From jiefu at openjdk.org  Sat Jul  1 00:05:17 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Sat, 1 Jul 2023 00:05:17 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v34]
In-Reply-To: <HDTz51ZPGpQuVQCfn6g40idvmPbG44WqRp4HDVN3UVM=.df608b19-f8a1-465a-9603-95d47337c7c4@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>
 <HDTz51ZPGpQuVQCfn6g40idvmPbG44WqRp4HDVN3UVM=.df608b19-f8a1-465a-9603-95d47337c7c4@github.com>
Message-ID: <Deg6iVh8PlTXg8YeQl2NNwl5J59-e25X4jZQRs1aMao=.49ad9917-e82e-456f-a573-d880e36d1654@github.com>

On Fri, 30 Jun 2023 21:12:11 GMT, ??? <duke at openjdk.org> wrote:

> can you create a new issue and i continue improving?

Filed: https://bugs.openjdk.org/browse/JDK-8311207

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1248348302

From mchung at openjdk.org  Sat Jul  1 00:11:02 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Sat, 1 Jul 2023 00:11:02 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: <R4xLoze2-JGgSy6d83bsyV_Cwg6DdUf2gMuo4N-tCWY=.32763d48-0dab-49fb-9916-f5922f1cc5be@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.

An alternative is to extend `ClassDesc::of` to accept the name of primitive types:


        ClassDesc.of("int").resolveConstantDesc(MethodHandles.publicLookup());
equivalent to:        
        ClassDesc.ofDescriptor("I").resolveConstantDesc(MethodHandles.publicLookup());   // currently supported

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

PR Comment: https://git.openjdk.org/jdk/pull/14743#issuecomment-1615290274

From liach at openjdk.org  Sat Jul  1 00:13:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 1 Jul 2023 00:13: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: <eOHGs7GpUPmKh7INrwfkISj8okP8iYcOc1h-XB2BaHw=.57aaee56-dddb-4f0b-9d50-a77665e4f8d4@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.

`ClassDesc.of()` already takes a binary name; another JVM programming language may declare a class with `int` binary name in the unnamed package, so we need a new API in `ClassDesc` for this purpose.

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

PR Comment: https://git.openjdk.org/jdk/pull/14743#issuecomment-1615294239

From liach at openjdk.org  Sat Jul  1 00:53:22 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 1 Jul 2023 00:53:22 GMT
Subject: [jdk21] RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString
Message-ID: <e9UoMfMUDlorD78ANVZaJa4Uf4J6Nnq51Jp9aOoKB_s=.eeb1914d-2bf4-45e3-a6c1-a58ebe1b08de@github.com>

Hi all,

This pull request contains a backport of commit [8c8e9d91](https://github.com/openjdk/jdk/commit/8c8e9d911d388f6ee621ed4d322efc56a9876708) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Chen Liang on 30 Jun 2023 and was reviewed by Mandy Chung.

The associated CSR https://bugs.openjdk.org/browse/JDK-8309823 has already been approved for release 21 as well.

Thanks!

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

Commit messages:
 - Backport 8c8e9d911d388f6ee621ed4d322efc56a9876708

Changes: https://git.openjdk.org/jdk21/pull/89/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=89&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309819
  Stats: 47 lines in 2 files changed: 10 ins; 10 del; 27 mod
  Patch: https://git.openjdk.org/jdk21/pull/89.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/89/head:pull/89

PR: https://git.openjdk.org/jdk21/pull/89

From joe.darcy at oracle.com  Sat Jul  1 01:13:30 2023
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 30 Jun 2023 18:13:30 -0700
Subject: List extending Collection/SequencedCollection
In-Reply-To: <CA+DiXd64Gm4TWHo5sno3j68_QKbTf1FvRE8N7X5H4RkKpR=F=w@mail.gmail.com>
References: <CA+DiXd7WgO2fuNJ=OAwUVutjBhk_1uN38uZ77=6-hNW6jCgyTg@mail.gmail.com>
 <591c1b08-a05c-5347-5965-c750aec10aa2@oracle.com>
 <CA+DiXd64Gm4TWHo5sno3j68_QKbTf1FvRE8N7X5H4RkKpR=F=w@mail.gmail.com>
Message-ID: <d40456ff-c11d-dcb8-417e-4c44f9473e11@oracle.com>

Hi Ryan,

Apropos of this discussion, I happened to recently give a talk to the 
JCP that in part covered behavioral compatibility in the JDK:

https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-06-13/JCP-EC-Public-Agenda-June-2023.html
https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-06-13/Contributing_to_OpenJDK_2023_04_12.pdf

There are many observable details of the JDK implementation, including 
reflective details, timing, etc. there are _not_ part of the interfaces 
users should rely on.

My current evaluation here is that it would set an unfortunate precedent 
to preclude making the sort of source changes in questions because of 
(potential) compatibility concerns in reflective modeling, especially in 
a feature release. (IMO, there is a stronger argument for not making 
such a change in an update release, but even there as the change is a 
semantically equivalent refactoring, I think it is generally fine.)

HTH,

-Joe

On 6/29/2023 11:30 AM, Ryan Ernst wrote:
> 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 mchung at openjdk.org  Sat Jul  1 01:36:03 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Sat, 1 Jul 2023 01:36:03 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: <P5HqINAyEPsNL6MP02zflunF8HWxM5A2UG57wmLT-LY=.b11fa92d-434f-41c4-8af0-b5e72317cd2d@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 descriptor string "I", "J", etc possible but not for "int", "long", "byte" etc  which are keywords and can't be used as identifiers to name a class.

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

PR Comment: https://git.openjdk.org/jdk/pull/14743#issuecomment-1615341542

From mchung at openjdk.org  Sat Jul  1 01:36:07 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Sat, 1 Jul 2023 01:36:07 GMT
Subject: [jdk21] RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString
In-Reply-To: <e9UoMfMUDlorD78ANVZaJa4Uf4J6Nnq51Jp9aOoKB_s=.eeb1914d-2bf4-45e3-a6c1-a58ebe1b08de@github.com>
References: <e9UoMfMUDlorD78ANVZaJa4Uf4J6Nnq51Jp9aOoKB_s=.eeb1914d-2bf4-45e3-a6c1-a58ebe1b08de@github.com>
Message-ID: <LM4ONfweOJEF6jyamhlyGTKDU833mx-12SGhShUqcmw=.22bc30b8-5632-4696-a12d-81730d0e047d@github.com>

On Sat, 1 Jul 2023 00:45:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [8c8e9d91](https://github.com/openjdk/jdk/commit/8c8e9d911d388f6ee621ed4d322efc56a9876708) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Chen Liang on 30 Jun 2023 and was reviewed by Mandy Chung.
> 
> The associated CSR https://bugs.openjdk.org/browse/JDK-8309823 has already been approved for release 21 as well.
> 
> Thanks!

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/89#pullrequestreview-1508023111

From liach at openjdk.org  Sat Jul  1 01:48:00 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 1 Jul 2023 01:48:00 GMT
Subject: [jdk21] RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString
In-Reply-To: <e9UoMfMUDlorD78ANVZaJa4Uf4J6Nnq51Jp9aOoKB_s=.eeb1914d-2bf4-45e3-a6c1-a58ebe1b08de@github.com>
References: <e9UoMfMUDlorD78ANVZaJa4Uf4J6Nnq51Jp9aOoKB_s=.eeb1914d-2bf4-45e3-a6c1-a58ebe1b08de@github.com>
Message-ID: <2U90dnIYINDVAGSf52ST5hBJ54I87byHA-_ruX_iPds=.da7b9b65-a089-4a8a-9e15-87aeba34a6de@github.com>

On Sat, 1 Jul 2023 00:45:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [8c8e9d91](https://github.com/openjdk/jdk/commit/8c8e9d911d388f6ee621ed4d322efc56a9876708) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Chen Liang on 30 Jun 2023 and was reviewed by Mandy Chung.
> 
> The associated CSR https://bugs.openjdk.org/browse/JDK-8309823 has already been approved for release 21 as well.
> 
> Thanks!

Thanks mandy! Can you help review #66 as well?

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

PR Comment: https://git.openjdk.org/jdk21/pull/89#issuecomment-1615347478

From duke at openjdk.org  Sat Jul  1 01:53:17 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 1 Jul 2023 01:53:17 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString
Message-ID: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>

[PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.

# Benchmark Result


sh make/devkit/createJMHBundle.sh
bash configure --with-jmh=build/jmh/jars
make test TEST="micro:java.util.UUIDBench.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)
-UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us

+Benchmark           (size)   Mode  Cnt   Score   Error   Units
+UUIDBench.toString   20000  thrpt   15  83.568 ? 0.401  ops/us (+34.74%)


## 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)
-UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us

+Benchmark           (size)   Mode  Cnt   Score   Error   Units
+UUIDBench.toString   20000  thrpt   15  95.653 ? 0.262  ops/us (+7.87%)



## 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)
-UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us

+Benchmark           (size)   Mode  Cnt   Score   Error   Units
+UUIDBench.toString   20000  thrpt   15  51.159 ? 1.639  ops/us


## 4. MacBookPro M1 Pro
``` diff
-Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
-UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us

+Benchmark           (size)   Mode  Cnt    Score   Error   Units
+UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)


## 5. Orange Pi 5 Plus

``` diff
-Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
-UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us

+Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
+UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)

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

Commit messages:
 - use big endian
 - 8311207: Optimization for j.u.UUID.toString

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

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

From duke at openjdk.org  Sat Jul  1 02:08:13 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 1 Jul 2023 02:08:13 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v34]
In-Reply-To: <Deg6iVh8PlTXg8YeQl2NNwl5J59-e25X4jZQRs1aMao=.49ad9917-e82e-456f-a573-d880e36d1654@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>
 <HDTz51ZPGpQuVQCfn6g40idvmPbG44WqRp4HDVN3UVM=.df608b19-f8a1-465a-9603-95d47337c7c4@github.com>
 <Deg6iVh8PlTXg8YeQl2NNwl5J59-e25X4jZQRs1aMao=.49ad9917-e82e-456f-a573-d880e36d1654@github.com>
Message-ID: <H4NS-vJd_gFCVtBqjLvUsy7If9Q1g9c9U8TpGxNClX4=.35ec6f02-58d3-43a9-8f91-f87d20a5826a@github.com>

On Sat, 1 Jul 2023 00:01:57 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> can you create a new issue and i continue improving?
>
>> can you create a new issue and i continue improving?
> 
> Filed: https://bugs.openjdk.org/browse/JDK-8311207

@liach @RogerRiggs continue discussion in [PR 14745](https://github.com/openjdk/jdk/pull/14745)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1248381502

From liach at openjdk.org  Sat Jul  1 02:11:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 1 Jul 2023 02:11:53 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString
In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
Message-ID: <o7QrgadMmKKRNW8uEwt2ukueQ1W3cJezF-3RhVcq99Y=.dfcb7f7c-fc29-48b6-9618-ad8a47a1f322@github.com>

On Sat, 1 Jul 2023 01:44:15 GMT, ??? <duke at openjdk.org> wrote:

> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
> 
> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.util.UUIDBench.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)
> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
> 
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
> 
> 
> ## 4. MacBookPro M1 Pro
> ``` diff
> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
> 
> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
> 
> 
> ## 5. Orange Pi 5 Plus
> 
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)

Is using `Unsafe` directly consistently faster than using ByteArray? It should have similar performance as ByteArray's VarHandle is simply a wrapper around Unsafe's put/get methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1615360439

From mchung at openjdk.org  Sat Jul  1 02:35:53 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Sat, 1 Jul 2023 02:35:53 GMT
Subject: [jdk21] RFR: 8310838: Correct range notations in MethodTypeDesc
 specification
In-Reply-To: <IVN1Fh7512My1ogwGPz_oHzD9X8tb6C52VmVICYCsaw=.433f1bd4-7a3e-46e3-be7e-7489bd82c87d@github.com>
References: <IVN1Fh7512My1ogwGPz_oHzD9X8tb6C52VmVICYCsaw=.433f1bd4-7a3e-46e3-be7e-7489bd82c87d@github.com>
Message-ID: <vtCWJ-_q9AVKK9OtKtNdEWeMLa6679gxL9j9rOPySys=.ea5905db-f9ee-437b-a424-2ee48fab6841@github.com>

On Mon, 26 Jun 2023 22:28:23 GMT, Chen Liang <liach at openjdk.org> wrote:

> 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!

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/66#pullrequestreview-1508057889

From duke at openjdk.org  Sat Jul  1 02:39:53 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 1 Jul 2023 02:39:53 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString
In-Reply-To: <o7QrgadMmKKRNW8uEwt2ukueQ1W3cJezF-3RhVcq99Y=.dfcb7f7c-fc29-48b6-9618-ad8a47a1f322@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <o7QrgadMmKKRNW8uEwt2ukueQ1W3cJezF-3RhVcq99Y=.dfcb7f7c-fc29-48b6-9618-ad8a47a1f322@github.com>
Message-ID: <1Obqiie0hWl9_617qSsXhor-jBrEE8mXbRvfCsN-QYs=.3e8a61e9-a21f-4f50-b103-2b1a031f33ca@github.com>

On Sat, 1 Jul 2023 02:09:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Is using `Unsafe` directly consistently faster than using ByteArray? It should have similar performance as ByteArray's VarHandle is simply a wrapper around Unsafe's put/get methods.

Using Unsafe on aliyun_ecs_c8i.xlarge and MacBookPro M1 Pro is faster than ByteArray, and I haven't figured out why

> 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 packDigits(int b0, int b1) {
> 
> I recommend such a refactor:
> 
> /**
>  * Return a big-endian packed integer for the 4 ASCII bytes for an input unsigned short value.
>  */
> static int packDigits16(int b) {
>     return (DIGITS[(b >> 8) & 0xff] << 16) | DIGITS[b & 0xff];
> }
> 
> And all your usages can be `HexDigits.packDigits16(((int) msb) >> 16)` and `HexDigits.packDigits16((int) msb)` without the `>> 24` and `>> 8`

but it's return an int value

> src/java.base/share/classes/java/util/HexDigits.java line 115:
> 
>> 113:      * Combine four hex shorts into one long based on big endian
>> 114:      */
>> 115:     static long packDigits(int b0, int b1, int b2, int b3) {
> 
> Same comment here:
> 
> 
> /**
>  * Return a big-endian packed long for the 8 ASCII bytes for an input unsigned int value.
>  */
> static long packDigits32(int b) {
>     return (((long) DIGITS[(b >> 24) & 0xff]) << 48)
>             | (((long) DIGITS[(b >> 16) & 0xff]) << 32)
>             | (DIGITS[(b >> 8) & 0xff] << 16)
>             | DIGITS[b & 0xff];
> }
> 
> And use sites become:
> 
> // old
> HexDigits.packDigits((int) (msb >> 56), (int) (msb >> 48), (int) (msb >> 40), (int) (msb >> 32))
> // new
> HexDigits.packDigits32((int) (msb >> 32))
> 
> and `HexDigits.packDigits32((int) (lsb >> 16))`

but it's return a long value

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1615378812
PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1248397231
PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1248397251

From liach at openjdk.org  Sat Jul  1 02:39:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 1 Jul 2023 02:39:54 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString
In-Reply-To: <1Obqiie0hWl9_617qSsXhor-jBrEE8mXbRvfCsN-QYs=.3e8a61e9-a21f-4f50-b103-2b1a031f33ca@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <o7QrgadMmKKRNW8uEwt2ukueQ1W3cJezF-3RhVcq99Y=.dfcb7f7c-fc29-48b6-9618-ad8a47a1f322@github.com>
 <1Obqiie0hWl9_617qSsXhor-jBrEE8mXbRvfCsN-QYs=.3e8a61e9-a21f-4f50-b103-2b1a031f33ca@github.com>
Message-ID: <iJBvHCrflljC3T-LXJCyELSZWY7cEFQIsD10EGyD2_4=.16e881f1-e13d-4250-9b18-9fd4d079a431@github.com>

On Sat, 1 Jul 2023 02:33:11 GMT, ??? <duke at openjdk.org> wrote:

> > Is using `Unsafe` directly consistently faster than using ByteArray? It should have similar performance as ByteArray's VarHandle is simply a wrapper around Unsafe's put/get methods.
> 
> Using Unsafe on aliyun_ecs_c8i.xlarge and MacBookPro M1 Pro is faster than ByteArray, and I haven't figured out why

Then it's probably VarHandle's overhead. No worries; your change to use Unsafe is totally fine.

Meanwhile, can you enable GitHub actions on your fork, so it can detect compile and test errors? Like this:
<img width="1259" alt="image" src="https://github.com/openjdk/jdk/assets/7806504/fa843978-757c-4ba0-a23f-055f25ddda7e">

>> 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 packDigits(int b0, int b1) {
>> 
>> I recommend such a refactor:
>> 
>> /**
>>  * Return a big-endian packed integer for the 4 ASCII bytes for an input unsigned short value.
>>  */
>> static int packDigits16(int b) {
>>     return (DIGITS[(b >> 8) & 0xff] << 16) | DIGITS[b & 0xff];
>> }
>> 
>> And all your usages can be `HexDigits.packDigits16(((int) msb) >> 16)` and `HexDigits.packDigits16((int) msb)` without the `>> 24` and `>> 8`
>
> but it's return an int value

The current code snippet still returns a int value... I think I can probably make a patch and demonstrate.

>> src/java.base/share/classes/java/util/HexDigits.java line 115:
>> 
>>> 113:      * Combine four hex shorts into one long based on big endian
>>> 114:      */
>>> 115:     static long packDigits(int b0, int b1, int b2, int b3) {
>> 
>> Same comment here:
>> 
>> 
>> /**
>>  * Return a big-endian packed long for the 8 ASCII bytes for an input unsigned int value.
>>  */
>> static long packDigits32(int b) {
>>     return (((long) DIGITS[(b >> 24) & 0xff]) << 48)
>>             | (((long) DIGITS[(b >> 16) & 0xff]) << 32)
>>             | (DIGITS[(b >> 8) & 0xff] << 16)
>>             | DIGITS[b & 0xff];
>> }
>> 
>> And use sites become:
>> 
>> // old
>> HexDigits.packDigits((int) (msb >> 56), (int) (msb >> 48), (int) (msb >> 40), (int) (msb >> 32))
>> // new
>> HexDigits.packDigits32((int) (msb >> 32))
>> 
>> and `HexDigits.packDigits32((int) (lsb >> 16))`
>
> but it's return a long value

My fault, fixed the return type in my code snippet.

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1615379558
PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1248397625
PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1248397481

From liach at openjdk.org  Sat Jul  1 02:39:55 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 1 Jul 2023 02:39:55 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString
In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
Message-ID: <46H4JIv8ok-pDZ2xaLCS_h7K1e8oZlKVb5aR9VJG_kA=.03064673-22a7-4a2e-a74b-ff4c75d9a028@github.com>

On Sat, 1 Jul 2023 01:44:15 GMT, ??? <duke at openjdk.org> wrote:

> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
> 
> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.util.UUIDBench.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)
> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
> 
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
> 
> 
> ## 4. MacBookPro M1 Pro
> ``` diff
> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
> 
> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
> 
> 
> ## 5. Orange Pi 5 Plus
> 
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)

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 packDigits(int b0, int b1) {

I recommend such a refactor:

/**
 * Return a big-endian packed integer for the 4 ASCII bytes for an input unsigned short value.
 */
static int packDigits16(int b) {
    return (DIGITS[(b >> 8) & 0xff] << 16) | DIGITS[b & 0xff];
}

And all your usages can be `HexDigits.packDigits16(((int) msb) >> 16)` and `HexDigits.packDigits16((int) msb)` without the `>> 24` and `>> 8`

src/java.base/share/classes/java/util/HexDigits.java line 115:

> 113:      * Combine four hex shorts into one long based on big endian
> 114:      */
> 115:     static long packDigits(int b0, int b1, int b2, int b3) {

Same comment here:


/**
 * Return a big-endian packed long for the 8 ASCII bytes for an input unsigned int value.
 */
static long packDigits32(int b) {
    return (((long) DIGITS[(b >> 24) & 0xff]) << 48)
            | (((long) DIGITS[(b >> 16) & 0xff]) << 32)
            | (DIGITS[(b >> 8) & 0xff] << 16)
            | DIGITS[b & 0xff];
}

And use sites become:

// old
HexDigits.packDigits((int) (msb >> 56), (int) (msb >> 48), (int) (msb >> 40), (int) (msb >> 32))
// new
HexDigits.packDigits32((int) (msb >> 32))

and `HexDigits.packDigits32((int) (lsb >> 16))`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1248389049
PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1248394179

From duke at openjdk.org  Sat Jul  1 02:42:54 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 1 Jul 2023 02:42:54 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString
In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
Message-ID: <v_cRP0yDu7qbUDtuhQGZs5ADTAiXRkG0PjuvGSwhNBs=.8a0d17ee-94a2-4007-8d26-3ab8170b68b0@github.com>

On Sat, 1 Jul 2023 01:44:15 GMT, ??? <duke at openjdk.org> wrote:

> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
> 
> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.util.UUIDBench.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)
> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
> 
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
> 
> 
> ## 4. MacBookPro M1 Pro
> ``` diff
> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
> 
> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
> 
> 
> ## 5. Orange Pi 5 Plus
> 
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)

![image](https://github.com/openjdk/jdk/assets/1166785/38c75145-b685-4c4e-a53a-97f8c44778e3)

it's enabled

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1615382771

From liach at openjdk.org  Sat Jul  1 02:47:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 1 Jul 2023 02:47:05 GMT
Subject: [jdk21] Integrated: 8310838: Correct range notations in MethodTypeDesc
 specification
In-Reply-To: <IVN1Fh7512My1ogwGPz_oHzD9X8tb6C52VmVICYCsaw=.433f1bd4-7a3e-46e3-be7e-7489bd82c87d@github.com>
References: <IVN1Fh7512My1ogwGPz_oHzD9X8tb6C52VmVICYCsaw=.433f1bd4-7a3e-46e3-be7e-7489bd82c87d@github.com>
Message-ID: <xjW3qwUipFl8P2GbcW1GBPTK3tQq-RHff9feeKn8BJ8=.5bcaff83-2def-4ad3-a20a-901ed6352084@github.com>

On Mon, 26 Jun 2023 22:28:23 GMT, Chen Liang <liach at openjdk.org> wrote:

> 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!

This pull request has now been integrated.

Changeset: bbcabe42
Author:    Chen Liang <liach at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/bbcabe4200da92f932a541e143a4adb337fddba0
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8310838: Correct range notations in MethodTypeDesc specification

Reviewed-by: mchung
Backport-of: a197ee797b3580d9f85636522587d3f6418dff6a

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

PR: https://git.openjdk.org/jdk21/pull/66

From liach at openjdk.org  Sat Jul  1 02:48:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 1 Jul 2023 02:48:05 GMT
Subject: [jdk21] Integrated: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString
In-Reply-To: <e9UoMfMUDlorD78ANVZaJa4Uf4J6Nnq51Jp9aOoKB_s=.eeb1914d-2bf4-45e3-a6c1-a58ebe1b08de@github.com>
References: <e9UoMfMUDlorD78ANVZaJa4Uf4J6Nnq51Jp9aOoKB_s=.eeb1914d-2bf4-45e3-a6c1-a58ebe1b08de@github.com>
Message-ID: <ZI3RWK67InGdh9U5idLVFpSIy2S1J-iw4GU2RKZyGxs=.35526032-b3c6-4a0e-b2b2-3379da42a70a@github.com>

On Sat, 1 Jul 2023 00:45:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [8c8e9d91](https://github.com/openjdk/jdk/commit/8c8e9d911d388f6ee621ed4d322efc56a9876708) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Chen Liang on 30 Jun 2023 and was reviewed by Mandy Chung.
> 
> The associated CSR https://bugs.openjdk.org/browse/JDK-8309823 has already been approved for release 21 as well.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 8088bc40
Author:    Chen Liang <liach at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/8088bc4033884adbd249ae9eb92c3ad1b81a69da
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
Backport-of: 8c8e9d911d388f6ee621ed4d322efc56a9876708

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

PR: https://git.openjdk.org/jdk21/pull/89

From liach at openjdk.org  Sat Jul  1 02:48:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 1 Jul 2023 02:48:53 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString
In-Reply-To: <v_cRP0yDu7qbUDtuhQGZs5ADTAiXRkG0PjuvGSwhNBs=.8a0d17ee-94a2-4007-8d26-3ab8170b68b0@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <v_cRP0yDu7qbUDtuhQGZs5ADTAiXRkG0PjuvGSwhNBs=.8a0d17ee-94a2-4007-8d26-3ab8170b68b0@github.com>
Message-ID: <-T65nJKW0UPEcWlXHiFDJ51n5A2e3wNl6hmNXZhA9rE=.8db181b3-b0c8-4044-ad4b-70ec99215903@github.com>

On Sat, 1 Jul 2023 02:40:22 GMT, ??? <duke at openjdk.org> wrote:

>> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.util.UUIDBench.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)
>> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
>> 
>> 
>> ## 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)
>> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
>> 
>> 
>> 
>> ## 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)
>> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
>> 
>> 
>> ## 4. MacBookPro M1 Pro
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
>> 
>> 
>> ## 5. Orange Pi 5 Plus
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
>> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)
>
> ![image](https://github.com/openjdk/jdk/assets/1166785/38c75145-b685-4c4e-a53a-97f8c44778e3)
> 
> it's enabled

@wenshao I have made my suggestions into a patch for you: https://github.com/wenshao/jdk/pull/1
Feel free to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1615387362

From duke at openjdk.org  Sat Jul  1 02:59:06 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 1 Jul 2023 02:59:06 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString [v2]
In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
Message-ID: <kZ5d8vcVvqgzt-YLlJEvDbh2MEew3JDFgq0PzrGtzBo=.28f0b219-ad04-4f18-99e2-1c335177aef0@github.com>

> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
> 
> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.util.UUIDBench.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)
> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
> 
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
> 
> 
> ## 4. MacBookPro M1 Pro
> ``` diff
> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
> 
> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
> 
> 
> ## 5. Orange Pi 5 Plus
> 
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)

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

 - Merge pull request #1 from liachmodded/optimization_for_uuid_to_string
   
   Suggested HexDigits change
 - Suggested HexDigits change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14745/files
  - new: https://git.openjdk.org/jdk/pull/14745/files/244c0eb1..425559f6

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

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

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

From duke at openjdk.org  Sat Jul  1 03:05:53 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 1 Jul 2023 03:05:53 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString
In-Reply-To: <v_cRP0yDu7qbUDtuhQGZs5ADTAiXRkG0PjuvGSwhNBs=.8a0d17ee-94a2-4007-8d26-3ab8170b68b0@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <v_cRP0yDu7qbUDtuhQGZs5ADTAiXRkG0PjuvGSwhNBs=.8a0d17ee-94a2-4007-8d26-3ab8170b68b0@github.com>
Message-ID: <UiHbvvIae5atTs4FnKmDjN9JlZtKJzehR0256ZgXZyE=.0b61b47f-40b0-41a1-ad31-a07a40a7f38e@github.com>

On Sat, 1 Jul 2023 02:40:22 GMT, ??? <duke at openjdk.org> wrote:

>> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.util.UUIDBench.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)
>> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
>> 
>> 
>> ## 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)
>> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
>> 
>> 
>> 
>> ## 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)
>> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
>> 
>> 
>> ## 4. MacBookPro M1 Pro
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
>> 
>> 
>> ## 5. Orange Pi 5 Plus
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
>> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)
>
> ![image](https://github.com/openjdk/jdk/assets/1166785/38c75145-b685-4c4e-a53a-97f8c44778e3)
> 
> it's enabled

> @wenshao I have made my suggestions into a patch for you: [wenshao#1](https://github.com/wenshao/jdk/pull/1) Feel free to review.

your version performance is a bit worse, if i can't find the reason, I will restore the previous version

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1615400139

From liach at openjdk.org  Sat Jul  1 03:08:52 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 1 Jul 2023 03:08:52 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString
In-Reply-To: <v_cRP0yDu7qbUDtuhQGZs5ADTAiXRkG0PjuvGSwhNBs=.8a0d17ee-94a2-4007-8d26-3ab8170b68b0@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <v_cRP0yDu7qbUDtuhQGZs5ADTAiXRkG0PjuvGSwhNBs=.8a0d17ee-94a2-4007-8d26-3ab8170b68b0@github.com>
Message-ID: <kpOcq5kD_t_CD2qOgwaVk6BFtS0zcRLFAlg3vE9z8DY=.e7fcc19c-c461-4c11-b14e-fb61ccf162bb@github.com>

On Sat, 1 Jul 2023 02:40:22 GMT, ??? <duke at openjdk.org> wrote:

>> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.util.UUIDBench.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)
>> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
>> 
>> 
>> ## 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)
>> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
>> 
>> 
>> 
>> ## 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)
>> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
>> 
>> 
>> ## 4. MacBookPro M1 Pro
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
>> 
>> 
>> ## 5. Orange Pi 5 Plus
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
>> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)
>
> ![image](https://github.com/openjdk/jdk/assets/1166785/38c75145-b685-4c4e-a53a-97f8c44778e3)
> 
> it's enabled

> > @wenshao I have made my suggestions into a patch for you: [wenshao#1](https://github.com/wenshao/jdk/pull/1) Feel free to review.
> 
> your version performance is a bit worse, if i can't find the reason, I will restore the previous version

Can you post the benchmark results? And do you have like a baseline for the benchmarks, as there may be other factors that affect performance from run to run?

Also, my fault for actions: can you go to your actions tab and enable actions for your fork like this?
<img width="1267" alt="image" src="https://github.com/openjdk/jdk/assets/7806504/d049d88e-e4fc-4d35-b2a4-87fbfe82dbd5">

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1615401266

From duke at openjdk.org  Sat Jul  1 03:11:54 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 1 Jul 2023 03:11:54 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString
In-Reply-To: <kpOcq5kD_t_CD2qOgwaVk6BFtS0zcRLFAlg3vE9z8DY=.e7fcc19c-c461-4c11-b14e-fb61ccf162bb@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <v_cRP0yDu7qbUDtuhQGZs5ADTAiXRkG0PjuvGSwhNBs=.8a0d17ee-94a2-4007-8d26-3ab8170b68b0@github.com>
 <kpOcq5kD_t_CD2qOgwaVk6BFtS0zcRLFAlg3vE9z8DY=.e7fcc19c-c461-4c11-b14e-fb61ccf162bb@github.com>
Message-ID: <UFYbl726zaUFyHqupNC4AuajAPWKi6EW-izuMS3vNHk=.93af92d3-fe61-49c2-94e8-fe8686d5df6c@github.com>

On Sat, 1 Jul 2023 03:06:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> ![image](https://github.com/openjdk/jdk/assets/1166785/38c75145-b685-4c4e-a53a-97f8c44778e3)
>> 
>> it's enabled
>
>> > @wenshao I have made my suggestions into a patch for you: [wenshao#1](https://github.com/wenshao/jdk/pull/1) Feel free to review.
>> 
>> your version performance is a bit worse, if i can't find the reason, I will restore the previous version
> 
> Can you post the benchmark results? And do you have like a baseline for the benchmarks, as there may be other factors that affect performance from run to run?
> 
> Also, my fault for actions: can you go to your actions tab and enable actions for your fork like this?
> <img width="1267" alt="image" src="https://github.com/openjdk/jdk/assets/7806504/d049d88e-e4fc-4d35-b2a4-87fbfe82dbd5">

@liach Your version performance is a bit worse, If I can't find the reason, I will revert to the previous version

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1615402440

From duke at openjdk.org  Sat Jul  1 03:22:06 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 1 Jul 2023 03:22:06 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString [v3]
In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
Message-ID: <ZdeYUDBiogN3nfGvYFXc4JQMHEFN9jkmLqyCKpS0_cs=.2a9f0958-a844-4e44-9500-e429cc865ee7@github.com>

> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
> 
> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.util.UUIDBench.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)
> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
> 
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
> 
> 
> ## 4. MacBookPro M1 Pro
> ``` diff
> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
> 
> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
> 
> 
> ## 5. Orange Pi 5 Plus
> 
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)

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

  revert to the previous version

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14745/files
  - new: https://git.openjdk.org/jdk/pull/14745/files/425559f6..76dba964

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

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

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

From duke at openjdk.org  Sat Jul  1 03:46:54 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 1 Jul 2023 03:46:54 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString
In-Reply-To: <kpOcq5kD_t_CD2qOgwaVk6BFtS0zcRLFAlg3vE9z8DY=.e7fcc19c-c461-4c11-b14e-fb61ccf162bb@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <v_cRP0yDu7qbUDtuhQGZs5ADTAiXRkG0PjuvGSwhNBs=.8a0d17ee-94a2-4007-8d26-3ab8170b68b0@github.com>
 <kpOcq5kD_t_CD2qOgwaVk6BFtS0zcRLFAlg3vE9z8DY=.e7fcc19c-c461-4c11-b14e-fb61ccf162bb@github.com>
Message-ID: <ZAl-C-xfMaoiVrD_Tkjm9sm3HQTd9ffsvlyEKimSMYU=.7032a085-cba5-4559-ac3e-f1866c42bf3b@github.com>

On Sat, 1 Jul 2023 03:06:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> ![image](https://github.com/openjdk/jdk/assets/1166785/38c75145-b685-4c4e-a53a-97f8c44778e3)
>> 
>> it's enabled
>
>> > @wenshao I have made my suggestions into a patch for you: [wenshao#1](https://github.com/wenshao/jdk/pull/1) Feel free to review.
>> 
>> your version performance is a bit worse, if i can't find the reason, I will restore the previous version
> 
> Can you post the benchmark results? And do you have like a baseline for the benchmarks, as there may be other factors that affect performance from run to run?
> 
> Also, my fault for actions: can you go to your actions tab and enable actions for your fork like this?
> <img width="1267" alt="image" src="https://github.com/openjdk/jdk/assets/7806504/d049d88e-e4fc-4d35-b2a4-87fbfe82dbd5">

@liach 

## MacBookPro M1 Pro
* Update 02
current version [76dba964](https://git.openjdk.org/jdk/pull/14745/files/76dba9649a530a2f21574f3dff1aa55a6ebe8888)

Benchmark           (size)   Mode  Cnt    Score   Error   Units 
UUIDBench.toString   20000  thrpt   15  104.262 ? 2.199  ops/us


* Update 01
your version [425559f6](https://git.openjdk.org/jdk/pull/14745/files/425559f65a3e5f72323abdadbbf9df426e196d9b)


Benchmark           (size)   Mode  Cnt   Score   Error   Units
UUIDBench.toString   20000  thrpt   15  81.622 ? 0.194  ops/us

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1615435719

From duke at openjdk.org  Sat Jul  1 03:57:53 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 1 Jul 2023 03:57:53 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString
In-Reply-To: <kpOcq5kD_t_CD2qOgwaVk6BFtS0zcRLFAlg3vE9z8DY=.e7fcc19c-c461-4c11-b14e-fb61ccf162bb@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <v_cRP0yDu7qbUDtuhQGZs5ADTAiXRkG0PjuvGSwhNBs=.8a0d17ee-94a2-4007-8d26-3ab8170b68b0@github.com>
 <kpOcq5kD_t_CD2qOgwaVk6BFtS0zcRLFAlg3vE9z8DY=.e7fcc19c-c461-4c11-b14e-fb61ccf162bb@github.com>
Message-ID: <PVg0J5JIZVKs_aE4sD6_ALCI-0XWpD1AgpSLhCZA6HA=.eeb3c02c-9fec-4885-931a-edfd07223d9d@github.com>

On Sat, 1 Jul 2023 03:06:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> ![image](https://github.com/openjdk/jdk/assets/1166785/38c75145-b685-4c4e-a53a-97f8c44778e3)
>> 
>> it's enabled
>
>> > @wenshao I have made my suggestions into a patch for you: [wenshao#1](https://github.com/wenshao/jdk/pull/1) Feel free to review.
>> 
>> your version performance is a bit worse, if i can't find the reason, I will restore the previous version
> 
> Can you post the benchmark results? And do you have like a baseline for the benchmarks, as there may be other factors that affect performance from run to run?
> 
> Also, my fault for actions: can you go to your actions tab and enable actions for your fork like this?
> <img width="1267" alt="image" src="https://github.com/openjdk/jdk/assets/7806504/d049d88e-e4fc-4d35-b2a4-87fbfe82dbd5">

@liach I guess your version is slower because it doesn't support out-of-order execution.

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1615445405

From duke at openjdk.org  Sat Jul  1 07:59:08 2023
From: duke at openjdk.org (Swati Sharma)
Date: Sat, 1 Jul 2023 07:59:08 GMT
Subject: RFR: 8311178: JMH tests don't scale well when sharing output buffers
Message-ID: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>

The below benchmark files have scaling issues due to cache contention and leads to poor scaling when run on multiple threads. The patch sets the scope from benchmark level to thread level to fix the issue:
- org/openjdk/bench/java/io/DataOutputStreamTest.java
- org/openjdk/bench/java/lang/ArrayCopyObject.java
- org/openjdk/bench/java/lang/ArrayFiddle.java
- org/openjdk/bench/java/time/format/DateTimeFormatterBench.java
- org/openjdk/bench/jdk/incubator/vector/IndexInRangeBenchmark.java
- org/openjdk/bench/jdk/incubator/vector/MemorySegmentVectorAccess.java
- org/openjdk/bench/jdk/incubator/vector/StoreMaskedBenchmark.java
- org/openjdk/bench/jdk/incubator/vector/StoreMaskedIOOBEBenchmark.java
- org/openjdk/bench/vm/compiler/ArrayFill.java
- org/openjdk/bench/vm/compiler/IndexVector.java

Also removing the static scope for variables in org/openjdk/bench/jdk/incubator/vector/VectorFPtoIntCastOperations.java for better scaling.

Please review and share your feedback.

Thanks,
Swati

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

Commit messages:
 - 8311178: JMH tests don't scale well when sharing output buffers

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

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

From duke at openjdk.org  Sat Jul  1 09:30:57 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 1 Jul 2023 09:30:57 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString [v3]
In-Reply-To: <ZdeYUDBiogN3nfGvYFXc4JQMHEFN9jkmLqyCKpS0_cs=.2a9f0958-a844-4e44-9500-e429cc865ee7@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <ZdeYUDBiogN3nfGvYFXc4JQMHEFN9jkmLqyCKpS0_cs=.2a9f0958-a844-4e44-9500-e429cc865ee7@github.com>
Message-ID: <OM3kOVFMUzitfFnSNXChhN68j0EO4OMFLmI5Vi-H63g=.e1f5d470-35fa-45be-8258-284f375d7264@github.com>

On Sat, 1 Jul 2023 03:22:06 GMT, ??? <duke at openjdk.org> wrote:

>> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.util.UUIDBench.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)
>> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
>> 
>> 
>> ## 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)
>> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
>> 
>> 
>> 
>> ## 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)
>> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
>> 
>> 
>> ## 4. MacBookPro M1 Pro
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
>> 
>> 
>> ## 5. Orange Pi 5 Plus
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
>> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert to the previous version

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

> 467:     @Override
> 468:     public String toString() {
> 469:         Unsafe unsafe = Unsafe.getUnsafe();

This?should probably be?stored in?a?`private static?final`?field.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1248729806

From duke at openjdk.org  Sat Jul  1 10:06:54 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 1 Jul 2023 10:06:54 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString [v4]
In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
Message-ID: <j4hmh7xzQDN86usT9a3VdGL0wv5p6BOYEdszSTbTxLU=.0762a670-f7da-485b-b684-8a12ebdfdfd2@github.com>

> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
> 
> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.util.UUIDBench.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)
> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
> 
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
> 
> 
> ## 4. MacBookPro M1 Pro
> ``` diff
> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
> 
> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
> 
> 
> ## 5. Orange Pi 5 Plus
> 
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)

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

  private static final Unsafe

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14745/files
  - new: https://git.openjdk.org/jdk/pull/14745/files/76dba964..43ec99d0

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

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

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

From duke at openjdk.org  Sat Jul  1 10:09:54 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 1 Jul 2023 10:09:54 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: <HYMaYgWe3-QdviQRhnbqLh7eonRPg-yI6szqiRHXh98=.c4f03d67-c902-4695-9da5-12db30d43eab@github.com>

On Thu, 29 Jun 2023 20:26: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 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`?

If it is not present, I get following output (sorry for German - `./configure` doesn't allow `JAVA_TOOL_OPTIONS` to be set to `-Duser.language=en`


windir='C:\WINDOWS' \
    'c:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\images\jdk\bin\javac' \
        -J-Xmx768m \
        -J-XX:MaxRAMPercentage=2.08333 \
        -J'-Dtest.boot.jdk=c:\progra~1\openjdk\jdk-20~1.1' \
        -J'-Djava.io.tmpdir=c:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jlink_JLink100Modules_java\tmp' \
        -J-ea \
        -J-esa \
        -J-Dtest.vm.opts='-Xmx768m -XX:MaxRAMPercentage=2.08333 -Dtest.boot.jdk=c:\progra~1\openjdk\jdk-20~1.1 -Djava.io.tmpdir=c:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jlink_JLink100Modules_java\tmp -ea -esa' \
        -J-Dtest.tool.vm.opts='-J-Xmx768m -J-XX:MaxRAMPercentage=2.08333 -J-Dtest.boot.jdk=c:\progra~1\openjdk\jdk-20~1.1 -J-Djava.io.tmpdir=c:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jlink_JLink100Modules_java\tmp -J-ea -J-esa' \
        -J-Dtest.compiler.opts= \
        -J-Dtest.java.opts= \
        -J-Dtest.jdk='c:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\images\jdk' \
        -J-Dcompile.jdk='c:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\images\jdk' \
        -J-Dtest.timeout.factor=4.0 \
        -J-Dtest.nativepath='c:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\images\test\jdk\jtreg\native' \
        -J-Dtest.root='C:\git-repositories\jdk\jdk\test\jdk' \
        -J-Dtest.name=tools/jlink/JLink100Modules.java \
        -J-Dtest.file='C:\git-repositories\jdk\jdk\test\jdk\tools\jlink\JLink100Modules.java' \
        -J-Dtest.src='C:\git-repositories\jdk\jdk\test\jdk\tools\jlink' \
        -J-Dtest.src.path='C:\git-repositories\jdk\jdk\test\jdk\tools\jlink;C:\git-repositories\jdk\jdk\test\jdk\tools\lib' \
        -J-Dtest.classes='C:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jlink_JLink100Modules_java\classes\0\tools\jlink\JLink100Modules.d' \
        -J-Dtest.class.path='C:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jlink_JLink100Modules_java\classes\0\tools\jlink\JLink100Modules.d;C:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jlink_JLink100Modules_java\classes\0\tools\lib' \
        -J-Dtest.class.path.prefix='C:\git-repositories\jdk\jdk\test\jdk\tools\jlink;C:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jlink_JLink100Modules_java\classes\0\tools\lib' \
        -J-Dtest.modules='java.base/jdk.internal.jimage jdk.jlink/jdk.tools.jlink.internal jdk.jlink/jdk.tools.jlink.plugin jdk.jlink/jdk.tools.jmod jdk.jlink/jdk.tools.jimage jdk.compiler' \
        --add-modules java.base,jdk.jlink,jdk.compiler \
        --add-exports java.base/jdk.internal.jimage=ALL-UNNAMED \
        --add-exports jdk.jlink/jdk.tools.jlink.internal=ALL-UNNAMED \
        --add-exports jdk.jlink/jdk.tools.jlink.plugin=ALL-UNNAMED \
        --add-exports jdk.jlink/jdk.tools.jmod=ALL-UNNAMED \
        --add-exports jdk.jlink/jdk.tools.jimage=ALL-UNNAMED \
        -d 'C:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jlink_JLink100Modules_java\classes\0\tools\lib' \
        -sourcepath 'C:\git-repositories\jdk\jdk\test\jdk\tools\lib' \
        -classpath 'C:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jlink_JLink100Modules_java\classes\0\tools\lib' 'C:\git-repositories\jdk\jdk\test\jdk\tools\lib\tests\Helper.java' 'C:\git-repositories\jdk\jdk\test\jdk\tools\lib\tests\JImageGenerator.java' 'C:\git-repositories\jdk\jdk\test\jdk\tools\lib\tests\JImageValidator.java' 'C:\git-repositories\jdk\jdk\test\jdk\tools\lib\tests\Result.java'
direct:
C:\git-repositories\jdk\jdk\test\jdk\tools\lib\tests\JImageValidator.java:36: Fehler: Package com.sun.tools.classfile ist nicht sichtbar
import com.sun.tools.classfile.ClassFile;
                    ^
  (Package com.sun.tools.classfile wird in Modul jdk.jdeps deklariert, aber nicht in das unbenannte Modul exportiert)
C:\git-repositories\jdk\jdk\test\jdk\tools\lib\tests\JImageValidator.java:37: Fehler: Package com.sun.tools.classfile ist nicht sichtbar
import com.sun.tools.classfile.ConstantPoolException;
                    ^
  (Package com.sun.tools.classfile wird in Modul jdk.jdeps deklariert, aber nicht in das unbenannte Modul exportiert)
2 Fehler

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1248754219

From duke at openjdk.org  Sat Jul  1 10:19:42 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 1 Jul 2023 10:19:42 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v9]
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: <yHb0GeRbitVSSqgEwFjXtpT3jDv5mv-Fw7LmyxL6GEM=.03f7c063-0413-46f0-9794-37f8b2a1c7ac@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 two additional commits since the last revision:

 - private static final Unsafe
 - code format

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14699/files
  - new: https://git.openjdk.org/jdk/pull/14699/files/dd13911a..632ff751

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

  Stats: 20 lines in 3 files changed: 6 ins; 2 del; 12 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  Sat Jul  1 10:44:05 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 1 Jul 2023 10:44:05 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v7]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <i4_78RE9Co-LHiyq7IA9hsvisJx4UskEsg-oaeIKkWY=.a047ec2c-7fb9-4a4a-a9a3-8e8180318c14@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 three additional commits since the last revision:

 - Add description
 - Fix nit (indent)
 - Add parameterization for the number of moduleDescriptors per helper method (was magic number 50 / 75 before)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14408/files
  - new: https://git.openjdk.org/jdk/pull/14408/files/b61c1dc8..edd85c99

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

  Stats: 33 lines in 1 file changed: 23 ins; 0 del; 10 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  Sat Jul  1 10:44:07 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 1 Jul 2023 10:44:07 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: <Rn1ONADC-S82VZcH9zV28kLgzkAKclbleEQfNmgDqbM=.550e27cf-83fd-43ce-8b96-d157c8bae66f@github.com>

On Thu, 29 Jun 2023 20:58:53 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
>
> 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)

I assume the "old" comments were too detailed. I removed them at [JabRef/jdk@`23bbc0c` (#2)](https://github.com/JabRef/jdk/pull/2/commits/23bbc0ce0c8fd8a4cd689c0260c5fbcb91b20046) to have the code reviewable. I can readd some of them if that helps.

I also added a compressed description of the idea at [`edd85c9` (#14408)](https://github.com/openjdk/jdk/pull/14408/commits/edd85c996125ce0a2950b0cfb95d1e387c35d5ff)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1248764698

From duke at openjdk.org  Sat Jul  1 11:02:06 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 1 Jul 2023 11:02:06 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v8]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <o2FnzAI1smypAWK8IOxC45O8kRaA5sPAkbK6_PAhuZM=.0edbffed-a721-4adb-a92f-fcb9e7bf5934@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 pull request now contains 11 commits:

 - Merge remote-tracking branch 'upstream/master' into fix-8240567
   
   # Conflicts:
   #	src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
 - Add description
 - Fix nit (indent)
 - Add parameterization for the number of moduleDescriptors per helper method (was magic number 50 / 75 before)
 - Fix threshold
 - 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
 - ... and 1 more: https://git.openjdk.org/jdk/compare/09a49240...a6c9c985

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

Changes: https://git.openjdk.org/jdk/pull/14408/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=07
  Stats: 257 lines in 2 files changed: 244 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  Sat Jul  1 11:27:01 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 1 Jul 2023 11:27:01 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v9]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <R5ZdsjibDfWvSNREVGzR0PGKBzE_KoK0hHFXpRV3lR4=.22e104ef-95cf-44ca-99ac-dfdf7787a856@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:

  Apply suggestions from code review
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14408/files
  - new: https://git.openjdk.org/jdk/pull/14408/files/a6c9c985..47043495

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

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 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  Sat Jul  1 12:12:19 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 1 Jul 2023 12:12:19 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v10]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <dhKz2eI34pqF1yFzsTrJ2u8xFVqhU_eHdxvtb_mR26k=.0d720d75-5fbe-4256-a858-9f64db744294@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:

  No final for class parameters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14408/files
  - new: https://git.openjdk.org/jdk/pull/14408/files/47043495..b2051c3f

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

  Stats: 3 lines in 1 file changed: 2 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 liach at openjdk.org  Sat Jul  1 13:36:56 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 1 Jul 2023 13:36:56 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v8]
In-Reply-To: <SDqmZ6Z39MoWNRWnre18AMhvv8tvjfoStMy8DIay-Uc=.5a7eae71-9985-4c5e-a91a-7484a8f61477@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <SDqmZ6Z39MoWNRWnre18AMhvv8tvjfoStMy8DIay-Uc=.5a7eae71-9985-4c5e-a91a-7484a8f61477@github.com>
Message-ID: <jjzy0X8bmN1tDcuJZGsgXeYeuvzteZ546-oUhBYwuI4=.df456e03-678a-4745-a103-12a8266a412e@github.com>

On Fri, 30 Jun 2023 13:27:11 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.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 (+...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify code

src/java.base/share/classes/java/lang/Integer.java line 439:

> 437:      */
> 438:     @Stable
> 439:     static final short[] DigitPacks = new short[] {

Since the old arrays with badly-styled names are now removed, can we rename this field to `PACKED_DIGITS`, or another upper snake case name?

src/java.base/share/classes/java/lang/StringUTF16.java line 1522:

> 1520:      */
> 1521:     @Stable
> 1522:     private static final int[] DigitPacksUTF16;

Same name suggestion, `PACKED_DIGITS_UTF16` or other upper snake case name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1247887691
PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1247889820

From duke at openjdk.org  Sat Jul  1 14:12:05 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 1 Jul 2023 14:12:05 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v10]
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: <zclbOTB8a0UxeGljWj9gpBn3T--jzVN1VRI3wAFv2-Y=.6d86a5b0-4dbf-42d3-bd7a-5b8894936d68@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:

  use upper case for static final field

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14699/files
  - new: https://git.openjdk.org/jdk/pull/14699/files/632ff751..b0863555

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

  Stats: 14 lines in 3 files changed: 0 ins; 0 del; 14 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  Sat Jul  1 14:34:05 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 1 Jul 2023 14:34:05 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString [v5]
In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
Message-ID: <MCskY_ofkHC2Q5FWb8KB1A3EDAlC0qzKOWNch-WGtdA=.39bdf518-576e-4c48-9aaf-cd438d9d5ede@github.com>

> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
> 
> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.util.UUIDBench.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)
> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
> 
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
> 
> 
> ## 4. MacBookPro M1 Pro
> ``` diff
> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
> 
> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
> 
> 
> ## 5. Orange Pi 5 Plus
> 
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)

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

  Explain the rationale
  
  Co-authored-by: liach <liach at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14745/files
  - new: https://git.openjdk.org/jdk/pull/14745/files/43ec99d0..6abf3148

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

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

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

From liach at openjdk.org  Sat Jul  1 14:39:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 1 Jul 2023 14:39:10 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: <0iLrnkvOJObzNlsaBUBpqh0LQxMQpjYBMPcesebWbEs=.4c1232b5-c181-4312-b7ea-d9870d498497@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

Since I am not that familiar with References, is it possible that the Lookup of `PROXY_LOOKUPS.get(intfc)` is immediately GC'd before `Reference::get` is called?

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

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

From duke at openjdk.org  Sat Jul  1 14:42:07 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 1 Jul 2023 14:42:07 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString [v6]
In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
Message-ID: <hY2cN_-xxTyqNZz1AMJC_klQyMPX36UVsjc1c5zSK58=.91762031-9a5d-40c2-b794-423112785629@github.com>

> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
> 
> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.util.UUIDBench.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)
> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
> 
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
> 
> 
> ## 4. MacBookPro M1 Pro
> ``` diff
> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
> 
> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
> 
> 
> ## 5. Orange Pi 5 Plus
> 
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)

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

  code style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14745/files
  - new: https://git.openjdk.org/jdk/pull/14745/files/6abf3148..e5274ddc

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

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

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

From duke at openjdk.org  Sat Jul  1 14:45:03 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 1 Jul 2023 14:45:03 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v11]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <SsoUVKpeLXVbUbVp1hiWlzGx8q_4jWP5uDqNfZoxUUs=.c8f04717-cfa7-4ee7-8f81-98896fd86b27@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:

 - Try to execute java(.exe) of build runtime
 - Reuse helper array list

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14408/files
  - new: https://git.openjdk.org/jdk/pull/14408/files/b2051c3f..fe5be2f8

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

  Stats: 51 lines in 2 files changed: 25 ins; 5 del; 21 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  Sat Jul  1 14:54:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 1 Jul 2023 14:54:54 GMT
Subject: RFR: 8311207: Optimization for j.u.UUID.toString [v6]
In-Reply-To: <hY2cN_-xxTyqNZz1AMJC_klQyMPX36UVsjc1c5zSK58=.91762031-9a5d-40c2-b794-423112785629@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <hY2cN_-xxTyqNZz1AMJC_klQyMPX36UVsjc1c5zSK58=.91762031-9a5d-40c2-b794-423112785629@github.com>
Message-ID: <pQ5v92MeNslmr9lrXJcdYTIed-p2NrRfq_Qmn_YAcSg=.768182f1-a6ee-4fb7-92ab-5791c1c002ee@github.com>

On Sat, 1 Jul 2023 14:42:07 GMT, ??? <duke at openjdk.org> wrote:

>> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.util.UUIDBench.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)
>> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
>> 
>> 
>> ## 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)
>> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
>> 
>> 
>> 
>> ## 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)
>> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
>> 
>> 
>> ## 4. MacBookPro M1 Pro
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
>> 
>> 
>> ## 5. Orange Pi 5 Plus
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
>> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code style

Marked as reviewed by liach (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/14745#pullrequestreview-1508657146

From duke at openjdk.org  Sat Jul  1 18:36:10 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 1 Jul 2023 18:36:10 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v12]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <cnOjEMZxpEKseWAzJc2hd5QLMdr9IeX0VLHLJ0RvtLo=.422fbffd-e4ef-4a57-855d-80bf821b2ddf@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:

 - Fix test
 - Fix ArrayList initialization and off-by-one errors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14408/files
  - new: https://git.openjdk.org/jdk/pull/14408/files/fe5be2f8..cdc9aee7

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

  Stats: 28 lines in 2 files changed: 1 ins; 17 del; 10 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 stsypanov at openjdk.org  Sat Jul  1 19:07:55 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sat, 1 Jul 2023 19:07:55 GMT
Subject: RFR: 8311178: JMH tests don't scale well when sharing output
 buffers
In-Reply-To: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
References: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
Message-ID: <-bJ0RJ4qNzcZoXn6WmqPd7VbtBEqoi-iMmUy3D-MNJo=.13545140-598a-4691-a13c-9c559756c918@github.com>

On Sat, 1 Jul 2023 07:53:17 GMT, Swati Sharma <duke at openjdk.org> wrote:

> The below benchmark files have scaling issues due to cache contention and leads to poor scaling when run on multiple threads. The patch sets the scope from benchmark level to thread level to fix the issue:
> - org/openjdk/bench/java/io/DataOutputStreamTest.java
> - org/openjdk/bench/java/lang/ArrayCopyObject.java
> - org/openjdk/bench/java/lang/ArrayFiddle.java
> - org/openjdk/bench/java/time/format/DateTimeFormatterBench.java
> - org/openjdk/bench/jdk/incubator/vector/IndexInRangeBenchmark.java
> - org/openjdk/bench/jdk/incubator/vector/MemorySegmentVectorAccess.java
> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedBenchmark.java
> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedIOOBEBenchmark.java
> - org/openjdk/bench/vm/compiler/ArrayFill.java
> - org/openjdk/bench/vm/compiler/IndexVector.java
> 
> Also removing the static scope for variables in org/openjdk/bench/jdk/incubator/vector/VectorFPtoIntCastOperations.java for better scaling.
> 
> Please review and share your feedback.
> 
> Thanks,
> Swati

test/micro/org/openjdk/bench/java/lang/ArrayCopyObject.java line 64:

> 62: }
> 63: 
> 64: @State(Scope.Thread)

Are you sure it makes sense as in `main()` method we set `fork(1)` so there's only one thread running the benchmark?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14746#discussion_r1248932401

From duke at openjdk.org  Sat Jul  1 22:06:54 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 1 Jul 2023 22:06:54 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v12]
In-Reply-To: <cnOjEMZxpEKseWAzJc2hd5QLMdr9IeX0VLHLJ0RvtLo=.422fbffd-e4ef-4a57-855d-80bf821b2ddf@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <cnOjEMZxpEKseWAzJc2hd5QLMdr9IeX0VLHLJ0RvtLo=.422fbffd-e4ef-4a57-855d-80bf821b2ddf@github.com>
Message-ID: <YeAI4B7iKHzTIei6UcSwdHgSGOl9_XE4856K2DwsCec=.2757f065-b64c-4d8b-9d2e-f4e16c8917fc@github.com>

On Sat, 1 Jul 2023 18:36:10 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:
> 
>  - Fix test
>  - Fix ArrayList initialization and off-by-one errors

I addressed all review comments. Tests are green. I also successfully tried with our desktop app (by backporting to JDK21).

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

PR Comment: https://git.openjdk.org/jdk/pull/14408#issuecomment-1616155040

From liach at openjdk.org  Sat Jul  1 23:35:55 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 1 Jul 2023 23:35:55 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v6]
In-Reply-To: <hY2cN_-xxTyqNZz1AMJC_klQyMPX36UVsjc1c5zSK58=.91762031-9a5d-40c2-b794-423112785629@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <hY2cN_-xxTyqNZz1AMJC_klQyMPX36UVsjc1c5zSK58=.91762031-9a5d-40c2-b794-423112785629@github.com>
Message-ID: <Anj1ssF095UKbmbUdB83JMl5zJQl3a9GW74JuSidrz0=.d21e15fe-50ce-4e55-aa17-8e7974d123ac@github.com>

On Sat, 1 Jul 2023 14:42:07 GMT, ??? <duke at openjdk.org> wrote:

>> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.util.UUIDBench.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)
>> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
>> 
>> 
>> ## 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)
>> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
>> 
>> 
>> 
>> ## 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)
>> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
>> 
>> 
>> ## 4. MacBookPro M1 Pro
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
>> 
>> 
>> ## 5. Orange Pi 5 Plus
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
>> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code style

For your information, merging a patch requires a reviewer's approval. They are mostly available during weekdays only. If you wish to have a patch integrated, don't regularly change it so we don't integrate something that's WIP. You can tell everyone that your patch is in shape and won't change unless there's reviews or critical problems.

Also, can you go to Actions tab on your fork repository to enable workflows in your fork repository (green button)? Only allowing actions in settings is not sufficient.

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1616181327

From liach at openjdk.org  Sun Jul  2 01:30:15 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 2 Jul 2023 01:30:15 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v10]
In-Reply-To: <zclbOTB8a0UxeGljWj9gpBn3T--jzVN1VRI3wAFv2-Y=.6d86a5b0-4dbf-42d3-bd7a-5b8894936d68@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <zclbOTB8a0UxeGljWj9gpBn3T--jzVN1VRI3wAFv2-Y=.6d86a5b0-4dbf-42d3-bd7a-5b8894936d68@github.com>
Message-ID: <iMfUQxQZpm1PoarhV24ZStryqXq8jwgoREfTeeShGTc=.1961567d-756b-43b0-a4d3-c754e3e50203@github.com>

On Sat, 1 Jul 2023 14:12:05 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.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 (+...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use upper case for static final field

src/java.base/share/classes/java/lang/StringUTF16.java line 1538:

> 1536:                 0x300039, 0x310039, 0x320039, 0x330039, 0x340039, 0x350039, 0x360039, 0x370039, 0x380039, 0x390039
> 1537:         };
> 1538:         if (isBigEndian()) {

If the digits always have to adapt to the endianness on initialization, should we just initialize this packed digits array to endianness and remove the endianness boolean in putInt/LongUnaligned?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1249069700

From duke at openjdk.org  Sun Jul  2 01:59:13 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 2 Jul 2023 01:59:13 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v10]
In-Reply-To: <iMfUQxQZpm1PoarhV24ZStryqXq8jwgoREfTeeShGTc=.1961567d-756b-43b0-a4d3-c754e3e50203@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <zclbOTB8a0UxeGljWj9gpBn3T--jzVN1VRI3wAFv2-Y=.6d86a5b0-4dbf-42d3-bd7a-5b8894936d68@github.com>
 <iMfUQxQZpm1PoarhV24ZStryqXq8jwgoREfTeeShGTc=.1961567d-756b-43b0-a4d3-c754e3e50203@github.com>
Message-ID: <9-wcKBzQqAnlYd043nervvHU98PXvYEbzGyvdiKbZkU=.6fb6e429-9fde-45fd-8094-f0043ab6df6e@github.com>

On Sun, 2 Jul 2023 01:27:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use upper case for static final field
>
> src/java.base/share/classes/java/lang/StringUTF16.java line 1538:
> 
>> 1536:                 0x300039, 0x310039, 0x320039, 0x330039, 0x340039, 0x350039, 0x360039, 0x370039, 0x380039, 0x390039
>> 1537:         };
>> 1538:         if (isBigEndian()) {
> 
> If the digits always have to adapt to the endianness on initialization, should we just initialize this packed digits array to endianness and remove the endianness boolean in putInt/LongUnaligned?

here is the endianness of each char, and putIntUnaligned is the endianness of the entire int

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1249086284

From liach at openjdk.org  Sun Jul  2 02:05:23 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 2 Jul 2023 02:05:23 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v20]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <hf1xG7bL3h5eNL7G5HMcj39OT31KhqHRNS-QmnyuwTQ=.118cf71b-5df9-429c-b435-93dc87968515@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 44 commits:

 - Merge branch 'master' into explore/mhp-iface
 - stage
   
   Signed-off-by: liach <liach at users.noreply.github.com>
 - Review comments
 - 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
 - ... and 34 more: https://git.openjdk.org/jdk/compare/0e3d91dc...44e62271

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

Changes: https://git.openjdk.org/jdk/pull/13197/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=19
  Stats: 1375 lines in 15 files changed: 1116 ins; 174 del; 85 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  Sun Jul  2 02:08:56 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 2 Jul 2023 02:08:56 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v10]
In-Reply-To: <zclbOTB8a0UxeGljWj9gpBn3T--jzVN1VRI3wAFv2-Y=.6d86a5b0-4dbf-42d3-bd7a-5b8894936d68@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <zclbOTB8a0UxeGljWj9gpBn3T--jzVN1VRI3wAFv2-Y=.6d86a5b0-4dbf-42d3-bd7a-5b8894936d68@github.com>
Message-ID: <lmavOXZQgFbp6ZtmT38UifSqi-oXoh3Axf12SSczZMQ=.6b177b27-cc12-4232-8f05-c1415d3da083@github.com>

On Sat, 1 Jul 2023 14:12:05 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.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 (+...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use upper case for static final field

src/java.base/share/classes/java/lang/StringUTF16.java line 1540:

> 1538:         if (isBigEndian()) {
> 1539:             for (int i = 0; i < digits.length; i++) {
> 1540:                 digits[i] <<= 8;

I know this changes the char-based endian (so putInt puts the non-0 to right bytes), what I suggest is something like:

digits[i] = Integer.reverseBytes(digits[i] << 8);


And you then remove the trailing `false` (little-endian) argument to `UNSAFE.putIntUnaligned`. 

This is safe because you don't use `PACKED_DIGITS_UTF16` with bitwise operations, unlike in UUID.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1249091010

From duke at openjdk.org  Sun Jul  2 02:16:10 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 2 Jul 2023 02:16:10 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v10]
In-Reply-To: <lmavOXZQgFbp6ZtmT38UifSqi-oXoh3Axf12SSczZMQ=.6b177b27-cc12-4232-8f05-c1415d3da083@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <zclbOTB8a0UxeGljWj9gpBn3T--jzVN1VRI3wAFv2-Y=.6d86a5b0-4dbf-42d3-bd7a-5b8894936d68@github.com>
 <lmavOXZQgFbp6ZtmT38UifSqi-oXoh3Axf12SSczZMQ=.6b177b27-cc12-4232-8f05-c1415d3da083@github.com>
Message-ID: <5Z3ZbryC3JVL9YPSpNsXSr_13V1w57HUtev_2G-4-P8=.4c301efc-1f68-4956-ace5-8ff4b163fc07@github.com>

On Sun, 2 Jul 2023 02:05:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use upper case for static final field
>
> src/java.base/share/classes/java/lang/StringUTF16.java line 1540:
> 
>> 1538:         if (isBigEndian()) {
>> 1539:             for (int i = 0; i < digits.length; i++) {
>> 1540:                 digits[i] <<= 8;
> 
> I know this changes the char-based endian (so putInt puts the non-0 to right bytes), what I suggest is something like:
> 
> digits[i] = Integer.reverseBytes(digits[i] << 8);
> 
> 
> And you then remove the trailing `false` (little-endian) argument to `UNSAFE.putIntUnaligned`. 
> 
> This is safe because you don't use `PACKED_DIGITS_UTF16` with bitwise operations, unlike in UUID.

in the getChars method, it is written from the back to the front. I run benchmark and found that the performance of using little endian is better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1249100341

From duke at openjdk.org  Sun Jul  2 03:56:07 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 2 Jul 2023 03:56:07 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v11]
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: <xmtG_aBYODAsDLttkJz5PYPY2Dk7zDuC7xf9xmAJ1XI=.ccad2a27-2e72-44f1-ab65-a535c5c03a88@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:

  Adapt endian in pack
  
  Co-authored-by: liach <liach at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14699/files
  - new: https://git.openjdk.org/jdk/pull/14699/files/b0863555..ff89b6b1

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

  Stats: 18 lines in 1 file changed: 5 ins; 5 del; 8 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  Sun Jul  2 12:18:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 2 Jul 2023 12:18: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: <3n3a_zG41I1GVeW5RHAr2EASIq4cV_lrxPup1oNuRv8=.49f6ebe7-75d8-4424-9259-dbe8b96800b9@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

Please hold off on sponsoring this; after another look, I find that LocalVariable and LocalVariableType can probably implement `WritableElement`.

Per our previous discussion, `WritableElement` should probably not be exposed; it is currently only exposed as a type parameter upper bound in `<T extends WritableElement<?>> void writeList(List<T> list);`

I think we might convert the `WritableElement` to an internal interface: is it possible to declare the method as `void writeTo(BufWriterImpl)`, and the public method is yet hidden from the API because `BufWriterImpl` is not in an exported package? For the `writeList`, I would turn it into `<T> void writeList(List<T> list, BiConsumer<T, BufWriter> writer)` or simply remove it.

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

PR Comment: https://git.openjdk.org/jdk/pull/14705#issuecomment-1616627718

From dholmes at openjdk.org  Mon Jul  3 00:37:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Jul 2023 00:37:05 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: <egWyx-TC0_ifwBRZCgtOUHUelGvWv_ipqnExJL5ALK8=.b42be8b6-be09-4806-bb48-2fe6c29b2725@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 think saving one volatile read is a reasonable trade-off for the loss of readability of this code change.

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

PR Comment: https://git.openjdk.org/jdk/pull/14692#issuecomment-1617048695

From duke at openjdk.org  Mon Jul  3 03:49:01 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 3 Jul 2023 03:49:01 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v12]
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: <PNhV9fuNjZQCC0FbZvfucuaf3D3b0FYap0z_J8mSyTA=.6b3d7540-f908-4e33-ac37-cdad1899fd80@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:

  Integer/Long toString test against compact strings
  
  Co-authored-by: liach <liach at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14699/files
  - new: https://git.openjdk.org/jdk/pull/14699/files/ff89b6b1..36f361f6

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

  Stats: 30 lines in 2 files changed: 14 ins; 6 del; 10 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  Mon Jul  3 04:09:00 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 3 Jul 2023 04:09:00 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower
Message-ID: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>

# Benchmark Result


sh make/devkit/createJMHBundle.sh
bash configure --with-jmh=build/jmh/jars
make test TEST="micro:java.lang.StringUpperLower.*"



## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
* cpu : intel xeon sapphire rapids (x64)

``` diff
-Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
-StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
-StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
-StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
-StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
-StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
-StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op

+Benchmark                      Mode  Cnt   Score   Error  Units
+StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
+StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
+StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
+StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
+StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
+StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+47.69%)


## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
* cpu : amd epc genoa (x64)

``` diff
-Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
-StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
-StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
-StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
-StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
-StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
-StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op

+Benchmark                      Mode  Cnt   Score   Error  Units
+StringUpperLower.lowerToLower  avgt   15  15.273 ? 0.012  ns/op (+45.18%)
+StringUpperLower.lowerToUpper  avgt   15  46.939 ? 0.037  ns/op (-1.75%)
+StringUpperLower.mixedToLower  avgt   15  27.978 ? 0.015  ns/op (+1.86%)
+StringUpperLower.mixedToUpper  avgt   15  38.120 ? 0.047  ns/op (+1.73%)
+StringUpperLower.upperToLower  avgt   15  27.994 ? 0.053  ns/op (+2.25%)
+StringUpperLower.upperToUpper  avgt   15  17.405 ? 0.006  ns/op (+60.64%)



## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
* cpu : aliyun yitian 710 (aarch64)
``` diff
-Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
-StringUpperLower.lowerToLower  avgt   15  29.035 ? 0.142  ns/op
-StringUpperLower.lowerToUpper  avgt   15  85.791 ? 0.387  ns/op
-StringUpperLower.mixedToLower  avgt   15  40.410 ? 1.023  ns/op
-StringUpperLower.mixedToUpper  avgt   15  72.904 ? 0.682  ns/op
-StringUpperLower.upperToLower  avgt   15  40.495 ? 0.990  ns/op
-StringUpperLower.upperToUpper  avgt   15  39.665 ? 0.036  ns/op

+Benchmark                      Mode  Cnt   Score   Error  Units
+StringUpperLower.lowerToLower  avgt   15  23.222 ? 0.035  ns/op (+25.03%)
+StringUpperLower.lowerToUpper  avgt   15  84.958 ? 0.725  ns/op (+0.98%)
+StringUpperLower.mixedToLower  avgt   15  40.931 ? 0.947  ns/op (-1.27%)
+StringUpperLower.mixedToUpper  avgt   15  71.845 ? 1.128  ns/op (+1.47%)
+StringUpperLower.upperToLower  avgt   15  40.967 ? 1.430  ns/op (-1.52%)
+StringUpperLower.upperToUpper  avgt   15  17.545 ? 0.159  ns/op (+126.07%)


## 4. MacBookPro M1 Pro
``` diff
-Benchmark                      Mode  Cnt   Score    Error  Units (baseline)
-StringUpperLower.lowerToLower  avgt   15  22.454 ?  0.160  ns/op
-StringUpperLower.lowerToUpper  avgt   15  60.394 ?  8.811  ns/op
-StringUpperLower.mixedToLower  avgt   15  57.825 ? 10.782  ns/op
-StringUpperLower.mixedToUpper  avgt   15  57.414 ?  7.899  ns/op
-StringUpperLower.upperToLower  avgt   15  55.500 ? 10.547  ns/op
-StringUpperLower.upperToUpper  avgt   15  24.637 ?  0.146  ns/op

+Benchmark                      Mode  Cnt   Score   Error  Units
+StringUpperLower.lowerToLower  avgt   15  15.854 ? 0.032  ns/op (+41.62%)
+StringUpperLower.lowerToUpper  avgt   15  48.417 ? 0.305  ns/op (+24.73%)
+StringUpperLower.mixedToLower  avgt   15  36.338 ? 0.346  ns/op (+59.13%)
+StringUpperLower.mixedToUpper  avgt   15  42.371 ? 0.376  ns/op (+35.50%)
+StringUpperLower.upperToLower  avgt   15  36.342 ? 0.324  ns/op (+52.71%)
+StringUpperLower.upperToUpper  avgt   15  11.149 ? 0.018  ns/op (+120.97%)


## 5. [Orange Pi 5 Plus](http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-plus.html)
CPU : Rockchip RK3588 (aarch64)

``` diff
-Benchmark                      Mode  Cnt    Score   Error  Units (baseline)
-StringUpperLower.lowerToLower  avgt   15   64.597 ? 0.211  ns/op
-StringUpperLower.lowerToUpper  avgt   15  146.723 ? 1.420  ns/op
-StringUpperLower.mixedToLower  avgt   15   78.629 ? 0.589  ns/op
-StringUpperLower.mixedToUpper  avgt   15  124.889 ? 1.358  ns/op
-StringUpperLower.upperToLower  avgt   15   78.981 ? 1.318  ns/op
-StringUpperLower.upperToUpper  avgt   15   61.466 ? 0.150  ns/op

+Benchmark                      Mode  Cnt    Score   Error  Units
+StringUpperLower.lowerToLower  avgt   15   41.060 ? 0.254  ns/op (+57.32%)
+StringUpperLower.lowerToUpper  avgt   15  136.750 ? 4.522  ns/op (+7.29%)
+StringUpperLower.mixedToLower  avgt   15   77.984 ? 0.953  ns/op (+8.27%)
+StringUpperLower.mixedToUpper  avgt   15  121.449 ? 1.466  ns/op (+2.83%)
+StringUpperLower.upperToLower  avgt   15   77.787 ? 0.722  ns/op (+1.53%)
+StringUpperLower.upperToUpper  avgt   15   30.798 ? 0.145  ns/op (+99.57%)

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

Commit messages:
 - optimization for StringLatin1 UpperLower

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

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

From duke at openjdk.org  Mon Jul  3 05:25:53 2023
From: duke at openjdk.org (Jacob G.)
Date: Mon, 3 Jul 2023 05:25:53 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower
In-Reply-To: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
References: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
Message-ID: <5WflowlPWB802ShoDHo9av95-uWFqA8o0l9iSlBwZ7s=.90a2cad5-104c-4f88-a89a-a744ef7d1979@github.com>

On Mon, 3 Jul 2023 04:02:44 GMT, ??? <duke at openjdk.org> wrote:

> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.StringUpperLower.*"
> 
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units
> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+47.69%)
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units
> +StringUpperLower.lowerToLower  avgt   15  15.273 ? 0.012  ns/op (+45.18%)
> +StringUpperLower.lowerToUpper  avgt   15  46.939 ? 0.037  ns/op (-1.75%)
> +StringUpperLower.mixedToLower  avgt   15  27.978 ? 0.015  ns/op (+1.86%)
> +StringUpperLower.mixedToUpper  avgt   15  38.120 ? 0.047  ns/op (+1.73%)
> +StringUpperLower.upperToLower  avgt   15  27.994 ? 0.053  ns/op (+2.25%)
> +StringUpperLower.upperToUpper  avgt   15  17.405 ? 0.006  ns/op (+60.64%)
> 
> 
> 
> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
> * cpu : aliyun yitian 710 (aarch64)
> ``` dif...

src/java.base/share/classes/java/lang/StringLatin1.java line 498:

> 496:         for (first = 0 ; first < len; first++ ) {
> 497:             int cp = value[first] & 0xff;
> 498:             if (cp >= 'a' && (cp <= 'z' || cp == 181 || (cp >= 223 && cp != 247))) {

The following would be consistent with your other changes:

if (CharacterDataLatin1.instance.isLowerCase(value[first] & 0xff)) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14751#discussion_r1250250652

From duke at openjdk.org  Mon Jul  3 05:33:05 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 3 Jul 2023 05:33:05 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower
In-Reply-To: <5WflowlPWB802ShoDHo9av95-uWFqA8o0l9iSlBwZ7s=.90a2cad5-104c-4f88-a89a-a744ef7d1979@github.com>
References: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
 <5WflowlPWB802ShoDHo9av95-uWFqA8o0l9iSlBwZ7s=.90a2cad5-104c-4f88-a89a-a744ef7d1979@github.com>
Message-ID: <vdVozW_IRQeja5rwTUX833Zap3pv-l_ZirAkOW8z2l8=.8ab1a807-7e09-438b-a205-1312fc3366f9@github.com>

On Mon, 3 Jul 2023 05:16:35 GMT, Jacob G. <duke at openjdk.org> wrote:

>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>> 
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
>> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units
>> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
>> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
>> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
>> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
>> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
>> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+47.69%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
>> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units
>> +StringUpperLower.lowerToLower  avgt   15  15.273 ? 0.012  ns/op (+45.18%)
>> +StringUpperLower.lowerToUpper  avgt   15  46.939 ? 0.037  ns/op (-1.75%)
>> +StringUpperLower.mixedToLower  avgt   15  27.978 ? 0.015  ns/op (+1.86%)
>> +StringUpperLower.mixedToUpper  avgt   15  38.120 ? 0.047  ns/op (+1.73%)
>> +StringUpperLower.upperToLower  avgt   15  27.994 ? 0.053  ns/op (+2.25%)
>> +StringUpperLower.upperToUpper  avgt   15  17.405 ? 0.006  ns/op (+60.64%)
>> 
>> 
>> 
>> ## 3. [aliyun_ecs_c8y.x...
>
> src/java.base/share/classes/java/lang/StringLatin1.java line 498:
> 
>> 496:         for (first = 0 ; first < len; first++ ) {
>> 497:             int cp = value[first] & 0xff;
>> 498:             if (cp >= 'a' && (cp <= 'z' || cp == 181 || (cp >= 223 && cp != 247))) {
> 
> The following would be consistent with your other changes:
> 
> if (CharacterDataLatin1.instance.isLowerCase(value[first] & 0xff)) {

When the value of cp is 170 or 186, the result of using isLowerCase is not expected, and it also cause build fail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14751#discussion_r1250261151

From mbaesken at openjdk.org  Mon Jul  3 07:02:05 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 3 Jul 2023 07:02:05 GMT
Subject: [jdk21] Integrated: 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: <Ok9gLzH1nzw5hhEcbNO3yh63Rs6AQ1f3esirHJSFPeQ=.cd9fb0fe-a745-459f-99f1-9b4502ac18b8@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

This pull request has now been integrated.

Changeset: 6f3f4aa2
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/6f3f4aa2936f5cbe120da1e29e924bc99cfd27d1
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: cjplummer
Backport-of: 39c104df44f17c1d65e35becd4272f73e2c6610c

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

PR: https://git.openjdk.org/jdk21/pull/87

From thartmann at openjdk.org  Mon Jul  3 07:21:12 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 3 Jul 2023 07:21:12 GMT
Subject: [jdk21] RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit
Message-ID: <h_RBEiO0NEZqa59LcF6XtZ4MWxYj5ZNj6tjcoA6SN2I=.679f0a19-e73b-48cf-bfb7-6a9924d585be@github.com>

Backport of [JDK-8310829](https://bugs.openjdk.java.net/browse/JDK-8310829). Applies cleanly.

Thanks,
Tobias

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

Commit messages:
 - 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in ExceptionTranslation::doit

Changes: https://git.openjdk.org/jdk21/pull/91/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=91&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310829
  Stats: 176 lines in 6 files changed: 123 ins; 21 del; 32 mod
  Patch: https://git.openjdk.org/jdk21/pull/91.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/91/head:pull/91

PR: https://git.openjdk.org/jdk21/pull/91

From liach at openjdk.org  Mon Jul  3 07:32:57 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 3 Jul 2023 07:32:57 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower
In-Reply-To: <vdVozW_IRQeja5rwTUX833Zap3pv-l_ZirAkOW8z2l8=.8ab1a807-7e09-438b-a205-1312fc3366f9@github.com>
References: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
 <5WflowlPWB802ShoDHo9av95-uWFqA8o0l9iSlBwZ7s=.90a2cad5-104c-4f88-a89a-a744ef7d1979@github.com>
 <vdVozW_IRQeja5rwTUX833Zap3pv-l_ZirAkOW8z2l8=.8ab1a807-7e09-438b-a205-1312fc3366f9@github.com>
Message-ID: <-CaA9mrdK1YOV4t9qHyU3rYHCj8PUUtTLTgjWmrK3PY=.7a891799-49f0-4577-b456-8a71dda59711@github.com>

On Mon, 3 Jul 2023 05:29:57 GMT, ??? <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringLatin1.java line 498:
>> 
>>> 496:         for (first = 0 ; first < len; first++ ) {
>>> 497:             int cp = value[first] & 0xff;
>>> 498:             if (cp >= 'a' && (cp <= 'z' || cp == 181 || (cp >= 223 && cp != 247))) {
>> 
>> The following would be consistent with your other changes:
>> 
>> if (CharacterDataLatin1.instance.isLowerCase(value[first] & 0xff)) {
>
> When the value of cp is 170 or 186, the result of using isLowerCase is not expected, and it also cause build fail.

Should we define a new method in `CharacterDataLain1` for such a dedicated check?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14751#discussion_r1250392626

From duke at openjdk.org  Mon Jul  3 08:27:54 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 3 Jul 2023 08:27:54 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower
In-Reply-To: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
References: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
Message-ID: <-psWR7VMUly2rMEGG_KLM2MHLpR33nbjMMCVqCGPSOY=.7bf442b3-2b8e-4365-9aee-8598e7198b73@github.com>

On Mon, 3 Jul 2023 04:02:44 GMT, ??? <duke at openjdk.org> wrote:

> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.StringUpperLower.*"
> 
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units
> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+47.69%)
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units
> +StringUpperLower.lowerToLower  avgt   15  15.273 ? 0.012  ns/op (+45.18%)
> +StringUpperLower.lowerToUpper  avgt   15  46.939 ? 0.037  ns/op (-1.75%)
> +StringUpperLower.mixedToLower  avgt   15  27.978 ? 0.015  ns/op (+1.86%)
> +StringUpperLower.mixedToUpper  avgt   15  38.120 ? 0.047  ns/op (+1.73%)
> +StringUpperLower.upperToLower  avgt   15  27.994 ? 0.053  ns/op (+2.25%)
> +StringUpperLower.upperToUpper  avgt   15  17.405 ? 0.006  ns/op (+60.64%)
> 
> 
> 
> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
> * cpu : aliyun yitian 710 (aarch64)
> ``` dif...

Changes requested by Glavo at github.com (no known OpenJDK username).

src/java.base/share/classes/java/lang/StringLatin1.java line 442:

> 440:             if (!canEncode(cp)) {                      // not a latin1 character
> 441:                 return toLowerCaseEx(str, value, first, locale, false);
> 442:             }

Suggestion:



I think this branch is unnecessary. All lowercase forms of Latin-1 characters can be encoded using Latin-1.

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

PR Review: https://git.openjdk.org/jdk/pull/14751#pullrequestreview-1510650205
PR Review Comment: https://git.openjdk.org/jdk/pull/14751#discussion_r1250472121

From stsypanov at openjdk.org  Mon Jul  3 08:36:04 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 3 Jul 2023 08:36:04 GMT
Subject: Withdrawn: 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: <rMqOJxL7zS_BAT-CHDTsjuZnihcHx7ibbd2abQgTeVI=.f97ebf9d-f732-41b8-a89c-bf4a79363e7c@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.

This pull request has been closed without being integrated.

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

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

From chagedorn at openjdk.org  Mon Jul  3 09:13:08 2023
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 3 Jul 2023 09:13:08 GMT
Subject: [jdk21] RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit
In-Reply-To: <h_RBEiO0NEZqa59LcF6XtZ4MWxYj5ZNj6tjcoA6SN2I=.679f0a19-e73b-48cf-bfb7-6a9924d585be@github.com>
References: <h_RBEiO0NEZqa59LcF6XtZ4MWxYj5ZNj6tjcoA6SN2I=.679f0a19-e73b-48cf-bfb7-6a9924d585be@github.com>
Message-ID: <OugfUXApxiI-Di_fll3S7GasoxVnb3RyRSzdWvcOb2k=.5553007c-f635-4c35-a597-675d753f278c@github.com>

On Mon, 3 Jul 2023 07:13:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8310829](https://bugs.openjdk.java.net/browse/JDK-8310829). Applies cleanly.
> 
> Thanks,
> Tobias

Looks good.

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/91#pullrequestreview-1510737726

From duke at openjdk.org  Mon Jul  3 09:24:54 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 3 Jul 2023 09:24:54 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower
In-Reply-To: <84X-Sn0sAnHgI_bHb3DKBjPhH8b7RL6-9LQ1CukqfFI=.d9262ef9-3db6-4f8a-9e72-0b11d8d31735@github.com>
References: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
 <-psWR7VMUly2rMEGG_KLM2MHLpR33nbjMMCVqCGPSOY=.7bf442b3-2b8e-4365-9aee-8598e7198b73@github.com>
 <84X-Sn0sAnHgI_bHb3DKBjPhH8b7RL6-9LQ1CukqfFI=.d9262ef9-3db6-4f8a-9e72-0b11d8d31735@github.com>
Message-ID: <CbjDLVUveTh9fh3P9R1ZhTQvHijslR7GhTTAUprmcho=.1d12cce4-fa93-4c39-828e-881dca161721@github.com>

On Mon, 3 Jul 2023 09:17:29 GMT, ??? <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringLatin1.java line 442:
>> 
>>> 440:             if (!canEncode(cp)) {                      // not a latin1 character
>>> 441:                 return toLowerCaseEx(str, value, first, locale, false);
>>> 442:             }
>> 
>> Suggestion:
>> 
>> 
>> 
>> I think this branch is unnecessary. All lowercase forms of Latin-1 characters can be encoded using Latin-1.
>
> String str0 = new String(new byte[]{-75}, StandardCharsets.ISO_8859_1);
> String str1 = str0.toUpperCase();
> 
> str0.coder is LATIN1
> str1.coder is UTF16

> ```java
> String str0 = new String(new byte[]{-75}, StandardCharsets.ISO_8859_1);
> String str1 = str0.toUpperCase();
> ```
> 
> str0.coder is LATIN1 str1.coder is UTF16

This happens only with `toUpperCase`, not with `toLowerCase`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14751#discussion_r1250545802

From duke at openjdk.org  Mon Jul  3 09:24:55 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 3 Jul 2023 09:24:55 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower
In-Reply-To: <CbjDLVUveTh9fh3P9R1ZhTQvHijslR7GhTTAUprmcho=.1d12cce4-fa93-4c39-828e-881dca161721@github.com>
References: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
 <-psWR7VMUly2rMEGG_KLM2MHLpR33nbjMMCVqCGPSOY=.7bf442b3-2b8e-4365-9aee-8598e7198b73@github.com>
 <84X-Sn0sAnHgI_bHb3DKBjPhH8b7RL6-9LQ1CukqfFI=.d9262ef9-3db6-4f8a-9e72-0b11d8d31735@github.com>
 <CbjDLVUveTh9fh3P9R1ZhTQvHijslR7GhTTAUprmcho=.1d12cce4-fa93-4c39-828e-881dca161721@github.com>
Message-ID: <YzvMi1CuifLD6THOCM6d5IpUzzfgnW7Rzdv2TT_lr_s=.a6965e78-d071-4bfb-992a-81563c3084bb@github.com>

On Mon, 3 Jul 2023 09:20:04 GMT, Glavo <duke at openjdk.org> wrote:

>> String str0 = new String(new byte[]{-75}, StandardCharsets.ISO_8859_1);
>> String str1 = str0.toUpperCase();
>> 
>> str0.coder is LATIN1
>> str1.coder is UTF16
>
>> ```java
>> String str0 = new String(new byte[]{-75}, StandardCharsets.ISO_8859_1);
>> String str1 = str0.toUpperCase();
>> ```
>> 
>> str0.coder is LATIN1 str1.coder is UTF16
> 
> This happens only with `toUpperCase`, not with `toLowerCase`.

another example:


String str0 = new String(new byte[]{-1}, StandardCharsets.ISO_8859_1);
String str1 = str0.toUpperCase();


str0.coder is LATIN1
str1.coder is UTF16

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14751#discussion_r1250548264

From duke at openjdk.org  Mon Jul  3 09:24:54 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 3 Jul 2023 09:24:54 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower
In-Reply-To: <-psWR7VMUly2rMEGG_KLM2MHLpR33nbjMMCVqCGPSOY=.7bf442b3-2b8e-4365-9aee-8598e7198b73@github.com>
References: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
 <-psWR7VMUly2rMEGG_KLM2MHLpR33nbjMMCVqCGPSOY=.7bf442b3-2b8e-4365-9aee-8598e7198b73@github.com>
Message-ID: <84X-Sn0sAnHgI_bHb3DKBjPhH8b7RL6-9LQ1CukqfFI=.d9262ef9-3db6-4f8a-9e72-0b11d8d31735@github.com>

On Mon, 3 Jul 2023 08:25:06 GMT, Glavo <duke at openjdk.org> wrote:

>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>> 
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
>> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units
>> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
>> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
>> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
>> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
>> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
>> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+47.69%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
>> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units
>> +StringUpperLower.lowerToLower  avgt   15  15.273 ? 0.012  ns/op (+45.18%)
>> +StringUpperLower.lowerToUpper  avgt   15  46.939 ? 0.037  ns/op (-1.75%)
>> +StringUpperLower.mixedToLower  avgt   15  27.978 ? 0.015  ns/op (+1.86%)
>> +StringUpperLower.mixedToUpper  avgt   15  38.120 ? 0.047  ns/op (+1.73%)
>> +StringUpperLower.upperToLower  avgt   15  27.994 ? 0.053  ns/op (+2.25%)
>> +StringUpperLower.upperToUpper  avgt   15  17.405 ? 0.006  ns/op (+60.64%)
>> 
>> 
>> 
>> ## 3. [aliyun_ecs_c8y.x...
>
> src/java.base/share/classes/java/lang/StringLatin1.java line 442:
> 
>> 440:             if (!canEncode(cp)) {                      // not a latin1 character
>> 441:                 return toLowerCaseEx(str, value, first, locale, false);
>> 442:             }
> 
> Suggestion:
> 
> 
> 
> I think this branch is unnecessary. All lowercase forms of Latin-1 characters can be encoded using Latin-1.

String str0 = new String(new byte[]{-75}, StandardCharsets.ISO_8859_1);
String str1 = str0.toUpperCase();

str0.coder is LATIN1
str1.coder is UTF16

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14751#discussion_r1250542217

From duke at openjdk.org  Mon Jul  3 09:27:53 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 3 Jul 2023 09:27:53 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower
In-Reply-To: <YzvMi1CuifLD6THOCM6d5IpUzzfgnW7Rzdv2TT_lr_s=.a6965e78-d071-4bfb-992a-81563c3084bb@github.com>
References: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
 <-psWR7VMUly2rMEGG_KLM2MHLpR33nbjMMCVqCGPSOY=.7bf442b3-2b8e-4365-9aee-8598e7198b73@github.com>
 <84X-Sn0sAnHgI_bHb3DKBjPhH8b7RL6-9LQ1CukqfFI=.d9262ef9-3db6-4f8a-9e72-0b11d8d31735@github.com>
 <CbjDLVUveTh9fh3P9R1ZhTQvHijslR7GhTTAUprmcho=.1d12cce4-fa93-4c39-828e-881dca161721@github.com>
 <YzvMi1CuifLD6THOCM6d5IpUzzfgnW7Rzdv2TT_lr_s=.a6965e78-d071-4bfb-992a-81563c3084bb@github.com>
Message-ID: <KHROQT-6HwG3n_Qw91zrFr7sqV4Sb7iB_ZxsR6gXLHQ=.209daa40-6973-460d-9bd4-7c83ab3a7914@github.com>

On Mon, 3 Jul 2023 09:21:54 GMT, ??? <duke at openjdk.org> wrote:

> another example:
> 
> ```
> String str0 = new String(new byte[]{-1}, StandardCharsets.ISO_8859_1);
> String str1 = str0.toUpperCase();
> ```
> 
> str0.coder is LATIN1 str1.coder is UTF16

I know this, these cases only happen with `toUpperCase`, not with `toLowerCase`, we can easily verify this:


jshell> for (int i = 0; i < 256; i++) if (Character.toUpperCase(i) > 0xFF) System.out.println(i);
181
255

jshell> for (int i = 0; i < 256; i++) if (Character.toLowerCase(i) > 0xFF) System.out.println(i);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14751#discussion_r1250553279

From duke at openjdk.org  Mon Jul  3 09:53:16 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 3 Jul 2023 09:53:16 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v2]
In-Reply-To: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
References: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
Message-ID: <oXmV3zI2GJ72ICiGJ6HnZOng-HBhT9JKH3_C1CHPYAA=.6cf80bb2-e0f4-4d7f-b796-135ee537abbe@github.com>

> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.StringUpperLower.*"
> 
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units
> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+47.69%)
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units
> +StringUpperLower.lowerToLower  avgt   15  15.273 ? 0.012  ns/op (+45.18%)
> +StringUpperLower.lowerToUpper  avgt   15  46.939 ? 0.037  ns/op (-1.75%)
> +StringUpperLower.mixedToLower  avgt   15  27.978 ? 0.015  ns/op (+1.86%)
> +StringUpperLower.mixedToUpper  avgt   15  38.120 ? 0.047  ns/op (+1.73%)
> +StringUpperLower.upperToLower  avgt   15  27.994 ? 0.053  ns/op (+2.25%)
> +StringUpperLower.upperToUpper  avgt   15  17.405 ? 0.006  ns/op (+60.64%)
> 
> 
> 
> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
> * cpu : aliyun yitian 710 (aarch64)
> ``` dif...

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

  remove unnecessary code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14751/files
  - new: https://git.openjdk.org/jdk/pull/14751/files/6179ca3d..47c4bb03

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

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

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

From thartmann at openjdk.org  Mon Jul  3 10:40:59 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 3 Jul 2023 10:40:59 GMT
Subject: [jdk21] RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit
In-Reply-To: <h_RBEiO0NEZqa59LcF6XtZ4MWxYj5ZNj6tjcoA6SN2I=.679f0a19-e73b-48cf-bfb7-6a9924d585be@github.com>
References: <h_RBEiO0NEZqa59LcF6XtZ4MWxYj5ZNj6tjcoA6SN2I=.679f0a19-e73b-48cf-bfb7-6a9924d585be@github.com>
Message-ID: <53DPSGZSvBq_pXpb-yMa-jcIA16QJQPhFa_4CiCop5E=.d489538a-7236-4073-8d84-8dac91f9f89a@github.com>

On Mon, 3 Jul 2023 07:13:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8310829](https://bugs.openjdk.java.net/browse/JDK-8310829). Applies cleanly.
> 
> Thanks,
> Tobias

Thanks, Christian!

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

PR Comment: https://git.openjdk.org/jdk21/pull/91#issuecomment-1617875850

From thartmann at openjdk.org  Mon Jul  3 10:41:00 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 3 Jul 2023 10:41:00 GMT
Subject: [jdk21] Integrated: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed
 in ExceptionTranslation::doit
In-Reply-To: <h_RBEiO0NEZqa59LcF6XtZ4MWxYj5ZNj6tjcoA6SN2I=.679f0a19-e73b-48cf-bfb7-6a9924d585be@github.com>
References: <h_RBEiO0NEZqa59LcF6XtZ4MWxYj5ZNj6tjcoA6SN2I=.679f0a19-e73b-48cf-bfb7-6a9924d585be@github.com>
Message-ID: <S6c-XofXJ2qi8WuSrZ6GSEyZ7c8IR3ur2EQHMiE00EA=.18af5949-4030-4f2a-88cf-02945ee35e7e@github.com>

On Mon, 3 Jul 2023 07:13:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8310829](https://bugs.openjdk.java.net/browse/JDK-8310829). Applies cleanly.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 6de4e8f6
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/6de4e8f601852f9f4b96974dd210ccaf1f655145
Stats:     176 lines in 6 files changed: 123 ins; 21 del; 32 mod

8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in ExceptionTranslation::doit

Reviewed-by: chagedorn
Backport-of: f6bdccb45caca0f69918a773a9ad9b2ad91b702f

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

PR: https://git.openjdk.org/jdk21/pull/91

From prappo at openjdk.org  Mon Jul  3 11:20:10 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 3 Jul 2023 11:20:10 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in java.text
Message-ID: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>

Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in the java.text area.

* Some changes to `equals` and `hashCode` are refactoring rather than modernization. Such changes can be as trivial as rearranging, adding, or commenting checks.

* java.text area contains more classes whose `equals` and `hashCode` could be simplified; for example: sun.text.CompactByteArray or java.text.DigitList. However, I found no evidence of `equals` and `hashCode` in those classes being used in source or tests. Since writing new tests in this case seems unreasonable, I **excluded** those classes from this PR.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14752/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14752&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311188
  Stats: 121 lines in 15 files changed: 31 ins; 52 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/14752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14752/head:pull/14752

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

From lancea at openjdk.org  Mon Jul  3 12:07:54 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 3 Jul 2023 12:07:54 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <_hJmUpFIm_Cer-PPkqMT1L76HdOc2xpBw-49ysn5y-U=.025de91b-c972-4177-8e23-feaf6099caaf@github.com>

On Mon, 3 Jul 2023 11:12:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in the java.text area.
> 
> * Some changes to `equals` and `hashCode` are refactoring rather than modernization. Such changes can be as trivial as rearranging, adding, or commenting checks.
> 
> * java.text area contains more classes whose `equals` and `hashCode` could be simplified; for example: sun.text.CompactByteArray or java.text.DigitList. However, I found no evidence of `equals` and `hashCode` in those classes being used in source or tests. Since writing new tests in this case seems unreasonable, I **excluded** those classes from this PR.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14752#pullrequestreview-1511056787

From mullan at openjdk.org  Mon Jul  3 16:06:58 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 3 Jul 2023 16:06:58 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: <Qk-_6a13mZG-L7BLwVBarU4_qWjx1ypfrbnwRI5uic8=.5ded9a75-a7e8-461a-9a58-f7d7b51bd351@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.

The changes in the security classes look fine to me.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14718#pullrequestreview-1511468933

From mchung at openjdk.org  Mon Jul  3 16:08:04 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Jul 2023 16:08:04 GMT
Subject: Integrated: 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: <QKjDEoFQgLsTA-T0M7SqrWF5CDaQRITxIEYC34Igi-c=.9a6ba35d-ed5b-4d70-8d40-ebc13dea4f54@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.

This pull request has now been integrated.

Changeset: b9198f99
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9198f993173b0fbdc7ff1400e2205d3969370da
Stats:     16 lines in 1 file changed: 9 ins; 0 del; 7 mod

8254566: Clarify the spec of ClassLoader::getClassLoadingLock for non-parallel capable loader

Reviewed-by: dholmes, darcy

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

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

From mchung at openjdk.org  Mon Jul  3 16:23:57 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Jul 2023 16:23:57 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v6]
In-Reply-To: <Rn1ONADC-S82VZcH9zV28kLgzkAKclbleEQfNmgDqbM=.550e27cf-83fd-43ce-8b96-d157c8bae66f@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>
 <Rn1ONADC-S82VZcH9zV28kLgzkAKclbleEQfNmgDqbM=.550e27cf-83fd-43ce-8b96-d157c8bae66f@github.com>
Message-ID: <YS-3VJoDNPGHU_l_bAdBzj3HC4oyNjo5al8_kBfKOoY=.dc05d05d-018d-48d2-9b2a-627d19012add@github.com>

On Sat, 1 Jul 2023 10:38:05 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> 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)
>
> I assume the "old" comments were too detailed. I removed them at [JabRef/jdk@`23bbc0c` (#2)](https://github.com/JabRef/jdk/pull/2/commits/23bbc0ce0c8fd8a4cd689c0260c5fbcb91b20046) to have the code reviewable. I can readd some of them if that helps.
> 
> I also added a compressed description of the idea at [`edd85c9` (#14408)](https://github.com/openjdk/jdk/pull/14408/commits/edd85c996125ce0a2950b0cfb95d1e387c35d5ff). **Update** here, in the PR one simply needs to scroll up and sees the new comment.

Have you considered passing the same ArrayList for saving and restoring local variables?  Currently each method creates one new array list and save the local variables from `firstVariableForDedup` to `nextLocalVar`, but the local variables from `firstVariableForDedup`  are already added to the array list created by the previous method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251088902

From mchung at openjdk.org  Mon Jul  3 16:32:04 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Jul 2023 16:32:04 GMT
Subject: [jdk21] RFR: 8254566: Clarify the spec of
 ClassLoader::getClassLoadingLock for non-parallel capable loader
Message-ID: <-y9RnzrpTwLkX2jtPtnAQe2ix0Nu3Z_b3ScpbybesxU=.5b3d81b3-87ea-4680-8e16-6822d8936cd3@github.com>

Backport of commit [b9198f99](https://github.com/openjdk/jdk/commit/b9198f993173b0fbdc7ff1400e2205d3969370da).

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

Commit messages:
 - Backport b9198f993173b0fbdc7ff1400e2205d3969370da

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

PR: https://git.openjdk.org/jdk21/pull/93

From mchung at openjdk.org  Mon Jul  3 16:49:55 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Jul 2023 16:49:55 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v6]
In-Reply-To: <YS-3VJoDNPGHU_l_bAdBzj3HC4oyNjo5al8_kBfKOoY=.dc05d05d-018d-48d2-9b2a-627d19012add@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>
 <Rn1ONADC-S82VZcH9zV28kLgzkAKclbleEQfNmgDqbM=.550e27cf-83fd-43ce-8b96-d157c8bae66f@github.com>
 <YS-3VJoDNPGHU_l_bAdBzj3HC4oyNjo5al8_kBfKOoY=.dc05d05d-018d-48d2-9b2a-627d19012add@github.com>
Message-ID: <GKUZKgr107zT6rmE-CFOkiBGtuikaFfNlrheOPWdn1w=.f4cc8fc3-3237-49e9-b6ce-b4a68c12f3a2@github.com>

On Mon, 3 Jul 2023 16:21:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I assume the "old" comments were too detailed. I removed them at [JabRef/jdk@`23bbc0c` (#2)](https://github.com/JabRef/jdk/pull/2/commits/23bbc0ce0c8fd8a4cd689c0260c5fbcb91b20046) to have the code reviewable. I can readd some of them if that helps.
>> 
>> I also added a compressed description of the idea at [`edd85c9` (#14408)](https://github.com/openjdk/jdk/pull/14408/commits/edd85c996125ce0a2950b0cfb95d1e387c35d5ff). **Update** here, in the PR one simply needs to scroll up and sees the new comment.
>
> Have you considered passing the same ArrayList for saving and restoring local variables?  Currently each method creates one new array list and save the local variables from `firstVariableForDedup` to `nextLocalVar`, but the local variables from `firstVariableForDedup`  are already added to the array list created by the previous method.

Ah, I see your commit.  I will check it out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251109605

From iris at openjdk.org  Mon Jul  3 16:50:52 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 3 Jul 2023 16:50:52 GMT
Subject: [jdk21] RFR: 8254566: Clarify the spec of
 ClassLoader::getClassLoadingLock for non-parallel capable loader
In-Reply-To: <-y9RnzrpTwLkX2jtPtnAQe2ix0Nu3Z_b3ScpbybesxU=.5b3d81b3-87ea-4680-8e16-6822d8936cd3@github.com>
References: <-y9RnzrpTwLkX2jtPtnAQe2ix0Nu3Z_b3ScpbybesxU=.5b3d81b3-87ea-4680-8e16-6822d8936cd3@github.com>
Message-ID: <bIALEM1cadHA2iaLlQ_WI5lzaBq4PpckOYu1B-lVFys=.e969b81c-20df-4dfd-964f-c8dce5af5173@github.com>

On Mon, 3 Jul 2023 16:23:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Backport of commit [b9198f99](https://github.com/openjdk/jdk/commit/b9198f993173b0fbdc7ff1400e2205d3969370da).

Looks identical to change in 22, as expected.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/93#pullrequestreview-1511522916

From mchung at openjdk.org  Mon Jul  3 17:11:59 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Jul 2023 17:11:59 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: <oXuqPp6460DVzFwOiDPge4j4z-KhGxNJMPKrVLtyhiU=.68349d72-32e9-4740-9739-5204c2b40cda@github.com>

On Thu, 29 Jun 2023 20:43:59 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
>
> 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.

What I meant here is to change the `configure` method to allow the plugin to take an argument for example

    --system-modules batch-size=100


This argument is optional.   If not specified, the default value is 75.    This way you can tune the batch-size if we hit the method size limit for whatever reason.   And the test can also verify with different size if appropriate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251128354

From mchung at openjdk.org  Mon Jul  3 17:12:00 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Jul 2023 17:12:00 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v6]
In-Reply-To: <oXuqPp6460DVzFwOiDPge4j4z-KhGxNJMPKrVLtyhiU=.68349d72-32e9-4740-9739-5204c2b40cda@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>
 <oXuqPp6460DVzFwOiDPge4j4z-KhGxNJMPKrVLtyhiU=.68349d72-32e9-4740-9739-5204c2b40cda@github.com>
Message-ID: <Rpfc5C0quW1vIjD2R5BTRznfAipUt86zVqd2AgrzUuk=.31b81b2b-f210-4415-8115-7c7bec116d1b@github.com>

On Mon, 3 Jul 2023 17:07:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 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.
>
> What I meant here is to change the `configure` method to allow the plugin to take an argument for example
> 
>     --system-modules batch-size=100
> 
> 
> This argument is optional.   If not specified, the default value is 75.    This way you can tune the batch-size if we hit the method size limit for whatever reason.   And the test can also verify with different size if appropriate.

`plugins.properties` needs to be updated to show the option added for this plugin.   

BTW, the current argument described in the usage is out-dated which needs update.

system-modules.argument=retainModuleTarget

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251130100

From ascarpino at openjdk.org  Mon Jul  3 17:51:10 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 3 Jul 2023 17:51:10 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base [v3]
In-Reply-To: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
Message-ID: <RnvLcqdxUlImVAZoqsqtJCI24ZGtMulCjeJ039uOSeA=.8dbbb2e0-247b-4fce-a0f2-97159b7fc157@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:

  return non volatile variable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14457/files
  - new: https://git.openjdk.org/jdk/pull/14457/files/32b4cee1..cf8e954d

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 naoto at openjdk.org  Mon Jul  3 18:12:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Jul 2023 18:12:54 GMT
Subject: RFR: 8310818: Refactor more Locale tests to use JUnit
In-Reply-To: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
References: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
Message-ID: <R4UAROrEuHNmhYEp7w_S72ktN29v_K9P_SG106IliUI=.b212696c-eeba-44ed-a1a7-487d45c2a4a1@github.com>

On Fri, 30 Jun 2023 07:52:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> 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

test/jdk/java/util/Locale/Bug8025703.java line 48:

> 46:      * language priority list by matching the correct tag(s). This test
> 47:      * was originally created to verify an older update to the LSR data file,
> 48:      * and the test may be deprecated by LanguageSubtagRegistryTest.java

If that's the case, can we update `LanguageSubtagRegistryTest.java` to cover these older updates and remove this test?

test/jdk/java/util/Locale/ISO639.java line 299:

> 297: 
> 298: // CODES generated from https://www.loc.gov/standards/iso639-2/ISO-639-2_utf-8.txt
> 299: // on March 9th, 2023.

Should be `expectedISO639Codes` instead of `CODES`, and this comment would be better placed on top of `expectedISO639Codes` method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14721#discussion_r1251159222
PR Review Comment: https://git.openjdk.org/jdk/pull/14721#discussion_r1251155431

From mchung at openjdk.org  Mon Jul  3 19:07:10 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Jul 2023 19:07:10 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v20]
In-Reply-To: <hf1xG7bL3h5eNL7G5HMcj39OT31KhqHRNS-QmnyuwTQ=.118cf71b-5df9-429c-b435-93dc87968515@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <hf1xG7bL3h5eNL7G5HMcj39OT31KhqHRNS-QmnyuwTQ=.118cf71b-5df9-429c-b435-93dc87968515@github.com>
Message-ID: <FB2WkV_IZGzG9uQXEHXuXlvypPQDbLkiQWnMpi1Mqeg=.e534be83-6652-43eb-a7d7-e08064a24e82@github.com>

On Sun, 2 Jul 2023 02:05:23 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 44 commits:
> 
>  - Merge branch 'master' into explore/mhp-iface
>  - stage
>    
>    Signed-off-by: liach <liach at users.noreply.github.com>
>  - Review comments
>  - 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
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/0e3d91dc...44e62271

No, it wouldn't.   `PROXY_LOOKUPS.get(intfc)` returns the `WeakReference` of the lookup class which is strongly reachable in the stack frame.

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

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

From duke at openjdk.org  Mon Jul  3 19:44:12 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 3 Jul 2023 19:44:12 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v5]
In-Reply-To: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
Message-ID: <qoc6DCxqbx0k7ae7G-TzZVZyeUia_qcZTtD58_qX7z8=.01b01e2e-ab89-4dc1-873a-ae633b87f1d8@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 eight additional commits since the last revision:

 - Merge branch 'openjdk:master' into latin1-no-repl
 - 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/512029d7..76498a5b

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

  Stats: 7482 lines in 474 files changed: 4398 ins; 1064 del; 2020 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 Jul  3 19:46:38 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 3 Jul 2023 19:46:38 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v6]
In-Reply-To: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
Message-ID: <7mAWi6eB57x0f0zs0fkVQ02POF5H05Dj3Jvw1QPa1IY=.1fa0133d-2a24-437e-b2a6-66cdf1ca0985@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:

  Use newStringLatin1NoRepl in UUID

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14655/files
  - new: https://git.openjdk.org/jdk/pull/14655/files/76498a5b..96788ddd

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

  Stats: 8 lines in 1 file changed: 0 ins; 6 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 mchung at openjdk.org  Mon Jul  3 20:25:05 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Jul 2023 20:25:05 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v12]
In-Reply-To: <cnOjEMZxpEKseWAzJc2hd5QLMdr9IeX0VLHLJ0RvtLo=.422fbffd-e4ef-4a57-855d-80bf821b2ddf@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <cnOjEMZxpEKseWAzJc2hd5QLMdr9IeX0VLHLJ0RvtLo=.422fbffd-e4ef-4a57-855d-80bf821b2ddf@github.com>
Message-ID: <q7G1LJoSYt_s-NmDi-KjnbsQHt9dpFpPFECguPxh8gM=.5804a18e-be76-4ba6-9d7a-a5e85018a8c2@github.com>

On Sat, 1 Jul 2023 18:36:10 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:
> 
>  - Fix test
>  - Fix ArrayList initialization and off-by-one errors

Thanks for the update.   Some comments below.   The test you add does not cause new locals be defined in the helper methods.   Do you think you can add such test case  i.e. new elements are added in the dedup var list by the helper functions?

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 128:

> 126: 
> 127:     public SystemModulesPlugin() {
> 128:         this(75);

Configuration is done via the `configure` method.   This allows users to tune the batch size by configuring the plugin on the command line.  For example:


system-modules.argument=batch-size=<N> sets the batch size of module descriptors\n\
\                       to avoid exceeding the method length limit.  The default\n\
\                       batch size is 75.   

system-modules.usage=\
\  --system-modules [batch-size=<N>]\n\
\                            Fast loading of module descriptors (always enabled).\n\
\                            The batch size specifies the maximum number of modules\n\
\                            be handled in one method to workaround if the generated\n\
\                            bytecode exceeds the method size limit. The default\n\
\                            batch size is 75.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 543:

> 541:         private static final int MAX_LOCAL_VARS = 256;
> 542: 
> 543:         private final int BUILDER_VAR    = MAX_LOCAL_VARS + 1;

why this one can't use the next available local variables?   i.e.  if no splitting, 1 is the next available slot (btw it looks like using 0 in the current implementation is a bug because this is an instance method).   If module descriptors are done in multiple helper methods, 3 is the next available slot.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 544:

> 542: 
> 543:         private final int BUILDER_VAR    = MAX_LOCAL_VARS + 1;
> 544:         private final int DEDUP_LIST_VAR = MAX_LOCAL_VARS + 2;

Same comment as BUILDER_VAR.  But this dedup variable list is passed as a parameter to the helper method.  It's already on the local slot 2.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 718:

> 716:             }
> 717: 
> 718:             // Instead of adding the module descriptor calls in this method,

What about this?


            // Split the module descriptors be created by multiple helper methods.
            // Each helper method "subi" creates the maximum N number of module descriptors
            //     mi, m{i+1} ...
            // to avoid exceeding the 64kb limit of method length.  Then it will call
            // "sub{i+1}" to creates the next batch of module descriptors m{i+n}, m{i+n+1}...
            // and so on.  During the construction of the module descriptors, the string sets and
            // modifier sets are deduplicated (see SystemModulesClassGenerator.DedupSetBuilder)
            // and cached in the locals. These locals are saved in an array list so
            // that the helper method can restore the local variables that may be
            // referenced by the bytecode generated for creating module descriptors.
            // Pseudo code looks like this:
            //
            // void subi(ModuleDescriptor[] mdescs, ArrayList<Object> localvars) {
            //      // assign localvars to local variables
            //      var l3 = localvars.get(0);
            //      var l4 = localvars.get(1);
            //        :
            //      // fill mdescs[i] to mdescs[i+n-1]
            //      mdescs[i] = ...
            //      mdescs[i+1] = ...
            //        :
            //      // save new local variables added
            //      localvars.add(lx)
            //      localvars.add(l{x+1})
            //        :
            //      sub{i+i}(mdescs, localvars);
            // }

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 745:

> 743:             ClassDesc arrayListClassDesc = ClassDesc.ofInternalName("java/util/ArrayList");
> 744: 
> 745:             int firstVar = nextLocalVar;

Suggestion:

            int dedupVarStart = nextLocalVar;

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 746:

> 744: 
> 745:             int firstVar = nextLocalVar;
> 746:             var wrapper = new Object() {

I think you can simply use a local variable at the beginning of each iteration.  See below.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 777:

> 775:             for (int n = 0, count = 0; n < splitModuleInfos.size(); count += splitModuleInfos.get(n).size(), n++) {
> 776:                 int index = n;       // the index of which ModuleInfo being processed in the current batch
> 777:                 int start = count;   // the start index to the return ModuleDescriptor array for the current batch

add `int curDedupVar = nextLocalVar;`

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 784:

> 782:                         cob -> {
> 783:                             cob.aload(2)
> 784:                                .astore(DEDUP_LIST_VAR);

I think you can keep slot 2 for the dedup var list by changing the start of `nextLocalVar` to 3?  Then you don't need to reassign it to another local.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 787:

> 785: 
> 786:                             if (nextLocalVar > firstVar) {
> 787:                                 for (int i = firstVar; i < nextLocalVar; i++) {

Suggestion:

                                for (int i = firstLocalVar; i < curLocalVar; i++) {

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 787:

> 785: 
> 786:                             if (nextLocalVar > firstVar) {
> 787:                                 for (int i = firstVar; i < nextLocalVar; i++) {

Suggestion:

                            if (curLocalVar > firstLocalVar) {
                                for (int i = firstLocalVar; i < curLocalVar; i++) {

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 806:

> 804:                             if (index < splitModuleInfos.size() - 1) {
> 805:                                 if ((nextLocalVar > firstVar) && (nextLocalVar > wrapper.lastCopiedVar)) {
> 806:                                     for (int i = wrapper.lastCopiedVar + 1; i < nextLocalVar; i++) {

shouldn't it start with `wrapper.lastCopiedVar`? 

Suggestion:

                            if (index < splitModuleInfos.size() - 1) {
                                if (nextLocalVar > firstLocalVar && nextLocalVar > curLocalVar) {
                                    for (int i = curLocalVar; i < nextLocalVar; i++) {

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

PR Review: https://git.openjdk.org/jdk/pull/14408#pullrequestreview-1511699439
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251228567
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251239488
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251240283
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251241479
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251243630
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251242653
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251244124
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251247256
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251249679
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251250488
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251251439

From mchung at openjdk.org  Mon Jul  3 20:25:08 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Jul 2023 20:25:08 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v6]
In-Reply-To: <HYMaYgWe3-QdviQRhnbqLh7eonRPg-yI6szqiRHXh98=.c4f03d67-c902-4695-9da5-12db30d43eab@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>
 <HYMaYgWe3-QdviQRhnbqLh7eonRPg-yI6szqiRHXh98=.c4f03d67-c902-4695-9da5-12db30d43eab@github.com>
Message-ID: <H5n0euImPxmTp6xwL_v_5JQB5oolFSDG6Ohvl02xmfs=.c01e5fb1-4ccb-4e65-9c71-34a6bf9cc232@github.com>

On Sat, 1 Jul 2023 10:07:15 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> 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`?
>
> If it is not present, I get following output (sorry for German - `./configure` doesn't allow `JAVA_TOOL_OPTIONS` to be set to `-Duser.language=en`
> 
> 
> windir='C:\WINDOWS' \
>     'c:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\images\jdk\bin\javac' \
>         -J-Xmx768m \
>         -J-XX:MaxRAMPercentage=2.08333 \
>         -J'-Dtest.boot.jdk=c:\progra~1\openjdk\jdk-20~1.1' \
>         -J'-Djava.io.tmpdir=c:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jlink_JLink100Modules_java\tmp' \
>         -J-ea \
>         -J-esa \
>         -J-Dtest.vm.opts='-Xmx768m -XX:MaxRAMPercentage=2.08333 -Dtest.boot.jdk=c:\progra~1\openjdk\jdk-20~1.1 -Djava.io.tmpdir=c:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jlink_JLink100Modules_java\tmp -ea -esa' \
>         -J-Dtest.tool.vm.opts='-J-Xmx768m -J-XX:MaxRAMPercentage=2.08333 -J-Dtest.boot.jdk=c:\progra~1\openjdk\jdk-20~1.1 -J-Djava.io.tmpdir=c:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jlink_JLink100Modules_java\tmp -J-ea -J-esa' \
>         -J-Dtest.compiler.opts= \
>         -J-Dtest.java.opts= \
>         -J-Dtest.jdk='c:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\images\jdk' \
>         -J-Dcompile.jdk='c:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\images\jdk' \
>         -J-Dtest.timeout.factor=4.0 \
>         -J-Dtest.nativepath='c:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\images\test\jdk\jtreg\native' \
>         -J-Dtest.root='C:\git-repositories\jdk\jdk\test\jdk' \
>         -J-Dtest.name=tools/jlink/JLink100Modules.java \
>         -J-Dtest.file='C:\git-repositories\jdk\jdk\test\jdk\tools\jlink\JLink100Modules.java' \
>         -J-Dtest.src='C:\git-repositories\jdk\jdk\test\jdk\tools\jlink' \
>         -J-Dtest.src.path='C:\git-repositories\jdk\jdk\test\jdk\tools\jlink;C:\git-repositories\jdk\jdk\test\jdk\tools\lib' \
>         -J-Dtest.classes='C:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jlink_JLink100Modules_java\classes\0\tools\jlink\JLink100Modules.d' \
>         -J-Dtest.class.path='C:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jlink_JLink100Modules_java\classes\0\tools\jlink\JLink100Modules.d;C:\git-repositories\jdk\jdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jlink_JLink100Modules_java\classe...

I see now.  It's used by JImageValidator and that can be replaced by the ClassFile API in the future.  Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251254277

From naoto at openjdk.org  Mon Jul  3 20:48:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Jul 2023 20:48:53 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <Lq67tFovUjWJoWxs655dwkkjg2UAuNQLWWZNdK9zPys=.82bcb1bf-20b3-4b92-a990-16c9d3210a1e@github.com>

On Mon, 3 Jul 2023 11:12:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in the java.text area.
> 
> * Some changes to `equals` and `hashCode` are refactoring rather than modernization. Such changes can be as trivial as rearranging, adding, or commenting checks.
> 
> * java.text area contains more classes whose `equals` and `hashCode` could be simplified; for example: sun.text.CompactByteArray or java.text.DigitList. However, I found no evidence of `equals` and `hashCode` in those classes being used in source or tests. Since writing new tests in this case seems unreasonable, I **excluded** those classes from this PR.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14752#pullrequestreview-1511762190

From mchung at openjdk.org  Mon Jul  3 21:00:53 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Jul 2023 21:00:53 GMT
Subject: [jdk21] Integrated: 8254566: Clarify the spec of
 ClassLoader::getClassLoadingLock for non-parallel capable loader
In-Reply-To: <-y9RnzrpTwLkX2jtPtnAQe2ix0Nu3Z_b3ScpbybesxU=.5b3d81b3-87ea-4680-8e16-6822d8936cd3@github.com>
References: <-y9RnzrpTwLkX2jtPtnAQe2ix0Nu3Z_b3ScpbybesxU=.5b3d81b3-87ea-4680-8e16-6822d8936cd3@github.com>
Message-ID: <geiIRmZCj1YOoJGq8Y-51EOp_ywQYQqwQLijmLGJzNI=.ca7e304f-2057-4278-993e-ae9f16b87626@github.com>

On Mon, 3 Jul 2023 16:23:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Backport of commit [b9198f99](https://github.com/openjdk/jdk/commit/b9198f993173b0fbdc7ff1400e2205d3969370da).

This pull request has now been integrated.

Changeset: 205dffe3
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/205dffe3831a0edca16bb66d9e455c741d543034
Stats:     16 lines in 1 file changed: 9 ins; 0 del; 7 mod

8254566: Clarify the spec of ClassLoader::getClassLoadingLock for non-parallel capable loader

Reviewed-by: iris
Backport-of: b9198f993173b0fbdc7ff1400e2205d3969370da

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

PR: https://git.openjdk.org/jdk21/pull/93

From duke at openjdk.org  Mon Jul  3 21:11:01 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Mon, 3 Jul 2023 21:11:01 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v13]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <T32BjlT0cAAikp78Qs3ncGnPn8-l-665Ai5Bs8HMokM=.c9fd2e85-2b92-4632-a64c-0c6487015eca@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 pull request now contains 19 commits:

 - Reposition DEDUP_LIST_VAR and BUILDER_VAR
 - Merge remote-tracking branch 'upstream/master' into fix-8240567
 - Fix test
 - Fix ArrayList initialization and off-by-one errors
 - Try to execute java(.exe) of build runtime
 - Reuse helper array list
 - No final for class parameters
 - Apply suggestions from code review
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Merge remote-tracking branch 'upstream/master' into fix-8240567
   
   # Conflicts:
   #	src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
 - Add description
 - ... and 9 more: https://git.openjdk.org/jdk/compare/b9198f99...6abca9f3

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

Changes: https://git.openjdk.org/jdk/pull/14408/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=12
  Stats: 262 lines in 2 files changed: 249 ins; 1 del; 12 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 Jul  3 21:11:03 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Mon, 3 Jul 2023 21:11:03 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v12]
In-Reply-To: <q7G1LJoSYt_s-NmDi-KjnbsQHt9dpFpPFECguPxh8gM=.5804a18e-be76-4ba6-9d7a-a5e85018a8c2@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <cnOjEMZxpEKseWAzJc2hd5QLMdr9IeX0VLHLJ0RvtLo=.422fbffd-e4ef-4a57-855d-80bf821b2ddf@github.com>
 <q7G1LJoSYt_s-NmDi-KjnbsQHt9dpFpPFECguPxh8gM=.5804a18e-be76-4ba6-9d7a-a5e85018a8c2@github.com>
Message-ID: <E_w_TdUqJY9EWA6nUEAO1gJ1dJAZxB-F3BGkPIlIDSE=.2e0f3a45-cbf8-4798-9827-44b3637c0eb4@github.com>

On Mon, 3 Jul 2023 20:00:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Oliver Kopp has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix test
>>  - Fix ArrayList initialization and off-by-one errors
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 543:
> 
>> 541:         private static final int MAX_LOCAL_VARS = 256;
>> 542: 
>> 543:         private final int BUILDER_VAR    = MAX_LOCAL_VARS + 1;
> 
> why this one can't use the next available local variables?   i.e.  if no splitting, 1 is the next available slot (btw it looks like using 0 in the current implementation is a bug because this is an instance method).   If module descriptors are done in multiple helper methods, 3 is the next available slot.

I tried that multiple times and always failed.  With following hack, I "debugged" the value of nextLocalVar at the beginning of the split:

    Files.writeString(Path.of("C:\\temp\\test.log"), "nextlocavar" + nextLocalVar, StandardOpenOption.CREATE, StandardOpenOption.APPEND);

The values are always 4. I did not dare to overwrite these "magic" slots 1, 2, 3. Despite using IntelliJ's call hierarchy feature, I could not find out where in the code this happens or for what reasons.

I moved `BUILDER_VAR` and `DEDUP_LIST_VAR` two "away".

I think, using `0` was "intentional", because `this` was not needed in the method and thus, this slot could be reused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251281097

From duke at openjdk.org  Mon Jul  3 21:28:09 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Mon, 3 Jul 2023 21:28:09 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v14]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <nMUIsM_lzObRo45VTXtfboa-w9ZPBDLaLMLHOzfPGNQ=.6e5155bc-3cc2-4eb1-a1bb-1406809fa3ea@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:

  Add --system-modules [batch-size=<N>]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14408/files
  - new: https://git.openjdk.org/jdk/pull/14408/files/6abca9f3..9835a640

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

  Stats: 22 lines in 2 files changed: 10 ins; 5 del; 7 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 Jul  3 21:28:11 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Mon, 3 Jul 2023 21:28:11 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v6]
In-Reply-To: <Rpfc5C0quW1vIjD2R5BTRznfAipUt86zVqd2AgrzUuk=.31b81b2b-f210-4415-8115-7c7bec116d1b@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>
 <oXuqPp6460DVzFwOiDPge4j4z-KhGxNJMPKrVLtyhiU=.68349d72-32e9-4740-9739-5204c2b40cda@github.com>
 <Rpfc5C0quW1vIjD2R5BTRznfAipUt86zVqd2AgrzUuk=.31b81b2b-f210-4415-8115-7c7bec116d1b@github.com>
Message-ID: <USC_IqD2bZy9G1U_lT0EGThFOq5h9X1tEywuUSfwJgg=.90d5396b-1336-44e8-aa3f-3cd7d9bbd951@github.com>

On Mon, 3 Jul 2023 17:09:35 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> What I meant here is to change the `configure` method to allow the plugin to take an argument for example
>> 
>>     --system-modules batch-size=100
>> 
>> 
>> This argument is optional.   If not specified, the default value is 75.    This way you can tune the batch-size if we hit the method size limit for whatever reason.   And the test can also verify with different size if appropriate.
>
> `plugins.properties` needs to be updated to show the option added for this plugin.   
> 
> BTW, the current argument described in the usage is out-dated which needs update.
> 
> system-modules.argument=retainModuleTarget

Added it at 9835a64018d. This is not for the main `./configure`. To which configure does that go?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251288777

From duke at openjdk.org  Mon Jul  3 21:33:29 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Mon, 3 Jul 2023 21:33:29 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v15]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <DswoZyCWro9oGK37Aw48zMuzUMuLfTdqA0_J2nZne7o=.41e76b54-cbea-4ff2-ae0a-cdf64b34f537@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:

  Refine comment
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14408/files
  - new: https://git.openjdk.org/jdk/pull/14408/files/9835a640..ae1bbe7c

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

  Stats: 27 lines in 1 file changed: 15 ins; 0 del; 12 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 mchung at openjdk.org  Mon Jul  3 22:03:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Jul 2023 22:03:56 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v6]
In-Reply-To: <USC_IqD2bZy9G1U_lT0EGThFOq5h9X1tEywuUSfwJgg=.90d5396b-1336-44e8-aa3f-3cd7d9bbd951@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>
 <oXuqPp6460DVzFwOiDPge4j4z-KhGxNJMPKrVLtyhiU=.68349d72-32e9-4740-9739-5204c2b40cda@github.com>
 <Rpfc5C0quW1vIjD2R5BTRznfAipUt86zVqd2AgrzUuk=.31b81b2b-f210-4415-8115-7c7bec116d1b@github.com>
 <USC_IqD2bZy9G1U_lT0EGThFOq5h9X1tEywuUSfwJgg=.90d5396b-1336-44e8-aa3f-3cd7d9bbd951@github.com>
Message-ID: <xHsE4DOHIpRlRuBlnlA2KJd4OqYJdhtLliXPe-AtyWU=.b8fdd60e-16f4-4245-b753-2525d2a32ab5@github.com>

On Mon, 3 Jul 2023 21:22:36 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> `plugins.properties` needs to be updated to show the option added for this plugin.   
>> 
>> BTW, the current argument described in the usage is out-dated which needs update.
>> 
>> system-modules.argument=retainModuleTarget
>
> Added it at 9835a64018d. This is not for the main `./configure`. To which configure does that go?

`SystemModulesPlugin::configure`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1251303974

From liach at openjdk.org  Mon Jul  3 23:52:52 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 3 Jul 2023 23:52:52 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>

On Mon, 3 Jul 2023 11:12:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in the java.text area.
> 
> * Some changes to `equals` and `hashCode` are refactoring rather than modernization. Such changes can be as trivial as rearranging, adding, or commenting checks.
> 
> * java.text area contains more classes whose `equals` and `hashCode` could be simplified; for example: sun.text.CompactByteArray or java.text.DigitList. However, I found no evidence of `equals` and `hashCode` in those classes being used in source or tests. Since writing new tests in this case seems unreasonable, I **excluded** those classes from this PR.

src/java.base/share/classes/java/text/AttributedString.java line 661:

> 659: 
> 660:     // returns whether the two objects are either both null or equal
> 661:     private static boolean valuesMatch(Object value1, Object value2) {

Can this be simply inlined, that its occurrences are replaced by Objects.equals?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1250888931

From prappo at openjdk.org  Tue Jul  4 00:24:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 4 Jul 2023 00:24:53 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text
In-Reply-To: <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
Message-ID: <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>

On Mon, 3 Jul 2023 13:22:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in the java.text area.
>> 
>> * Some changes to `equals` and `hashCode` are refactoring rather than modernization. Such changes can be as trivial as rearranging, adding, or commenting checks.
>> 
>> * java.text area contains more classes whose `equals` and `hashCode` could be simplified; for example: sun.text.CompactByteArray or java.text.DigitList. However, I found no evidence of `equals` and `hashCode` in those classes being used in source or tests. Since writing new tests in this case seems unreasonable, I **excluded** those classes from this PR.
>
> src/java.base/share/classes/java/text/AttributedString.java line 661:
> 
>> 659: 
>> 660:     // returns whether the two objects are either both null or equal
>> 661:     private static boolean valuesMatch(Object value1, Object value2) {
> 
> Can this be simply inlined, that its occurrences are replaced by Objects.equals?

It certainly can, but...

I've been working on a similar PR for the java.util package. That package has lots of performance-sensitive locations that could also use `Objects.equals`. In that package, I ran into comments referring to an issue with using Object.equals: [JDK-8015417](https://bugs.openjdk.org/browse/JDK-8015417). So, I might do some additional research before integrating this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1251354662

From liach at openjdk.org  Tue Jul  4 00:42:58 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Jul 2023 00:42:58 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text
In-Reply-To: <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
Message-ID: <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>

On Tue, 4 Jul 2023 00:22:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/AttributedString.java line 661:
>> 
>>> 659: 
>>> 660:     // returns whether the two objects are either both null or equal
>>> 661:     private static boolean valuesMatch(Object value1, Object value2) {
>> 
>> Can this be simply inlined, that its occurrences are replaced by Objects.equals?
>
> It certainly can, but...
> 
> I've been working on a similar PR for the java.util package. That package has lots of performance-sensitive locations that could also use `Objects.equals`. In that package, I ran into comments referring to an issue with using Object.equals: [JDK-8015417](https://bugs.openjdk.org/browse/JDK-8015417). So, I might do some additional research before integrating this PR.

Hmm, I think that issue refers to code that have explicit non-Object parameter types (like `X::equals(Object)boolean` in the issue's sample). This method already have both arguments as `Object`, so I don't think there's any type-specific inlining opportunities.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1251361532

From valeriep at openjdk.org  Tue Jul  4 00:51:10 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 4 Jul 2023 00:51:10 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base [v3]
In-Reply-To: <RnvLcqdxUlImVAZoqsqtJCI24ZGtMulCjeJ039uOSeA=.8dbbb2e0-247b-4fce-a0f2-97159b7fc157@github.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
 <RnvLcqdxUlImVAZoqsqtJCI24ZGtMulCjeJ039uOSeA=.8dbbb2e0-247b-4fce-a0f2-97159b7fc157@github.com>
Message-ID: <mD8BifefUFOtw1sgnYXQdpnYspHZBZ0uNhundp2QUJM=.1215246e-bfe3-45d0-aeb7-6a2f30c39e48@github.com>

On Mon, 3 Jul 2023 17:51:10 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:
> 
>   return non volatile variable

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14457#pullrequestreview-1511888440

From prappo at openjdk.org  Tue Jul  4 01:04:07 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 4 Jul 2023 01:04:07 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text
In-Reply-To: <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
Message-ID: <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>

On Tue, 4 Jul 2023 00:40:14 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hmm, I think that issue refers to code that have explicit non-Object parameter types (like `X::equals(Object)boolean` in the issue's sample). This method already have both arguments as `Object`, so I don't think there's any type-specific inlining opportunities.

If that's true, then perhaps those (and some other) locations got that idea wrong:
* https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/Collections.java#L5712-L5719
* https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/AbstractMap.java#L577-L585

Maybe @rose00 could clarify that? 

FWIW, I also note that `HashMap` does not use similar private static methods; it uses `Objects.equals(Object, Object)` and `Objects.hashCode` overloads that take parameters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1251369954

From duke at openjdk.org  Tue Jul  4 04:19:03 2023
From: duke at openjdk.org (Swati Sharma)
Date: Tue, 4 Jul 2023 04:19:03 GMT
Subject: RFR: 8311178: JMH tests don't scale well when sharing output
 buffers
In-Reply-To: <-bJ0RJ4qNzcZoXn6WmqPd7VbtBEqoi-iMmUy3D-MNJo=.13545140-598a-4691-a13c-9c559756c918@github.com>
References: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
 <-bJ0RJ4qNzcZoXn6WmqPd7VbtBEqoi-iMmUy3D-MNJo=.13545140-598a-4691-a13c-9c559756c918@github.com>
Message-ID: <LRe46iN8wLZNHjfkME1Bq2EBIdhQsEiqkx83ViAq9BM=.be1de2c1-1656-4859-accc-368970d1beb2@github.com>

On Sat, 1 Jul 2023 19:05:23 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> The below benchmark files have scaling issues due to cache contention and leads to poor scaling when run on multiple threads. The patch sets the scope from benchmark level to thread level to fix the issue:
>> - org/openjdk/bench/java/io/DataOutputStreamTest.java
>> - org/openjdk/bench/java/lang/ArrayCopyObject.java
>> - org/openjdk/bench/java/lang/ArrayFiddle.java
>> - org/openjdk/bench/java/time/format/DateTimeFormatterBench.java
>> - org/openjdk/bench/jdk/incubator/vector/IndexInRangeBenchmark.java
>> - org/openjdk/bench/jdk/incubator/vector/MemorySegmentVectorAccess.java
>> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedBenchmark.java
>> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedIOOBEBenchmark.java
>> - org/openjdk/bench/vm/compiler/ArrayFill.java
>> - org/openjdk/bench/vm/compiler/IndexVector.java
>> 
>> Also removing the static scope for variables in org/openjdk/bench/jdk/incubator/vector/VectorFPtoIntCastOperations.java for better scaling.
>> 
>> Please review and share your feedback.
>> 
>> Thanks,
>> Swati
>
> test/micro/org/openjdk/bench/java/lang/ArrayCopyObject.java line 64:
> 
>> 62: }
>> 63: 
>> 64: @State(Scope.Thread)
> 
> Are you sure it makes sense as in `main()` method we set `fork(1)` so there's only one thread running the benchmark?

AFAIK fork value specifies number of times harness should [fork](https://javadoc.io/doc/org.openjdk.jmh/jmh-core/0.6/org/openjdk/jmh/annotations/Fork.html). Also the change is setting scope to thread level not controlling the number of threads.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14746#discussion_r1251459004

From duke at openjdk.org  Tue Jul  4 09:38:11 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Tue, 4 Jul 2023 09:38:11 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v16]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <Hhp8LtK4dS_Hml9_wb3mG-xxg3HoGsziFKWnb4Rvjms=.6a186cd3-f2f1-45e0-9edd-066760df309f@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:

 - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14408/files
  - new: https://git.openjdk.org/jdk/pull/14408/files/ae1bbe7c..142b5550

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

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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  Tue Jul  4 09:43:25 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Tue, 4 Jul 2023 09:43:25 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v17]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <bEFby568O__lkcEwWebL9JrSMD4TKJvxkpqtw43NlM8=.0c9e905d-5e57-438e-86df-929105d27274@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:

  Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14408/files
  - new: https://git.openjdk.org/jdk/pull/14408/files/142b5550..f50ec774

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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  Tue Jul  4 09:49:16 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Tue, 4 Jul 2023 09:49:16 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v18]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <KKd3VEWvWObFpDb4QQFZeqoUjnxwJrb9VeAp1mKtSos=.d4a2da11-1194-4520-adf0-25b413d4d120@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 pull request now contains 26 commits:

 - Merge remote-tracking branch 'upstream/master' into fix-8240567
 - Replace non-final wrapper by local variable
 - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Refine comment
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Add --system-modules [batch-size=<N>]
 - Reposition DEDUP_LIST_VAR and BUILDER_VAR
 - Merge remote-tracking branch 'upstream/master' into fix-8240567
 - Fix test
 - ... and 16 more: https://git.openjdk.org/jdk/compare/711cddd8...bbbbb0e5

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

Changes: https://git.openjdk.org/jdk/pull/14408/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=17
  Stats: 284 lines in 3 files changed: 265 ins; 1 del; 18 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  Tue Jul  4 11:00:13 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Tue, 4 Jul 2023 11:00:13 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v19]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <fp9PEVNZNpBwh0yHwPC9-HhI8vbH6pjDxUd29ogWEmw=.796ded42-ba4b-4a02-86a9-08b680110168@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:

  Refine test to fill DedupSetBuilder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14408/files
  - new: https://git.openjdk.org/jdk/pull/14408/files/bbbbb0e5..15d7448b

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

  Stats: 12 lines in 1 file changed: 2 ins; 3 del; 7 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  Tue Jul  4 11:00:14 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Tue, 4 Jul 2023 11:00:14 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v12]
In-Reply-To: <q7G1LJoSYt_s-NmDi-KjnbsQHt9dpFpPFECguPxh8gM=.5804a18e-be76-4ba6-9d7a-a5e85018a8c2@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <cnOjEMZxpEKseWAzJc2hd5QLMdr9IeX0VLHLJ0RvtLo=.422fbffd-e4ef-4a57-855d-80bf821b2ddf@github.com>
 <q7G1LJoSYt_s-NmDi-KjnbsQHt9dpFpPFECguPxh8gM=.5804a18e-be76-4ba6-9d7a-a5e85018a8c2@github.com>
Message-ID: <73he0C2zKdXwlsm5743pM4maEC-kKFLwAQDpJVuBh3o=.6a42b1c8-1ef3-4383-829b-2bf6795ad7b5@github.com>

On Mon, 3 Jul 2023 20:22:30 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Thanks for the update. Some comments below. 

Thank you for the feedback! I didn't see the "proper" usage of effectively final variables.

> The test you add does not cause new locals be defined in the helper methods. Do you think you can add such test case i.e. new elements are added in the dedup var list by the helper functions?

I modified the "end-to-end" test in [`15d7448` (#14408)](https://github.com/openjdk/jdk/pull/14408/commits/15d7448b3132e6f0838ac6cb8eb2b939c6eb00f2).

Note that the numbers cannot be arbitrarily increased. Otherwise, one gets errors similar to following

    Fehler: java.lang.IllegalArgumentException: Code length 102397 is outside the allowed range in sub1(ModuleDescriptor[],ArrayList)void

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

PR Comment: https://git.openjdk.org/jdk/pull/14408#issuecomment-1620024255

From jlaskey at openjdk.org  Tue Jul  4 12:38:55 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 4 Jul 2023 12:38:55 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v2]
In-Reply-To: <oo8ioWDux3g2ISV5aUMFzBzJJs5ediM8vvVQW_Qy3m4=.89108686-498a-4f70-9f71-019539e0b979@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <w8y-x_u0M6ZYanFXvIkiMhfEsQ76P0M1Fc_4zq8lZIw=.ecce0329-f356-422a-8571-a1ac1d954ec9@github.com>
 <oo8ioWDux3g2ISV5aUMFzBzJJs5ediM8vvVQW_Qy3m4=.89108686-498a-4f70-9f71-019539e0b979@github.com>
Message-ID: <OXIRroFEjq-SZ4YLbwWsa2wwtaWm3D3BPVcz8cZHZuk=.f99b09d0-17b8-4a66-ac4d-b07572b1783a@github.com>

On Fri, 30 Jun 2023 17:48:35 GMT, Mandy Chung <mchung 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
>
> 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`.

@mlchung I missed the use of newNativeReferenceQueue. This change has been sitting in my queue for a few years, I will adapt to the new reality. Thank you for pointing it out.

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

PR Comment: https://git.openjdk.org/jdk/pull/14684#issuecomment-1620171192

From prappo at openjdk.org  Tue Jul  4 12:47:29 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 4 Jul 2023 12:47:29 GMT
Subject: RFR: 8311290: Improve java.lang.ref.Cleaner rendered documentation
Message-ID: <-CJKywK-ap6b24sv5195VMvViQ8k0EGz2quYvTfSHLk=.eeb06202-951c-4937-9110-991988bb7d4a@github.com>

1. Missing leading asterisk interferes with example indentation; nothing in https://bugs.openjdk.org/browse/JDK-8276700 (or review thereof), which introduced that line, suggests that the asterisk was omitted on purpose. 
2. link and linkplain tags are used suboptimally.

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

Commit messages:
 - Improve links markup

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

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

From jlaskey at openjdk.org  Tue Jul  4 12:55:22 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 4 Jul 2023 12:55:22 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v3]
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: <ogWIsIozaQk7aTZ8BaGJcoo8N87re4GiEawCnCVvNT4=.e71655ee-7322-48c2-ab47-077c21a7a576@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:

  Update to use VirtualThread friendly stale queue.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14684/files
  - new: https://git.openjdk.org/jdk/pull/14684/files/ed467b64..b05c232f

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

  Stats: 8 lines in 2 files changed: 2 ins; 5 del; 1 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 jlaskey at openjdk.org  Tue Jul  4 12:55:22 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 4 Jul 2023 12:55:22 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v3]
In-Reply-To: <oo8ioWDux3g2ISV5aUMFzBzJJs5ediM8vvVQW_Qy3m4=.89108686-498a-4f70-9f71-019539e0b979@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <w8y-x_u0M6ZYanFXvIkiMhfEsQ76P0M1Fc_4zq8lZIw=.ecce0329-f356-422a-8571-a1ac1d954ec9@github.com>
 <oo8ioWDux3g2ISV5aUMFzBzJJs5ediM8vvVQW_Qy3m4=.89108686-498a-4f70-9f71-019539e0b979@github.com>
Message-ID: <Tz-P2HBVxh2_exPLHdDphfZIWy12YrkpPEFFUe5YUdA=.61cd9295-9cef-4802-a3a8-b04e22770f7c@github.com>

On Fri, 30 Jun 2023 17:29:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update to use VirtualThread friendly stale queue.
>
> 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.

Will update

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1251985524

From jvernee at openjdk.org  Tue Jul  4 15:11:20 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Jul 2023 15:11:20 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v20]
In-Reply-To: <hf1xG7bL3h5eNL7G5HMcj39OT31KhqHRNS-QmnyuwTQ=.118cf71b-5df9-429c-b435-93dc87968515@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <hf1xG7bL3h5eNL7G5HMcj39OT31KhqHRNS-QmnyuwTQ=.118cf71b-5df9-429c-b435-93dc87968515@github.com>
Message-ID: <rNliqJl6CKnlyXP226Any7ZoBeHmjaKzO65JYiC8O9Q=.1ddae1a6-bf0b-45a0-853c-6b51881bdf5d@github.com>

On Sun, 2 Jul 2023 02:05:23 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 44 commits:
> 
>  - Merge branch 'master' into explore/mhp-iface
>  - stage
>    
>    Signed-off-by: liach <liach at users.noreply.github.com>
>  - Review comments
>  - 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
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/0e3d91dc...44e62271

Overall the latest version looks really good. Thanks!

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 186:

> 184:      * Discussion:
> 185:      * Since project leyden aims to improve startup speed, asInterfaceInstance
> 186:      * will share one implementation class for each interface than one implementation

Suggestion:

     * will share one implementation class for each interface rather than one implementation

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 324:

> 322:             r = PROXY_LOOKUPS.get(intfc);
> 323:         }
> 324:         return r.get();

This doesn't look right to me. AFAICT the Lookup can be GC'd before we call `get`.

> No, it wouldn't. PROXY_LOOKUPS.get(intfc) returns the WeakReference of the lookup class which is strongly reachable in the stack frame.

I'm not sure how the lookup class (`intfc` ?) is keeping the `Lookup` alive here?

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

PR Review: https://git.openjdk.org/jdk/pull/13197#pullrequestreview-1512911743
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1252043160
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1252085215

From jvernee at openjdk.org  Tue Jul  4 15:11:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Jul 2023 15:11:21 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v20]
In-Reply-To: <rNliqJl6CKnlyXP226Any7ZoBeHmjaKzO65JYiC8O9Q=.1ddae1a6-bf0b-45a0-853c-6b51881bdf5d@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <hf1xG7bL3h5eNL7G5HMcj39OT31KhqHRNS-QmnyuwTQ=.118cf71b-5df9-429c-b435-93dc87968515@github.com>
 <rNliqJl6CKnlyXP226Any7ZoBeHmjaKzO65JYiC8O9Q=.1ddae1a6-bf0b-45a0-853c-6b51881bdf5d@github.com>
Message-ID: <Un9nM057_HHtFmN9LZ_xsIK7Kz0CnzOy_YQn6DpBZYg=.35de84d4-1403-4723-b8e4-2f7c7a4873f1@github.com>

On Tue, 4 Jul 2023 13:37:45 GMT, Jorn Vernee <jvernee 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 44 commits:
>> 
>>  - Merge branch 'master' into explore/mhp-iface
>>  - stage
>>    
>>    Signed-off-by: liach <liach at users.noreply.github.com>
>>  - Review comments
>>  - 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
>>  - ... and 34 more: https://git.openjdk.org/jdk/compare/0e3d91dc...44e62271
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 186:
> 
>> 184:      * Discussion:
>> 185:      * Since project leyden aims to improve startup speed, asInterfaceInstance
>> 186:      * will share one implementation class for each interface than one implementation
> 
> Suggestion:
> 
>      * will share one implementation class for each interface rather than one implementation

Perhaps this (and the above three notes) should be put into `@implNote`s.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1252053206

From prappo at openjdk.org  Tue Jul  4 19:07:11 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 4 Jul 2023 19:07:11 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: <Gv1n8I71wi5tj_7tTw_3_THVL3OHryZf9Ql5CoSiYUg=.67f7106d-7224-470a-9442-71f922bbd51f@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.

Alright, I think all the areas that this PR touches have been reviewed by area experts.

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

PR Comment: https://git.openjdk.org/jdk/pull/14718#issuecomment-1620628939

From prappo at openjdk.org  Tue Jul  4 19:07:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 4 Jul 2023 19:07:13 GMT
Subject: Integrated: 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: <CaxmruNSZegLj23Jbo8nyHa24-GLbjcq44hO8gB9kzs=.f46d65b8-3cc3-46e0-bebd-b7083dcb915a@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.

This pull request has now been integrated.

Changeset: 7b3c2dc5
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7b3c2dc5f45afc3646ff5cdc0f6efd68e0b70ea5
Stats:     23 lines in 13 files changed: 0 ins; 0 del; 23 mod

8311122: Fix typos in java.base

Reviewed-by: darcy, naoto, mchung, iris, mli, mullan

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

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

From prappo at openjdk.org  Tue Jul  4 19:13:20 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 4 Jul 2023 19:13:20 GMT
Subject: [jdk21] RFR: 8311122: Fix typos in java.base
Message-ID: <YrumBX_8GznPTvQDB5MMypOIO9nweYb2xv9MCEwR_Ok=.816a12c0-7560-4eef-a99c-a3d88f92b48c@github.com>

Hi all,

This pull request contains a backport of commit [7b3c2dc5](https://github.com/openjdk/jdk/commit/7b3c2dc5f45afc3646ff5cdc0f6efd68e0b70ea5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Pavel Rappo on 4 Jul 2023 and was reviewed by Joe Darcy, Naoto Sato, Mandy Chung, Iris Clark, Hamlin Li and Sean Mullan.

Thanks!

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

Commit messages:
 - Backport 7b3c2dc5f45afc3646ff5cdc0f6efd68e0b70ea5

Changes: https://git.openjdk.org/jdk21/pull/94/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=94&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/jdk21/pull/94.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/94/head:pull/94

PR: https://git.openjdk.org/jdk21/pull/94

From prappo at openjdk.org  Tue Jul  4 19:16:03 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 4 Jul 2023 19:16:03 GMT
Subject: [jdk21] RFR: 8311122: Fix typos in java.base
In-Reply-To: <YrumBX_8GznPTvQDB5MMypOIO9nweYb2xv9MCEwR_Ok=.816a12c0-7560-4eef-a99c-a3d88f92b48c@github.com>
References: <YrumBX_8GznPTvQDB5MMypOIO9nweYb2xv9MCEwR_Ok=.816a12c0-7560-4eef-a99c-a3d88f92b48c@github.com>
Message-ID: <62_fhK8uOuKoer-B-6-CA5tbSGNiMJaEJwIUXP-VGrU=.f064e582-d6f3-4596-a367-8a4a85923ba4@github.com>

On Tue, 4 Jul 2023 19:05:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7b3c2dc5](https://github.com/openjdk/jdk/commit/7b3c2dc5f45afc3646ff5cdc0f6efd68e0b70ea5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Pavel Rappo on 4 Jul 2023 and was reviewed by Joe Darcy, Naoto Sato, Mandy Chung, Iris Clark, Hamlin Li and Sean Mullan.
> 
> Thanks!

This PR is as close to noreg-doc as one can get. The only reason it should be backported to jdk21 is a typo in an error message here: https://github.com/openjdk/jdk21/blob/c9111d57ce132d70d4360535254658ef6b8d134d/src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java#L373

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

PR Comment: https://git.openjdk.org/jdk21/pull/94#issuecomment-1620635386

From mchung at openjdk.org  Tue Jul  4 21:03:24 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 4 Jul 2023 21:03:24 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v20]
In-Reply-To: <rNliqJl6CKnlyXP226Any7ZoBeHmjaKzO65JYiC8O9Q=.1ddae1a6-bf0b-45a0-853c-6b51881bdf5d@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <hf1xG7bL3h5eNL7G5HMcj39OT31KhqHRNS-QmnyuwTQ=.118cf71b-5df9-429c-b435-93dc87968515@github.com>
 <rNliqJl6CKnlyXP226Any7ZoBeHmjaKzO65JYiC8O9Q=.1ddae1a6-bf0b-45a0-853c-6b51881bdf5d@github.com>
Message-ID: <z50FP_6tYBl98sBqUj-9fotNsSRfZxp4VDe5mgMPjZQ=.dd988437-bb10-4de2-b476-8c4b0063d608@github.com>

On Tue, 4 Jul 2023 14:14:03 GMT, Jorn Vernee <jvernee 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 44 commits:
>> 
>>  - Merge branch 'master' into explore/mhp-iface
>>  - stage
>>    
>>    Signed-off-by: liach <liach at users.noreply.github.com>
>>  - Review comments
>>  - 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
>>  - ... and 34 more: https://git.openjdk.org/jdk/compare/0e3d91dc...44e62271
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 324:
> 
>> 322:             r = PROXY_LOOKUPS.get(intfc);
>> 323:         }
>> 324:         return r.get();
> 
> This doesn't look right to me. AFAICT the Lookup can be GC'd before we call `get`.
> 
>> No, it wouldn't. PROXY_LOOKUPS.get(intfc) returns the WeakReference of the lookup class which is strongly reachable in the stack frame.
> 
> I'm not sure how the lookup class (`intfc` ?) is keeping the `Lookup` alive here?

Sorry I re-read Chen's question and missing the last half of the sentence.   My reply was about:  If the referent is not GC'ed, `r.get()` returns non-null which will be returned to the caller.  If the referent becomes weakly reachable, `r.get()` will return null.

OK.  In any case, I was thinking to use a local variable to keep the lookup object strongly reachable.   I adjusted the patch to keep a class value of a holder of `WeakReference` ([ab3d8b2](https://github.com/mlchung/jdk/commit/ab3d8b2f086dfac4f8fda1ddce415270c0c53d2b)):


    private static Lookup getProxyClassLookup(Class<?> intfc) {
        WeakReferenceHolder<Lookup> r = PROXY_LOOKUPS.get(intfc);
        Lookup lookup = r.get();
        if (lookup == null) {
             // If the referent is cleared, create a new value and update cached weak reference.
            lookup = newProxyLookup(intfc);
            r.set(lookup);
        }
        return lookup;
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1252356427

From jvernee at openjdk.org  Tue Jul  4 21:40:09 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Jul 2023 21:40:09 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v20]
In-Reply-To: <z50FP_6tYBl98sBqUj-9fotNsSRfZxp4VDe5mgMPjZQ=.dd988437-bb10-4de2-b476-8c4b0063d608@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <hf1xG7bL3h5eNL7G5HMcj39OT31KhqHRNS-QmnyuwTQ=.118cf71b-5df9-429c-b435-93dc87968515@github.com>
 <rNliqJl6CKnlyXP226Any7ZoBeHmjaKzO65JYiC8O9Q=.1ddae1a6-bf0b-45a0-853c-6b51881bdf5d@github.com>
 <z50FP_6tYBl98sBqUj-9fotNsSRfZxp4VDe5mgMPjZQ=.dd988437-bb10-4de2-b476-8c4b0063d608@github.com>
Message-ID: <yPyS40bQO6_Okx38j7oNZ5PoFtHcj3xihrcaWJ8XF1s=.21d3611f-9859-4752-b405-b366dd2c64d9@github.com>

On Tue, 4 Jul 2023 21:00:30 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 324:
>> 
>>> 322:             r = PROXY_LOOKUPS.get(intfc);
>>> 323:         }
>>> 324:         return r.get();
>> 
>> This doesn't look right to me. AFAICT the Lookup can be GC'd before we call `get`.
>> 
>>> No, it wouldn't. PROXY_LOOKUPS.get(intfc) returns the WeakReference of the lookup class which is strongly reachable in the stack frame.
>> 
>> I'm not sure how the lookup class (`intfc` ?) is keeping the `Lookup` alive here?
>
> Sorry I re-read Chen's question and missing the last half of the sentence.   My reply was about:  If the referent is not GC'ed, `r.get()` returns non-null which will be returned to the caller.  If the referent becomes weakly reachable, `r.get()` will return null.
> 
> OK.  In any case, I was thinking to use a local variable to keep the lookup object strongly reachable.   I adjusted the patch to keep a class value of a holder of `WeakReference` ([ab3d8b2](https://github.com/mlchung/jdk/commit/ab3d8b2f086dfac4f8fda1ddce415270c0c53d2b)):
> 
> 
>     private static Lookup getProxyClassLookup(Class<?> intfc) {
>         WeakReferenceHolder<Lookup> r = PROXY_LOOKUPS.get(intfc);
>         Lookup lookup = r.get();
>         if (lookup == null) {
>              // If the referent is cleared, create a new value and update cached weak reference.
>             lookup = newProxyLookup(intfc);
>             r.set(lookup);
>         }
>         return lookup;
>     }

Ok, thanks. This is similar to the solution I would have suggested.

The only thing I'm unsure about is races. ClassValue allows multiple threads to race to compute the final value, but in the end only 1 is chosen that is returned to all threads.

If multiple threads race to create a new proxy lookup here, they will all get a distinct lookup returned to them. I think this is okay? Though, it would mean we have less sharing of proxy classes.

Maybe this code should synchronize on `r` to make sure only 1 lookup is created per interface. (Letting threads race to compute the value is also a possibility, but it also leads some threads to do work that is then discarded, and then the VM has to clean up the class they defined as well).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1252373506

From jrose at openjdk.org  Tue Jul  4 22:06:53 2023
From: jrose at openjdk.org (John R Rose)
Date: Tue, 4 Jul 2023 22:06:53 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text
In-Reply-To: <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
 <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
Message-ID: <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>

On Tue, 4 Jul 2023 01:01:22 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Hmm, I think that issue refers to code that have explicit non-Object parameter types (like `X::equals(Object)boolean` in the issue's sample). This method already have both arguments as `Object`, so I don't think there's any type-specific inlining opportunities.
>
>> Hmm, I think that issue refers to code that have explicit non-Object parameter types (like `X::equals(Object)boolean` in the issue's sample). This method already have both arguments as `Object`, so I don't think there's any type-specific inlining opportunities.
> 
> If that's true, then perhaps those (and some other) locations got that idea wrong:
> * https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/Collections.java#L5712-L5719
> * https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/AbstractMap.java#L577-L585
> 
> Maybe @rose00 could clarify that? 
> 
> FWIW, I also note that `HashMap` does not use similar private static methods; it uses `Objects.equals(Object, Object)` and `Objects.hashCode` overloads that take parameters.

I wrote a little case study on `Objects::equals` that talks about how it should optimize, when it does, why it doesn?t, and how (maybe) to fix that.

https://cr.openjdk.org/~jrose/jvm/equals-profile.html
https://cr.openjdk.org/~jrose/jvm/equals-profile.md

This is also attached to the JBS bug.

The work on [JDK-8026251](https://bugs.openjdk.org/browse/JDK-8026251) with the `TypeProfileLevel` switch bring us closer to correctly optimizing `Objects::equals` in more cases.  Sadly, JDK refactoring by itself will not get all the way to where we want to go.  The JVM?s profiling logic needs tweaking.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1252383352

From iris at openjdk.org  Tue Jul  4 23:32:59 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 4 Jul 2023 23:32:59 GMT
Subject: [jdk21] RFR: 8311122: Fix typos in java.base
In-Reply-To: <YrumBX_8GznPTvQDB5MMypOIO9nweYb2xv9MCEwR_Ok=.816a12c0-7560-4eef-a99c-a3d88f92b48c@github.com>
References: <YrumBX_8GznPTvQDB5MMypOIO9nweYb2xv9MCEwR_Ok=.816a12c0-7560-4eef-a99c-a3d88f92b48c@github.com>
Message-ID: <uAriPW49UIM-_Oltk6aclRhrJOq49Scm_sNhuycb3R4=.6a81c5ec-d5ba-4efb-a782-faf0c1bb5cd2@github.com>

On Tue, 4 Jul 2023 19:05:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7b3c2dc5](https://github.com/openjdk/jdk/commit/7b3c2dc5f45afc3646ff5cdc0f6efd68e0b70ea5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Pavel Rappo on 4 Jul 2023 and was reviewed by Joe Darcy, Naoto Sato, Mandy Chung, Iris Clark, Hamlin Li and Sean Mullan.
> 
> Thanks!

Appears identical to change in 22, as expected.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/94#pullrequestreview-1513478430

From djelinski at openjdk.org  Wed Jul  5 10:29:58 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 5 Jul 2023 10:29:58 GMT
Subject: RFR: 8311489: Remove unused dirent_md files
Message-ID: <0cdWgqaIhjUcLYTTHj5rHlAga6r3Uj2hOSfg8I8SOEM=.6be0b071-9421-43c7-8b77-e8e79486155c@github.com>

The methods declared in dirent_md are not used in libjava and not exported. They should be removed.

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

Commit messages:
 - Remove dirent_md

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

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

From simonis at openjdk.org  Wed Jul  5 11:52:11 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 5 Jul 2023 11:52:11 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() can throw if invoked
 reflectively
Message-ID: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>

As the included jtreg test demonstrates, `StackWalker.getCallerClass()` can throw an `UnsupportedOperationException` if called reflectively. Currently this only happens if we invoke `StackWalker.getCallerClass()` recursively reflectively, but this issue will become more prominent once we fix [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447).

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

Commit messages:
 - 8311500: StackWalker.getCallerClass() can throw if invoked reflectively

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

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

From prappo at openjdk.org  Wed Jul  5 12:51:16 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 5 Jul 2023 12:51:16 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v2]
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <yJYjdnSwyxGd9qAZm5chBOwJW9GVyqQzkoE0u6OYQxE=.87a9e8ca-2ea3-4af6-9d5b-041e6f275c73@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.

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

 - Add a benchmark
 - Merge branch 'master' into 8310813
 - Use fewer range checks to improve performance
 - Improve
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14630/files
  - new: https://git.openjdk.org/jdk/pull/14630/files/a9cbbe57..9f838612

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

  Stats: 16685 lines in 761 files changed: 8059 ins; 4263 del; 4363 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  Wed Jul  5 13:00:01 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 5 Jul 2023 13:00:01 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v2]
In-Reply-To: <pTMvEIx5UPajYBUi4pCgN6CsyzVd6tlJhqcla4D3nV4=.c8aa7c9d-4bbe-482e-8b96-1423950105eb@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <pTMvEIx5UPajYBUi4pCgN6CsyzVd6tlJhqcla4D3nV4=.c8aa7c9d-4bbe-482e-8b96-1423950105eb@github.com>
Message-ID: <sQMHonHDGXV9t_LBogY6AYWT6tu56sVHr9T6YOsIP6w=.1ac4bc77-f453-4586-8408-e879fea9a8a7@github.com>

On Thu, 29 Jun 2023 15:50:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Add a benchmark
>>  - Merge branch 'master' into 8310813
>>  - Use fewer range checks to improve performance
>>  - Improve
>>  - Initial commit
>
> LGTM; I assume the comment about aarch64 perf was a 10% improvement.

Here's some explanation for the recent commits I've added since @RogerRiggs reviewed this PR.

1. Since `BigInteger.hashCode()` is unspecified, we can change it. Again: I think that the proposed implementation is no worse in hashing quality than the current one; if you disagree, please voice your concerns.

FWIW, we can keep the existing `BigInteger.hashCode()` values whilst still improving the implementation, using JDK-internal support:

    @Override
    public int hashCode() {
        return ArraysSupport.vectorizedHashCode(mag, 0, mag.length, 1,
                ArraysSupport.T_INT) * signum;
    }

AFAIU, such an implementation would always yield exactly the same values the current (i.e. mainline) implementation does. But that could be a little slower than the original proposal, especially for a smaller BigInteger.

The key thing that allows to keep the current hash-code values in the above implementation is that `1` argument, which is the initial hash-code value, which cannot be specified in `Arrays.hashCode`. Unfortunately, we don't have mid-layer methods in between Arrays.hashCode and ArraysSupport.vectorizedHashCode like that of Arrays.mismatch and ArraysSupport.vectorizedMismatch. It's either all the null check but short-circuits or unconditional vectorization but the initial value. I wonder if we could consider `ArraysSupport.hashCode($type[] array, int fromIndex, int length, int initialValue)` overloads, which could be useful beyond BigInteger, as I've already seen in JDK. Contributors to ArraysSupport, @PaulSandoz, @ChrisHegarty, @cl4es, @stuart-marks; thoughts?

2. Maybe surprisingly, but we don't have microbenchmarks for BigInteger's equals, hashCode, and compareTo. While I don't know how often people use the former two methods, I reckon, the latter method is essential. Anyway, I added benchmarks to cover all three. Note: benchmark for hashCode shows only its performance, not its hashing quality. Again: if you think the current version is in any way worse than the mainline version, please voice your concerns.

AFAIK, the biggest consumer of BigInteger in JDK is security area. So, I assume a good way to judge this change is to run security benchmarks to make sure they haven't slipped.

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

PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1621705028

From clanger at openjdk.org  Wed Jul  5 13:53:58 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 5 Jul 2023 13:53:58 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v3]
In-Reply-To: <hz2VoLHbP2n0_RAq1krcyEIlrHwRN0yHdeX5MCKylMg=.b35456f5-6ee6-4007-a575-4ddd8ea7f465@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <hz2VoLHbP2n0_RAq1krcyEIlrHwRN0yHdeX5MCKylMg=.b35456f5-6ee6-4007-a575-4ddd8ea7f465@github.com>
Message-ID: <ubqaW-6fAyiJbYVbziD0X5vER4bMyP_1qBXmDDoeEdg=.51cfaf72-603e-443c-b2db-8c6bc5ff0215@github.com>

On Fri, 30 Jun 2023 11:37:10 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.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove import

Looks good overall. I made a few suggestions.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach024/TestDescription.java line 40:

> 38:  *     Agent's JAR file contains modified class java.util.TooManyListenersException (it is assumed
> 39:  *     that this class isn't loaded before agent is loaded), agent instantiates TooManyListenersException
> 40:  *     and checks that non-modified version of this class was loaded from jdk image (not from agent's JAR).

"from the jdk image"

test/jdk/com/sun/tools/attach/ProviderTest.java line 110:

> 108:         public static void main(String args[]) throws Exception {
> 109:             // deal with internal builds where classes are loaded from the
> 110:             // 'classes' directory rather than the image modules file

"... rather than the runtime image"

test/langtools/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java line 27:

> 25:  * @test
> 26:  * @bug 4798312
> 27:  * @summary In Windows, javap doesn't load classes from image

"... from the runtime image"

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

Changes requested by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14593#pullrequestreview-1514576016
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1253140142
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1253141204
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1253142105

From clanger at openjdk.org  Wed Jul  5 13:54:01 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 5 Jul 2023 13:54:01 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v3]
In-Reply-To: <ggJTRFLg4cRBkeXkY_gGOQPI8dBTg_PTbto4yhl0Rp8=.6335d5a3-9653-48d6-886b-61851ac31014@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <RhyKQERReuok9CVTDMV57hGRtnfTtUnKMEWfVLKQepQ=.afa0d7fb-99a5-486d-83e1-db7cbfbf7ccf@github.com>
 <ggJTRFLg4cRBkeXkY_gGOQPI8dBTg_PTbto4yhl0Rp8=.6335d5a3-9653-48d6-886b-61851ac31014@github.com>
Message-ID: <Kl7Oa4UKUteVNTsTijnPc1q3tiNojlxtwldtJdUcXfU=.70212614-1ffa-4487-9d09-b4fe97b26612@github.com>

On Thu, 22 Jun 2023 09:21:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> 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 ?

maybe "... to the current runtime."?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1253139297

From rriggs at openjdk.org  Wed Jul  5 14:08:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Jul 2023 14:08:55 GMT
Subject: RFR: 8311290: Improve java.lang.ref.Cleaner rendered documentation
In-Reply-To: <-CJKywK-ap6b24sv5195VMvViQ8k0EGz2quYvTfSHLk=.eeb06202-951c-4937-9110-991988bb7d4a@github.com>
References: <-CJKywK-ap6b24sv5195VMvViQ8k0EGz2quYvTfSHLk=.eeb06202-951c-4937-9110-991988bb7d4a@github.com>
Message-ID: <_DHLPGiQjBPkzS3bkDeRCqx7eUtY352s0ygkVT3ikjY=.2ea9bfe2-0504-4f45-9059-9a061e27998c@github.com>

On Tue, 4 Jul 2023 12:40:26 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> 1. Missing leading asterisk interferes with example indentation; nothing in https://bugs.openjdk.org/browse/JDK-8276700 (or review thereof), which introduced that line, suggests that the asterisk was omitted on purpose. 
> 2. link and linkplain tags are used suboptimally.

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14768#pullrequestreview-1514614451

From prappo at openjdk.org  Wed Jul  5 14:14:04 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 5 Jul 2023 14:14:04 GMT
Subject: Integrated: 8311290: Improve java.lang.ref.Cleaner rendered
 documentation
In-Reply-To: <-CJKywK-ap6b24sv5195VMvViQ8k0EGz2quYvTfSHLk=.eeb06202-951c-4937-9110-991988bb7d4a@github.com>
References: <-CJKywK-ap6b24sv5195VMvViQ8k0EGz2quYvTfSHLk=.eeb06202-951c-4937-9110-991988bb7d4a@github.com>
Message-ID: <hSCARoVrU1voWtGXkhpkkqUSiY8phbb0VrK0oRbUfEk=.b5cd3bc9-99dc-473b-9e10-b189a8618b5f@github.com>

On Tue, 4 Jul 2023 12:40:26 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> 1. Missing leading asterisk interferes with example indentation; nothing in https://bugs.openjdk.org/browse/JDK-8276700 (or review thereof), which introduced that line, suggests that the asterisk was omitted on purpose. 
> 2. link and linkplain tags are used suboptimally.

This pull request has now been integrated.

Changeset: 2cffef21
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2cffef21201c3e8be87c92234712839bff531047
Stats:     9 lines in 1 file changed: 1 ins; 0 del; 8 mod

8311290: Improve java.lang.ref.Cleaner rendered documentation

Reviewed-by: rriggs

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

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

From ecaspole at openjdk.org  Wed Jul  5 14:41:55 2023
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 5 Jul 2023 14:41:55 GMT
Subject: RFR: 8311178: JMH tests don't scale well when sharing output
 buffers
In-Reply-To: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
References: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
Message-ID: <zBS1EIi8Z8kz5Q_eBL4XopFXbBu-vSZzlN9MbxYEQ8s=.d8f65f69-5ed8-4584-b8df-b1fcb124a25c@github.com>

On Sat, 1 Jul 2023 07:53:17 GMT, Swati Sharma <duke at openjdk.org> wrote:

> The below benchmark files have scaling issues due to cache contention and leads to poor scaling when run on multiple threads. The patch sets the scope from benchmark level to thread level to fix the issue:
> - org/openjdk/bench/java/io/DataOutputStreamTest.java
> - org/openjdk/bench/java/lang/ArrayCopyObject.java
> - org/openjdk/bench/java/lang/ArrayFiddle.java
> - org/openjdk/bench/java/time/format/DateTimeFormatterBench.java
> - org/openjdk/bench/jdk/incubator/vector/IndexInRangeBenchmark.java
> - org/openjdk/bench/jdk/incubator/vector/MemorySegmentVectorAccess.java
> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedBenchmark.java
> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedIOOBEBenchmark.java
> - org/openjdk/bench/vm/compiler/ArrayFill.java
> - org/openjdk/bench/vm/compiler/IndexVector.java
> 
> Also removing the static scope for variables in org/openjdk/bench/jdk/incubator/vector/VectorFPtoIntCastOperations.java for better scaling.
> 
> Please review and share your feedback.
> 
> Thanks,
> Swati

LGTM.
Eric

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

Marked as reviewed by ecaspole (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14746#pullrequestreview-1514692914

From shade at openjdk.org  Wed Jul  5 14:43:56 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Jul 2023 14:43:56 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() can throw if invoked
 reflectively
In-Reply-To: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
Message-ID: <f8yJSmGX8kBlm5S1cLD9jHigyaUfxQGeaSh29dYO8Rg=.faa75f06-427b-464f-990c-cd6c9f474ee9@github.com>

On Wed, 5 Jul 2023 11:45:59 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> As the included jtreg test demonstrates, `StackWalker.getCallerClass()` can throw an `UnsupportedOperationException` if called reflectively. Currently this only happens if we invoke `StackWalker.getCallerClass()` recursively reflectively, but this issue will become more prominent once we fix [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447).

Neither PR nor the bug describes what the root cause it, so it is very hard to see if patch makes sense. Please describe the problem and solution briefly?

src/hotspot/share/prims/stackwalk.cpp line 168:

> 166:                               int max_nframes, int start_index,
> 167:                               objArrayHandle  frames_array,
> 168:                               int& end_index, bool firstBatch, TRAPS) {

The style is `is_first_batch`.

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

PR Review: https://git.openjdk.org/jdk/pull/14773#pullrequestreview-1514691062
PR Review Comment: https://git.openjdk.org/jdk/pull/14773#discussion_r1253212866

From rriggs at openjdk.org  Wed Jul  5 15:04:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Jul 2023 15:04:57 GMT
Subject: RFR: 8310999: Add @since info in jdk.jsobject files
Message-ID: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>

Source code cleanup.
Add @since, remove unused imports and remove unnecessary SuppressWarnings of deprecation.

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

Commit messages:
 - 8310999: Add @since info in jdk.jsobject files

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

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

From mbaesken at openjdk.org  Wed Jul  5 15:07:15 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Jul 2023 15:07:15 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v4]
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <C4Bimt6SEUdL7KSK5tk64Q5zxRTWr5PvT_PTpEaMx3I=.d56fba5b-e89c-46d8-9b7f-488a6c559fe1@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 comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14593/files
  - new: https://git.openjdk.org/jdk/pull/14593/files/9b2232a7..3a7b057a

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

  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 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 Jul  5 15:07:16 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 5 Jul 2023 15:07:16 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v4]
In-Reply-To: <C4Bimt6SEUdL7KSK5tk64Q5zxRTWr5PvT_PTpEaMx3I=.d56fba5b-e89c-46d8-9b7f-488a6c559fe1@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <C4Bimt6SEUdL7KSK5tk64Q5zxRTWr5PvT_PTpEaMx3I=.d56fba5b-e89c-46d8-9b7f-488a6c559fe1@github.com>
Message-ID: <ilbUZTTFeWpuxDgfjIAm8V_mHGN6dB7fzOT_LyjRg00=.6cd9a766-600c-4cdf-b9b5-f43593181d5e@github.com>

On Wed, 5 Jul 2023 15:01:52 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.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust comments

Fine from my end now. Just one minor nit left. ?

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 to the current runtime

You should bring back the period at the end of the sentence.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14593#pullrequestreview-1514740197
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1253244166

From mbaesken at openjdk.org  Wed Jul  5 15:07:17 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Jul 2023 15:07:17 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v3]
In-Reply-To: <hz2VoLHbP2n0_RAq1krcyEIlrHwRN0yHdeX5MCKylMg=.b35456f5-6ee6-4007-a575-4ddd8ea7f465@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <hz2VoLHbP2n0_RAq1krcyEIlrHwRN0yHdeX5MCKylMg=.b35456f5-6ee6-4007-a575-4ddd8ea7f465@github.com>
Message-ID: <Mmx3ALXzgyehKSzS46dg6O6_E5jgT3Qh6PGdgdjCgWo=.9c92adab-f6a2-45b2-acb9-c5acfdc3f088@github.com>

On Fri, 30 Jun 2023 11:37:10 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.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove import

Hi  Christoph, thanks for the suggestions, I added some changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/14593#issuecomment-1621939153

From roger.riggs at oracle.com  Wed Jul  5 15:18:20 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 5 Jul 2023 11:18:20 -0400
Subject: Adapt ArrayList Javadoc for sequenced collections
In-Reply-To: <9bcb8f8e-ac95-1403-c64a-1b7371835152@wwwmaster.at>
References: <cb0f6d03-ce36-44d9-fc50-8e4b352731f1@wwwmaster.at>
 <9bcb8f8e-ac95-1403-c64a-1b7371835152@wwwmaster.at>
Message-ID: <5486e8e6-d600-187d-5370-b69dc7cc198c@oracle.com>

Hi Daniel,

Core-libs-dev is indeed the correct alias for this documentation issue.

Create an issue to track: JDK-8311517 
<https://bugs.openjdk.org/browse/JDK-8311517>

Regards, Roger

On 7/1/23 3:35 PM, Daniel Schmid wrote:

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.

I originally posted this in the core-libs-dev mailing list 
(https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html) 
but it seems like that mail has been overlooked due to the amount of 
other content with PRs etc. there.

Yours,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230705/c7a332c3/attachment-0001.htm>

From lancea at openjdk.org  Wed Jul  5 15:44:54 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 5 Jul 2023 15:44:54 GMT
Subject: RFR: 8310999: Add @since info in jdk.jsobject files
In-Reply-To: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
References: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
Message-ID: <tLMsGn7jg5CrRFEAH26eLhKXy6b_510bzotnV6LjzWs=.36cbdd1b-580f-42b5-85db-242088562d67@github.com>

On Wed, 5 Jul 2023 14:51:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Source code cleanup.
> Add @since, remove unused imports and remove unnecessary SuppressWarnings of deprecation.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14775#pullrequestreview-1514831003

From bpb at openjdk.org  Wed Jul  5 15:53:56 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 5 Jul 2023 15:53:56 GMT
Subject: RFR: 8311489: Remove unused dirent_md files
In-Reply-To: <0cdWgqaIhjUcLYTTHj5rHlAga6r3Uj2hOSfg8I8SOEM=.6be0b071-9421-43c7-8b77-e8e79486155c@github.com>
References: <0cdWgqaIhjUcLYTTHj5rHlAga6r3Uj2hOSfg8I8SOEM=.6be0b071-9421-43c7-8b77-e8e79486155c@github.com>
Message-ID: <iKL3K6Msa1uC3gckXyoRoi6JqHCROSU-zRQz-gf-168=.4da5071f-18c3-4f9e-b7fa-7df21777e149@github.com>

On Wed, 5 Jul 2023 10:21:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The methods declared in dirent_md are not used in libjava and not exported. They should be removed.

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14772#pullrequestreview-1514847033

From rriggs at openjdk.org  Wed Jul  5 15:57:59 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Jul 2023 15:57:59 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text
In-Reply-To: <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
 <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
 <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
Message-ID: <yFxgKKwY3_83gXHrJtjTdGoqE-0fVv3sPpu_XdDBjgE=.1cc447b5-776f-478a-9aa6-e822505131f6@github.com>

On Tue, 4 Jul 2023 22:03:58 GMT, John R Rose <jrose at openjdk.org> wrote:

>>> Hmm, I think that issue refers to code that have explicit non-Object parameter types (like `X::equals(Object)boolean` in the issue's sample). This method already have both arguments as `Object`, so I don't think there's any type-specific inlining opportunities.
>> 
>> If that's true, then perhaps those (and some other) locations got that idea wrong:
>> * https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/Collections.java#L5712-L5719
>> * https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/AbstractMap.java#L577-L585
>> 
>> Maybe @rose00 could clarify that? 
>> 
>> FWIW, I also note that `HashMap` does not use similar private static methods; it uses `Objects.equals(Object, Object)` and `Objects.hashCode` overloads that take parameters.
>
> I wrote a little case study on `Objects::equals` that talks about how it should optimize, when it does, why it doesn?t, and how (maybe) to fix that.
> 
> https://cr.openjdk.org/~jrose/jvm/equals-profile.html
> https://cr.openjdk.org/~jrose/jvm/equals-profile.md
> 
> This is also attached to the JBS bug.
> 
> The work on [JDK-8026251](https://bugs.openjdk.org/browse/JDK-8026251) with the `TypeProfileLevel` switch bring us closer to correctly optimizing `Objects::equals` in more cases.  Sadly, JDK refactoring by itself will not get all the way to where we want to go.  The JVM?s profiling logic needs tweaking.

I'd suggest replacing the calls to `valuesMatch` with `Objects.equals` and remove the `valuesMatch` method as unnecessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1253289975

From rriggs at openjdk.org  Wed Jul  5 15:57:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Jul 2023 15:57:57 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>

On Mon, 3 Jul 2023 11:12:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in the java.text area.
> 
> * Some changes to `equals` and `hashCode` are refactoring rather than modernization. Such changes can be as trivial as rearranging, adding, or commenting checks.
> 
> * java.text area contains more classes whose `equals` and `hashCode` could be simplified; for example: sun.text.CompactByteArray or java.text.DigitList. However, I found no evidence of `equals` and `hashCode` in those classes being used in source or tests. Since writing new tests in this case seems unreasonable, I **excluded** those classes from this PR.

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/java/text/CompactNumberFormat.java line 2364:

> 2362:             return true;
> 2363:         }
> 2364: 

Moving this before the `super.equals` call  performance-wise would favor the equals case. (statistics not available guess)

The code style in these files favors `if (this == obj)`... over the swapped order of arguments.

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

> 2924:         if (obj == this) { // disambiguate super equality from ref equality
> 2925:             return true;
> 2926:         }

Ditto comment in CompactNumberFormat.

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

> 2928:         DecimalFormat other = (DecimalFormat) obj;
> 2929:         return ((posPrefixPattern == other.posPrefixPattern &&
> 2930:                  positivePrefix.equals(other.positivePrefix))

This might also be:

return (obj instanceof DecimalFormat other) && 
                 posPrefixPattern == other.posPrefixPattern &&
                 positivePrefix.equals(other.positivePrefix));

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

PR Review: https://git.openjdk.org/jdk/pull/14752#pullrequestreview-1514810525
PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1253309018
PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1253310120
PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1253317064

From joehw at openjdk.org  Wed Jul  5 16:00:04 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 5 Jul 2023 16:00:04 GMT
Subject: RFR: 8310999: Add @since info in jdk.jsobject files
In-Reply-To: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
References: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
Message-ID: <dLunlI-vDwzYJg5DiHxK5C-11GE5oQUBux9a9zFdQt8=.056c1064-8308-4bb6-9440-6d9187d335e5@github.com>

On Wed, 5 Jul 2023 14:51:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Source code cleanup.
> Add @since, remove unused imports and remove unnecessary SuppressWarnings of deprecation.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14775#pullrequestreview-1514853322

From bpb at openjdk.org  Wed Jul  5 16:00:06 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 5 Jul 2023 16:00:06 GMT
Subject: RFR: 8310999: Add @since info in jdk.jsobject files
In-Reply-To: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
References: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
Message-ID: <Sg-9a4F7fXGzmTn5FdSx47f0rMR6_b8-GzgcNkAeN88=.1a90f5c5-0706-4b3c-8f92-9cf8e1b0b63d@github.com>

On Wed, 5 Jul 2023 14:51:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Source code cleanup.
> Add @since, remove unused imports and remove unnecessary SuppressWarnings of deprecation.

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14775#pullrequestreview-1514857272

From iris at openjdk.org  Wed Jul  5 16:00:07 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 5 Jul 2023 16:00:07 GMT
Subject: RFR: 8310999: Add @since info in jdk.jsobject files
In-Reply-To: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
References: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
Message-ID: <nIWRmwuFbbF5WMIBbBR9Gfm7300goZjpH3XEJxd4VRM=.6b213cff-7836-492c-8235-49e31e525c8c@github.com>

On Wed, 5 Jul 2023 14:51:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Source code cleanup.
> Add @since, remove unused imports and remove unnecessary SuppressWarnings of deprecation.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14775#pullrequestreview-1514859373

From mchung at openjdk.org  Wed Jul  5 16:03:10 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 5 Jul 2023 16:03:10 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v20]
In-Reply-To: <yPyS40bQO6_Okx38j7oNZ5PoFtHcj3xihrcaWJ8XF1s=.21d3611f-9859-4752-b405-b366dd2c64d9@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <hf1xG7bL3h5eNL7G5HMcj39OT31KhqHRNS-QmnyuwTQ=.118cf71b-5df9-429c-b435-93dc87968515@github.com>
 <rNliqJl6CKnlyXP226Any7ZoBeHmjaKzO65JYiC8O9Q=.1ddae1a6-bf0b-45a0-853c-6b51881bdf5d@github.com>
 <z50FP_6tYBl98sBqUj-9fotNsSRfZxp4VDe5mgMPjZQ=.dd988437-bb10-4de2-b476-8c4b0063d608@github.com>
 <yPyS40bQO6_Okx38j7oNZ5PoFtHcj3xihrcaWJ8XF1s=.21d3611f-9859-4752-b405-b366dd2c64d9@github.com>
Message-ID: <Hp3hILBdbNg1oIrj8RHv235kTx_qjhydiG73Nwbl6Vs=.88948bf0-03d4-45e3-a5b4-b8f0becbf6b3@github.com>

On Tue, 4 Jul 2023 21:35:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> If multiple threads race to create a new proxy lookup here, they will all get a distinct lookup returned to them. I think this is okay? Though, it would mean we have less sharing of proxy classes.

yes, that's okay.  We can also do what you suggest to synchronize on `r`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1253325517

From prr at openjdk.org  Wed Jul  5 16:07:58 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Jul 2023 16:07:58 GMT
Subject: RFR: 8310999: Add @since info in jdk.jsobject files
In-Reply-To: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
References: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
Message-ID: <O5f5zd4tczPJnY2R77ONBmY0JBlljO4YG8Ilhhf0Rjc=.91c0e7da-f302-4c48-bb2d-d74949d0414c@github.com>

On Wed, 5 Jul 2023 14:51:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Source code cleanup.
> Add @since, remove unused imports and remove unnecessary SuppressWarnings of deprecation.

unless my eyes deceive me the suppresswarnings is still present.

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

Changes requested by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14775#pullrequestreview-1514878528

From rriggs at openjdk.org  Wed Jul  5 16:20:07 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Jul 2023 16:20:07 GMT
Subject: RFR: 8310999: Add @since info in jdk.jsobject files [v2]
In-Reply-To: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
References: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
Message-ID: <y2uxmFUheUCKrgiWmETZV5EUUMbZYaJAAqkCEuSLQRY=.a0af3f30-47ce-41e1-a31c-e16ad02ad448@github.com>

> Source code cleanup.
> Add @since, remove unused imports and remove unnecessary SuppressWarnings of deprecation.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove unneeded @SuppressWarnings

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14775/files
  - new: https://git.openjdk.org/jdk/pull/14775/files/f63e9e9c..72333076

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

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

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

From rriggs at openjdk.org  Wed Jul  5 16:20:08 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Jul 2023 16:20:08 GMT
Subject: RFR: 8310999: Add @since info in jdk.jsobject files [v2]
In-Reply-To: <O5f5zd4tczPJnY2R77ONBmY0JBlljO4YG8Ilhhf0Rjc=.91c0e7da-f302-4c48-bb2d-d74949d0414c@github.com>
References: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
 <O5f5zd4tczPJnY2R77ONBmY0JBlljO4YG8Ilhhf0Rjc=.91c0e7da-f302-4c48-bb2d-d74949d0414c@github.com>
Message-ID: <wJld7NPxyIpBGaX8gsL21WcOUVi-n9MRUeYHBSOwBSE=.e182d763-0e7b-422c-9fea-a867f647d8fb@github.com>

On Wed, 5 Jul 2023 16:05:25 GMT, Phil Race <prr at openjdk.org> wrote:

> unless my eyes deceive me the suppresswarnings is still present.

Gack!, I removed it and then put it back to try to discover why it was there in the first place.
Gone again and thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/14775#issuecomment-1622080242

From iris at openjdk.org  Wed Jul  5 16:23:54 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 5 Jul 2023 16:23:54 GMT
Subject: RFR: 8310999: Add @since info in jdk.jsobject files [v2]
In-Reply-To: <y2uxmFUheUCKrgiWmETZV5EUUMbZYaJAAqkCEuSLQRY=.a0af3f30-47ce-41e1-a31c-e16ad02ad448@github.com>
References: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
 <y2uxmFUheUCKrgiWmETZV5EUUMbZYaJAAqkCEuSLQRY=.a0af3f30-47ce-41e1-a31c-e16ad02ad448@github.com>
Message-ID: <9BYBwXANMOrFYDGFwa-o1p0asy1hEFT4PD0bNW_iUrM=.4a6cc12f-2fef-4afb-9aa2-49c8029c6093@github.com>

On Wed, 5 Jul 2023 16:20:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Source code cleanup.
>> Add @since, remove unused imports and remove unnecessary SuppressWarnings of deprecation.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded @SuppressWarnings

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14775#pullrequestreview-1514905287

From prappo at openjdk.org  Wed Jul  5 16:35:11 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 5 Jul 2023 16:35:11 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v2]
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <4pOxaS_C1TBzmH44xKGHlMnKGriFIZT7RNfvU62hY1w=.02d9ea08-365b-4744-8a36-1bce19a393fc@github.com>

> Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in the java.text area.
> 
> * Some changes to `equals` and `hashCode` are refactoring rather than modernization. Such changes can be as trivial as rearranging, adding, or commenting checks.
> 
> * java.text area contains more classes whose `equals` and `hashCode` could be simplified; for example: sun.text.CompactByteArray or java.text.DigitList. However, I found no evidence of `equals` and `hashCode` in those classes being used in source or tests. Since writing new tests in this case seems unreasonable, I **excluded** those classes from this PR.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Adhere to surrounding code style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14752/files
  - new: https://git.openjdk.org/jdk/pull/14752/files/e5497367..b338480e

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

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

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

From prappo at openjdk.org  Wed Jul  5 16:35:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 5 Jul 2023 16:35:13 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v2]
In-Reply-To: <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>
Message-ID: <_5Dma3GpgEds2ywyD4xBZ32Mqmu6NWl4-uv_jQWRBnY=.da3bfa73-2b98-4639-88f0-f6b48dffb2a9@github.com>

On Wed, 5 Jul 2023 15:47:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adhere to surrounding code style
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 2926:
> 
>> 2924:         if (obj == this) { // disambiguate super equality from ref equality
>> 2925:             return true;
>> 2926:         }
> 
> Ditto comment in CompactNumberFormat.

Fixed this and the other one in b338480e540.

> src/java.base/share/classes/java/text/DecimalFormat.java line 2930:
> 
>> 2928:         DecimalFormat other = (DecimalFormat) obj;
>> 2929:         return ((posPrefixPattern == other.posPrefixPattern &&
>> 2930:                  positivePrefix.equals(other.positivePrefix))
> 
> This might also be:
> 
> return (obj instanceof DecimalFormat other) && 
>                  posPrefixPattern == other.posPrefixPattern &&
>                  positivePrefix.equals(other.positivePrefix));

Do you mean we could use `obj instanceof DecimalFormat other` in front of that 30-line `&&` expression, or that we could collapse the list to exactly what you wrote?

Separately, `super.equals` already performs the class check; so enhanced `instanceof` could be used only as a syntactic sugar, but even then it won't decrease the line count: we trade one line for another very similar line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1253358517
PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1253357171

From prappo at openjdk.org  Wed Jul  5 16:42:55 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 5 Jul 2023 16:42:55 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v2]
In-Reply-To: <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>
Message-ID: <jWff4xux0qab4756UxzvazeDXGY_x83TYbnXlEZKVHM=.54a58dc3-c99a-4878-9c51-c2db981b84b0@github.com>

On Wed, 5 Jul 2023 15:46:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adhere to surrounding code style
>
> src/java.base/share/classes/java/text/CompactNumberFormat.java line 2364:
> 
>> 2362:             return true;
>> 2363:         }
>> 2364: 
> 
> Moving this before the `super.equals` call  performance-wise would favor the equals case. (statistics not available guess)
> 
> The code style in these files favors `if (this == obj)`... over the swapped order of arguments.

You are right, I have no stats. Performance-wise, it's already better than what was there before. Before, there was no short-circuit check. But I can go either way; I don't have a strong opinion.

Reusing superclass' equals is not often seen these days (and that code is old), so some amount of overlap is expected. Regardless of whether we rearrange that check or not, if the passed object is not `this`, we end up checking `this == obj` twice: once in super.equals, the other time in here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1253369039

From prappo at openjdk.org  Wed Jul  5 16:50:19 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 5 Jul 2023 16:50:19 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v3]
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <6im2y4KWWzErV1MQU-rs2ufaliio0mE5Rekv9_T9CWc=.f43c6952-2d6d-4be0-ac95-2683b1d61f35@github.com>

> Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in the java.text area.
> 
> * Some changes to `equals` and `hashCode` are refactoring rather than modernization. Such changes can be as trivial as rearranging, adding, or commenting checks.
> 
> * java.text area contains more classes whose `equals` and `hashCode` could be simplified; for example: sun.text.CompactByteArray or java.text.DigitList. However, I found no evidence of `equals` and `hashCode` in those classes being used in source or tests. Since writing new tests in this case seems unreasonable, I **excluded** those classes from this PR.

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

 - Merge branch 'master' into 8311188
 - Adhere to surrounding code style
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14752/files
  - new: https://git.openjdk.org/jdk/pull/14752/files/b338480e..641fb1e5

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

  Stats: 1750 lines in 166 files changed: 747 ins; 349 del; 654 mod
  Patch: https://git.openjdk.org/jdk/pull/14752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14752/head:pull/14752

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

From simonis at openjdk.org  Wed Jul  5 17:25:24 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 5 Jul 2023 17:25:24 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() can throw if invoked
 reflectively [v2]
In-Reply-To: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
Message-ID: <yS8kuYQ-iQzTnhuxiiS7-ifGAlxP_6znBKmKMftKL20=.e71006f6-a38c-4340-9afa-1057e8e5b638@github.com>

> As the included jtreg test demonstrates, `StackWalker.getCallerClass()` can throw an `UnsupportedOperationException` if called reflectively. Currently this only happens if we invoke `StackWalker.getCallerClass()` recursively reflectively, but this issue will become more prominent once we fix [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447). The gory details follow below:
> 
> The protocol between the Java API and the JVM for `StackWalker.getCallerClass()/walk()` is as follows:
> - On the Java side, `StackWalker` calls into `StackStreamFactory` for the real work.
> - For `StackWalker.getCallerClass()` `StackStreamFactory` basically creates a `Class[]` which will be passed down and filled in the JVM. For `StackWalker.walk()` it will normally be a `StackFrameInfo[]` (or a `LiveStackFrameInfo[]` if the internal `ExtendedOption.LOCALS_AND_OPERANDS` option was used).
> - The default size of this arrays is currently `StackStreamFactory.SMALL_BATCH` which is 8 (but see [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447)).
> - `StackStreamFactory` than calls `AbstractStackWalker.callStackWalk()` which is a natively implemented in the VM by `JVM_CallStackWalk()`.
> -  `JVM_CallStackWalk()` calls `StackWalk::walk()` which calls `StackWalk::fetchFirstBatch()` which calls `StackWalk::fill_in_frames()` which walks the stack and fills in the available class/stackframe slots in the passed in array until the array is full or there are no more stack frames,
> - Once  `StackWalk::fill_in_frames()` returns, `StackWalk::fetchFirstBatch()` calls back to Java by invoking `AbstractStackWalker::doStackWalk()` to consume the result.
> - `AbstractStackWalker::doStackWalk()` calls `consumeFrames()` (which is overridden depending on whether we initially called `getCallerClass()` or `walk()`) which consumes the frames until it either finishes (e.g. finds the caller class) or until there are no more frames.
> - In the latter case `consumeFrames()` will call into the the VM again by calling `AbstractStackWalker.fetchStackFrames()` to fetch additional frames from the stack.
> - `AbstractStackWalker.fetchStackFrames()` is implemented by `JVM_MoreStackWalk()` which calls `StackWalk::fetchNextBatch()` which calls `StackWalk::fill_in_frames()` (the same method that already fetched the initial batch of frames).
> 
> Following is a stacktrace of what I've explained so far:
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x143a96a]  StackWalk::fill_in_frames...

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Rename new parameter according to the HS coding conventions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14773/files
  - new: https://git.openjdk.org/jdk/pull/14773/files/7ae5b2b5..1ec6d90b

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

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

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

From simonis at openjdk.org  Wed Jul  5 17:25:24 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 5 Jul 2023 17:25:24 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() can throw if invoked
 reflectively [v2]
In-Reply-To: <f8yJSmGX8kBlm5S1cLD9jHigyaUfxQGeaSh29dYO8Rg=.faa75f06-427b-464f-990c-cd6c9f474ee9@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
 <f8yJSmGX8kBlm5S1cLD9jHigyaUfxQGeaSh29dYO8Rg=.faa75f06-427b-464f-990c-cd6c9f474ee9@github.com>
Message-ID: <xDYuyIsXewSo_IP37yHol7tkIyY9Fk_aRCjeMNN2ZsQ=.fbbacccb-48e7-47c1-8754-e7155f3ac196@github.com>

On Wed, 5 Jul 2023 14:41:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Neither PR nor the bug describes what the root cause it, so it is very hard to see if patch makes sense. Please describe the problem and solution briefly?

Fair enough :)

I've put the details into the initial comment and also renamed the new parameter according to the HS coding conventions.

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

PR Comment: https://git.openjdk.org/jdk/pull/14773#issuecomment-1622176346

From mchung at openjdk.org  Wed Jul  5 17:28:03 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 5 Jul 2023 17:28:03 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v19]
In-Reply-To: <fp9PEVNZNpBwh0yHwPC9-HhI8vbH6pjDxUd29ogWEmw=.796ded42-ba4b-4a02-86a9-08b680110168@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <fp9PEVNZNpBwh0yHwPC9-HhI8vbH6pjDxUd29ogWEmw=.796ded42-ba4b-4a02-86a9-08b680110168@github.com>
Message-ID: <CJuqpdWdrQpn8QNiocm6EuUzVNwYmoNqX8F3ryTIZ7U=.3dbd8f38-7a5f-4001-a6c9-641d25695081@github.com>

On Tue, 4 Jul 2023 11:00:13 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:
> 
>   Refine test to fill DedupSetBuilder

It's looking pretty good. 

About the test, I don't see `ArrayList::add` in the generated bytecode of `sub2-13`.   The dedup string set is used for the targets of qualified exports and opens and uses.   The modifiers set of `requires` is deduplicated but not the required module names.

I assume you want this be backported.  If so, we should give it some baked time after it's integrated to the main line.    I'm okay if you want to extend the test in a follow up.     You can extract the generated class to verify:

$ jimage extract --dir=dir out-jlink/lib/modules
$ javap -p -v dir/java.base/jdk/internal/module/SystemModules$all.class

test/jdk/tools/jlink/JLink100Modules.java line 118:

> 116:         Path bin = binDir.resolve("java");
> 117: 
> 118:         ProcessBuilder processBuilder = new ProcessBuilder(bin.toString(), "-XX:+UnlockDiagnosticVMOptions", "-XX:+BytecodeVerificationLocal", "-m", "bug8240567x/testpackage.JLink100ModulesTest");

please wrap this long line into multiple lines.

test/jdk/tools/jlink/JLink100Modules.java line 123:

> 121:         Process process = processBuilder.start();
> 122:         int exitCode = process.waitFor();
> 123:         if (exitCode != 0) throw new AssertionError("Exit code is not 0");

Suggestion:

        if (exitCode != 0)
             throw new AssertionError("JLink100ModulesTest failed to launch");

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

PR Review: https://git.openjdk.org/jdk/pull/14408#pullrequestreview-1514989193
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1253405169
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1253405958

From prr at openjdk.org  Wed Jul  5 17:28:54 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Jul 2023 17:28:54 GMT
Subject: RFR: 8310999: Add @since info in jdk.jsobject files [v2]
In-Reply-To: <y2uxmFUheUCKrgiWmETZV5EUUMbZYaJAAqkCEuSLQRY=.a0af3f30-47ce-41e1-a31c-e16ad02ad448@github.com>
References: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
 <y2uxmFUheUCKrgiWmETZV5EUUMbZYaJAAqkCEuSLQRY=.a0af3f30-47ce-41e1-a31c-e16ad02ad448@github.com>
Message-ID: <xfZqRLIdxTxdfzfTV3F0JVXOTTGQIBWWFMQ8fzfVtfw=.6104ba98-983a-46ca-9bd4-5dae7507aac7@github.com>

On Wed, 5 Jul 2023 16:20:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Source code cleanup.
>> Add @since, remove unused imports and remove unnecessary SuppressWarnings of deprecation.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded @SuppressWarnings

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14775#pullrequestreview-1515009563

From rriggs at openjdk.org  Wed Jul  5 17:43:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Jul 2023 17:43:03 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v3]
In-Reply-To: <_5Dma3GpgEds2ywyD4xBZ32Mqmu6NWl4-uv_jQWRBnY=.da3bfa73-2b98-4639-88f0-f6b48dffb2a9@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>
 <_5Dma3GpgEds2ywyD4xBZ32Mqmu6NWl4-uv_jQWRBnY=.da3bfa73-2b98-4639-88f0-f6b48dffb2a9@github.com>
Message-ID: <cFabV-5KRjpZOfjT01AWzE6W3GoJtoGGQjeK3u0tVMw=.b1ad96d9-38b0-4fb6-843d-0215e9e359da@github.com>

On Wed, 5 Jul 2023 16:27:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DecimalFormat.java line 2930:
>> 
>>> 2928:         DecimalFormat other = (DecimalFormat) obj;
>>> 2929:         return ((posPrefixPattern == other.posPrefixPattern &&
>>> 2930:                  positivePrefix.equals(other.positivePrefix))
>> 
>> This might also be:
>> 
>> return (obj instanceof DecimalFormat other) && 
>>                  posPrefixPattern == other.posPrefixPattern &&
>>                  positivePrefix.equals(other.positivePrefix));
>
> Do you mean we could use `obj instanceof DecimalFormat other` in front of that 30-line `&&` expression, or that we could collapse the list to exactly what you wrote?
> 
> Separately, `super.equals` already performs the class check; so enhanced `instanceof` could be used only as a syntactic sugar, but even then it won't decrease the line count: we trade one line for another very similar line.

Just what I wrote; I agree its a toss up from lines of code and performance.
I spotted that style in other files and its just a question of style; your choice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1253433196

From rriggs at openjdk.org  Wed Jul  5 17:48:01 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Jul 2023 17:48:01 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v3]
In-Reply-To: <jWff4xux0qab4756UxzvazeDXGY_x83TYbnXlEZKVHM=.54a58dc3-c99a-4878-9c51-c2db981b84b0@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>
 <jWff4xux0qab4756UxzvazeDXGY_x83TYbnXlEZKVHM=.54a58dc3-c99a-4878-9c51-c2db981b84b0@github.com>
Message-ID: <IMTlpOXrBFPrUB2GTutRk-DnT-fqbHYNIww7ZY5lEaU=.7201c806-910b-49ac-acdb-2610eeb7e233@github.com>

On Wed, 5 Jul 2023 16:39:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/CompactNumberFormat.java line 2364:
>> 
>>> 2362:             return true;
>>> 2363:         }
>>> 2364: 
>> 
>> Moving this before the `super.equals` call  performance-wise would favor the equals case. (statistics not available guess)
>> 
>> The code style in these files favors `if (this == obj)`... over the swapped order of arguments.
>
> You are right, I have no stats. Performance-wise, it's already better than what was there before. Before, there was no short-circuit check. But I can go either way; I don't have a strong opinion.
> 
> Reusing superclass' equals is not often seen these days (and that code is old), so some amount of overlap is expected. Regardless of whether we rearrange that check or not, if the passed object is not `this`, we end up checking `this == obj` twice: once in super.equals, the other time in here.

True, there's no simple way to avoid the double check in either the equal or not equal case.
And I don't know enough about the Hotspot compiler to know whether it would spot the duplication and optimize it.
In many `equals` methods, the test for self equality is frequently the first line.
Is fine as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1253438509

From rriggs at openjdk.org  Wed Jul  5 18:25:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Jul 2023 18:25:03 GMT
Subject: Integrated: 8310999: Add @since info in jdk.jsobject files
In-Reply-To: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
References: <8gQI7_4_YHYsTXE_RtGvM3Ko7uL61tcPVASyayTDwEM=.76a23a64-d8b2-4a9e-903f-581eba567c86@github.com>
Message-ID: <EevtNT1LmmVvpFDvnOHYl4PF7MiVo7Klslq1SaAO17Y=.1de966ab-06b1-47db-8585-56940a3483ca@github.com>

On Wed, 5 Jul 2023 14:51:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Source code cleanup.
> Add @since, remove unused imports and remove unnecessary SuppressWarnings of deprecation.

This pull request has now been integrated.

Changeset: 6eba096c
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6eba096ca2e6bf3b7244c632e37b32f2e47b4acc
Stats:     10 lines in 2 files changed: 1 ins; 6 del; 3 mod

8310999: Add @since info in jdk.jsobject files

Reviewed-by: lancea, joehw, bpb, iris, prr

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

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

From rriggs at openjdk.org  Wed Jul  5 18:45:01 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Jul 2023 18:45:01 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v3]
In-Reply-To: <ogWIsIozaQk7aTZ8BaGJcoo8N87re4GiEawCnCVvNT4=.e71655ee-7322-48c2-ab47-077c21a7a576@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <ogWIsIozaQk7aTZ8BaGJcoo8N87re4GiEawCnCVvNT4=.e71655ee-7322-48c2-ab47-077c21a7a576@github.com>
Message-ID: <oSyT1OjSEpM9umKHGOJK_YF-iP9ws_U_Rd-h7ANVNAo=.b7609166-59c6-42ac-8cd2-1608bf32693b@github.com>

On Tue, 4 Jul 2023 12:55:22 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:
> 
>   Update to use VirtualThread friendly stale queue.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14684#pullrequestreview-1515122805

From jvernee at openjdk.org  Wed Jul  5 19:16:13 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 5 Jul 2023 19:16:13 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v20]
In-Reply-To: <Hp3hILBdbNg1oIrj8RHv235kTx_qjhydiG73Nwbl6Vs=.88948bf0-03d4-45e3-a5b4-b8f0becbf6b3@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <hf1xG7bL3h5eNL7G5HMcj39OT31KhqHRNS-QmnyuwTQ=.118cf71b-5df9-429c-b435-93dc87968515@github.com>
 <rNliqJl6CKnlyXP226Any7ZoBeHmjaKzO65JYiC8O9Q=.1ddae1a6-bf0b-45a0-853c-6b51881bdf5d@github.com>
 <z50FP_6tYBl98sBqUj-9fotNsSRfZxp4VDe5mgMPjZQ=.dd988437-bb10-4de2-b476-8c4b0063d608@github.com>
 <yPyS40bQO6_Okx38j7oNZ5PoFtHcj3xihrcaWJ8XF1s=.21d3611f-9859-4752-b405-b366dd2c64d9@github.com>
 <Hp3hILBdbNg1oIrj8RHv235kTx_qjhydiG73Nwbl6Vs=.88948bf0-03d4-45e3-a5b4-b8f0becbf6b3@github.com>
Message-ID: <CSUHNYCkq9FDQRgLc17J1wVO9XtMztl7OrfgImJZmhQ=.7f3e2ae5-20b7-4850-ad2b-ed60278f5230@github.com>

On Wed, 5 Jul 2023 16:00:11 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Ok, thanks. This is similar to the solution I would have suggested.
>> 
>> The only thing I'm unsure about is races. ClassValue allows multiple threads to race to compute the final value, but in the end only 1 is chosen that is returned to all threads.
>> 
>> If multiple threads race to create a new proxy lookup here, they will all get a distinct lookup returned to them. I think this is okay? Though, it would mean we have less sharing of proxy classes.
>> 
>> Maybe this code should synchronize on `r` to make sure only 1 lookup is created per interface. (Letting threads race to compute the value is also a possibility, but it also leads some threads to do work that is then discarded, and then the VM has to clean up the class they defined as well).
>
>> If multiple threads race to create a new proxy lookup here, they will all get a distinct lookup returned to them. I think this is okay? Though, it would mean we have less sharing of proxy classes.
> 
> yes, that's okay.  We can also do what you suggest to synchronize on `r`.

I don't have a strong opinion, but I'm in favor of synchronizing (in a double-checked locking style), because the amount of work that would be discarded in the case of a race would be non-trivial.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1253523585

From mchung at openjdk.org  Wed Jul  5 19:16:53 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 5 Jul 2023 19:16:53 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() can throw if invoked
 reflectively [v2]
In-Reply-To: <yS8kuYQ-iQzTnhuxiiS7-ifGAlxP_6znBKmKMftKL20=.e71006f6-a38c-4340-9afa-1057e8e5b638@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
 <yS8kuYQ-iQzTnhuxiiS7-ifGAlxP_6znBKmKMftKL20=.e71006f6-a38c-4340-9afa-1057e8e5b638@github.com>
Message-ID: <gpNi8d1i2-Hug0LZscTkd5KdfEArVB5XLIXr78miQQM=.adabbd4a-0197-4f50-bc9a-da084223180b@github.com>

On Wed, 5 Jul 2023 17:25:24 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> As the included jtreg test demonstrates, `StackWalker.getCallerClass()` can throw an `UnsupportedOperationException` if called reflectively. Currently this only happens if we invoke `StackWalker.getCallerClass()` recursively reflectively, but this issue will become more prominent once we fix [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447). The gory details follow below:
>> 
>> The protocol between the Java API and the JVM for `StackWalker.getCallerClass()/walk()` is as follows:
>> - On the Java side, `StackWalker` calls into `StackStreamFactory` for the real work.
>> - For `StackWalker.getCallerClass()` `StackStreamFactory` basically creates a `Class[]` which will be passed down and filled in the JVM. For `StackWalker.walk()` it will normally be a `StackFrameInfo[]` (or a `LiveStackFrameInfo[]` if the internal `ExtendedOption.LOCALS_AND_OPERANDS` option was used).
>> - The default size of this arrays is currently `StackStreamFactory.SMALL_BATCH` which is 8 (but see [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447)).
>> - `StackStreamFactory` than calls `AbstractStackWalker.callStackWalk()` which is a natively implemented in the VM by `JVM_CallStackWalk()`.
>> -  `JVM_CallStackWalk()` calls `StackWalk::walk()` which calls `StackWalk::fetchFirstBatch()` which calls `StackWalk::fill_in_frames()` which walks the stack and fills in the available class/stackframe slots in the passed in array until the array is full or there are no more stack frames,
>> - Once  `StackWalk::fill_in_frames()` returns, `StackWalk::fetchFirstBatch()` calls back to Java by invoking `AbstractStackWalker::doStackWalk()` to consume the result.
>> - `AbstractStackWalker::doStackWalk()` calls `consumeFrames()` (which is overridden depending on whether we initially called `getCallerClass()` or `walk()`) which consumes the frames until it either finishes (e.g. finds the caller class) or until there are no more frames.
>> - In the latter case `consumeFrames()` will call into the the VM again by calling `AbstractStackWalker.fetchStackFrames()` to fetch additional frames from the stack.
>> - `AbstractStackWalker.fetchStackFrames()` is implemented by `JVM_MoreStackWalk()` which calls `StackWalk::fetchNextBatch()` which calls `StackWalk::fill_in_frames()` (the same method that already fetched the initial batch of frames).
>> 
>> Following is a stacktrace of what I've explained so far:
>> 
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x1...
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename new parameter according to the HS coding conventions

Thanks for catching this issue.    I agree that `Method::invoke` should be skipped the caller-sensitive test in this case but the fix isn't quite right.    The caller-sensitive test should apply in any batch.    For example, `CSM` calls `getCallerClass` reflectively, I think the stack would look like this:


java.lang.StackWalker::getCallerClass
java.lang.invoke.DirectMethodHandle$Holder::invokeStatic
java.lang.invoke.LambdaForm$MH/0x0000000800002c00::invoke
:
:
jdk.internal.reflect.DirectMethodHandleAccessor::invokeImpl
jdk.internal.reflect.DirectMethodHandleAccessor::invoke
java.lang.reflect.Method::invoke
CSM  <--------- caller-sensitive method and UOE should be thrown



In this case, UOE should be thrown.

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

PR Comment: https://git.openjdk.org/jdk/pull/14773#issuecomment-1622325630

From duke at openjdk.org  Wed Jul  5 19:22:27 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 5 Jul 2023 19:22:27 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v20]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <sSQVbaoVbuSkiHXOGwBqaq0rDu97HQNVduynil7ZSEE=.1bb2ad87-2ac3-463b-8883-56e5280a4be9@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:

  Update test/jdk/tools/jlink/JLink100Modules.java
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14408/files
  - new: https://git.openjdk.org/jdk/pull/14408/files/15d7448b..8d02911b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=18-19

  Stats: 2 lines in 1 file changed: 1 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 mchung at openjdk.org  Wed Jul  5 19:35:57 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 5 Jul 2023 19:35:57 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v3]
In-Reply-To: <ogWIsIozaQk7aTZ8BaGJcoo8N87re4GiEawCnCVvNT4=.e71655ee-7322-48c2-ab47-077c21a7a576@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <ogWIsIozaQk7aTZ8BaGJcoo8N87re4GiEawCnCVvNT4=.e71655ee-7322-48c2-ab47-077c21a7a576@github.com>
Message-ID: <WcRkPWHPUjKn_Fn_tclAvnugUciHaRn3CrdyW2gI_7M=.0c9adb60-83bd-40e2-bc23-06fd80e4722c@github.com>

On Tue, 4 Jul 2023 12:55:22 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:
> 
>   Update to use VirtualThread friendly stale queue.

`WeakReferenceKey::equals` and `SoftReferenceKey::equals`:

Instead of `return Objects.equals(get(), obj);`, suggest to do:


    return refersTo(obj);

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

PR Review: https://git.openjdk.org/jdk/pull/14684#pullrequestreview-1515202443

From prappo at openjdk.org  Wed Jul  5 20:09:55 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 5 Jul 2023 20:09:55 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v3]
In-Reply-To: <cFabV-5KRjpZOfjT01AWzE6W3GoJtoGGQjeK3u0tVMw=.b1ad96d9-38b0-4fb6-843d-0215e9e359da@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>
 <_5Dma3GpgEds2ywyD4xBZ32Mqmu6NWl4-uv_jQWRBnY=.da3bfa73-2b98-4639-88f0-f6b48dffb2a9@github.com>
 <cFabV-5KRjpZOfjT01AWzE6W3GoJtoGGQjeK3u0tVMw=.b1ad96d9-38b0-4fb6-843d-0215e9e359da@github.com>
Message-ID: <1fCuDas6gnda96PDU_iXDA6RcKm7jIs8LMYo5PffEwc=.7646081f-e335-4c46-9681-0eaf78ddad9e@github.com>

On Wed, 5 Jul 2023 17:39:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Do you mean we could use `obj instanceof DecimalFormat other` in front of that 30-line `&&` expression, or that we could collapse the list to exactly what you wrote?
>> 
>> Separately, `super.equals` already performs the class check; so enhanced `instanceof` could be used only as a syntactic sugar, but even then it won't decrease the line count: we trade one line for another very similar line.
>
> Just what I wrote; I agree its a toss up from lines of code and performance.
> I spotted that style in other files and its just a question of style; your choice.

I see. We are likely on the same page. My guess is that you saw incomplete source in "Files changed" on GitHub. In reality, that return statement spans 30 lines. I was initially confused by that trailing semicolon in your suggestion; I thought you propose to remove everything but those three lines, hence my question.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1253594304

From duke at openjdk.org  Wed Jul  5 22:43:14 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 5 Jul 2023 22:43:14 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v21]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <sP4JnpjuDaQgfmw3MuqmOGFz3NwLyZ-5pITudiPt-8M=.75284dca-ff59-426d-a61e-848d36bfecf0@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 pull request now contains 30 commits:

 - Merge remote-tracking branch 'upstream/master' into fix-8240567
 - Reformat
 - Update test/jdk/tools/jlink/JLink100Modules.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Refine test to fill DedupSetBuilder
 - Merge remote-tracking branch 'upstream/master' into fix-8240567
 - Replace non-final wrapper by local variable
 - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Refine comment
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - ... and 20 more: https://git.openjdk.org/jdk/compare/66d27365...e112f03a

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

Changes: https://git.openjdk.org/jdk/pull/14408/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=20
  Stats: 287 lines in 3 files changed: 268 ins; 1 del; 18 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 Jul  5 23:32:56 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 5 Jul 2023 23:32:56 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v19]
In-Reply-To: <CJuqpdWdrQpn8QNiocm6EuUzVNwYmoNqX8F3ryTIZ7U=.3dbd8f38-7a5f-4001-a6c9-641d25695081@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <fp9PEVNZNpBwh0yHwPC9-HhI8vbH6pjDxUd29ogWEmw=.796ded42-ba4b-4a02-86a9-08b680110168@github.com>
 <CJuqpdWdrQpn8QNiocm6EuUzVNwYmoNqX8F3ryTIZ7U=.3dbd8f38-7a5f-4001-a6c9-641d25695081@github.com>
Message-ID: <nJtaOmnevHioGemQCIfp25ldjI0ZV_BD2ksZp3CJKmk=.a4f1a323-aab6-4c61-bba4-3aee348648c9@github.com>

On Wed, 5 Jul 2023 17:25:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> It's looking pretty good.

Thank you!

> About the test, I don't see `ArrayList::add` in the generated bytecode of `sub2-13`. The dedup string set is used for the targets of qualified exports and opens and uses. The modifiers set of `requires` is deduplicated but not the required module names.

Thank you for the hint.

> I assume you want this be backported. If so, we should give it some baked time after it's integrated to the main line.

Sounds great!

> I'm okay if you want to extend the test in a follow up. 

That would be great. Will take time to craft a proper setting.

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

PR Comment: https://git.openjdk.org/jdk/pull/14408#issuecomment-1622680550

From mchung at openjdk.org  Wed Jul  5 23:42:00 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 5 Jul 2023 23:42:00 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v21]
In-Reply-To: <sP4JnpjuDaQgfmw3MuqmOGFz3NwLyZ-5pITudiPt-8M=.75284dca-ff59-426d-a61e-848d36bfecf0@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <sP4JnpjuDaQgfmw3MuqmOGFz3NwLyZ-5pITudiPt-8M=.75284dca-ff59-426d-a61e-848d36bfecf0@github.com>
Message-ID: <-zAUx2Pg7I2jTOZpg3ZwU1WgR8VqhUSfRW8XjNNszIk=.84e2a184-8e2e-4cab-8d1c-a080eeb05245@github.com>

On Wed, 5 Jul 2023 22:43:14 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 pull request now contains 30 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into fix-8240567
>  - Reformat
>  - Update test/jdk/tools/jlink/JLink100Modules.java
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Refine test to fill DedupSetBuilder
>  - Merge remote-tracking branch 'upstream/master' into fix-8240567
>  - Replace non-final wrapper by local variable
>  - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Refine comment
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/66d27365...e112f03a

I approve this patch.   I'll create a JBS issue to follow up the test update.

test/jdk/tools/jlink/JLink100Modules.java line 75:

> 73:             for (int j = 0; j < i % 20; j++) {
> 74:                 moduleInfoContent.append("  requires module" + j + "x;\n");
> 75:             }

Do you want to keep this change?   or at least take out the comment since this doesn't feed DedupSetBuilder.

Can you add a comment about "the numbers cannot be arbitrarily increased".

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14408#pullrequestreview-1515516921
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1253756746

From liach at openjdk.org  Wed Jul  5 23:53:23 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Jul 2023 23:53:23 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v20]
In-Reply-To: <hf1xG7bL3h5eNL7G5HMcj39OT31KhqHRNS-QmnyuwTQ=.118cf71b-5df9-429c-b435-93dc87968515@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <hf1xG7bL3h5eNL7G5HMcj39OT31KhqHRNS-QmnyuwTQ=.118cf71b-5df9-429c-b435-93dc87968515@github.com>
Message-ID: <rgtmiHAYiinO3iK9x0r7lQr2-bM1FzVC8zeDlyLOWgY=.d2c96ff8-01cc-484c-937b-34318cc9e2da@github.com>

On Sun, 2 Jul 2023 02:05:23 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 44 commits:
> 
>  - Merge branch 'master' into explore/mhp-iface
>  - stage
>    
>    Signed-off-by: liach <liach at users.noreply.github.com>
>  - Review comments
>  - 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
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/0e3d91dc...44e62271

Thank you for the weakreference investigations. Will push an update soon.

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

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

From duke at openjdk.org  Thu Jul  6 00:13:05 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 6 Jul 2023 00:13:05 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v22]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <ticPIAuqoi7aa6zmiCWokw-ksO5hiJ1X12_diLYRE68=.f9e27fa8-5e53-457b-8502-9ba1db7c0e3d@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 pull request now contains 32 commits:

 - Merge remote-tracking branch 'upstream/master' into fix-8240567
 - Revert (non-working) DedupSetBuilder filling
 - Merge remote-tracking branch 'upstream/master' into fix-8240567
 - Reformat
 - Update test/jdk/tools/jlink/JLink100Modules.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Refine test to fill DedupSetBuilder
 - Merge remote-tracking branch 'upstream/master' into fix-8240567
 - Replace non-final wrapper by local variable
 - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - ... and 22 more: https://git.openjdk.org/jdk/compare/d072c40f...584edbae

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

Changes: https://git.openjdk.org/jdk/pull/14408/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=21
  Stats: 286 lines in 3 files changed: 267 ins; 1 del; 18 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  Thu Jul  6 00:13:08 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 6 Jul 2023 00:13:08 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v21]
In-Reply-To: <-zAUx2Pg7I2jTOZpg3ZwU1WgR8VqhUSfRW8XjNNszIk=.84e2a184-8e2e-4cab-8d1c-a080eeb05245@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <sP4JnpjuDaQgfmw3MuqmOGFz3NwLyZ-5pITudiPt-8M=.75284dca-ff59-426d-a61e-848d36bfecf0@github.com>
 <-zAUx2Pg7I2jTOZpg3ZwU1WgR8VqhUSfRW8XjNNszIk=.84e2a184-8e2e-4cab-8d1c-a080eeb05245@github.com>
Message-ID: <2Eoj63NwjNNuyv_JlcREXw0_neVSyptlRKpNYa_wL-o=.8b938c13-b1c4-41f9-babb-2c3d4fa56520@github.com>

On Wed, 5 Jul 2023 23:37:28 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Oliver Kopp has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into fix-8240567
>>  - Reformat
>>  - Update test/jdk/tools/jlink/JLink100Modules.java
>>    
>>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>>  - Refine test to fill DedupSetBuilder
>>  - Merge remote-tracking branch 'upstream/master' into fix-8240567
>>  - Replace non-final wrapper by local variable
>>  - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
>>    
>>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>>  - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
>>    
>>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>>  - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
>>    
>>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>>  - Refine comment
>>    
>>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>>  - ... and 20 more: https://git.openjdk.org/jdk/compare/66d27365...e112f03a
>
> test/jdk/tools/jlink/JLink100Modules.java line 75:
> 
>> 73:             for (int j = 0; j < i % 20; j++) {
>> 74:                 moduleInfoContent.append("  requires module" + j + "x;\n");
>> 75:             }
> 
> Do you want to keep this change?   or at least take out the comment since this doesn't feed DedupSetBuilder.
> 
> Can you add a comment about "the numbers cannot be arbitrarily increased".

I reverted at [`8494517` (#14408)](https://github.com/openjdk/jdk/pull/14408/commits/8494517103c7b303e28c8a8e15fab951b9ea28ea). Think, the comment is then not necessary?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1253771020

From duke at openjdk.org  Thu Jul  6 05:20:14 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 6 Jul 2023 05:20:14 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v3]
In-Reply-To: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
References: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
Message-ID: <qj2QzoxFNnxHTsUfNhVodTgagWMsYKJdE5UgYcEN3Bw=.f1035c20-249b-478e-8003-5af0906ec34d@github.com>

> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.StringUpperLower.*"
> 
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
> +StringUpperLower.lowerToLo...

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

  add method CharacterDataLatin1#isLowerCaseEx

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14751/files
  - new: https://git.openjdk.org/jdk/pull/14751/files/47c4bb03..bc03c99a

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

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

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

From dholmes at openjdk.org  Thu Jul  6 07:19:01 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Jul 2023 07:19:01 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() can throw if invoked
 reflectively [v2]
In-Reply-To: <yS8kuYQ-iQzTnhuxiiS7-ifGAlxP_6znBKmKMftKL20=.e71006f6-a38c-4340-9afa-1057e8e5b638@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
 <yS8kuYQ-iQzTnhuxiiS7-ifGAlxP_6znBKmKMftKL20=.e71006f6-a38c-4340-9afa-1057e8e5b638@github.com>
Message-ID: <M_BgGUi9gYYTy6o-4fMmF6UkZK3FHNveFulEvWeD37A=.ce0f74b6-7c6d-4cca-8b4b-60b64a1685e4@github.com>

On Wed, 5 Jul 2023 17:25:24 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> As the included jtreg test demonstrates, `StackWalker.getCallerClass()` can throw an `UnsupportedOperationException` if called reflectively. Currently this only happens if we invoke `StackWalker.getCallerClass()` recursively reflectively, but this issue will become more prominent once we fix [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447). The gory details follow below:
>> 
>> The protocol between the Java API and the JVM for `StackWalker.getCallerClass()/walk()` is as follows:
>> - On the Java side, `StackWalker` calls into `StackStreamFactory` for the real work.
>> - For `StackWalker.getCallerClass()` `StackStreamFactory` basically creates a `Class[]` which will be passed down and filled in the JVM. For `StackWalker.walk()` it will normally be a `StackFrameInfo[]` (or a `LiveStackFrameInfo[]` if the internal `ExtendedOption.LOCALS_AND_OPERANDS` option was used).
>> - The default size of this arrays is currently `StackStreamFactory.SMALL_BATCH` which is 8 (but see [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447)).
>> - `StackStreamFactory` than calls `AbstractStackWalker.callStackWalk()` which is a natively implemented in the VM by `JVM_CallStackWalk()`.
>> -  `JVM_CallStackWalk()` calls `StackWalk::walk()` which calls `StackWalk::fetchFirstBatch()` which calls `StackWalk::fill_in_frames()` which walks the stack and fills in the available class/stackframe slots in the passed in array until the array is full or there are no more stack frames,
>> - Once  `StackWalk::fill_in_frames()` returns, `StackWalk::fetchFirstBatch()` calls back to Java by invoking `AbstractStackWalker::doStackWalk()` to consume the result.
>> - `AbstractStackWalker::doStackWalk()` calls `consumeFrames()` (which is overridden depending on whether we initially called `getCallerClass()` or `walk()`) which consumes the frames until it either finishes (e.g. finds the caller class) or until there are no more frames.
>> - In the latter case `consumeFrames()` will call into the the VM again by calling `AbstractStackWalker.fetchStackFrames()` to fetch additional frames from the stack.
>> - `AbstractStackWalker.fetchStackFrames()` is implemented by `JVM_MoreStackWalk()` which calls `StackWalk::fetchNextBatch()` which calls `StackWalk::fill_in_frames()` (the same method that already fetched the initial batch of frames).
>> 
>> Following is a stacktrace of what I've explained so far:
>> 
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x1...
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename new parameter according to the HS coding conventions

src/hotspot/share/prims/stackwalk.cpp line 501:

> 499:     KeepStackGCProcessedMark keep_stack(THREAD);
> 500:     numFrames = fill_in_frames(mode, stream, frame_count, start_index,
> 501:                                frames_array, end_index, true, CHECK_NULL);

Could you annotate the new argument please ie. `true /* first batch */` and `false /* not first batch */`. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14773#discussion_r1254033569

From mbaesken at openjdk.org  Thu Jul  6 07:35:10 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Jul 2023 07:35:10 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v5]
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <98WmwQW2HwA0y6V4kHm-Mz75WifXcX1R6eKMq-jQyjU=.b07ce857-c2d1-46cb-9dc5-0dd075ad8dd4@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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14593/files
  - new: https://git.openjdk.org/jdk/pull/14593/files/3a7b057a..f29c4019

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Thu Jul  6 07:35:11 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Jul 2023 07:35:11 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v4]
In-Reply-To: <C4Bimt6SEUdL7KSK5tk64Q5zxRTWr5PvT_PTpEaMx3I=.d56fba5b-e89c-46d8-9b7f-488a6c559fe1@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <C4Bimt6SEUdL7KSK5tk64Q5zxRTWr5PvT_PTpEaMx3I=.d56fba5b-e89c-46d8-9b7f-488a6c559fe1@github.com>
Message-ID: <ACVSe2CyRIW9jGwYeYFV8vVzvLZP9s--c_DRlennbC0=.6a79f38d-83a0-4bcb-892a-9ee4a26c1ef7@github.com>

On Wed, 5 Jul 2023 15:07:15 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.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust comments

Hi Christoph, thanks for the review !
I added the '.' as suggested.

Any objections to the latest revision?

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

PR Comment: https://git.openjdk.org/jdk/pull/14593#issuecomment-1623132227

From dholmes at openjdk.org  Thu Jul  6 07:35:12 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Jul 2023 07:35:12 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v5]
In-Reply-To: <ggJTRFLg4cRBkeXkY_gGOQPI8dBTg_PTbto4yhl0Rp8=.6335d5a3-9653-48d6-886b-61851ac31014@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <RhyKQERReuok9CVTDMV57hGRtnfTtUnKMEWfVLKQepQ=.afa0d7fb-99a5-486d-83e1-db7cbfbf7ccf@github.com>
 <ggJTRFLg4cRBkeXkY_gGOQPI8dBTg_PTbto4yhl0Rp8=.6335d5a3-9653-48d6-886b-61851ac31014@github.com>
Message-ID: <bOO1io-5BepHCKflts0nCy6cRslj4BacSPPfy5QSlsA=.459b6299-df27-4cb3-a0b1-cb4308d021e1@github.com>

On Thu, 22 Jun 2023 09:23:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> 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 .

This is a trivial test for a trivial issue. javap will be tested much more thoroughly by other tests. I think this test can be deleted without any loss of coverage. Or it can just be left.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1254047816

From simonis at openjdk.org  Thu Jul  6 08:00:54 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 6 Jul 2023 08:00:54 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() can throw if invoked
 reflectively [v2]
In-Reply-To: <gpNi8d1i2-Hug0LZscTkd5KdfEArVB5XLIXr78miQQM=.adabbd4a-0197-4f50-bc9a-da084223180b@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
 <yS8kuYQ-iQzTnhuxiiS7-ifGAlxP_6znBKmKMftKL20=.e71006f6-a38c-4340-9afa-1057e8e5b638@github.com>
 <gpNi8d1i2-Hug0LZscTkd5KdfEArVB5XLIXr78miQQM=.adabbd4a-0197-4f50-bc9a-da084223180b@github.com>
Message-ID: <PyYmuR0rgaHcV4qOY0l9xgZLmjzaKts4Pjxq4r4C5ag=.36b839ba-36bd-4872-a061-34ad928ad957@github.com>

On Wed, 5 Jul 2023 19:14:07 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Thanks for catching this issue. I agree that `Method::invoke` should be skipped the caller-sensitive test in this case but the fix isn't quite right. The caller-sensitive test should apply in any batch. For example, `CSM` calls `getCallerClass` reflectively, I think the stack would look like this:
> 
> ```
> java.lang.StackWalker::getCallerClass
> java.lang.invoke.DirectMethodHandle$Holder::invokeStatic
> java.lang.invoke.LambdaForm$MH/0x0000000800002c00::invoke
> :
> :
> jdk.internal.reflect.DirectMethodHandleAccessor::invokeImpl
> jdk.internal.reflect.DirectMethodHandleAccessor::invoke
> java.lang.reflect.Method::invoke
> CSM  <--------- caller-sensitive method and UOE should be thrown
> ```
> 
> In this case, UOE should be thrown.

Hi @mlchung ,
Thanks for your comments. I think you're right. More specifically, the caller-sensitive test should be applied to the first non-reflective, non-methodhandle frame, independent on the batch in which it appears.

I'll add a new test for the case you've brought up and update the fix accordingly.

Best regards,
Volker

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

PR Comment: https://git.openjdk.org/jdk/pull/14773#issuecomment-1623171029

From djelinski at openjdk.org  Thu Jul  6 10:28:02 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 6 Jul 2023 10:28:02 GMT
Subject: Integrated: 8311489: Remove unused dirent_md files
In-Reply-To: <0cdWgqaIhjUcLYTTHj5rHlAga6r3Uj2hOSfg8I8SOEM=.6be0b071-9421-43c7-8b77-e8e79486155c@github.com>
References: <0cdWgqaIhjUcLYTTHj5rHlAga6r3Uj2hOSfg8I8SOEM=.6be0b071-9421-43c7-8b77-e8e79486155c@github.com>
Message-ID: <39XyguK68R1wr_F74kPltJD_LuzlGiP-YKuK9GZJn38=.f70f3a1f-59ed-4888-9d5e-8e95aeee3597@github.com>

On Wed, 5 Jul 2023 10:21:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The methods declared in dirent_md are not used in libjava and not exported. They should be removed.

This pull request has now been integrated.

Changeset: 356067d0
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/356067d03f964fd0f24a055cfd772e27c8939812
Stats:     194 lines in 3 files changed: 0 ins; 193 del; 1 mod

8311489: Remove unused dirent_md files

Reviewed-by: bpb

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

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

From prappo at openjdk.org  Thu Jul  6 10:46:56 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Jul 2023 10:46:56 GMT
Subject: [jdk21] Integrated: 8311122: Fix typos in java.base
In-Reply-To: <YrumBX_8GznPTvQDB5MMypOIO9nweYb2xv9MCEwR_Ok=.816a12c0-7560-4eef-a99c-a3d88f92b48c@github.com>
References: <YrumBX_8GznPTvQDB5MMypOIO9nweYb2xv9MCEwR_Ok=.816a12c0-7560-4eef-a99c-a3d88f92b48c@github.com>
Message-ID: <4upquGoBx6qmILTd-DmE9YQ3ZCqMQYTV-LKZBOMBL80=.901bb792-f564-4f30-80b6-a8591ceecead@github.com>

On Tue, 4 Jul 2023 19:05:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7b3c2dc5](https://github.com/openjdk/jdk/commit/7b3c2dc5f45afc3646ff5cdc0f6efd68e0b70ea5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Pavel Rappo on 4 Jul 2023 and was reviewed by Joe Darcy, Naoto Sato, Mandy Chung, Iris Clark, Hamlin Li and Sean Mullan.
> 
> Thanks!

This pull request has now been integrated.

Changeset: bfed32bd
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/bfed32bd092751f2dca1d1b546ed078f0e45574b
Stats:     23 lines in 13 files changed: 0 ins; 0 del; 23 mod

8311122: Fix typos in java.base

Reviewed-by: iris
Backport-of: 7b3c2dc5f45afc3646ff5cdc0f6efd68e0b70ea5

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

PR: https://git.openjdk.org/jdk21/pull/94

From prappo at openjdk.org  Thu Jul  6 11:53:15 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Jul 2023 11:53:15 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v4]
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <4X2aZtSwlLRrWk0-bWXGypVemadA7ci1QBY29IyKNYs=.d7b03659-133d-4808-9ca5-e449afa11cc5@github.com>

> Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in the java.text area.
> 
> * Some changes to `equals` and `hashCode` are refactoring rather than modernization. Such changes can be as trivial as rearranging, adding, or commenting checks.
> 
> * java.text area contains more classes whose `equals` and `hashCode` could be simplified; for example: sun.text.CompactByteArray or java.text.DigitList. However, I found no evidence of `equals` and `hashCode` in those classes being used in source or tests. Since writing new tests in this case seems unreasonable, I **excluded** those classes from this PR.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Re-arrange checks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14752/files
  - new: https://git.openjdk.org/jdk/pull/14752/files/641fb1e5..f1ce3a10

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

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

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

From prappo at openjdk.org  Thu Jul  6 11:53:16 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Jul 2023 11:53:16 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v4]
In-Reply-To: <IMTlpOXrBFPrUB2GTutRk-DnT-fqbHYNIww7ZY5lEaU=.7201c806-910b-49ac-acdb-2610eeb7e233@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>
 <jWff4xux0qab4756UxzvazeDXGY_x83TYbnXlEZKVHM=.54a58dc3-c99a-4878-9c51-c2db981b84b0@github.com>
 <IMTlpOXrBFPrUB2GTutRk-DnT-fqbHYNIww7ZY5lEaU=.7201c806-910b-49ac-acdb-2610eeb7e233@github.com>
Message-ID: <s1mrmNlFEx8Hq-JM3pe4TEweILL_Wk6hRMIxXMnbRuY=.2da534e8-8d84-490a-a988-ce04d928f82d@github.com>

On Wed, 5 Jul 2023 17:44:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> You are right, I have no stats. Performance-wise, it's already better than what was there before. Before, there was no short-circuit check. But I can go either way; I don't have a strong opinion.
>> 
>> Reusing superclass' equals is not often seen these days (and that code is old), so some amount of overlap is expected. Regardless of whether we rearrange that check or not, if the passed object is not `this`, we end up checking `this == obj` twice: once in super.equals, the other time in here.
>
> True, there's no simple way to avoid the double check in either the equal or not equal case.
> And I don't know enough about the Hotspot compiler to know whether it would spot the duplication and optimize it.
> In many `equals` methods, the test for self equality is frequently the first line.
> Is fine as is.

Re-arranged the checks in f1ce3a1. You are right, this way is more conventional. As a bonus, we can dispense with the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1254322430

From jlaskey at openjdk.org  Thu Jul  6 12:11:06 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 6 Jul 2023 12:11:06 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v3]
In-Reply-To: <WcRkPWHPUjKn_Fn_tclAvnugUciHaRn3CrdyW2gI_7M=.0c9adb60-83bd-40e2-bc23-06fd80e4722c@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <ogWIsIozaQk7aTZ8BaGJcoo8N87re4GiEawCnCVvNT4=.e71655ee-7322-48c2-ab47-077c21a7a576@github.com>
 <WcRkPWHPUjKn_Fn_tclAvnugUciHaRn3CrdyW2gI_7M=.0c9adb60-83bd-40e2-bc23-06fd80e4722c@github.com>
Message-ID: <gffnM8x_xUFCBDzMXtM3ntFQICRl-sdpBHESt7RU3qU=.5de52680-1105-4a86-9074-5fe13765b31c@github.com>

On Wed, 5 Jul 2023 19:33:28 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update to use VirtualThread friendly stale queue.
>
> `WeakReferenceKey::equals` and `SoftReferenceKey::equals`:
> 
> Instead of `return Objects.equals(get(), obj);`, suggest to do:
> 
> 
>     return refersTo(obj);

@mlchung Not sure I catch the nuance. `refersTo` doesn't work if the search key is constructed. For example, if the key reference is a `record Pair(int a, int b) {}`, then `map.containsKey(new Pair(10, 20))` would locate with equals but not with `refersTo`.

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

PR Comment: https://git.openjdk.org/jdk/pull/14684#issuecomment-1623568281

From jlaskey at openjdk.org  Thu Jul  6 12:20:15 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 6 Jul 2023 12:20:15 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v4]
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: <ItKCnYFJsSeXS5jeshHQvyx1ZX28tgikR4-OFnOoWvk=.d569c8d7-9545-471c-b803-3a3c13515f64@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 with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge branch 'master' into 8310913
 - Update to use VirtualThread friendly stale queue.
 - Remove warning tied to String Templates
 - 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=03
  Stats: 1400 lines in 12 files changed: 768 ins; 625 del; 7 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 rriggs at openjdk.org  Thu Jul  6 13:29:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Jul 2023 13:29:57 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v3]
In-Reply-To: <WcRkPWHPUjKn_Fn_tclAvnugUciHaRn3CrdyW2gI_7M=.0c9adb60-83bd-40e2-bc23-06fd80e4722c@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <ogWIsIozaQk7aTZ8BaGJcoo8N87re4GiEawCnCVvNT4=.e71655ee-7322-48c2-ab47-077c21a7a576@github.com>
 <WcRkPWHPUjKn_Fn_tclAvnugUciHaRn3CrdyW2gI_7M=.0c9adb60-83bd-40e2-bc23-06fd80e4722c@github.com>
Message-ID: <_UeHdWw3d10O82Nllpo8aDl29awwSZmAwFlrxd9GQVo=.540cd8ea-d189-4f0b-93ea-b7d6e81c58a7@github.com>

On Wed, 5 Jul 2023 19:33:28 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update to use VirtualThread friendly stale queue.
>
> `WeakReferenceKey::equals` and `SoftReferenceKey::equals`:
> 
> Instead of `return Objects.equals(get(), obj);`, suggest to do:
> 
> 
>     return refersTo(obj);

> @mlchung Not sure I catch the nuance. `refersTo` doesn't work if the search key is constructed. For example, if the key reference is a `record Pair(int a, int b) {}`, then `map.containsKey(new Pair(10, 20))` would locate with equals but not with `refersTo`.

Using `get()` on a reference can momentarily create a strong reference to the item. `refersTo()` does not.
But since your map is holding proxies to the object,  `refersTo()` would be to the proxy, not the object; so that's not an option.

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

PR Comment: https://git.openjdk.org/jdk/pull/14684#issuecomment-1623683197

From mullan at openjdk.org  Thu Jul  6 14:06:02 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 6 Jul 2023 14:06:02 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: <nSqaed-WJKu7WbYdZd1yAN9xIHqwK17Aq8cHd-HpBeQ=.3d484325-dd74-4ea6-9580-ce8dca2fedd9@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/5cbc0d11...7e6f5090

src/java.base/share/classes/sun/launcher/SecuritySettings.java line 123:

> 121:         }
> 122: 
> 123:         ostream.println(INDENT + "Security TLS configuration:");

What about also noting the name of the TLS/JSSE provider in this line, for example:

"Security TLS configuration (SunJSSE provider):"

This would be useful information if a customer is using a 3rd party JSSE provider, and it is selected before SunJSSE, as the defaults in that case may be different.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1254491773

From prappo at openjdk.org  Thu Jul  6 14:49:55 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Jul 2023 14:49:55 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v4]
In-Reply-To: <yFxgKKwY3_83gXHrJtjTdGoqE-0fVv3sPpu_XdDBjgE=.1cc447b5-776f-478a-9aa6-e822505131f6@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
 <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
 <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
 <yFxgKKwY3_83gXHrJtjTdGoqE-0fVv3sPpu_XdDBjgE=.1cc447b5-776f-478a-9aa6-e822505131f6@github.com>
Message-ID: <qvXutZf0OG3yUBcf342TfbtwRD6-sJDIKmpP7eywdPU=.05a02263-1314-48a8-b20e-4c44422b6792@github.com>

On Wed, 5 Jul 2023 15:33:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> I'd suggest replacing the calls to `valuesMatch` with `Objects.equals` and remove the `valuesMatch` method as unnecessary.

I'll do something about them soon, Roger. But first I need to understand JDK-8015417 better, as it also affects other similar PRs already in review or in the works.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1254550699

From liach at openjdk.org  Thu Jul  6 16:12:15 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Jul 2023 16:12:15 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v21]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <njwxOJWKkee2RJ2xpg8EUhnechvTCiUcuOGP7LFg1I0=.9d577955-f908-47b7-a947-d501c1957b04@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 48 commits:

 - Spec update, also fix broken null behaviors
 - Merge branch 'master' into explore/mhp-iface
 - Merge branch 'mh-proxies' of https://github.com/mlchung/jdk into explore/mhp-iface
 - store a WeakReference holder in the class value
 - Merge branch 'master' into explore/mhp-iface
 - stage
   
   Signed-off-by: liach <liach at users.noreply.github.com>
 - Review comments
 - 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.
 - ... and 38 more: https://git.openjdk.org/jdk/compare/97e99f01...571e1fa6

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

Changes: https://git.openjdk.org/jdk/pull/13197/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=20
  Stats: 1539 lines in 15 files changed: 1176 ins; 219 del; 144 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 mchung at openjdk.org  Thu Jul  6 16:12:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 6 Jul 2023 16:12:16 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v22]
In-Reply-To: <ticPIAuqoi7aa6zmiCWokw-ksO5hiJ1X12_diLYRE68=.f9e27fa8-5e53-457b-8502-9ba1db7c0e3d@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <ticPIAuqoi7aa6zmiCWokw-ksO5hiJ1X12_diLYRE68=.f9e27fa8-5e53-457b-8502-9ba1db7c0e3d@github.com>
Message-ID: <uAH4zr5AqePdG51B_NQAHIF8jXBZ74Od-EBalrpKmw0=.f1875a99-d984-44b8-8dd0-55eca6a47ffe@github.com>

On Thu, 6 Jul 2023 00:13:05 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 pull request now contains 32 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into fix-8240567
>  - Revert (non-working) DedupSetBuilder filling
>  - Merge remote-tracking branch 'upstream/master' into fix-8240567
>  - Reformat
>  - Update test/jdk/tools/jlink/JLink100Modules.java
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Refine test to fill DedupSetBuilder
>  - Merge remote-tracking branch 'upstream/master' into fix-8240567
>  - Replace non-final wrapper by local variable
>  - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - ... and 22 more: https://git.openjdk.org/jdk/compare/d072c40f...584edbae

I created https://bugs.openjdk.org/browse/JDK-8311591.   This issue should not be backport until JDK-8311591 is resolved.

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

PR Comment: https://git.openjdk.org/jdk/pull/14408#issuecomment-1623937334

From duke at openjdk.org  Thu Jul  6 16:12:18 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 6 Jul 2023 16:12:18 GMT
Subject: Integrated: 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: <bFRcJzIc0crHlTrcKcZQM7hyfQkJBSEoPFMx1SxCqzs=.6cafc33f-53bd-43fe-9a21-24fc765ff2ce@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.

This pull request has now been integrated.

Changeset: ec7da91b
Author:    Oliver Kopp <kopp.dev at gmail.com>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec7da91bd83803b7d91a4de3a01caf0ba256c037
Stats:     286 lines in 3 files changed: 267 ins; 1 del; 18 mod

8240567: MethodTooLargeException thrown while creating a jlink image

Reviewed-by: mchung

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

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

From liach at openjdk.org  Thu Jul  6 16:18:20 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Jul 2023 16:18:20 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v21]
In-Reply-To: <njwxOJWKkee2RJ2xpg8EUhnechvTCiUcuOGP7LFg1I0=.9d577955-f908-47b7-a947-d501c1957b04@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <njwxOJWKkee2RJ2xpg8EUhnechvTCiUcuOGP7LFg1I0=.9d577955-f908-47b7-a947-d501c1957b04@github.com>
Message-ID: <gdGrq9JnSm0AKHcLdYr-RA8yUhsJ29Kw-b-DwXxBcGA=.eebccdb3-0bd1-4a91-a22c-1b0cca916683@github.com>

On Thu, 6 Jul 2023 16:12: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 48 commits:
> 
>  - Spec update, also fix broken null behaviors
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'mh-proxies' of https://github.com/mlchung/jdk into explore/mhp-iface
>  - store a WeakReference holder in the class value
>  - Merge branch 'master' into explore/mhp-iface
>  - stage
>    
>    Signed-off-by: liach <liach at users.noreply.github.com>
>  - Review comments
>  - 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.
>  - ... and 38 more: https://git.openjdk.org/jdk/compare/97e99f01...571e1fa6

The merge warning is due to me merging Mandy's patch after I merged master locally.

As Jorn suggested, I am now revamping the specification for MethodHandleProxies methods as well. Another discovery that prompted my doc change is that I found I have missed the requirement that `isWrapperInstance` should return `false` for `null` and `wrapperInstanceXxx` methods throw IAE instead of NPE; I have specified those cases and added a test case as well.

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

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

From prappo at openjdk.org  Thu Jul  6 16:19:55 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Jul 2023 16:19:55 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v4]
In-Reply-To: <qvXutZf0OG3yUBcf342TfbtwRD6-sJDIKmpP7eywdPU=.05a02263-1314-48a8-b20e-4c44422b6792@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
 <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
 <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
 <yFxgKKwY3_83gXHrJtjTdGoqE-0fVv3sPpu_XdDBjgE=.1cc447b5-776f-478a-9aa6-e822505131f6@github.com>
 <qvXutZf0OG3yUBcf342TfbtwRD6-sJDIKmpP7eywdPU=.05a02263-1314-48a8-b20e-4c44422b6792@github.com>
Message-ID: <JSKOtvQJzLz_TaXTLOggWvMZsWOIYoYgvywHCehbDyI=.0c33e78e-f070-4761-8687-738e8a038306@github.com>

On Thu, 6 Jul 2023 14:46:59 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I'd suggest replacing the calls to `valuesMatch` with `Objects.equals` and remove the `valuesMatch` method as unnecessary.
>
>> I'd suggest replacing the calls to `valuesMatch` with `Objects.equals` and remove the `valuesMatch` method as unnecessary.
> 
> I'll do something about them soon, Roger. But first I need to understand JDK-8015417 better, as it also affects other similar PRs already in review or in the works.

> I wrote a little case study on `Objects::equals` that talks about how it should optimize, when it does, why it doesn?t, and how (maybe) to fix that.
> 
> https://cr.openjdk.org/~jrose/jvm/equals-profile.html https://cr.openjdk.org/~jrose/jvm/equals-profile.md
> 
> This is also attached to the JBS bug.
> 
> The work on [JDK-8026251](https://bugs.openjdk.org/browse/JDK-8026251) with the `TypeProfileLevel` switch bring us closer to correctly optimizing `Objects::equals` in more cases. Sadly, JDK refactoring by itself will not get all the way to where we want to go. The JVM?s profiling logic needs tweaking.

This PR has turned into an impromptu discussion on JDK-8015417. I think it's reasonable to continue it here, rather than to fork a separate discussion, because of (i) the relevance, (ii) context, and (iii) the fact that I have already pointed someone to this thread elsewhere.

Below is my mental model which I built based on your excellent write-up, John; is this model correct?

1. Inside a static method of a utility class, such as `java.util.Objects`,  `java.util.Arrays`, and `jdk.internal.util.ArraysSupport`, that have one or more parameters of `java.lang.Object` or arrays thereof, "observation of a static type" fails because `java.lang.Object` is the most inexact type possible.

2. Generics that might be available in the context of a call site of the said method do not _currently_ contribute to "observation of a static type" inside the said method:

        T obj = ...
        return Objects.hashCode(obj);

   It would still be true inside the method, if it used someone else's or its own generic parameters, as for example, `java.util.Objects.compare` does:

        public static <T> int compare(T a, T b, Comparator<? super T> c) {
            return (a == b) ? 0 :  c.compare(a, b);
        }

   In the sense of being opposite to "specific", generics are as "generic" as `java.lang.Object` and are not reifiable even for optimization purposes.

3. The above two points conclude the "observation of a static type" part of the issue. Our only hope is now (dynamic) profiling followed by successful type speculation.

4. Hand-inlining the said method is necessary but not sufficient to win the optimization. One way to avoid the need for hand-inlining is to annotate that method with `@ForceInline`.

5. Profiling/speculation leads to desired devirtualization of the call to an instance method, if the reference through which the call is made refers to an instance of an exact type (i.e. a `final` class or a primitive[^*]). Note: the reference itself does not need to be of an exact type. For example, this will do:

        Object s = "myString";
        ...
        java.util.Objects.hashCode(s);

4. Inside a general-purpose method, such as `Objects.hashCode(Object)`, profiling is noisy, and thus is unlikely to pan out a successful speculation. Outside such a general-purpose method, at its call site, profiling could be less noisy.

[^*]:  It cannot be primitive in this case, because we are only concerned with methods that accept `java.lang.Object`.
----

Let's further test that model by checking its predictions.

1. Consider mainline `java.util.AbstractMap.SimpleEntry`:

        public boolean equals(Object o) {
            return o instanceof Map.Entry<?, ?> e
                    && eq(key, e.getKey())
                    && eq(value, e.getValue());
        }

        /**
         * Utility method for SimpleEntry and SimpleImmutableEntry.
         * Test for equality, checking for nulls.
         *
         * NB: Do not replace with Object.equals until JDK-8015417 is resolved.
         */
        private static boolean eq(Object o1, Object o2) {
            return o1 == null ? o2 == null : o1.equals(o2);
        }

   Since everything here is either of type `java.lang.Object` or a wildcard, no information is contributed to "observation of a static type". That `eq` method is likely is as bad as `Objects.equals`, assuming our runtime operates on many maps of different parameterizations leading to a noisy profile. Which means that in this case, we can reasonably refactor that `equals` as follows:

        public boolean equals(Object o) {
            return o instanceof Map.Entry<?, ?> e
                    && Objects.equals(key, e.getKey())
                    && Objects.equals(value, e.getValue());
        }

   Similar reasoning could be applied to that same class' `hashCode`, to refactor it from this:

        public int hashCode() {
            return (key   == null ? 0 :   key.hashCode()) ^
                   (value == null ? 0 : value.hashCode());
        }

   to this:

        public int hashCode() {
            return (Objects.hashCode(key)) ^
                   (Objects.hashCode(value));
        }

   Unlike the previous example, however, where we trade one inlining for another, here we might lose the first layer of inlining. But assuming that `Objects.hashCode` is relatively small and additionally might get annotated with `@ForceInline` as a result of this discussion later on, it will be inlined.

2. Consider an opposite example:

        public class ECFieldF2m implements ECField {
            ...
            private BigInteger rp;
            ...
            public int hashCode() {
                int value = m << 5;
                value += (rp==null? 0:rp.hashCode());
                // no need to involve ks here since ks and rp
                // should be equivalent.
                return value;
            }
        }

   Would it be reasonable to change `hashCode` like this?

        public int hashCode() {
            int value = m << 5;
            value += Objects.hashCode(rp);
            // no need to involve ks here since ks and rp
            // should be equivalent.
            return value;
        }

   Firstly, we lose inlining. Secondly, the fact that `rp` is `BigInteger` is no longer immediately available to the actual hash code computation. Assuming that `java.util.Objects.hashCode` will be inlined at runtime, and given enough invocations, it will be profiled and subjected to class hierarchy analysis (CHA), which in the absence of `BigInteger.hashCode` overrides will hopefully determine that the call could be further inlined.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1254659913

From mchung at openjdk.org  Thu Jul  6 16:27:58 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 6 Jul 2023 16:27:58 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v3]
In-Reply-To: <_UeHdWw3d10O82Nllpo8aDl29awwSZmAwFlrxd9GQVo=.540cd8ea-d189-4f0b-93ea-b7d6e81c58a7@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <ogWIsIozaQk7aTZ8BaGJcoo8N87re4GiEawCnCVvNT4=.e71655ee-7322-48c2-ab47-077c21a7a576@github.com>
 <WcRkPWHPUjKn_Fn_tclAvnugUciHaRn3CrdyW2gI_7M=.0c9adb60-83bd-40e2-bc23-06fd80e4722c@github.com>
 <_UeHdWw3d10O82Nllpo8aDl29awwSZmAwFlrxd9GQVo=.540cd8ea-d189-4f0b-93ea-b7d6e81c58a7@github.com>
Message-ID: <hpRWRqVFUWuvxk6W8dRWyvg3N6wyP9sQbuBxzhHo88s=.b7c9dd6f-1f1b-42d6-a942-48d77f4724c0@github.com>

On Thu, 6 Jul 2023 13:27:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> `WeakReferenceKey::equals` and `SoftReferenceKey::equals`:
>> 
>> Instead of `return Objects.equals(get(), obj);`, suggest to do:
>> 
>> 
>>     return refersTo(obj);
>
>> @mlchung Not sure I catch the nuance. `refersTo` doesn't work if the search key is constructed. For example, if the key reference is a `record Pair(int a, int b) {}`, then `map.containsKey(new Pair(10, 20))` would locate with equals but not with `refersTo`.
> 
> Using `get()` on a reference can momentarily create a strong reference to the item. `refersTo()` does not.
> But since your map is holding proxies to the object,  `refersTo()` would be to the proxy, not the object; so that's not an option.

@RogerRiggs `WeakReferenceKey` is a `WeakReference` with the key as the referent.   I might be missing something?

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

PR Comment: https://git.openjdk.org/jdk/pull/14684#issuecomment-1623967599

From mchung at openjdk.org  Thu Jul  6 16:37:02 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 6 Jul 2023 16:37:02 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v4]
In-Reply-To: <ItKCnYFJsSeXS5jeshHQvyx1ZX28tgikR4-OFnOoWvk=.d569c8d7-9545-471c-b803-3a3c13515f64@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <ItKCnYFJsSeXS5jeshHQvyx1ZX28tgikR4-OFnOoWvk=.d569c8d7-9545-471c-b803-3a3c13515f64@github.com>
Message-ID: <mPixQr1l4tMsUPO5saT-9GLpv-Fx8OTyoDcBm9J5u2k=.cf881b8b-ae07-4205-a4b5-8cc305dda615@github.com>

On Thu, 6 Jul 2023 12:20:15 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 with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge branch 'master' into 8310913
>  - Update to use VirtualThread friendly stale queue.
>  - Remove warning tied to String Templates
>  - 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

src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 111:

> 109:         this.isSoft = isSoft;
> 110:         this.map = map;
> 111:         this.stale = SharedSecrets.getJavaLangRefAccess().newNativeReferenceQueue();

I don't think you want all `ReferencedKeyMap` instances use native reference queue which may cause the virtual thread to pin on the carrier thread if it synchronizes the monitor lock.

Perhaps add a new factory method that takes a `ReferenceQueue` and `MethodType` will create it with `NativeReferenceQueue`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1254677202

From mchung at openjdk.org  Thu Jul  6 16:59:18 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 6 Jul 2023 16:59:18 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v21]
In-Reply-To: <njwxOJWKkee2RJ2xpg8EUhnechvTCiUcuOGP7LFg1I0=.9d577955-f908-47b7-a947-d501c1957b04@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <njwxOJWKkee2RJ2xpg8EUhnechvTCiUcuOGP7LFg1I0=.9d577955-f908-47b7-a947-d501c1957b04@github.com>
Message-ID: <BIdZkL2aORSEoqu7d6utUJcdn5TRETiSwBxSvPW_OmQ=.a3cf66f1-fbbd-4ff9-a815-fd039ce911f2@github.com>

On Thu, 6 Jul 2023 16:12: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 48 commits:
> 
>  - Spec update, also fix broken null behaviors
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'mh-proxies' of https://github.com/mlchung/jdk into explore/mhp-iface
>  - store a WeakReference holder in the class value
>  - Merge branch 'master' into explore/mhp-iface
>  - stage
>    
>    Signed-off-by: liach <liach at users.noreply.github.com>
>  - Review comments
>  - 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.
>  - ... and 38 more: https://git.openjdk.org/jdk/compare/97e99f01...571e1fa6

Please revert the spec change.  This makes it hard to review.  Also I don't understand why the spec needs to be revamped - can you explain?  This PR is to reimplement the method handle proxies which should conform to the current spec.

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

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

From mchung at openjdk.org  Thu Jul  6 17:17:57 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 6 Jul 2023 17:17:57 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v8]
In-Reply-To: <rsK3bo2OtxGtMNdH4oNR3c-acbpFl9ki1mBzG4_x8wY=.5251d1ac-f83f-4b78-82b6-5dec965186c9@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <Do1PCxXWlOkJ92jocEgyrtJsJZ2lQkJXgFDEFd0mxAc=.f4957955-4d6b-4066-8b94-50e47a7e96f8@github.com>
 <rsK3bo2OtxGtMNdH4oNR3c-acbpFl9ki1mBzG4_x8wY=.5251d1ac-f83f-4b78-82b6-5dec965186c9@github.com>
Message-ID: <sesMMIlaEim4JwvkNJnM5Vjl65_eXZ3af_9X2UzOR5c=.09a13afe-87e3-4b23-832c-d5edd80bca0c@github.com>

On Thu, 29 Jun 2023 08:27:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 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.

I think throwing an error for an invalid suboption makes sense.   `-XshowSetting` without the suboption is default to print all settings, i.e. equivalent to `-XshowSetting:all`.   But the switch statment is missing the `all` case.   I think we should fix this and error for any invalid option.

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

PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1624030798

From rriggs at openjdk.org  Thu Jul  6 18:30:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Jul 2023 18:30:56 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v3]
In-Reply-To: <_UeHdWw3d10O82Nllpo8aDl29awwSZmAwFlrxd9GQVo=.540cd8ea-d189-4f0b-93ea-b7d6e81c58a7@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <ogWIsIozaQk7aTZ8BaGJcoo8N87re4GiEawCnCVvNT4=.e71655ee-7322-48c2-ab47-077c21a7a576@github.com>
 <WcRkPWHPUjKn_Fn_tclAvnugUciHaRn3CrdyW2gI_7M=.0c9adb60-83bd-40e2-bc23-06fd80e4722c@github.com>
 <_UeHdWw3d10O82Nllpo8aDl29awwSZmAwFlrxd9GQVo=.540cd8ea-d189-4f0b-93ea-b7d6e81c58a7@github.com>
Message-ID: <BDYiiejVvC7kcvMr0T4Ekz3CUGJHvuFprUxne4Q0ncE=.83668922-3dd5-4012-92b3-c53a30cb3744@github.com>

On Thu, 6 Jul 2023 13:27:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> `WeakReferenceKey::equals` and `SoftReferenceKey::equals`:
>> 
>> Instead of `return Objects.equals(get(), obj);`, suggest to do:
>> 
>> 
>>     return refersTo(obj);
>
>> @mlchung Not sure I catch the nuance. `refersTo` doesn't work if the search key is constructed. For example, if the key reference is a `record Pair(int a, int b) {}`, then `map.containsKey(new Pair(10, 20))` would locate with equals but not with `refersTo`.
> 
> Using `get()` on a reference can momentarily create a strong reference to the item. `refersTo()` does not.
> But since your map is holding proxies to the object,  `refersTo()` would be to the proxy, not the object; so that's not an option.

> @RogerRiggs `WeakReferenceKey` is a `WeakReference` with the key as the referent. I might be missing something?

The comparison of the unwrapped key using `refersTo` is an identity comparison; but the usual comparison for Maps uses `equals`.  Using `refersTo` would limit the use of ReferencedKeyMap to cases where the original key requires identity comparision. (I missed Jim's earlier comment that pointed this out.)

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

PR Comment: https://git.openjdk.org/jdk/pull/14684#issuecomment-1624135067

From mchung at openjdk.org  Thu Jul  6 18:56:58 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 6 Jul 2023 18:56:58 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v4]
In-Reply-To: <ItKCnYFJsSeXS5jeshHQvyx1ZX28tgikR4-OFnOoWvk=.d569c8d7-9545-471c-b803-3a3c13515f64@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <ItKCnYFJsSeXS5jeshHQvyx1ZX28tgikR4-OFnOoWvk=.d569c8d7-9545-471c-b803-3a3c13515f64@github.com>
Message-ID: <d5AQNCI4JDFJ_6wbJBV7axqgtViGH4B3oRPWeMCkL78=.c97c3ac9-d191-41e4-943f-1ceaf0c6564a@github.com>

On Thu, 6 Jul 2023 12:20:15 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 with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge branch 'master' into 8310913
>  - Update to use VirtualThread friendly stale queue.
>  - Remove warning tied to String Templates
>  - 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

thanks.  It may worth adding a comment about equality comparison and can't use `refersTo`

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

PR Comment: https://git.openjdk.org/jdk/pull/14684#issuecomment-1624165098

From rriggs at openjdk.org  Thu Jul  6 19:01:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Jul 2023 19:01:06 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: <RwiedzZlfLbLBW48WCNl6vsQ6pSmhCn8r3oGx2hhyqE=.0cfe558a-7ca4-438b-abf3-648db5e24097@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/da750e20...7e6f5090

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 115:

> 113:     private static StringBuilder outBuf = new StringBuilder();
> 114: 
> 115:     private static final String INDENT = " ".repeat(4);

Revert this, its just making a simple constant into a runtime expression.

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

PR Review: https://git.openjdk.org/jdk/pull/14394#pullrequestreview-1517119059
PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1254799500

From jlu at openjdk.org  Thu Jul  6 19:32:09 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 6 Jul 2023 19:32:09 GMT
Subject: RFR: 8310818: Refactor more Locale tests to use JUnit [v2]
In-Reply-To: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
References: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
Message-ID: <o1Hev0mCe5cDNWWs0b0LdglJbd6vswi6rp6Tmug5eHo=.15af9fe4-a6e0-4e3b-ad49-d551e92cd297@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

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Review: Remove Bug8025703.java and add to LSRT.java
 - Review: Clarify comments in ISO639.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14721/files
  - new: https://git.openjdk.org/jdk/pull/14721/files/f065726e..c1c55898

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

  Stats: 104 lines in 3 files changed: 12 ins; 88 del; 4 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 jlu at openjdk.org  Thu Jul  6 19:32:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 6 Jul 2023 19:32:11 GMT
Subject: RFR: 8310818: Refactor more Locale tests to use JUnit [v2]
In-Reply-To: <R4UAROrEuHNmhYEp7w_S72ktN29v_K9P_SG106IliUI=.b212696c-eeba-44ed-a1a7-487d45c2a4a1@github.com>
References: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
 <R4UAROrEuHNmhYEp7w_S72ktN29v_K9P_SG106IliUI=.b212696c-eeba-44ed-a1a7-487d45c2a4a1@github.com>
Message-ID: <3Pq8FFVrmA70ZFYlK-MA0q_AWYQesAnFH2EwTWsZ9q4=.0d0915fd-ecdf-41bc-9494-b8ef0882e121@github.com>

On Mon, 3 Jul 2023 17:55:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Review: Remove Bug8025703.java and add to LSRT.java
>>  - Review: Clarify comments in ISO639.java
>
> test/jdk/java/util/Locale/Bug8025703.java line 48:
> 
>> 46:      * language priority list by matching the correct tag(s). This test
>> 47:      * was originally created to verify an older update to the LSR data file,
>> 48:      * and the test may be deprecated by LanguageSubtagRegistryTest.java
> 
> If that's the case, can we update `LanguageSubtagRegistryTest.java` to cover these older updates and remove this test?

Yes, merged the tags from `Bug8025703.java` into `LanguageSubtagRegistryTest.java` and removed `Bug8025703.java`.

> test/jdk/java/util/Locale/ISO639.java line 299:
> 
>> 297: 
>> 298: // CODES generated from https://www.loc.gov/standards/iso639-2/ISO-639-2_utf-8.txt
>> 299: // on March 9th, 2023.
> 
> Should be `expectedISO639Codes` instead of `CODES`, and this comment would be better placed on top of `expectedISO639Codes` method

Adjusted

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14721#discussion_r1254834468
PR Review Comment: https://git.openjdk.org/jdk/pull/14721#discussion_r1254834584

From jlaskey at openjdk.org  Thu Jul  6 19:59:11 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 6 Jul 2023 19:59:11 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v5]
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: <G3gGbJEH4WMS0LOWaNFelqL0gfoeflEhi61xNSNASy8=.c6acd39a-8ecd-4b6d-a581-78e4d96158e5@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:

  Add flag for reference queue type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14684/files
  - new: https://git.openjdk.org/jdk/pull/14684/files/140561fc..f4854011

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

  Stats: 64 lines in 8 files changed: 12 ins; 28 del; 24 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 mchung at openjdk.org  Thu Jul  6 20:02:04 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 6 Jul 2023 20:02:04 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v5]
In-Reply-To: <G3gGbJEH4WMS0LOWaNFelqL0gfoeflEhi61xNSNASy8=.c6acd39a-8ecd-4b6d-a581-78e4d96158e5@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <G3gGbJEH4WMS0LOWaNFelqL0gfoeflEhi61xNSNASy8=.c6acd39a-8ecd-4b6d-a581-78e4d96158e5@github.com>
Message-ID: <RsQy_4b8SwkUkk-z2h_1GFv6tPb0aCp6eTsehuQbAN8=.42b4c7a6-c973-472c-9a63-64e969a37e62@github.com>

On Thu, 6 Jul 2023 19:59:11 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:
> 
>   Add flag for reference queue type

src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 107:

> 105:      *                        be used, {@link WeakReference} otherwise.
> 106:      * @param useNativeQueue  true if uses NativeReferenceQueue
> 107:      *                        otherwise use {@link ReferenceQueue}.

no such param for this constructor.

src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 132:

> 130:      */
> 131:     public static <K, V> ReferencedKeyMap<K, V>
> 132:     create(boolean isSoft, boolean useNativeQueue, Supplier<Map<ReferenceKey<K>, V>> supplier) {

I suggest to keep the previous `create(boolean isSoft, Supplier supplier)`  factory method that defaults to non-native reference queue, which is commonly used.   Only `MethodType` needs to use native reference queue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1254856896
PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1254860906

From lancea at openjdk.org  Thu Jul  6 20:03:55 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 6 Jul 2023 20:03:55 GMT
Subject: RFR: 8310818: Refactor more Locale tests to use JUnit [v2]
In-Reply-To: <o1Hev0mCe5cDNWWs0b0LdglJbd6vswi6rp6Tmug5eHo=.15af9fe4-a6e0-4e3b-ad49-d551e92cd297@github.com>
References: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
 <o1Hev0mCe5cDNWWs0b0LdglJbd6vswi6rp6Tmug5eHo=.15af9fe4-a6e0-4e3b-ad49-d551e92cd297@github.com>
Message-ID: <wBZjzIlrLtQBQEoMZ_Cq1zcqojEBZ6_WfFAr9ysZDoM=.45a7b316-528c-419b-ab7c-0cac3374b7e4@github.com>

On Thu, 6 Jul 2023 19:32:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> 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
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review: Remove Bug8025703.java and add to LSRT.java
>  - Review: Clarify comments in ISO639.java

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14721#pullrequestreview-1517223095

From bpb at openjdk.org  Thu Jul  6 20:15:02 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Jul 2023 20:15:02 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent of
 close but throws UncheckedIOException
Message-ID: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>

Add a default method `java.io.Closeable::closeUnchecked` which is equivalent to `Closeable::close` except that it instead throws `java.io.UncheckedIOException`.

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

Commit messages:
 - 8066869: Add Closeable::closeUnchecked that is the equivalent of close but throws UncheckedIOException

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

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

From bpb at openjdk.org  Thu Jul  6 20:15:02 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Jul 2023 20:15:02 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent
 of close but throws UncheckedIOException
In-Reply-To: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
Message-ID: <idBmWQzdRE_yLtm9eWdjUWPR-nUD95K5KDl5lwr7A6E=.47845de0-0a8c-42fa-8804-1be3e38be522@github.com>

On Thu, 6 Jul 2023 20:07:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a default method `java.io.Closeable::closeUnchecked` which is equivalent to `Closeable::close` except that it instead throws `java.io.UncheckedIOException`.

A CSR will follow if there is agreement on the concept.

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

PR Comment: https://git.openjdk.org/jdk/pull/14789#issuecomment-1624248529

From rriggs at openjdk.org  Thu Jul  6 20:44:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Jul 2023 20:44:54 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent
 of close but throws UncheckedIOException
In-Reply-To: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
Message-ID: <lwY-bzUOOECishP5nSnexshOdnKnmhMY72EStfhXjHc=.c6808696-b497-4f29-b4ab-502573e5d0ad@github.com>

On Thu, 6 Jul 2023 20:07:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a default method `java.io.Closeable::closeUnchecked` which is equivalent to `Closeable::close` except that it instead throws `java.io.UncheckedIOException`.

src/java.base/share/classes/java/io/Closeable.java line 60:

> 58:      * with it. If the stream is already closed then invoking this
> 59:      * method has no effect.
> 60:      *

Can you add an example showing the recommended pattern of use?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14789#discussion_r1254898461

From bpb at openjdk.org  Thu Jul  6 20:57:54 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Jul 2023 20:57:54 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent
 of close but throws UncheckedIOException
In-Reply-To: <lwY-bzUOOECishP5nSnexshOdnKnmhMY72EStfhXjHc=.c6808696-b497-4f29-b4ab-502573e5d0ad@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
 <lwY-bzUOOECishP5nSnexshOdnKnmhMY72EStfhXjHc=.c6808696-b497-4f29-b4ab-502573e5d0ad@github.com>
Message-ID: <_9kshGA47UELjIJyRGFjnbwk4xIuWwLqGhuSNYuQtSM=.428efac1-7dd3-49de-94f3-be166b8c2616@github.com>

On Thu, 6 Jul 2023 20:42:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Can you add an example showing the recommended pattern of use?

One pattern is for example when reading from a stream and closing it is highly unlikely to generate an exception, then instead of the try block in

InputStream in = ...;
while(someCondition) {
    int b = in.read();
    // process b
}
try {
    in.close();
} catch (IOException ignored) {
}

one could simply write

in.closeUnchecked();

and avoid the boilerplate imposed by the checked exception. This sort of code can be found in many places in the tests in `<OpenJDK>/test/jdk`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14789#discussion_r1254910730

From naoto at openjdk.org  Thu Jul  6 21:09:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Jul 2023 21:09:59 GMT
Subject: RFR: 8311528: Remove IDE specific SuppressWarnings
Message-ID: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>

Removing the IDE specific `@SuppressWarnings` attached to `java.util.Calendar#equals()`. `equals()` implementation now checks the type of the other instance for this.

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

Commit messages:
 - initial commit

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

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

From naoto at openjdk.org  Thu Jul  6 21:09:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Jul 2023 21:09:55 GMT
Subject: RFR: 8310818: Refactor more Locale tests to use JUnit [v2]
In-Reply-To: <o1Hev0mCe5cDNWWs0b0LdglJbd6vswi6rp6Tmug5eHo=.15af9fe4-a6e0-4e3b-ad49-d551e92cd297@github.com>
References: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
 <o1Hev0mCe5cDNWWs0b0LdglJbd6vswi6rp6Tmug5eHo=.15af9fe4-a6e0-4e3b-ad49-d551e92cd297@github.com>
Message-ID: <WnHb7MHCrkREZDvADW4w2M6bMveSXI0Gj0JICT7hH0g=.bc5a1eae-55cb-4302-a467-6e9eb07aa9b4@github.com>

On Thu, 6 Jul 2023 19:32:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> 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
>> - Combine Bug8025703.java into LanguageSubtagRegistryTest.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
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review: Remove Bug8025703.java and add to LSRT.java
>  - Review: Clarify comments in ISO639.java

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14721#pullrequestreview-1517315299

From lancea at openjdk.org  Thu Jul  6 21:17:53 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 6 Jul 2023 21:17:53 GMT
Subject: RFR: 8311528: Remove IDE specific SuppressWarnings
In-Reply-To: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>
References: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>
Message-ID: <NY1ITAC-kGMZoLvW2OH8oXB0Qm-GvtmynyqPLxxjlQQ=.09c25eb4-0a4d-4f4f-a3fe-a386e9b5c2f8@github.com>

On Thu, 6 Jul 2023 21:03:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the IDE specific `@SuppressWarnings` attached to `java.util.Calendar#equals()`. `equals()` implementation now checks the type of the other instance for this.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14790#pullrequestreview-1517325657

From bpb at openjdk.org  Thu Jul  6 21:26:52 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Jul 2023 21:26:52 GMT
Subject: RFR: 8311528: Remove IDE specific SuppressWarnings
In-Reply-To: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>
References: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>
Message-ID: <qciAMtic29U1TmuW_TmCc6eCeYE9I466_T3RLDZrBUE=.7d0ad62d-a8ad-4b25-84ea-6a1842017f6c@github.com>

On Thu, 6 Jul 2023 21:03:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the IDE specific `@SuppressWarnings` attached to `java.util.Calendar#equals()`. `equals()` implementation now checks the type of the other instance for this.

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14790#pullrequestreview-1517336153

From forax at univ-mlv.fr  Thu Jul  6 21:43:59 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 6 Jul 2023 23:43:59 +0200 (CEST)
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the
 equivalent of close but throws UncheckedIOException
In-Reply-To: <_9kshGA47UELjIJyRGFjnbwk4xIuWwLqGhuSNYuQtSM=.428efac1-7dd3-49de-94f3-be166b8c2616@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
 <lwY-bzUOOECishP5nSnexshOdnKnmhMY72EStfhXjHc=.c6808696-b497-4f29-b4ab-502573e5d0ad@github.com>
 <_9kshGA47UELjIJyRGFjnbwk4xIuWwLqGhuSNYuQtSM=.428efac1-7dd3-49de-94f3-be166b8c2616@github.com>
Message-ID: <1964293768.98318143.1688679839453.JavaMail.zimbra@univ-eiffel.fr>

I'm not a big fan of hiding exceptions, why not wrapping the IOException in an UncheckedIOException ?

So closeUnchecked() means close and throw an unchecked exception if an exception occurs.

regards,
R?mi

----- Original Message -----
> From: "Brian Burkhalter" <bpb at openjdk.org>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Thursday, July 6, 2023 11:57:54 PM
> Subject: Re: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent of close but throws UncheckedIOException

> On Thu, 6 Jul 2023 20:42:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:
> 
>> Can you add an example showing the recommended pattern of use?
> 
> One pattern is for example when reading from a stream and closing it is highly
> unlikely to generate an exception, then instead of the try block in
> 
> InputStream in = ...;
> while(someCondition) {
>    int b = in.read();
>    // process b
> }
> try {
>    in.close();
> } catch (IOException ignored) {
> }
> 
> one could simply write
> 
> in.closeUnchecked();
> 
> and avoid the boilerplate imposed by the checked exception. This sort of code
> can be found in many places in the tests in `<OpenJDK>/test/jdk`.
> 
> -------------
> 
> PR Review Comment: https://git.openjdk.org/jdk/pull/14789#discussion_r1254910730

From bpb at openjdk.org  Thu Jul  6 21:49:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Jul 2023 21:49:10 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead of 1
Message-ID: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>

Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no guarantee as to how the underlying output stream actually writes the bytes provided to it.

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

Commit messages:
 - 8155902: DataOutputStream writeInt creates 2 packets instead of 1

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

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

From bpb at openjdk.org  Thu Jul  6 21:49:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Jul 2023 21:49:10 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1
In-Reply-To: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
Message-ID: <KBy7X5dZiHpqiv_B4dxUkkgqmWhNO51D8Q3bf6ahfAg=.aa297a5e-6427-4c4b-9e4b-3761bfc2ab7e@github.com>

On Thu, 6 Jul 2023 21:40:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no guarantee as to how the underlying output stream actually writes the bytes provided to it.

It might be equally reasonable simply to resolve the issue as "Not an Issue." A CSR will be created if that is not the case.

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

PR Comment: https://git.openjdk.org/jdk/pull/14791#issuecomment-1624344687

From rriggs at openjdk.org  Thu Jul  6 21:50:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Jul 2023 21:50:57 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: <l7SmjUdigXQpmerC6pxj4rJ5vyaQUh7CN9J4UvqqSh4=.67df0792-b69b-470b-899b-ac6634946a28@github.com>

On Sun, 18 Jun 2023 20:26:04 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
>
> As things stand, this PR makes things worse not better I'm afraid.

@jodastephen Please review updated descriptions.  Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/14479#issuecomment-1624350524

From jlu at openjdk.org  Thu Jul  6 21:55:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 6 Jul 2023 21:55:54 GMT
Subject: RFR: 8311528: Remove IDE specific SuppressWarnings
In-Reply-To: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>
References: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>
Message-ID: <4JZQk3Ln3OcJ-RBWfRCUwapfgz_R3vLiFhZH8ZFfqCA=.db4b4d2d-7cfc-4763-a9c8-426a08ef5abc@github.com>

On Thu, 6 Jul 2023 21:03:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the IDE specific `@SuppressWarnings` attached to `java.util.Calendar#equals()`. `equals()` implementation now checks the type of the other instance for this.

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/14790#pullrequestreview-1517371749

From smarks at openjdk.org  Thu Jul  6 22:44:53 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 6 Jul 2023 22:44:53 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent
 of close but throws UncheckedIOException
In-Reply-To: <_9kshGA47UELjIJyRGFjnbwk4xIuWwLqGhuSNYuQtSM=.428efac1-7dd3-49de-94f3-be166b8c2616@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
 <lwY-bzUOOECishP5nSnexshOdnKnmhMY72EStfhXjHc=.c6808696-b497-4f29-b4ab-502573e5d0ad@github.com>
 <_9kshGA47UELjIJyRGFjnbwk4xIuWwLqGhuSNYuQtSM=.428efac1-7dd3-49de-94f3-be166b8c2616@github.com>
Message-ID: <Wbvj__K2pVhqyOGt8Zz-a-5J_b8000oWnTTXkDLnf5k=.efbb6f2b-9d2a-4ee9-be2f-ad234afec537@github.com>

On Thu, 6 Jul 2023 20:55:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Closeable.java line 60:
>> 
>>> 58:      * with it. If the stream is already closed then invoking this
>>> 59:      * method has no effect.
>>> 60:      *
>> 
>> Can you add an example showing the recommended pattern of use?
>
>> Can you add an example showing the recommended pattern of use?
> 
> One pattern is for example when reading from a stream and closing it is highly unlikely to generate an exception, then instead of the try block in
> 
> InputStream in = ...;
> while(someCondition) {
>     int b = in.read();
>     // process b
> }
> try {
>     in.close();
> } catch (IOException ignored) {
> }
> 
> one could simply write
> 
> in.closeUnchecked();
> 
> and avoid the boilerplate imposed by the checked exception. This sort of code can be found in many places in the tests in `<OpenJDK>/test/jdk`.

OK, but note that using `closeUnchecked` in this way changes the behavior. Instead of ignoring an `IOException` it will get rethrown wrapped in an `UncheckedIOException`. This is probably reasonable for test code, where it's often acceptable to let exceptions propagate instead of handling them.

Are there other places in the JDK (in library code or in the tests) where `closeUnchecked` can and should be used? If so, maybe they should be updated as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14789#discussion_r1254993519

From bpb at openjdk.org  Thu Jul  6 22:50:53 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Jul 2023 22:50:53 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent
 of close but throws UncheckedIOException
In-Reply-To: <Wbvj__K2pVhqyOGt8Zz-a-5J_b8000oWnTTXkDLnf5k=.efbb6f2b-9d2a-4ee9-be2f-ad234afec537@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
 <lwY-bzUOOECishP5nSnexshOdnKnmhMY72EStfhXjHc=.c6808696-b497-4f29-b4ab-502573e5d0ad@github.com>
 <_9kshGA47UELjIJyRGFjnbwk4xIuWwLqGhuSNYuQtSM=.428efac1-7dd3-49de-94f3-be166b8c2616@github.com>
 <Wbvj__K2pVhqyOGt8Zz-a-5J_b8000oWnTTXkDLnf5k=.efbb6f2b-9d2a-4ee9-be2f-ad234afec537@github.com>
Message-ID: <eymPzTvN8XP1mNZ5WXOSlz0ht04loq5d8o68k7QEGQE=.b4109d3c-a5c8-45c7-a246-c6020afdf752@github.com>

On Thu, 6 Jul 2023 22:42:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This is probably reasonable for test code, where it's often acceptable to let exceptions propagate instead of handling them.

Understood.

> Are there other places in the JDK (in library code or in the tests) where `closeUnchecked` can and should be used? If so, maybe they should be updated as well.

Unless it's a matter of further background investigation, I think actually making any such changes would be better handled as a separate issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14789#discussion_r1254996175

From prappo at openjdk.org  Thu Jul  6 23:25:55 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Jul 2023 23:25:55 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: <LV850VH2NQB3zXnYeay-5QpIb2gV70U6C_Y6eDGDUy0=.c8c7b552-d56b-4fad-8608-f2681387e60d@github.com>

On Tue, 20 Jun 2023 18:23:09 GMT, Roger Riggs <rriggs 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).

Late to the party. FWIW, the only way I can think of 0 as of a positive integer is when it is represented using fixed-width two's complement (e.g. Java's byte, short, int, and long). In that case, the sign bit for 0 is cleared, just like that of a positive integer and unlike that of a negative integer, assuming the same representation.

For example, the following expression will tell you if an `int i` is non-negative, i.e. zero or positive:

    i >>> 31 == 0

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

PR Comment: https://git.openjdk.org/jdk/pull/14479#issuecomment-1624425467

From prappo at openjdk.org  Thu Jul  6 23:33:58 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Jul 2023 23:33:58 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: <otyJ-Wb2h5MYgAGSCV0b_a0uaCd88iq7GHChvIfOuC0=.a18be2fb-ec28-4e69-80be-1845aff80d3a@github.com>

On Sun, 18 Jun 2023 20:26:04 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
>
> As things stand, this PR makes things worse not better I'm afraid.

> @jodastephen Please review updated descriptions. Thanks

I'm not @jodastephen, obviously, but we both suggested doing something with punctuation/grammar as this reads funny/peculiar:

    @return the comparator value is less than zero

Maybe our suggestions got lost in this huge discussion, or you've decided to address them later.

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

PR Comment: https://git.openjdk.org/jdk/pull/14479#issuecomment-1624431201

From duke at openjdk.org  Thu Jul  6 23:35:09 2023
From: duke at openjdk.org (duke)
Date: Thu, 6 Jul 2023 23:35:09 GMT
Subject: Withdrawn: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <uaRK1W4uoY8WriKgYieJVUIGwgh0EMcgfXRicbKTmg4=.e68ef291-6589-493a-b7e9-8086097fb392@github.com>

On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

This pull request has been closed without being integrated.

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

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

From smarks at openjdk.org  Thu Jul  6 23:40:56 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 6 Jul 2023 23:40:56 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v4]
In-Reply-To: <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
 <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
 <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
Message-ID: <tB0gdwb1wJsxS3sn9FmNwvj_2HOmm6N7WBysURUYoPM=.25f1b2f6-ea63-4022-b451-aa93eb57c04b@github.com>

On Tue, 4 Jul 2023 22:03:58 GMT, John R Rose <jrose at openjdk.org> wrote:

>>> Hmm, I think that issue refers to code that have explicit non-Object parameter types (like `X::equals(Object)boolean` in the issue's sample). This method already have both arguments as `Object`, so I don't think there's any type-specific inlining opportunities.
>> 
>> If that's true, then perhaps those (and some other) locations got that idea wrong:
>> * https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/Collections.java#L5712-L5719
>> * https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/AbstractMap.java#L577-L585
>> 
>> Maybe @rose00 could clarify that? 
>> 
>> FWIW, I also note that `HashMap` does not use similar private static methods; it uses `Objects.equals(Object, Object)` and `Objects.hashCode` overloads that take parameters.
>
> I wrote a little case study on `Objects::equals` that talks about how it should optimize, when it does, why it doesn?t, and how (maybe) to fix that.
> 
> https://cr.openjdk.org/~jrose/jvm/equals-profile.html
> https://cr.openjdk.org/~jrose/jvm/equals-profile.md
> 
> This is also attached to the JBS bug.
> 
> The work on [JDK-8026251](https://bugs.openjdk.org/browse/JDK-8026251) with the `TypeProfileLevel` switch bring us closer to correctly optimizing `Objects::equals` in more cases.  Sadly, JDK refactoring by itself will not get all the way to where we want to go.  The JVM?s profiling logic needs tweaking.

Thanks @rose00 for the writeup and @pavelrappo for asking pertinent followup questions.

For me the issue here is that there is a bunch of lore about avoiding `Objects::equals` and it's embodied in comments like this:

> NB: Do not replace with Object.equals until JDK-8015417 is resolved. 

These comments are almost exactly ten years old, and we can't seem to find any evidence showing that a slowdown occurred if `Objects::equals` were used. The comments are a "dead hand" at this point. Is there a way to demonstrate whether there is or is not any difference when using `Objects::equals`?

As a side note, I observe that the `eq` method in Collections.java and AbstractMap.java does this:

    return o1 == null ? o2 == null : o1.equals(o2);

whereas `Objects::equals` will test `o1 == o2` and skip the `equals()` call if the references are non-null and equals. This might confound the comparison a bit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1255024667

From smarks at openjdk.org  Thu Jul  6 23:52:53 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 6 Jul 2023 23:52:53 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent
 of close but throws UncheckedIOException
In-Reply-To: <eymPzTvN8XP1mNZ5WXOSlz0ht04loq5d8o68k7QEGQE=.b4109d3c-a5c8-45c7-a246-c6020afdf752@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
 <lwY-bzUOOECishP5nSnexshOdnKnmhMY72EStfhXjHc=.c6808696-b497-4f29-b4ab-502573e5d0ad@github.com>
 <_9kshGA47UELjIJyRGFjnbwk4xIuWwLqGhuSNYuQtSM=.428efac1-7dd3-49de-94f3-be166b8c2616@github.com>
 <Wbvj__K2pVhqyOGt8Zz-a-5J_b8000oWnTTXkDLnf5k=.efbb6f2b-9d2a-4ee9-be2f-ad234afec537@github.com>
 <eymPzTvN8XP1mNZ5WXOSlz0ht04loq5d8o68k7QEGQE=.b4109d3c-a5c8-45c7-a246-c6020afdf752@github.com>
Message-ID: <nKVlPz318cDfN03kEkNTK5ZS7yfuVuCedFqXgMMa12E=.15d23924-670e-4d99-a6b7-91d1a6179ffc@github.com>

On Thu, 6 Jul 2023 22:48:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Unless it's a matter of further background investigation, I think actually making any such changes would be better handled as a separate issue.

OK. It doesn't have to be part of this change, but it would good if some example use cases could be identified. All too often I come up with great ideas for APIs, and then when I look around for example use sites, I can't find any ... and maybe this is telling me the API idea isn't as great as I thought it was.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14789#discussion_r1255035997

From prappo at openjdk.org  Fri Jul  7 00:42:15 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 7 Jul 2023 00:42:15 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v4]
In-Reply-To: <tB0gdwb1wJsxS3sn9FmNwvj_2HOmm6N7WBysURUYoPM=.25f1b2f6-ea63-4022-b451-aa93eb57c04b@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
 <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
 <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
 <tB0gdwb1wJsxS3sn9FmNwvj_2HOmm6N7WBysURUYoPM=.25f1b2f6-ea63-4022-b451-aa93eb57c04b@github.com>
Message-ID: <r4-dPyuclFOYil8WAkurSA0wlwSF7wlugZX8LDa2qrE=.f7cde5c3-5882-4511-8548-10dea66522c5@github.com>

On Thu, 6 Jul 2023 23:38:01 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> For me the issue here is that there is a bunch of lore about avoiding `Objects::equals` and it's embodied in comments like this:
> 
> > NB: Do not replace with Object.equals until JDK-8015417 is resolved.
> 
> These comments are almost exactly ten years old, and we can't seem to find any evidence showing that a slowdown occurred if `Objects::equals` were used. The comments are a "dead hand" at this point. Is there a way to demonstrate whether there is or is not any difference when using `Objects::equals`?

Agree on all of the above; this is "rumor control".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1255067182

From bpb at openjdk.org  Fri Jul  7 01:12:05 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 7 Jul 2023 01:12:05 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent
 of close but throws UncheckedIOException
In-Reply-To: <nKVlPz318cDfN03kEkNTK5ZS7yfuVuCedFqXgMMa12E=.15d23924-670e-4d99-a6b7-91d1a6179ffc@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
 <lwY-bzUOOECishP5nSnexshOdnKnmhMY72EStfhXjHc=.c6808696-b497-4f29-b4ab-502573e5d0ad@github.com>
 <_9kshGA47UELjIJyRGFjnbwk4xIuWwLqGhuSNYuQtSM=.428efac1-7dd3-49de-94f3-be166b8c2616@github.com>
 <Wbvj__K2pVhqyOGt8Zz-a-5J_b8000oWnTTXkDLnf5k=.efbb6f2b-9d2a-4ee9-be2f-ad234afec537@github.com>
 <eymPzTvN8XP1mNZ5WXOSlz0ht04loq5d8o68k7QEGQE=.b4109d3c-a5c8-45c7-a246-c6020afdf752@github.com>
 <nKVlPz318cDfN03kEkNTK5ZS7yfuVuCedFqXgMMa12E=.15d23924-670e-4d99-a6b7-91d1a6179ffc@github.com>
Message-ID: <pNjcutKIJ6rzYVu6bHm94T9WLVjuUCTQVyqYZUlFpJc=.beef14ac-fea7-4d0b-88c7-e2dc6d3d55ef@github.com>

On Thu, 6 Jul 2023 23:50:04 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> and then when I look around for example use sites, I can't find any ... and maybe this is telling me the API idea isn't as great as I thought it was.

I hear you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14789#discussion_r1255084190

From liach at openjdk.org  Fri Jul  7 01:20:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jul 2023 01:20:54 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent
 of close but throws UncheckedIOException
In-Reply-To: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
Message-ID: <d0tFyy6N0kU-tD4VmyG143uaEINNUZ_ZeyfX-s9beMM=.c06a383c-5002-434a-b654-b0f5ea245374@github.com>

On Thu, 6 Jul 2023 20:07:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a default method `java.io.Closeable::closeUnchecked` which is equivalent to `Closeable::close` except that it instead throws `java.io.UncheckedIOException`.

src/java.base/share/classes/java/io/Closeable.java line 72:

> 70:      * Therefore if an {@linkplain UncheckedIOException} is thrown then its
> 71:      * {@linkplain UncheckedIOException#getCause() getCause} method will return the
> 72:      * {@linkplain IOException} thrown by {@link #close() close}.

These links should all be `@link` as they should be rendered like code like the `{@code IOException}` below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14789#discussion_r1255091952

From liach at openjdk.org  Fri Jul  7 01:25:55 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jul 2023 01:25:55 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v6]
In-Reply-To: <Anj1ssF095UKbmbUdB83JMl5zJQl3a9GW74JuSidrz0=.d21e15fe-50ce-4e55-aa17-8e7974d123ac@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <hY2cN_-xxTyqNZz1AMJC_klQyMPX36UVsjc1c5zSK58=.91762031-9a5d-40c2-b794-423112785629@github.com>
 <Anj1ssF095UKbmbUdB83JMl5zJQl3a9GW74JuSidrz0=.d21e15fe-50ce-4e55-aa17-8e7974d123ac@github.com>
Message-ID: <MR__8GPxX3tqqmD5CaY0s4AJ2j1B_7JtfkbS0k1wFnA=.a2349fc8-2298-4d1b-b2fa-e4be097c4487@github.com>

On Sat, 1 Jul 2023 23:32:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> /integrate

A "reviewer" means a role in the jdk project in the OpenJDK organization: https://openjdk.org/census#jdk

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1624502704

From jlu at openjdk.org  Fri Jul  7 01:36:10 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 7 Jul 2023 01:36:10 GMT
Subject: Integrated: 8310923: Refactor Currency tests to use JUnit
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: <luD1BoKNWPX-r4oxKJrBlQWfnKEfjIDaQAo2NJivlxE=.7badbe3b-632b-4056-a222-0c13e5ff4904@github.com>

On Tue, 27 Jun 2023 19:04:35 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.

This pull request has now been integrated.

Changeset: e848d947
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e848d9471f5de86e5ac157b710cd7371f12f0024
Stats:     1089 lines in 9 files changed: 436 ins; 372 del; 281 mod

8310923: Refactor Currency tests to use JUnit

Reviewed-by: naoto, lancea

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

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

From liach at openjdk.org  Fri Jul  7 02:21:17 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jul 2023 02:21:17 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v21]
In-Reply-To: <njwxOJWKkee2RJ2xpg8EUhnechvTCiUcuOGP7LFg1I0=.9d577955-f908-47b7-a947-d501c1957b04@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <njwxOJWKkee2RJ2xpg8EUhnechvTCiUcuOGP7LFg1I0=.9d577955-f908-47b7-a947-d501c1957b04@github.com>
Message-ID: <UFU0GE51MdIrmT9QcxJruYvCmJD9EbU5ZqhU2pi-niA=.6644bfc6-f6e0-42f9-b675-ad0d5b3f6f11@github.com>

On Thu, 6 Jul 2023 16:12: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 48 commits:
> 
>  - Spec update, also fix broken null behaviors
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'mh-proxies' of https://github.com/mlchung/jdk into explore/mhp-iface
>  - store a WeakReference holder in the class value
>  - Merge branch 'master' into explore/mhp-iface
>  - stage
>    
>    Signed-off-by: liach <liach at users.noreply.github.com>
>  - Review comments
>  - 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.
>  - ... and 38 more: https://git.openjdk.org/jdk/compare/97e99f01...571e1fa6

The spec change was for:
1. The spec is already updated for the hidden class IAE requirement, which is already the existing behavior (from j.l.r.Proxy)
2. That Jorn suggests to change implNote.

If I revert the spec changes, I will revert the IAE for hidden interface note as well; it's already existing behavior. I will adjust the CSR to be purely behavioral for the differences under reflection inspection (Object vs Proxy superclass, no more marker interfaces)

I think the spec in baseline is consistent with the implementation, both new and old. I think the spec itself does need some update, like the `Class::forName` specification: it has a few redundancies and inaccuracies.

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

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

From mchung at openjdk.org  Fri Jul  7 02:57:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 7 Jul 2023 02:57:16 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v21]
In-Reply-To: <njwxOJWKkee2RJ2xpg8EUhnechvTCiUcuOGP7LFg1I0=.9d577955-f908-47b7-a947-d501c1957b04@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <njwxOJWKkee2RJ2xpg8EUhnechvTCiUcuOGP7LFg1I0=.9d577955-f908-47b7-a947-d501c1957b04@github.com>
Message-ID: <cXS2W0CNj-YMVeY40kF1kE5JXWSTpRG9ftV1kq5ffQ8=.b13cca7e-196a-4d04-a3f0-17c939dc8155@github.com>

On Thu, 6 Jul 2023 16:12: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 48 commits:
> 
>  - Spec update, also fix broken null behaviors
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'mh-proxies' of https://github.com/mlchung/jdk into explore/mhp-iface
>  - store a WeakReference holder in the class value
>  - Merge branch 'master' into explore/mhp-iface
>  - stage
>    
>    Signed-off-by: liach <liach at users.noreply.github.com>
>  - Review comments
>  - 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.
>  - ... and 38 more: https://git.openjdk.org/jdk/compare/97e99f01...571e1fa6

The diff of the javadoc touches many lines.   I prefer to keep this PR focus on the implementation change.  It's okay to keep IAE for the hidden class and a small spec change.   Or you can take IAE for hidden interface out and do it in a separate PR - either way is fine with me.   I'm not sure if that implementation details should be an implNote and nothing significant for users to be aware of.

For the specification clarification unrelated to this PR, it should be a separate issue.

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

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

From djelinski at openjdk.org  Fri Jul  7 05:26:53 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 7 Jul 2023 05:26:53 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1
In-Reply-To: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
Message-ID: <Lgl9zEBhMRdb-PrkXxUxYk5zyG6wTxI8PpmgGh0ITGs=.cbbf8b80-6613-4bef-ba4b-52a42552e55c@github.com>

On Thu, 6 Jul 2023 21:40:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no guarantee as to how the underlying output stream actually writes the bytes provided to it.

This issue is reported against JDK 8 and 9. It was fixed in 16 with 17f04fc9. I think you can close it as duplicate.

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

PR Comment: https://git.openjdk.org/jdk/pull/14791#issuecomment-1624766495

From liach at openjdk.org  Fri Jul  7 06:45:46 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jul 2023 06:45:46 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v22]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <cKUEte7iDFjGSjnpWp4Otw-jr49x33S9JARZkrvWng8=.cfdd4210-9319-4f3b-b731-de2befc00eb2@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 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:

  Fix broken null behaviors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/571e1fa6..ca7b5630

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

  Stats: 132 lines in 1 file changed: 37 ins; 31 del; 64 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  Fri Jul  7 06:45:51 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jul 2023 06:45:51 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v21]
In-Reply-To: <njwxOJWKkee2RJ2xpg8EUhnechvTCiUcuOGP7LFg1I0=.9d577955-f908-47b7-a947-d501c1957b04@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <njwxOJWKkee2RJ2xpg8EUhnechvTCiUcuOGP7LFg1I0=.9d577955-f908-47b7-a947-d501c1957b04@github.com>
Message-ID: <-5aNRR68OnyQKvxd5erKADn2lueaArm4p9b90Dk1ZyE=.3e720ce1-bdd9-4025-bda5-4b7c05cdb3eb@github.com>

On Thu, 6 Jul 2023 16:12: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 48 commits:
> 
>  - Spec update, also fix broken null behaviors
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'mh-proxies' of https://github.com/mlchung/jdk into explore/mhp-iface
>  - store a WeakReference holder in the class value
>  - Merge branch 'master' into explore/mhp-iface
>  - stage
>    
>    Signed-off-by: liach <liach at users.noreply.github.com>
>  - Review comments
>  - 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.
>  - ... and 38 more: https://git.openjdk.org/jdk/compare/97e99f01...571e1fa6

I have force pushed a change that drops the spec changes and fixed a few incorrect behaviors with `null`; the force push is to avoid reduce the overall changes. 

The IAE for hidden interfaces spec is not included; it is already the existing behavior in master.

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

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

From mbaesken at openjdk.org  Fri Jul  7 07:00:05 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 7 Jul 2023 07:00:05 GMT
Subject: Integrated: 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: <5z7tycp2SolizjphgpOZ9dewDyUSx4kL-Ad-D9_fKZE=.0f5bda5f-2d9c-41cf-b6cd-dd4ee866aaf9@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.

This pull request has now been integrated.

Changeset: 25cbe85d
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25cbe85d6f46bed82c7f1266ce52c86943e29d60
Stats:     17 lines in 12 files changed: 0 ins; 8 del; 9 mod

8310550: Adjust references to rt.jar

Reviewed-by: erikj, clanger

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

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

From mli at openjdk.org  Fri Jul  7 08:31:56 2023
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 7 Jul 2023 08:31:56 GMT
Subject: RFR: 8311178: JMH tests don't scale well when sharing output
 buffers
In-Reply-To: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
References: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
Message-ID: <NAqYeoBo6lmu3_A16aV3Q8aCu5oMK1u7rG4UYUTWZEI=.f7b4bd90-95a5-4714-8604-f32f21adf0cf@github.com>

On Sat, 1 Jul 2023 07:53:17 GMT, Swati Sharma <duke at openjdk.org> wrote:

> The below benchmark files have scaling issues due to cache contention and leads to poor scaling when run on multiple threads. The patch sets the scope from benchmark level to thread level to fix the issue:
> - org/openjdk/bench/java/io/DataOutputStreamTest.java
> - org/openjdk/bench/java/lang/ArrayCopyObject.java
> - org/openjdk/bench/java/lang/ArrayFiddle.java
> - org/openjdk/bench/java/time/format/DateTimeFormatterBench.java
> - org/openjdk/bench/jdk/incubator/vector/IndexInRangeBenchmark.java
> - org/openjdk/bench/jdk/incubator/vector/MemorySegmentVectorAccess.java
> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedBenchmark.java
> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedIOOBEBenchmark.java
> - org/openjdk/bench/vm/compiler/ArrayFill.java
> - org/openjdk/bench/vm/compiler/IndexVector.java
> 
> Also removing the static scope for variables in org/openjdk/bench/jdk/incubator/vector/VectorFPtoIntCastOperations.java for better scaling.
> 
> Please review and share your feedback.
> 
> Thanks,
> Swati

Hi,
I'm not sure if I understand this improvement correctly.
I'm not quite familiar with JMH and it's annotations, but seems to me, the change from `@State(Scope.Benchmark)` to `@State(Scope.Thread)` should not improve the performance by reducing cache contention, as in the jmh doc it says "State objects are usually injected into Benchmark methods as ***arguments***, and JMH takes care of their instantiation and sharing.", this seems mean that @State only matters when the annotated class is used as a parameter of a @Benchmark method, but in the tests you modifed, seems there is no such use case.
Please also check the sample usages at https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_03_States.java.

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

PR Comment: https://git.openjdk.org/jdk/pull/14746#issuecomment-1625030990

From sgehwolf at openjdk.org  Fri Jul  7 08:40:47 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 7 Jul 2023 08:40:47 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present
Message-ID: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>

Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized).

The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime.

Basic usage example:

$ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
$ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
$ ls ../linux-x86_64-server-release/images/jdk/jmods
java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.management.jmod  jdk.jlink.jmod       jdk.naming.dns.jmod        jdk.unsupported.jmod
java.instrument.jmod      java.security.jgss.jmod  jdk.accessibility.jmod    jdk.httpserver.jmod        jdk.jartool.jmod                          jdk.jpackage.jmod    jdk.naming.rmi.jmod        jdk.xml.dom.jmod
java.logging.jmod         java.security.sasl.jmod  jdk.attach.jmod           jdk.incubator.vector.jmod  jdk.javadoc.jmod                          jdk.jshell.jmod      jdk.net.jmod               jdk.zipfs.jmod
java.management.jmod      java.se.jmod             jdk.charsets.jmod         jdk.internal.ed.jmod       jdk.jcmd.jmod                             jdk.jsobject.jmod    jdk.nio.mapmode.jmod
java.management.rmi.jmod  java.smartcardio.jmod    jdk.compiler.jmod         jdk.internal.jvmstat.jmod  jdk.jconsole.jmod                         jdk.jstatd.jmod      jdk.random.jmod
java.naming.jmod          java.sql.jmod            jdk.crypto.cryptoki.jmod  jdk.internal.le.jmod       jdk.jdeps.jmod                            jdk.localedata.jmod  jdk.sctp.jmod
$ ls jmods
ls: cannot access 'jmods': No such file or directory
$ ./bin/jlink --version
22-internal
$ ./bin/jlink --add-modules java.se --output ../build/java.se-runtime --verbose
java.base jrt:/java.base (jmod-less)
java.compiler jrt:/java.compiler (jmod-less)
java.datatransfer jrt:/java.datatransfer (jmod-less)
java.desktop jrt:/java.desktop (jmod-less)
java.instrument jrt:/java.instrument (jmod-less)
java.logging jrt:/java.logging (jmod-less)
java.management jrt:/java.management (jmod-less)
java.management.rmi jrt:/java.management.rmi (jmod-less)
java.naming jrt:/java.naming (jmod-less)
java.net.http jrt:/java.net.http (jmod-less)
java.prefs jrt:/java.prefs (jmod-less)
java.rmi jrt:/java.rmi (jmod-less)
java.scripting jrt:/java.scripting (jmod-less)
java.se jrt:/java.se (jmod-less)
java.security.jgss jrt:/java.security.jgss (jmod-less)
java.security.sasl jrt:/java.security.sasl (jmod-less)
java.sql jrt:/java.sql (jmod-less)
java.sql.rowset jrt:/java.sql.rowset (jmod-less)
java.transaction.xa jrt:/java.transaction.xa (jmod-less)
java.xml jrt:/java.xml (jmod-less)
java.xml.crypto jrt:/java.xml.crypto (jmod-less)

Providers:
  java.desktop provides java.net.ContentHandlerFactory used by java.base
  java.base provides java.nio.file.spi.FileSystemProvider used by java.base
  java.naming provides java.security.Provider used by java.base
  java.security.jgss provides java.security.Provider used by java.base
  java.security.sasl provides java.security.Provider used by java.base
  java.xml.crypto provides java.security.Provider used by java.base
  java.base provides java.util.random.RandomGenerator used by java.base
  java.management.rmi provides javax.management.remote.JMXConnectorProvider used by java.management
  java.management.rmi provides javax.management.remote.JMXConnectorServerProvider used by java.management
  java.desktop provides javax.print.PrintServiceLookup used by java.desktop
  java.desktop provides javax.print.StreamPrintServiceFactory used by java.desktop
  java.management provides javax.security.auth.spi.LoginModule used by java.base
  java.desktop provides javax.sound.midi.spi.MidiDeviceProvider used by java.desktop
  java.desktop provides javax.sound.midi.spi.MidiFileReader used by java.desktop
  java.desktop provides javax.sound.midi.spi.MidiFileWriter used by java.desktop
  java.desktop provides javax.sound.midi.spi.SoundbankReader used by java.desktop
  java.desktop provides javax.sound.sampled.spi.AudioFileReader used by java.desktop
  java.desktop provides javax.sound.sampled.spi.AudioFileWriter used by java.desktop
  java.desktop provides javax.sound.sampled.spi.FormatConversionProvider used by java.desktop
  java.desktop provides javax.sound.sampled.spi.MixerProvider used by java.desktop
  java.logging provides jdk.internal.logger.DefaultLoggerFinder used by java.base
  java.desktop provides sun.datatransfer.DesktopDatatransferService used by java.datatransfer


One nice property of this patch is that it can produce an identical (as in binary identical) `java.se` JDK image in "jmod-less" mode as compared to a regular jlink with packaged modules present. This has been asserted in newly added tests. In order to prevent accidental copy of modified files in the base JDK a checksum mechanism is in place to warn about this when jlinking. This is also asserted in tests.

One limitation of this mode is that there is no way to use it for cross-linking (at least currently). That is, a jmod-less `jlink` needs to happen on the same runtime platform the resulting image is intended to get deployed on.

Testing:
- [x] GHA (including `jdk/tools/jlink` tests). See for example [the latest run](https://github.com/jerboaa/jdk/actions/runs/5477743443) and [here](https://github.com/jerboaa/jdk/actions/runs/5475484765).
- [x] Some tests on our internal infra (JDK 17-based). It didn't show any regressions.
- [x] Added tests as part of the patch (8 of them). All pass on the major platforms.

Thoughts?

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

Commit messages:
 - 8311302: Allow for jlinking a custom runtime without packaged modules being present

Changes: https://git.openjdk.org/jdk/pull/14787/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311302
  Stats: 2083 lines in 23 files changed: 2016 ins; 33 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

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

From duke at openjdk.org  Fri Jul  7 08:47:11 2023
From: duke at openjdk.org (sid8606)
Date: Fri, 7 Jul 2023 08:47:11 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API
 (Preview)
Message-ID: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>

Implementation of "Foreign Function & Memory API" for s390x.

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

Commit messages:
 - Fix whitespace errors and boilerplate text
 - 8311630:[s390] Implementation of Foreign Function & Memory API (Preview)

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

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

From amitkumar at openjdk.org  Fri Jul  7 08:56:02 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 7 Jul 2023 08:56:02 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview)
In-Reply-To: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
Message-ID: <kEIl6ISM39TySUNbwZb7_5hVh-l_Nn2370roPJB7cxI=.c95eea46-36bc-4f82-a052-821b243ed2d4@github.com>

On Fri, 7 Jul 2023 07:55:03 GMT, sid8606 <duke at openjdk.org> wrote:

> Implementation of "Foreign Function & Memory API" for s390x.

Will run test, maybe you want to adopt these changes. That's it for now.

src/hotspot/cpu/s390/downcallLinker_s390.cpp line 2:

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

Please add the header-year back

src/hotspot/cpu/s390/downcallLinker_s390.cpp line 78:

> 76:     _frame_complete(0),
> 77:     _frame_size_slots(0),
> 78:     _oop_maps(NULL) {

replace NULL with `nullptr`

src/hotspot/cpu/s390/downcallLinker_s390.cpp line 105:

> 103:     bool needs_return_buffer,
> 104:     int captured_state_mask,
> 105:     bool needs_transition) {

maybe indent it back (?)

src/hotspot/cpu/s390/foreignGlobals_s390.cpp line 2:

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

Please add the header-year back

src/hotspot/cpu/s390/foreignGlobals_s390.cpp line 46:

> 44: bool ABIDescriptor::is_volatile_reg(FloatRegister reg) const {
> 45:   return _float_argument_registers.contains(reg)
> 46:     || _float_additional_volatile_registers.contains(reg);

maybe alignment needed (?)

src/hotspot/cpu/s390/frame_s390.cpp line 231:

> 229:   UpcallStub* blob = _cb->as_upcall_stub();
> 230:   JavaFrameAnchor* jfa = blob->jfa_for_frame(*this);
> 231:   return jfa->last_Java_sp() == NULL;

Replace NULL with nullptr

src/hotspot/cpu/s390/frame_s390.cpp line 235:

> 233: 
> 234: frame frame::sender_for_upcall_stub_frame(RegisterMap* map) const {
> 235:   assert(map != NULL, "map must be set");

use nullptr

src/java.base/share/classes/jdk/internal/foreign/abi/s390/S390Architecture.java line 3:

> 1: /*
> 2:  * Copyright (c) 2020, 2023, Oracle and/or its affiliates. All rights reserved.
> 3:  * Copyright (c) 2023 SAP SE. All rights reserved.

Add IBM's Copyrights ;-)

` Copyright (c) 2023, IBM Corp.`

src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390CallArranger.java line 3:

> 1: /*
> 2:  * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights reserved.
> 3:  * Copyright (c) 2023 SAP SE. All rights reserved.

Add IBM's copyright

src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390Linker.java line 3:

> 1: /*
> 2:  * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights reserved.
> 3:  * Copyright (c) 2023 SAP SE. All rights reserved.

Add IBM's copyright

src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/TypeClass.java line 3:

> 1: /*
> 2:  * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights reserved.
> 3:  * Copyright (c) 2023 SAP SE. All rights reserved.

Add IBM's copyright

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

Changes requested by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14801#pullrequestreview-1518282531
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255434276
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255447838
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255473422
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255435187
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255440455
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255449488
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255449998
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255464266
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255465193
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255465767
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255467623

From duke at openjdk.org  Fri Jul  7 10:01:20 2023
From: duke at openjdk.org (sid8606)
Date: Fri, 7 Jul 2023 10:01:20 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v2]
In-Reply-To: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
Message-ID: <t_D4CaM9h-wbAm-SvI4hQqCiNYUh1wR1_cVwDCA7GrE=.9793bbc5-2dfe-43fa-bd72-37430dd0c8a4@github.com>

> Implementation of "Foreign Function & Memory API" for s390x.

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

  Address Amit's review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14801/files
  - new: https://git.openjdk.org/jdk/pull/14801/files/68b2470b..e719c164

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

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

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

From duke at openjdk.org  Fri Jul  7 10:01:21 2023
From: duke at openjdk.org (sid8606)
Date: Fri, 7 Jul 2023 10:01:21 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v2]
In-Reply-To: <kEIl6ISM39TySUNbwZb7_5hVh-l_Nn2370roPJB7cxI=.c95eea46-36bc-4f82-a052-821b243ed2d4@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <kEIl6ISM39TySUNbwZb7_5hVh-l_Nn2370roPJB7cxI=.c95eea46-36bc-4f82-a052-821b243ed2d4@github.com>
Message-ID: <LbNgW7huiKP8_2cdsQGWAv8sEW2lEyetOfkVRnm3nJA=.495a8cf1-3c9c-4d03-abc8-df096c526b11@github.com>

On Fri, 7 Jul 2023 08:53:06 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Amit's review comments
>
> Will run test, maybe you want to adopt these changes. That's it for now.

Thank you @offamitkumar for quick reviews. I have addressed comments in new commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/14801#issuecomment-1625163831

From prappo at openjdk.org  Fri Jul  7 11:14:54 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 7 Jul 2023 11:14:54 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v2]
In-Reply-To: <sQMHonHDGXV9t_LBogY6AYWT6tu56sVHr9T6YOsIP6w=.1ac4bc77-f453-4586-8408-e879fea9a8a7@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <pTMvEIx5UPajYBUi4pCgN6CsyzVd6tlJhqcla4D3nV4=.c8aa7c9d-4bbe-482e-8b96-1423950105eb@github.com>
 <sQMHonHDGXV9t_LBogY6AYWT6tu56sVHr9T6YOsIP6w=.1ac4bc77-f453-4586-8408-e879fea9a8a7@github.com>
Message-ID: <uYc7epqNkrTHCwDq0A8qFmJ_IID32OiS23IYqUxPjxY=.172cb723-2510-44d5-ac78-90b11b85ebc6@github.com>

On Wed, 5 Jul 2023 12:57:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Unfortunately, we don't have mid-layer methods in between Arrays.hashCode and ArraysSupport.vectorizedHashCode like that of Arrays.mismatch and ArraysSupport.vectorizedMismatch. It's either all the null check but short-circuits or unconditional vectorization but the initial value. I wonder if we could consider `ArraysSupport.hashCode($type[] array, int fromIndex, int length, int initialValue)` overloads, which could be useful beyond BigInteger, as I've already seen in JDK. Contributors to ArraysSupport, @PaulSandoz, @ChrisHegarty, @cl4es, @stuart-marks; thoughts?

Here are a few more examples of code that could benefit from such a mid-layer API:
* https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
* https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
* https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362

While we are here, shouldn't this be called `unsignedHashCode` rather than `signedHashCode`?

https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java#L214-L220

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

PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1625253882

From jlaskey at openjdk.org  Fri Jul  7 11:49:22 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 7 Jul 2023 11:49:22 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v6]
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: <X-6j5WPseJftucqEE8WgBxTw_bQf-VhkUNKtsdgBDDs=.3ca2eb44-ea46-4a90-b6db-f9329e478be2@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:

  Simple versions of create

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14684/files
  - new: https://git.openjdk.org/jdk/pull/14684/files/f4854011..8eff9183

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

  Stats: 36 lines in 3 files changed: 33 ins; 2 del; 1 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 stuefe at openjdk.org  Fri Jul  7 13:10:48 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Jul 2023 13:10:48 GMT
Subject: [jdk21] RFR: 8310265: (process) jspawnhelper should not use argv[0]
Message-ID: <nAGfR2uVy01teyKxqJEGKQvcwju3k1j4OhvJf_cvb0w=.754d9523-96af-49c1-9a43-bd283314ad8c@github.com>

Hi all,

Clean backport for JDK-83210265.

Thanks!

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

Commit messages:
 - Backport 47d00a4cbeff5d757dda9c660dfd2385c02a57d7

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

PR: https://git.openjdk.org/jdk21/pull/103

From jvernee at openjdk.org  Fri Jul  7 13:13:06 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Jul 2023 13:13:06 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v2]
In-Reply-To: <t_D4CaM9h-wbAm-SvI4hQqCiNYUh1wR1_cVwDCA7GrE=.9793bbc5-2dfe-43fa-bd72-37430dd0c8a4@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <t_D4CaM9h-wbAm-SvI4hQqCiNYUh1wR1_cVwDCA7GrE=.9793bbc5-2dfe-43fa-bd72-37430dd0c8a4@github.com>
Message-ID: <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>

On Fri, 7 Jul 2023 10:01:20 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x.
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Amit's review comments

Overall looks great! I'd mostly like to understand what's going on with: https://github.com/openjdk/jdk/pull/14801#discussion_r1255718844

src/hotspot/cpu/s390/downcallLinker_s390.cpp line 159:

> 157:   int allocated_frame_size = 0;
> 158:   assert(_abi._shadow_space_bytes == frame::z_abi_160_size, "expected space according to ABI");
> 159:   allocated_frame_size = frame::z_abi_160_size;

I'm assuming that the 160 byte space is part of the C ABI, not the Java ABI, right? In that case you could just use `_abi._shadow_space_bytes` here, as this code doesn't necessarily know it's calling into C. i.e. that knowledge is captured in the Java code.

src/hotspot/cpu/s390/downcallLinker_s390.cpp line 162:

> 160:   allocated_frame_size += arg_shuffle.out_arg_bytes();
> 161: 
> 162:   bool should_save_return_value = !_needs_return_buffer && _needs_transition;;

Since return buffer is not implemented here, I suggest adding an assert that checks that `_needs_return_buffer` is always false.

src/hotspot/cpu/s390/downcallLinker_s390.cpp line 207:

> 205:   __ z_lg(callerSP, _z_abi(callers_sp), Z_SP); // preset (used to access caller frame argument slots)
> 206:   __ block_comment("{ argument shuffle");
> 207:   arg_shuffle.generate(_masm, as_VMStorage(callerSP), frame::z_jit_out_preserve_size, _abi._shadow_space_bytes, locs);

I'm not sure exactly what `callerSP` is doing, but it seems to be Z_SP + bias? Why can't the `in_stk_bias` parameter be used for that? (and then use `tmp` for the shuffle reg).

src/hotspot/cpu/s390/foreignGlobals_s390.cpp line 115:

> 113:   switch (to_reg.type()) {
> 114:     case StorageType::INTEGER:
> 115:       if (to_reg.segment_mask() == REG64_MASK && from_reg.segment_mask() == REG32_MASK ) {

Since this deals with 32 bit regs as well, might want to rename the function to just `move_reg` (i.e drop the `64`)

src/hotspot/cpu/s390/foreignGlobals_s390.cpp line 186:

> 184:     case StorageType::FRAME_DATA: {
> 185:       switch (from_reg.stack_size()) {
> 186:         case 8: __ mem2reg_opt(Z_R0_scratch, Address (callerSP, reg2offset(from_reg, in_stk_bias)), true); break;

A potential issue here is that Z_R0_scratch could be used by the target ABI, that's why the shuffle register is passed as an argument on other platforms. (It also makes it clearer in the calling code that that register is used somehow).

src/hotspot/cpu/s390/upcallLinker_s390.cpp line 141:

> 139: 
> 140:   // The Java call uses the JIT ABI, but we also call C.
> 141:   int out_arg_area = MAX2(frame::z_jit_out_preserve_size + arg_shuffle.out_arg_bytes(), (int)frame::z_abi_160_size);

What do you mean here with "but we also call C"? Upcall stubs are always calling into Java, though the source ABI is unknown.

src/hotspot/cpu/s390/upcallLinker_s390.cpp line 172:

> 170:   //      |---------------------| = frame_bottom_offset = frame_size
> 171:   //      | (optional)          |
> 172:   //      | ret_buf             |

There's no return buffer, so this can be removed.

src/hotspot/cpu/s390/upcallLinker_s390.cpp line 232:

> 230: 
> 231:   // return value shuffle
> 232:   if (!needs_return_buffer) {

I suggest using an assert here instead.

src/hotspot/cpu/s390/upcallLinker_s390.cpp line 243:

> 241:         case T_CHAR:
> 242:         case T_INT:
> 243:           __ z_lgfr(Z_RET, Z_RET); // Clear garbage in high half.

Same as PPC here; this should really be done on the Java side. (See: https://github.com/openjdk/jdk/pull/12708#issuecomment-1440433079 and related discussion)

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 78:

> 76:     @CallerSensitive
> 77:     public final MethodHandle downcallHandle(MemorySegment symbol, FunctionDescriptor function, Option... options) {
> 78:     Reflection.ensureNativeAccess(Reflection.getCallerClass(), Linker.class, "downcallHandle");

Looks spurious? Please undo

src/java.base/share/classes/jdk/internal/foreign/abi/s390/S390Architecture.java line 115:

> 113: 
> 114:     private static VMStorage floatRegister(int index) {
> 115:         return new VMStorage(StorageType.FLOAT, REG64_MASK, index, "v" + index);

Maybe this should be `"f"` instead of `"v"`? (given the names of the variables above)
Suggestion:

        return new VMStorage(StorageType.FLOAT, REG64_MASK, index, "f" + index);

src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390CallArranger.java line 136:

> 134:         return returnLayout
> 135:             .filter(GroupLayout.class::isInstance)
> 136:             .filter(layout -> layout instanceof GroupLayout)

These lines both do the same, so one can be removed.

src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/TypeClass.java line 114:

> 112:                 return false;
> 113:                     }
> 114:         }

I believe this loop is not needed, since above it's determined that `scalarLayouts` has only 1 element.

test/jdk/java/foreign/TestClassLoaderFindNative.java line 63:

> 61:     public void testVariableSymbolLookup() {
> 62:         MemorySegment segment = SymbolLookup.loaderLookup().find("c").get().reinterpret(ByteOrder.nativeOrder() == ByteOrder.LITTLE_ENDIAN ? 1 : 4);
> 63:         assertEquals(segment.get(JAVA_BYTE, ByteOrder.nativeOrder() == ByteOrder.LITTLE_ENDIAN ? 0 : 3), 42);

Could you explain why this is needed? It looks like the lookup is returning the wrong address?

test/jdk/java/foreign/TestIllegalLink.java line 57:

> 55: 
> 56:     private static final boolean IS_SYSV = CABI.current() == CABI.SYS_V;
> 57:     private static final boolean byteorder = ByteOrder.nativeOrder() == ByteOrder.LITTLE_ENDIAN;

Please rename this field to something more descriptive, e.g. `IS_LE` (and capitalize).

test/jdk/java/foreign/TestLayouts.java line 46:

> 44: public class TestLayouts {
> 45: 
> 46:     boolean byteorder = ByteOrder.nativeOrder() == ByteOrder.LITTLE_ENDIAN;

Same here

test/jdk/java/foreign/callarranger/platform/PlatformLayouts.java line 312:

> 310:      * This class defines layout constants modelling standard primitive types supported by the S390 ABI.
> 311:      */
> 312:     public static final class S390 {

These are only needed if you plan on adding a CallArranger test as well.

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

PR Review: https://git.openjdk.org/jdk/pull/14801#pullrequestreview-1518533244
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255680103
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255712765
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255718844
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255660955
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255723226
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255733518
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255735380
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255735815
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255743888
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255645400
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255640717
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255629673
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255624777
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255619049
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255619320
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255620308
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255621583

From rriggs at openjdk.org  Fri Jul  7 13:31:04 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Jul 2023 13:31:04 GMT
Subject: [jdk21] RFR: 8310265: (process) jspawnhelper should not use
 argv[0]
In-Reply-To: <nAGfR2uVy01teyKxqJEGKQvcwju3k1j4OhvJf_cvb0w=.754d9523-96af-49c1-9a43-bd283314ad8c@github.com>
References: <nAGfR2uVy01teyKxqJEGKQvcwju3k1j4OhvJf_cvb0w=.754d9523-96af-49c1-9a43-bd283314ad8c@github.com>
Message-ID: <2L7d-o6OnIL1FmUA1iBtyqEzd65H9V_6vNP-dbc6WAs=.0f68dd76-5546-425a-9f65-feb22f2687f7@github.com>

On Thu, 6 Jul 2023 19:42:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi all,
> 
> Clean backport for JDK-83210265.
> 
> Thanks!

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/103#pullrequestreview-1518889288

From stuefe at openjdk.org  Fri Jul  7 13:46:01 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Jul 2023 13:46:01 GMT
Subject: [jdk21] RFR: 8310265: (process) jspawnhelper should not use
 argv[0]
In-Reply-To: <2L7d-o6OnIL1FmUA1iBtyqEzd65H9V_6vNP-dbc6WAs=.0f68dd76-5546-425a-9f65-feb22f2687f7@github.com>
References: <nAGfR2uVy01teyKxqJEGKQvcwju3k1j4OhvJf_cvb0w=.754d9523-96af-49c1-9a43-bd283314ad8c@github.com>
 <2L7d-o6OnIL1FmUA1iBtyqEzd65H9V_6vNP-dbc6WAs=.0f68dd76-5546-425a-9f65-feb22f2687f7@github.com>
Message-ID: <3bST-yTO6IXCfPrZ2riXllltD-pbfSwzyoJI1LZHz_4=.3b07cc25-9214-439c-95c3-e3512d2ee93c@github.com>

On Fri, 7 Jul 2023 13:27:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Hi all,
>> 
>> Clean backport for JDK-83210265.
>> 
>> Thanks!
>
> Marked as reviewed by rriggs (Reviewer).

Thank you @RogerRiggs !

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

PR Comment: https://git.openjdk.org/jdk21/pull/103#issuecomment-1625435021

From stuefe at openjdk.org  Fri Jul  7 13:46:03 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Jul 2023 13:46:03 GMT
Subject: [jdk21] Integrated: 8310265: (process) jspawnhelper should not use
 argv[0]
In-Reply-To: <nAGfR2uVy01teyKxqJEGKQvcwju3k1j4OhvJf_cvb0w=.754d9523-96af-49c1-9a43-bd283314ad8c@github.com>
References: <nAGfR2uVy01teyKxqJEGKQvcwju3k1j4OhvJf_cvb0w=.754d9523-96af-49c1-9a43-bd283314ad8c@github.com>
Message-ID: <c2yfeMobcdKtYgv0LZPj6KP6ZP09qNa4rLxB53Rw5ZA=.e3bc4d02-6b6f-4f63-b386-11d4fd2babdb@github.com>

On Thu, 6 Jul 2023 19:42:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi all,
> 
> Clean backport for JDK-83210265.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 6ef80168
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/6ef801683844e5cc06804d51060ed81b1e8f3cc5
Stats:     10 lines in 2 files changed: 4 ins; 0 del; 6 mod

8310265: (process) jspawnhelper should not use argv[0]

Reviewed-by: rriggs
Backport-of: 47d00a4cbeff5d757dda9c660dfd2385c02a57d7

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

PR: https://git.openjdk.org/jdk21/pull/103

From coffeys at openjdk.org  Fri Jul  7 13:47:31 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 7 Jul 2023 13:47:31 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v9]
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: <ooM2-22ytP1MzjcRPBnPOgV0MOxSMqD251QsQkbuhto=.cc8dfe89-4831-49ed-b3ce-3f7722ea562b@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 17 additional commits since the last revision:

 - tweaks based on latest reviews
 - Merge branch 'master' into 8281658-showsettings-security
 - 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.
 - ... and 7 more: https://git.openjdk.org/jdk/compare/f233ca46...c563e18e

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14394/files
  - new: https://git.openjdk.org/jdk/pull/14394/files/7e6f5090..c563e18e

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

  Stats: 50304 lines in 563 files changed: 5893 ins; 41788 del; 2623 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 Jul  7 13:47:31 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 7 Jul 2023 13:47:31 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v8]
In-Reply-To: <sesMMIlaEim4JwvkNJnM5Vjl65_eXZ3af_9X2UzOR5c=.09a13afe-87e3-4b23-832c-d5edd80bca0c@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <Do1PCxXWlOkJ92jocEgyrtJsJZ2lQkJXgFDEFd0mxAc=.f4957955-4d6b-4066-8b94-50e47a7e96f8@github.com>
 <rsK3bo2OtxGtMNdH4oNR3c-acbpFl9ki1mBzG4_x8wY=.5251d1ac-f83f-4b78-82b6-5dec965186c9@github.com>
 <sesMMIlaEim4JwvkNJnM5Vjl65_eXZ3af_9X2UzOR5c=.09a13afe-87e3-4b23-832c-d5edd80bca0c@github.com>
Message-ID: <RL_OQDUQIZ1NOOdBZ4ZGK2BzGvWULBrjgNZjzK2gLoc=.91d27f40-4015-43f8-9363-c6f25c3b81be@github.com>

On Thu, 6 Jul 2023 17:15:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > 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.
> 
> I think throwing an error for an invalid suboption makes sense. `-XshowSetting` without the suboption is default to print all settings, i.e. equivalent to `-XshowSetting:all`. But the switch statment is missing the `all` case. I think we should fix this and error for any invalid option.

fair point Mandy - I hope to change such behavior in a new follow on patch that I'll deliver shortly: JDK-8311653

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

PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1625434995

From coffeys at openjdk.org  Fri Jul  7 13:47:34 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 7 Jul 2023 13:47:34 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v8]
In-Reply-To: <RwiedzZlfLbLBW48WCNl6vsQ6pSmhCn8r3oGx2hhyqE=.0cfe558a-7ca4-438b-abf3-648db5e24097@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <Do1PCxXWlOkJ92jocEgyrtJsJZ2lQkJXgFDEFd0mxAc=.f4957955-4d6b-4066-8b94-50e47a7e96f8@github.com>
 <RwiedzZlfLbLBW48WCNl6vsQ6pSmhCn8r3oGx2hhyqE=.0cfe558a-7ca4-438b-abf3-648db5e24097@github.com>
Message-ID: <bqjogccbwF7UwWeiFmRzAJka2_2Gr-HjVfEIvAjpW6k=.cb61541d-7cb7-4252-a131-3b7dddf68d87@github.com>

On Thu, 6 Jul 2023 18:43:41 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 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/774eb316...7e6f5090
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 115:
> 
>> 113:     private static StringBuilder outBuf = new StringBuilder();
>> 114: 
>> 115:     private static final String INDENT = " ".repeat(4);
> 
> Revert this, its just making a simple constant into a runtime expression.

Thanks Roger. Fair point. Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1255844148

From coffeys at openjdk.org  Fri Jul  7 13:47:35 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 7 Jul 2023 13:47:35 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v8]
In-Reply-To: <nSqaed-WJKu7WbYdZd1yAN9xIHqwK17Aq8cHd-HpBeQ=.3d484325-dd74-4ea6-9580-ce8dca2fedd9@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <Do1PCxXWlOkJ92jocEgyrtJsJZ2lQkJXgFDEFd0mxAc=.f4957955-4d6b-4066-8b94-50e47a7e96f8@github.com>
 <nSqaed-WJKu7WbYdZd1yAN9xIHqwK17Aq8cHd-HpBeQ=.3d484325-dd74-4ea6-9580-ce8dca2fedd9@github.com>
Message-ID: <9G_72rcKvOLsqveLtQOM5yxUBIeuKEZQGGrMjRSLk5o=.efe5f084-bc39-4ba3-84d9-ae52e7eb46eb@github.com>

On Thu, 6 Jul 2023 14:03:12 GMT, Sean Mullan <mullan 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 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/774eb316...7e6f5090
>
> src/java.base/share/classes/sun/launcher/SecuritySettings.java line 123:
> 
>> 121:         }
>> 122: 
>> 123:         ostream.println(INDENT + "Security TLS configuration:");
> 
> What about also noting the name of the TLS/JSSE provider in this line, for example:
> 
> "Security TLS configuration (SunJSSE provider):"
> 
> This would be useful information if a customer is using a 3rd party JSSE provider, and it is selected before SunJSSE, as the defaults in that case may be different.

good suggestion Sean. Patch updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1255842787

From rriggs at openjdk.org  Fri Jul  7 14:23:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Jul 2023 14:23:54 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1
In-Reply-To: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
Message-ID: <CN_eDr4hn06aPLpQErLX8TD5qQAYKsAuatQDvfVPy4Q=.b6b6a07f-0cae-4244-96c3-337f9faa9e0d@github.com>

On Thu, 6 Jul 2023 21:40:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no guarantee as to how the underlying output stream actually writes the bytes provided to it.

src/java.base/share/classes/java/io/DataOutputStream.java line 44:

> 42:  * the underlying output stream, hence there is no guarantee as to
> 43:  * the details of how the bytes are written.
> 44:  *

I'd drop "merely".

I would not want to give any assurances about whether the bytes of an encoded primitive were written individually or as a group.  
For the primitive types the value is encoded and written as one or more bytes to the underlying stream.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14791#discussion_r1255901199

From ryan at iernst.net  Fri Jul  7 14:25:16 2023
From: ryan at iernst.net (Ryan Ernst)
Date: Fri, 7 Jul 2023 07:25:16 -0700
Subject: List extending Collection/SequencedCollection
In-Reply-To: <d40456ff-c11d-dcb8-417e-4c44f9473e11@oracle.com>
References: <d40456ff-c11d-dcb8-417e-4c44f9473e11@oracle.com>
Message-ID: <1AD8CF66-B7E7-4793-8608-92D4F90CA66F@iernst.net>

Thanks for laying out your thinking, Joe. I will watch your talks. 

If I understood your response correctly, you are ok making such a change, especially since it is semantically equivalent? If that?s the case, is JDK 21 past the point of feature release, or should the change target only 22? It doesn?t matter much to me, but I thought since SequencedCollection is added in 21 it would be good to ?fix? this there so as to avoid a gap in behavior. 



> On Jun 30, 2023, at 6:13 PM, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
> 
> ?Hi Ryan,
> 
> Apropos of this discussion, I happened to recently give a talk to the JCP that in part covered behavioral compatibility in the JDK:
> 
> https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-06-13/JCP-EC-Public-Agenda-June-2023.html
> https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-06-13/Contributing_to_OpenJDK_2023_04_12.pdf
> 
> There are many observable details of the JDK implementation, including reflective details, timing, etc. there are _not_ part of the interfaces users should rely on.
> 
> My current evaluation here is that it would set an unfortunate precedent to preclude making the sort of source changes in questions because of (potential) compatibility concerns in reflective modeling, especially in a feature release. (IMO, there is a stronger argument for not making such a change in an update release, but even there as the change is a semantically equivalent refactoring, I think it is generally fine.)
> 
> HTH,
> 
> -Joe
> 
>> On 6/29/2023 11:30 AM, Ryan Ernst wrote:
>> 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 duke at openjdk.org  Fri Jul  7 14:38:00 2023
From: duke at openjdk.org (sid8606)
Date: Fri, 7 Jul 2023 14:38:00 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v2]
In-Reply-To: <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <t_D4CaM9h-wbAm-SvI4hQqCiNYUh1wR1_cVwDCA7GrE=.9793bbc5-2dfe-43fa-bd72-37430dd0c8a4@github.com>
 <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
Message-ID: <6QyvVMmV5y98wD5_BsFRVEL9-GFXUcOm5_pc0dRtQBw=.8a7e4b93-0633-4333-a1aa-f3af865f073d@github.com>

On Fri, 7 Jul 2023 10:32:54 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Amit's review comments
>
> test/jdk/java/foreign/TestClassLoaderFindNative.java line 63:
> 
>> 61:     public void testVariableSymbolLookup() {
>> 62:         MemorySegment segment = SymbolLookup.loaderLookup().find("c").get().reinterpret(ByteOrder.nativeOrder() == ByteOrder.LITTLE_ENDIAN ? 1 : 4);
>> 63:         assertEquals(segment.get(JAVA_BYTE, ByteOrder.nativeOrder() == ByteOrder.LITTLE_ENDIAN ? 0 : 3), 42);
> 
> Could you explain why this is needed? It looks like the lookup is returning the wrong address?

Since  s390x runs in Big Endian mode. We get LSB on higher address of integer size.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255921714

From rriggs at openjdk.org  Fri Jul  7 14:40:16 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Jul 2023 14:40:16 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v5]
In-Reply-To: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
Message-ID: <fGqDBJqsa9w-w2lm7dnlbmN_So7alDP5cDwcAO2zsBg=.d7b4aad1-63cf-4e40-9fbd-21551ce0b0d7@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 ten additional commits since the last revision:

 - Improve the grammar of "the comparator value is" -> "the comparator value, that is"
   Thanks for the reminder.
 - Merge branch 'master' into 8310033-time-compareto
 - Improve descriptions to be more specific and remove inappropriate use of before/after
   Remove extra blank lines
 - Clarify return values of date time classes
 - 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/62f01b5d..71dc98ae

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

  Stats: 26834 lines in 1236 files changed: 13236 ins; 6372 del; 7226 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 coffeys at openjdk.org  Fri Jul  7 14:53:00 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 7 Jul 2023 14:53:00 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v8]
In-Reply-To: <9G_72rcKvOLsqveLtQOM5yxUBIeuKEZQGGrMjRSLk5o=.efe5f084-bc39-4ba3-84d9-ae52e7eb46eb@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <Do1PCxXWlOkJ92jocEgyrtJsJZ2lQkJXgFDEFd0mxAc=.f4957955-4d6b-4066-8b94-50e47a7e96f8@github.com>
 <nSqaed-WJKu7WbYdZd1yAN9xIHqwK17Aq8cHd-HpBeQ=.3d484325-dd74-4ea6-9580-ce8dca2fedd9@github.com>
 <9G_72rcKvOLsqveLtQOM5yxUBIeuKEZQGGrMjRSLk5o=.efe5f084-bc39-4ba3-84d9-ae52e7eb46eb@github.com>
Message-ID: <klbs820bM_JNz8A3lqFKIx5q2O8wNTQ22mMP8HiPoAg=.e1db0dfc-9300-4d9c-9d65-19ca6e06145b@github.com>

On Fri, 7 Jul 2023 13:40:53 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/SecuritySettings.java line 123:
>> 
>>> 121:         }
>>> 122: 
>>> 123:         ostream.println(INDENT + "Security TLS configuration:");
>> 
>> What about also noting the name of the TLS/JSSE provider in this line, for example:
>> 
>> "Security TLS configuration (SunJSSE provider):"
>> 
>> This would be useful information if a customer is using a 3rd party JSSE provider, and it is selected before SunJSSE, as the defaults in that case may be different.
>
> good suggestion Sean. Patch updated.

I think we need to harden this area of code actually. Some JDK configurations may not have an SSL provider.

e.g. (removing JSSE from config)   


    See "java -X" for verbose security settings options
    Security provider static configuration: (in order of preference)
        Provider name: SUN
        Provider name: SunRsaSign
Exception in thread "main" java.lang.InternalError: Failed to create SSL socket
	at java.base/sun.launcher.SecuritySettings.printSecurityTLSConfig(SecuritySettings.java:121)
	at java.base/sun.launcher.SecuritySettings.printSecuritySummarySettings(SecuritySettings.java:75)
	at java.base/sun.launcher.LauncherHelper.showSettings(LauncherHelper.java:188)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1255945485

From duke at openjdk.org  Fri Jul  7 14:58:00 2023
From: duke at openjdk.org (sid8606)
Date: Fri, 7 Jul 2023 14:58:00 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v2]
In-Reply-To: <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <t_D4CaM9h-wbAm-SvI4hQqCiNYUh1wR1_cVwDCA7GrE=.9793bbc5-2dfe-43fa-bd72-37430dd0c8a4@github.com>
 <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
Message-ID: <u9rVr_KhMSKN42SM_XoNt-1zXq2HIjyB4OLmLIK1CTI=.7a252b72-bb50-4bdd-a686-db7ad76a4985@github.com>

On Fri, 7 Jul 2023 12:15:39 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Amit's review comments
>
> src/hotspot/cpu/s390/upcallLinker_s390.cpp line 141:
> 
>> 139: 
>> 140:   // The Java call uses the JIT ABI, but we also call C.
>> 141:   int out_arg_area = MAX2(frame::z_jit_out_preserve_size + arg_shuffle.out_arg_bytes(), (int)frame::z_abi_160_size);
> 
> What do you mean here with "but we also call C"? Upcall stubs are always calling into Java, though the source ABI is unknown.

We do native calls in this stub, so make sure allocated stack is big enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1255953719

From rriggs at openjdk.org  Fri Jul  7 15:15:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Jul 2023 15:15:55 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v6]
In-Reply-To: <hY2cN_-xxTyqNZz1AMJC_klQyMPX36UVsjc1c5zSK58=.91762031-9a5d-40c2-b794-423112785629@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <hY2cN_-xxTyqNZz1AMJC_klQyMPX36UVsjc1c5zSK58=.91762031-9a5d-40c2-b794-423112785629@github.com>
Message-ID: <90SkXhk3AttjkCDs26NYiysShCkPfCyyi2mYeY432Mw=.c9bac184-e20c-4533-a288-fdb70eaa0a73@github.com>

On Sat, 1 Jul 2023 14:42:07 GMT, ??? <duke at openjdk.org> wrote:

>> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.util.UUIDBench.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)
>> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
>> 
>> 
>> ## 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)
>> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
>> 
>> 
>> 
>> ## 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)
>> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
>> 
>> 
>> ## 4. MacBookPro M1 Pro
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
>> 
>> 
>> ## 5. Orange Pi 5 Plus
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
>> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code style

src/java.base/share/classes/java/util/HexDigits.java line 44:

> 42:      *       0 -> '00' -> ('0' << 8) | '0' -> 0x3030
> 43:      *       1 -> '01' -> ('0' << 8) | '1' -> 0x3130
> 44:      *       2 -> '02' -> ('0' << 8) | '2' -> 0x3230

The description of the array content does not need to be exhaustive; just sufficient to understand how it is indexed and the meaning of the values.

src/java.base/share/classes/java/util/HexDigits.java line 108:

> 106:      * Return a big-endian packed integer for the 4 ASCII bytes for an input unsigned 2-byte integer.
> 107:      * {@code b0} is the most significant byte and {@code b1} is the least significant byte.
> 108:      * The integer is passed byte-wise to allow reordering of execution.

The more natural API would be to pass the 16-bit value as an int (or short). Simplifying the callers.
Is there a significant performance difference?
The extraction of the 8-bit values could be done here instead of the caller and still allow hardware specific instruction optimization.

Also below, pass the 32-bit value as an int.

src/java.base/share/classes/java/util/HexDigits.java line 116:

> 114:     /**
> 115:      * Return a big-endian packed long for the 8 ASCII bytes for an input unsigned 4-byte integer.
> 116:      * {@code b0} is the most significant byte and {@code b4} is the least significant byte.

Typo "b4" -> "b3".

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

> 473:         long msb = mostSigBits;
> 474:         byte[] buf = new byte[36];
> 475:         UNSAFE.putLongUnaligned(

I understood that since UUID was not used during startup, that using VarHandles is the preferred abstraction.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1255985815
PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1255966155
PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1255962869
PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1255980037

From bpb at openjdk.org  Fri Jul  7 15:29:57 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 7 Jul 2023 15:29:57 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1
In-Reply-To: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
Message-ID: <Exys2W0FofMsIZQWlNT6IeSlCnAcBHqKLrpxGosj79A=.a531123e-c797-4d79-a29a-c1b8ebe63d7e@github.com>

On Thu, 6 Jul 2023 21:40:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no guarantee as to how the underlying output stream actually writes the bytes provided to it.

> This issue is reported against JDK 8 and 9. It was fixed in 16 with [17f04fc](https://github.com/openjdk/jdk/commit/17f04fc9e755a83727ac9d13a39b487f99311efd). I think you can close it as duplicate.

Thanks. I saw that change go by but did not connect the dots. Was it actually verified that things are not split up into two or more packets? It seems that `write(2)` could in fact return a value less than the number of bytes requested.

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

PR Comment: https://git.openjdk.org/jdk/pull/14791#issuecomment-1625582230

From bpb at openjdk.org  Fri Jul  7 15:44:06 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 7 Jul 2023 15:44:06 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1 [v2]
In-Reply-To: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
Message-ID: <h9PlDFUdKbSjiQtJKLnu_FGLv0vdkrvs-b81pnqIIEU=.34443364-2a9a-4d26-a446-7f6a2e447e99@github.com>

> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no guarantee as to how the underlying output stream actually writes the bytes provided to it.

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

  8155902: Delete "merely"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14791/files
  - new: https://git.openjdk.org/jdk/pull/14791/files/b7778adc..43c392e8

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

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

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

From simonis at openjdk.org  Fri Jul  7 15:48:53 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 7 Jul 2023 15:48:53 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() can throw if invoked
 reflectively [v2]
In-Reply-To: <gpNi8d1i2-Hug0LZscTkd5KdfEArVB5XLIXr78miQQM=.adabbd4a-0197-4f50-bc9a-da084223180b@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
 <yS8kuYQ-iQzTnhuxiiS7-ifGAlxP_6znBKmKMftKL20=.e71006f6-a38c-4340-9afa-1057e8e5b638@github.com>
 <gpNi8d1i2-Hug0LZscTkd5KdfEArVB5XLIXr78miQQM=.adabbd4a-0197-4f50-bc9a-da084223180b@github.com>
Message-ID: <3VRIubx6RtYXAe87vPtEjh0jOFaK6W9xGEY4_mATMRA=.0e77fd3a-6d7c-4d0f-a7b8-094a91849f02@github.com>

On Wed, 5 Jul 2023 19:14:07 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename new parameter according to the HS coding conventions
>
> Thanks for catching this issue.    I agree that `Method::invoke` should be skipped the caller-sensitive test in this case but the fix isn't quite right.    The caller-sensitive test should apply in any batch.    For example, `CSM` calls `getCallerClass` reflectively, I think the stack would look like this:
> 
> 
> java.lang.StackWalker::getCallerClass
> java.lang.invoke.DirectMethodHandle$Holder::invokeStatic
> java.lang.invoke.LambdaForm$MH/0x0000000800002c00::invoke
> :
> :
> jdk.internal.reflect.DirectMethodHandleAccessor::invokeImpl
> jdk.internal.reflect.DirectMethodHandleAccessor::invoke
> java.lang.reflect.Method::invoke
> CSM  <--------- caller-sensitive method and UOE should be thrown
> 
> 
> 
> In this case, UOE should be thrown.

By the way, great that you raised this issue @mlchung :) While writing a test for it I realized the the current implementation is *already failing* to trow an `UnsupportedOperationException` if `StackWalker::getCallerClass()` is called reflectively from a `@CallerSensitive` method (because the caller sensitive method is not at the first method at `index == start_index`):

[0,161s][debug][stackwalk] Start walking: mode 6 skip 0 frames batch size 6
[0,161s][debug][stackwalk] 
[0,161s][debug][stackwalk]   skip  java.lang.StackStreamFactory$AbstractStackWalker::callStackWalk
[0,161s][debug][stackwalk]   skip  java.lang.StackStreamFactory$AbstractStackWalker::beginStackWalk
[0,161s][debug][stackwalk]   skip  java.lang.StackStreamFactory$AbstractStackWalker::walkHelper
[0,161s][debug][stackwalk]   skip  java.lang.StackStreamFactory$AbstractStackWalker::walk
[0,161s][debug][stackwalk]   skip  java.lang.StackStreamFactory$CallerClassFinder::findCaller
[0,161s][debug][stackwalk]   skip  java.lang.StackWalker::getCallerClass
[0,161s][debug][stackwalk] fill_in_frames limit=6 start=2 frames length=8
[0,161s][debug][stackwalk]   hidden method:  java.lang.invoke.DirectMethodHandle$Holder::invokeSpecial
[0,161s][debug][stackwalk]   hidden method:  java.lang.invoke.LambdaForm$MH/0x00000007c0084c00::invoke
[0,161s][debug][stackwalk]   hidden method:  java.lang.invoke.Invokers$Holder::invokeExact_MT
[0,161s][debug][stackwalk]   hidden method:  java.util.CallerSensitiveMethod$$InjectedInvoker/0x00000007c0085000::reflect_invoke_V
[0,161s][debug][stackwalk]   hidden method:  java.lang.invoke.DirectMethodHandle$Holder::invokeStatic
[0,161s][debug][stackwalk]   hidden method:  java.lang.invoke.LambdaForm$MH/0x00000007c0085400::invokeExact_MT
[0,161s][debug][stackwalk]   hidden method:  jdk.internal.reflect.DirectMethodHandleAccessor::invokeImpl
[0,161s][debug][stackwalk]   2: frame method:  jdk.internal.reflect.DirectMethodHandleAccessor::invoke bci=24
[0,161s][debug][stackwalk]   2: done frame method:  jdk.internal.reflect.DirectMethodHandleAccessor::invoke
[0,161s][debug][stackwalk]   3: frame method:  java.lang.reflect.Method::invoke bci=90
[0,161s][debug][stackwalk]   3: done frame method:  java.lang.reflect.Method::invoke
[0,161s][debug][stackwalk]   4: frame method:  java.util.CallerSensitiveMethod::getCallerClass bci=110
[0,161s][debug][stackwalk]   4: done frame method:  java.util.CallerSensitiveMethod::getCallerClass
[0,161s][debug][stackwalk]   5: frame method:  ReflectiveGetCallerClassTest::main bci=38
[0,161s][debug][stackwalk]   5: done frame method:  ReflectiveGetCallerClassTest::main
[0,161s][debug][stackwalk] fill_in_frames done frames_decoded=4 at_end=1
doStackWalk: skip 0 start 2 end 6
  frame 2: class jdk.internal.reflect.DirectMethodHandleAccessor
  skip: frame 2 class jdk.internal.reflect.DirectMethodHandleAccessor
  next frame at 2: class jdk.internal.reflect.DirectMethodHandleAccessor (origin 2 fence 6)
  skip: frame 3 class java.lang.reflect.Method
  next frame at 3: class java.lang.reflect.Method (origin 3 fence 6)
  next frame at 4: class java.util.CallerSensitiveMethod (origin 4 fence 6)
  next frame at 5: class ReflectiveGetCallerClassTest (origin 5 fence 6)
CallerSensitiveMethod::getCallerClass() called from class ReflectiveGetCallerClassTest
Exception in thread "main" java.lang.RuntimeException: Expected UnsupportedOperationException when calling StackWalker::getCallerClass() from @CallerSensitive method reflectively
	at java.base/java.util.CallerSensitiveMethod.getCallerClass(CallerSensitiveMethod.java:79)
	at ReflectiveGetCallerClassTest.main(ReflectiveGetCallerClassTest.java:84)


The existing test under `test/jdk/java/lang/StackWalker/CallerSensitiveMethod/src/java.base/java/util/CSM.java` for calls from `@CallerSensitive` methods only handles direct but not reflective calls.

I'll post a patch which will hopefully fix both cases later today.

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

PR Comment: https://git.openjdk.org/jdk/pull/14773#issuecomment-1625607182

From bpb at openjdk.org  Fri Jul  7 15:56:13 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 7 Jul 2023 15:56:13 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent
 of close but throws UncheckedIOException [v2]
In-Reply-To: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
Message-ID: <sU6xopTzco46hc8p2USnYlpqymdqK6h8oihTbebUKic=.bb31c4e0-bb1f-47ed-b1df-f0cb3b456c24@github.com>

> Add a default method `java.io.Closeable::closeUnchecked` which is equivalent to `Closeable::close` except that it instead throws `java.io.UncheckedIOException`.

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

  8066869: linkplain -> link

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14789/files
  - new: https://git.openjdk.org/jdk/pull/14789/files/8db998bd..c89945b8

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

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

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

From bpb at openjdk.org  Fri Jul  7 15:56:16 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 7 Jul 2023 15:56:16 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent
 of close but throws UncheckedIOException [v2]
In-Reply-To: <d0tFyy6N0kU-tD4VmyG143uaEINNUZ_ZeyfX-s9beMM=.c06a383c-5002-434a-b654-b0f5ea245374@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
 <d0tFyy6N0kU-tD4VmyG143uaEINNUZ_ZeyfX-s9beMM=.c06a383c-5002-434a-b654-b0f5ea245374@github.com>
Message-ID: <TafmfZF_C6mSfORSUM3DayKValeCx27DRiDt0WFzeCI=.939d7fbb-b75e-4f66-b068-7fdfee382cdb@github.com>

On Fri, 7 Jul 2023 01:18:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8066869: linkplain -> link
>
> src/java.base/share/classes/java/io/Closeable.java line 72:
> 
>> 70:      * Therefore if an {@linkplain UncheckedIOException} is thrown then its
>> 71:      * {@linkplain UncheckedIOException#getCause() getCause} method will return the
>> 72:      * {@linkplain IOException} thrown by {@link #close() close}.
> 
> These links should all be `@link` as they should be rendered like code like the `{@code IOException}` below.

I agree. So changed in c89945b81a9d8312087593ed5e6ccba06a413ce0.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14789#discussion_r1256041500

From skuksenko at openjdk.org  Fri Jul  7 16:05:54 2023
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Fri, 7 Jul 2023 16:05:54 GMT
Subject: RFR: 8311178: JMH tests don't scale well when sharing output
 buffers
In-Reply-To: <NAqYeoBo6lmu3_A16aV3Q8aCu5oMK1u7rG4UYUTWZEI=.f7b4bd90-95a5-4714-8604-f32f21adf0cf@github.com>
References: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
 <NAqYeoBo6lmu3_A16aV3Q8aCu5oMK1u7rG4UYUTWZEI=.f7b4bd90-95a5-4714-8604-f32f21adf0cf@github.com>
Message-ID: <W9KinS6D_i4g8gUr799ayeLSW8opwLlfzwlb3cEdt80=.9a2acdfc-8a86-44df-8218-5424fb28d3d8@github.com>

On Fri, 7 Jul 2023 08:29:06 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> The below benchmark files have scaling issues due to cache contention and leads to poor scaling when run on multiple threads. The patch sets the scope from benchmark level to thread level to fix the issue:
>> - org/openjdk/bench/java/io/DataOutputStreamTest.java
>> - org/openjdk/bench/java/lang/ArrayCopyObject.java
>> - org/openjdk/bench/java/lang/ArrayFiddle.java
>> - org/openjdk/bench/java/time/format/DateTimeFormatterBench.java
>> - org/openjdk/bench/jdk/incubator/vector/IndexInRangeBenchmark.java
>> - org/openjdk/bench/jdk/incubator/vector/MemorySegmentVectorAccess.java
>> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedBenchmark.java
>> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedIOOBEBenchmark.java
>> - org/openjdk/bench/vm/compiler/ArrayFill.java
>> - org/openjdk/bench/vm/compiler/IndexVector.java
>> 
>> Also removing the static scope for variables in org/openjdk/bench/jdk/incubator/vector/VectorFPtoIntCastOperations.java for better scaling.
>> 
>> Please review and share your feedback.
>> 
>> Thanks,
>> Swati
>
> Hi,
> I'm not sure if I understand this improvement correctly.
> I'm not quite familiar with JMH and it's annotations, but seems to me, the change from `@State(Scope.Benchmark)` to `@State(Scope.Thread)` should not improve the performance by reducing cache contention, as in the jmh doc it says "State objects are usually injected into Benchmark methods as ***arguments***, and JMH takes care of their instantiation and sharing.", this seems mean that @State only matters when the annotated class is used as a parameter of a @Benchmark method, but in the tests you modifed, seems there is no such use case.
> Please also check the sample usages at https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_03_States.java.

@Hamlin-Li 
The PR is fully correct.
Don't forget, every Java instance method has a specific argument which called "this".  That is why @State annotation is working.

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

PR Comment: https://git.openjdk.org/jdk/pull/14746#issuecomment-1625627033

From mchung at openjdk.org  Fri Jul  7 16:12:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 7 Jul 2023 16:12:56 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() can throw if invoked
 reflectively [v2]
In-Reply-To: <yS8kuYQ-iQzTnhuxiiS7-ifGAlxP_6znBKmKMftKL20=.e71006f6-a38c-4340-9afa-1057e8e5b638@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
 <yS8kuYQ-iQzTnhuxiiS7-ifGAlxP_6znBKmKMftKL20=.e71006f6-a38c-4340-9afa-1057e8e5b638@github.com>
Message-ID: <I1H5jT2qpbvUVzNgOQ_jvw5eOHu6zxCUcTlalg6_ZXE=.470d21ac-a7a1-455c-9e2c-6c040b17fb18@github.com>

On Wed, 5 Jul 2023 17:25:24 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> As the included jtreg test demonstrates, `StackWalker.getCallerClass()` can throw an `UnsupportedOperationException` if called reflectively. Currently this only happens if we invoke `StackWalker.getCallerClass()` recursively reflectively, but this issue will become more prominent once we fix [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447). The gory details follow below:
>> 
>> The protocol between the Java API and the JVM for `StackWalker.getCallerClass()/walk()` is as follows:
>> - On the Java side, `StackWalker` calls into `StackStreamFactory` for the real work.
>> - For `StackWalker.getCallerClass()` `StackStreamFactory` basically creates a `Class[]` which will be passed down and filled in the JVM. For `StackWalker.walk()` it will normally be a `StackFrameInfo[]` (or a `LiveStackFrameInfo[]` if the internal `ExtendedOption.LOCALS_AND_OPERANDS` option was used).
>> - The default size of this arrays is currently `StackStreamFactory.SMALL_BATCH` which is 8 (but see [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447)).
>> - `StackStreamFactory` than calls `AbstractStackWalker.callStackWalk()` which is a natively implemented in the VM by `JVM_CallStackWalk()`.
>> -  `JVM_CallStackWalk()` calls `StackWalk::walk()` which calls `StackWalk::fetchFirstBatch()` which calls `StackWalk::fill_in_frames()` which walks the stack and fills in the available class/stackframe slots in the passed in array until the array is full or there are no more stack frames,
>> - Once  `StackWalk::fill_in_frames()` returns, `StackWalk::fetchFirstBatch()` calls back to Java by invoking `AbstractStackWalker::doStackWalk()` to consume the result.
>> - `AbstractStackWalker::doStackWalk()` calls `consumeFrames()` (which is overridden depending on whether we initially called `getCallerClass()` or `walk()`) which consumes the frames until it either finishes (e.g. finds the caller class) or until there are no more frames.
>> - In the latter case `consumeFrames()` will call into the the VM again by calling `AbstractStackWalker.fetchStackFrames()` to fetch additional frames from the stack.
>> - `AbstractStackWalker.fetchStackFrames()` is implemented by `JVM_MoreStackWalk()` which calls `StackWalk::fetchNextBatch()` which calls `StackWalk::fill_in_frames()` (the same method that already fetched the initial batch of frames).
>> 
>> Following is a stacktrace of what I've explained so far:
>> 
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x1...
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename new parameter according to the HS coding conventions

Yes that's the bug.   `index == start_index` assumes the first frame is the caller of `getCallerClass` as it misses the reflective case.

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

PR Comment: https://git.openjdk.org/jdk/pull/14773#issuecomment-1625638581

From mchung at openjdk.org  Fri Jul  7 16:19:59 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 7 Jul 2023 16:19:59 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v6]
In-Reply-To: <X-6j5WPseJftucqEE8WgBxTw_bQf-VhkUNKtsdgBDDs=.3ca2eb44-ea46-4a90-b6db-f9329e478be2@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <X-6j5WPseJftucqEE8WgBxTw_bQf-VhkUNKtsdgBDDs=.3ca2eb44-ea46-4a90-b6db-f9329e478be2@github.com>
Message-ID: <uEf4uzzc7qhq5q0LRU5GkYDGIRrgQHhrX6OVApn46Ms=.3a436a99-460f-4728-bdf7-69f5167b7df4@github.com>

On Fri, 7 Jul 2023 11:49:22 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:
> 
>   Simple versions of create

Looks good.  Thanks for the update.   Nit:  the test can use the 2-arg factory method.

test/jdk/jdk/internal/util/ReferencedKeyTest.java line 63:

> 61: 
> 62:     static void mapTest(boolean isSoft, Supplier<Map<ReferenceKey<Long>, String>> supplier) {
> 63:         Map<Long, String> map = ReferencedKeyMap.create(isSoft, false, supplier);

Suggestion:

        Map<Long, String> map = ReferencedKeyMap.create(isSoft, supplier);

test/jdk/jdk/internal/util/ReferencedKeyTest.java line 72:

> 70: 
> 71:     static void setTest(boolean isSoft, Supplier<Map<ReferenceKey<Long>, ReferenceKey<Long>>> supplier) {
> 72:         ReferencedKeySet<Long> set = ReferencedKeySet.create(isSoft, false, supplier);

Suggestion:

        ReferencedKeySet<Long> set = ReferencedKeySet.create(isSoft, supplier);

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14684#pullrequestreview-1519246419
PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1256081914
PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1256082313

From jlaskey at openjdk.org  Fri Jul  7 16:31:26 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 7 Jul 2023 16:31:26 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v7]
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: <iQFjvjuvyhReApyL3_tAsinardKrQnePtGM3EflKrcM=.120e36fa-c0ac-43ff-a407-cc620781bba6@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:

  Update ReferencedKeyTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14684/files
  - new: https://git.openjdk.org/jdk/pull/14684/files/8eff9183..bb943b6f

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 mchung at openjdk.org  Fri Jul  7 16:35:20 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 7 Jul 2023 16:35:20 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v22]
In-Reply-To: <cKUEte7iDFjGSjnpWp4Otw-jr49x33S9JARZkrvWng8=.cfdd4210-9319-4f3b-b731-de2befc00eb2@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <cKUEte7iDFjGSjnpWp4Otw-jr49x33S9JARZkrvWng8=.cfdd4210-9319-4f3b-b731-de2befc00eb2@github.com>
Message-ID: <D8tlg83uRxvtwj52VxhBEjPRej-IPYaMW_tqZWuNnVQ=.83986c56-5be3-4b63-9729-f6cf96064a66@github.com>

On Fri, 7 Jul 2023 06:45:46 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 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:
> 
>   Fix broken null behaviors

FYI.   You can do git revert instead of force push.

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

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

From bpb at openjdk.org  Fri Jul  7 16:40:53 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 7 Jul 2023 16:40:53 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent
 of close but throws UncheckedIOException
In-Reply-To: <1964293768.98318143.1688679839453.JavaMail.zimbra@univ-eiffel.fr>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
 <1964293768.98318143.1688679839453.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <1LVQLBxmHqGmrVyZWP38ziJr399_cGfyTsOwk-tdqyk=.b8d2a044-1244-4559-8534-6e92ac1df5c5@github.com>

On Fri, 7 Jul 2023 16:23:37 GMT, Remi Forax <forax at univ-mlv.fr> wrote:

> I'm not a big fan of hiding exceptions, why not wrapping the IOException in an UncheckedIOException ?
> 
> So closeUnchecked() means close and throw an unchecked exception if an exception occurs.

I am confused by this comment. That is what `closeUnchecked()` is specified to do.

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

PR Comment: https://git.openjdk.org/jdk/pull/14789#issuecomment-1625669306

From rriggs at openjdk.org  Fri Jul  7 17:27:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Jul 2023 17:27:56 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v7]
In-Reply-To: <iQFjvjuvyhReApyL3_tAsinardKrQnePtGM3EflKrcM=.120e36fa-c0ac-43ff-a407-cc620781bba6@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <iQFjvjuvyhReApyL3_tAsinardKrQnePtGM3EflKrcM=.120e36fa-c0ac-43ff-a407-cc620781bba6@github.com>
Message-ID: <rrwlDiVdp5KvZb-CiTGKEBAOE470rdMUmZvBoEZ5rlA=.1bc0e803-678f-4065-b684-16a9ef300ec6@github.com>

On Fri, 7 Jul 2023 16:31:26 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:
> 
>   Update ReferencedKeyTest.java

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14684#pullrequestreview-1519340228

From smarks at openjdk.org  Fri Jul  7 17:43:01 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 7 Jul 2023 17:43:01 GMT
Subject: RFR: 8308694: Clarify reversed() default methods' implementation
 requirements [v3]
In-Reply-To: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>
References: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>
Message-ID: <0XmieY15qpqkqwKIrfNIkJYtfOk8CwJpJxn4DGo8xLM=.562f4605-a3bb-4b2f-adc6-c3a471aadbc7@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 with a new target base 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-8308694-clarify-reversed
 - Update to avoid overspecification.
 - 8308694: Clarify reversed() default methods' implementation requirements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14504/files
  - new: https://git.openjdk.org/jdk/pull/14504/files/0a8b769f..c8a69ee7

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

  Stats: 74794 lines in 1515 files changed: 18072 ins; 48133 del; 8589 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  Fri Jul  7 17:43:55 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 7 Jul 2023 17:43:55 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1 [v2]
In-Reply-To: <CN_eDr4hn06aPLpQErLX8TD5qQAYKsAuatQDvfVPy4Q=.b6b6a07f-0cae-4244-96c3-337f9faa9e0d@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
 <CN_eDr4hn06aPLpQErLX8TD5qQAYKsAuatQDvfVPy4Q=.b6b6a07f-0cae-4244-96c3-337f9faa9e0d@github.com>
Message-ID: <av30ChJTZb9rkea0qm3DTwLikGVMcMb2Cm086rKhCeY=.b8d781a2-db26-41c8-992b-69e368035e18@github.com>

On Fri, 7 Jul 2023 14:21:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> I would not want to give any assurances about whether the bytes of an encoded primitive were written individually or as a group.

Would it be helpful to add further verbiage?

For example, the sequence of bytes comprising the primitive data type may be written as more than one packet of bytes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14791#discussion_r1256193116

From djelinski at openjdk.org  Fri Jul  7 18:01:57 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 7 Jul 2023 18:01:57 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1
In-Reply-To: <Exys2W0FofMsIZQWlNT6IeSlCnAcBHqKLrpxGosj79A=.a531123e-c797-4d79-a29a-c1b8ebe63d7e@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
 <Exys2W0FofMsIZQWlNT6IeSlCnAcBHqKLrpxGosj79A=.a531123e-c797-4d79-a29a-c1b8ebe63d7e@github.com>
Message-ID: <zc8j8oDDucCWkVY4g7orhfkMu-xiA6ySvRPn1goZ7HU=.418d0071-3d84-4937-8761-2aa488e2a4a8@github.com>

On Fri, 7 Jul 2023 15:27:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Was it actually verified that things are not split up into two or more packets? It seems that `write(2)` could in fact return a value less than the number of bytes requested.

Yes, the test case included in JBS sends all 4 bytes in a single packet now.
We can't guarantee that every writeInt will always send all bytes in the same packet, but at least we won't send single-byte packets.

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

PR Comment: https://git.openjdk.org/jdk/pull/14791#issuecomment-1625766507

From jvernee at openjdk.org  Fri Jul  7 18:02:55 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Jul 2023 18:02:55 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v2]
In-Reply-To: <u9rVr_KhMSKN42SM_XoNt-1zXq2HIjyB4OLmLIK1CTI=.7a252b72-bb50-4bdd-a686-db7ad76a4985@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <t_D4CaM9h-wbAm-SvI4hQqCiNYUh1wR1_cVwDCA7GrE=.9793bbc5-2dfe-43fa-bd72-37430dd0c8a4@github.com>
 <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
 <u9rVr_KhMSKN42SM_XoNt-1zXq2HIjyB4OLmLIK1CTI=.7a252b72-bb50-4bdd-a686-db7ad76a4985@github.com>
Message-ID: <EJn9BTDGTgS0gTgaM-QOV4XWo6797L5nlfLPBNYyw-0=.a4e0b97e-d024-4362-850a-23f31304e71f@github.com>

On Fri, 7 Jul 2023 14:54:54 GMT, sid8606 <duke at openjdk.org> wrote:

>> src/hotspot/cpu/s390/upcallLinker_s390.cpp line 141:
>> 
>>> 139: 
>>> 140:   // The Java call uses the JIT ABI, but we also call C.
>>> 141:   int out_arg_area = MAX2(frame::z_jit_out_preserve_size + arg_shuffle.out_arg_bytes(), (int)frame::z_abi_160_size);
>> 
>> What do you mean here with "but we also call C"? Upcall stubs are always calling into Java, though the source ABI is unknown.
>
> We do native calls in this stub, so make sure allocated stack frame size is big enough.

Ah, right thanks. That's good.

>> test/jdk/java/foreign/TestClassLoaderFindNative.java line 63:
>> 
>>> 61:     public void testVariableSymbolLookup() {
>>> 62:         MemorySegment segment = SymbolLookup.loaderLookup().find("c").get().reinterpret(ByteOrder.nativeOrder() == ByteOrder.LITTLE_ENDIAN ? 1 : 4);
>>> 63:         assertEquals(segment.get(JAVA_BYTE, ByteOrder.nativeOrder() == ByteOrder.LITTLE_ENDIAN ? 0 : 3), 42);
>> 
>> Could you explain why this is needed? It looks like the lookup is returning the wrong address?
>
> Since  s390x runs in Big Endian mode. We get LSB on higher address of integer size.

Ah, wait, now I see. The native side uses `int` as a type, but we try to load it as a `JAVA_BYTE`. I think this is a bug in the test. The Java side should use `JAVA_INT` instead, and the size passed to `reinterpret` should be `4` (which matches the native type). What happens if you make that change instead? Does the test pass then?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1256224573
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1256219721

From rriggs at openjdk.org  Fri Jul  7 18:16:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Jul 2023 18:16:55 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1 [v2]
In-Reply-To: <av30ChJTZb9rkea0qm3DTwLikGVMcMb2Cm086rKhCeY=.b8d781a2-db26-41c8-992b-69e368035e18@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
 <CN_eDr4hn06aPLpQErLX8TD5qQAYKsAuatQDvfVPy4Q=.b6b6a07f-0cae-4244-96c3-337f9faa9e0d@github.com>
 <av30ChJTZb9rkea0qm3DTwLikGVMcMb2Cm086rKhCeY=.b8d781a2-db26-41c8-992b-69e368035e18@github.com>
Message-ID: <sdpWmVKOJiYIfy_GyLYcnKpzS_XeTokxrtB8qOAAby4=.ed036671-f703-4bf7-b1e4-55012d6ecc7c@github.com>

On Fri, 7 Jul 2023 17:41:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/DataOutputStream.java line 44:
>> 
>>> 42:  * the underlying output stream, hence there is no guarantee as to
>>> 43:  * the details of how the bytes are written.
>>> 44:  *
>> 
>> I'd drop "merely".
>> 
>> I would not want to give any assurances about whether the bytes of an encoded primitive were written individually or as a group.  
>> For the primitive types the value is encoded and written as one or more bytes to the underlying stream.
>
>> I would not want to give any assurances about whether the bytes of an encoded primitive were written individually or as a group.
> 
> Would it be helpful to add further verbiage?
> 
> For example, the sequence of bytes comprising the primitive data type may be written as more than one packet of bytes.

"packet" is network centric terminology.
Perhaps something like:  "may be written individually or in any grouping of bytes"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14791#discussion_r1256254810

From duke at openjdk.org  Fri Jul  7 18:28:56 2023
From: duke at openjdk.org (sid8606)
Date: Fri, 7 Jul 2023 18:28:56 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v2]
In-Reply-To: <EJn9BTDGTgS0gTgaM-QOV4XWo6797L5nlfLPBNYyw-0=.a4e0b97e-d024-4362-850a-23f31304e71f@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <t_D4CaM9h-wbAm-SvI4hQqCiNYUh1wR1_cVwDCA7GrE=.9793bbc5-2dfe-43fa-bd72-37430dd0c8a4@github.com>
 <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
 <u9rVr_KhMSKN42SM_XoNt-1zXq2HIjyB4OLmLIK1CTI=.7a252b72-bb50-4bdd-a686-db7ad76a4985@github.com>
 <EJn9BTDGTgS0gTgaM-QOV4XWo6797L5nlfLPBNYyw-0=.a4e0b97e-d024-4362-850a-23f31304e71f@github.com>
Message-ID: <BdmrlUqlE4iYfuV7QOk4A9id6I4F6NsiMYWJZq8GeYU=.23f76e87-b381-4890-8ca1-175d28222e1e@github.com>

On Fri, 7 Jul 2023 17:55:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Since  s390x runs in Big Endian mode. We get LSB on higher address of integer size.
>
> Ah, wait, now I see. The native side uses `int` as a type, but we try to load it as a `JAVA_BYTE`. I think this is a bug in the test. The Java side should use `JAVA_INT` instead, and the size passed to `reinterpret` should be `4` (which matches the native type). What happens if you make that change instead? Does the test pass then?

Yes, it does pass the test with above changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1256271583

From jlu at openjdk.org  Fri Jul  7 19:15:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 7 Jul 2023 19:15:14 GMT
Subject: Integrated: 8310818: Refactor more Locale tests to use JUnit
In-Reply-To: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
References: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
Message-ID: <SLTZgI1cmZIjPOjpTkZwKoaZdyV8XSeEId-ve5C687s=.b791094f-9b61-4454-8874-a8b912be779c@github.com>

On Fri, 30 Jun 2023 07:52:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> 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
> - Combine Bug8025703.java into LanguageSubtagRegistryTest.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

This pull request has now been integrated.

Changeset: 12e94309
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12e943091071b02b5756b57527a5f86a3d881cb8
Stats:     1377 lines in 13 files changed: 681 ins; 686 del; 10 mod

8310818: Refactor more Locale tests to use JUnit

Reviewed-by: lancea, naoto

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

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

From jvernee at openjdk.org  Fri Jul  7 19:38:55 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Jul 2023 19:38:55 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v2]
In-Reply-To: <BdmrlUqlE4iYfuV7QOk4A9id6I4F6NsiMYWJZq8GeYU=.23f76e87-b381-4890-8ca1-175d28222e1e@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <t_D4CaM9h-wbAm-SvI4hQqCiNYUh1wR1_cVwDCA7GrE=.9793bbc5-2dfe-43fa-bd72-37430dd0c8a4@github.com>
 <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
 <u9rVr_KhMSKN42SM_XoNt-1zXq2HIjyB4OLmLIK1CTI=.7a252b72-bb50-4bdd-a686-db7ad76a4985@github.com>
 <EJn9BTDGTgS0gTgaM-QOV4XWo6797L5nlfLPBNYyw-0=.a4e0b97e-d024-4362-850a-23f31304e71f@github.com>
 <BdmrlUqlE4iYfuV7QOk4A9id6I4F6NsiMYWJZq8GeYU=.23f76e87-b381-4890-8ca1-175d28222e1e@github.com>
Message-ID: <v5C2EV6-1kozsHK3qddG-nIJoCfqwUPmeGjY-Bim1X0=.592e5b12-4da2-461f-8c0a-440ed146583c@github.com>

On Fri, 7 Jul 2023 18:25:58 GMT, sid8606 <duke at openjdk.org> wrote:

>> Ah, wait, now I see. The native side uses `int` as a type, but we try to load it as a `JAVA_BYTE`. I think this is a bug in the test. The Java side should use `JAVA_INT` instead, and the size passed to `reinterpret` should be `4` (which matches the native type). What happens if you make that change instead? Does the test pass then?
>
> Yes, it does pass the test with above changes.

Ok, please use the above changes instead then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1256361842

From coffeys at openjdk.org  Fri Jul  7 19:42:18 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 7 Jul 2023 19:42:18 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v10]
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: <Q38GHs2heGPTM512RZt80CzBI9uK5cir5Vrhqy6ytoM=.72abc91a-d5f2-4b1b-b51e-57e51a826020@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:

 - Harden code to report lack of SSL support
 - Testcase correction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14394/files
  - new: https://git.openjdk.org/jdk/pull/14394/files/c563e18e..559f698e

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

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 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 rriggs at openjdk.org  Fri Jul  7 20:37:00 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Jul 2023 20:37:00 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v6]
In-Reply-To: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
Message-ID: <Oq9zcg0S5sYEQsQFJrjWevAZdwRHsl_s_yochsILob8=.2c55b7e5-10dd-4456-8aa5-afec0f10ed2a@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:

  Correct the descriptions to correctly identify the compareTo return
  value < 0 as this is before that, and > 0 as this is after that.
  Thanks to a careful reviewer spotting my reversing of the conditions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14479/files
  - new: https://git.openjdk.org/jdk/pull/14479/files/71dc98ae..5e07e79a

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

  Stats: 40 lines in 17 files changed: 0 ins; 6 del; 34 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 liach at openjdk.org  Fri Jul  7 22:28:55 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jul 2023 22:28:55 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v6]
In-Reply-To: <90SkXhk3AttjkCDs26NYiysShCkPfCyyi2mYeY432Mw=.c9bac184-e20c-4533-a288-fdb70eaa0a73@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <hY2cN_-xxTyqNZz1AMJC_klQyMPX36UVsjc1c5zSK58=.91762031-9a5d-40c2-b794-423112785629@github.com>
 <90SkXhk3AttjkCDs26NYiysShCkPfCyyi2mYeY432Mw=.c9bac184-e20c-4533-a288-fdb70eaa0a73@github.com>
Message-ID: <h6zvx6tdzwuv2xLMD9A6t0a2eG4jnc4foxj-0uItnfs=.ed67910f-267e-4f30-8cfc-a30a92334128@github.com>

On Fri, 7 Jul 2023 15:02:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Is there a significant performance difference?

Yes, see https://github.com/openjdk/jdk/pull/14745#issuecomment-1615435719 for the revision at https://github.com/openjdk/jdk/pull/14745/commits/425559f65a3e5f72323abdadbbf9df426e196d9b
On my device, the UUIDBench.toString has a smaller difference of about 8%, but it is still noticeable.

Unfortunately, I don't know architecture well enough to explain this difference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1256560149

From smarks at openjdk.org  Fri Jul  7 22:55:12 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 7 Jul 2023 22:55:12 GMT
Subject: RFR: 8308694: Clarify reversed() default methods' implementation
 requirements [v4]
In-Reply-To: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>
References: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>
Message-ID: <vqfR6hqMAWpVLiZziDacV0aRrZJn-AfJB9oMHHbvZlg=.05458d05-ac73-4f42-aa32-971ec12d2db8@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 two additional commits since the last revision:

 - Update docs for reversed() method of List, SortedMap, SortedSet.
 - Slight rewording of the original paragraph in Deque.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14504/files
  - new: https://git.openjdk.org/jdk/pull/14504/files/c8a69ee7..b97e6022

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

  Stats: 27 lines in 4 files changed: 18 ins; 0 del; 9 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 stuart.marks at oracle.com  Fri Jul  7 23:21:46 2023
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 7 Jul 2023 16:21:46 -0700
Subject: List extending Collection/SequencedCollection
In-Reply-To: <1AD8CF66-B7E7-4793-8608-92D4F90CA66F@iernst.net>
References: <d40456ff-c11d-dcb8-417e-4c44f9473e11@oracle.com>
 <1AD8CF66-B7E7-4793-8608-92D4F90CA66F@iernst.net>
Message-ID: <871a9b9a-eb27-83dc-626c-1aac379feab7@oracle.com>

Hi Ryan,

Thanks for trying out JDK 21 early access.

The issue you raise is indeed an inconsistency, but it's not clear which way it 
should be resolved, or even whether it needs to be resolved, as the consequences are 
quite minor.

Specifically, when the Sequenced Collections JEP was integrated, it included these 
changes (edited for brevity):

- public interface List<E> extends Collection<E> {
+ public interface List<E> extends SequencedCollection<E> {

- public interface SortedSet<E> extends Set<E> {
+ public interface SortedSet<E> extends Set<E>, SequencedSet<E> {

As you observed, on List, SequencedCollection has replaced Collection, but on 
SortedSet, SequencedSet was added alongside Set. Which way is correct? Should 
SequencedCollection have been added to List, instead of replacing Collection? Or on 
SortedSet, should SequencedSet have replaced Set instead of simply being added?

(I have to admit my first inclination was that the SortedSet change was a mistake, 
and that SequencedSet ought to have replaced Set. I think the reason it turned out 
the way it did was that, my earliest prototype, before I published anything, had a 
single interface OrderedCollection. This was retrofitted onto SortedSet as

     public interface SortedSet<E> extends Set<E>, OrderedCollection<E> {

Only later did I decide to add OrderedSet, and so I changed the declaration to

     public interface SortedSet<E> extends Set<E>, OrderedSet<E> {

and I didn't notice that the interfaces could be minimized. And of course there were 
a couple rounds of renaming subsequent to this.)

In any case, this inconsistency is of little consequence, as the members available 
to users of the interfaces in question are the same regardless of the way the 
interfaces are declared. This is true from both a source and binary compatibility 
standpoint.

Joe's point about compatibility is that even though such changes are *visible* to 
reflective code, they aren't *incompatible*. There are many compatible changes 
possible, such as moving the declaration of a method upward in the hierarchy. From 
the standpoint of reflection, that method may appear to have been removed from some 
interface; but that doesn't mean it's incompatible. Reflective code needs to be 
adjusted to take such things into account. The presence or absence of Collection as 
a superinterface of List is a similar case.

Perhaps in some sense the JDK itself ought to be more consistent about this. We have 
for example this:

     class HashSet extends AbstractSet implements Set, Cloneable, Serializable

but also this:

     class EnumSet extends AbstractSet implements Cloneable, Serializable

(That is, EnumSet is "missing" Set.)

Questions about this have been asked on Stack Overflow, and various answers there 
have made up a rationale about the possibly-redundant interfaces being included 
explicitly because it expresses intent more clearly, or some such. My own guess is 
that nobody has paid much attention to this issue because resolving it one way or 
another hardly makes any practical difference.

s'marks

On 7/7/23 7:25 AM, Ryan Ernst wrote:
> Thanks for laying out your thinking, Joe. I will watch your talks.
> 
> If I understood your response correctly, you are ok making such a change, especially since it is semantically equivalent? If that?s the case, is JDK 21 past the point of feature release, or should the change target only 22? It doesn?t matter much to me, but I thought since SequencedCollection is added in 21 it would be good to ?fix? this there so as to avoid a gap in behavior.
> 
> 
> 
>> On Jun 30, 2023, at 6:13 PM, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
>>
>> ?Hi Ryan,
>>
>> Apropos of this discussion, I happened to recently give a talk to the JCP that in part covered behavioral compatibility in the JDK:
>>
>> https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-06-13/JCP-EC-Public-Agenda-June-2023.html
>> https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-06-13/Contributing_to_OpenJDK_2023_04_12.pdf
>>
>> There are many observable details of the JDK implementation, including reflective details, timing, etc. there are _not_ part of the interfaces users should rely on.
>>
>> My current evaluation here is that it would set an unfortunate precedent to preclude making the sort of source changes in questions because of (potential) compatibility concerns in reflective modeling, especially in a feature release. (IMO, there is a stronger argument for not making such a change in an update release, but even there as the change is a semantically equivalent refactoring, I think it is generally fine.)
>>
>> HTH,
>>
>> -Joe
>>
>>> On 6/29/2023 11:30 AM, Ryan Ernst wrote:
>>> 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 duke at openjdk.org  Fri Jul  7 23:45:56 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 7 Jul 2023 23:45:56 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v6]
In-Reply-To: <90SkXhk3AttjkCDs26NYiysShCkPfCyyi2mYeY432Mw=.c9bac184-e20c-4533-a288-fdb70eaa0a73@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <hY2cN_-xxTyqNZz1AMJC_klQyMPX36UVsjc1c5zSK58=.91762031-9a5d-40c2-b794-423112785629@github.com>
 <90SkXhk3AttjkCDs26NYiysShCkPfCyyi2mYeY432Mw=.c9bac184-e20c-4533-a288-fdb70eaa0a73@github.com>
Message-ID: <BiJjZ5_DTJGBRxDrnR3HokZdcyubNzOoH-6_Q9QY_xk=.f4439c9e-a9d1-41b8-a467-1f2adf6de6bf@github.com>

On Fri, 7 Jul 2023 15:09:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code style
>
> src/java.base/share/classes/java/util/UUID.java line 475:
> 
>> 473:         long msb = mostSigBits;
>> 474:         byte[] buf = new byte[36];
>> 475:         UNSAFE.putLongUnaligned(
> 
> I understood that since UUID was not used during startup, that using VarHandles is the preferred abstraction.

Using VarHandle will be 10% slower than using Unsafe directly, I haven't found the reason yet

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1256615424

From duke at openjdk.org  Sat Jul  8 00:20:20 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 8 Jul 2023 00:20:20 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v7]
In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
Message-ID: <f6vmtp22GlgZ8loB_lH46hy5224Hpx7-zGdP_0G_wEk=.55e9cf5d-be28-4582-bda4-c585835343de@github.com>

> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
> 
> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.util.UUIDBench.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)
> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
> 
> 
> 
> ## 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)
> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
> 
> 
> ## 4. MacBookPro M1 Pro
> ``` diff
> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
> 
> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
> 
> 
> ## 5. Orange Pi 5 Plus
> 
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)

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

  fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14745/files
  - new: https://git.openjdk.org/jdk/pull/14745/files/e5274ddc..d6bb2725

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

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

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

From duke at openjdk.org  Sat Jul  8 04:31:56 2023
From: duke at openjdk.org (sid8606)
Date: Sat, 8 Jul 2023 04:31:56 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v2]
In-Reply-To: <v5C2EV6-1kozsHK3qddG-nIJoCfqwUPmeGjY-Bim1X0=.592e5b12-4da2-461f-8c0a-440ed146583c@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <t_D4CaM9h-wbAm-SvI4hQqCiNYUh1wR1_cVwDCA7GrE=.9793bbc5-2dfe-43fa-bd72-37430dd0c8a4@github.com>
 <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
 <u9rVr_KhMSKN42SM_XoNt-1zXq2HIjyB4OLmLIK1CTI=.7a252b72-bb50-4bdd-a686-db7ad76a4985@github.com>
 <EJn9BTDGTgS0gTgaM-QOV4XWo6797L5nlfLPBNYyw-0=.a4e0b97e-d024-4362-850a-23f31304e71f@github.com>
 <BdmrlUqlE4iYfuV7QOk4A9id6I4F6NsiMYWJZq8GeYU=.23f76e87-b381-4890-8ca1-175d28222e1e@github.com>
 <v5C2EV6-1kozsHK3qddG-nIJoCfqwUPmeGjY-Bim1X0=.592e5b12-4da2-461f-8c0a-440ed146583c@github.com>
Message-ID: <qE4RdKl6aRP4tZkUfKtepii1FMrVXaCFyzujc5VLdlc=.a3cdca49-0591-4e57-860e-6d6a4d7ad383@github.com>

On Fri, 7 Jul 2023 19:35:53 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Yes, it does pass the test with above changes.
>
> Ok, please use the above changes instead then.

Sure, Thank you

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1256959506

From duke at openjdk.org  Sat Jul  8 07:16:55 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 8 Jul 2023 07:16:55 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v6]
In-Reply-To: <90SkXhk3AttjkCDs26NYiysShCkPfCyyi2mYeY432Mw=.c9bac184-e20c-4533-a288-fdb70eaa0a73@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <hY2cN_-xxTyqNZz1AMJC_klQyMPX36UVsjc1c5zSK58=.91762031-9a5d-40c2-b794-423112785629@github.com>
 <90SkXhk3AttjkCDs26NYiysShCkPfCyyi2mYeY432Mw=.c9bac184-e20c-4533-a288-fdb70eaa0a73@github.com>
Message-ID: <rhelsHv97sIz-DqZYhd2HFJqydgqU4IaSL_29YeaYng=.b9bebe17-99e8-486d-b993-ff0cdef602ee@github.com>

On Fri, 7 Jul 2023 15:13:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code style
>
> src/java.base/share/classes/java/util/HexDigits.java line 44:
> 
>> 42:      *       0 -> '00' -> ('0' << 8) | '0' -> 0x3030
>> 43:      *       1 -> '01' -> ('0' << 8) | '1' -> 0x3130
>> 44:      *       2 -> '02' -> ('0' << 8) | '2' -> 0x3230
> 
> The description of the array content does not need to be exhaustive; just sufficient to understand how it is indexed and the meaning of the values.

The comment is already there, I think the value on the right is easier to understand in hexadecimal

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1257114731

From forax at univ-mlv.fr  Sat Jul  8 09:39:10 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 08 Jul 2023 09:39:10 +0000
Subject: =?US-ASCII?Q?Re=3A_RFR=3A_8066869=3A_Add_Close?=
 =?US-ASCII?Q?able=3A=3AcloseUnchecked_that_is?=
 =?US-ASCII?Q?_the_equivalent_of_close_but_throws_UncheckedIOException?=
In-Reply-To: <1LVQLBxmHqGmrVyZWP38ziJr399_cGfyTsOwk-tdqyk=.b8d2a044-1244-4559-8534-6e92ac1df5c5@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
 <1964293768.98318143.1688679839453.JavaMail.zimbra@univ-eiffel.fr>
 <1LVQLBxmHqGmrVyZWP38ziJr399_cGfyTsOwk-tdqyk=.b8d2a044-1244-4559-8534-6e92ac1df5c5@github.com>
Message-ID: <760F84FE-325B-4CA2-8946-EFFBC9117481@univ-mlv.fr>

oops, sorry, my bad, sending an email when you are deprived of sleep does not lead to a good outcome. 

Remi


On July 7, 2023 4:40:53 PM UTC, Brian Burkhalter <bpb at openjdk.org> wrote:
>On Fri, 7 Jul 2023 16:23:37 GMT, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> I'm not a big fan of hiding exceptions, why not wrapping the IOException in an UncheckedIOException ?
>> 
>> So closeUnchecked() means close and throw an unchecked exception if an exception occurs.
>
>I am confused by this comment. That is what `closeUnchecked()` is specified to do.
>
>-------------
>
>PR Comment: https://git.openjdk.org/jdk/pull/14789#issuecomment-1625669306
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230708/c934757a/attachment-0001.htm>

From duke at openjdk.org  Sat Jul  8 10:14:14 2023
From: duke at openjdk.org (yaqsun)
Date: Sat, 8 Jul 2023 10:14:14 GMT
Subject: RFR: 8311631: When multiple users run
 tools/jpackage/share/LicenseTest.java,
 Permission denied for writing /var/tmp/*.files
Message-ID: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>

Low risk, only test changes.
The prerequisite is to install the rpmbuild command, when multiple users switch to write /var/tmp/*.files will have the permission forbidden.

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

Commit messages:
 - 8311631: When multiple users run tools/jpackage/share/LicenseTest.java, Permission denied for writing /var/tmp/*.files.

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

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

From duke at openjdk.org  Sat Jul  8 10:48:15 2023
From: duke at openjdk.org (sid8606)
Date: Sat, 8 Jul 2023 10:48:15 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
Message-ID: <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>

> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).

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

  Address suggestions from Jorn Vernee

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14801/files
  - new: https://git.openjdk.org/jdk/pull/14801/files/e719c164..f916864d

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

  Stats: 137 lines in 11 files changed: 1 ins; 77 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/14801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14801/head:pull/14801

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

From duke at openjdk.org  Sat Jul  8 10:59:58 2023
From: duke at openjdk.org (sid8606)
Date: Sat, 8 Jul 2023 10:59:58 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v2]
In-Reply-To: <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <t_D4CaM9h-wbAm-SvI4hQqCiNYUh1wR1_cVwDCA7GrE=.9793bbc5-2dfe-43fa-bd72-37430dd0c8a4@github.com>
 <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
Message-ID: <72UoBC1ZL2QmnHBoEj1SoH2xn-Aj2UZj29HKiLQs-IY=.84b05a3a-aaf2-4d25-88d6-af6c5a3d33ad@github.com>

On Fri, 7 Jul 2023 10:33:10 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Amit's review comments
>
> test/jdk/java/foreign/TestIllegalLink.java line 57:
> 
>> 55: 
>> 56:     private static final boolean IS_SYSV = CABI.current() == CABI.SYS_V;
>> 57:     private static final boolean byteorder = ByteOrder.nativeOrder() == ByteOrder.LITTLE_ENDIAN;
> 
> Please rename this field to something more descriptive, e.g. `IS_LE` (and capitalize).

Thanks, Made the changes.

> test/jdk/java/foreign/TestLayouts.java line 46:
> 
>> 44: public class TestLayouts {
>> 45: 
>> 46:     boolean byteorder = ByteOrder.nativeOrder() == ByteOrder.LITTLE_ENDIAN;
> 
> Same here

Fixed

> test/jdk/java/foreign/callarranger/platform/PlatformLayouts.java line 312:
> 
>> 310:      * This class defines layout constants modelling standard primitive types supported by the S390 ABI.
>> 311:      */
>> 312:     public static final class S390 {
> 
> These are only needed if you plan on adding a CallArranger test as well.

Removed For now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1257226257
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1257226355
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1257226562

From duke at openjdk.org  Sat Jul  8 11:06:00 2023
From: duke at openjdk.org (sid8606)
Date: Sat, 8 Jul 2023 11:06:00 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v2]
In-Reply-To: <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <t_D4CaM9h-wbAm-SvI4hQqCiNYUh1wR1_cVwDCA7GrE=.9793bbc5-2dfe-43fa-bd72-37430dd0c8a4@github.com>
 <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
Message-ID: <qrUsPgpe8552L4vMyAXvFivTSY7QZcvzZImMxiRG7X0=.0ebbf37e-edd5-4f16-afc2-48e6c34c88ca@github.com>

On Fri, 7 Jul 2023 11:56:28 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Amit's review comments
>
> src/hotspot/cpu/s390/downcallLinker_s390.cpp line 162:
> 
>> 160:   allocated_frame_size += arg_shuffle.out_arg_bytes();
>> 161: 
>> 162:   bool should_save_return_value = !_needs_return_buffer && _needs_transition;;
> 
> Since return buffer is not implemented here, I suggest adding an assert that checks that `_needs_return_buffer` is always false.

Added assert.

> src/hotspot/cpu/s390/foreignGlobals_s390.cpp line 115:
> 
>> 113:   switch (to_reg.type()) {
>> 114:     case StorageType::INTEGER:
>> 115:       if (to_reg.segment_mask() == REG64_MASK && from_reg.segment_mask() == REG32_MASK ) {
> 
> Since this deals with 32 bit regs as well, might want to rename the function to just `move_reg` (i.e drop the `64`)

Renamed.

> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 78:
> 
>> 76:     @CallerSensitive
>> 77:     public final MethodHandle downcallHandle(MemorySegment symbol, FunctionDescriptor function, Option... options) {
>> 78:     Reflection.ensureNativeAccess(Reflection.getCallerClass(), Linker.class, "downcallHandle");
> 
> Looks spurious? Please undo

Fixed

> src/java.base/share/classes/jdk/internal/foreign/abi/s390/S390Architecture.java line 115:
> 
>> 113: 
>> 114:     private static VMStorage floatRegister(int index) {
>> 115:         return new VMStorage(StorageType.FLOAT, REG64_MASK, index, "v" + index);
> 
> Maybe this should be `"f"` instead of `"v"`? (given the names of the variables above)
> Suggestion:
> 
>         return new VMStorage(StorageType.FLOAT, REG64_MASK, index, "f" + index);

Fixed

> src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390CallArranger.java line 136:
> 
>> 134:         return returnLayout
>> 135:             .filter(GroupLayout.class::isInstance)
>> 136:             .filter(layout -> layout instanceof GroupLayout)
> 
> These lines both do the same, so one can be removed.

Fixed

> src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/TypeClass.java line 114:
> 
>> 112:                 return false;
>> 113:                     }
>> 114:         }
> 
> I believe this loop is not needed, since above it's determined that `scalarLayouts` has only 1 element.

Removed, Thank you

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1257228786
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1257228670
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1257228415
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1257228265
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1257228164
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1257228044

From duke at openjdk.org  Sat Jul  8 11:09:59 2023
From: duke at openjdk.org (sid8606)
Date: Sat, 8 Jul 2023 11:09:59 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v2]
In-Reply-To: <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <t_D4CaM9h-wbAm-SvI4hQqCiNYUh1wR1_cVwDCA7GrE=.9793bbc5-2dfe-43fa-bd72-37430dd0c8a4@github.com>
 <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
Message-ID: <BMJPz_QFt9ANhzz2mULpLHxvC4LlFzJfNss5hjsDDsI=.b7677a86-00c2-4527-b27f-9d15980e9b4f@github.com>

On Fri, 7 Jul 2023 12:02:33 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Amit's review comments
>
> src/hotspot/cpu/s390/downcallLinker_s390.cpp line 207:
> 
>> 205:   __ z_lg(callerSP, _z_abi(callers_sp), Z_SP); // preset (used to access caller frame argument slots)
>> 206:   __ block_comment("{ argument shuffle");
>> 207:   arg_shuffle.generate(_masm, as_VMStorage(callerSP), frame::z_jit_out_preserve_size, _abi._shadow_space_bytes, locs);
> 
> I'm not sure exactly what `callerSP` is doing, but it seems to be Z_SP + bias? Why can't the `in_stk_bias` parameter be used for that? (and then use `tmp` for the shuffle reg).

Here we saving the caller frame i.e java stack pointer to use in Argument shuffling, I made the changes to use frame pointer Z_R11 now. hence removed this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1257229839

From duke at openjdk.org  Sat Jul  8 11:13:58 2023
From: duke at openjdk.org (sid8606)
Date: Sat, 8 Jul 2023 11:13:58 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v2]
In-Reply-To: <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <t_D4CaM9h-wbAm-SvI4hQqCiNYUh1wR1_cVwDCA7GrE=.9793bbc5-2dfe-43fa-bd72-37430dd0c8a4@github.com>
 <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
Message-ID: <US5H5629byzQfWST5-IpXZv8C3nVuK1sRt9BbyrqZSY=.e57abe77-6b04-4f1c-947e-bf8c52d19cd2@github.com>

On Fri, 7 Jul 2023 12:06:39 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Amit's review comments
>
> src/hotspot/cpu/s390/foreignGlobals_s390.cpp line 186:
> 
>> 184:     case StorageType::FRAME_DATA: {
>> 185:       switch (from_reg.stack_size()) {
>> 186:         case 8: __ mem2reg_opt(Z_R0_scratch, Address (callerSP, reg2offset(from_reg, in_stk_bias)), true); break;
> 
> A potential issue here is that Z_R0_scratch could be used by the target ABI, that's why the shuffle register is passed as an argument on other platforms. (It also makes it clearer in the calling code that that register is used somehow).

Now using Z_R11 frame pointer and passing shuffle register to use as temp.

> src/hotspot/cpu/s390/upcallLinker_s390.cpp line 172:
> 
>> 170:   //      |---------------------| = frame_bottom_offset = frame_size
>> 171:   //      | (optional)          |
>> 172:   //      | ret_buf             |
> 
> There's no return buffer, so this can be removed.

Fixed

> src/hotspot/cpu/s390/upcallLinker_s390.cpp line 232:
> 
>> 230: 
>> 231:   // return value shuffle
>> 232:   if (!needs_return_buffer) {
> 
> I suggest using an assert here instead.

Added an assert, thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1257230962
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1257231066
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1257231195

From duke at openjdk.org  Sat Jul  8 12:01:53 2023
From: duke at openjdk.org (Swati Sharma)
Date: Sat, 8 Jul 2023 12:01:53 GMT
Subject: RFR: 8311178: JMH tests don't scale well when sharing output
 buffers
In-Reply-To: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
References: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
Message-ID: <yVoF-QkHztc8N5KKv1dFXrgtb8LpCzZzJuH9-M1zW4w=.1fd54f71-62d3-4ef1-a566-3de8b3dfd687@github.com>

On Sat, 1 Jul 2023 07:53:17 GMT, Swati Sharma <duke at openjdk.org> wrote:

> The below benchmark files have scaling issues due to cache contention and leads to poor scaling when run on multiple threads. The patch sets the scope from benchmark level to thread level to fix the issue:
> - org/openjdk/bench/java/io/DataOutputStreamTest.java
> - org/openjdk/bench/java/lang/ArrayCopyObject.java
> - org/openjdk/bench/java/lang/ArrayFiddle.java
> - org/openjdk/bench/java/time/format/DateTimeFormatterBench.java
> - org/openjdk/bench/jdk/incubator/vector/IndexInRangeBenchmark.java
> - org/openjdk/bench/jdk/incubator/vector/MemorySegmentVectorAccess.java
> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedBenchmark.java
> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedIOOBEBenchmark.java
> - org/openjdk/bench/vm/compiler/ArrayFill.java
> - org/openjdk/bench/vm/compiler/IndexVector.java
> 
> Also removing the static scope for variables in org/openjdk/bench/jdk/incubator/vector/VectorFPtoIntCastOperations.java for better scaling.
> 
> Please review and share your feedback.
> 
> Thanks,
> Swati

> Hi, I'm not sure if I understand this improvement correctly. I'm not quite familiar with JMH and it's annotations, but seems to me, the change from `@State(Scope.Benchmark)` to `@State(Scope.Thread)` should not improve the performance by reducing cache contention, as in the jmh doc it says "State objects are usually injected into Benchmark methods as _**arguments**_, and JMH takes care of their instantiation and sharing.", this seems mean that @State only matters when the annotated class is used as a parameter of a @benchmark method, but in the tests you modifed, seems there is no such use case. Please also check the sample usages at https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_03_States.java.

Please check the https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_04_DefaultState.java sample case where @State annotation applies to all instance methods. The PR proposal is to change default state from benchmark to thread.

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

PR Comment: https://git.openjdk.org/jdk/pull/14746#issuecomment-1627181265

From duke at openjdk.org  Sat Jul  8 12:48:53 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 8 Jul 2023 12:48:53 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent
 of close but throws UncheckedIOException [v2]
In-Reply-To: <sU6xopTzco46hc8p2USnYlpqymdqK6h8oihTbebUKic=.bb31c4e0-bb1f-47ed-b1df-f0cb3b456c24@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
 <sU6xopTzco46hc8p2USnYlpqymdqK6h8oihTbebUKic=.bb31c4e0-bb1f-47ed-b1df-f0cb3b456c24@github.com>
Message-ID: <RuCrzg5T3WzSyYQ1E3euQxH8QlxDbL1IdGOarj2kkyg=.94c986bc-fff2-4e55-95b2-f123c07ac1b6@github.com>

On Fri, 7 Jul 2023 15:56:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a default method `java.io.Closeable::closeUnchecked` which is equivalent to `Closeable::close` except that it instead throws `java.io.UncheckedIOException`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8066869: linkplain -> link

Can it be a static method instead of a default method? `Closeable` is a widely used class, so adding new default methods risks conflicting with existing methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/14789#issuecomment-1627236039

From jvernee at openjdk.org  Sat Jul  8 14:24:56 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sat, 8 Jul 2023 14:24:56 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
Message-ID: <k4SU_nGWOzZkNJDUX4Pu-d1gw73vVtpJKP-mzlWiwwI=.9e92f4a6-a82c-44cb-85e4-95a4193d2a3e@github.com>

On Sat, 8 Jul 2023 10:48:15 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address suggestions from Jorn Vernee

The changes look good, thanks. I'll run some testing in our CI.

Not sure if you want to fix https://github.com/openjdk/jdk/pull/14801#discussion_r1255743888 now or later.

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

PR Review: https://git.openjdk.org/jdk/pull/14801#pullrequestreview-1520712793

From kasperni at gmail.com  Sun Jul  9 12:45:48 2023
From: kasperni at gmail.com (Kasper Nielsen)
Date: Sun, 9 Jul 2023 15:45:48 +0300
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the
 equivalent of close but throws UncheckedIOException [v2]
In-Reply-To: <RuCrzg5T3WzSyYQ1E3euQxH8QlxDbL1IdGOarj2kkyg=.94c986bc-fff2-4e55-95b2-f123c07ac1b6@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
 <sU6xopTzco46hc8p2USnYlpqymdqK6h8oihTbebUKic=.bb31c4e0-bb1f-47ed-b1df-f0cb3b456c24@github.com>
 <RuCrzg5T3WzSyYQ1E3euQxH8QlxDbL1IdGOarj2kkyg=.94c986bc-fff2-4e55-95b2-f123c07ac1b6@github.com>
Message-ID: <CAPs6151Eisk6AKUY1nJjX7ezdSovQOney=oE=WOw5AWxiPH_7A@mail.gmail.com>

What would an alternative method signature look like for a method called
closeUnchecked?

On Sat, 8 Jul 2023 at 15.49, Glavo <duke at openjdk.org> wrote:

>
> Can it be a static method instead of a default method? `Closeable` is a
> widely used class, so adding new default methods risks conflicting with
> existing methods.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230709/156a56f5/attachment.htm>

From duke at openjdk.org  Sun Jul  9 16:40:07 2023
From: duke at openjdk.org (ExE Boss)
Date: Sun, 9 Jul 2023 16:40:07 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v6]
In-Reply-To: <BiJjZ5_DTJGBRxDrnR3HokZdcyubNzOoH-6_Q9QY_xk=.f4439c9e-a9d1-41b8-a467-1f2adf6de6bf@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <hY2cN_-xxTyqNZz1AMJC_klQyMPX36UVsjc1c5zSK58=.91762031-9a5d-40c2-b794-423112785629@github.com>
 <90SkXhk3AttjkCDs26NYiysShCkPfCyyi2mYeY432Mw=.c9bac184-e20c-4533-a288-fdb70eaa0a73@github.com>
 <BiJjZ5_DTJGBRxDrnR3HokZdcyubNzOoH-6_Q9QY_xk=.f4439c9e-a9d1-41b8-a467-1f2adf6de6bf@github.com>
Message-ID: <rO_OWRkMfKxcQuQi3bwj1r6ytOFkTwcx-48wTNGBc7M=.01c6c573-9016-477d-a6fe-72755aa5d258@github.com>

On Fri, 7 Jul 2023 23:42:51 GMT, ??? <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/UUID.java line 475:
>> 
>>> 473:         long msb = mostSigBits;
>>> 474:         byte[] buf = new byte[36];
>>> 475:         UNSAFE.putLongUnaligned(
>> 
>> I understood that since UUID was not used during startup, that using VarHandles is the preferred abstraction.
>
> Using VarHandle will be 10% slower than using Unsafe directly, I haven't found the reason yet

I?believe it?s?because `VarHandle`s do?bounds?checking:
https://github.com/openjdk/jdk/blob/581f90e242b8a943215a223189d171b7ede37785/src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template#L113-L116 https://github.com/openjdk/jdk/blob/581f90e242b8a943215a223189d171b7ede37785/src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template#L144-L161

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1257510755

From liach at openjdk.org  Sun Jul  9 23:18:58 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 9 Jul 2023 23:18:58 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: <w6mlIVJl4UKJnBN8H-KPPiuN_JKEW5zoZJey73LzkDI=.b9d53439-8946-4bea-9507-c0cab7f9c4fb@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

Keep alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/13664#issuecomment-1627857356

From alanb at openjdk.org  Mon Jul 10 05:05:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Jul 2023 05:05:13 GMT
Subject: RFR: 8310892: ScopedValue throwing StructureViolationException
 should be clearer [v3]
In-Reply-To: <Gx7CEUhkRn3ykiF7PhJnfMjecw3mTrr3fXFEuOaJIoM=.3c6a7a3b-a445-45a0-9353-5434b6b7e853@github.com>
References: <Gx7CEUhkRn3ykiF7PhJnfMjecw3mTrr3fXFEuOaJIoM=.3c6a7a3b-a445-45a0-9353-5434b6b7e853@github.com>
Message-ID: <peR8bfaksIZORq80OicDER5LT7C786mvB9BteL7eUsU=.5cd3f11a-a6c9-4024-8f0d-d2cd6ca26078@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 with a new target base 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
 - s/ ith/with/
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14679/files
  - new: https://git.openjdk.org/jdk/pull/14679/files/08158fe8..2e94515d

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

  Stats: 52253 lines in 606 files changed: 7072 ins; 42498 del; 2683 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 alanb at openjdk.org  Mon Jul 10 05:23:17 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Jul 2023 05:23:17 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: <C0sNst_uDnRyzwCunCD1fONbrbnKWXd41uvqt1Crb8A=.56f4dceb-17ec-46a4-a75d-c9586f51f38c@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

src/java.base/share/classes/java/lang/ClassLoader.java line 661:

> 659:      * concurrently without deadlocks.  For non-parallel-capable class loaders,
> 660:      * the {@code ClassLoader} object is synchronized on during the class loading
> 661:      * operations.  Class loaders with non-hierarchical delegation should be

At some point we might want to re-visit the use of "non-hierarchical" (and "hierarchical" in the class description) as deadlocks are also possible with hierarchical delegation when mixing parent-first and child-first delegation. It could be that the the API note provides a strong recommendation the class loader be parallel capable when it is anything other than single parent with parent delegation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14720#discussion_r1257723627

From alanb at openjdk.org  Mon Jul 10 05:33:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Jul 2023 05:33:12 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v5]
In-Reply-To: <o1kCrnJzTAiEKF84HDgMZQltwIDLeTBOBXouGC5S_0E=.4087cdc2-b4db-4e35-80ed-72241aee7120@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>
 <o1kCrnJzTAiEKF84HDgMZQltwIDLeTBOBXouGC5S_0E=.4087cdc2-b4db-4e35-80ed-72241aee7120@github.com>
Message-ID: <Li41Umr9wkDUT1zMjWQHBg8LFgSOQkOPTqbN-rv6_e8=.c9f65e17-1d39-4481-a776-9cfdb6d38e83@github.com>

On Fri, 30 Jun 2023 09:57:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Alan, I adjusted the comment in DriverManager.java .

Thanks, the update looks okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1257728322

From jpai at openjdk.org  Mon Jul 10 06:08:03 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Jul 2023 06:08:03 GMT
Subject: RFR: 8310892: ScopedValue throwing StructureViolationException
 should be clearer [v3]
In-Reply-To: <peR8bfaksIZORq80OicDER5LT7C786mvB9BteL7eUsU=.5cd3f11a-a6c9-4024-8f0d-d2cd6ca26078@github.com>
References: <Gx7CEUhkRn3ykiF7PhJnfMjecw3mTrr3fXFEuOaJIoM=.3c6a7a3b-a445-45a0-9353-5434b6b7e853@github.com>
 <peR8bfaksIZORq80OicDER5LT7C786mvB9BteL7eUsU=.5cd3f11a-a6c9-4024-8f0d-d2cd6ca26078@github.com>
Message-ID: <AiTPj8ICcvvwAut9KgbK7333IzRdnRt59gdTxmR7Sg8=.19c5c669-c147-4253-baab-a22a204c2ab2@github.com>

On Mon, 10 Jul 2023 05:05:13 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.
>
> 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
>  - s/ ith/with/
>  - Initial commit

src/java.base/share/classes/java/lang/ScopedValue.java line 405:

> 403:          * as a <em>structure violation</em> when the operation completes (normally or with an
> 404:          * exception). In that case, the underlying construct of the {@code StructuredTaskScope}
> 405:          * is closed and {@link StructureViolationException} is thrown.

Hello Alan, does this mean that the original exception (if any) that caused the completion of the operation would be lost and the caller would instead receive just the `StructureViolationException`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14679#discussion_r1257748611

From alanb at openjdk.org  Mon Jul 10 06:15:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Jul 2023 06:15:56 GMT
Subject: RFR: 8310892: ScopedValue throwing StructureViolationException
 should be clearer [v3]
In-Reply-To: <AiTPj8ICcvvwAut9KgbK7333IzRdnRt59gdTxmR7Sg8=.19c5c669-c147-4253-baab-a22a204c2ab2@github.com>
References: <Gx7CEUhkRn3ykiF7PhJnfMjecw3mTrr3fXFEuOaJIoM=.3c6a7a3b-a445-45a0-9353-5434b6b7e853@github.com>
 <peR8bfaksIZORq80OicDER5LT7C786mvB9BteL7eUsU=.5cd3f11a-a6c9-4024-8f0d-d2cd6ca26078@github.com>
 <AiTPj8ICcvvwAut9KgbK7333IzRdnRt59gdTxmR7Sg8=.19c5c669-c147-4253-baab-a22a204c2ab2@github.com>
Message-ID: <9wCib_fFVr_i06oYQcD60ge3fSEueXGmbxTtr4VrBBU=.78ff1766-8eaa-4076-a35c-a5bfbe3cc50b@github.com>

On Mon, 10 Jul 2023 06:04:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge
>>  - s/ ith/with/
>>  - Initial commit
>
> src/java.base/share/classes/java/lang/ScopedValue.java line 405:
> 
>> 403:          * as a <em>structure violation</em> when the operation completes (normally or with an
>> 404:          * exception). In that case, the underlying construct of the {@code StructuredTaskScope}
>> 405:          * is closed and {@link StructureViolationException} is thrown.
> 
> Hello Alan, does this mean that the original exception (if any) that caused the completion of the operation would be lost and the caller would instead receive just the `StructureViolationException`?

No, it's just means the SVE is suppressed - see the discussion in the CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14679#discussion_r1257753666

From jpai at openjdk.org  Mon Jul 10 06:26:56 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Jul 2023 06:26:56 GMT
Subject: RFR: 8310892: ScopedValue throwing StructureViolationException
 should be clearer [v3]
In-Reply-To: <peR8bfaksIZORq80OicDER5LT7C786mvB9BteL7eUsU=.5cd3f11a-a6c9-4024-8f0d-d2cd6ca26078@github.com>
References: <Gx7CEUhkRn3ykiF7PhJnfMjecw3mTrr3fXFEuOaJIoM=.3c6a7a3b-a445-45a0-9353-5434b6b7e853@github.com>
 <peR8bfaksIZORq80OicDER5LT7C786mvB9BteL7eUsU=.5cd3f11a-a6c9-4024-8f0d-d2cd6ca26078@github.com>
Message-ID: <tjIBaiZ3GUNSUmxzSRtyUln9HUN7CHPt2sYPm7Zlzas=.4e4be6a5-1874-4ea0-991e-d94ac8cb2767@github.com>

On Mon, 10 Jul 2023 05:05:13 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.
>
> 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
>  - s/ ith/with/
>  - Initial commit

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14679#pullrequestreview-1521301185

From jpai at openjdk.org  Mon Jul 10 06:26:57 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Jul 2023 06:26:57 GMT
Subject: RFR: 8310892: ScopedValue throwing StructureViolationException
 should be clearer [v3]
In-Reply-To: <9wCib_fFVr_i06oYQcD60ge3fSEueXGmbxTtr4VrBBU=.78ff1766-8eaa-4076-a35c-a5bfbe3cc50b@github.com>
References: <Gx7CEUhkRn3ykiF7PhJnfMjecw3mTrr3fXFEuOaJIoM=.3c6a7a3b-a445-45a0-9353-5434b6b7e853@github.com>
 <peR8bfaksIZORq80OicDER5LT7C786mvB9BteL7eUsU=.5cd3f11a-a6c9-4024-8f0d-d2cd6ca26078@github.com>
 <AiTPj8ICcvvwAut9KgbK7333IzRdnRt59gdTxmR7Sg8=.19c5c669-c147-4253-baab-a22a204c2ab2@github.com>
 <9wCib_fFVr_i06oYQcD60ge3fSEueXGmbxTtr4VrBBU=.78ff1766-8eaa-4076-a35c-a5bfbe3cc50b@github.com>
Message-ID: <1Zu9UlA5MDtOm784nGH-hR13oGBfs3ZtGkvdrMDdf5A=.07f46e3e-dd51-47f7-83fe-1416f622df35@github.com>

On Mon, 10 Jul 2023 06:13:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ScopedValue.java line 405:
>> 
>>> 403:          * as a <em>structure violation</em> when the operation completes (normally or with an
>>> 404:          * exception). In that case, the underlying construct of the {@code StructuredTaskScope}
>>> 405:          * is closed and {@link StructureViolationException} is thrown.
>> 
>> Hello Alan, does this mean that the original exception (if any) that caused the completion of the operation would be lost and the caller would instead receive just the `StructureViolationException`?
>
> No, it's just means the SVE is suppressed - see the discussion in the CSR.

Thank you, looks good to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14679#discussion_r1257763217

From mli at openjdk.org  Mon Jul 10 08:20:56 2023
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 10 Jul 2023 08:20:56 GMT
Subject: RFR: 8311178: JMH tests don't scale well when sharing output
 buffers
In-Reply-To: <W9KinS6D_i4g8gUr799ayeLSW8opwLlfzwlb3cEdt80=.9a2acdfc-8a86-44df-8218-5424fb28d3d8@github.com>
References: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
 <NAqYeoBo6lmu3_A16aV3Q8aCu5oMK1u7rG4UYUTWZEI=.f7b4bd90-95a5-4714-8604-f32f21adf0cf@github.com>
 <W9KinS6D_i4g8gUr799ayeLSW8opwLlfzwlb3cEdt80=.9a2acdfc-8a86-44df-8218-5424fb28d3d8@github.com>
Message-ID: <gLLj2ES1jEOgVa8lBFi-GZvMJyv3s5-4RV8cbZvy1GA=.c19b32c4-d2d5-4642-9633-649c6ad536bd@github.com>

On Fri, 7 Jul 2023 16:02:57 GMT, Sergey Kuksenko <skuksenko at openjdk.org> wrote:

>> Hi,
>> I'm not sure if I understand this improvement correctly.
>> I'm not quite familiar with JMH and it's annotations, but seems to me, the change from `@State(Scope.Benchmark)` to `@State(Scope.Thread)` should not improve the performance by reducing cache contention, as in the jmh doc it says "State objects are usually injected into Benchmark methods as ***arguments***, and JMH takes care of their instantiation and sharing.", this seems mean that @State only matters when the annotated class is used as a parameter of a @Benchmark method, but in the tests you modifed, seems there is no such use case.
>> Please also check the sample usages at https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_03_States.java.
>
> @Hamlin-Li 
> The PR is fully correct.
> Don't forget, every Java instance method has a specific argument which called "this".  That is why @State annotation is working.

@kuksenko @swati-sha Thanks for explanation. I can understand what you said.
But I'm still not quite sure, as I remember jmh does some code manipulation or instrumentation at source code (or bytecode level?), so the jmh test code you write or see might not be the exact code to be executed at runtime.
It's better to be reviewed further by some one more familiar with jmh, or could you add some data comparing the performance difference, so we can tell it easily?

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

PR Comment: https://git.openjdk.org/jdk/pull/14746#issuecomment-1628469975

From mcimadamore at openjdk.org  Mon Jul 10 11:07:29 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 10 Jul 2023 11:07:29 GMT
Subject: RFR: 8311593: Minor doc issue in MemorySegment::copy
Message-ID: <bDfXS7vDwhA08dual0N-URtyZxX1owyvFFmuL7QM-Rc=.b019c506-7b94-4e74-9fa8-6a296124390e@github.com>

This simple PR fixes an issue where `this segment` was used in the javadoc of two static methods.

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

Commit messages:
 - Initial push

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

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

From dfuchs at openjdk.org  Mon Jul 10 11:10:24 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 10 Jul 2023 11:10:24 GMT
Subject: RFR: 8310892: ScopedValue throwing StructureViolationException
 should be clearer [v3]
In-Reply-To: <peR8bfaksIZORq80OicDER5LT7C786mvB9BteL7eUsU=.5cd3f11a-a6c9-4024-8f0d-d2cd6ca26078@github.com>
References: <Gx7CEUhkRn3ykiF7PhJnfMjecw3mTrr3fXFEuOaJIoM=.3c6a7a3b-a445-45a0-9353-5434b6b7e853@github.com>
 <peR8bfaksIZORq80OicDER5LT7C786mvB9BteL7eUsU=.5cd3f11a-a6c9-4024-8f0d-d2cd6ca26078@github.com>
Message-ID: <E-jfJ-RfHaFB_xx2l_-H_jdD3t2rjy_7giKoSWRl43s=.217e8e00-7551-46d5-80f3-27555c43d3de@github.com>

On Mon, 10 Jul 2023 05:05:13 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.
>
> 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
>  - s/ ith/with/
>  - Initial commit

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14679#pullrequestreview-1521829170

From alanb at openjdk.org  Mon Jul 10 12:37:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Jul 2023 12:37:04 GMT
Subject: Integrated: 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: <pKMuZL2jzIUX9b7yQTF2UvpFkj8CggZnzPWBa-II0Kw=.f64fe34e-6745-452b-9209-ddfca87f8e77@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.

This pull request has now been integrated.

Changeset: 623cfcd0
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/623cfcd04b0c4662e614cb6a3bf52536abc02d5a
Stats:     60 lines in 1 file changed: 12 ins; 6 del; 42 mod

8310892: ScopedValue throwing StructureViolationException should be clearer

Reviewed-by: dfuchs, jpai

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

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

From prappo at openjdk.org  Mon Jul 10 13:51:18 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 10 Jul 2023 13:51:18 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v2]
In-Reply-To: <TnQtpTsqbn-Cbkf8hKAwq9kyS9hW98gVJGUbqKfUAHo=.6c70029e-cc77-4833-a1b5-aa274e6eac1e@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>
 <TnQtpTsqbn-Cbkf8hKAwq9kyS9hW98gVJGUbqKfUAHo=.6c70029e-cc77-4833-a1b5-aa274e6eac1e@github.com>
Message-ID: <yvvpPXfV8w3LVXpyM9M4TrUHbFHMOHgAcgE_IWwU2e0=.99cf43f7-0ac8-4a78-947f-a36393ad2749@github.com>

On Mon, 26 Jun 2023 14:42:11 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> 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.

Back to your two suggestions, Raffaello. On the one hand, I think it's hard to beat the readability of `?:`. On the other hand, such comparison is performance-sensitive and is a pattern in BigInteger. So we might as well extract it into a private utility method whose initial version could look like this:

    static int compareUnequal(int x, int y) {
        return x > y ? 1 : -1;
    }

That method has a clear name and returns only guaranteed values. (You were right about being on the safe side with `Integer.compareUnsigned(x, y)`. Look at its `Byte` cousin, who was a similarly-worded spec but does not only return -1, 0, 1:

    public static int compareUnsigned(byte x, byte y) {
        return Byte.toUnsignedInt(x) - Byte.toUnsignedInt(y);
    }

.)

Then someone experienced in bit-twiddling could probably take it from there and produce a branchless comparison, which will be fast, but likely far from readable or obvious.

I'm not experienced in bit-twiddling, but probably there are some simplifications to that naive solution one could come up from quickly glancing into "Hacker's Delight":

    private final static int[] TAB = new int[]{-1, 1};
    
    public static int compareUnequal(int x, int y) {
        // In HD, 3-valued compare function:
        //  * outputs 0 and 1, but we need -1 and 1
        //  * might not be taking advantage of the fact that x != y
        int idx = (c(y, x) - c(x, y)) >>> 31;
        return TAB[idx];
    }

    private static int c(int x, int y) {
        return (x - y) ^ ((x ^ y) & ((x - y) ^ x));
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1258298626

From skuksenko at openjdk.org  Mon Jul 10 14:06:13 2023
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Mon, 10 Jul 2023 14:06:13 GMT
Subject: RFR: 8311178: JMH tests don't scale well when sharing output
 buffers
In-Reply-To: <gLLj2ES1jEOgVa8lBFi-GZvMJyv3s5-4RV8cbZvy1GA=.c19b32c4-d2d5-4642-9633-649c6ad536bd@github.com>
References: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
 <NAqYeoBo6lmu3_A16aV3Q8aCu5oMK1u7rG4UYUTWZEI=.f7b4bd90-95a5-4714-8604-f32f21adf0cf@github.com>
 <W9KinS6D_i4g8gUr799ayeLSW8opwLlfzwlb3cEdt80=.9a2acdfc-8a86-44df-8218-5424fb28d3d8@github.com>
 <gLLj2ES1jEOgVa8lBFi-GZvMJyv3s5-4RV8cbZvy1GA=.c19b32c4-d2d5-4642-9633-649c6ad536bd@github.com>
Message-ID: <nwNy1HuiFEZEGHSc-uKHCWqwc3rB_6OrypUNcCeEYLk=.6ed3c1f3-5cb0-4982-99ac-e6d0e486c76e@github.com>

On Mon, 10 Jul 2023 08:17:59 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> @Hamlin-Li 
>> The PR is fully correct.
>> Don't forget, every Java instance method has a specific argument which called "this".  That is why @State annotation is working.
>
> @kuksenko @swati-sha Thanks for explanation. I can understand what you said.
> But I'm still not quite sure, as I remember jmh does some code manipulation or instrumentation at source code (or bytecode level?), so the jmh test code you write or see might not be the exact code to be executed at runtime.
> It's better to be reviewed further by some one more familiar with jmh, or could you add some data comparing the performance difference, so we can tell it easily?

@Hamlin-Li 
I am one of JMH's authors. I know how it works. There is no need for tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/14746#issuecomment-1629033698

From jvernee at openjdk.org  Mon Jul 10 14:24:53 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Jul 2023 14:24:53 GMT
Subject: RFR: 8311593: Minor doc issue in MemorySegment::copy
In-Reply-To: <bDfXS7vDwhA08dual0N-URtyZxX1owyvFFmuL7QM-Rc=.b019c506-7b94-4e74-9fa8-6a296124390e@github.com>
References: <bDfXS7vDwhA08dual0N-URtyZxX1owyvFFmuL7QM-Rc=.b019c506-7b94-4e74-9fa8-6a296124390e@github.com>
Message-ID: <H6OFQIdUWIZ8s6Qn474RG02TpnL0m8tGRGM1I-DrFV0=.bdce59b7-08ad-4b9b-bbd9-cd3ca0a59104@github.com>

On Mon, 10 Jul 2023 11:00:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This simple PR fixes an issue where `this segment` was used in the javadoc of two static methods.

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14813#pullrequestreview-1522209900

From rgiulietti at openjdk.org  Mon Jul 10 14:42:56 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 10 Jul 2023 14:42:56 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v2]
In-Reply-To: <yvvpPXfV8w3LVXpyM9M4TrUHbFHMOHgAcgE_IWwU2e0=.99cf43f7-0ac8-4a78-947f-a36393ad2749@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>
 <TnQtpTsqbn-Cbkf8hKAwq9kyS9hW98gVJGUbqKfUAHo=.6c70029e-cc77-4833-a1b5-aa274e6eac1e@github.com>
 <yvvpPXfV8w3LVXpyM9M4TrUHbFHMOHgAcgE_IWwU2e0=.99cf43f7-0ac8-4a78-947f-a36393ad2749@github.com>
Message-ID: <oNl2Z0muX2_X-uwil__YnDiNrwLc2Ssvhfyaj2R0_wI=.1c5b65d2-0432-4c7b-8f51-8f45eedc148a@github.com>

On Mon, 10 Jul 2023 13:48:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Yep, you're right.
>
> Back to your two suggestions, Raffaello. On the one hand, I think it's hard to beat the readability of `?:`. On the other hand, such comparison is performance-sensitive and is a pattern in BigInteger. So we might as well extract it into a private utility method whose initial version could look like this:
> 
>     static int compareUnequal(int x, int y) {
>         return x > y ? 1 : -1;
>     }
> 
> That method has a clear name and returns only guaranteed values. (You were right about being on the safe side with `Integer.compareUnsigned(x, y)`. Look at its `Byte` cousin, who was a similarly-worded spec but does not only return -1, 0, 1:
> 
>     public static int compareUnsigned(byte x, byte y) {
>         return Byte.toUnsignedInt(x) - Byte.toUnsignedInt(y);
>     }
> 
> .)
> 
> Then someone experienced in bit-twiddling could probably take it from there and produce a branchless comparison, which will be fast, but likely far from readable or obvious.
> 
> I'm not experienced in bit-twiddling, but probably there are some simplifications to that naive solution one could come up from quickly glancing into "Hacker's Delight":
> 
>     private final static int[] TAB = new int[]{-1, 1};
>     
>     public static int compareUnequal(int x, int y) {
>         // In HD, 3-valued compare function:
>         //  * outputs 0 and 1, but we need -1 and 1
>         //  * might not be taking advantage of the fact that x != y
>         int idx = (c(y, x) - c(x, y)) >>> 31;
>         return TAB[idx];
>     }
> 
>     private static int c(int x, int y) {
>         return (x - y) ^ ((x ^ y) & ((x - y) ^ x));
>     }

`Comparable.compareTo()` is defined to return a negative, zero, or positive integer, not necessarily -1, 0, 1. Code that depends on specific values like the latter is not robust. That said, I have no clue why `BigInteger.compareTo()`'s spec mentions these specific values.

As for bit twiddling, I would not make the code less readable, except in highly performance sensitive code.

(BTW, rather than the `TAB `array above, I would compute the result as: `2 * idx - 1`, or `(idx << 1) - 1` if you don't trust you compiler. But in the end I think branches in modern CPUs are faster than all that twiddling.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1258370514

From mullan at openjdk.org  Mon Jul 10 14:44:24 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 10 Jul 2023 14:44:24 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v10]
In-Reply-To: <Q38GHs2heGPTM512RZt80CzBI9uK5cir5Vrhqy6ytoM=.72abc91a-d5f2-4b1b-b51e-57e51a826020@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <Q38GHs2heGPTM512RZt80CzBI9uK5cir5Vrhqy6ytoM=.72abc91a-d5f2-4b1b-b51e-57e51a826020@github.com>
Message-ID: <BcRW3wTj5DXL54bo7asqfNmetMGX9DjmAv28KVOwq74=.c1939faa-ed38-440b-92f1-7657484fdb93@github.com>

On Fri, 7 Jul 2023 19:42:18 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:
> 
>  - Harden code to report lack of SSL support
>  - Testcase correction

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14394#pullrequestreview-1522251783

From mcimadamore at openjdk.org  Mon Jul 10 15:07:21 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 10 Jul 2023 15:07:21 GMT
Subject: Integrated: 8311593: Minor doc issue in MemorySegment::copy
In-Reply-To: <bDfXS7vDwhA08dual0N-URtyZxX1owyvFFmuL7QM-Rc=.b019c506-7b94-4e74-9fa8-6a296124390e@github.com>
References: <bDfXS7vDwhA08dual0N-URtyZxX1owyvFFmuL7QM-Rc=.b019c506-7b94-4e74-9fa8-6a296124390e@github.com>
Message-ID: <2otuEXEWlowF-A89Hyn6S8dQG1M4tDllaGiQ7Vi0LUk=.ef0cb838-7a2a-457a-a30e-4a2b85b08ede@github.com>

On Mon, 10 Jul 2023 11:00:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This simple PR fixes an issue where `this segment` was used in the javadoc of two static methods.

This pull request has now been integrated.

Changeset: 6569b252
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6569b252b9e61e3eed77039c483529154feffbba
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8311593: Minor doc issue in MemorySegment::copy

Reviewed-by: jvernee

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

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

From mcimadamore at openjdk.org  Mon Jul 10 15:16:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 10 Jul 2023 15:16:27 GMT
Subject: [jdk21] RFR: 8311593: Minor doc issue in MemorySegment::copy
Message-ID: <_VELzPHfPysw4v_wJkp3AGpU6dFT5EC268Q8leUIbAc=.ca6525de-5e00-4085-b11a-bfac4f807c99@github.com>

Clean backport of https://git.openjdk.org/jdk/pull/14813

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

Commit messages:
 - Backport 6569b252b9e61e3eed77039c483529154feffbba

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

PR: https://git.openjdk.org/jdk21/pull/107

From rgiulietti at openjdk.org  Mon Jul 10 15:18:16 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 10 Jul 2023 15:18:16 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v2]
In-Reply-To: <oNl2Z0muX2_X-uwil__YnDiNrwLc2Ssvhfyaj2R0_wI=.1c5b65d2-0432-4c7b-8f51-8f45eedc148a@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>
 <TnQtpTsqbn-Cbkf8hKAwq9kyS9hW98gVJGUbqKfUAHo=.6c70029e-cc77-4833-a1b5-aa274e6eac1e@github.com>
 <yvvpPXfV8w3LVXpyM9M4TrUHbFHMOHgAcgE_IWwU2e0=.99cf43f7-0ac8-4a78-947f-a36393ad2749@github.com>
 <oNl2Z0muX2_X-uwil__YnDiNrwLc2Ssvhfyaj2R0_wI=.1c5b65d2-0432-4c7b-8f51-8f45eedc148a@github.com>
Message-ID: <MJErU7SRTytbpjcKXHHQ95xPG_KH3vtWYk8dz-8b95w=.657b21a9-f262-4026-8a95-280cfdaa6282@github.com>

On Mon, 10 Jul 2023 14:39:51 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Back to your two suggestions, Raffaello. On the one hand, I think it's hard to beat the readability of `?:`. On the other hand, such comparison is performance-sensitive and is a pattern in BigInteger. So we might as well extract it into a private utility method whose initial version could look like this:
>> 
>>     static int compareUnequal(int x, int y) {
>>         return x > y ? 1 : -1;
>>     }
>> 
>> That method has a clear name and returns only guaranteed values. (You were right about being on the safe side with `Integer.compareUnsigned(x, y)`. Look at its `Byte` cousin, who was a similarly-worded spec but does not only return -1, 0, 1:
>> 
>>     public static int compareUnsigned(byte x, byte y) {
>>         return Byte.toUnsignedInt(x) - Byte.toUnsignedInt(y);
>>     }
>> 
>> .)
>> 
>> Then someone experienced in bit-twiddling could probably take it from there and produce a branchless comparison, which will be fast, but likely far from readable or obvious.
>> 
>> I'm not experienced in bit-twiddling, but probably there are some simplifications to that naive solution one could come up from quickly glancing into "Hacker's Delight":
>> 
>>     private final static int[] TAB = new int[]{-1, 1};
>>     
>>     public static int compareUnequal(int x, int y) {
>>         // In HD, 3-valued compare function:
>>         //  * outputs 0 and 1, but we need -1 and 1
>>         //  * might not be taking advantage of the fact that x != y
>>         int idx = (c(y, x) - c(x, y)) >>> 31;
>>         return TAB[idx];
>>     }
>> 
>>     private static int c(int x, int y) {
>>         return (x - y) ^ ((x ^ y) & ((x - y) ^ x));
>>     }
>
> `Comparable.compareTo()` is defined to return a negative, zero, or positive integer, not necessarily -1, 0, 1. Code that depends on specific values like the latter is not robust. That said, I have no clue why `BigInteger.compareTo()`'s spec mentions these specific values.
> 
> As for bit twiddling, I would not make the code less readable, except in highly performance sensitive code.
> 
> (BTW, rather than the `TAB `array above, I would compute the result as: `2 * idx - 1`, or `(idx << 1) - 1` if you don't trust you compiler. But in the end I think branches in modern CPUs are faster than all that twiddling.)

A branchless way to clamp an `int v` to {-1, 0, 1} depending on whether `v < 0`, `v == 0`, or `v > 0` is

(v >> 31) | ((v | -v) >>> 31);

This extends to `long` as well: replace `31` by `63`.

If left uncommented, this is less readable than branches.
In addition, you'd need to measure whether 5 ops are better than 2 branches: you might be surprised ;-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1258420065

From rgiulietti at openjdk.org  Mon Jul 10 15:19:05 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 10 Jul 2023 15:19:05 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v2]
In-Reply-To: <oNl2Z0muX2_X-uwil__YnDiNrwLc2Ssvhfyaj2R0_wI=.1c5b65d2-0432-4c7b-8f51-8f45eedc148a@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>
 <TnQtpTsqbn-Cbkf8hKAwq9kyS9hW98gVJGUbqKfUAHo=.6c70029e-cc77-4833-a1b5-aa274e6eac1e@github.com>
 <yvvpPXfV8w3LVXpyM9M4TrUHbFHMOHgAcgE_IWwU2e0=.99cf43f7-0ac8-4a78-947f-a36393ad2749@github.com>
 <oNl2Z0muX2_X-uwil__YnDiNrwLc2Ssvhfyaj2R0_wI=.1c5b65d2-0432-4c7b-8f51-8f45eedc148a@github.com>
Message-ID: <MJErU7SRTytbpjcKXHHQ95xPG_KH3vtWYk8dz-8b95w=.7cdf2647-6749-49f6-bffe-ece7c09cd942@github.com>

On Mon, 10 Jul 2023 14:39:51 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Back to your two suggestions, Raffaello. On the one hand, I think it's hard to beat the readability of `?:`. On the other hand, such comparison is performance-sensitive and is a pattern in BigInteger. So we might as well extract it into a private utility method whose initial version could look like this:
>> 
>>     static int compareUnequal(int x, int y) {
>>         return x > y ? 1 : -1;
>>     }
>> 
>> That method has a clear name and returns only guaranteed values. (You were right about being on the safe side with `Integer.compareUnsigned(x, y)`. Look at its `Byte` cousin, who was a similarly-worded spec but does not only return -1, 0, 1:
>> 
>>     public static int compareUnsigned(byte x, byte y) {
>>         return Byte.toUnsignedInt(x) - Byte.toUnsignedInt(y);
>>     }
>> 
>> .)
>> 
>> Then someone experienced in bit-twiddling could probably take it from there and produce a branchless comparison, which will be fast, but likely far from readable or obvious.
>> 
>> I'm not experienced in bit-twiddling, but probably there are some simplifications to that naive solution one could come up from quickly glancing into "Hacker's Delight":
>> 
>>     private final static int[] TAB = new int[]{-1, 1};
>>     
>>     public static int compareUnequal(int x, int y) {
>>         // In HD, 3-valued compare function:
>>         //  * outputs 0 and 1, but we need -1 and 1
>>         //  * might not be taking advantage of the fact that x != y
>>         int idx = (c(y, x) - c(x, y)) >>> 31;
>>         return TAB[idx];
>>     }
>> 
>>     private static int c(int x, int y) {
>>         return (x - y) ^ ((x ^ y) & ((x - y) ^ x));
>>     }
>
> `Comparable.compareTo()` is defined to return a negative, zero, or positive integer, not necessarily -1, 0, 1. Code that depends on specific values like the latter is not robust. That said, I have no clue why `BigInteger.compareTo()`'s spec mentions these specific values.
> 
> As for bit twiddling, I would not make the code less readable, except in highly performance sensitive code.
> 
> (BTW, rather than the `TAB `array above, I would compute the result as: `2 * idx - 1`, or `(idx << 1) - 1` if you don't trust you compiler. But in the end I think branches in modern CPUs are faster than all that twiddling.)

A branchless way to clamp an `int v` to {-1, 0, 1} depending on whether `v < 0`, `v == 0`, or `v > 0` is

(v >> 31) | ((v | -v) >>> 31);

This extends to `long` as well: replace `31` by `63`.

If left uncommented, this is less readable than branches.
In addition, you'd need to measure whether 5 ops are better than 2 branches: you might be surprised ;-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1258420065

From jjiang at openjdk.org  Mon Jul 10 16:11:13 2023
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 10 Jul 2023 16:11:13 GMT
Subject: RFR: 8311178: JMH tests don't scale well when sharing output
 buffers
In-Reply-To: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
References: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
Message-ID: <Ult5GXO3qfcaygqPQTLWzu87heWds_Va3KE7cVSpaw8=.9e7e84a5-44f8-49e7-8a02-2244d14eddce@github.com>

On Sat, 1 Jul 2023 07:53:17 GMT, Swati Sharma <duke at openjdk.org> wrote:

> The below benchmark files have scaling issues due to cache contention and leads to poor scaling when run on multiple threads. The patch sets the scope from benchmark level to thread level to fix the issue:
> - org/openjdk/bench/java/io/DataOutputStreamTest.java
> - org/openjdk/bench/java/lang/ArrayCopyObject.java
> - org/openjdk/bench/java/lang/ArrayFiddle.java
> - org/openjdk/bench/java/time/format/DateTimeFormatterBench.java
> - org/openjdk/bench/jdk/incubator/vector/IndexInRangeBenchmark.java
> - org/openjdk/bench/jdk/incubator/vector/MemorySegmentVectorAccess.java
> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedBenchmark.java
> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedIOOBEBenchmark.java
> - org/openjdk/bench/vm/compiler/ArrayFill.java
> - org/openjdk/bench/vm/compiler/IndexVector.java
> 
> Also removing the static scope for variables in org/openjdk/bench/jdk/incubator/vector/VectorFPtoIntCastOperations.java for better scaling.
> 
> Please review and share your feedback.
> 
> Thanks,
> Swati

Not review this PR, but just raise a question.
Should a JMH test, at least in JDK repo, always uses `@State(Scope.Thread)`, even though it uses only one thread?

I just looked through those JMH tests, and found all of them, like the bellows, don't specify the number of threads via `@Threads`.


org/openjdk/bench/java/io/DataOutputStreamTest.java
org/openjdk/bench/java/lang/ArrayCopyObject.java


I suppose the default number of threads is 1.
Maybe the default value will be overridden via the commands when running these JMH tests in bulk (?)

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

PR Comment: https://git.openjdk.org/jdk/pull/14746#issuecomment-1629261727

From duke at openjdk.org  Mon Jul 10 16:31:18 2023
From: duke at openjdk.org (sid8606)
Date: Mon, 10 Jul 2023 16:31:18 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v2]
In-Reply-To: <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <t_D4CaM9h-wbAm-SvI4hQqCiNYUh1wR1_cVwDCA7GrE=.9793bbc5-2dfe-43fa-bd72-37430dd0c8a4@github.com>
 <X-SHhefBX8xbFZqMIiwa8qBwg4CIDh_gWu2r45fM2W0=.bf54e3b1-5c49-468d-acdc-4e085f89feb2@github.com>
Message-ID: <CO2ZrUuBQTIDfkRFuZwaUo7lC-RCLJXavkKDKxROVjg=.4ea1df97-661d-4f4e-8f8c-e4ff2cb01c8d@github.com>

On Fri, 7 Jul 2023 12:24:10 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Amit's review comments
>
> src/hotspot/cpu/s390/upcallLinker_s390.cpp line 243:
> 
>> 241:         case T_CHAR:
>> 242:         case T_INT:
>> 243:           __ z_lgfr(Z_RET, Z_RET); // Clear garbage in high half.
> 
> Same as PPC here; this should really be done on the Java side. (See: https://github.com/openjdk/jdk/pull/12708#issuecomment-1440433079 and related discussion)

I plan to fix it later once done with experiments with this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1258555188

From jvernee at openjdk.org  Mon Jul 10 16:50:59 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Jul 2023 16:50:59 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
Message-ID: <pkWVqvldVFieTiikR1A3flW8OFSHhsbAeT0_ob_Mt7A=.77ea58c3-f2bb-42bc-b4cd-dca47ae5ed23@github.com>

On Sat, 8 Jul 2023 10:48:15 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address suggestions from Jorn Vernee

Tests came back green

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14801#pullrequestreview-1522544318

From bpb at openjdk.org  Mon Jul 10 17:04:14 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 10 Jul 2023 17:04:14 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1 [v2]
In-Reply-To: <sdpWmVKOJiYIfy_GyLYcnKpzS_XeTokxrtB8qOAAby4=.ed036671-f703-4bf7-b1e4-55012d6ecc7c@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
 <CN_eDr4hn06aPLpQErLX8TD5qQAYKsAuatQDvfVPy4Q=.b6b6a07f-0cae-4244-96c3-337f9faa9e0d@github.com>
 <av30ChJTZb9rkea0qm3DTwLikGVMcMb2Cm086rKhCeY=.b8d781a2-db26-41c8-992b-69e368035e18@github.com>
 <sdpWmVKOJiYIfy_GyLYcnKpzS_XeTokxrtB8qOAAby4=.ed036671-f703-4bf7-b1e4-55012d6ecc7c@github.com>
Message-ID: <SkOU0MV93pKreENjY2g_zwOsg70rpOJIqSYcgcMFjvc=.4e1fcfc8-2f84-47c8-b072-257435e26b9c@github.com>

On Fri, 7 Jul 2023 18:14:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> I would not want to give any assurances about whether the bytes of an encoded primitive were written individually or as a group.
>> 
>> Would it be helpful to add further verbiage?
>> 
>> For example, the sequence of bytes comprising the primitive data type may be written as more than one packet of bytes.
>
> "packet" is network centric terminology.
> Perhaps something like:  "may be written individually or in any grouping of bytes"

Commit 43c392e8c797f5a5c29a67e87f350e8dc9c5b190 changed it to

The write methods of this class delegate to the methods
of the underlying output stream, hence there is no 
guarantee as to the details of how the bytes are written.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14791#discussion_r1258602797

From naoto at openjdk.org  Mon Jul 10 17:10:20 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 10 Jul 2023 17:10:20 GMT
Subject: Integrated: 8311528: Remove IDE specific SuppressWarnings
In-Reply-To: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>
References: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>
Message-ID: <jo6IgqyipyEM2QDIbBRwOtxCEYjGW1_nECOSi-JgKvM=.08a5a920-2152-45a2-9e70-f1f993548df8@github.com>

On Thu, 6 Jul 2023 21:03:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the IDE specific `@SuppressWarnings` attached to `java.util.Calendar#equals()`. `equals()` implementation now checks the type of the other instance for this.

This pull request has now been integrated.

Changeset: 63f32fbe
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/63f32fbe9771b8200f707ed5d1d0e6555ad90f8b
Stats:     15 lines in 1 file changed: 1 ins; 1 del; 13 mod

8311528: Remove IDE specific SuppressWarnings

Reviewed-by: lancea, bpb, jlu

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

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

From darcy at openjdk.org  Mon Jul 10 17:10:16 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 10 Jul 2023 17:10:16 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v2]
In-Reply-To: <pTMvEIx5UPajYBUi4pCgN6CsyzVd6tlJhqcla4D3nV4=.c8aa7c9d-4bbe-482e-8b96-1423950105eb@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <pTMvEIx5UPajYBUi4pCgN6CsyzVd6tlJhqcla4D3nV4=.c8aa7c9d-4bbe-482e-8b96-1423950105eb@github.com>
Message-ID: <-hRTcFsCaDtdobIiQV-dfh1eeAEcT18sk972TG0QRRU=.6aff2ebf-b146-4483-98c7-29b342d674d9@github.com>

On Thu, 29 Jun 2023 15:50:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Add a benchmark
>>  - Merge branch 'master' into 8310813
>>  - Use fewer range checks to improve performance
>>  - Improve
>>  - Initial commit
>
> LGTM; I assume the comment about aarch64 perf was a 10% improvement.

> Here's some explanation for the recent commits I've added since @RogerRiggs reviewed this PR.
> 
>     1. Since `BigInteger.hashCode()` is unspecified, we can change it. Again: I think that the proposed implementation is no worse in hashing quality than the current one; if you disagree, please voice your concerns.
> 
> 
> FWIW, we can keep the existing `BigInteger.hashCode()` values whilst still improving the implementation, using JDK-internal support:
> 
> ```
> @Override
> public int hashCode() {
>     return ArraysSupport.vectorizedHashCode(mag, 0, mag.length, 1,
>             ArraysSupport.T_INT) * signum;
> }
> ```
> 
> AFAIU, such an implementation would always yield exactly the same values the current (i.e. mainline) implementation does. But that could be a little slower than the original proposal, especially for a smaller BigInteger.
> 
> The key thing that allows to keep the current hash-code values in the above implementation is that `1` argument, which is the initial hash-code value, which cannot be specified in `Arrays.hashCode`. Unfortunately, we don't have mid-layer methods in between Arrays.hashCode and ArraysSupport.vectorizedHashCode like that of Arrays.mismatch and ArraysSupport.vectorizedMismatch. It's either all the null check but short-circuits or unconditional vectorization but the initial value. I wonder if we could consider `ArraysSupport.hashCode($type[] array, int fromIndex, int length, int initialValue)` overloads, which could be useful beyond BigInteger, as I've already seen in JDK. Contributors to ArraysSupport, @PaulSandoz, @ChrisHegarty, @cl4es, @stuart-marks; thoughts?
> 
>     2. Maybe surprisingly, but we don't have microbenchmarks for BigInteger's equals, hashCode, and compareTo. While I don't know how often people use the former two methods, I reckon, the latter method is essential. Anyway, I added benchmarks to cover all three. Note: benchmark for hashCode shows only its performance, not its hashing quality. Again: if you think the current version is in any way worse than the mainline version, please voice your concerns.
> 
> 
> AFAIK, the biggest consumer of BigInteger in JDK is security area. So, I assume a good way to judge this change is to run security benchmarks to make sure they haven't slipped.

I would be in favor of keeping the current hash behavior for now, even if it is updated in subsequent work. Users have had more than two decades to become, accidentally, reliant on the hash algorithms.

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

PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1629373643

From darcy at openjdk.org  Mon Jul 10 17:27:12 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 10 Jul 2023 17:27:12 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent
 of close but throws UncheckedIOException [v2]
In-Reply-To: <sU6xopTzco46hc8p2USnYlpqymdqK6h8oihTbebUKic=.bb31c4e0-bb1f-47ed-b1df-f0cb3b456c24@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
 <sU6xopTzco46hc8p2USnYlpqymdqK6h8oihTbebUKic=.bb31c4e0-bb1f-47ed-b1df-f0cb3b456c24@github.com>
Message-ID: <YipUGI9iOZPsbEd9K43TJYiR9XGmss9xtPeZmJLKe9I=.469cb22e-352a-4ded-96d7-514de5df3758@github.com>

On Fri, 7 Jul 2023 15:56:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a default method `java.io.Closeable::closeUnchecked` which is equivalent to `Closeable::close` except that it instead throws `java.io.UncheckedIOException`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8066869: linkplain -> link

Hmm.

If the goal was to preserve the ability to use the try-with-resources statement, then a utility method that wrapped a java.io.Closeable with a java.io.UncheckedCloseable would be needed, where UncheckedCloseable had a close method that was declared to not throw any exceptions and did the IOException wrapping.

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

PR Comment: https://git.openjdk.org/jdk/pull/14789#issuecomment-1629398735

From jvernee at openjdk.org  Mon Jul 10 17:33:19 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Jul 2023 17:33:19 GMT
Subject: [jdk21] RFR: 8311593: Minor doc issue in MemorySegment::copy
In-Reply-To: <_VELzPHfPysw4v_wJkp3AGpU6dFT5EC268Q8leUIbAc=.ca6525de-5e00-4085-b11a-bfac4f807c99@github.com>
References: <_VELzPHfPysw4v_wJkp3AGpU6dFT5EC268Q8leUIbAc=.ca6525de-5e00-4085-b11a-bfac4f807c99@github.com>
Message-ID: <I17jeaeXTnEzhFYEWZAXXTcEZIlUyHQue3H_u3G6SB8=.2135b936-24c4-46aa-95a7-2476ec067a36@github.com>

On Mon, 10 Jul 2023 15:08:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Clean backport of https://git.openjdk.org/jdk/pull/14813

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/107#pullrequestreview-1522609664

From alanb at openjdk.org  Mon Jul 10 18:08:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Jul 2023 18:08:21 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent
 of close but throws UncheckedIOException [v2]
In-Reply-To: <sU6xopTzco46hc8p2USnYlpqymdqK6h8oihTbebUKic=.bb31c4e0-bb1f-47ed-b1df-f0cb3b456c24@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
 <sU6xopTzco46hc8p2USnYlpqymdqK6h8oihTbebUKic=.bb31c4e0-bb1f-47ed-b1df-f0cb3b456c24@github.com>
Message-ID: <Yi7X-uOxkAaFEPKUoCcrwYQxh8PzFs6drvTMi91-Q20=.64f99f31-a8bf-4512-98ce-fce224aff3e0@github.com>

On Fri, 7 Jul 2023 15:56:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a default method `java.io.Closeable::closeUnchecked` which is equivalent to `Closeable::close` except that it instead throws `java.io.UncheckedIOException`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8066869: linkplain -> link

> Add a default method `java.io.Closeable::closeUnchecked` which is equivalent to `Closeable::close` except that it instead throws `java.io.UncheckedIOException`.

I'm not sure about the usefulness of this as it means using try-finally instead of try-with-resources. To continue to use try-with-resources would need a new interface + some kind of adaptor. Also probably need to think about the code in the block. Calls to methods such as read/write will throw IOException so code will have to deal with them anyway - maybe you could a migrate a few examples using some of the common closeables to see if this is the case.

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

PR Comment: https://git.openjdk.org/jdk/pull/14789#issuecomment-1629455470

From duke at openjdk.org  Mon Jul 10 18:14:18 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 10 Jul 2023 18:14:18 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent
 of close but throws UncheckedIOException [v2]
In-Reply-To: <sU6xopTzco46hc8p2USnYlpqymdqK6h8oihTbebUKic=.bb31c4e0-bb1f-47ed-b1df-f0cb3b456c24@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
 <sU6xopTzco46hc8p2USnYlpqymdqK6h8oihTbebUKic=.bb31c4e0-bb1f-47ed-b1df-f0cb3b456c24@github.com>
Message-ID: <WaJrEf6cpHKr3EZepE7oWfFv44e-Zelf9r6mj5n7Ax0=.cd385100-af1a-4980-a919-74a504cd7d0a@github.com>

On Fri, 7 Jul 2023 15:56:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a default method `java.io.Closeable::closeUnchecked` which is equivalent to `Closeable::close` except that it instead throws `java.io.UncheckedIOException`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8066869: linkplain -> link

I don't like this PR. The problems it can solve are very limited, and the way to solve the problem is not an excellent solution worth promoting.

After the introduction of lambda in Java 8, the cumbersomeness brought by checked exceptions became more prominent. I think we need a more general construct to solve this, rather than just adding some helper methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/14789#issuecomment-1629462808

From mchung at openjdk.org  Mon Jul 10 18:18:31 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 10 Jul 2023 18:18:31 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v22]
In-Reply-To: <cKUEte7iDFjGSjnpWp4Otw-jr49x33S9JARZkrvWng8=.cfdd4210-9319-4f3b-b731-de2befc00eb2@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <cKUEte7iDFjGSjnpWp4Otw-jr49x33S9JARZkrvWng8=.cfdd4210-9319-4f3b-b731-de2befc00eb2@github.com>
Message-ID: <DWF3tGxV-nUwRY-ukLmeSdjWNzpfO-I74mOfMz5Rprk=.16f92ff8-8d19-4f03-a9ed-df3e59a2e623@github.com>

On Fri, 7 Jul 2023 06:45:46 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 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:
> 
>   Fix broken null behaviors

Looks good in general.   Can you please add a test to verify that the hidden class is unloaded and then call `asInterfaceInstace` again on the same interface to spin a new class.

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 185:

> 183:      *
> 184:      * The shared-class implementation is also closer in behavior to the original
> 185:      * proxy-backed implementation. We might add another API for super-customized instances.

The implementor note mainly specifies that there is no guarantee on a stable mapping of the SAM interface to the implementation class.

I see this new note you added is to document the current implementation and alternatives.   I would move this closer to the code (see below).   I made some suggested edits.   I avoid using the term "super-customized" since it's not clear what it means unless reading JBS comments.  I also avoid referring to Project Leyden but instead describes it with some reasonable details say "more friendly for pre-generation....".

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 209:

> 207:             mh = target;
> 208:         }
> 209: 

What about this comment rephrased from the new note you added:


        // Define one hidden class for each interface.  Create an instance of
        // the hidden class for a given target method handle which will be
        // accessed via getfield.  Multiple instances may be created for a
        // hidden class.  This approach allows the generated hidden classes
        // more shareable.
        //
        // An alternative approach is to define one hidden class with the
        // target method handle as class data and the target method handle
        // is loaded via ldc/condy.  If more than one target method handles
        // are used, the extra classes will pollute the same type profiles.
        // In addition, hidden classes without class data is more friendly
        // for pre-generation (shifting the dynamic class generation from
        // runtime to an earlier phrase).
        //

test/jdk/java/lang/invoke/MethodHandleProxies/BasicTest.java line 183:

> 181: 
> 182:     @Test
> 183:     public void testModule() throws Throwable {

This test case belongs more to `ProxyForMethodHandleTest` test, which verifies if it's a dynamic module.   We can move the package exports tests to `ProxyForMethodHandleTest`.

test/jdk/java/lang/invoke/MethodHandleProxies/ProxyForMethodHandleTest.java line 61:

> 59: 
> 60:     public static void assertDynamicModule(Module m, ClassLoader ld, Class<?> proxyClass) {
> 61:         if (!m.isNamed() || !m.getName().startsWith("jdk.MHProxy")) {

This can also check if the package of the proxy class is not unconditionally exported.

test/jdk/java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java line 54:

> 52:         } catch (Throwable ex) {
> 53:             throw new AssertionError("Test failed for " + cl, ex);
> 54:         }

Nit: formatting - try block inside the for-loop
Suggestion:

        for (Class<?> cl : List.of(Runnable.class, Client.class, NestedInterface.class)) {
            try {
                Object o = MethodHandleProxies.asInterfaceInstance(cl, originalMh);
                testWrapperInstanceTarget(o, originalMh);
                testWrapperInstanceType(o, cl);
            } catch (Throwable ex) {
                throw new AssertionError("Test failed for " + cl, ex);
            }
        }

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

PR Review: https://git.openjdk.org/jdk/pull/13197#pullrequestreview-1519328472
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1258671075
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1258671964
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1256560775
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1256562501
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1256158328

From duke at openjdk.org  Mon Jul 10 18:27:20 2023
From: duke at openjdk.org (Jenny Shivayogi)
Date: Mon, 10 Jul 2023 18:27:20 GMT
Subject: RFR: 8311645: Memory leak in jspawnhelper spawnChild after JDK-8307990
Message-ID: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>

Free-ing 'buf' before two conditional return statements introduced by JDK-8307990

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

Commit messages:
 - removing tab space and resolving merge conflict
 - Merge branch 'openjdk:master' into JDK-8311645
 - removing tab space
 - freeing the buf before return
 - removing tab space

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

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

From shade at openjdk.org  Mon Jul 10 18:27:21 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Jul 2023 18:27:21 GMT
Subject: RFR: 8311645: Memory leak in jspawnhelper spawnChild after
 JDK-8307990
In-Reply-To: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
References: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
Message-ID: <9uACtVbScRxHs61JSDL-4nA3b8ol3DUXYyqk8zdj2T0=.b08c4fb3-5000-4658-8f26-b4dfd394eaf0@github.com>

On Sat, 8 Jul 2023 02:05:27 GMT, Jenny Shivayogi <duke at openjdk.org> wrote:

> Free-ing 'buf' before two conditional return statements introduced by JDK-8307990

Looks okay, but need to fix two whitespace errors for jcheck to be happy.
Also, attention @simonis, whose patch introduced this little problem, I think.

src/java.base/unix/native/libjava/ProcessImpl_md.c line 566:

> 564:     if (writeFully(c->childenv[1], (char *)&magic, sizeof(magic)) != sizeof(magic)) { // magic number first
> 565:         free(buf);
> 566: 	return -1;

See jcheck warnings: there is `TAB` on this line, which should be replaced by 4-space indents.

src/java.base/unix/native/libjava/ProcessImpl_md.c line 575:

> 573:         writeFully(c->childenv[1], buf, bufsize) != bufsize) {
> 574:         free(buf);
> 575: 	return -1;

Same here.

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

Changes requested by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14809#pullrequestreview-1521836916
PR Review Comment: https://git.openjdk.org/jdk/pull/14809#discussion_r1258092041
PR Review Comment: https://git.openjdk.org/jdk/pull/14809#discussion_r1258092196

From simonis at openjdk.org  Mon Jul 10 18:27:21 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 10 Jul 2023 18:27:21 GMT
Subject: RFR: 8311645: Memory leak in jspawnhelper spawnChild after
 JDK-8307990
In-Reply-To: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
References: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
Message-ID: <UZy69in42TcIaBIOadNV13QcUksDAPZdXwUEU9R4NcQ=.b8b8596b-9dff-4853-80e3-40cd4cdd83a2@github.com>

On Sat, 8 Jul 2023 02:05:27 GMT, Jenny Shivayogi <duke at openjdk.org> wrote:

> Free-ing 'buf' before two conditional return statements introduced by JDK-8307990

Hi @kspeeyu ,

Thanks for fixing this issue. The fix looks good except the whitespace issue already mentioned before.

Notice that we don't use TABs for code indentation in OpenJDK. For the native Hotspot sources (i.e. the ones under `src/hotspot/`) we use an indentation of two spaces whereas for Java code and the native part of the class library (i.e. the native code outside `src/hotspot`) we use four spaces. We don't change the indentation of imported libraries like HarfBuzz or zlib at all.

You can find more details on the coding style under https://github.com/openjdk/jdk/tree/master/doc. Just in case you haven't seen it yet, the [OpenJDK Developers? Guide](https://openjdk.org/guide/) also contains a lot of useful information.

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

PR Comment: https://git.openjdk.org/jdk/pull/14809#issuecomment-1629328688

From duke at openjdk.org  Mon Jul 10 18:27:21 2023
From: duke at openjdk.org (Jenny Shivayogi)
Date: Mon, 10 Jul 2023 18:27:21 GMT
Subject: RFR: 8311645: Memory leak in jspawnhelper spawnChild after
 JDK-8307990
In-Reply-To: <9uACtVbScRxHs61JSDL-4nA3b8ol3DUXYyqk8zdj2T0=.b08c4fb3-5000-4658-8f26-b4dfd394eaf0@github.com>
References: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
 <9uACtVbScRxHs61JSDL-4nA3b8ol3DUXYyqk8zdj2T0=.b08c4fb3-5000-4658-8f26-b4dfd394eaf0@github.com>
Message-ID: <Knc36TUEDddcImFRmsDPpYmlhdeQixmLblu4V0RO1kE=.bc2461a7-c71c-47cb-9bdd-e6e4101b672d@github.com>

On Mon, 10 Jul 2023 11:12:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Free-ing 'buf' before two conditional return statements introduced by JDK-8307990
>
> src/java.base/unix/native/libjava/ProcessImpl_md.c line 575:
> 
>> 573:         writeFully(c->childenv[1], buf, bufsize) != bufsize) {
>> 574:         free(buf);
>> 575: 	return -1;
> 
> Same here.

Thanks for that. Will do

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14809#discussion_r1258490292

From shade at openjdk.org  Mon Jul 10 18:31:10 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Jul 2023 18:31:10 GMT
Subject: RFR: 8311645: Memory leak in jspawnhelper spawnChild after
 JDK-8307990
In-Reply-To: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
References: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
Message-ID: <WdmrutHZ0KG_Uh204ezhmJru4cV0DfWEznLrJPYUB0I=.c228b012-08d7-4812-af3f-93810b9c1606@github.com>

On Sat, 8 Jul 2023 02:05:27 GMT, Jenny Shivayogi <duke at openjdk.org> wrote:

> Free-ing 'buf' before two conditional return statements introduced by JDK-8307990

Looks good!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14809#pullrequestreview-1522691783

From duke at openjdk.org  Mon Jul 10 18:31:12 2023
From: duke at openjdk.org (Jenny Shivayogi)
Date: Mon, 10 Jul 2023 18:31:12 GMT
Subject: RFR: 8311645: Memory leak in jspawnhelper spawnChild after
 JDK-8307990
In-Reply-To: <UZy69in42TcIaBIOadNV13QcUksDAPZdXwUEU9R4NcQ=.b8b8596b-9dff-4853-80e3-40cd4cdd83a2@github.com>
References: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
 <UZy69in42TcIaBIOadNV13QcUksDAPZdXwUEU9R4NcQ=.b8b8596b-9dff-4853-80e3-40cd4cdd83a2@github.com>
Message-ID: <dWArXOo5h5udsCY6Qhh_2MWDpN4jxzLyCYpyqr48jHo=.0565f9ac-5eb7-4045-8fd0-444c683689d6@github.com>

On Mon, 10 Jul 2023 16:38:26 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Free-ing 'buf' before two conditional return statements introduced by JDK-8307990
>
> Hi @kspeeyu ,
> 
> Thanks for fixing this issue. The fix looks good except the whitespace issue already mentioned before.
> 
> Notice that we don't use TABs for code indentation in OpenJDK. For the native Hotspot sources (i.e. the ones under `src/hotspot/`) we use an indentation of two spaces whereas for Java code and the native part of the class library (i.e. the native code outside `src/hotspot`) we use four spaces. We don't change the indentation of imported libraries like HarfBuzz or zlib at all.
> 
> You can find more details on the coding style under https://github.com/openjdk/jdk/tree/master/doc. Just in case you haven't seen it yet, the [OpenJDK Developers? Guide](https://openjdk.org/guide/) also contains a lot of useful information.

@simonis, thanks for your response. Fixed the whitespace, will follow the coding style guidelines.

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

PR Comment: https://git.openjdk.org/jdk/pull/14809#issuecomment-1629484604

From prappo at openjdk.org  Mon Jul 10 18:32:25 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 10 Jul 2023 18:32:25 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v2]
In-Reply-To: <-hRTcFsCaDtdobIiQV-dfh1eeAEcT18sk972TG0QRRU=.6aff2ebf-b146-4483-98c7-29b342d674d9@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <pTMvEIx5UPajYBUi4pCgN6CsyzVd6tlJhqcla4D3nV4=.c8aa7c9d-4bbe-482e-8b96-1423950105eb@github.com>
 <-hRTcFsCaDtdobIiQV-dfh1eeAEcT18sk972TG0QRRU=.6aff2ebf-b146-4483-98c7-29b342d674d9@github.com>
Message-ID: <B0bA9g1k5-los70gD6pNPWcAcmmdAH2LvoB4qNM5t2A=.642bc61c-a1ce-42fd-b575-0283e6109db8@github.com>

On Mon, 10 Jul 2023 17:07:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I would be in favor of keeping the current hash behavior for now, even if it is updated in subsequent work. Users have had more than two decades to become, accidentally, reliant on the hash algorithms.

Fair enough; then I suggest we introduce the required utility method (i.e. hashOfRange) in ArraysSupport first.

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

PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1629486588

From simonis at openjdk.org  Mon Jul 10 18:36:13 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 10 Jul 2023 18:36:13 GMT
Subject: RFR: 8311645: Memory leak in jspawnhelper spawnChild after
 JDK-8307990
In-Reply-To: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
References: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
Message-ID: <le9-5OQM2teqNf0Pv-3NyQbreXyJqEsOWOvHBlhi-zk=.65163683-e4af-4ded-9b4d-1d720434ec74@github.com>

On Sat, 8 Jul 2023 02:05:27 GMT, Jenny Shivayogi <duke at openjdk.org> wrote:

> Free-ing 'buf' before two conditional return statements introduced by JDK-8307990

Thanks, looks good now.

I can sponsor your change once you `/integrate`.

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

Marked as reviewed by simonis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14809#pullrequestreview-1522703422

From shade at openjdk.org  Mon Jul 10 18:44:15 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Jul 2023 18:44:15 GMT
Subject: RFR: 8311645: Memory leak in jspawnhelper spawnChild after
 JDK-8307990
In-Reply-To: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
References: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
Message-ID: <ALMfG21D225eXrtFKMpKVJ2TXI7WhuIU7oB6ZzSgIXI=.f19776e1-9a8e-4428-8534-24926c44846c@github.com>

On Sat, 8 Jul 2023 02:05:27 GMT, Jenny Shivayogi <duke at openjdk.org> wrote:

> Free-ing 'buf' before two conditional return statements introduced by JDK-8307990

Hold on a sec, let's make sure the GitHub Actions complete with all green. We can techinically wait after `/integrate` is said for sponsored changeset, but it is cleaner process-wise to wait for GHA all-clear/all-green.

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

PR Comment: https://git.openjdk.org/jdk/pull/14809#issuecomment-1629497462

From simonis at openjdk.org  Mon Jul 10 18:55:15 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 10 Jul 2023 18:55:15 GMT
Subject: RFR: 8311645: Memory leak in jspawnhelper spawnChild after
 JDK-8307990
In-Reply-To: <ALMfG21D225eXrtFKMpKVJ2TXI7WhuIU7oB6ZzSgIXI=.f19776e1-9a8e-4428-8534-24926c44846c@github.com>
References: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
 <ALMfG21D225eXrtFKMpKVJ2TXI7WhuIU7oB6ZzSgIXI=.f19776e1-9a8e-4428-8534-24926c44846c@github.com>
Message-ID: <KseWgT-tyDj0Vu8va068NCKTZHtv-DJ7i7cUmIwHy4o=.f0564d36-f4ac-4ce5-b3e2-97623e98616c@github.com>

On Mon, 10 Jul 2023 18:38:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Hold on a sec, let's make sure the GitHub Actions complete with all green. We can techinically wait after `/integrate` is said for sponsored changeset, but it is cleaner process-wise to wait for GHA all-clear/all-green.

Sure thing :)

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

PR Comment: https://git.openjdk.org/jdk/pull/14809#issuecomment-1629524673

From Bruno.Borges at microsoft.com  Mon Jul 10 19:08:17 2023
From: Bruno.Borges at microsoft.com (Bruno Borges)
Date: Mon, 10 Jul 2023 19:08:17 +0000
Subject: 4-letter patterns in Date Format Style no longer give full text style
Message-ID: <MN2PR21MB14372F87A6D0B81D0831E3AD8530A@MN2PR21MB1437.namprd21.prod.outlook.com>

Hi all,

Was there any change to Date Time Formatter API that made the "EEEE" and the "MMMM" (and other 4-letter patterns) change from Java 8 to 11+ ?

In Java 8, "EEEE" with locale en_US correctly gives the FULL day of week, e.g., "Monday".

In Java 11 and 17 (two I've tested), the same input will give "Mon".

I've also tested for "MMMM" expecting "July" (as in 8), but in 11/17 I get only "Jul".

Here's a test case:

brunoborges/date-formatting-bug at f8f84a1 (github.com)<https://github.com/brunoborges/date-formatting-bug/actions/runs/5511890139/jobs/10048031299>


Thanks,
Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230710/314a4e18/attachment.htm>

From joe.darcy at oracle.com  Mon Jul 10 19:33:35 2023
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 10 Jul 2023 12:33:35 -0700
Subject: 4-letter patterns in Date Format Style no longer give full text
 style
In-Reply-To: <MN2PR21MB14372F87A6D0B81D0831E3AD8530A@MN2PR21MB1437.namprd21.prod.outlook.com>
References: <MN2PR21MB14372F87A6D0B81D0831E3AD8530A@MN2PR21MB1437.namprd21.prod.outlook.com>
Message-ID: <1ca07a7f-4205-7c1e-4ffe-099f9130102f@oracle.com>

Perhaps JEP 252 (https://openjdk.org/jeps/252) as mentioned in the JDK 9 
release notes.


-Joe


On 7/10/2023 12:08 PM, Bruno Borges wrote:
> Hi all,
>
> Was there any change to Date Time Formatter API that made the "EEEE" 
> and the "MMMM" (and other 4-letter patterns) change from Java 8 to 11+ ?
>
> In Java 8, "EEEE" with locale en_US correctly gives the FULL day of 
> week, e.g., "Monday".
>
> In Java 11 and 17 (two I've tested), the same input will give "Mon".
>
> I've also tested for "MMMM" expecting "July" (as in 8), but in 11/17 I 
> get only "Jul".
>
> Here's a test case:
>
> brunoborges/date-formatting-bug at f8f84a1 (github.com) 
> <https://github.com/brunoborges/date-formatting-bug/actions/runs/5511890139/jobs/10048031299>
>
>
> Thanks,
> Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230710/408a4cbe/attachment-0001.htm>

From darcy at openjdk.org  Mon Jul 10 19:35:03 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 10 Jul 2023 19:35:03 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types
In-Reply-To: <P5HqINAyEPsNL6MP02zflunF8HWxM5A2UG57wmLT-LY=.b11fa92d-434f-41c4-8af0-b5e72317cd2d@github.com>
References: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
 <P5HqINAyEPsNL6MP02zflunF8HWxM5A2UG57wmLT-LY=.b11fa92d-434f-41c4-8af0-b5e72317cd2d@github.com>
Message-ID: <jg_yX5ZDCaWm4gKAfTNnkipTjPp1MYPELMRAZWzf9Pg=.775b8781-2439-45d8-bb6c-82228ddba42d@github.com>

On Sat, 1 Jul 2023 01:32:48 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The descriptor string "I", "J", etc possible but not for "int", "long", "byte" etc which are keywords and can't be used as identifiers to name a class.

For users, I think it is reasonable for there to be an API accepting the source-level names ("int", "float", etc.) rather than the JVM-level names.

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

PR Comment: https://git.openjdk.org/jdk/pull/14743#issuecomment-1629604712

From naoto.sato at oracle.com  Mon Jul 10 19:36:10 2023
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 10 Jul 2023 12:36:10 -0700
Subject: 4-letter patterns in Date Format Style no longer give full text
 style
In-Reply-To: <MN2PR21MB14372F87A6D0B81D0831E3AD8530A@MN2PR21MB1437.namprd21.prod.outlook.com>
References: <MN2PR21MB14372F87A6D0B81D0831E3AD8530A@MN2PR21MB1437.namprd21.prod.outlook.com>
Message-ID: <1d6901ec-2dbf-e79a-6ff7-f183849b1360@oracle.com>

Hi,

In your test case,

```
new Locale("en_US");
```

This will fall back to ROOT locale texts with CLDR (default since JDK9) 
where it differs from US English. Probably you may want to `new 
Locale("en", "US)` or preferably use `Locale.US` constant.

Naoto

On 7/10/23 12:08 PM, Bruno Borges wrote:
> Hi all,
> 
> Was there any change to Date Time Formatter API that made the "EEEE" and 
> the "MMMM" (and other 4-letter patterns) change from Java 8 to 11+ ?
> 
> In Java 8, "EEEE" with locale en_US correctly gives the FULL day of 
> week, e.g., "Monday".
> 
> In Java 11 and 17 (two I've tested), the same input will give "Mon".
> 
> I've also tested for "MMMM" expecting "July" (as in 8), but in 11/17 I 
> get only "Jul".
> 
> Here's a test case:
> 
> brunoborges/date-formatting-bug at f8f84a1 (github.com) 
> <https://github.com/brunoborges/date-formatting-bug/actions/runs/5511890139/jobs/10048031299>
> 
> 
> Thanks,
> Bruno

From Bruno.Borges at microsoft.com  Mon Jul 10 19:49:48 2023
From: Bruno.Borges at microsoft.com (Bruno Borges)
Date: Mon, 10 Jul 2023 19:49:48 +0000
Subject: [EXTERNAL] Re: 4-letter patterns in Date Format Style no longer
 give full text style
In-Reply-To: <1d6901ec-2dbf-e79a-6ff7-f183849b1360@oracle.com>
References: <MN2PR21MB14372F87A6D0B81D0831E3AD8530A@MN2PR21MB1437.namprd21.prod.outlook.com>
 <1d6901ec-2dbf-e79a-6ff7-f183849b1360@oracle.com>
Message-ID: <MN2PR21MB1437A8D1F97C06FFE1DA84378530A@MN2PR21MB1437.namprd21.prod.outlook.com>

Given that "en_US" is well known and commonly a user input data, what is then the ideal way to create a Locale object for such string input?

And isn't this the case of a breaking change more than just updating the time database used by default in JDK?

Perhaps in other words, shouldn't Locale(String) constructor attempt to parse the input for the Locale(String, String) constructor so the behavior would have been maintained in accordance to Java 8?

Sent from mobile device.
________________________________
From: Naoto Sato <naoto.sato at oracle.com>
Sent: Monday, July 10, 2023 12:36:10 PM
To: Bruno Borges <Bruno.Borges at microsoft.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: [EXTERNAL] Re: 4-letter patterns in Date Format Style no longer give full text style

Hi,

In your test case,

```
new Locale("en_US");
```

This will fall back to ROOT locale texts with CLDR (default since JDK9)
where it differs from US English. Probably you may want to `new
Locale("en", "US)` or preferably use `Locale.US` constant.

Naoto

On 7/10/23 12:08 PM, Bruno Borges wrote:
> Hi all,
>
> Was there any change to Date Time Formatter API that made the "EEEE" and
> the "MMMM" (and other 4-letter patterns) change from Java 8 to 11+ ?
>
> In Java 8, "EEEE" with locale en_US correctly gives the FULL day of
> week, e.g., "Monday".
>
> In Java 11 and 17 (two I've tested), the same input will give "Mon".
>
> I've also tested for "MMMM" expecting "July" (as in 8), but in 11/17 I
> get only "Jul".
>
> Here's a test case:
>
> brunoborges/date-formatting-bug at f8f84a1 (github.com)
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbrunoborges%2Fdate-formatting-bug%2Factions%2Fruns%2F5511890139%2Fjobs%2F10048031299&data=05%7C01%7CBruno.Borges%40microsoft.com%7C742add55ab3045a3ba2f08db817ced57%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638246145792123639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Pgkr6uURQFaOjO3GL2stbpWprIgKFJTHBkBvu5ZZFNY%3D&reserved=0<https://github.com/brunoborges/date-formatting-bug/actions/runs/5511890139/jobs/10048031299>>
>
>
> Thanks,
> Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230710/6b825ef3/attachment-0001.htm>

From naoto.sato at oracle.com  Mon Jul 10 20:09:12 2023
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 10 Jul 2023 13:09:12 -0700
Subject: [EXTERNAL] Re: 4-letter patterns in Date Format Style no longer
 give full text style
In-Reply-To: <MN2PR21MB1437A8D1F97C06FFE1DA84378530A@MN2PR21MB1437.namprd21.prod.outlook.com>
References: <MN2PR21MB14372F87A6D0B81D0831E3AD8530A@MN2PR21MB1437.namprd21.prod.outlook.com>
 <1d6901ec-2dbf-e79a-6ff7-f183849b1360@oracle.com>
 <MN2PR21MB1437A8D1F97C06FFE1DA84378530A@MN2PR21MB1437.namprd21.prod.outlook.com>
Message-ID: <4bcff591-e5e7-9e2e-2795-5a0b2db8bae0@oracle.com>

On 7/10/23 12:49 PM, Bruno Borges wrote:
> Given that "en_US" is well known and commonly a user input data, what is 
> then the ideal way to create a Locale object for such string input?

Then use Locale.forLanguageTag(). It will accept BCP 47 Langauge tag. 
You will need to replace `_` with `-`.

> 
> And isn't this the case of a breaking change more than just updating the 
> time database used by default in JDK?

You could specify the system property `java.locale.providers` to COMPAT 
to use the JDK8 locales (although this has been deprecated in JDK21). 
However, expecting US resources with Locale("en_US") is incorrect in the 
first place.

> 
> Perhaps in other words, shouldn't Locale(String) constructor attempt to 
> parse the input for the Locale(String, String) constructor so the 
> behavior would have been maintained in accordance to Java 8?

Don't think so. The spec of Locale(String) is clear that it won't do any 
syntactic checks on the input. Otherwise if someone had been creating 
"xxx_yyy" as a language, it will break.

Naoto

> 
> Sent from mobile device.
> ------------------------------------------------------------------------
> *From:* Naoto Sato <naoto.sato at oracle.com>
> *Sent:* Monday, July 10, 2023 12:36:10 PM
> *To:* Bruno Borges <Bruno.Borges at microsoft.com>; 
> core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* [EXTERNAL] Re: 4-letter patterns in Date Format Style no 
> longer give full text style
> Hi,
> 
> In your test case,
> 
> ```
> new Locale("en_US");
> ```
> 
> This will fall back to ROOT locale texts with CLDR (default since JDK9)
> where it differs from US English. Probably you may want to `new
> Locale("en", "US)` or preferably use `Locale.US` constant.
> 
> Naoto
> 
> On 7/10/23 12:08 PM, Bruno Borges wrote:
>> Hi all,
>> 
>> Was there any change to Date Time Formatter API that made the "EEEE" and 
>> the "MMMM" (and other 4-letter patterns) change from Java 8 to 11+ ?
>> 
>> In Java 8, "EEEE" with locale en_US correctly gives the FULL day of 
>> week, e.g., "Monday".
>> 
>> In Java 11 and 17 (two I've tested), the same input will give "Mon".
>> 
>> I've also tested for "MMMM" expecting "July" (as in 8), but in 11/17 I 
>> get only "Jul".
>> 
>> Here's a test case:
>> 
>> brunoborges/date-formatting-bug at f8f84a1 (github.com) 
>> <https://github.com/brunoborges/date-formatting-bug/actions/runs/5511890139/jobs/10048031299 <https://urldefense.com/v3/__https://github.com/brunoborges/date-formatting-bug/actions/runs/5511890139/jobs/10048031299__;!!ACWV5N9M2RV99hQ!JFb8UvDcd0yJhPFTBgCl61gnX6IBN2X7VtRBoKwvcLBkHwCJxL6QM52A6g7Lq960cGc9hgiqdusTFB7YMNgvlIdG$>>
>> 
>> 
>> Thanks,
>> Bruno

From darcy at openjdk.org  Mon Jul 10 20:24:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 10 Jul 2023 20:24:30 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types [v2]
In-Reply-To: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
References: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
Message-ID: <kQkaCbpl40k-iwJn-omUvbcPOCVwnfe3UhGRuTuPezg=.7239465c-af53-4e08-96e5-c44f4b17cd74@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.

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:

 - Update API proposal.
 - Merge branch 'master' into JDK-6361826
 - JDK-6361826: (reflect) provide method for mapping strings to class object for primitive types

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14743/files
  - new: https://git.openjdk.org/jdk/pull/14743/files/24b7aa81..e16b4e90

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

  Stats: 47203 lines in 345 files changed: 3708 ins; 42009 del; 1486 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  Mon Jul 10 20:39:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 10 Jul 2023 20:39:14 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types
In-Reply-To: <ayBNl-W-zwTAW7KXuU8GuwW9ykspvl5EBVRSA3SitpA=.652918b0-d719-4741-9033-955ca7bd7a74@github.com>
References: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
 <ayBNl-W-zwTAW7KXuU8GuwW9ykspvl5EBVRSA3SitpA=.652918b0-d719-4741-9033-955ca7bd7a74@github.com>
Message-ID: <_lr5QkY99wd5sCCCDEXUo_VLAT-GadSgYgYcjP4JodI=.65e54165-24a9-473f-897f-202bbd3dd09d@github.com>

On Fri, 30 Jun 2023 23:46:48 GMT, Chen Liang <liach at openjdk.org> wrote:

> 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.

For discussion purposes, pushed an update where the new method returns null on a non-primitive name.

To approximate normal name lookup is a Java source file (without imports), could be done with code like:

Objects.requireNonNullElse(Class.forPrimitiveName(name), name -> Class.forName(name))

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

PR Comment: https://git.openjdk.org/jdk/pull/14743#issuecomment-1629694729

From sviswanathan at openjdk.org  Mon Jul 10 21:10:16 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 10 Jul 2023 21:10:16 GMT
Subject: RFR: 8311178: JMH tests don't scale well when sharing output
 buffers
In-Reply-To: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
References: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
Message-ID: <h8fgeP34r2Z1upwKLkxBdLGMLoSLdDKI82oZ4dDBcsI=.5c89078c-580f-4f89-a7e0-f752387f68ac@github.com>

On Sat, 1 Jul 2023 07:53:17 GMT, Swati Sharma <duke at openjdk.org> wrote:

> The below benchmark files have scaling issues due to cache contention and leads to poor scaling when run on multiple threads. The patch sets the scope from benchmark level to thread level to fix the issue:
> - org/openjdk/bench/java/io/DataOutputStreamTest.java
> - org/openjdk/bench/java/lang/ArrayCopyObject.java
> - org/openjdk/bench/java/lang/ArrayFiddle.java
> - org/openjdk/bench/java/time/format/DateTimeFormatterBench.java
> - org/openjdk/bench/jdk/incubator/vector/IndexInRangeBenchmark.java
> - org/openjdk/bench/jdk/incubator/vector/MemorySegmentVectorAccess.java
> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedBenchmark.java
> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedIOOBEBenchmark.java
> - org/openjdk/bench/vm/compiler/ArrayFill.java
> - org/openjdk/bench/vm/compiler/IndexVector.java
> 
> Also removing the static scope for variables in org/openjdk/bench/jdk/incubator/vector/VectorFPtoIntCastOperations.java for better scaling.
> 
> Please review and share your feedback.
> 
> Thanks,
> Swati

Looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14746#pullrequestreview-1523049432

From duke at openjdk.org  Mon Jul 10 23:26:13 2023
From: duke at openjdk.org (duke)
Date: Mon, 10 Jul 2023 23:26:13 GMT
Subject: Withdrawn: 8302204: Optimize BigDecimal.divide
In-Reply-To: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
Message-ID: <TvfQJXHca5d2ueMsXge-gtGKIKNQgrCK8bh8pnurbo8=.87e16c86-0b95-47fd-a2d4-12f0efdf18b6@github.com>

On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu <duke at openjdk.org> wrote:

> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the poor performance of BigDecimal.divide under certain circumstance.
> 
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit. According to the flame-graph below, it is StripZeros that spends most of the time of BigDecimal.divide. Hence we propose this patch to optimize stripping zeros.
> ![?? 1](https://user-images.githubusercontent.com/39413832/218062061-53cd0220-776e-4b72-8b9a-6b0f11707986.png)
> 
> Currently, createAndStripZerosToMatchScale() is performed linearly. That is, the target value is parsed from back to front, each time stripping out single ?0?. To optimize, we can adopt the method of binary search. That is, each time we try to strip out ${scale/2} ?0?s. 
> 
> The performance looks good. Therotically, time complexity of our method is O(log n), while the current one is O(n). In practice, benchmarks on Spark3 show that 1/3 less time (102s->68s) is spent on TPC-DS query4. We also runs Jtreg and JCK to check correctness, and it seems fine.
> 
> More about environment: 
> we run Spark3.3.0 on Openjdk11, but it seems jdk version doesn?t have much impact on BigDecimal. Spark cluster consists of a main node and 2 core nodes, each has 4cores, 16g memory and 4x500GB storage.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Tue Jul 11 00:12:14 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 11 Jul 2023 00:12:14 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: <9_clK3b9vL3yNup2ZOxBVnW1F7T-PA7AGf0vJdlL9bg=.9ce05871-8416-4b2f-ad44-93ab0c3a298f@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 any reviewers take a look at this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1629901436

From mcimadamore at openjdk.org  Tue Jul 11 00:39:19 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 11 Jul 2023 00:39:19 GMT
Subject: [jdk21] RFR: 8311593: Minor doc issue in MemorySegment::copy
In-Reply-To: <_VELzPHfPysw4v_wJkp3AGpU6dFT5EC268Q8leUIbAc=.ca6525de-5e00-4085-b11a-bfac4f807c99@github.com>
References: <_VELzPHfPysw4v_wJkp3AGpU6dFT5EC268Q8leUIbAc=.ca6525de-5e00-4085-b11a-bfac4f807c99@github.com>
Message-ID: <1Pw-UopK8cCKBbqMVbaDgFoIasuKf65ZgmycSYXyPaY=.a3cea2c8-bd15-4ded-9fd8-1c4f12240425@github.com>

On Mon, 10 Jul 2023 15:08:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Clean backport of https://git.openjdk.org/jdk/pull/14813

Closing due to issue when creating backport.

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

PR Comment: https://git.openjdk.org/jdk21/pull/107#issuecomment-1629921468

From mcimadamore at openjdk.org  Tue Jul 11 00:39:19 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 11 Jul 2023 00:39:19 GMT
Subject: [jdk21] Withdrawn: 8311593: Minor doc issue in MemorySegment::copy
In-Reply-To: <_VELzPHfPysw4v_wJkp3AGpU6dFT5EC268Q8leUIbAc=.ca6525de-5e00-4085-b11a-bfac4f807c99@github.com>
References: <_VELzPHfPysw4v_wJkp3AGpU6dFT5EC268Q8leUIbAc=.ca6525de-5e00-4085-b11a-bfac4f807c99@github.com>
Message-ID: <lMnpLYmNtaugLcBi2SvAPb_sIZzYBDy1VO_VBq_MLb8=.cae93312-11a6-4930-ba03-cab1d49986c9@github.com>

On Mon, 10 Jul 2023 15:08:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Clean backport of https://git.openjdk.org/jdk/pull/14813

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk21/pull/107

From smarks at openjdk.org  Tue Jul 11 00:44:29 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 11 Jul 2023 00:44:29 GMT
Subject: RFR: 8308694: Clarify reversed() default methods' implementation
 requirements [v4]
In-Reply-To: <vqfR6hqMAWpVLiZziDacV0aRrZJn-AfJB9oMHHbvZlg=.05458d05-ac73-4f42-aa32-971ec12d2db8@github.com>
References: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>
 <vqfR6hqMAWpVLiZziDacV0aRrZJn-AfJB9oMHHbvZlg=.05458d05-ac73-4f42-aa32-971ec12d2db8@github.com>
Message-ID: <LUqvtb9lArL7pwwrk3-iMGMSwPJEynI1GC_4mh6LMbg=.37620287-8c15-4152-be47-147d40dfaf77@github.com>

On Fri, 7 Jul 2023 22:55:12 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 two additional commits since the last revision:
> 
>  - Update docs for reversed() method of List, SortedMap, SortedSet.
>  - Slight rewording of the original paragraph in Deque.

CSR [JDK-8311845](https://bugs.openjdk.org/browse/JDK-8311845) ready for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/14504#issuecomment-1629924405

From mcimadamore at openjdk.org  Tue Jul 11 00:47:32 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 11 Jul 2023 00:47:32 GMT
Subject: [jdk21] RFR: 8311593: Minor doc issue in MemorySegment::copy
Message-ID: <0T-uF2XS0HX5safbT6DRyTd3M_VJ5bpIpY92ByNa3Go=.ba5d0b84-57c7-40c2-ad4c-3f9bb77cfd60@github.com>

Clean backport of https://git.openjdk.org/jdk/pull/14813
(sorry for filing another one, I realized there was an issue with the JBS issues pointing the wrong way)

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

Commit messages:
 - Backport 6569b252b9e61e3eed77039c483529154feffbba

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

PR: https://git.openjdk.org/jdk21/pull/109

From alanb at openjdk.org  Tue Jul 11 05:43:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Jul 2023 05:43:10 GMT
Subject: RFR: 8311645: Memory leak in jspawnhelper spawnChild after
 JDK-8307990
In-Reply-To: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
References: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
Message-ID: <7vNEhefGaNjvUdBcfDssbO4Uw79lZHNkHvrWUQJeQTc=.15ffc06b-d187-44a2-a2ef-b9eff29ac4bc@github.com>

On Sat, 8 Jul 2023 02:05:27 GMT, Jenny Shivayogi <duke at openjdk.org> wrote:

> Free-ing 'buf' before two conditional return statements introduced by JDK-8307990

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14809#pullrequestreview-1523459114

From Alan.Bateman at oracle.com  Tue Jul 11 06:51:06 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 11 Jul 2023 07:51:06 +0100
Subject: [EXTERNAL] Re: 4-letter patterns in Date Format Style no longer
 give full text style
In-Reply-To: <4bcff591-e5e7-9e2e-2795-5a0b2db8bae0@oracle.com>
References: <MN2PR21MB14372F87A6D0B81D0831E3AD8530A@MN2PR21MB1437.namprd21.prod.outlook.com>
 <1d6901ec-2dbf-e79a-6ff7-f183849b1360@oracle.com>
 <MN2PR21MB1437A8D1F97C06FFE1DA84378530A@MN2PR21MB1437.namprd21.prod.outlook.com>
 <4bcff591-e5e7-9e2e-2795-5a0b2db8bae0@oracle.com>
Message-ID: <0464a56c-9d6d-908f-37bf-e83ddc02af26@oracle.com>



On 10/07/2023 21:09, Naoto Sato wrote:
> :
>
>>
>> And isn't this the case of a breaking change more than just updating 
>> the time database used by default in JDK?
>
> You could specify the system property `java.locale.providers` to 
> COMPAT to use the JDK8 locales (although this has been deprecated in 
> JDK21). However, expecting US resources with Locale("en_US") is 
> incorrect in the first place.

Just to add to Naoto's comments.

JDK 8 was the first release to include CLDR locale data (JEP 127). JDK 8 
continued to use the legacy JRE locale data by default but the system 
property could be use to try out CLDR data in advance of the switch to 
using it by default in JDK 9 (JEP 252). From JDK 9 to this day, the 
system property can be used to switch back to the JRE lcoale data 
although this locale data hasn't been maintained for several years.

-Alan

From mli at openjdk.org  Tue Jul 11 06:58:02 2023
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 11 Jul 2023 06:58:02 GMT
Subject: RFR: 8311178: JMH tests don't scale well when sharing output
 buffers
In-Reply-To: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
References: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
Message-ID: <WoHUzH3aN6s7LWVNArNcCpC-yP26p8cuLq5oHCPidGA=.297dfdea-79db-4d3a-bd73-4a2edf02f0da@github.com>

On Sat, 1 Jul 2023 07:53:17 GMT, Swati Sharma <duke at openjdk.org> wrote:

> The below benchmark files have scaling issues due to cache contention and leads to poor scaling when run on multiple threads. The patch sets the scope from benchmark level to thread level to fix the issue:
> - org/openjdk/bench/java/io/DataOutputStreamTest.java
> - org/openjdk/bench/java/lang/ArrayCopyObject.java
> - org/openjdk/bench/java/lang/ArrayFiddle.java
> - org/openjdk/bench/java/time/format/DateTimeFormatterBench.java
> - org/openjdk/bench/jdk/incubator/vector/IndexInRangeBenchmark.java
> - org/openjdk/bench/jdk/incubator/vector/MemorySegmentVectorAccess.java
> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedBenchmark.java
> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedIOOBEBenchmark.java
> - org/openjdk/bench/vm/compiler/ArrayFill.java
> - org/openjdk/bench/vm/compiler/IndexVector.java
> 
> Also removing the static scope for variables in org/openjdk/bench/jdk/incubator/vector/VectorFPtoIntCastOperations.java for better scaling.
> 
> Please review and share your feedback.
> 
> Thanks,
> Swati

Marked as reviewed by mli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14746#pullrequestreview-1523547091

From mli at openjdk.org  Tue Jul 11 06:58:05 2023
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 11 Jul 2023 06:58:05 GMT
Subject: RFR: 8311178: JMH tests don't scale well when sharing output
 buffers
In-Reply-To: <gLLj2ES1jEOgVa8lBFi-GZvMJyv3s5-4RV8cbZvy1GA=.c19b32c4-d2d5-4642-9633-649c6ad536bd@github.com>
References: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
 <NAqYeoBo6lmu3_A16aV3Q8aCu5oMK1u7rG4UYUTWZEI=.f7b4bd90-95a5-4714-8604-f32f21adf0cf@github.com>
 <W9KinS6D_i4g8gUr799ayeLSW8opwLlfzwlb3cEdt80=.9a2acdfc-8a86-44df-8218-5424fb28d3d8@github.com>
 <gLLj2ES1jEOgVa8lBFi-GZvMJyv3s5-4RV8cbZvy1GA=.c19b32c4-d2d5-4642-9633-649c6ad536bd@github.com>
Message-ID: <G66WVAxbxy94bbnIDMdqZSyFcZUbBUpDBdI_u1Rvpb4=.e9be8719-4d83-4401-bf2a-5a635c7295a1@github.com>

On Mon, 10 Jul 2023 08:17:59 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> @Hamlin-Li 
>> The PR is fully correct.
>> Don't forget, every Java instance method has a specific argument which called "this".  That is why @State annotation is working.
>
> @kuksenko @swati-sha Thanks for explanation. I can understand what you said.
> But I'm still not quite sure, as I remember jmh does some code manipulation or instrumentation at source code (or bytecode level?), so the jmh test code you write or see might not be the exact code to be executed at runtime.
> It's better to be reviewed further by some one more familiar with jmh, or could you add some data comparing the performance difference, so we can tell it easily?

> @Hamlin-Li I am one of JMH's authors. I know how it works. There is no need for tests.

@kuksenko Thanks for the confirmation.
Then the benchmark modification looks good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/14746#issuecomment-1630252431

From shade at openjdk.org  Tue Jul 11 07:41:11 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Jul 2023 07:41:11 GMT
Subject: RFR: 8311645: Memory leak in jspawnhelper spawnChild after
 JDK-8307990
In-Reply-To: <dWArXOo5h5udsCY6Qhh_2MWDpN4jxzLyCYpyqr48jHo=.0565f9ac-5eb7-4045-8fd0-444c683689d6@github.com>
References: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
 <UZy69in42TcIaBIOadNV13QcUksDAPZdXwUEU9R4NcQ=.b8b8596b-9dff-4853-80e3-40cd4cdd83a2@github.com>
 <dWArXOo5h5udsCY6Qhh_2MWDpN4jxzLyCYpyqr48jHo=.0565f9ac-5eb7-4045-8fd0-444c683689d6@github.com>
Message-ID: <0EEaDfm8lEHyme0P8O9mebe4Zk9kRrcxYEiUbnyAOmE=.41f9a65e-061f-4195-ba3f-ea42a8c80fb3@github.com>

On Mon, 10 Jul 2023 18:28:08 GMT, Jenny Shivayogi <duke at openjdk.org> wrote:

>> Hi @kspeeyu ,
>> 
>> Thanks for fixing this issue. The fix looks good except the whitespace issue already mentioned before.
>> 
>> Notice that we don't use TABs for code indentation in OpenJDK. For the native Hotspot sources (i.e. the ones under `src/hotspot/`) we use an indentation of two spaces whereas for Java code and the native part of the class library (i.e. the native code outside `src/hotspot`) we use four spaces. We don't change the indentation of imported libraries like HarfBuzz or zlib at all.
>> 
>> You can find more details on the coding style under https://github.com/openjdk/jdk/tree/master/doc. Just in case you haven't seen it yet, the [OpenJDK Developers? Guide](https://openjdk.org/guide/) also contains a lot of useful information.
>
> @simonis, thanks for your response. Fixed the whitespace, will follow the coding style guidelines.

GHA reports one test failure, but it looks infrastructural. Feel free to say `/integrate`, @kspeeyu.

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

PR Comment: https://git.openjdk.org/jdk/pull/14809#issuecomment-1630309804

From duke at openjdk.org  Tue Jul 11 08:07:13 2023
From: duke at openjdk.org (Swati Sharma)
Date: Tue, 11 Jul 2023 08:07:13 GMT
Subject: RFR: 8311178: JMH tests don't scale well when sharing output
 buffers
In-Reply-To: <Ult5GXO3qfcaygqPQTLWzu87heWds_Va3KE7cVSpaw8=.9e7e84a5-44f8-49e7-8a02-2244d14eddce@github.com>
References: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
 <Ult5GXO3qfcaygqPQTLWzu87heWds_Va3KE7cVSpaw8=.9e7e84a5-44f8-49e7-8a02-2244d14eddce@github.com>
Message-ID: <PzHtavGR1B6evP_INyTGVvms3cnCZLux6I5yF0x4_5s=.ea0010a5-b52e-4d39-93e3-ad98689de06a@github.com>

On Mon, 10 Jul 2023 16:07:44 GMT, John Jiang <jjiang at openjdk.org> wrote:

> Not review this PR, but just raise a question. Should a JMH test, at least in JDK repo, always uses `@State(Scope.Thread)`, even though it uses only one thread?
> 
> I just looked through those JMH tests, and found all of them, like the bellows, don't specify the number of threads via `@Threads`.
> 
> ```
> org/openjdk/bench/java/io/DataOutputStreamTest.java
> org/openjdk/bench/java/lang/ArrayCopyObject.java
> ```
> 
> I suppose the default number of threads is 1. Maybe the default value will be overridden via the commands when running these JMH tests in bulk (?)

Not always but state should be set to Thread level when the class variables are shared by multiple threads, also the variable scope should be set to non static. While running these benchmarks in multithreaded way, observed scaling issues as variables are shared but scope is set to benchmark level.

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

PR Comment: https://git.openjdk.org/jdk/pull/14746#issuecomment-1630347091

From duke at openjdk.org  Tue Jul 11 08:11:03 2023
From: duke at openjdk.org (Swati Sharma)
Date: Tue, 11 Jul 2023 08:11:03 GMT
Subject: RFR: 8311178: JMH tests don't scale well when sharing output
 buffers
In-Reply-To: <zBS1EIi8Z8kz5Q_eBL4XopFXbBu-vSZzlN9MbxYEQ8s=.d8f65f69-5ed8-4584-b8df-b1fcb124a25c@github.com>
References: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
 <zBS1EIi8Z8kz5Q_eBL4XopFXbBu-vSZzlN9MbxYEQ8s=.d8f65f69-5ed8-4584-b8df-b1fcb124a25c@github.com>
Message-ID: <VdVuxKiT2yBPToMcF_byxpTsEIXfLTz2jLGJnd3jf4A=.2685acfb-a990-4464-a0aa-eed22a682a2a@github.com>

On Wed, 5 Jul 2023 14:39:08 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

>> The below benchmark files have scaling issues due to cache contention and leads to poor scaling when run on multiple threads. The patch sets the scope from benchmark level to thread level to fix the issue:
>> - org/openjdk/bench/java/io/DataOutputStreamTest.java
>> - org/openjdk/bench/java/lang/ArrayCopyObject.java
>> - org/openjdk/bench/java/lang/ArrayFiddle.java
>> - org/openjdk/bench/java/time/format/DateTimeFormatterBench.java
>> - org/openjdk/bench/jdk/incubator/vector/IndexInRangeBenchmark.java
>> - org/openjdk/bench/jdk/incubator/vector/MemorySegmentVectorAccess.java
>> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedBenchmark.java
>> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedIOOBEBenchmark.java
>> - org/openjdk/bench/vm/compiler/ArrayFill.java
>> - org/openjdk/bench/vm/compiler/IndexVector.java
>> 
>> Also removing the static scope for variables in org/openjdk/bench/jdk/incubator/vector/VectorFPtoIntCastOperations.java for better scaling.
>> 
>> Please review and share your feedback.
>> 
>> Thanks,
>> Swati
>
> LGTM.
> Eric

Thanks all for reviewing this ! @ericcaspole , @sviswa7 , @Hamlin-Li

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

PR Comment: https://git.openjdk.org/jdk/pull/14746#issuecomment-1630351831

From alanb at openjdk.org  Tue Jul 11 08:18:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Jul 2023 08:18:13 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1 [v2]
In-Reply-To: <h9PlDFUdKbSjiQtJKLnu_FGLv0vdkrvs-b81pnqIIEU=.34443364-2a9a-4d26-a446-7f6a2e447e99@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
 <h9PlDFUdKbSjiQtJKLnu_FGLv0vdkrvs-b81pnqIIEU=.34443364-2a9a-4d26-a446-7f6a2e447e99@github.com>
Message-ID: <G0833AaelMZWJYsCjigNTG8aAmCBhOLRjwwOJcXwzq8=.de9e9930-c262-4569-b54a-f9477181f15a@github.com>

On Fri, 7 Jul 2023 15:44:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no guarantee as to how the underlying output stream actually writes the bytes provided to it.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8155902: Delete "merely"

In passing, we should probably look into the inconsistency in the synchronization. The write methods are synchronized, the writeXXX methods and other methods are not. The class specified that it is not safe for use by concurrent threads without appropriate synchronization.

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

PR Comment: https://git.openjdk.org/jdk/pull/14791#issuecomment-1630363468

From alanb at openjdk.org  Tue Jul 11 08:34:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Jul 2023 08:34:18 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1 [v2]
In-Reply-To: <h9PlDFUdKbSjiQtJKLnu_FGLv0vdkrvs-b81pnqIIEU=.34443364-2a9a-4d26-a446-7f6a2e447e99@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
 <h9PlDFUdKbSjiQtJKLnu_FGLv0vdkrvs-b81pnqIIEU=.34443364-2a9a-4d26-a446-7f6a2e447e99@github.com>
Message-ID: <C5ihIpG-q92tbCSc-LG0XIQ3GsIUZBXf74eKrr2qcDA=.c6ff2d45-bc50-408d-8cd7-a41d78f8a77b@github.com>

On Fri, 7 Jul 2023 15:44:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no guarantee as to how the underlying output stream actually writes the bytes provided to it.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8155902: Delete "merely"

src/java.base/share/classes/java/io/DataOutputStream.java line 44:

> 42:  * the underlying output stream, hence there is no guarantee as to
> 43:  * the details of how the bytes are written.
> 44:  *

It might be better to expand the first paragraph of the class description to make it clearer that it wraps another output stream. Writing to the DOS will write bytes to the underlying output stream. That would give you the setup needed to explain that writing data that is more than one byte may result in several writes to the underlying output stream.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14791#discussion_r1259392223

From liach at openjdk.org  Tue Jul 11 12:04:33 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Jul 2023 12:04:33 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v22]
In-Reply-To: <DWF3tGxV-nUwRY-ukLmeSdjWNzpfO-I74mOfMz5Rprk=.16f92ff8-8d19-4f03-a9ed-df3e59a2e623@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <cKUEte7iDFjGSjnpWp4Otw-jr49x33S9JARZkrvWng8=.cfdd4210-9319-4f3b-b731-de2befc00eb2@github.com>
 <DWF3tGxV-nUwRY-ukLmeSdjWNzpfO-I74mOfMz5Rprk=.16f92ff8-8d19-4f03-a9ed-df3e59a2e623@github.com>
Message-ID: <BKm139fKhW4yBCbdovRNWiYh1itV1hVIrPGDjNqexVQ=.9155d1bd-b93c-429a-bdba-a08ac915e4a2@github.com>

On Mon, 10 Jul 2023 18:14:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> If more than one target method handles are used, the extra classes will pollute the same type profiles.

Is this the case? I thought the profile pollution happens with the impl class holding MH in instance field approach, while JIT handles split-class much nicer.

In a second look, I find that the old note was in fact, already covered in the API specification; I will include the "multiple class over time" into this rephrase.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1259615068

From jvernee at openjdk.org  Tue Jul 11 12:17:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 11 Jul 2023 12:17:21 GMT
Subject: [jdk21] RFR: 8311593: Minor doc issue in MemorySegment::copy
In-Reply-To: <0T-uF2XS0HX5safbT6DRyTd3M_VJ5bpIpY92ByNa3Go=.ba5d0b84-57c7-40c2-ad4c-3f9bb77cfd60@github.com>
References: <0T-uF2XS0HX5safbT6DRyTd3M_VJ5bpIpY92ByNa3Go=.ba5d0b84-57c7-40c2-ad4c-3f9bb77cfd60@github.com>
Message-ID: <CWR7OdsBxV9ZyxmF2JQhAIFJRn7ZP2qtQBbIobGewV0=.20cc6dae-a42e-4e4d-ad81-201787403e79@github.com>

On Tue, 11 Jul 2023 00:40:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Clean backport of https://git.openjdk.org/jdk/pull/14813
> (sorry for filing another one, I realized there was an issue with the JBS issues pointing the wrong way)

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/109#pullrequestreview-1524127489

From liach at openjdk.org  Tue Jul 11 13:09:00 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Jul 2023 13:09:00 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v23]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <vsLZylD7kPvugXPDHmBSy1bBsH2JZSgNJZbz7fvfiWs=.4a62a498-1c1b-4d8d-aa5f-022a8051720b@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 50 commits:

 - Clean up impl comment, reorganize tests; weak ref broken
 - Merge branch 'master' into explore/mhp-iface
 - Fix broken null behaviors
 - Merge branch 'master' into explore/mhp-iface
 - Merge branch 'mh-proxies' of https://github.com/mlchung/jdk into explore/mhp-iface
 - store a WeakReference holder in the class value
 - Merge branch 'master' into explore/mhp-iface
 - stage
   
   Signed-off-by: liach <liach at users.noreply.github.com>
 - Review comments
 - Code cleanup, thanks mandy!
 - ... and 40 more: https://git.openjdk.org/jdk/compare/4b1403d0...3d67ed06

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

Changes: https://git.openjdk.org/jdk/pull/13197/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=22
  Stats: 1749 lines in 16 files changed: 1349 ins; 311 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 duke at openjdk.org  Tue Jul 11 13:15:35 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 11 Jul 2023 13:15:35 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v22]
In-Reply-To: <DWF3tGxV-nUwRY-ukLmeSdjWNzpfO-I74mOfMz5Rprk=.16f92ff8-8d19-4f03-a9ed-df3e59a2e623@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <cKUEte7iDFjGSjnpWp4Otw-jr49x33S9JARZkrvWng8=.cfdd4210-9319-4f3b-b731-de2befc00eb2@github.com>
 <DWF3tGxV-nUwRY-ukLmeSdjWNzpfO-I74mOfMz5Rprk=.16f92ff8-8d19-4f03-a9ed-df3e59a2e623@github.com>
Message-ID: <1nE5mEZ63wSqLPMnRoLaStmBAjMByprXP_7jce15mlc=.aa6f3b6e-d4b1-4e15-a422-2828f86f8895@github.com>

On Fri, 7 Jul 2023 17:15:38 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang 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:
>> 
>>   Fix broken null behaviors
>
> test/jdk/java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java line 54:
> 
>> 52:         } catch (Throwable ex) {
>> 53:             throw new AssertionError("Test failed for " + cl, ex);
>> 54:         }
> 
> Nit: formatting - try block inside the for-loop
> Suggestion:
> 
>         for (Class<?> cl : List.of(Runnable.class, Client.class, NestedInterface.class)) {
>             try {
>                 Object o = MethodHandleProxies.asInterfaceInstance(cl, originalMh);
>                 testWrapperInstanceTarget(o, originalMh);
>                 testWrapperInstanceType(o, cl);
>             } catch (Throwable ex) {
>                 throw new AssertionError("Test failed for " + cl, ex);
>             }
>         }

This?has the?downside that?any?error will?not?run any?later?tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1259716091

From liach at openjdk.org  Tue Jul 11 13:19:25 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Jul 2023 13:19:25 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v22]
In-Reply-To: <D8tlg83uRxvtwj52VxhBEjPRej-IPYaMW_tqZWuNnVQ=.83986c56-5be3-4b63-9729-f6cf96064a66@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <cKUEte7iDFjGSjnpWp4Otw-jr49x33S9JARZkrvWng8=.cfdd4210-9319-4f3b-b731-de2befc00eb2@github.com>
 <D8tlg83uRxvtwj52VxhBEjPRej-IPYaMW_tqZWuNnVQ=.83986c56-5be3-4b63-9729-f6cf96064a66@github.com>
Message-ID: <LjrTTWOLhxHhPHW0H4_SqOaws6oLWwclqL3W0MHvIrg=.47b3298c-2d9f-483b-a54a-f0c8388dab60@github.com>

On Fri, 7 Jul 2023 16:31:47 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang 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:
>> 
>>   Fix broken null behaviors
>
> FYI.   You can do git revert instead of force push.

@mlchung Thank you for the new round of review.
I have split the large test into 3 parts, testing general contracts, against different types of interfaces, and implementation-related tests. The old MethodHandleProxies test, which tests against different types of interfaces, is merged into the interface one. The module one, being an implementation detail, is merged into the implementation test.

I have a few problems that need help:
1. I think the type profile pollution only happens with the instance-field approach, as I recall different instance fields' MHs pollute profiling. The comment need to be corrected if I'm right.
2. The weak reference test in the impl-related test breaks in weird ways:
   1. https://github.com/openjdk/jdk/pull/13197/files#diff-effc9e10eca79d537b6321e9d72b8bbcf0fc6c1c2ac9d13f3524951bc54d48fdR196
      When this line is removed, the next call to `asInterfaceInstance` will return a wrapper with a new implementation class, even if the old instance is still in a local variable; as in jshell:

      ```java
      import java.lang.invoke.*;
      var mh = MethodHandles.zero(void.class);
      var c1 = MethodHandleProxies.asInterfaceInstance(Runnable.class, mh);
      System.gc();
      var c2 = MethodHandleProxies.asInterfaceInstance(Runnable.class, mh);
      c1.getClass() == c2.getClass()
      ```
      The last `==` line shows that `c1` and `c2` are both reachable, so there are 2 coexistent implementation classes somehow; not sure how the original one is lost in gc.
   2. https://github.com/openjdk/jdk/pull/13197/files#diff-effc9e10eca79d537b6321e9d72b8bbcf0fc6c1c2ac9d13f3524951bc54d48fdR202
       The MHP implementation class weak reference is not cleared by gc, even though the wrapper is no longer reachable.

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

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

From jvernee at openjdk.org  Tue Jul 11 13:43:26 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 11 Jul 2023 13:43:26 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v22]
In-Reply-To: <LjrTTWOLhxHhPHW0H4_SqOaws6oLWwclqL3W0MHvIrg=.47b3298c-2d9f-483b-a54a-f0c8388dab60@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <cKUEte7iDFjGSjnpWp4Otw-jr49x33S9JARZkrvWng8=.cfdd4210-9319-4f3b-b731-de2befc00eb2@github.com>
 <D8tlg83uRxvtwj52VxhBEjPRej-IPYaMW_tqZWuNnVQ=.83986c56-5be3-4b63-9729-f6cf96064a66@github.com>
 <LjrTTWOLhxHhPHW0H4_SqOaws6oLWwclqL3W0MHvIrg=.47b3298c-2d9f-483b-a54a-f0c8388dab60@github.com>
Message-ID: <iIDQm1WSc_Ya_rQo36u6KUgNQQox9ociH7iWfDQzPZw=.b4f82817-3b25-471f-ba1f-98f1b51c8ff4@github.com>

On Tue, 11 Jul 2023 13:16:21 GMT, Chen Liang <liach at openjdk.org> wrote:

> 1. I think the type profile pollution only happens with the instance-field approach, as I recall different instance fields' MHs pollute profiling. The comment need to be corrected if I'm right.

What happens is not really 'profile pollution'. The issue is that C2 can not inline through non-constant method handles. So we always get an indirect call through the MethodHandle's [invokeBasic stub](https://github.com/openjdk/jdk/blob/a1cfc9695405fe517fae1b9f760ae42b85f66be9/src/hotspot/cpu/x86/methodHandles_x86.cpp#L165).

> When this line is removed, the next call to asInterfaceInstance will return a wrapper with a new implementation class, even if the old instance is still in a local variable.

The WeakReference inside the implementation points to the `Lookup` object. I think this Lookup goes out of scope after `asInterfaceInstance` returns, right? (it's not saved inside the returned instance or class). So, it would be immediately eligible for GC.

I think a SoftReference would work better for the cache (which the GC clears less eagerly). Or the returned interface instance could save a reference to the Lookup object in order to keep it reachable.

> The MHP implementation class weak reference is not cleared by gc, even though the wrapper is no longer reachable.

Note that when running in interpreted mode (which is likely for these tests), a variable is 'alive' from the perspective of the GC until the method ends. i.e. the `{ ... }` used in the test does nothing WRT GC. You would have to explicitly make `c1` `null` for the class to be unreachable.

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

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

From rriggs at openjdk.org  Tue Jul 11 14:06:05 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Jul 2023 14:06:05 GMT
Subject: RFR: 8311645: Memory leak in jspawnhelper spawnChild after
 JDK-8307990
In-Reply-To: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
References: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
Message-ID: <_C45oE6q0mUhwCjzwrQWjFVdOmoQ_0iEurbYPxlmuJc=.7345af12-64df-410e-88a2-32162494f777@github.com>

On Sat, 8 Jul 2023 02:05:27 GMT, Jenny Shivayogi <duke at openjdk.org> wrote:

> Free-ing 'buf' before two conditional return statements introduced by JDK-8307990

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14809#pullrequestreview-1524357337

From liach at openjdk.org  Tue Jul 11 14:55:25 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Jul 2023 14:55:25 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v19]
In-Reply-To: <jm_AJ5zALuQSbilifFRNapuZczcMuCy0g9lPwzsBgws=.1d43a13c-9354-4afd-a444-5c759e2db804@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <jm_AJ5zALuQSbilifFRNapuZczcMuCy0g9lPwzsBgws=.1d43a13c-9354-4afd-a444-5c759e2db804@github.com>
Message-ID: <1RNnoAR3k4MOCJRcivE7l_ceb0vsHelzgXhpLu33yEQ=.07f193c6-8ce4-49eb-b68e-cc34d30c8536@github.com>

On Thu, 29 Jun 2023 01:55: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 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

The CSR has been approved and I have drafted a release note at https://bugs.openjdk.org/browse/JDK-8311878 following the instructions on the openjdk guide. @psandoz @mlchung Can you please review this release note since you've reviewed this patch?

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

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

From asotona at openjdk.org  Tue Jul 11 15:09:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 11 Jul 2023 15:09:48 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v9]
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: <4NCOczzNv-G14FVzqmO60GagflxNSI1RIv8_Yt7nXrI=.57cfc798-0e28-4ee9-be99-4df12ed3c9f8@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:

  fixed code printing and ConstantPoolException reporting indoex

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11411/files
  - new: https://git.openjdk.org/jdk/pull/11411/files/834de482..eb9d864f

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

  Stats: 78 lines in 2 files changed: 5 ins; 1 del; 72 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  Tue Jul 11 15:15:51 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Jul 2023 15:15:51 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v24]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <fS-1n133eU3Kt5nczYHlu86Z0JouqHhvLuCU05JKS3k=.5680a0e3-44a2-4078-adfc-651d8710a33e@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 incrementally with one additional commit since the last revision:

  Fix the lazy test, thanks Jorn Vernee!

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/3d67ed06..c7b852d9

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

  Stats: 26 lines in 2 files changed: 6 ins; 1 del; 19 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  Tue Jul 11 15:16:35 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Jul 2023 15:16:35 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v22]
In-Reply-To: <iIDQm1WSc_Ya_rQo36u6KUgNQQox9ociH7iWfDQzPZw=.b4f82817-3b25-471f-ba1f-98f1b51c8ff4@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <cKUEte7iDFjGSjnpWp4Otw-jr49x33S9JARZkrvWng8=.cfdd4210-9319-4f3b-b731-de2befc00eb2@github.com>
 <D8tlg83uRxvtwj52VxhBEjPRej-IPYaMW_tqZWuNnVQ=.83986c56-5be3-4b63-9729-f6cf96064a66@github.com>
 <LjrTTWOLhxHhPHW0H4_SqOaws6oLWwclqL3W0MHvIrg=.47b3298c-2d9f-483b-a54a-f0c8388dab60@github.com>
 <iIDQm1WSc_Ya_rQo36u6KUgNQQox9ociH7iWfDQzPZw=.b4f82817-3b25-471f-ba1f-98f1b51c8ff4@github.com>
Message-ID: <VAybno3zx5jZ3EjV0iZci0AP3jFwRqRuEB2RlDSsHQM=.4c298b19-db9d-49f7-9e70-efa270802466@github.com>

On Tue, 11 Jul 2023 13:40:27 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @mlchung Thank you for the new round of review.
>> I have split the large test into 3 parts, testing general contracts, against different types of interfaces, and implementation-related tests. The old MethodHandleProxies test, which tests against different types of interfaces, is merged into the interface one. The module one, being an implementation detail, is merged into the implementation test.
>> 
>> I have a few problems that need help:
>> 1. I think the type profile pollution only happens with the instance-field approach, as I recall different instance fields' MHs pollute profiling. The comment need to be corrected if I'm right.
>> 2. The weak reference test in the impl-related test breaks in weird ways:
>>    1. https://github.com/openjdk/jdk/pull/13197/files#diff-effc9e10eca79d537b6321e9d72b8bbcf0fc6c1c2ac9d13f3524951bc54d48fdR196
>>       When this line is removed, the next call to `asInterfaceInstance` will return a wrapper with a new implementation class, even if the old instance is still in a local variable; as in jshell:
>> 
>>       ```java
>>       import java.lang.invoke.*;
>>       var mh = MethodHandles.zero(void.class);
>>       var c1 = MethodHandleProxies.asInterfaceInstance(Runnable.class, mh);
>>       System.gc();
>>       var c2 = MethodHandleProxies.asInterfaceInstance(Runnable.class, mh);
>>       c1.getClass() == c2.getClass()
>>       ```
>>       The last `==` line shows that `c1` and `c2` are both reachable, so there are 2 coexistent implementation classes somehow; not sure how the original one is lost in gc. Without gc, the 2 wrappers have the same implementation class.
>>    2. https://github.com/openjdk/jdk/pull/13197/files#diff-effc9e10eca79d537b6321e9d72b8bbcf0fc6c1c2ac9d13f3524951bc54d48fdR202
>>        The MHP implementation class weak reference is not cleared by gc, even though the wrapper is no longer reachable.
>
>> 1. I think the type profile pollution only happens with the instance-field approach, as I recall different instance fields' MHs pollute profiling. The comment need to be corrected if I'm right.
> 
> What happens is not really 'profile pollution'. The issue is that C2 can not inline through non-constant method handles. So we always get an indirect call through the MethodHandle's [invokeBasic stub](https://github.com/openjdk/jdk/blob/a1cfc9695405fe517fae1b9f760ae42b85f66be9/src/hotspot/cpu/x86/methodHandles_x86.cpp#L165).
> 
> EDIT: Sorry, I should have read Mandy's suggestion more closely. The issue when we generate many classes (one per method handle), is that when we call the resulting interface instances at the same call site, the different implementation classes will cause profile pollution.
> 
>> When this line is removed, the next call to asInterfaceInstance will return a wrapper with a new implementation class, even if the old instance is still in a local variable.
> 
> The WeakReference inside the implementation points to the `Lookup` object. I think this Lookup goes out of scope after `asInterfaceInstance` returns, right? (it's not saved inside the returned instance or class). So, it would be immediately eligible for GC.
> 
> I think a SoftReference would work better for the cache (which the GC clears less eagerly). Or the returned interface instance could save a reference to the Lookup object in order to keep it reachable.
> 
>> The MHP implementation class weak reference is not cleared by gc, even though the wrapper is no longer reachable.
> 
> Note that when running in interpreted mode (which is likely for these tests), a variable is 'alive' from the perspective of the GC until the method ends. i.e. the `{ ... }` used in the test does nothing WRT GC. You would have to explicitly make `c1` `null` for the class to be unreachable.

Thank you so much @JornVernee: The WeakReference should point to the impl class. The Lookup is a cheap wrapper, so I changed it to be created each time instead. The test comes back green on my device with your suggestions.

I think this patch is stable now; feel free to review again, especially that I've rearranged the tests.

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

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

From simonis at openjdk.org  Tue Jul 11 15:48:13 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 11 Jul 2023 15:48:13 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() can throw if invoked
 reflectively [v2]
In-Reply-To: <yS8kuYQ-iQzTnhuxiiS7-ifGAlxP_6znBKmKMftKL20=.e71006f6-a38c-4340-9afa-1057e8e5b638@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
 <yS8kuYQ-iQzTnhuxiiS7-ifGAlxP_6znBKmKMftKL20=.e71006f6-a38c-4340-9afa-1057e8e5b638@github.com>
Message-ID: <_PFAIwFztDmWVKgVFpZcYqFjarJHum0O5-qbQbuhFDY=.3f907681-5434-4875-aac2-838ffc72ec00@github.com>

On Wed, 5 Jul 2023 17:25:24 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> As the included jtreg test demonstrates, `StackWalker.getCallerClass()` can throw an `UnsupportedOperationException` if called reflectively. Currently this only happens if we invoke `StackWalker.getCallerClass()` recursively reflectively, but this issue will become more prominent once we fix [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447). The gory details follow below:
>> 
>> The protocol between the Java API and the JVM for `StackWalker.getCallerClass()/walk()` is as follows:
>> - On the Java side, `StackWalker` calls into `StackStreamFactory` for the real work.
>> - For `StackWalker.getCallerClass()` `StackStreamFactory` basically creates a `Class[]` which will be passed down and filled in the JVM. For `StackWalker.walk()` it will normally be a `StackFrameInfo[]` (or a `LiveStackFrameInfo[]` if the internal `ExtendedOption.LOCALS_AND_OPERANDS` option was used).
>> - The default size of this arrays is currently `StackStreamFactory.SMALL_BATCH` which is 8 (but see [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447)).
>> - `StackStreamFactory` than calls `AbstractStackWalker.callStackWalk()` which is a natively implemented in the VM by `JVM_CallStackWalk()`.
>> -  `JVM_CallStackWalk()` calls `StackWalk::walk()` which calls `StackWalk::fetchFirstBatch()` which calls `StackWalk::fill_in_frames()` which walks the stack and fills in the available class/stackframe slots in the passed in array until the array is full or there are no more stack frames,
>> - Once  `StackWalk::fill_in_frames()` returns, `StackWalk::fetchFirstBatch()` calls back to Java by invoking `AbstractStackWalker::doStackWalk()` to consume the result.
>> - `AbstractStackWalker::doStackWalk()` calls `consumeFrames()` (which is overridden depending on whether we initially called `getCallerClass()` or `walk()`) which consumes the frames until it either finishes (e.g. finds the caller class) or until there are no more frames.
>> - In the latter case `consumeFrames()` will call into the the VM again by calling `AbstractStackWalker.fetchStackFrames()` to fetch additional frames from the stack.
>> - `AbstractStackWalker.fetchStackFrames()` is implemented by `JVM_MoreStackWalk()` which calls `StackWalk::fetchNextBatch()` which calls `StackWalk::fill_in_frames()` (the same method that already fetched the initial batch of frames).
>> 
>> Following is a stacktrace of what I've explained so far:
>> 
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x1...
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename new parameter according to the HS coding conventions

As discussed before, the test for a `@CallerSensitive` method must be applied to the first non-reflective, non-methodhandle frame below `StackWalker::getCallerClass()`, independent from the batch in which it appears. Because we can not predict which batch this will be, I've removed the previous solution which added a special flag to distinguish the first from the follow up batches. Instead I've added a new flag `_needs_caller_sensitive_check` to the `BaseFrameStream` class because every invocation of `StackWalker::getCallerClass()` will always use a single instance of `BaseFrameStream`.

Currently the check for `@CallerSensitive` methods can only be done in the VM because for `StackWalker::getCallerClass()` we only pass the `Class` of each stack frame back to Java but not the corresponding `Method`. On the other hand, we currently skip reflective and methodhandle frames in Java (i.e. with `isReflectionFrame()` and `isMethodHandleFrame()`). In order to avoid the need to pass the stack frame methods back to Java I've therefore implemented (and combined) the the check for reflective and methodhandle frames in the VM (see `is_reflection_or_methodhandle_frame()`). Because `isMethodHandleFrame()` was only used in `ClassBuffer::consumeFrames()` it can be removed. I think we can also skip the remaining test for reflective frames in `AbstractStackWalker::peekFrame()` for the `getCallerClass()` case (because that check is now already done in the VM) but I'll leave that for [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447).

I've also moved the `ReflectiveGetCallerClassTest.java` test under `java/lang/StackWalker/CallerSensitiveMethod` such that I can use the `java/util/CSM.java` class which gets injected into the base module for the new `@CallerSensitive` test.

Finally I realized that some `StackWalker` tests fail if we run with `-javaoption:-XX:+ShowHiddenFrames`. Ideally these tests should be fixed to make them agnostic to `ShowHiddenFrames` but for now I've added a `@requires vm.opt.ShowHiddenFrames == false` tag to exclude them if ran with `-XX:+ShowHiddenFrames`.

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

PR Comment: https://git.openjdk.org/jdk/pull/14773#issuecomment-1631065562

From simonis at openjdk.org  Tue Jul 11 15:47:35 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 11 Jul 2023 15:47:35 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() can throw if invoked
 reflectively [v3]
In-Reply-To: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
Message-ID: <BhLE3dfNH4BcJr1wdYplaRLON1PAABl_Kxw9bE0S36k=.388595b3-0094-41af-ad7c-ce8183fb72b2@github.com>

> As the included jtreg test demonstrates, `StackWalker.getCallerClass()` can throw an `UnsupportedOperationException` if called reflectively. Currently this only happens if we invoke `StackWalker.getCallerClass()` recursively reflectively, but this issue will become more prominent once we fix [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447). The gory details follow below:
> 
> The protocol between the Java API and the JVM for `StackWalker.getCallerClass()/walk()` is as follows:
> - On the Java side, `StackWalker` calls into `StackStreamFactory` for the real work.
> - For `StackWalker.getCallerClass()` `StackStreamFactory` basically creates a `Class[]` which will be passed down and filled in the JVM. For `StackWalker.walk()` it will normally be a `StackFrameInfo[]` (or a `LiveStackFrameInfo[]` if the internal `ExtendedOption.LOCALS_AND_OPERANDS` option was used).
> - The default size of this arrays is currently `StackStreamFactory.SMALL_BATCH` which is 8 (but see [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447)).
> - `StackStreamFactory` than calls `AbstractStackWalker.callStackWalk()` which is a natively implemented in the VM by `JVM_CallStackWalk()`.
> -  `JVM_CallStackWalk()` calls `StackWalk::walk()` which calls `StackWalk::fetchFirstBatch()` which calls `StackWalk::fill_in_frames()` which walks the stack and fills in the available class/stackframe slots in the passed in array until the array is full or there are no more stack frames,
> - Once  `StackWalk::fill_in_frames()` returns, `StackWalk::fetchFirstBatch()` calls back to Java by invoking `AbstractStackWalker::doStackWalk()` to consume the result.
> - `AbstractStackWalker::doStackWalk()` calls `consumeFrames()` (which is overridden depending on whether we initially called `getCallerClass()` or `walk()`) which consumes the frames until it either finishes (e.g. finds the caller class) or until there are no more frames.
> - In the latter case `consumeFrames()` will call into the the VM again by calling `AbstractStackWalker.fetchStackFrames()` to fetch additional frames from the stack.
> - `AbstractStackWalker.fetchStackFrames()` is implemented by `JVM_MoreStackWalk()` which calls `StackWalk::fetchNextBatch()` which calls `StackWalk::fill_in_frames()` (the same method that already fetched the initial batch of frames).
> 
> Following is a stacktrace of what I've explained so far:
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x143a96a]  StackWalk::fill_in_frames...

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Fixed case when calling getCallerClass() from a @CallerSensitive method reflectively

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14773/files
  - new: https://git.openjdk.org/jdk/pull/14773/files/1ec6d90b..08143fdb

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

  Stats: 293 lines in 14 files changed: 187 ins; 87 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/14773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14773/head:pull/14773

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

From simonis at openjdk.org  Tue Jul 11 15:55:14 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 11 Jul 2023 15:55:14 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() throws UOE if invoked
 reflectively [v2]
In-Reply-To: <M_BgGUi9gYYTy6o-4fMmF6UkZK3FHNveFulEvWeD37A=.ce0f74b6-7c6d-4cca-8b4b-60b64a1685e4@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
 <yS8kuYQ-iQzTnhuxiiS7-ifGAlxP_6znBKmKMftKL20=.e71006f6-a38c-4340-9afa-1057e8e5b638@github.com>
 <M_BgGUi9gYYTy6o-4fMmF6UkZK3FHNveFulEvWeD37A=.ce0f74b6-7c6d-4cca-8b4b-60b64a1685e4@github.com>
Message-ID: <EEqDGvEL7I7AcE-foE5i6vCnpg7t1PRzmGGW-0RMgRY=.fcd21eb8-c3dc-47de-a7c9-a27f1d7e01a9@github.com>

On Thu, 6 Jul 2023 07:16:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename new parameter according to the HS coding conventions
>
> src/hotspot/share/prims/stackwalk.cpp line 501:
> 
>> 499:     KeepStackGCProcessedMark keep_stack(THREAD);
>> 500:     numFrames = fill_in_frames(mode, stream, frame_count, start_index,
>> 501:                                frames_array, end_index, true, CHECK_NULL);
> 
> Could you annotate the new argument please ie. `true /* first batch */` and `false /* not first batch */`. Thanks.

I've removed these arguments in the latest version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14773#discussion_r1259939849

From duke at openjdk.org  Tue Jul 11 16:18:31 2023
From: duke at openjdk.org (Swati Sharma)
Date: Tue, 11 Jul 2023 16:18:31 GMT
Subject: Integrated: 8311178: JMH tests don't scale well when sharing output
 buffers
In-Reply-To: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
References: <BkRL74lC-UCLegAmbU5QLhk2f5uYnDoZLh2CHL4t0pI=.52c1af97-5ca1-4779-a84a-5e71bd700ec0@github.com>
Message-ID: <1B7eIPZb3Ih_Ep0FEkvR-GRisJ3ZytMXCixJ_YB63ik=.913c26b7-41f4-49a3-a8d2-9b42cdd668d6@github.com>

On Sat, 1 Jul 2023 07:53:17 GMT, Swati Sharma <duke at openjdk.org> wrote:

> The below benchmark files have scaling issues due to cache contention and leads to poor scaling when run on multiple threads. The patch sets the scope from benchmark level to thread level to fix the issue:
> - org/openjdk/bench/java/io/DataOutputStreamTest.java
> - org/openjdk/bench/java/lang/ArrayCopyObject.java
> - org/openjdk/bench/java/lang/ArrayFiddle.java
> - org/openjdk/bench/java/time/format/DateTimeFormatterBench.java
> - org/openjdk/bench/jdk/incubator/vector/IndexInRangeBenchmark.java
> - org/openjdk/bench/jdk/incubator/vector/MemorySegmentVectorAccess.java
> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedBenchmark.java
> - org/openjdk/bench/jdk/incubator/vector/StoreMaskedIOOBEBenchmark.java
> - org/openjdk/bench/vm/compiler/ArrayFill.java
> - org/openjdk/bench/vm/compiler/IndexVector.java
> 
> Also removing the static scope for variables in org/openjdk/bench/jdk/incubator/vector/VectorFPtoIntCastOperations.java for better scaling.
> 
> Please review and share your feedback.
> 
> Thanks,
> Swati

This pull request has now been integrated.

Changeset: a03a3a43
Author:    Swati Sharma <swati.sharma at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a03a3a43bb16ddc7df78f64e07db823224bde6fb
Stats:     17 lines in 12 files changed: 0 ins; 0 del; 17 mod

8311178: JMH tests don't scale well when sharing output buffers

Co-authored-by: Vladimir Ivanov <vaivanov at openjdk.org>
Reviewed-by: ecaspole, sviswanathan, mli

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

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

From mchung at openjdk.org  Tue Jul 11 16:20:32 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 11 Jul 2023 16:20:32 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v24]
In-Reply-To: <fS-1n133eU3Kt5nczYHlu86Z0JouqHhvLuCU05JKS3k=.5680a0e3-44a2-4078-adfc-651d8710a33e@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <fS-1n133eU3Kt5nczYHlu86Z0JouqHhvLuCU05JKS3k=.5680a0e3-44a2-4078-adfc-651d8710a33e@github.com>
Message-ID: <Q_Z-8HZJYqJZ7CG_imS_fOgftLfSryyets29npDQ8Fc=.83ef2efd-2a94-4d45-99dd-8de860e8050a@github.com>

On Tue, 11 Jul 2023 15:15:51 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 incrementally with one additional commit since the last revision:
> 
>   Fix the lazy test, thanks Jorn Vernee!

I missed to comment on `getProxyClassLookup` - we agree to change this to synchronize on the holder object to avoid spinning multiple hidden classes when multiple threads are in the race of creating the wrapper class for the same interface.  Can you make the change?

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

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

From mchung at openjdk.org  Tue Jul 11 16:41:24 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 11 Jul 2023 16:41:24 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v19]
In-Reply-To: <jm_AJ5zALuQSbilifFRNapuZczcMuCy0g9lPwzsBgws=.1d43a13c-9354-4afd-a444-5c759e2db804@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <jm_AJ5zALuQSbilifFRNapuZczcMuCy0g9lPwzsBgws=.1d43a13c-9354-4afd-a444-5c759e2db804@github.com>
Message-ID: <cgEdeux7AIMCkzDIuBmb14_C0N8blidCBm01odFbWQU=.742c2684-41ec-4680-9b1a-c6af24a5f5e5@github.com>

On Thu, 29 Jun 2023 01:55: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 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

Thanks for adding the release note.   I reviewed and made some adjustment to the release note.

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

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

From prappo at openjdk.org  Tue Jul 11 16:43:26 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 11 Jul 2023 16:43:26 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex, length, 
 initialValue)
Message-ID: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>

This PR adds an internal method to calculate hash code from the provided integer array, offset and length into that array, and the initial hash code value.

Current options for calculating a hash code for int[] are inflexible. It's either ArraysSupport.vectorizedHashCode with an offset, length and initial value, or Arrays.hashCode with just an array.

For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling. Unfortunately, it's the only hash code method that operates on an array subrange or accepts the initial hash code value.

A more convenient method could be added and then used, for example, here:

* https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083

* https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680

* https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362

This PR adds such a method and provides tests for it. Additionally, this PR adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, behaviour which was specified but untested.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14831/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14831&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311864
  Stats: 149 lines in 4 files changed: 142 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14831/head:pull/14831

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

From bpb at openjdk.org  Tue Jul 11 16:48:24 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 11 Jul 2023 16:48:24 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1 [v3]
In-Reply-To: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
Message-ID: <UoqsvKkBoidVoDP32Ent2oVPq6ak3qcnNLJBeU25Mno=.be8053b9-3f31-4f71-8d31-adc54f090058@github.com>

> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no guarantee as to how the underlying output stream actually writes the bytes provided to it.

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

  8155902: Add verbiage to existing paragraph; remove apiNote

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14791/files
  - new: https://git.openjdk.org/jdk/pull/14791/files/43c392e8..f89aa63a

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

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

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

From bpb at openjdk.org  Tue Jul 11 16:48:24 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 11 Jul 2023 16:48:24 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1 [v2]
In-Reply-To: <C5ihIpG-q92tbCSc-LG0XIQ3GsIUZBXf74eKrr2qcDA=.c6ff2d45-bc50-408d-8cd7-a41d78f8a77b@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
 <h9PlDFUdKbSjiQtJKLnu_FGLv0vdkrvs-b81pnqIIEU=.34443364-2a9a-4d26-a446-7f6a2e447e99@github.com>
 <C5ihIpG-q92tbCSc-LG0XIQ3GsIUZBXf74eKrr2qcDA=.c6ff2d45-bc50-408d-8cd7-a41d78f8a77b@github.com>
Message-ID: <03AjEm4PNofiI40Z8zpqPGLBYE_5n3wopgdQzRxhxuE=.33148147-edf7-4c94-8ac8-82dc1f24b19b@github.com>

On Tue, 11 Jul 2023 08:30:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8155902: Delete "merely"
>
> src/java.base/share/classes/java/io/DataOutputStream.java line 44:
> 
>> 42:  * the underlying output stream, hence there is no guarantee as to
>> 43:  * the details of how the bytes are written.
>> 44:  *
> 
> It might be better to expand the first paragraph of the class description to make it clearer that it wraps another output stream. Writing to the DOS will write bytes to the underlying output stream. That would give you the setup needed to explain that writing data that is more than one byte may result in several writes to the underlying output stream.

Changed accordingly in f89aa63ac2b03e66ae3f7238e4decbb0d28794de.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14791#discussion_r1259997711

From duke at openjdk.org  Tue Jul 11 16:58:23 2023
From: duke at openjdk.org (Jenny Shivayogi)
Date: Tue, 11 Jul 2023 16:58:23 GMT
Subject: Integrated: 8311645: Memory leak in jspawnhelper spawnChild after
 JDK-8307990
In-Reply-To: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
References: <xG3axl7zox3P6GCfcjoKOGECxTnGyIet-UfiJ-Gs_qQ=.320ae2c1-8f95-4e65-876e-6363706b8c06@github.com>
Message-ID: <4Ti23osThwQGrjOWI61rUwfxJ8CwN3gS7_TUdy-HXeM=.54dbccb6-b253-4ec6-bbc4-44ef8bbebc09@github.com>

On Sat, 8 Jul 2023 02:05:27 GMT, Jenny Shivayogi <duke at openjdk.org> wrote:

> Free-ing 'buf' before two conditional return statements introduced by JDK-8307990

This pull request has now been integrated.

Changeset: 401c3dea
Author:    Jenny Shivayogi <kspeeyu at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/401c3dea5d8823bc9c0f40506ddad46e983ebf68
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8311645: Memory leak in jspawnhelper spawnChild after JDK-8307990

Reviewed-by: shade, simonis, alanb, rriggs

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

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

From mchung at openjdk.org  Tue Jul 11 17:10:34 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 11 Jul 2023 17:10:34 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v22]
In-Reply-To: <VAybno3zx5jZ3EjV0iZci0AP3jFwRqRuEB2RlDSsHQM=.4c298b19-db9d-49f7-9e70-efa270802466@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <cKUEte7iDFjGSjnpWp4Otw-jr49x33S9JARZkrvWng8=.cfdd4210-9319-4f3b-b731-de2befc00eb2@github.com>
 <D8tlg83uRxvtwj52VxhBEjPRej-IPYaMW_tqZWuNnVQ=.83986c56-5be3-4b63-9729-f6cf96064a66@github.com>
 <LjrTTWOLhxHhPHW0H4_SqOaws6oLWwclqL3W0MHvIrg=.47b3298c-2d9f-483b-a54a-f0c8388dab60@github.com>
 <iIDQm1WSc_Ya_rQo36u6KUgNQQox9ociH7iWfDQzPZw=.b4f82817-3b25-471f-ba1f-98f1b51c8ff4@github.com>
 <VAybno3zx5jZ3EjV0iZci0AP3jFwRqRuEB2RlDSsHQM=.4c298b19-db9d-49f7-9e70-efa270802466@github.com>
Message-ID: <QnbPKoLwX8ABDKnszrqxsC9yJScynUFP9BdQJtYpK8g=.1ce09823-309d-4a0f-b274-6a41238e5d85@github.com>

On Tue, 11 Jul 2023 15:13:49 GMT, Chen Liang <liach at openjdk.org> wrote:

> The WeakReference should point to the impl class. The Lookup is a cheap wrapper, so I changed it to be created each time instead. 

I won't object to keep the impl class.   Just to be clear, the test should pass even if it keeps Lookup as the referent, right?

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

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

From jlu at openjdk.org  Tue Jul 11 17:15:21 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 11 Jul 2023 17:15:21 GMT
Subject: Integrated: 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: <pwgiH_72R9pIkv-9jKhYZ9H4fDc7_dN-g3GulA_eOfc=.b0267ba6-4a87-447c-9fbf-ab06667c4cb3@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.

This pull request has now been integrated.

Changeset: 6cb9ec32
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6cb9ec32a68634f0b6f7461c9dc7ef0c0e59861d
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

6960866: [Fmt-Ch] ChoiceFormat claims impossible and unimplemented functionality

Reviewed-by: naoto

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

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

From bpb at openjdk.org  Tue Jul 11 17:17:06 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 11 Jul 2023 17:17:06 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1 [v2]
In-Reply-To: <G0833AaelMZWJYsCjigNTG8aAmCBhOLRjwwOJcXwzq8=.de9e9930-c262-4569-b54a-f9477181f15a@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
 <h9PlDFUdKbSjiQtJKLnu_FGLv0vdkrvs-b81pnqIIEU=.34443364-2a9a-4d26-a446-7f6a2e447e99@github.com>
 <G0833AaelMZWJYsCjigNTG8aAmCBhOLRjwwOJcXwzq8=.de9e9930-c262-4569-b54a-f9477181f15a@github.com>
Message-ID: <C2h9F8u9oBDhSZMDdx4LXOcpwnRfqBGfFbr5kVbmnSE=.231ea827-c33d-49cc-b07e-c2c2922c51ed@github.com>

On Tue, 11 Jul 2023 08:15:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In passing, we should probably look into the inconsistency in the synchronization.

This can be addressed in the context of [JDK-8295797](https://bugs.openjdk.org/browse/JDK-8295797).

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

PR Comment: https://git.openjdk.org/jdk/pull/14791#issuecomment-1631193890

From alanb at openjdk.org  Tue Jul 11 17:27:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Jul 2023 17:27:15 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1 [v3]
In-Reply-To: <UoqsvKkBoidVoDP32Ent2oVPq6ak3qcnNLJBeU25Mno=.be8053b9-3f31-4f71-8d31-adc54f090058@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
 <UoqsvKkBoidVoDP32Ent2oVPq6ak3qcnNLJBeU25Mno=.be8053b9-3f31-4f71-8d31-adc54f090058@github.com>
Message-ID: <iCEAu6C4CH2cw15VJfz2zGoySzKdHpfchZ6I-ciMmT0=.798f4a2c-b776-4b4f-9698-58b900f271e2@github.com>

On Tue, 11 Jul 2023 16:48:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no guarantee as to how the underlying output stream actually writes the bytes provided to it.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8155902: Add verbiage to existing paragraph; remove apiNote

src/java.base/share/classes/java/io/DataOutputStream.java line 37:

> 35:  * write methods of that output stream. Hence writing data consisting of
> 36:  * more than a single byte may cause several writes to the underlying
> 37:  * output stream.

This looks much better than the apiNote. One suggestion is to drop "Hence", I don't think it is needed here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14791#discussion_r1260044736

From Bruno.Borges at microsoft.com  Tue Jul 11 17:34:36 2023
From: Bruno.Borges at microsoft.com (Bruno Borges)
Date: Tue, 11 Jul 2023 17:34:36 +0000
Subject: [EXTERNAL] Re: 4-letter patterns in Date Format Style no longer
 give full text style
In-Reply-To: <0464a56c-9d6d-908f-37bf-e83ddc02af26@oracle.com>
References: <MN2PR21MB14372F87A6D0B81D0831E3AD8530A@MN2PR21MB1437.namprd21.prod.outlook.com>
 <1d6901ec-2dbf-e79a-6ff7-f183849b1360@oracle.com>
 <MN2PR21MB1437A8D1F97C06FFE1DA84378530A@MN2PR21MB1437.namprd21.prod.outlook.com>
 <4bcff591-e5e7-9e2e-2795-5a0b2db8bae0@oracle.com>
 <0464a56c-9d6d-908f-37bf-e83ddc02af26@oracle.com>
Message-ID: <MN2PR21MB14372FFADC09AB02C6E926388531A@MN2PR21MB1437.namprd21.prod.outlook.com>

Thanks all for your comments.

My issue has been on writing a library (baseline with 8, but support 9+ as well) that may take locale as a String input, and it is likely it will come in languaceCode_countryCode format (with underscore instead of dash). My questions started after noticing that in Java 8, new Locale("en_US") was working in our unit tests giving me the right locale with the correct language code, and the correct country code. Then, in Java 9+ due to JEP 252, the unit tests were failing.

If this was an end user application, the solution would certainly to be to tweak the system property as suggested.

To address the issue for the library, I implemented a simple locale parser to check whether the input has a dash, or an underscore. If underscore, then I split the string. Otherwise, I pass it on to Locale(String).

I was just hoping that Locale would have such builder method, similar to Locale.forLanguageTag().

Is it a fair conclusion that perhaps the issue has always been with Locale(String language) accepting languageCode_countryCode as input in Java 8 (due to the legacy database) ?


________________________________
From: Alan Bateman <Alan.Bateman at oracle.com>
Sent: July 10, 2023 11:51 PM
To: Bruno Borges <Bruno.Borges at microsoft.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Cc: Naoto Sato <naoto.sato at oracle.com>
Subject: Re: [EXTERNAL] Re: 4-letter patterns in Date Format Style no longer give full text style



On 10/07/2023 21:09, Naoto Sato wrote:
> :
>
>>
>> And isn't this the case of a breaking change more than just updating
>> the time database used by default in JDK?
>
> You could specify the system property `java.locale.providers` to
> COMPAT to use the JDK8 locales (although this has been deprecated in
> JDK21). However, expecting US resources with Locale("en_US") is
> incorrect in the first place.

Just to add to Naoto's comments.

JDK 8 was the first release to include CLDR locale data (JEP 127). JDK 8
continued to use the legacy JRE locale data by default but the system
property could be use to try out CLDR data in advance of the switch to
using it by default in JDK 9 (JEP 252). From JDK 9 to this day, the
system property can be used to switch back to the JRE lcoale data
although this locale data hasn't been maintained for several years.

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

From bpb at openjdk.org  Tue Jul 11 17:36:18 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 11 Jul 2023 17:36:18 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1 [v4]
In-Reply-To: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
Message-ID: <SFPkCALdaCV4JXRL6g-LQ8-ZlpgLEaF33Z9iJDxWs34=.7e4b8790-6aaa-44e9-852b-391dabab63e2@github.com>

> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no guarantee as to how the underlying output stream actually writes the bytes provided to it.

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

  8155902: Remove "Hence"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14791/files
  - new: https://git.openjdk.org/jdk/pull/14791/files/f89aa63a..3f195664

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

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

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

From alanb at openjdk.org  Tue Jul 11 17:36:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Jul 2023 17:36:19 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1 [v4]
In-Reply-To: <SFPkCALdaCV4JXRL6g-LQ8-ZlpgLEaF33Z9iJDxWs34=.7e4b8790-6aaa-44e9-852b-391dabab63e2@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
 <SFPkCALdaCV4JXRL6g-LQ8-ZlpgLEaF33Z9iJDxWs34=.7e4b8790-6aaa-44e9-852b-391dabab63e2@github.com>
Message-ID: <8kvzPw2eHcSZLXGqQzzjuRLluRcV9pJNd0qsM8t1Tow=.0dd9abc1-43be-4064-965a-b36378441663@github.com>

On Tue, 11 Jul 2023 17:31:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no guarantee as to how the underlying output stream actually writes the bytes provided to it.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8155902: Remove "Hence"

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14791#pullrequestreview-1524796477

From bpb at openjdk.org  Tue Jul 11 17:36:20 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 11 Jul 2023 17:36:20 GMT
Subject: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead
 of 1 [v3]
In-Reply-To: <iCEAu6C4CH2cw15VJfz2zGoySzKdHpfchZ6I-ciMmT0=.798f4a2c-b776-4b4f-9698-58b900f271e2@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
 <UoqsvKkBoidVoDP32Ent2oVPq6ak3qcnNLJBeU25Mno=.be8053b9-3f31-4f71-8d31-adc54f090058@github.com>
 <iCEAu6C4CH2cw15VJfz2zGoySzKdHpfchZ6I-ciMmT0=.798f4a2c-b776-4b4f-9698-58b900f271e2@github.com>
Message-ID: <3OM3o1fIVdEarVJltNh-09-MP0o77mpcWYPjPZrWnVg=.2d89df8c-9ae9-473e-9298-043bf2fa1212@github.com>

On Tue, 11 Jul 2023 17:24:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8155902: Add verbiage to existing paragraph; remove apiNote
>
> src/java.base/share/classes/java/io/DataOutputStream.java line 37:
> 
>> 35:  * write methods of that output stream. Hence writing data consisting of
>> 36:  * more than a single byte may cause several writes to the underlying
>> 37:  * output stream.
> 
> This looks much better than the apiNote. One suggestion is to drop "Hence", I don't think it is needed here.

Dropped in 3f195664b25767305e745c91aa9ae8513fa8f9a4.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14791#discussion_r1260059053

From alanb at openjdk.org  Tue Jul 11 17:36:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Jul 2023 17:36:32 GMT
Subject: [jdk21] RFR: 8310892: ScopedValue throwing StructureViolationException
 should be clearer
Message-ID: <70LkDiFCgZL3Hzdf4Bu8R7wQ2dDPAmBA1Np94X7XszI=.8b2eb3ed-26c1-4fb7-96be-d645f2f820c2@github.com>

Clean backport of https://git.openjdk.org/jdk/pull/14679

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

Commit messages:
 - Backport 623cfcd04b0c4662e614cb6a3bf52536abc02d5a

Changes: https://git.openjdk.org/jdk21/pull/113/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=113&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/jdk21/pull/113.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/113/head:pull/113

PR: https://git.openjdk.org/jdk21/pull/113

From darcy at openjdk.org  Tue Jul 11 17:41:18 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 11 Jul 2023 17:41:18 GMT
Subject: [jdk21] RFR: 8310892: ScopedValue throwing
 StructureViolationException should be clearer
In-Reply-To: <70LkDiFCgZL3Hzdf4Bu8R7wQ2dDPAmBA1Np94X7XszI=.8b2eb3ed-26c1-4fb7-96be-d645f2f820c2@github.com>
References: <70LkDiFCgZL3Hzdf4Bu8R7wQ2dDPAmBA1Np94X7XszI=.8b2eb3ed-26c1-4fb7-96be-d645f2f820c2@github.com>
Message-ID: <1wnsL8zM3ztd4WY74rYsysbetZaFh1kK5t3Ie_nvetg=.af071859-aa88-4d3c-9916-cad031c272b4@github.com>

On Tue, 11 Jul 2023 17:21:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Clean backport of https://git.openjdk.org/jdk/pull/14679

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/113#pullrequestreview-1524813830

From rriggs at openjdk.org  Tue Jul 11 17:54:23 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Jul 2023 17:54:23 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v7]
In-Reply-To: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
Message-ID: <1dEun4T-zq47Un7WaIYRz2vbGECpwcGw2bhCDc-Ggrg=.6ce9b8b7-7895-4c5a-a00e-e7b9a6dfc000@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 12 additional commits since the last revision:

 - Improve wording and remove markup for clarity
 - Merge branch 'master' into 8310033-time-compareto
 - Correct the descriptions to correctly identify the compareTo return
   value < 0 as this is before that, and > 0 as this is after that.
   Thanks to a careful reviewer spotting my reversing of the conditions.
 - Improve the grammar of "the comparator value is" -> "the comparator value, that is"
   Thanks for the reminder.
 - Merge branch 'master' into 8310033-time-compareto
 - Improve descriptions to be more specific and remove inappropriate use of before/after
   Remove extra blank lines
 - Clarify return values of date time classes
 - 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
 - ... and 2 more: https://git.openjdk.org/jdk/compare/e99d4aa7...1d39e2d4

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14479/files
  - new: https://git.openjdk.org/jdk/pull/14479/files/5e07e79a..1d39e2d4

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

  Stats: 41002 lines in 32 files changed: 638 ins; 40238 del; 126 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 iris at openjdk.org  Tue Jul 11 17:57:14 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 11 Jul 2023 17:57:14 GMT
Subject: [jdk21] RFR: 8310892: ScopedValue throwing
 StructureViolationException should be clearer
In-Reply-To: <70LkDiFCgZL3Hzdf4Bu8R7wQ2dDPAmBA1Np94X7XszI=.8b2eb3ed-26c1-4fb7-96be-d645f2f820c2@github.com>
References: <70LkDiFCgZL3Hzdf4Bu8R7wQ2dDPAmBA1Np94X7XszI=.8b2eb3ed-26c1-4fb7-96be-d645f2f820c2@github.com>
Message-ID: <cpe2zL1EIqqJ34Uu_CeVrIqvOkfUHH1lvTxRkeMFGSk=.b99aa881-4c20-45bf-b38f-88a47bafc108@github.com>

On Tue, 11 Jul 2023 17:21:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Clean backport of https://git.openjdk.org/jdk/pull/14679

Same as 22.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/113#pullrequestreview-1524839981

From mchung at openjdk.org  Tue Jul 11 18:03:35 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 11 Jul 2023 18:03:35 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v24]
In-Reply-To: <fS-1n133eU3Kt5nczYHlu86Z0JouqHhvLuCU05JKS3k=.5680a0e3-44a2-4078-adfc-651d8710a33e@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <fS-1n133eU3Kt5nczYHlu86Z0JouqHhvLuCU05JKS3k=.5680a0e3-44a2-4078-adfc-651d8710a33e@github.com>
Message-ID: <-n4IYL86ZptMmc0AxkSGVEUlb2YeUMaL61IAm80b-iI=.2451b3cc-238c-49d0-8af6-629605b76204@github.com>

On Tue, 11 Jul 2023 15:15:51 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 incrementally with one additional commit since the last revision:
> 
>   Fix the lazy test, thanks Jorn Vernee!

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 325:

> 323:             r.set(cl);
> 324:         }
> 325:         return new Lookup(cl);

Suggestion:

         if (cl != null)
            return new Lookup(cl);

        synchronized (r) {
            cl = r.get();
            if (cl == null) {
                // If the referent is cleared, create a new value and update cached weak reference.
                cl = newProxy(intfc);
                r.set(cl);
            }
            return new Lookup(cl);
        }

test/jdk/java/lang/invoke/MethodHandleProxies/ProxiesImplementationTest.java line 55:

> 53:  * @run junit ProxiesImplementationTest
> 54:  */
> 55: public class ProxiesImplementationTest {

how about `WrapperHiddenClassTest`?   It's explicit that this verifies the wrapper hidden class.

test/jdk/java/lang/invoke/MethodHandleProxies/ProxiesImplementationTest.java line 130:

> 128:     @Test
> 129:     public void testNoAccess() {
> 130:         Client untrusted = asInterfaceInstance(Client.class, MethodHandles.zero(void.class));

Suggestion:

        Client obj = asInterfaceInstance(Client.class, MethodHandles.zero(void.class));

test/jdk/java/lang/invoke/MethodHandleProxies/ProxiesImplementationTest.java line 132:

> 130:         Client untrusted = asInterfaceInstance(Client.class, MethodHandles.zero(void.class));
> 131:         var instanceClass = untrusted.getClass();
> 132:         var leakLookup = Client.leakLookup();

This is not really malicious code.   It's checking the interface has no access to the proxy class.   Probably better to rename them to be less alarming.

Suggestion:

        var lookup = Client.lookup();

test/jdk/java/lang/invoke/MethodHandleProxies/ProxiesImplementationTest.java line 134:

> 132:         var leakLookup = Client.leakLookup();
> 133:         assertEquals(MethodHandles.Lookup.ORIGINAL, leakLookup.lookupModes() & MethodHandles.Lookup.ORIGINAL,
> 134:                 "Leaked lookup original flag");

Suggestion:

                "expect lookup has original flag");

test/jdk/java/lang/invoke/MethodHandleProxies/ProxiesImplementationTest.java line 194:

> 192: 
> 193:         var c1 = asInterfaceInstance(ifaceClass, mh);
> 194:         cl = new WeakReference<>(c1.getClass());

Nit: define a new variable not to mix with `c1`.

Suggestion:

        var wr = new WeakReference<>(c1.getClass());

test/jdk/java/lang/invoke/MethodHandleProxies/ProxiesImplementationTest.java line 198:

> 196:         System.gc();
> 197:         var c2 = asInterfaceInstance(ifaceClass, mh);
> 198:         assertTrue(cl.refersTo(c2.getClass()), "MHP should reuse implementation class when available");

We can simplify the test a little bit.  Just to check if the class of `c1` and `c2` is the same first.

Suggestion:

        var c2 = asInterfaceInstance(ifaceClass, mh);
        assertTrue(c1.getClass() == c2.getClass(), "MHP should reuse implementation class when available");

test/jdk/java/lang/invoke/MethodHandleProxies/ProxiesImplementationTest.java line 201:

> 199:         Reference.reachabilityFence(c1);
> 200: 
> 201:         // allow GC in interpreter

This not only affects GC in interpreter.   maybe something like this:

Suggestion:

        // clear strong reference to the wrapper instances

test/jdk/java/lang/invoke/MethodHandleProxies/ProxiesImplementationTest.java line 206:

> 204: 
> 205:         System.gc();
> 206:         assertTrue(cl.refersTo(null), "MHP impl class should be cleared by gc"); // broken

Use `jdk.test.lib.util.ForceGC` to make the check more reliable.   Add `@library /test/lib` to use the test library.

Suggestion:

        if (ForceGC.wait(() -> wr.refersTo(null))) {
            assertTrue(wr.refersTo(null), "MHP impl class should be cleared by gc");
        }

test/jdk/java/lang/invoke/MethodHandleProxies/ProxiesInterfaceTest.java line 56:

> 54:  * @run junit ProxiesInterfaceTest
> 55:  */
> 56: public class ProxiesInterfaceTest {

I can't tell from the test name that is any different than the basic test.    It seems that this test can be merged with `ProxiesBasicTest.java`.  It can simply be named as `BasicTest.java`.   The prefix `Proxies` seems redundant.

test/jdk/java/lang/invoke/MethodHandleProxies/ProxiesInterfaceTest.java line 143:

> 141:     }
> 142: 
> 143:     //<editor-fold desc="Infrastructure">

this comment can be deleted.

test/jdk/java/lang/invoke/MethodHandleProxies/ProxiesInterfaceTest.java line 257:

> 255:     public non-sealed interface NonSealed extends Sealed {
> 256:     }
> 257:     //</editor-fold>

comment inserted by IDE?

test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesAsIFInstanceCall.java line 36:

> 34: import org.openjdk.jmh.annotations.Warmup;
> 35: 
> 36: import java.lang.invoke.LambdaMetafactory;

this import is unused.

test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesAsIFInstanceCall.java line 49:

> 47: /**
> 48:  * Benchmark evaluates the call performance of MethodHandleProxies.asInterfaceInstance
> 49:  * return value, compared to

incomplete comment?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260091588
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260084281
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260038998
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260042092
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260042412
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260063660
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260065837
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260085900
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260070232
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260082317
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260076642
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260077571
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260086803
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260087517

From mchung at openjdk.org  Tue Jul 11 18:03:37 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 11 Jul 2023 18:03:37 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v24]
In-Reply-To: <-n4IYL86ZptMmc0AxkSGVEUlb2YeUMaL61IAm80b-iI=.2451b3cc-238c-49d0-8af6-629605b76204@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <fS-1n133eU3Kt5nczYHlu86Z0JouqHhvLuCU05JKS3k=.5680a0e3-44a2-4078-adfc-651d8710a33e@github.com>
 <-n4IYL86ZptMmc0AxkSGVEUlb2YeUMaL61IAm80b-iI=.2451b3cc-238c-49d0-8af6-629605b76204@github.com>
Message-ID: <AluIhuvPEGjy3arL_cTyHp1rc4JKv1h4V44FFgY4v8E=.9a7f14e7-2285-4521-ad57-d5ba0c0c41e0@github.com>

On Tue, 11 Jul 2023 17:38:42 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the lazy test, thanks Jorn Vernee!
>
> test/jdk/java/lang/invoke/MethodHandleProxies/ProxiesImplementationTest.java line 206:
> 
>> 204: 
>> 205:         System.gc();
>> 206:         assertTrue(cl.refersTo(null), "MHP impl class should be cleared by gc"); // broken
> 
> Use `jdk.test.lib.util.ForceGC` to make the check more reliable.   Add `@library /test/lib` to use the test library.
> 
> Suggestion:
> 
>         if (ForceGC.wait(() -> wr.refersTo(null))) {
>             assertTrue(wr.refersTo(null), "MHP impl class should be cleared by gc");
>         }

Can test new hidden class is spinned after `ForceGC`:


        c1 = asInterfaceInstance(ifaceClass, mh);
        c2 = asInterfaceInstance(ifaceClass, mh);
        assertTrue(c1.getClass() == c2.getClass(), "MHP should reuse implementation class when available");
        Reference.reachabilityFence(c1);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260071394

From lancea at openjdk.org  Tue Jul 11 18:04:12 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 11 Jul 2023 18:04:12 GMT
Subject: [jdk21] RFR: 8310892: ScopedValue throwing
 StructureViolationException should be clearer
In-Reply-To: <70LkDiFCgZL3Hzdf4Bu8R7wQ2dDPAmBA1Np94X7XszI=.8b2eb3ed-26c1-4fb7-96be-d645f2f820c2@github.com>
References: <70LkDiFCgZL3Hzdf4Bu8R7wQ2dDPAmBA1Np94X7XszI=.8b2eb3ed-26c1-4fb7-96be-d645f2f820c2@github.com>
Message-ID: <FDg3EgPmkXIFMk2-OVYNqEgFYGxnDP-L0DqwqBnurxY=.b5c19cb6-abb2-4456-9182-79a8ff182679@github.com>

On Tue, 11 Jul 2023 17:21:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Clean backport of https://git.openjdk.org/jdk/pull/14679

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/113#pullrequestreview-1524851331

From djelinski at openjdk.org  Tue Jul 11 18:19:55 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 11 Jul 2023 18:19:55 GMT
Subject: RFR: 8155902: DataOuputStream should clarify that it might write
 primitive types as multiple byte groups [v4]
In-Reply-To: <SFPkCALdaCV4JXRL6g-LQ8-ZlpgLEaF33Z9iJDxWs34=.7e4b8790-6aaa-44e9-852b-391dabab63e2@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
 <SFPkCALdaCV4JXRL6g-LQ8-ZlpgLEaF33Z9iJDxWs34=.7e4b8790-6aaa-44e9-852b-391dabab63e2@github.com>
Message-ID: <I_B9R3nMqratwsPtG1tUv9Z1ntYp3dO3L_axnsExTGk=.284a2663-f5c1-4f02-94b6-02965c372232@github.com>

On Tue, 11 Jul 2023 17:36:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no guarantee as to how the underlying output stream actually writes the bytes provided to it.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8155902: Remove "Hence"

LGTM.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14791#pullrequestreview-1524897743

From liach at openjdk.org  Tue Jul 11 18:21:34 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Jul 2023 18:21:34 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v22]
In-Reply-To: <QnbPKoLwX8ABDKnszrqxsC9yJScynUFP9BdQJtYpK8g=.1ce09823-309d-4a0f-b274-6a41238e5d85@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <cKUEte7iDFjGSjnpWp4Otw-jr49x33S9JARZkrvWng8=.cfdd4210-9319-4f3b-b731-de2befc00eb2@github.com>
 <D8tlg83uRxvtwj52VxhBEjPRej-IPYaMW_tqZWuNnVQ=.83986c56-5be3-4b63-9729-f6cf96064a66@github.com>
 <LjrTTWOLhxHhPHW0H4_SqOaws6oLWwclqL3W0MHvIrg=.47b3298c-2d9f-483b-a54a-f0c8388dab60@github.com>
 <iIDQm1WSc_Ya_rQo36u6KUgNQQox9ociH7iWfDQzPZw=.b4f82817-3b25-471f-ba1f-98f1b51c8ff4@github.com>
 <VAybno3zx5jZ3EjV0iZci0AP3jFwRqRuEB2RlDSsHQM=.4c298b19-db9d-49f7-9e70-efa270802466@github.com>
 <QnbPKoLwX8ABDKnszrqxsC9yJScynUFP9BdQJtYpK8g=.1ce09823-309d-4a0f-b274-6a41238e5d85@github.com>
Message-ID: <M1vUvQfLmlJ5X2HzlU4cfEqba_UQTOOR8eHFTdeShrM=.6dde848e-e12c-4fb3-bb1f-a35b51635faf@github.com>

On Tue, 11 Jul 2023 17:07:00 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>  Just to be clear, the test should pass even if it keeps Lookup as the referent, right?

No. The test will not because there's no reference to the `Lookup` except in `asInterfaceInstance` itself; the `Lookup`s thus are always eligible for GC, even if there's living wrapper instance, as shown in the first broken `assertTrue(cl.referTo(c2.getClass()))` test. The `Class` object for implementation, however, is always reachable as long as any wrapper instance is reachable.

The alternative to keeping Classes in weak reference is to keep a lookup in the hidden class and cache that particular lookup, which IMO only complicates both the support code (have to distinguish from `Lookup` returned by `defineHiddenClass` and edit spinned bytecode).

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

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

From prappo at openjdk.org  Tue Jul 11 18:23:15 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 11 Jul 2023 18:23:15 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
Message-ID: <l_iGdiDyneZYKB4vEsgn5zFAM-W2wZttqwoOtDeA7EE=.31840bf9-da2b-4e1a-8c50-cdf7e34bae98@github.com>

On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR adds an internal method to calculate hash code from the provided integer array, offset and length into that array, and the initial hash code value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's either ArraysSupport.vectorizedHashCode with an offset, length and initial value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling. Unfortunately, it's the only hash code method that operates on an array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, behaviour which was specified but untested.

If people agree with this PR in principle, I'll include variants for byte[] and Object[] in this PR. So it could be immediately used in already identified sites in JDK, once integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1631283432

From mchung at openjdk.org  Tue Jul 11 18:27:28 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 11 Jul 2023 18:27:28 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v24]
In-Reply-To: <fS-1n133eU3Kt5nczYHlu86Z0JouqHhvLuCU05JKS3k=.5680a0e3-44a2-4078-adfc-651d8710a33e@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <fS-1n133eU3Kt5nczYHlu86Z0JouqHhvLuCU05JKS3k=.5680a0e3-44a2-4078-adfc-651d8710a33e@github.com>
Message-ID: <rqF4P0KgiZ2LgpCfqjE5lPVm01HhPC0CcoZfnxXh1L0=.98496b0e-7751-4bb7-b014-36bf8b65f368@github.com>

On Tue, 11 Jul 2023 15:15:51 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 incrementally with one additional commit since the last revision:
> 
>   Fix the lazy test, thanks Jorn Vernee!

I see now.   Ok.    Then `getProxyClassLookup` can simply return `Class<?>` and let the caller to create the `Lookup` object then (should rename to `getProxyClass`).

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

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

From liach at openjdk.org  Tue Jul 11 18:34:33 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Jul 2023 18:34:33 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v24]
In-Reply-To: <-n4IYL86ZptMmc0AxkSGVEUlb2YeUMaL61IAm80b-iI=.2451b3cc-238c-49d0-8af6-629605b76204@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <fS-1n133eU3Kt5nczYHlu86Z0JouqHhvLuCU05JKS3k=.5680a0e3-44a2-4078-adfc-651d8710a33e@github.com>
 <-n4IYL86ZptMmc0AxkSGVEUlb2YeUMaL61IAm80b-iI=.2451b3cc-238c-49d0-8af6-629605b76204@github.com>
Message-ID: <86NhS6LZpZn6vIt_7W-ns0E-FQmsSveOdRWq2rbhJuU=.d2269100-4bda-4806-ba9a-892db7b70c68@github.com>

On Tue, 11 Jul 2023 17:36:33 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the lazy test, thanks Jorn Vernee!
>
> test/jdk/java/lang/invoke/MethodHandleProxies/ProxiesImplementationTest.java line 198:
> 
>> 196:         System.gc();
>> 197:         var c2 = asInterfaceInstance(ifaceClass, mh);
>> 198:         assertTrue(cl.refersTo(c2.getClass()), "MHP should reuse implementation class when available");
> 
> We can simplify the test a little bit.  Just to check if the class of `c1` and `c2` is the same first.
> 
> Suggestion:
> 
>         var c2 = asInterfaceInstance(ifaceClass, mh);
>         assertTrue(c1.getClass() == c2.getClass(), "MHP should reuse implementation class when available");

I will keep the gc, which ensures a scenario like that incorrectly weakref'd Lookup doesn't happpen again.

> test/jdk/java/lang/invoke/MethodHandleProxies/ProxiesInterfaceTest.java line 143:
> 
>> 141:     }
>> 142: 
>> 143:     //<editor-fold desc="Infrastructure">
> 
> this comment can be deleted.

It was a leftover from when I tried to organize the tests with IDE editor folds. No longer necessary indeed.

> test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesAsIFInstanceCall.java line 49:
> 
>> 47: /**
>> 48:  * Benchmark evaluates the call performance of MethodHandleProxies.asInterfaceInstance
>> 49:  * return value, compared to
> 
> incomplete comment?

On a side note, these benchmarks were added for the class-per-MH implementation; I probably need to reevaluate if these 2 benchmarks are needed, or if the original `MethodHandleProxiesAsIFInstance.java` suffices.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260124340
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260116789
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1260116076

From liach at openjdk.org  Tue Jul 11 18:38:25 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Jul 2023 18:38:25 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v19]
In-Reply-To: <jm_AJ5zALuQSbilifFRNapuZczcMuCy0g9lPwzsBgws=.1d43a13c-9354-4afd-a444-5c759e2db804@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <jm_AJ5zALuQSbilifFRNapuZczcMuCy0g9lPwzsBgws=.1d43a13c-9354-4afd-a444-5c759e2db804@github.com>
Message-ID: <i0XXJOuUkcPq34xvt4qcTjamURSyE7EAZR5BeLX2dZI=.006ca241-020e-475a-82f6-9cff7ab6b577@github.com>

On Thu, 29 Jun 2023 01:55: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 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

Can I integrate this patch now? Seems release notes are usually delivered after patch integration.

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

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

From lancea at openjdk.org  Tue Jul 11 18:45:14 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 11 Jul 2023 18:45:14 GMT
Subject: RFR: 8155902: DataOuputStream should clarify that it might write
 primitive types as multiple byte groups [v4]
In-Reply-To: <SFPkCALdaCV4JXRL6g-LQ8-ZlpgLEaF33Z9iJDxWs34=.7e4b8790-6aaa-44e9-852b-391dabab63e2@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
 <SFPkCALdaCV4JXRL6g-LQ8-ZlpgLEaF33Z9iJDxWs34=.7e4b8790-6aaa-44e9-852b-391dabab63e2@github.com>
Message-ID: <G5ti6LS3Gc2TRcbUW367GhOq5ixCe9ojvaSAgMcQu7E=.45106e10-f0e7-4422-93ba-2ab0d90ca30f@github.com>

On Tue, 11 Jul 2023 17:36:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no guarantee as to how the underlying output stream actually writes the bytes provided to it.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8155902: Remove "Hence"

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14791#pullrequestreview-1524954637

From mchung at openjdk.org  Tue Jul 11 18:52:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 11 Jul 2023 18:52:12 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v19]
In-Reply-To: <jm_AJ5zALuQSbilifFRNapuZczcMuCy0g9lPwzsBgws=.1d43a13c-9354-4afd-a444-5c759e2db804@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <jm_AJ5zALuQSbilifFRNapuZczcMuCy0g9lPwzsBgws=.1d43a13c-9354-4afd-a444-5c759e2db804@github.com>
Message-ID: <tZybqTa_3-istJeKeuVNJ4Hsoq1bm9MaYarickgxOBc=.9973bd88-9f49-43b6-99b4-79231d1b3fc9@github.com>

On Thu, 29 Jun 2023 01:55: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 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

yes, go ahead.

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

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

From liach at openjdk.org  Tue Jul 11 19:02:13 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Jul 2023 19:02:13 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v19]
In-Reply-To: <jm_AJ5zALuQSbilifFRNapuZczcMuCy0g9lPwzsBgws=.1d43a13c-9354-4afd-a444-5c759e2db804@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <jm_AJ5zALuQSbilifFRNapuZczcMuCy0g9lPwzsBgws=.1d43a13c-9354-4afd-a444-5c759e2db804@github.com>
Message-ID: <i7yBMeBbLt0sSEnteSxjLSB22QSvK9R8WZnJJPh2cUQ=.baeeccd4-d707-4536-be32-a2fc3c889a56@github.com>

On Thu, 29 Jun 2023 01:55: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 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

Sorry for my incorrect ping and bothering.

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

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

From liach at openjdk.org  Tue Jul 11 19:22:58 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Jul 2023 19:22:58 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v25]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <dTxPQBneimja4eNhQuamUgJNakNMzgATciUte76SK5c=.95622355-daa2-41a9-bfdf-a1527eb077a3@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 incrementally with one additional commit since the last revision:

  Review changees

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/c7b852d9..4a41e8cb

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

  Stats: 1517 lines in 9 files changed: 600 ins; 907 del; 10 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 rriggs at openjdk.org  Tue Jul 11 19:26:05 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Jul 2023 19:26:05 GMT
Subject: RFR: 8155902: DataOuputStream should clarify that it might write
 primitive types as multiple byte groups [v4]
In-Reply-To: <SFPkCALdaCV4JXRL6g-LQ8-ZlpgLEaF33Z9iJDxWs34=.7e4b8790-6aaa-44e9-852b-391dabab63e2@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
 <SFPkCALdaCV4JXRL6g-LQ8-ZlpgLEaF33Z9iJDxWs34=.7e4b8790-6aaa-44e9-852b-391dabab63e2@github.com>
Message-ID: <ZTE0yEwz54HhwqsxbWrYbs4pZcnsYu4YhVrHl-eeCCM=.0c9ff187-2163-4cbd-9dec-9644d1f22cd1@github.com>

On Tue, 11 Jul 2023 17:36:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no guarantee as to how the underlying output stream actually writes the bytes provided to it.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8155902: Remove "Hence"

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14791#pullrequestreview-1525016664

From mcimadamore at openjdk.org  Tue Jul 11 21:47:12 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 11 Jul 2023 21:47:12 GMT
Subject: [jdk21] Integrated: 8311593: Minor doc issue in MemorySegment::copy
In-Reply-To: <0T-uF2XS0HX5safbT6DRyTd3M_VJ5bpIpY92ByNa3Go=.ba5d0b84-57c7-40c2-ad4c-3f9bb77cfd60@github.com>
References: <0T-uF2XS0HX5safbT6DRyTd3M_VJ5bpIpY92ByNa3Go=.ba5d0b84-57c7-40c2-ad4c-3f9bb77cfd60@github.com>
Message-ID: <a3oHs-aNjuIugcjlusgmRj9t8ieS4CVcByLz6UV8QNQ=.7c4d8a24-ddc5-4c50-88ad-2f4c87e0e625@github.com>

On Tue, 11 Jul 2023 00:40:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Clean backport of https://git.openjdk.org/jdk/pull/14813
> (sorry for filing another one, I realized there was an issue with the JBS issues pointing the wrong way)

This pull request has now been integrated.

Changeset: ca108041
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/ca10804155d37b814d58a79f1f308eb189fb8a72
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8311593: Minor doc issue in MemorySegment::copy

Reviewed-by: jvernee
Backport-of: 6569b252b9e61e3eed77039c483529154feffbba

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

PR: https://git.openjdk.org/jdk21/pull/109

From asemenyuk at openjdk.org  Tue Jul 11 22:19:13 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 11 Jul 2023 22:19:13 GMT
Subject: RFR: 8311631: When multiple users run
 tools/jpackage/share/LicenseTest.java,
 Permission denied for writing /var/tmp/*.files
In-Reply-To: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
References: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
Message-ID: <HoEIx-hPC8rzh2LMfeyPmbFAEsP_vpIZqo0ZPjjSiCA=.57a09bca-1743-4541-9dee-5c6c93ad11aa@github.com>

On Fri, 7 Jul 2023 09:51:23 GMT, yaqsun <duke at openjdk.org> wrote:

> Low risk, only test changes.
> The prerequisite is to install the rpmbuild command, when multiple users switch to write /var/tmp/*.files will have the permission forbidden.

The change affects jpackage rpm spec template file. It is misleading to state that this change is `Low risk, only test changes.`

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

PR Comment: https://git.openjdk.org/jdk/pull/14802#issuecomment-1631579638

From asemenyuk at openjdk.org  Tue Jul 11 22:53:10 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 11 Jul 2023 22:53:10 GMT
Subject: RFR: 8311631: When multiple users run
 tools/jpackage/share/LicenseTest.java,
 Permission denied for writing /var/tmp/*.files
In-Reply-To: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
References: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
Message-ID: <OZuXDYhO8ZtNR7iD_IBq_OJyPNd2IInJtW08LvNy__M=.acb1947d-8a01-40cb-b20d-63ffcfd035ad@github.com>

On Fri, 7 Jul 2023 09:51:23 GMT, yaqsun <duke at openjdk.org> wrote:

> Low risk, only test changes.
> The prerequisite is to install the rpmbuild command, when multiple users switch to write /var/tmp/*.files will have the permission forbidden.

How about `%{buildroot}`? Shouldn't it be user-specific as well?

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

Changes requested by asemenyuk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14802#pullrequestreview-1525254211

From duke at openjdk.org  Wed Jul 12 01:17:04 2023
From: duke at openjdk.org (yaqsun)
Date: Wed, 12 Jul 2023 01:17:04 GMT
Subject: RFR: 8311631: When multiple users run
 tools/jpackage/share/LicenseTest.java,
 Permission denied for writing /var/tmp/*.files
In-Reply-To: <HoEIx-hPC8rzh2LMfeyPmbFAEsP_vpIZqo0ZPjjSiCA=.57a09bca-1743-4541-9dee-5c6c93ad11aa@github.com>
References: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
 <HoEIx-hPC8rzh2LMfeyPmbFAEsP_vpIZqo0ZPjjSiCA=.57a09bca-1743-4541-9dee-5c6c93ad11aa@github.com>
Message-ID: <OmS10IJIIIqoloGB89hrHxVnArfrv60zIpjbMdDS9Ac=.a03b6cff-3b28-4a15-9bee-345e8d1bb1ed@github.com>

On Tue, 11 Jul 2023 22:15:49 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> The change affects jpackage rpm spec template file. It is misleading to state that this change is `Low risk, only test changes.`

My mistake, I will update the initial comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/14802#issuecomment-1631707190

From asemenyuk at openjdk.org  Wed Jul 12 01:41:11 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 12 Jul 2023 01:41:11 GMT
Subject: RFR: 8311631: When multiple users run
 tools/jpackage/share/LicenseTest.java,
 Permission denied for writing /var/tmp/*.files
In-Reply-To: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
References: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
Message-ID: <wE3fUa6CgkTlKKi6_mWcBJWv_YsSmTTTK7ULjKcMT14=.ad6c03f8-8d46-4868-a83f-51807caf5e22@github.com>

On Fri, 7 Jul 2023 09:51:23 GMT, yaqsun <duke at openjdk.org> wrote:

> The prerequisite is to install the rpmbuild command, when multiple users switch to write /var/tmp/*.files will have the permission forbidden.

I believe the problem is the use of `%{_tmppath}` for the root of intermediate files. Should be changed to `%{_builddir}` or some other user-specific directory

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

PR Comment: https://git.openjdk.org/jdk/pull/14802#issuecomment-1631722800

From duke at openjdk.org  Wed Jul 12 02:32:52 2023
From: duke at openjdk.org (yaqsun)
Date: Wed, 12 Jul 2023 02:32:52 GMT
Subject: RFR: 8311631: When multiple users run
 tools/jpackage/share/LicenseTest.java,
 Permission denied for writing /var/tmp/*.files
In-Reply-To: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
References: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
Message-ID: <b4-kcoE6z4WEgXKl4dn0uPgDLeHoC6nyHJWxTMHluh4=.80666ae0-332f-4438-9156-17e907488b7c@github.com>

On Fri, 7 Jul 2023 09:51:23 GMT, yaqsun <duke at openjdk.org> wrote:

> The prerequisite is to install the rpmbuild command, when multiple users switch to write /var/tmp/*.files will have the permission forbidden.

How about JTwork(if achievable)? Files created in JTwork do not need to be cleaned when the "rpmbuild" command completes.

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

PR Comment: https://git.openjdk.org/jdk/pull/14802#issuecomment-1631757760

From alanb at openjdk.org  Wed Jul 12 06:53:23 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Jul 2023 06:53:23 GMT
Subject: [jdk21] Integrated: 8310892: ScopedValue throwing
 StructureViolationException should be clearer
In-Reply-To: <70LkDiFCgZL3Hzdf4Bu8R7wQ2dDPAmBA1Np94X7XszI=.8b2eb3ed-26c1-4fb7-96be-d645f2f820c2@github.com>
References: <70LkDiFCgZL3Hzdf4Bu8R7wQ2dDPAmBA1Np94X7XszI=.8b2eb3ed-26c1-4fb7-96be-d645f2f820c2@github.com>
Message-ID: <U-AhYtZ4zAVt5z94xnQ7lewYPpmUU1I5iBeePwHSF2k=.1a742754-66a3-4e48-a3b8-4d5419cda5ac@github.com>

On Tue, 11 Jul 2023 17:21:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Clean backport of https://git.openjdk.org/jdk/pull/14679

This pull request has now been integrated.

Changeset: 3bb37508
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/3bb375080f0ff205a5a200d0355dbd517d29c857
Stats:     60 lines in 1 file changed: 12 ins; 6 del; 42 mod

8310892: ScopedValue throwing StructureViolationException should be clearer

Reviewed-by: darcy, iris, lancea
Backport-of: 623cfcd04b0c4662e614cb6a3bf52536abc02d5a

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

PR: https://git.openjdk.org/jdk21/pull/113

From alanb at openjdk.org  Wed Jul 12 07:00:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Jul 2023 07:00:26 GMT
Subject: RFR: 8311867: StructuredTaskScope.shutdown does not interrupt newly
 started threads
Message-ID: <vrfJZDSublpA2ZOXK_AfTF92D8hbzLsQRqx1Xp4HBFI=.475d09c2-7629-4d2c-b966-c2b93c4f400c@github.com>

StructuredTaskScope.shutdown can sometimes not interrupt the thread for a newly forked subtask, leading to join blocking until subtask completes. The "hang" can be duplicated with a stress test that shuts down the scope while a long running subtask is being forked. The bug is in the underlying thread flock code where it filters the threads to just the live threads and so filters out new/unstarted threads, that filtering was left over from some refactoring in the loom repo a long time ago and should have been removed.

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

Commit messages:
 - Initial commit

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

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

From duke at openjdk.org  Wed Jul 12 07:04:15 2023
From: duke at openjdk.org (sid8606)
Date: Wed, 12 Jul 2023 07:04:15 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
Message-ID: <sF3GAJ8QhF2tt-gcSyZp0yiCMJwJGAtEJSdpHmX4bcg=.63061877-b597-42a0-9c05-686f45bd8cf8@github.com>

On Sat, 8 Jul 2023 10:48:15 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address suggestions from Jorn Vernee

@TheRealMDoerr , @reinrich  Please review this PR, Would like to hear your reviews on platform specific changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/14801#issuecomment-1631958291

From duke at openjdk.org  Wed Jul 12 09:08:16 2023
From: duke at openjdk.org (Andy-Tatman)
Date: Wed, 12 Jul 2023 09:08:16 GMT
Subject: RFR: 8305734+8311905:
 "BitSet.get(int, int) always returns the empty BitSet when the Integer.MAX
 VALUE is set" +
 "BitSet.valueOf(...) allows bitsets to be created that behave incorrectly."
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: <aUrAwayH3wclmtFV8ichP5RszDudEHhJOHsn4bFmMDo=.64c2f3db-1f95-4525-8bcc-610951b2e841@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 and https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8311905

I posted a second bug report & edited this PR to also include this second bug. https://bugs.openjdk.org/browse/JDK-8311905

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

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1632130983

From alanb at openjdk.org  Wed Jul 12 09:11:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Jul 2023 09:11:32 GMT
Subject: RFR: 8311926: java/lang/ScopedValue/StressStackOverflow.java takes
 9mins in tier1
Message-ID: <WRhBxjo1GoGAyyFxnzLVoN4nPOmOCe3_2rhBevgi5E8=.ba60391d-9984-4fdb-8ebf-e9b75aaa9b1f@github.com>

The test runs 3 times, each run is for 3 minutes so 9 mins in total and too long for tier1. Here's the times for test/jdk:tier1_part1 that I see locally:


==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/jdk:tier1_part1                    1025  1025     0     0
==============================
TEST SUCCESS

Finished building target 'run-test' in configuration 'linux-x64'

real	10m22.414s
user	64m1.774s
sys	2m31.938s


The test is changed to use separate test description so that the 3 runs can execute in parallel if possible. I've also dialled down the test from 3 to 2 minutes. At some point we need to tackle the issue of stress tests in tier1, this one may be a candidate for a higher tier. The exclude list for JTREG_TEST_THREAD_FACTORY=Virtual (ProblemList-Virtual.txt) is also updated to exclude the test on all platforms rather than just Linux while JDK-8309646 is being investigated.

Here are the times with the updated test:


==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/jdk:tier1_part1                    1027  1027     0     0
==============================
TEST SUCCESS

Finished building target 'run-test' in configuration 'linux-x64'

real	3m22.509s
user	60m15.551s
sys	2m32.574s

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

Commit messages:
 - Initial commit

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

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

From duke at openjdk.org  Wed Jul 12 09:15:28 2023
From: duke at openjdk.org (Andy-Tatman)
Date: Wed, 12 Jul 2023 09:15:28 GMT
Subject: RFR: 8305734+8311905:
 "BitSet.get(int, int) always returns the empty BitSet when the Integer.MAX
 VALUE is set" +
 "BitSet.valueOf(...) allows bitsets to be created that behave incorrectly."
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: <cPyb9XvGBjQ9L8HAkftiqFG4LRaRAfOPiPxjfUCn4sg=.58d36f0b-7b8f-42f6-86f9-68bdf13a6472@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 and https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8311905

Hi everyone,

Apologies for not being very active recently. 
I have been looking at the BitSet class for my bachelor's thesis. As part of that I, together with drs. Hans-Dieter A. Hiep & dr. Stijn de Gouw, wrote an article on the 2 bugs we discovered, namely the one in get(int,int) discussed here as well as a bug in the `valueOf(..)` methods. We found these bugs while trying to make a formal specification of the class.
As part of this, we also laid out 2 main solution directions, one allowing and one banning setting the `Integer.MAX_VALUE` bit. Both directions include a suggested fix for the `get(int,int)` method and for the `valueOf(..)` methods. 
The allowing `Int.MAX` direction would involve the change in `get(int,int)` as suggested in this PR, as well as a specification change in `valueOf(..)` as well as length().
The banning `Int.MAX` direction would involve a larger set of changes in specification, but the bug in `get(int,int)` itself would no longer be possible and so the bug fix in this PR would not be necessary. 
Following this, we also discuss pro's and con's of each approach. 

Both approaches would probably require a CSR, as the issue in the `valueOf(..)` methods is related to the specification, rather than the actual implementation, of the methods.

We look forward to hearing any thoughts you might have.
I have posted the article on Google Drive, as it has not officially been published yet: https://drive.google.com/file/d/1Ja0UHq8eLTGDKCPtbB_GWAc8D5y-krDE/view?usp=drive_link

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

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1632142207

From liach at openjdk.org  Wed Jul 12 09:57:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Jul 2023 09:57:09 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: <3WBluAotH5l16O5I4SNFqFhGfvpF_Iup4lheTp2MLRE=.feef5637-27c8-44b5-b437-7abf7d41baa7@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 and https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8311905

Fyi you can keep the pull request title to that of one issue, like
`8305734: BitSet.get(int, int) always returns the empty BitSet when the Integer.MAX VALUE is set`
and add the other issue with a pull request command (in a comment), like
`/issue add 8311905`.

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

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1632203900

From jpai at openjdk.org  Wed Jul 12 10:58:49 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jul 2023 10:58:49 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v19]
In-Reply-To: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
Message-ID: <FNS2S9_X6_XYlpurHWDDLlwuCQltQLOIEOTgZkJ27pE=.6fbd0f44-f9e4-4c70-bebf-9e200df8184e@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 45 commits:

 - move copyright before imports in the new test
 - add a new test for jlink --endian usages
 - merge latest from master branch
 - use newly introduced Architecture.byteOrder() API
 - merge latest from master branch
 - 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
 - ... and 35 more: https://git.openjdk.org/jdk/compare/753bd563...962d542d

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

Changes: https://git.openjdk.org/jdk/pull/11943/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=18
  Stats: 221 lines in 8 files changed: 181 ins; 14 del; 26 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  Wed Jul 12 10:58:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jul 2023 10:58:54 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: <NBO4c02rehtqHTGGq3gHbZwf1UeEeTZq6JlAWck5GuA=.8c1dea1a-2d0b-44f0-b443-9bece92e5ff4@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 is now ready for further reviews. I've updated it to now completely rely on the newly introduced `jdk.internal.util.Architecture` APIs instead of the jlink code relying on a `target.properties` for mapping architectures to their endianness.
Existing tests in `test/jdk/tools/jlink` continue to pass with these latest changes. I've introduced a new jtreg test `JLinkEndianTest` to verify one of the possible `--endian` option usage. We can't automate the cross-platform testing of this command, but at least this test should verify that it won't allow creation of images with a `--endian` which doesn't match the target platform's endianness.

tier testing is currently in progress.

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

PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1632283625

From jpai at openjdk.org  Wed Jul 12 11:02:10 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jul 2023 11:02:10 GMT
Subject: RFR: 8311926: java/lang/ScopedValue/StressStackOverflow.java takes
 9mins in tier1
In-Reply-To: <WRhBxjo1GoGAyyFxnzLVoN4nPOmOCe3_2rhBevgi5E8=.ba60391d-9984-4fdb-8ebf-e9b75aaa9b1f@github.com>
References: <WRhBxjo1GoGAyyFxnzLVoN4nPOmOCe3_2rhBevgi5E8=.ba60391d-9984-4fdb-8ebf-e9b75aaa9b1f@github.com>
Message-ID: <MrEDYhooLc_LAWB2srEswF3QqXRi8swAvJ49ZrO3LmY=.26268fa7-5374-479b-b186-9a6bd393122b@github.com>

On Wed, 12 Jul 2023 09:00:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The test runs 3 times, each run is for 3 minutes so 9 mins in total and too long for tier1. Here's the times for test/jdk:tier1_part1 that I see locally:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk:tier1_part1                    1025  1025     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x64'
> 
> real	10m22.414s
> user	64m1.774s
> sys	2m31.938s
> 
> 
> The test is changed to use separate test description so that the 3 runs can execute in parallel if possible. I've also dialled down the test from 3 to 2 minutes. At some point we need to tackle the issue of stress tests in tier1, this one may be a candidate for a higher tier. The exclude list for JTREG_TEST_THREAD_FACTORY=Virtual (ProblemList-Virtual.txt) is also updated to exclude the test on all platforms rather than just Linux while JDK-8309646 is being investigated.
> 
> Here are the times with the updated test:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk:tier1_part1                    1027  1027     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x64'
> 
> real	3m22.509s
> user	60m15.551s
> sys	2m32.574s

This looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14849#pullrequestreview-1526079186

From jpai at openjdk.org  Wed Jul 12 11:51:17 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jul 2023 11:51:17 GMT
Subject: RFR: 8311867: StructuredTaskScope.shutdown does not interrupt
 newly started threads
In-Reply-To: <vrfJZDSublpA2ZOXK_AfTF92D8hbzLsQRqx1Xp4HBFI=.475d09c2-7629-4d2c-b966-c2b93c4f400c@github.com>
References: <vrfJZDSublpA2ZOXK_AfTF92D8hbzLsQRqx1Xp4HBFI=.475d09c2-7629-4d2c-b966-c2b93c4f400c@github.com>
Message-ID: <PTO9YrXbEjTE3czW4awq3YrAsn7JQz7DPqQ0-gSWmY8=.eddcef89-cd03-4497-a78e-e3b85b3a09a0@github.com>

On Tue, 11 Jul 2023 17:03:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> StructuredTaskScope.shutdown can sometimes not interrupt the thread for a newly forked subtask, leading to join blocking until subtask completes. The "hang" can be duplicated with a stress test that shuts down the scope while a long running subtask is being forked. The bug is in the underlying thread flock code where it filters the threads to just the live threads and so filters out new/unstarted threads, that filtering was left over from some refactoring in the loom repo a long time ago and should have been removed.

test/jdk/java/util/concurrent/StructuredTaskScope/StressShutdown.java line 83:

> 81:             // fork subtask to shutdown
> 82:             scope.fork(() -> {
> 83:                 scope.shutdown();

Hello Alan, the proposed source change in `ThreadFlock` and the reason for that change appear good to me.
However, as far as I understand, it appears to me that this test may not be reproducing the issue where shutdown gets called when there are threads that are about to start. From what I see in the API and implementation of `scope.fork()`, when the `fork()` returns, it's guaranteed that a `Thread` for the subtask has been started (keeping aside the failed to start cases). So in this test here, when we reach this point where we attempt a `shutdown()` all 15 "beforeShutdown" subtasks would already have threads that are started and alive. i.e. there won't be any "about to be started thread". As for the 15 "afterShutdown" forks() that follow, they would already notice that the scope is shutdown and won't start the new threads.
Did I misunderstand this test?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14833#discussion_r1261060214

From jpai at openjdk.org  Wed Jul 12 12:04:12 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jul 2023 12:04:12 GMT
Subject: RFR: 8311867: StructuredTaskScope.shutdown does not interrupt
 newly started threads
In-Reply-To: <vrfJZDSublpA2ZOXK_AfTF92D8hbzLsQRqx1Xp4HBFI=.475d09c2-7629-4d2c-b966-c2b93c4f400c@github.com>
References: <vrfJZDSublpA2ZOXK_AfTF92D8hbzLsQRqx1Xp4HBFI=.475d09c2-7629-4d2c-b966-c2b93c4f400c@github.com>
Message-ID: <fl2hcUubqkBnqzpERF2A6ZDWY8vAON4SuA0b-eVeBYo=.3be7833b-b183-464a-9f8d-bd34a41129c9@github.com>

On Tue, 11 Jul 2023 17:03:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> StructuredTaskScope.shutdown can sometimes not interrupt the thread for a newly forked subtask, leading to join blocking until subtask completes. The "hang" can be duplicated with a stress test that shuts down the scope while a long running subtask is being forked. The bug is in the underlying thread flock code where it filters the threads to just the live threads and so filters out new/unstarted threads, that filtering was left over from some refactoring in the loom repo a long time ago and should have been removed.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14833#pullrequestreview-1526191301

From jpai at openjdk.org  Wed Jul 12 12:04:15 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jul 2023 12:04:15 GMT
Subject: RFR: 8311867: StructuredTaskScope.shutdown does not interrupt
 newly started threads
In-Reply-To: <oOw7R-xGZvaFHIsJ7faKBuXeJGYOTv4tgDd3Xde60Jo=.86667628-0e2d-4c25-bce3-25f6b382a349@github.com>
References: <vrfJZDSublpA2ZOXK_AfTF92D8hbzLsQRqx1Xp4HBFI=.475d09c2-7629-4d2c-b966-c2b93c4f400c@github.com>
 <PTO9YrXbEjTE3czW4awq3YrAsn7JQz7DPqQ0-gSWmY8=.eddcef89-cd03-4497-a78e-e3b85b3a09a0@github.com>
 <oOw7R-xGZvaFHIsJ7faKBuXeJGYOTv4tgDd3Xde60Jo=.86667628-0e2d-4c25-bce3-25f6b382a349@github.com>
Message-ID: <5Kc7fzThaoRnPF_J9kc-EQTPRqBcP4uEQS9AtXr6UIo=.784e1742-6d77-47ec-9032-3165751f2c9d@github.com>

On Wed, 12 Jul 2023 11:56:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/util/concurrent/StructuredTaskScope/StressShutdown.java line 83:
>> 
>>> 81:             // fork subtask to shutdown
>>> 82:             scope.fork(() -> {
>>> 83:                 scope.shutdown();
>> 
>> Hello Alan, the proposed source change in `ThreadFlock` and the reason for that change appear good to me.
>> However, as far as I understand, it appears to me that this test may not be reproducing the issue where shutdown gets called when there are threads that are about to start. From what I see in the API and implementation of `scope.fork()`, when the `fork()` returns, it's guaranteed that a `Thread` for the subtask has been started (keeping aside the failed to start cases). So in this test here, when we reach this point where we attempt a `shutdown()` all 15 "beforeShutdown" subtasks would already have threads that are started and alive. i.e. there won't be any "about to be started thread". As for the 15 "afterShutdown" forks() that follow, they would already notice that the scope is shutdown and won't start the new threads.
>> Did I misunderstand this test?
>
>> As for the 15 "afterShutdown" forks() that follow, they would already notice that the scope is shutdown and won't start the new threads.
>> Did I misunderstand this test?
> 
> The test arranges for a subtask to do shutdown, it's not done by the main task. That setups up the conditions for the shutdown to race with the subsequent forking done by the main task.

Ah! Indeed, I missed that crucial detail. So the shutdown() call itself can happen when one of the "afterShutdown" subtask is being forked and a new thread being created for it. Makes sense. Thank you for that explanation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14833#discussion_r1261073745

From alanb at openjdk.org  Wed Jul 12 12:04:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Jul 2023 12:04:14 GMT
Subject: RFR: 8311867: StructuredTaskScope.shutdown does not interrupt
 newly started threads
In-Reply-To: <PTO9YrXbEjTE3czW4awq3YrAsn7JQz7DPqQ0-gSWmY8=.eddcef89-cd03-4497-a78e-e3b85b3a09a0@github.com>
References: <vrfJZDSublpA2ZOXK_AfTF92D8hbzLsQRqx1Xp4HBFI=.475d09c2-7629-4d2c-b966-c2b93c4f400c@github.com>
 <PTO9YrXbEjTE3czW4awq3YrAsn7JQz7DPqQ0-gSWmY8=.eddcef89-cd03-4497-a78e-e3b85b3a09a0@github.com>
Message-ID: <oOw7R-xGZvaFHIsJ7faKBuXeJGYOTv4tgDd3Xde60Jo=.86667628-0e2d-4c25-bce3-25f6b382a349@github.com>

On Wed, 12 Jul 2023 11:47:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> As for the 15 "afterShutdown" forks() that follow, they would already notice that the scope is shutdown and won't start the new threads.
> Did I misunderstand this test?

The test arranges for a subtask to do shutdown, it's not done by the main task. That setups up the conditions for the shutdown to race with the subsequent forking done by the main task.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14833#discussion_r1261069364

From viktor.klang at oracle.com  Wed Jul 12 12:12:06 2023
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 12 Jul 2023 12:12:06 +0000
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: <MW4PR10MB5774FCA304105F807B1DEB46FF36A@MW4PR10MB5774.namprd10.prod.outlook.com>

Hey all,

An update after having received some great feedback?it's much appreciated!

Some concern around `unsupportedCombiner()` and `finisherNotNeeded()` was voiced,
and I thought I'd both respond to that here, and also outline alternatives.

Providing permutations of the `of`-factory accounting for stateless Gatherers (think: having their `A` type parameter be the `Void`-type), as well as optionally providing a finisher, a combiner, and a set of Characteristics results in 20+ overloads of `of`. With so many choices, I think there's a big risk that A) it will be difficult for people to find the right set of parameters, and B) it'll be hard for reviewers to know if the right operation/variant was chosen.

After having experimented with this quite a bit, I think the following trade-off might be better:

`Gatherer.of()` takes all the required parameters, and should be used for **ad-hoc** creation of Gatherer-instances.

Since it is also possible to implement the `Gatherer`-interface directly, what can be done to ease such implementations:

    - `initializer()` can have a default implementation which returns a `Supplier<T>` which always returns `null` (effectively stateless).
    - `combiner()` can have a default implementation which returns `unsupportedCombiner()` which means that operations by default are sequential-only, and by overriding `combiner()` the `Gatherer` now is parallelizable.
    - `finisher()` can have a default implementation which returns `finisherNotNeeded()` which is true if the user hasn't overridden it to do something.
    - `characteristics()` can default to the empty set of characteristics, so if none are specifically returned by an explicit override, nothing can be presumed about the nature of the `Gatherer` itself.

This approach leaves `Integrator<A,T,R>` as the single abstract method on `Gatherer` meaning that the following can be an interesting approach from a workflow perspective which I'll outline below.

Let's take a first, albeit simplistic, stab at implementing the `map`-operation as a `Gatherer`:

```java
public static <T,R> Gatherer<T,?,R> map(final Function<? super T, ? extends R> mapper) {
    Objects.requireNonNull(mapper);
    return () -> (ignore, element, downstream) -> downstream.flush(mapper.apply(element));
}
```

The above will create a `Gatherer` which has `null` as its state, is sequential-only, and has no finisher.

Now, `map` can safely be parallelized if we provide a combiner, and if we are to evolve the code above, we'd convert the lambda to an anonymous class (most IDEs support this functionality with a keystroke or two, but is trivial to do manually) which would look like this:


```java
    public static <T,R> Gatherer<T,?,R> map(final Function<? super T, ? extends R> mapper) {
        Objects.requireNonNull(mapper);
        return new Gatherer<T, Object, R>() {
            @Override
            public Integrator<Object, T, R> integrator() {
                return (ignore, element, downstream) -> downstream.flush(mapper.apply(element));
            }

            @Override
            public BinaryOperator<Object> combiner() {
                return (left, right) -> null;
            }
        };
    }
```

Now, let's say that we don't want to potentially allocate a new `Integrator`-instance for each invocation of `integrator()` we can have our `Gatherer` implement `Integrator` and return itself?this requires us to move from an anonymous inner class to a named inner class:

```java
    public static <T,R> Gatherer<T,?,R> map(final Function<? super T, ? extends R> mapper) {
        Objects.requireNonNull(mapper);
        class Impl implements Gatherer<T, Void, R>, Integrator<Void, T, R> {
            @Override
            public Integrator<Void, T, R> integrator() {
                return this;
            }

            @Override
            public boolean integrate(Void ignore, T element, Sink<? super R> downstream) {
                return downstream.flush(mapper.apply(element));
            }

            @Override
            public BinaryOperator<Void> combiner() {
                return (left, right) -> null;
            }
        }
        return new Impl();
    }
```

Then we realize that our `Gatherer` is both `STATELESS`, `SIZE_PRESERVING`, and `GREEDY`, so we specify that as `Characteristics` so that the runtime can optimize accordingly:

```java
    public static <T,R> Gatherer<T,?,R> map(final Function<? super T, ? extends R> mapper) {
        Objects.requireNonNull(mapper);
        class Impl implements Gatherer<T, Void, R>, Integrator<Void, T, R> {
            final static Set<Characteristics> CHARACTERISTICS =
                    Set.of(Characteristics.STATELESS,
                           Characteristics.GREEDY,
                           Characteristics.SIZE_PRESERVING);

            @Override
            public boolean integrate(Void ignore, T element, Sink<? super R> downstream) {
                return downstream.flush(mapper.apply(element));
            }

            @Override
            public Integrator<Void, T, R> integrator() {
                return this;
            }

            @Override
            public BinaryOperator<Void> combiner() {
                return (left, right) -> null;
            }

            @Override
            public Set<Characteristics> characteristics() {
                return CHARACTERISTICS;
            }
        }
        return new Impl();
    }
```

The equivalent code using the `Gatherer.of()`-factory method would look something like:

```java
    public static <T,R> Gatherer<T,?,R> map(final Function<? super T, ? extends R> mapper) {
        Objects.requireNonNull(mapper);
        return Gatherer.of(
                () -> (Void)null,
                (ignore, element, downstream) -> downstream.flush(mapper.apply(element)),
                (left, right) -> left,
                Gatherer.finisherNotNeeded(),
                Characteristics.STATELESS, Characteristics.GREEDY, Characteristics.SIZE_PRESERVING
        );
    }
```

What we could introduce to make the aforementioned a bit cleaner, would be to introduce an `initializerNotNeeded()` so that it could look like this:

```java
    public static <T,R> Gatherer<T,?,R> map(final Function<? super T, ? extends R> mapper) {
        Objects.requireNonNull(mapper);
        return Gatherer.of(
                Gatherer.initializerNotNeeded(),
                (ignore, element, downstream) -> downstream.flush(mapper.apply(element)),
                (left, right) -> left,
                Gatherer.finisherNotNeeded(),
                Characteristics.STATELESS, Characteristics.GREEDY, Characteristics.SIZE_PRESERVING
        );
    }
```

With a bit of static imports, it can look like this:

```java
    public static <T,R> Gatherer<T,?,R> map(final Function<? super T, ? extends R> mapper) {
        Objects.requireNonNull(mapper);
        return Gatherer.of(
                initializerNotNeeded(),
                (ignore, element, downstream) -> downstream.flush(mapper.apply(element)),
                (left, right) -> left,
                finisherNotNeeded(),
                STATELESS, GREEDY, SIZE_PRESERVING
        );
    }
```

While the above is semantically equivalent to:

```java
public static <T,R> Gatherer<T,?,R> map(final Function<? super T, ? extends R> mapper) {
    Objects.requireNonNull(mapper);
    return () -> (ignore, element, downstream) -> downstream.flush(mapper.apply(element));
}
```

The version using `Gatherer.of` enables parallel execution when running in a parallel stream, and it also gives more hints to the runtime?making it more likely that it will have better performance than the SAM-version.

Now, the point is not that `map` is something which needs reimplementation, but rather it serves as a well-understood intermediate operation where we can focus on the ergonomics of `Gatherer` rather than the operation itself.

Let me know what you think about providing `default`-implementations of everything sans `integrator()` (making `Gatherer` a SAM) as an alternative to having to provide 20+ overloads of `of()`.

Cheers,
?

________________________________
From: Viktor Klang
Sent: Tuesday, 27 June 2023 19:10
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
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?

(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/20230712/c732f8f9/attachment-0001.htm>

From duke at openjdk.org  Wed Jul 12 12:55:34 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 12 Jul 2023 12:55:34 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base
Message-ID: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>

Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.

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

Commit messages:
 - Update DateTimeFormatterBuilder
 - Avoid locale-sensitive case conversions in java.base

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

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

From jpai at openjdk.org  Wed Jul 12 12:55:34 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jul 2023 12:55:34 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base
In-Reply-To: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
Message-ID: <nx1fOnnGD7eHw-oJEt1vD7Y99rmInjK-v7F7JbxdFSg=.1fcd91d8-170f-4738-9ffd-d95a2e4b21b9@github.com>

On Mon, 3 Jul 2023 20:53:34 GMT, Glavo <duke at openjdk.org> wrote:

> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.

Hello Glavo, I've created https://bugs.openjdk.org/browse/JDK-8311943 to track this change. Please update the title to this PR to `8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base` so that it triggers the official RFR.

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

PR Comment: https://git.openjdk.org/jdk/pull/14763#issuecomment-1632426553

From alanb at openjdk.org  Wed Jul 12 13:29:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Jul 2023 13:29:11 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base
In-Reply-To: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
Message-ID: <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>

On Mon, 3 Jul 2023 20:53:34 GMT, Glavo <duke at openjdk.org> wrote:

> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.

src/java.base/share/classes/java/io/StreamTokenizer.java line 632:

> 630:             sval = String.copyValueOf(buf, 0, i);
> 631:             if (forceLower)
> 632:                 sval = sval.toLowerCase(Locale.ROOT);

I suspect this change to StreamTokenizer needs eyes. I think long standing behavior of the lowerCaseMode(true) has been to use the rules for the default locale so we need to be careful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1261178834

From duke at openjdk.org  Wed Jul 12 14:35:16 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 12 Jul 2023 14:35:16 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base
In-Reply-To: <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>
Message-ID: <qNfFCDiE8DYJna7MXp77UnasD8Vg3iU6HBm5c4KVgu0=.0be8245d-3ff2-43b6-bd79-a258569013ad@github.com>

On Wed, 12 Jul 2023 13:26:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I suspect this change to StreamTokenizer needs eyes. I think long standing behavior of the lowerCaseMode(true) has been to use the rules for the default locale so we need to be careful.

I investigated some usage of this method on GitHub:

https://github.com/search?q=%22lowerCaseMode%28true%29%22+language%3AJava&type=code

In the use cases I see, it seems that no one wants to rely on the default locale.

However, while I think this corrects the behavior, this caused a change in the behavior of the API, so a CSR may be required. I don't want to debate this in this PR, so I'll revert this change and open a new PR in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1261271535

From rriggs at openjdk.org  Wed Jul 12 14:43:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Jul 2023 14:43:19 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v19]
In-Reply-To: <FNS2S9_X6_XYlpurHWDDLlwuCQltQLOIEOTgZkJ27pE=.6fbd0f44-f9e4-4c70-bebf-9e200df8184e@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <FNS2S9_X6_XYlpurHWDDLlwuCQltQLOIEOTgZkJ27pE=.6fbd0f44-f9e4-4c70-bebf-9e200df8184e@github.com>
Message-ID: <n7Pe7-OBLTUY63IhftXTdrnqRYC2P9WbSi-Y8X8aI6c=.6bfb6f90-0ffe-4801-9aef-f784517f9d29@github.com>

On Wed, 12 Jul 2023 10:58:49 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 45 commits:
> 
>  - move copyright before imports in the new test
>  - add a new test for jlink --endian usages
>  - merge latest from master branch
>  - use newly introduced Architecture.byteOrder() API
>  - merge latest from master branch
>  - 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
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/753bd563...962d542d

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 846:

> 844:                 String targetPlatformVal = readJavaBaseTargetPlatform(cf);
> 845:                 try {
> 846:                     return Platform.parsePlatform(targetPlatformVal);

You may want to modify `Platform.parsePlatform(s)` to use `Architecture.lookupByName(s)` instead of doing the alias mapping itself.  Platform.java:53-56.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1261280929

From duke at openjdk.org  Wed Jul 12 15:06:36 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 12 Jul 2023 15:06:36 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base [v2]
In-Reply-To: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
Message-ID: <8j9x5j5Gw_A5Oz1yKloOUaYOIOCUqGxIT_7U9UsnQDE=.7591e55d-c111-4c43-b82a-5f0252019b62@github.com>

> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.

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

  Revert StreamTokenizer.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14763/files
  - new: https://git.openjdk.org/jdk/pull/14763/files/944acdc4..8b8957f5

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

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

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

From alanb at openjdk.org  Wed Jul 12 15:48:24 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Jul 2023 15:48:24 GMT
Subject: Integrated: 8311926: java/lang/ScopedValue/StressStackOverflow.java
 takes 9mins in tier1
In-Reply-To: <WRhBxjo1GoGAyyFxnzLVoN4nPOmOCe3_2rhBevgi5E8=.ba60391d-9984-4fdb-8ebf-e9b75aaa9b1f@github.com>
References: <WRhBxjo1GoGAyyFxnzLVoN4nPOmOCe3_2rhBevgi5E8=.ba60391d-9984-4fdb-8ebf-e9b75aaa9b1f@github.com>
Message-ID: <0Da-zpLALyQIjcqLShX4X6I70x_el6S6aFRSOz-w0_U=.311ddb70-2c7c-404e-9b47-9eb0d9346f06@github.com>

On Wed, 12 Jul 2023 09:00:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The test runs 3 times, each run is for 3 minutes so 9 mins in total and too long for tier1. Here's the times for test/jdk:tier1_part1 that I see locally:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk:tier1_part1                    1025  1025     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x64'
> 
> real	10m22.414s
> user	64m1.774s
> sys	2m31.938s
> 
> 
> The test is changed to use separate test description so that the 3 runs can execute in parallel if possible. I've also dialled down the test from 3 to 2 minutes. At some point we need to tackle the issue of stress tests in tier1, this one may be a candidate for a higher tier. The exclude list for JTREG_TEST_THREAD_FACTORY=Virtual (ProblemList-Virtual.txt) is also updated to exclude the test on all platforms rather than just Linux while JDK-8309646 is being investigated.
> 
> Here are the times with the updated test:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk:tier1_part1                    1027  1027     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x64'
> 
> real	3m22.509s
> user	60m15.551s
> sys	2m32.574s

This pull request has now been integrated.

Changeset: 7304316a
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7304316a8c55a4c0f2a96d1b99ba9e97e49ed7f4
Stats:     20 lines in 2 files changed: 14 ins; 1 del; 5 mod

8311926: java/lang/ScopedValue/StressStackOverflow.java takes 9mins in tier1

Reviewed-by: jpai

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

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

From uschindler at openjdk.org  Wed Jul 12 16:08:17 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Wed, 12 Jul 2023 16:08:17 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base [v2]
In-Reply-To: <qNfFCDiE8DYJna7MXp77UnasD8Vg3iU6HBm5c4KVgu0=.0be8245d-3ff2-43b6-bd79-a258569013ad@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>
 <qNfFCDiE8DYJna7MXp77UnasD8Vg3iU6HBm5c4KVgu0=.0be8245d-3ff2-43b6-bd79-a258569013ad@github.com>
Message-ID: <wcIqS-Z73fwLZICL2uhFveTBVYMYO2dtanzNtfm6PFA=.18624ed6-39fb-4b69-b777-7c293816d974@github.com>

On Wed, 12 Jul 2023 14:31:53 GMT, Glavo <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/StreamTokenizer.java line 632:
>> 
>>> 630:             sval = String.copyValueOf(buf, 0, i);
>>> 631:             if (forceLower)
>>> 632:                 sval = sval.toLowerCase(Locale.ROOT);
>> 
>> I suspect this change to StreamTokenizer needs eyes. I think long standing behavior of the lowerCaseMode(true) has been to use the rules for the default locale so we need to be careful.
>
>> I suspect this change to StreamTokenizer needs eyes. I think long standing behavior of the lowerCaseMode(true) has been to use the rules for the default locale so we need to be careful.
> 
> I investigated usage of this method on GitHub:
> 
> https://github.com/search?q=%22lowerCaseMode%28true%29%22+language%3AJava&type=code
> 
> In some of the use cases I investigated, it seems that no one wants to rely on the default locale.
> 
> However, while I think this corrects the behavior, this caused a change in the behavior of the API, so a CSR may be required. I don't want to debate this in this PR, so I'll revert this change and open a new PR in the future.

Maybe a small suggestion to make it clear whats wanted here. In other projects I am involved in (Apache Lucene/Solr, Apache TIKA, PostgresSQL JDBC, Checkstyle itsself, Elasticserach/Opensearch), which use the [forbiddenapis Maven/Gradle/Ant plugin](https://github.com/policeman-tools/forbidden-apis/), we forbid all calls to several Java APIs (including toLowerCase/toUpperCase case). All bytecode using this will build failure (FYI, we also disallow other stuff like relying of default timezone or characterset).
To make it clear what is really intended, those projects agreed on having `toLowerCase(Locale.getDefault())`, so it is explicit what's wanted.
Without that it could be that somebody else starts the discussion again.

This is just a suggestion to be explicit as it makes maintaining the code easier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1261404900

From smarks at openjdk.org  Wed Jul 12 16:14:31 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 12 Jul 2023 16:14:31 GMT
Subject: Integrated: 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: <bVVsYbiOSV21jYpfVHMC_LQT91iV1uy5Mlw-RH72Q94=.697f55eb-b8b4-4909-8ed8-5b4fd2d9269a@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.

This pull request has now been integrated.

Changeset: f82c8184
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f82c8184b26142da4018ae096cfa39d87a4c6540
Stats:     32 lines in 4 files changed: 24 ins; 0 del; 8 mod

8308694: Clarify reversed() default methods' implementation requirements

Reviewed-by: rriggs

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

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

From duke at openjdk.org  Wed Jul 12 16:22:15 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 12 Jul 2023 16:22:15 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base [v2]
In-Reply-To: <wcIqS-Z73fwLZICL2uhFveTBVYMYO2dtanzNtfm6PFA=.18624ed6-39fb-4b69-b777-7c293816d974@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>
 <qNfFCDiE8DYJna7MXp77UnasD8Vg3iU6HBm5c4KVgu0=.0be8245d-3ff2-43b6-bd79-a258569013ad@github.com>
 <wcIqS-Z73fwLZICL2uhFveTBVYMYO2dtanzNtfm6PFA=.18624ed6-39fb-4b69-b777-7c293816d974@github.com>
Message-ID: <Lb7gqaFf_SOuR4pXtDc-Nv5HvoITkO2KwvFfKAaZmyg=.6cbdf125-b849-49cc-912b-e6878afafd88@github.com>

On Wed, 12 Jul 2023 16:05:03 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

> Maybe a small suggestion to make it clear whats wanted here. In other projects I am involved in (Apache Lucene/Solr, Apache TIKA, PostgresSQL JDBC, Checkstyle itsself, Elasticserach/Opensearch), which use the [forbiddenapis Maven/Gradle/Ant plugin](https://github.com/policeman-tools/forbidden-apis/), we forbid all calls to several Java APIs (including toLowerCase/toUpperCase case). All bytecode using this will build failure (FYI, we also disallow other stuff like relying of default timezone or characterset). To make it clear what is really intended, those projects agreed on having `toLowerCase(Locale.getDefault())`, so it is explicit what's wanted. Without that it could be that somebody else starts the discussion again.
> 
> This is just a suggestion to be explicit as it makes maintaining the code easier.

I agree with this.

I'm working on deprecating `toLowerCase()` and `toUpperCase()`, this PR is part of that effort. I wish to convert all use cases of them to `toLowerCase(Locale)` and `toUpperCase(Locale)`.

More backstory is detailed in https://github.com/openjdk/jdk/pull/13434#issuecomment-1503989660.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1261421937

From duke at openjdk.org  Wed Jul 12 16:26:59 2023
From: duke at openjdk.org (Benjamin Marwell)
Date: Wed, 12 Jul 2023 16:26:59 GMT
Subject: RFR: 8305947: SequenceInputStream implementation can use an
 Iterator rather than Enumeration
In-Reply-To: <FrSt-VBQqsi0UfENhLyGQNEjTtjtRkcoshYbpcLRLO4=.869a26e1-2032-47b3-abc6-cd5b843100d7@github.com>
References: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>
 <FrSt-VBQqsi0UfENhLyGQNEjTtjtRkcoshYbpcLRLO4=.869a26e1-2032-47b3-abc6-cd5b843100d7@github.com>
Message-ID: <RIQDPVYTi9Dqzjp7RCO9Si3dqz0bfaOu9xDWsqEdPHU=.cd26cffa-e6bb-44bd-aee7-b3b5df1c2a49@github.com>

On Fri, 9 Jun 2023 15:49:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> 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).

Thanks, will put it on the mailing list.

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

PR Comment: https://git.openjdk.org/jdk/pull/11718#issuecomment-1632848128

From duke at openjdk.org  Wed Jul 12 18:11:28 2023
From: duke at openjdk.org (iaroslavski)
Date: Wed, 12 Jul 2023 18:11:28 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: <3M3Xd4w_-Xz9SHjF8kUg_yzPUUI01iF3NWzKu95VRGM=.717291ca-eb55-4d87-9640-5df832960c56@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-1632989652

From bpb at openjdk.org  Wed Jul 12 18:18:25 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 12 Jul 2023 18:18:25 GMT
Subject: Integrated: 8155902: DataOuputStream should clarify that it might
 write primitive types as multiple byte groups
In-Reply-To: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
References: <58LVayUle16cq_O21X9xd-43eY2Tntnxl1QNNFaAD3k=.d8ef1f3f-3f78-4765-93ba-c0ee808ae5a5@github.com>
Message-ID: <ePN3PY4kXPmu06bPunrTOk7ecGE-s5zFkFRwRRR2_G8=.3ef1cf58-f80b-42fb-870f-69b9dbec223b@github.com>

On Thu, 6 Jul 2023 21:40:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no guarantee as to how the underlying output stream actually writes the bytes provided to it.

This pull request has now been integrated.

Changeset: ed9337e6
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed9337e6656e9f2f6d891deb26495a79324d37c6
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8155902: DataOuputStream should clarify that it might write primitive types as multiple byte groups

Reviewed-by: alanb, djelinski, lancea, rriggs

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

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

From smarks at openjdk.org  Wed Jul 12 18:29:27 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 12 Jul 2023 18:29:27 GMT
Subject: [jdk21] RFR: 8308694: Clarify reversed() default methods'
 implementation requirements
Message-ID: <iMnL88T2MrI-7mXpIm-X9oGYSP5Grw43pmLQ5SEiPOs=.fab37854-5097-4792-a930-651be983b2fd@github.com>

Hi all,

This pull request contains a backport of commit [f82c8184](https://github.com/openjdk/jdk/commit/f82c8184b26142da4018ae096cfa39d87a4c6540) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Stuart Marks on 12 Jul 2023 and was reviewed by Roger Riggs.

Thanks!

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

Commit messages:
 - Backport f82c8184b26142da4018ae096cfa39d87a4c6540

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

PR: https://git.openjdk.org/jdk21/pull/115

From mchung at openjdk.org  Wed Jul 12 19:52:27 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 12 Jul 2023 19:52:27 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v19]
In-Reply-To: <FNS2S9_X6_XYlpurHWDDLlwuCQltQLOIEOTgZkJ27pE=.6fbd0f44-f9e4-4c70-bebf-9e200df8184e@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <FNS2S9_X6_XYlpurHWDDLlwuCQltQLOIEOTgZkJ27pE=.6fbd0f44-f9e4-4c70-bebf-9e200df8184e@github.com>
Message-ID: <vQGGPSnWOg2Pi56-KmKqHBY2PU3l1QfTr6OV6-1OZSU=.36185ab9-9b4d-432e-bf35-409d45c272e4@github.com>

On Wed, 12 Jul 2023 10:58:49 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 45 commits:
> 
>  - move copyright before imports in the new test
>  - add a new test for jlink --endian usages
>  - merge latest from master branch
>  - use newly introduced Architecture.byteOrder() API
>  - merge latest from master branch
>  - 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
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/753bd563...962d542d

Looks okay with a suggestion to determine the endianness outside `ImageHelper`.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Jlink.java line 168:

> 166:             this.output = output;
> 167:             this.modules = Objects.requireNonNull(modules);
> 168:             this.endian = endian;

`JlinkConfiguration` does not need to know the endianness.   Only the image builder needs it.   Probably good to take the `endian` parameter out from `JlinkConfiguration` and instead pass the value of `--endian` to `JlinkTask::createImageProvider` like other jlink options.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 412:

> 410: 
> 411:         // First create the image provider
> 412:         ImageHelper imageProvider = createImageProvider(config,

formatting nit: line 413-415 should be adjusted to align the parameters.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 568:

> 566:         Map<String, Path> mods = cf.modules().stream()
> 567:             .collect(Collectors.toMap(ResolvedModule::name, JlinkTask::toPathLocation));
> 568:         return new ImageHelper(cf, mods, config.getByteOrder(), retainModulesPath, ignoreSigning,

Also we can move the logic of determining the endianess of the target platform out of `ImageHelper`.   Evaluate the target platform and endianness here and pass to `ImageHelper`.

Suggestion:

        // endian is the value specified via --endian and a new parameter to createImageProvider 
        Platform targetPlatform = targetPlatform(cf, modsPaths);
        ByteOrder targetOrder = endian != null ? endian : targetPlatform.arch().byteOrder();
        return new ImageHelper(cf, mods, targetOrder, retainModulesPath, ignoreSigning,

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 856:

> 854:         // returns true if the current platform's "jmods" directory is the parent of the
> 855:         // passed javaBasePath
> 856:         private static boolean isJavaBaseFromCurrentPlatform(Path javaBasePath) throws IOException {

This method checks if we are jlinking the JMOD files from the default module path.   This is not exactly checking if `java.base` matches the current platform since there are other possible setups too.    Suggest to rename the method name to `isJavaBaseFromDefaultModulePath`.   So the comments should also be updated to reflect that.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 857:

> 855:         // passed javaBasePath
> 856:         private static boolean isJavaBaseFromCurrentPlatform(Path javaBasePath) throws IOException {
> 857:             Path currentPlatformJmods = getDefaultModulePath();

Suggestion:

            Path defaultModulePath = getDefaultModulePath();

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

PR Review: https://git.openjdk.org/jdk/pull/11943#pullrequestreview-1527094883
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1261636015
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1261642743
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1261654437
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1261639546
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1261640202

From naoto at openjdk.org  Wed Jul 12 21:50:17 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Jul 2023 21:50:17 GMT
Subject: [jdk21] RFR: 8308694: Clarify reversed() default methods'
 implementation requirements
In-Reply-To: <iMnL88T2MrI-7mXpIm-X9oGYSP5Grw43pmLQ5SEiPOs=.fab37854-5097-4792-a930-651be983b2fd@github.com>
References: <iMnL88T2MrI-7mXpIm-X9oGYSP5Grw43pmLQ5SEiPOs=.fab37854-5097-4792-a930-651be983b2fd@github.com>
Message-ID: <W_elLxMzETWi_LNeY6Vk9SaByBm7xGl82R1One2DR0M=.7bd785f2-9081-4ced-a632-abbadd41b97c@github.com>

On Wed, 12 Jul 2023 18:21:29 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f82c8184](https://github.com/openjdk/jdk/commit/f82c8184b26142da4018ae096cfa39d87a4c6540) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Stuart Marks on 12 Jul 2023 and was reviewed by Roger Riggs.
> 
> Thanks!

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/115#pullrequestreview-1527278010

From bpb at openjdk.org  Wed Jul 12 21:54:17 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 12 Jul 2023 21:54:17 GMT
Subject: [jdk21] RFR: 8308694: Clarify reversed() default methods'
 implementation requirements
In-Reply-To: <iMnL88T2MrI-7mXpIm-X9oGYSP5Grw43pmLQ5SEiPOs=.fab37854-5097-4792-a930-651be983b2fd@github.com>
References: <iMnL88T2MrI-7mXpIm-X9oGYSP5Grw43pmLQ5SEiPOs=.fab37854-5097-4792-a930-651be983b2fd@github.com>
Message-ID: <K1Mrqbh37iVSResTwnlXX0ycqP3yKEboKsI3U6e-XaA=.51df9c62-562b-4dd4-a4c3-e577b459601c@github.com>

On Wed, 12 Jul 2023 18:21:29 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f82c8184](https://github.com/openjdk/jdk/commit/f82c8184b26142da4018ae096cfa39d87a4c6540) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Stuart Marks on 12 Jul 2023 and was reviewed by Roger Riggs.
> 
> Thanks!

+1

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/115#pullrequestreview-1527285450

From jrose at openjdk.org  Wed Jul 12 22:29:13 2023
From: jrose at openjdk.org (John R Rose)
Date: Wed, 12 Jul 2023 22:29:13 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v4]
In-Reply-To: <r4-dPyuclFOYil8WAkurSA0wlwSF7wlugZX8LDa2qrE=.f7cde5c3-5882-4511-8548-10dea66522c5@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
 <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
 <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
 <tB0gdwb1wJsxS3sn9FmNwvj_2HOmm6N7WBysURUYoPM=.25f1b2f6-ea63-4022-b451-aa93eb57c04b@github.com>
 <r4-dPyuclFOYil8WAkurSA0wlwSF7wlugZX8LDa2qrE=.f7cde5c3-5882-4511-8548-10dea66522c5@github.com>
Message-ID: <9yQuD4s56Jx6Ks4ORj_mGSEIPOGg2YE9lua0uzhJJgs=.1f7b4918-88b9-4246-90b1-18c463cbbafb@github.com>

On Fri, 7 Jul 2023 00:39:20 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Thanks @rose00 for the writeup and @pavelrappo for asking pertinent followup questions.
>> 
>> For me the issue here is that there is a bunch of lore about avoiding `Objects::equals` and it's embodied in comments like this:
>> 
>>> NB: Do not replace with Object.equals until JDK-8015417 is resolved. 
>> 
>> These comments are almost exactly ten years old, and we can't seem to find any evidence showing that a slowdown occurred if `Objects::equals` were used. The comments are a "dead hand" at this point. Is there a way to demonstrate whether there is or is not any difference when using `Objects::equals`?
>> 
>> As a side note, I observe that the `eq` method in Collections.java and AbstractMap.java does this:
>> 
>>     return o1 == null ? o2 == null : o1.equals(o2);
>> 
>> whereas `Objects::equals` will test `o1 == o2` and skip the `equals()` call if the references are non-null and equals. This might confound the comparison a bit.
>
>> For me the issue here is that there is a bunch of lore about avoiding `Objects::equals` and it's embodied in comments like this:
>> 
>> > NB: Do not replace with Object.equals until JDK-8015417 is resolved.
>> 
>> These comments are almost exactly ten years old, and we can't seem to find any evidence showing that a slowdown occurred if `Objects::equals` were used. The comments are a "dead hand" at this point. Is there a way to demonstrate whether there is or is not any difference when using `Objects::equals`?
> 
> Agree on all of the above; this is "rumor control".

@pavelrappo

> Let's further test that model by checking its predictions.
> 
> ?Which means that in this case, we can reasonably refactor that `equals` as follows:
>    ```
>     public boolean equals(Object o) {
>         return o instanceof Map.Entry<?, ?> e
>                 && Objects.equals(key, e.getKey())
>                 && Objects.equals(value, e.getValue());
>     }
>    ```

Yes, I believe that is so.  Discounting (probably polluted) profile effects, it is no better and no worse to have your own helper `eq` or use the one in `Objects`.

>      
>    Similar reasoning could be applied to that same class' `hashCode`, to refactor it from this:
>    ```
>     public int hashCode() {
>         return (key   == null ? 0 :   key.hashCode()) ^
>                (value == null ? 0 : value.hashCode());
>     }
>    ```
>      
>    to this:
>    ```
>     public int hashCode() {
>         return (Objects.hashCode(key)) ^
>                (Objects.hashCode(value));
>     }
>    ```

Correct.

>    Unlike the previous example, however, where we trade one inlining for another, here we might lose the first layer of inlining. But assuming that `Objects.hashCode` is relatively small and additionally might get annotated with `@ForceInline` as a result of this discussion later on, it will be inlined.

Correct.

> 2. Consider an opposite example?
>      
>    Would it be reasonable to change `hashCode` like this?
>    ```
>     public int hashCode() {
>         int value = m << 5;
>         value += Objects.hashCode(rp);
>         // no need to involve ks here since ks and rp
>         // should be equivalent.
>         return value;
>     }
>    ```

Yes, it would be, because `rp` has a statically observable type, `BigInteger`.  And that observation will flow across the call to the helper method.

>    Firstly, we lose inlining.

I don?t get that; I?d rather say ?we assume the helper is inlined?.  Or are you talking about the hoped-for inlining of `recv.hashCode()`?  That works as long as a good-enough type of `recv` (`rp` or the formal to the helper) is observable.  In this case `BigInteger` is good.  If this were generic code and `rp` were `Object` then that would be not so good.

> Secondly, the fact that `rp` is `BigInteger` is no longer immediately available to the actual hash code computation. Assuming that `java.util.Objects.hashCode` will be inlined at runtime, and given enough invocations, it will be profiled and subjected to class hierarchy analysis (CHA), which in the absence of `BigInteger.hashCode` overrides will hopefully determine that the call could be further inlined.

This is mostly correct, except that we rely on the static type of `rp`, smuggled across the inlining barrier.  There is no need for profiling.  Indeed, it is rare for a profiled type to be used for CHA; that is mainly for statically observed types.

@stuart-marks

> These comments are almost exactly ten years old, and we can't seem to find any evidence showing that a slowdown occurred if `Objects::equals` were used. The comments are a ?dead hand? at this point. Is there a way to demonstrate whether there is or is not any difference when using `Objects::equals`?

(Ooh: The Mortmain Strikes Back!  I guess I scared somebody a decade ago.  Better get this sorted?)

I think we should mark these helpers `@ForceInline` and then take what winnings we can get from them.  That means either refactoring all candidate sites in the JDK to use the helpers, or refactoring all but those which are risky.

We need a risk assessment in either case, because even if we refactor everything we will have to be ready to fix performance outages (if significant) by either recoding or adding a touch more profiling into the JVM.  Just a touch; it can be focused on just these helpers, if they are made intrinsics.

(Definitions: The ?receiver? is the reference that will get the call to the `Object` method.  As it happens it is always the lead argument to the helper.  A ?usefully restrictive? type is one for which the eventual virtual method call will reach exactly one method.  Every `final` class is a usefully restrictive type, almost every interface is not usefully restrictive.)

Here are less risky use cases:

 - The receiver in the use case is statically typed to a usefully restrictive type
 - The dynamic type of the receiver is variable and can take on many values.

In the first case, inlining the helper will provide the JIT all the information it needs to devirtualize and inline the method it calls.

In the second case, we give up hope that the JIT will inline the method, whether or not we perform the refactorization.

The more risky use cases are all others:

 - The dynamic type of the receiver takes only one or two values, even if its type is not usefully restrictive.

This can happen with generic code, but mainly in microbenchmarks, which are artificially small programs.  At scale most generic code is multi-purpose, which means the values that flow through them have many dynamic types.  So I think refactoring inside widely-used generic code is safe, not risky.  Beware making policy here only with microbenchmarks.

In risky cases like this, the JVM?s profiling machinery captures useful information on the receiver at the use site, information that would be absent after refactoring the virtual call inside the helper method.  This can and should be fixed by targeted profiling on the arguments of exactly those helpers.

I think it is hard to find the risky cases.

(We can generalize this later as well, and HotSpot already has a flag for that.  I think setting `TypeProfileLevel` to 112 instead of its current default 111 would fix the helpers, and many other problems as well.  But it would have an unpredictable effect on startup and footprint.  Targeting it to just our special helpers is likely to have no adverse effects.)

The above discussion applies to both `equals` and `hashCode`.  For `equals` there is a secondary effect from type observations on the second argument, but it only matters if we are already winning and inlining the virtual method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1261783207

From duke at openjdk.org  Wed Jul 12 22:38:24 2023
From: duke at openjdk.org (duke)
Date: Wed, 12 Jul 2023 22:38:24 GMT
Subject: Withdrawn: 8302818: Optimize wrapper sets and immutable sets of Enums
In-Reply-To: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
References: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
Message-ID: <kkMR4LuTAN0B-KkLwICSkadILBP7RdAmpHI05hX2vgI=.147886c3-4988-466b-a078-edc8a94a0a2d@github.com>

On Thu, 9 Feb 2023 16:20:31 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
> 
> This PR introduces optimization classes for these situations.  No public APIs are changed.

This pull request has been closed without being integrated.

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

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

From smarks at openjdk.org  Wed Jul 12 23:02:13 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 12 Jul 2023 23:02:13 GMT
Subject: [jdk21] Integrated: 8308694: Clarify reversed() default methods'
 implementation requirements
In-Reply-To: <iMnL88T2MrI-7mXpIm-X9oGYSP5Grw43pmLQ5SEiPOs=.fab37854-5097-4792-a930-651be983b2fd@github.com>
References: <iMnL88T2MrI-7mXpIm-X9oGYSP5Grw43pmLQ5SEiPOs=.fab37854-5097-4792-a930-651be983b2fd@github.com>
Message-ID: <ZEXRsQ3L9lI2h4wSzI2K5seN12H0pYB0nYQ0_rTXgDg=.dc2cde1b-b008-4675-98df-c6d3be5c38f6@github.com>

On Wed, 12 Jul 2023 18:21:29 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f82c8184](https://github.com/openjdk/jdk/commit/f82c8184b26142da4018ae096cfa39d87a4c6540) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Stuart Marks on 12 Jul 2023 and was reviewed by Roger Riggs.
> 
> Thanks!

This pull request has now been integrated.

Changeset: f6ad56bc
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/f6ad56bcbcfee3ee2db7dfb14f817c0a7bf18279
Stats:     32 lines in 4 files changed: 24 ins; 0 del; 8 mod

8308694: Clarify reversed() default methods' implementation requirements

Reviewed-by: naoto, bpb
Backport-of: f82c8184b26142da4018ae096cfa39d87a4c6540

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

PR: https://git.openjdk.org/jdk21/pull/115

From smarks at openjdk.org  Wed Jul 12 23:24:28 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 12 Jul 2023 23:24:28 GMT
Subject: RFR: 8306785: fix deficient spliterators for Sequenced Collections
Message-ID: <DBT3pVrG4anlneVSMG_RkcjbAtpx8IV9YCVjEtl5KkI=.d29dffd7-3b36-4373-8506-bfab305a3b39@github.com>

Change some reverse-ordered spliterators to use `Spliterators.spliterator(Collection, ORDERED)` instead of `Spliterators.spliteratorUnknownSize()`. This gives SIZED and ORDERED spliterators. More optimizations will be done later. I'm intending to backport this to JDK 21 so I want this to be minimal.

I've also included some adjustments to spliterator implementation comments to clear up a few points of confusion. (No spec changes.)

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

Commit messages:
 - Update some Spliterator comments; change default views to use spliterator(Collection).

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

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

From smarks at openjdk.org  Wed Jul 12 23:24:28 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 12 Jul 2023 23:24:28 GMT
Subject: RFR: 8306785: fix deficient spliterators for Sequenced Collections
In-Reply-To: <DBT3pVrG4anlneVSMG_RkcjbAtpx8IV9YCVjEtl5KkI=.d29dffd7-3b36-4373-8506-bfab305a3b39@github.com>
References: <DBT3pVrG4anlneVSMG_RkcjbAtpx8IV9YCVjEtl5KkI=.d29dffd7-3b36-4373-8506-bfab305a3b39@github.com>
Message-ID: <OWv88k01wHXw2DHalNkOIJuwwJAgeT-p0-LiBTU9_nc=.511d0233-fb47-41e6-a08e-de576bcb41c6@github.com>

On Wed, 12 Jul 2023 17:25:03 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Change some reverse-ordered spliterators to use `Spliterators.spliterator(Collection, ORDERED)` instead of `Spliterators.spliteratorUnknownSize()`. This gives SIZED and ORDERED spliterators. More optimizations will be done later. I'm intending to backport this to JDK 21 so I want this to be minimal.
> 
> I've also included some adjustments to spliterator implementation comments to clear up a few points of confusion. (No spec changes.)

@PaulSandoz I'd appreciate your thoughts on the comment changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/14854#issuecomment-1633324874

From psandoz at openjdk.org  Wed Jul 12 23:41:01 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 12 Jul 2023 23:41:01 GMT
Subject: RFR: 8306785: fix deficient spliterators for Sequenced Collections
In-Reply-To: <DBT3pVrG4anlneVSMG_RkcjbAtpx8IV9YCVjEtl5KkI=.d29dffd7-3b36-4373-8506-bfab305a3b39@github.com>
References: <DBT3pVrG4anlneVSMG_RkcjbAtpx8IV9YCVjEtl5KkI=.d29dffd7-3b36-4373-8506-bfab305a3b39@github.com>
Message-ID: <Qa-rIKRDUp8a-qCYeMXNp_ULErO7zS4b5wsS3uKkvgI=.14e51811-ae84-448c-af1e-b2c5542565f4@github.com>

On Wed, 12 Jul 2023 17:25:03 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Change some reverse-ordered spliterators to use `Spliterators.spliterator(Collection, ORDERED)` instead of `Spliterators.spliteratorUnknownSize()`. This gives SIZED and ORDERED spliterators. More optimizations will be done later. I'm intending to backport this to JDK 21 so I want this to be minimal.
> 
> I've also included some adjustments to spliterator implementation comments to clear up a few points of confusion. (No spec changes.)

This looks like a reasonable low risk change, plus good clarifications on comments.

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

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14854#pullrequestreview-1527372524

From smarks at openjdk.org  Wed Jul 12 23:49:08 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 12 Jul 2023 23:49:08 GMT
Subject: Integrated: 8306785: fix deficient spliterators for Sequenced
 Collections
In-Reply-To: <DBT3pVrG4anlneVSMG_RkcjbAtpx8IV9YCVjEtl5KkI=.d29dffd7-3b36-4373-8506-bfab305a3b39@github.com>
References: <DBT3pVrG4anlneVSMG_RkcjbAtpx8IV9YCVjEtl5KkI=.d29dffd7-3b36-4373-8506-bfab305a3b39@github.com>
Message-ID: <CzSmLVD_DskmywCXKepO3oQwRPAuT-oU8i84ea53atQ=.14276fd8-fba8-4864-8626-a8188b02fe7a@github.com>

On Wed, 12 Jul 2023 17:25:03 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Change some reverse-ordered spliterators to use `Spliterators.spliterator(Collection, ORDERED)` instead of `Spliterators.spliteratorUnknownSize()`. This gives SIZED and ORDERED spliterators. More optimizations will be done later. I'm intending to backport this to JDK 21 so I want this to be minimal.
> 
> I've also included some adjustments to spliterator implementation comments to clear up a few points of confusion. (No spec changes.)

This pull request has now been integrated.

Changeset: 743e8b8e
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/743e8b8e0a9fe032a0dd652a4fef1f761af66595
Stats:     30 lines in 6 files changed: 18 ins; 4 del; 8 mod

8306785: fix deficient spliterators for Sequenced Collections

Reviewed-by: psandoz

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

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

From smarks at openjdk.org  Thu Jul 13 05:54:32 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 13 Jul 2023 05:54:32 GMT
Subject: [jdk21] RFR: 8306785: fix deficient spliterators for Sequenced
 Collections
Message-ID: <coJ6ejt-wgPj3EJ5QQgY2uO0dlVYcHf2wqHgxv4-n9Y=.66f3dcab-12fc-476b-a3fd-0d67965d5301@github.com>

Hi all,

This pull request contains a backport of commit [743e8b8e](https://github.com/openjdk/jdk/commit/743e8b8e0a9fe032a0dd652a4fef1f761af66595) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Stuart Marks on 12 Jul 2023 and was reviewed by Paul Sandoz.

Thanks!

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

Commit messages:
 - Backport 743e8b8e0a9fe032a0dd652a4fef1f761af66595

Changes: https://git.openjdk.org/jdk21/pull/118/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=118&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306785
  Stats: 30 lines in 6 files changed: 18 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jdk21/pull/118.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/118/head:pull/118

PR: https://git.openjdk.org/jdk21/pull/118

From jlu at openjdk.org  Thu Jul 13 06:40:24 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Jul 2023 06:40:24 GMT
Subject: RFR: 8311968: Clarify Three-letter time zone IDs in java.util.TimeZone
Message-ID: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>

Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8311979) which links the full list of deprecated three-letter IDs in java.util.TimeZone

Although it is made apparent in TimeZone that certain 3-letter IDs are deprecated, it does not actually list them in the specification. In addition to linking the full list, it is clarified that not _all_ 3-letter IDs are deprecated, as there are quite a few that come from the tzdb.

This change links to the full list found in ZoneId.

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

Commit messages:
 - Expand TZDB
 - Init commit

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

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

From qamai at openjdk.org  Thu Jul 13 07:19:12 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 13 Jul 2023 07:19:12 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
Message-ID: <4c-Ag3V0BMmclWZNbWiJ6tJdOPcBJpLCREMEGcK78ys=.8879c729-2e77-4618-8ca2-9f07a6f7e59e@github.com>

On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling.

Could you clarify this statement? Thanks a lot.

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

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1633696435

From duke at openjdk.org  Thu Jul 13 07:27:22 2023
From: duke at openjdk.org (yaqsun)
Date: Thu, 13 Jul 2023 07:27:22 GMT
Subject: RFR: 8311631: When multiple users run
 tools/jpackage/share/LicenseTest.java,
 Permission denied for writing /var/tmp/*.files [v2]
In-Reply-To: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
References: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
Message-ID: <tlogilGhgOPDCmKldD1UWGwoRqi3TYNe3tmgKG2D8EY=.0d789b18-6aac-4102-859d-653aab1cbcdf@github.com>

> The prerequisite is to install the rpmbuild command, when multiple users switch to write /var/tmp/*.files will have the permission forbidden.

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

  8311631: When multiple users run tools/jpackage/share/LicenseTest.java, Permission denied for writing /var/tmp/*.files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14802/files
  - new: https://git.openjdk.org/jdk/pull/14802/files/011653ab..fcab800d

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

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

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

From alanb at openjdk.org  Thu Jul 13 07:36:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Jul 2023 07:36:18 GMT
Subject: Integrated: 8311867: StructuredTaskScope.shutdown does not interrupt
 newly started threads
In-Reply-To: <vrfJZDSublpA2ZOXK_AfTF92D8hbzLsQRqx1Xp4HBFI=.475d09c2-7629-4d2c-b966-c2b93c4f400c@github.com>
References: <vrfJZDSublpA2ZOXK_AfTF92D8hbzLsQRqx1Xp4HBFI=.475d09c2-7629-4d2c-b966-c2b93c4f400c@github.com>
Message-ID: <dotnhQ43F33KfVpjLglIhy-R8Dv7A8mDcLmJ_OEFTq4=.4a6c0040-8012-489c-9321-b2884d07befa@github.com>

On Tue, 11 Jul 2023 17:03:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> StructuredTaskScope.shutdown can sometimes not interrupt the thread for a newly forked subtask, leading to join blocking until subtask completes. The "hang" can be duplicated with a stress test that shuts down the scope while a long running subtask is being forked. The bug is in the underlying thread flock code where it filters the threads to just the live threads and so filters out new/unstarted threads, that filtering was left over from some refactoring in the loom repo a long time ago and should have been removed.

This pull request has now been integrated.

Changeset: 92a04e20
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92a04e201e68aa4d682053cef4b36180ec5620f5
Stats:     99 lines in 3 files changed: 95 ins; 0 del; 4 mod

8311867: StructuredTaskScope.shutdown does not interrupt newly started threads

Reviewed-by: jpai

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

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

From shade at openjdk.org  Thu Jul 13 08:40:21 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 13 Jul 2023 08:40:21 GMT
Subject: [jdk21] RFR: 8311645: Memory leak in jspawnhelper spawnChild after
 JDK-8307990
Message-ID: <7OxmM0CK5EksT569SadXQzzbNu4F0cUfXxgh2jDwq94=.564fbe3e-2686-48d0-8c13-cfb273cda424@github.com>

Clean backport. Fixes the regression introduced in JDK 21.

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

Commit messages:
 - Backport 401c3dea5d8823bc9c0f40506ddad46e983ebf68

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

PR: https://git.openjdk.org/jdk21/pull/120

From prappo at openjdk.org  Thu Jul 13 08:46:54 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 13 Jul 2023 08:46:54 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <4c-Ag3V0BMmclWZNbWiJ6tJdOPcBJpLCREMEGcK78ys=.8879c729-2e77-4618-8ca2-9f07a6f7e59e@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
 <4c-Ag3V0BMmclWZNbWiJ6tJdOPcBJpLCREMEGcK78ys=.8879c729-2e77-4618-8ca2-9f07a6f7e59e@github.com>
Message-ID: <0ZtnI2TpsreVVgBi7tAvq0AP-MwDHK9llp0o0gzJ_ZU=.e70f9929-1cbf-42fd-8186-1f4c18343804@github.com>

On Thu, 13 Jul 2023 07:15:57 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> > For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling.
> 
> Could you clarify this statement? Thanks a lot.

My mental model is that Arrays.hashCode is to ArraysSupport.vectorizedHashCode as Arrays.mismatch to ArraysSupport.vectorizedMismatch. In either pair, the first method is applicable to some generic array, whereas the second method is applicable to an array that would definitely benefit from vectorized processing.

When I see a call to ArraysSupport.vectorizedHashCode, it reads like a statement: this particular computation must be vectorized. Now, was it author's intention, or there simply were no alternatives to compute hash code of an array subrange or with a different initial value?

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

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1633821479

From alanb at openjdk.org  Thu Jul 13 08:51:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Jul 2023 08:51:09 GMT
Subject: [jdk21] RFR: 8311645: Memory leak in jspawnhelper spawnChild after
 JDK-8307990
In-Reply-To: <7OxmM0CK5EksT569SadXQzzbNu4F0cUfXxgh2jDwq94=.564fbe3e-2686-48d0-8c13-cfb273cda424@github.com>
References: <7OxmM0CK5EksT569SadXQzzbNu4F0cUfXxgh2jDwq94=.564fbe3e-2686-48d0-8c13-cfb273cda424@github.com>
Message-ID: <kItR_F33-BPD0b2S4CE-VKYNTkf8BlRX3y7V4rz0Xxw=.7a62d918-698e-431c-9ac4-1e6f35e63c4c@github.com>

On Thu, 13 Jul 2023 08:31:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Clean backport. Fixes the regression introduced in JDK 21.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/120#pullrequestreview-1527931960

From qamai at openjdk.org  Thu Jul 13 09:17:04 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 13 Jul 2023 09:17:04 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <0ZtnI2TpsreVVgBi7tAvq0AP-MwDHK9llp0o0gzJ_ZU=.e70f9929-1cbf-42fd-8186-1f4c18343804@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
 <4c-Ag3V0BMmclWZNbWiJ6tJdOPcBJpLCREMEGcK78ys=.8879c729-2e77-4618-8ca2-9f07a6f7e59e@github.com>
 <0ZtnI2TpsreVVgBi7tAvq0AP-MwDHK9llp0o0gzJ_ZU=.e70f9929-1cbf-42fd-8186-1f4c18343804@github.com>
Message-ID: <pb1XM9lf0JE7KD_9jEwc1eKRcGdopuZt4p3wSxuD3Vo=.7d5bdf48-b90f-49bf-879d-baa5889baf75@github.com>

On Thu, 13 Jul 2023 08:44:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>>> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling.
>> 
>> Could you clarify this statement? Thanks a lot.
>
>> > For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling.
>> 
>> Could you clarify this statement? Thanks a lot.
> 
> My mental model is that Arrays.hashCode is to ArraysSupport.vectorizedHashCode as Arrays.mismatch to ArraysSupport.vectorizedMismatch. In either pair, the first method is applicable to some generic array, whereas the second method is applicable to an array that would definitely benefit from vectorized processing.
> 
> When I see a call to ArraysSupport.vectorizedHashCode, it reads like a statement: this particular computation must be vectorized. Now, was it author's intention, or there simply were no alternatives to compute hash code of an array subrange or with a different initial value?

@pavelrappo Actually I look at the implementation of `ArraySupport.vectorizedHashCode` and it does branching and only uses vector instructions if the length is sufficiently large. Please do benchmarking if you are uncertain with performance characteristics of functions. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1633867335

From prappo at openjdk.org  Thu Jul 13 09:31:17 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 13 Jul 2023 09:31:17 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <0ZtnI2TpsreVVgBi7tAvq0AP-MwDHK9llp0o0gzJ_ZU=.e70f9929-1cbf-42fd-8186-1f4c18343804@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
 <4c-Ag3V0BMmclWZNbWiJ6tJdOPcBJpLCREMEGcK78ys=.8879c729-2e77-4618-8ca2-9f07a6f7e59e@github.com>
 <0ZtnI2TpsreVVgBi7tAvq0AP-MwDHK9llp0o0gzJ_ZU=.e70f9929-1cbf-42fd-8186-1f4c18343804@github.com>
Message-ID: <HvUEqxe92gXg9jXPWnKPI8DAYdiIkSYPsnMIHDcquYg=.333b5481-e304-4599-9053-43d04ba80684@github.com>

On Thu, 13 Jul 2023 08:44:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>>> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling.
>> 
>> Could you clarify this statement? Thanks a lot.
>
>> > For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling.
>> 
>> Could you clarify this statement? Thanks a lot.
> 
> My mental model is that Arrays.hashCode is to ArraysSupport.vectorizedHashCode as Arrays.mismatch to ArraysSupport.vectorizedMismatch. In either pair, the first method is applicable to some generic array, whereas the second method is applicable to an array that would definitely benefit from vectorized processing.
> 
> When I see a call to ArraysSupport.vectorizedHashCode, it reads like a statement: this particular computation must be vectorized. Now, was it author's intention, or there simply were no alternatives to compute hash code of an array subrange or with a different initial value?

> @pavelrappo Actually I look at the implementation of `ArraySupport.vectorizedHashCode` and it does branching and only uses vector instructions if the length is sufficiently large. Please do benchmarking if you are uncertain with performance characteristics of functions. Thanks.

Are you sure you are talking about `vectorizedHashCode` and not `vectorizedMismatch`? While the latter indeed branches on array length, the former consists of simple for-loops, which might not be the actual thing anyway because the whole method is `@IntrinsicCandidate`.

Regardless of any performance characteristics, the call to something named `vectorizedHashCode` might needlessly draw attention to something that does not deserve it.
 
My mental model might be wrong, but let me give you a stream analogy. Would you not pause and think if you unexpectedly saw this?

    ...
    .stream()
    ...
    .parallel()
    ...

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

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1633888417

From prappo at openjdk.org  Thu Jul 13 10:57:17 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 13 Jul 2023 10:57:17 GMT
Subject: RFR: 8312019: Simplify and modernize java.util.BitSet.equals
Message-ID: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>

Please review this PR to use modern APIs and language features to simplify equals for BitSet. 

I couldn't see how to refactor hashCode using Arrays utility methods in a way that preserves its specification. So, aside from refactoring its doc comment and annotating it with `@Overrides`, I left it intact.

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

Commit messages:
 - Initial commit

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

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

From jpai at openjdk.org  Thu Jul 13 11:37:49 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Jul 2023 11:37:49 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v20]
In-Reply-To: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
Message-ID: <fimjS_-MQpByyJHD2qXqd5xSA4_9HphjZZmqpQZcCL4=.2fab97d1-0cc6-40f4-b370-2b9dec158b8c@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 incrementally with six additional commits since the last revision:

 - include a test to verify that an explicitly specified --endian value which matches the target platform's endianness, creates the image correctly
 - Roger's suggestion - use Architecture.lookupByName() instead of dealing with alias name replacements
 - Determine the target platform outside of the ImageHelper and just pass it the determined target platform
 - minor formatting change - align parameters
 - Mandy's suggestion - rename (and update comments) isJavaBaseFromCurrentPlatform to isJavaBaseFromDefaultModulePath
 - Mandy's suggestion - no need to store endian in JLinkConfiguration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11943/files
  - new: https://git.openjdk.org/jdk/pull/11943/files/962d542d..733e7b50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=18-19

  Stats: 235 lines in 6 files changed: 119 ins; 101 del; 15 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  Thu Jul 13 11:37:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Jul 2023 11:37:54 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v19]
In-Reply-To: <FNS2S9_X6_XYlpurHWDDLlwuCQltQLOIEOTgZkJ27pE=.6fbd0f44-f9e4-4c70-bebf-9e200df8184e@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <FNS2S9_X6_XYlpurHWDDLlwuCQltQLOIEOTgZkJ27pE=.6fbd0f44-f9e4-4c70-bebf-9e200df8184e@github.com>
Message-ID: <faTMwVVTsBMHZRP5KZ_kwD4kJ7JIGXe6JzMX_Lq1tkU=.a30fc7b5-0c96-43ba-855c-71781b5ad38e@github.com>

On Wed, 12 Jul 2023 10:58:49 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 45 commits:
> 
>  - move copyright before imports in the new test
>  - add a new test for jlink --endian usages
>  - merge latest from master branch
>  - use newly introduced Architecture.byteOrder() API
>  - merge latest from master branch
>  - 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
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/753bd563...962d542d

Thank you Roger and Mandy for the latest suggestions. I've updated the PR to incorporate those.

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

PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1634083298

From jpai at openjdk.org  Thu Jul 13 11:38:00 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Jul 2023 11:38:00 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v19]
In-Reply-To: <vQGGPSnWOg2Pi56-KmKqHBY2PU3l1QfTr6OV6-1OZSU=.36185ab9-9b4d-432e-bf35-409d45c272e4@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <FNS2S9_X6_XYlpurHWDDLlwuCQltQLOIEOTgZkJ27pE=.6fbd0f44-f9e4-4c70-bebf-9e200df8184e@github.com>
 <vQGGPSnWOg2Pi56-KmKqHBY2PU3l1QfTr6OV6-1OZSU=.36185ab9-9b4d-432e-bf35-409d45c272e4@github.com>
Message-ID: <QZ_yrUkemLBGU-DU-75kRI3rbsEv0m8CJdJY9geJU-0=.918e2322-10e8-40b6-bee7-0e3be70b8933@github.com>

On Wed, 12 Jul 2023 19:24:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
>> 
>>  - move copyright before imports in the new test
>>  - add a new test for jlink --endian usages
>>  - merge latest from master branch
>>  - use newly introduced Architecture.byteOrder() API
>>  - merge latest from master branch
>>  - 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
>>  - ... and 35 more: https://git.openjdk.org/jdk/compare/753bd563...962d542d
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Jlink.java line 168:
> 
>> 166:             this.output = output;
>> 167:             this.modules = Objects.requireNonNull(modules);
>> 168:             this.endian = endian;
> 
> `JlinkConfiguration` does not need to know the endianness.   Only the image builder needs it.   Probably good to take the `endian` parameter out from `JlinkConfiguration` and instead pass the value of `--endian` to `JlinkTask::createImageProvider` like other jlink options.

Done. The updated PR no longer has the endian value in the `JlinkConfiguration`

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 412:
> 
>> 410: 
>> 411:         // First create the image provider
>> 412:         ImageHelper imageProvider = createImageProvider(config,
> 
> formatting nit: line 413-415 should be adjusted to align the parameters.

Fixed

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 568:
> 
>> 566:         Map<String, Path> mods = cf.modules().stream()
>> 567:             .collect(Collectors.toMap(ResolvedModule::name, JlinkTask::toPathLocation));
>> 568:         return new ImageHelper(cf, mods, config.getByteOrder(), retainModulesPath, ignoreSigning,
> 
> Also we can move the logic of determining the endianess of the target platform out of `ImageHelper`.   Evaluate the target platform and endianness here and pass to `ImageHelper`.
> 
> Suggestion:
> 
>         // endian is the value specified via --endian and a new parameter to createImageProvider 
>         Platform targetPlatform = targetPlatform(cf, modsPaths);
>         ByteOrder targetOrder = endian != null ? endian : targetPlatform.arch().byteOrder();
>         return new ImageHelper(cf, mods, targetOrder, retainModulesPath, ignoreSigning,

I've updated the PR to use this suggestion. With this suggested change, the code is much more cleaner and I now just pass the `targetPlatform` to the `ImageHelper` constructor.

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 856:
> 
>> 854:         // returns true if the current platform's "jmods" directory is the parent of the
>> 855:         // passed javaBasePath
>> 856:         private static boolean isJavaBaseFromCurrentPlatform(Path javaBasePath) throws IOException {
> 
> This method checks if we are jlinking the JMOD files from the default module path.   This is not exactly checking if `java.base` matches the current platform since there are other possible setups too.    Suggest to rename the method name to `isJavaBaseFromDefaultModulePath`.   So the comments should also be updated to reflect that.

Renamed as suggested and updated the comments as well in the updated version of the PR.

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 857:
> 
>> 855:         // passed javaBasePath
>> 856:         private static boolean isJavaBaseFromCurrentPlatform(Path javaBasePath) throws IOException {
>> 857:             Path currentPlatformJmods = getDefaultModulePath();
> 
> Suggestion:
> 
>             Path defaultModulePath = getDefaultModulePath();

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1262425330
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1262426029
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1262427486
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1262425722
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1262425873

From jpai at openjdk.org  Thu Jul 13 11:38:03 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Jul 2023 11:38:03 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v19]
In-Reply-To: <n7Pe7-OBLTUY63IhftXTdrnqRYC2P9WbSi-Y8X8aI6c=.6bfb6f90-0ffe-4801-9aef-f784517f9d29@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <FNS2S9_X6_XYlpurHWDDLlwuCQltQLOIEOTgZkJ27pE=.6fbd0f44-f9e4-4c70-bebf-9e200df8184e@github.com>
 <n7Pe7-OBLTUY63IhftXTdrnqRYC2P9WbSi-Y8X8aI6c=.6bfb6f90-0ffe-4801-9aef-f784517f9d29@github.com>
Message-ID: <VzxExU3DUaEVvzs_eyYLAcE0yjahijUoc79vXFc0tbQ=.d06ebd9b-e73d-4039-87a7-4e7b30b69a37@github.com>

On Wed, 12 Jul 2023 14:38:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
>> 
>>  - move copyright before imports in the new test
>>  - add a new test for jlink --endian usages
>>  - merge latest from master branch
>>  - use newly introduced Architecture.byteOrder() API
>>  - merge latest from master branch
>>  - 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
>>  - ... and 35 more: https://git.openjdk.org/jdk/compare/753bd563...962d542d
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 846:
> 
>> 844:                 String targetPlatformVal = readJavaBaseTargetPlatform(cf);
>> 845:                 try {
>> 846:                     return Platform.parsePlatform(targetPlatformVal);
> 
> You may want to modify `Platform.parsePlatform(s)` to use `Architecture.lookupByName(s)` instead of doing the alias mapping itself.  Platform.java:53-56.

That's a good point. I've updated the PR with your suggested implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1262424756

From jpai at openjdk.org  Thu Jul 13 11:46:39 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Jul 2023 11:46:39 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v21]
In-Reply-To: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
Message-ID: <ncyqPyRO8dEypxI76YMOjO8R_BU4_PwwOzEYUrQrkL8=.de648084-40b5-40cb-aecc-9dd5ad8c4887@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 incrementally with one additional commit since the last revision:

  minor - remove duplicated code comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11943/files
  - new: https://git.openjdk.org/jdk/pull/11943/files/733e7b50..258a62d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=19-20

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 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 shade at openjdk.org  Thu Jul 13 12:01:15 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 13 Jul 2023 12:01:15 GMT
Subject: [jdk21] RFR: 8311645: Memory leak in jspawnhelper spawnChild after
 JDK-8307990
In-Reply-To: <7OxmM0CK5EksT569SadXQzzbNu4F0cUfXxgh2jDwq94=.564fbe3e-2686-48d0-8c13-cfb273cda424@github.com>
References: <7OxmM0CK5EksT569SadXQzzbNu4F0cUfXxgh2jDwq94=.564fbe3e-2686-48d0-8c13-cfb273cda424@github.com>
Message-ID: <7XE4cEZtb6pxCVdu9AtsD0m1JT1tNaX5-ij5f2C1JbU=.e0ab7874-7e3f-4448-9d7f-e9d8a2f9a2ca@github.com>

On Thu, 13 Jul 2023 08:31:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Clean backport. Fixes the regression introduced in JDK 21.

Test failures in GHA are unrelated.

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

PR Comment: https://git.openjdk.org/jdk21/pull/120#issuecomment-1634114884

From shade at openjdk.org  Thu Jul 13 12:01:16 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 13 Jul 2023 12:01:16 GMT
Subject: [jdk21] Integrated: 8311645: Memory leak in jspawnhelper spawnChild
 after JDK-8307990
In-Reply-To: <7OxmM0CK5EksT569SadXQzzbNu4F0cUfXxgh2jDwq94=.564fbe3e-2686-48d0-8c13-cfb273cda424@github.com>
References: <7OxmM0CK5EksT569SadXQzzbNu4F0cUfXxgh2jDwq94=.564fbe3e-2686-48d0-8c13-cfb273cda424@github.com>
Message-ID: <ADuNmNW1ZbJ5rurctD37Dkdl-ocUe_KHQTgzNUFjbz0=.b823cb22-5dea-40e5-8d13-8ed8917f458d@github.com>

On Thu, 13 Jul 2023 08:31:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Clean backport. Fixes the regression introduced in JDK 21.

This pull request has now been integrated.

Changeset: 99d87e90
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/99d87e90972d3ab587e49d493de6a8b9e0b8058f
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8311645: Memory leak in jspawnhelper spawnChild after JDK-8307990

Reviewed-by: alanb
Backport-of: 401c3dea5d8823bc9c0f40506ddad46e983ebf68

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

PR: https://git.openjdk.org/jdk21/pull/120

From rriggs at openjdk.org  Thu Jul 13 14:01:11 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Jul 2023 14:01:11 GMT
Subject: [jdk21] RFR: 8306785: fix deficient spliterators for Sequenced
 Collections
In-Reply-To: <coJ6ejt-wgPj3EJ5QQgY2uO0dlVYcHf2wqHgxv4-n9Y=.66f3dcab-12fc-476b-a3fd-0d67965d5301@github.com>
References: <coJ6ejt-wgPj3EJ5QQgY2uO0dlVYcHf2wqHgxv4-n9Y=.66f3dcab-12fc-476b-a3fd-0d67965d5301@github.com>
Message-ID: <kFxjy-aZwHEwoY8lZLT2SEgyJ4ZY6P6Vzpk0QKH-oMw=.fed44865-6e79-4c37-bab8-9995aaa3ad96@github.com>

On Thu, 13 Jul 2023 05:45:37 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [743e8b8e](https://github.com/openjdk/jdk/commit/743e8b8e0a9fe032a0dd652a4fef1f761af66595) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Stuart Marks on 12 Jul 2023 and was reviewed by Paul Sandoz.
> 
> Thanks!

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/118#pullrequestreview-1528521886

From duke at openjdk.org  Thu Jul 13 14:29:28 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 13 Jul 2023 14:29:28 GMT
Subject: Integrated: 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: <S66adkFqvOE4FHWqPyq-HSZ5t2qyXN7cS7DF-J-uEcc=.e592bb2a-96ae-4441-97e3-e6af4940db35@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.

This pull request has now been integrated.

Changeset: 8c9d091f
Author:    Viktor Klang <viktor.klang at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c9d091f19760deece8daf3e57add85482b9f2a7
Stats:     3 lines in 2 files changed: 0 ins; 1 del; 2 mod

8308047: java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java timed out and also had jcmd pipe errors

Reviewed-by: stefank, alanb

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

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

From rriggs at openjdk.org  Thu Jul 13 14:49:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Jul 2023 14:49:15 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v21]
In-Reply-To: <ncyqPyRO8dEypxI76YMOjO8R_BU4_PwwOzEYUrQrkL8=.de648084-40b5-40cb-aecc-9dd5ad8c4887@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <ncyqPyRO8dEypxI76YMOjO8R_BU4_PwwOzEYUrQrkL8=.de648084-40b5-40cb-aecc-9dd5ad8c4887@github.com>
Message-ID: <Y4I7JpwH3pn_MTnkail7iHTfkeujY3mQjwif_crYSS0=.4bf8e990-784f-4b55-ae3a-8b8d8bd7d683@github.com>

On Thu, 13 Jul 2023 11:46:39 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 one additional commit since the last revision:
> 
>   minor - remove duplicated code comment

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/11943#pullrequestreview-1528628459

From duke at openjdk.org  Thu Jul 13 14:49:20 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 13 Jul 2023 14:49:20 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <HvUEqxe92gXg9jXPWnKPI8DAYdiIkSYPsnMIHDcquYg=.333b5481-e304-4599-9053-43d04ba80684@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
 <4c-Ag3V0BMmclWZNbWiJ6tJdOPcBJpLCREMEGcK78ys=.8879c729-2e77-4618-8ca2-9f07a6f7e59e@github.com>
 <0ZtnI2TpsreVVgBi7tAvq0AP-MwDHK9llp0o0gzJ_ZU=.e70f9929-1cbf-42fd-8186-1f4c18343804@github.com>
 <HvUEqxe92gXg9jXPWnKPI8DAYdiIkSYPsnMIHDcquYg=.333b5481-e304-4599-9053-43d04ba80684@github.com>
Message-ID: <7LrU8FC1T0RO36F-JTI54hJ6K3uFY8w3X3yIzDUp0KI=.e771d51f-45a5-4c40-886c-9bb9e22e0a57@github.com>

On Thu, 13 Jul 2023 09:27:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > @pavelrappo Actually I look at the implementation of `ArraySupport.vectorizedHashCode` and it does branching and only uses vector instructions if the length is sufficiently large. Please do benchmarking if you are uncertain with performance characteristics of functions. Thanks.
> 
> Are you sure you are talking about `vectorizedHashCode` and not `vectorizedMismatch`? While the latter indeed branches on array length, the former consists of simple for-loops, which might not be the actual thing anyway because the whole method is `@IntrinsicCandidate`.
> 
> Regardless of any performance characteristics, the call to something named `vectorizedHashCode` might needlessly draw attention to something that does not deserve it.
> 
> My mental model might be wrong, but let me give you a stream analogy. Would you not pause and think if you unexpectedly saw this?
> 
> ```
> ...
> .stream()
> ...
> .parallel()
> ...
> ```

I don't think it's a good analogy. In my understanding, it is an obvious fact that `vectorizedHashCode` will not always vectorize, as vectorized code must always handle suffixes that cannot be vectorized.

I don't think judging outside `vectorizedHashCode` will make the code clear, unless `vectorizedHashCode` only handles the part that can be vectorized, and the processing of suffixes is also outside `vectorizedHashCode`.

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

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1634378224

From rriggs at openjdk.org  Thu Jul 13 14:53:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Jul 2023 14:53:56 GMT
Subject: RFR: 8312019: Simplify and modernize java.util.BitSet.equals
In-Reply-To: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
References: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
Message-ID: <YQhzTnDuXSyDfqlgixyIY72WzaOycQjN2HFh6DBEV-M=.82696b69-bbba-4461-b6b2-853b2bbfab1c@github.com>

On Thu, 13 Jul 2023 10:50:30 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify equals for BitSet. 
> 
> I couldn't see how to refactor hashCode using Arrays utility methods in a way that preserves its specification. So, aside from refactoring its doc comment and annotating it with `@Overrides`, I left it intact.

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14868#pullrequestreview-1528639357

From jlaskey at openjdk.org  Thu Jul 13 15:07:35 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Jul 2023 15:07:35 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v8]
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: <6fpeJ9q0R9LTBsv9ynVXmUtuP9o0b4fVgbyGR2iZ59E=.0fe636ac-df43-4397-87d2-b9ea0ba1585a@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:

  Update test to check for gc.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14684/files
  - new: https://git.openjdk.org/jdk/pull/14684/files/bb943b6f..3cf389b0

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

  Stats: 39 lines in 1 file changed: 26 ins; 0 del; 13 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 mchung at openjdk.org  Thu Jul 13 16:19:26 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 13 Jul 2023 16:19:26 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v21]
In-Reply-To: <ncyqPyRO8dEypxI76YMOjO8R_BU4_PwwOzEYUrQrkL8=.de648084-40b5-40cb-aecc-9dd5ad8c4887@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <ncyqPyRO8dEypxI76YMOjO8R_BU4_PwwOzEYUrQrkL8=.de648084-40b5-40cb-aecc-9dd5ad8c4887@github.com>
Message-ID: <CK7XplGebWy7DnDr9dVRAZoLc-VO3g70GG7d0Jd1tgc=.d6760104-e3d3-4685-ba97-14b2b3a956f1@github.com>

On Thu, 13 Jul 2023 11:46:39 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 one additional commit since the last revision:
> 
>   minor - remove duplicated code comment

Thanks for the update.  Looks much cleaner.

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/11943#pullrequestreview-1528803294

From smarks at openjdk.org  Thu Jul 13 18:06:18 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 13 Jul 2023 18:06:18 GMT
Subject: [jdk21] Integrated: 8306785: fix deficient spliterators for Sequenced
 Collections
In-Reply-To: <coJ6ejt-wgPj3EJ5QQgY2uO0dlVYcHf2wqHgxv4-n9Y=.66f3dcab-12fc-476b-a3fd-0d67965d5301@github.com>
References: <coJ6ejt-wgPj3EJ5QQgY2uO0dlVYcHf2wqHgxv4-n9Y=.66f3dcab-12fc-476b-a3fd-0d67965d5301@github.com>
Message-ID: <UCNDttKiohWhj_4e92LefeB9iDxGC_K_QB6pvESU-f8=.88794e25-ae62-4403-b08f-7c00a12652bc@github.com>

On Thu, 13 Jul 2023 05:45:37 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [743e8b8e](https://github.com/openjdk/jdk/commit/743e8b8e0a9fe032a0dd652a4fef1f761af66595) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Stuart Marks on 12 Jul 2023 and was reviewed by Paul Sandoz.
> 
> Thanks!

This pull request has now been integrated.

Changeset: b4f19f57
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/b4f19f57e174bffad2e9f3c185414dcd7f481668
Stats:     30 lines in 6 files changed: 18 ins; 4 del; 8 mod

8306785: fix deficient spliterators for Sequenced Collections

Reviewed-by: rriggs
Backport-of: 743e8b8e0a9fe032a0dd652a4fef1f761af66595

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

PR: https://git.openjdk.org/jdk21/pull/118

From alanb at openjdk.org  Thu Jul 13 18:07:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Jul 2023 18:07:48 GMT
Subject: [jdk21] RFR: 8311867: StructuredTaskScope.shutdown does not interrupt
 newly started threads
Message-ID: <TCs3mKOaPnXUxufPKEnMQvbRSXZNJqT4YvYMs-jNHeY=.9c3729ec-950f-4262-87a6-cddd8371f33d@github.com>

Clean backport of https://git.openjdk.org/jdk/pull/14833

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

Commit messages:
 - Backport 92a04e201e68aa4d682053cef4b36180ec5620f5

Changes: https://git.openjdk.org/jdk21/pull/123/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=123&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311867
  Stats: 99 lines in 3 files changed: 95 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk21/pull/123.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/123/head:pull/123

PR: https://git.openjdk.org/jdk21/pull/123

From rriggs at openjdk.org  Thu Jul 13 18:29:10 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Jul 2023 18:29:10 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
Message-ID: <jSbwqLoGNWuWV8CEXEqLPO2-mYiIne2YH4f2Y8cLxw0=.82826a14-f192-4186-b5e5-579787c00876@github.com>

On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR adds an internal method to calculate hash code from the provided integer array, offset and length into that array, and the initial hash code value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's either ArraysSupport.vectorizedHashCode with an offset, length and initial value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling. Unfortunately, it's the only hash code method that operates on an array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, behaviour which was specified but untested.

These look like useful additions, plus versions for byte[] and Object[].

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

PR Review: https://git.openjdk.org/jdk/pull/14831#pullrequestreview-1529028350

From naoto at openjdk.org  Thu Jul 13 18:32:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Jul 2023 18:32:04 GMT
Subject: RFR: 8311968: Clarify Three-letter time zone IDs in
 java.util.TimeZone
In-Reply-To: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
References: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
Message-ID: <tuq3Aj5fS5lo4iwIYsLL3BADczYlyjlq7IvG3_hEdGM=.d4c41654-f4ad-426b-9cab-30d50b244f02@github.com>

On Thu, 13 Jul 2023 06:34:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8311979) which links the full list of deprecated three-letter IDs in java.util.TimeZone
> 
> Although it is made apparent in TimeZone that certain 3-letter IDs are deprecated, it does not actually list them in the specification. In addition to linking the full list, it is clarified that not _all_ 3-letter IDs are deprecated, as there are quite a few that come from the tzdb.
> 
> This change links to the full list found in ZoneId.

src/java.base/share/classes/java/util/TimeZone.java line 133:

> 131:  * for multiple time zones (for example, "CST" could be U.S. "Central Standard
> 132:  * Time" and "China Standard Time"), and the Java platform can then only
> 133:  * recognize one of them. The full list of the deprecated IDs can be viewed

"deprecated IDs and their mappings" may read better, as SHORT_IDS is a map

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14861#discussion_r1262923761

From jlu at openjdk.org  Thu Jul 13 18:36:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Jul 2023 18:36:29 GMT
Subject: [jdk21] RFR: 6960866: [Fmt-Ch] ChoiceFormat claims impossible and
 unimplemented functionality
Message-ID: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>

Please review this PR which backports https://github.com/openjdk/jdk/commit/6cb9ec32a68634f0b6f7461c9dc7ef0c0e59861d

Thank you

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

Commit messages:
 - 6960866: [Fmt-Ch] ChoiceFormat claims impossible and unimplemented functionality

Changes: https://git.openjdk.org/jdk21/pull/125/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=125&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/jdk21/pull/125.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/125/head:pull/125

PR: https://git.openjdk.org/jdk21/pull/125

From jlu at openjdk.org  Thu Jul 13 18:41:47 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Jul 2023 18:41:47 GMT
Subject: RFR: 8311968: Clarify Three-letter time zone IDs in
 java.util.TimeZone [v2]
In-Reply-To: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
References: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
Message-ID: <DqBjaXMYN3Szcab5xf1XrSt9U1rpATZ5Son-uCg_kWQ=.81705488-34b9-4c35-b360-d7d114c3ee73@github.com>

> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8311979) which links the full list of deprecated three-letter IDs in java.util.TimeZone
> 
> Although it is made apparent in TimeZone that certain 3-letter IDs are deprecated, it does not actually list them in the specification. In addition to linking the full list, it is clarified that not _all_ 3-letter IDs are deprecated, as there are quite a few that come from the tzdb.
> 
> This change links to the full list found in ZoneId.

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

  Review: update wording to include mappings

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14861/files
  - new: https://git.openjdk.org/jdk/pull/14861/files/b9dfd4e5..3919ad19

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

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

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

From jlu at openjdk.org  Thu Jul 13 18:41:49 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Jul 2023 18:41:49 GMT
Subject: RFR: 8311968: Clarify Three-letter time zone IDs in
 java.util.TimeZone [v2]
In-Reply-To: <tuq3Aj5fS5lo4iwIYsLL3BADczYlyjlq7IvG3_hEdGM=.d4c41654-f4ad-426b-9cab-30d50b244f02@github.com>
References: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
 <tuq3Aj5fS5lo4iwIYsLL3BADczYlyjlq7IvG3_hEdGM=.d4c41654-f4ad-426b-9cab-30d50b244f02@github.com>
Message-ID: <2muWkCsEycULcXgx0SGQmzQ5wBgzKpBQtgykZzUu-cU=.7ac413e4-9573-4197-a869-b8b8d7adedf1@github.com>

On Thu, 13 Jul 2023 18:29:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review: update wording to include mappings
>
> src/java.base/share/classes/java/util/TimeZone.java line 133:
> 
>> 131:  * for multiple time zones (for example, "CST" could be U.S. "Central Standard
>> 132:  * Time" and "China Standard Time"), and the Java platform can then only
>> 133:  * recognize one of them. The full list of the deprecated IDs can be viewed
> 
> "deprecated IDs and their mappings" may read better, as SHORT_IDS is a map

Good point, clarified the PR and CSR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14861#discussion_r1262929615

From duke at openjdk.org  Thu Jul 13 18:54:27 2023
From: duke at openjdk.org (duke)
Date: Thu, 13 Jul 2023 18:54:27 GMT
Subject: Withdrawn: JDK-8296360: Track native memory used by zlib via NMT
In-Reply-To: <WW7_ad6YUZQ26hrK4idngOcwkotxiJr1PAyfP29Lj64=.5779f834-b617-4295-b69e-c37c796f5268@github.com>
References: <WW7_ad6YUZQ26hrK4idngOcwkotxiJr1PAyfP29Lj64=.5779f834-b617-4295-b69e-c37c796f5268@github.com>
Message-ID: <zCh0h3Q5e4PgT3O-yLyZBAVMTHn43F0Rjp9KvfGgRvI=.f3440681-b504-43df-9237-7586470f52e3@github.com>

On Fri, 4 Nov 2022 14:35:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This patch adds NMT tracking to the zlib.
> 
> *Please note: we currently discuss whether NMT can be expanded across the JDK in this ML discussion [1]. This PR depends on the outcome of that discussion and won't proceed unless greenlighted. But since [1] is stalled, I post the PR for RFR to get some feedback on the code itself and for people to try it out.*
> 
> NMT tracks hotspot native allocations but does not cover the JDK (apart from small exceptions). But the native memory
> footprint of JDK libraries can be very significant. Recently we had a customer whose zlib footprint went into the ~40GB range. We analyzed the problem with an in-house memory tracker, but things would have been a lot simpler using NMT.
> 
> This patch instruments the zlib via zalloc hooks, which is minimally invasive. It does not touch zlib sources, so it works with both the bundled zlib and system zlib. All the instrumentation happens in the JVM zlib wrapper.
> 
> 
> -         j.u.zip (deflate) (reserved=624, committed=624)
>                             (malloc=624 #3) 
>  
> -         j.u.zip (inflate) (reserved=221377904, committed=221377904)
>                             (malloc=221377904 #60877) 
>  
> -               Zip (other) (reserved=8163446896, committed=8163446896)
>                             (malloc=8163446896 #182622) 
> 
> 
> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html

This pull request has been closed without being integrated.

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

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

From naoto at openjdk.org  Thu Jul 13 18:55:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Jul 2023 18:55:13 GMT
Subject: RFR: 8311968: Clarify Three-letter time zone IDs in
 java.util.TimeZone [v2]
In-Reply-To: <DqBjaXMYN3Szcab5xf1XrSt9U1rpATZ5Son-uCg_kWQ=.81705488-34b9-4c35-b360-d7d114c3ee73@github.com>
References: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
 <DqBjaXMYN3Szcab5xf1XrSt9U1rpATZ5Son-uCg_kWQ=.81705488-34b9-4c35-b360-d7d114c3ee73@github.com>
Message-ID: <nkE6av7jIyNplPFs1iFyOmk3veA-7YUkeZNgSOqukPM=.bb40925e-9452-4ba8-b0b0-73c92c9702ce@github.com>

On Thu, 13 Jul 2023 18:41:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8311979) which links the full list of deprecated three-letter IDs in java.util.TimeZone
>> 
>> Although it is made apparent in TimeZone that certain 3-letter IDs are deprecated, it does not actually list them in the specification. In addition to linking the full list, it is clarified that not _all_ 3-letter IDs are deprecated, as there are quite a few that come from the tzdb.
>> 
>> This change links to the full list found in ZoneId.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: update wording to include mappings

LGTM. Reviewed the CSR too

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14861#pullrequestreview-1529063574

From naoto at openjdk.org  Thu Jul 13 19:17:10 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Jul 2023 19:17:10 GMT
Subject: [jdk21] RFR: 6960866: [Fmt-Ch] ChoiceFormat claims impossible and
 unimplemented functionality
In-Reply-To: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>
References: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>
Message-ID: <pNupGFoQf2NbHZtnWkieRXVTjowwhW-bMOEMY69Q1fE=.3290171b-2462-4dcd-b75d-4fd620698386@github.com>

On Thu, 13 Jul 2023 18:28:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which backports https://github.com/openjdk/jdk/commit/6cb9ec32a68634f0b6f7461c9dc7ef0c0e59861d
> 
> Thank you

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/125#pullrequestreview-1529096169

From dl at openjdk.org  Thu Jul 13 19:21:01 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 13 Jul 2023 19:21:01 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v6]
In-Reply-To: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
Message-ID: <JLu2abTrdYaA72UojilLoZe14xxNRQUAAnS_G9pGNpY=.3692be64-289d-4562-b089-e5d9b50df928@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 seven additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8301341
 - Simplify contention handling; fix test
 - Fix inverted test assert; improve internal documentation; simplify code
 - 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/2f591a0b..060e6774

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

  Stats: 61202 lines in 786 files changed: 10819 ins; 48250 del; 2133 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 mchung at openjdk.org  Thu Jul 13 19:30:05 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 13 Jul 2023 19:30:05 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() throws UOE if invoked
 reflectively [v3]
In-Reply-To: <BhLE3dfNH4BcJr1wdYplaRLON1PAABl_Kxw9bE0S36k=.388595b3-0094-41af-ad7c-ce8183fb72b2@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
 <BhLE3dfNH4BcJr1wdYplaRLON1PAABl_Kxw9bE0S36k=.388595b3-0094-41af-ad7c-ce8183fb72b2@github.com>
Message-ID: <YTeOwOSdTJFmtokw3-YaH-BizLDzSbq5BWvB5-8ycYQ=.94f11e59-8b37-4f3a-8f3c-4cd9db88cdad@github.com>

On Tue, 11 Jul 2023 15:47:35 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> As the included jtreg test demonstrates, `StackWalker.getCallerClass()` can throw an `UnsupportedOperationException` if called reflectively. Currently this only happens if we invoke `StackWalker.getCallerClass()` recursively reflectively, but this issue will become more prominent once we fix [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447). The gory details follow below:
>> 
>> The protocol between the Java API and the JVM for `StackWalker.getCallerClass()/walk()` is as follows:
>> - On the Java side, `StackWalker` calls into `StackStreamFactory` for the real work.
>> - For `StackWalker.getCallerClass()` `StackStreamFactory` basically creates a `Class[]` which will be passed down and filled in the JVM. For `StackWalker.walk()` it will normally be a `StackFrameInfo[]` (or a `LiveStackFrameInfo[]` if the internal `ExtendedOption.LOCALS_AND_OPERANDS` option was used).
>> - The default size of this arrays is currently `StackStreamFactory.SMALL_BATCH` which is 8 (but see [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447)).
>> - `StackStreamFactory` than calls `AbstractStackWalker.callStackWalk()` which is a natively implemented in the VM by `JVM_CallStackWalk()`.
>> -  `JVM_CallStackWalk()` calls `StackWalk::walk()` which calls `StackWalk::fetchFirstBatch()` which calls `StackWalk::fill_in_frames()` which walks the stack and fills in the available class/stackframe slots in the passed in array until the array is full or there are no more stack frames,
>> - Once  `StackWalk::fill_in_frames()` returns, `StackWalk::fetchFirstBatch()` calls back to Java by invoking `AbstractStackWalker::doStackWalk()` to consume the result.
>> - `AbstractStackWalker::doStackWalk()` calls `consumeFrames()` (which is overridden depending on whether we initially called `getCallerClass()` or `walk()`) which consumes the frames until it either finishes (e.g. finds the caller class) or until there are no more frames.
>> - In the latter case `consumeFrames()` will call into the the VM again by calling `AbstractStackWalker.fetchStackFrames()` to fetch additional frames from the stack.
>> - `AbstractStackWalker.fetchStackFrames()` is implemented by `JVM_MoreStackWalk()` which calls `StackWalk::fetchNextBatch()` which calls `StackWalk::fill_in_frames()` (the same method that already fetched the initial batch of frames).
>> 
>> Following is a stacktrace of what I've explained so far:
>> 
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x1...
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed case when calling getCallerClass() from a @CallerSensitive method reflectively

I wonder if we should move the check to throw UOE if called by caller-sensitive method in Java as a general guidance to implement the runtime in Java if desirable.   That means it requires the VM to fill not only the class in the buffer but also need a flag to indicate the method is caller-sensitive or not.   It's a tradeoff of the buffer size.    The common case for `getCallerClass` is being invoked statically and should find the class from the first batch.   Only if it's invoked reflectively and if filtered in the Java,  it'll fetch more batches and hence the performance would not be as fast as filtered in VM but I think that's okay since it's uncommon.

Would you have cycle to implement this alternative and determine any performance impact to common cases?  Then evaluate this further.

The benchmark is at `test/micro/org/openjdk/bench/java/lang/StackWalkBench.java`.

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

PR Comment: https://git.openjdk.org/jdk/pull/14773#issuecomment-1634783438

From lancea at openjdk.org  Thu Jul 13 19:35:20 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 13 Jul 2023 19:35:20 GMT
Subject: [jdk21] RFR: 6960866: [Fmt-Ch] ChoiceFormat claims impossible and
 unimplemented functionality
In-Reply-To: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>
References: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>
Message-ID: <7gQniErTeuFDrW2k-gnwGHF0M91r3uoSEZvU9K-F5y0=.a4e5ad25-19f1-4016-ac6e-e54d14038944@github.com>

On Thu, 13 Jul 2023 18:28:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which backports https://github.com/openjdk/jdk/commit/6cb9ec32a68634f0b6f7461c9dc7ef0c0e59861d
> 
> Thank you

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/125#pullrequestreview-1529122742

From lancea at openjdk.org  Thu Jul 13 19:41:04 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 13 Jul 2023 19:41:04 GMT
Subject: RFR: 8311968: Clarify Three-letter time zone IDs in
 java.util.TimeZone [v2]
In-Reply-To: <DqBjaXMYN3Szcab5xf1XrSt9U1rpATZ5Son-uCg_kWQ=.81705488-34b9-4c35-b360-d7d114c3ee73@github.com>
References: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
 <DqBjaXMYN3Szcab5xf1XrSt9U1rpATZ5Son-uCg_kWQ=.81705488-34b9-4c35-b360-d7d114c3ee73@github.com>
Message-ID: <-2chC3MkWU8N4XFEW8inDX7XYbZ62WoNad9Z5HIvlVQ=.7d0dfcaf-4040-4add-9e30-9cb33db113b8@github.com>

On Thu, 13 Jul 2023 18:41:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8311979) which links the full list of deprecated three-letter IDs in java.util.TimeZone
>> 
>> Although it is made apparent in TimeZone that certain 3-letter IDs are deprecated, it does not actually list them in the specification. In addition to linking the full list, it is clarified that not _all_ 3-letter IDs are deprecated, as there are quite a few that come from the tzdb.
>> 
>> This change links to the full list found in ZoneId.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: update wording to include mappings

src/java.base/share/classes/java/util/TimeZone.java line 135:

> 133:  * recognize one of them. The full list of the deprecated IDs and their mappings
> 134:  * can be viewed at {@link java.time.ZoneId#SHORT_IDS}. It should be noted that
> 135:  * not all three-letter time zone IDs are deprecated, as some come from the IANA

This is a bit confusing at least to me as I did not see which SHORT_IDS were not deprecated via the link above, but perhaps I missed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14861#discussion_r1262983679

From jlu at openjdk.org  Thu Jul 13 20:27:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Jul 2023 20:27:33 GMT
Subject: RFR: 8311968: Clarify Three-letter time zone IDs in
 java.util.TimeZone [v3]
In-Reply-To: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
References: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
Message-ID: <dvoQ91IdsoTVu-Q-ouOa6qEm8Ca8783z7YRlX8IppaM=.5f39bb46-1f2a-4a09-948d-9fd42bf49d6c@github.com>

> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8311979) which links the full list of deprecated three-letter IDs in java.util.TimeZone
> 
> Although it is made apparent in TimeZone that certain 3-letter IDs are deprecated, it does not actually list them in the specification. In addition to linking the full list, it is clarified that not _all_ 3-letter IDs are deprecated, as there are quite a few that come from the tzdb.
> 
> This change links to the full list found in ZoneId.

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

  Clarify wording on deprecation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14861/files
  - new: https://git.openjdk.org/jdk/pull/14861/files/3919ad19..85588211

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

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

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

From jlu at openjdk.org  Thu Jul 13 20:27:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Jul 2023 20:27:33 GMT
Subject: RFR: 8311968: Clarify Three-letter time zone IDs in
 java.util.TimeZone [v2]
In-Reply-To: <-2chC3MkWU8N4XFEW8inDX7XYbZ62WoNad9Z5HIvlVQ=.7d0dfcaf-4040-4add-9e30-9cb33db113b8@github.com>
References: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
 <DqBjaXMYN3Szcab5xf1XrSt9U1rpATZ5Son-uCg_kWQ=.81705488-34b9-4c35-b360-d7d114c3ee73@github.com>
 <-2chC3MkWU8N4XFEW8inDX7XYbZ62WoNad9Z5HIvlVQ=.7d0dfcaf-4040-4add-9e30-9cb33db113b8@github.com>
Message-ID: <qr_MsmecKf7TL7l6HHZRsgzR3ubEQkF3x9NKEOCg09s=.f362ab0c-b0d5-4ab7-89d6-360596f4fd6a@github.com>

On Thu, 13 Jul 2023 19:38:35 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: update wording to include mappings
>
> src/java.base/share/classes/java/util/TimeZone.java line 135:
> 
>> 133:  * recognize one of them. The full list of the deprecated IDs and their mappings
>> 134:  * can be viewed at {@link java.time.ZoneId#SHORT_IDS}. It should be noted that
>> 135:  * not all three-letter time zone IDs are deprecated, as some come from the IANA
> 
> This is a bit confusing at least to me as I did not see which SHORT_IDS were not deprecated via the link above, but perhaps I missed it.

I see your point, the intent was that there exists three-letter time zone IDs and only the deprecated ones were at `SHORT_IDS`. I have updated the wording to explicitly clarify this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14861#discussion_r1263019145

From iris at openjdk.org  Thu Jul 13 21:02:18 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 13 Jul 2023 21:02:18 GMT
Subject: [jdk21] RFR: 6960866: [Fmt-Ch] ChoiceFormat claims impossible and
 unimplemented functionality
In-Reply-To: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>
References: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>
Message-ID: <PczmmJ9mI5_G8O8PT2hs8FuNnAk-fXJJoAqHyhB9SRk=.08b82364-9859-4cb2-8ef1-a9a5be71cb7b@github.com>

On Thu, 13 Jul 2023 18:28:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which backports https://github.com/openjdk/jdk/commit/6cb9ec32a68634f0b6f7461c9dc7ef0c0e59861d
> 
> Thank you

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/125#pullrequestreview-1529236511

From jlu at openjdk.org  Thu Jul 13 21:17:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Jul 2023 21:17:14 GMT
Subject: RFR: 8311968: Clarify Three-letter time zone IDs in
 java.util.TimeZone [v2]
In-Reply-To: <qr_MsmecKf7TL7l6HHZRsgzR3ubEQkF3x9NKEOCg09s=.f362ab0c-b0d5-4ab7-89d6-360596f4fd6a@github.com>
References: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
 <DqBjaXMYN3Szcab5xf1XrSt9U1rpATZ5Son-uCg_kWQ=.81705488-34b9-4c35-b360-d7d114c3ee73@github.com>
 <-2chC3MkWU8N4XFEW8inDX7XYbZ62WoNad9Z5HIvlVQ=.7d0dfcaf-4040-4add-9e30-9cb33db113b8@github.com>
 <qr_MsmecKf7TL7l6HHZRsgzR3ubEQkF3x9NKEOCg09s=.f362ab0c-b0d5-4ab7-89d6-360596f4fd6a@github.com>
Message-ID: <bY4Dkun29-40ffrxoZCr9YESs8EMsewM-x6luDeGxH0=.297ce037-b8c0-4148-8e25-04cd96d902d0@github.com>

On Thu, 13 Jul 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/TimeZone.java line 135:
>> 
>>> 133:  * recognize one of them. The full list of the deprecated IDs and their mappings
>>> 134:  * can be viewed at {@link java.time.ZoneId#SHORT_IDS}. It should be noted that
>>> 135:  * not all three-letter time zone IDs are deprecated, as some come from the IANA
>> 
>> This is a bit confusing at least to me as I did not see which SHORT_IDS were not deprecated via the link above, but perhaps I missed it.
>
> I see your point, the intent was that there exists three-letter time zone IDs and only the deprecated ones were at `SHORT_IDS`. I have updated the wording to explicitly clarify this.

Please disregard the previous message, I talked with Naoto and all the three-letter time zone IDs (and four-letter) are deprecated regardless if they are from the JDK or TZDB, so I will readjust the wording again

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14861#discussion_r1263059906

From jlu at openjdk.org  Thu Jul 13 22:43:27 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Jul 2023 22:43:27 GMT
Subject: RFR: 8311968: Clarify Three-letter time zone IDs in
 java.util.TimeZone [v4]
In-Reply-To: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
References: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
Message-ID: <rRnlbdl-_ApQV9Nq5_VrtaYyBEFdWqan6y9ExfSa-To=.38725c42-c89b-42cf-b710-9fa37466128f@github.com>

> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8311979) which links the full list of deprecated three-letter IDs in java.util.TimeZone
> 
> Although it is made apparent in TimeZone that certain 3-letter IDs are deprecated, it does not actually list them in the specification. In addition to linking the full list, it is clarified that not _all_ 3-letter IDs are deprecated, as there are quite a few that come from the tzdb.
> 
> This change links to the full list found in ZoneId.

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

  Need only link to SHORT_IDS, mentioning tzdb beyond scope

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14861/files
  - new: https://git.openjdk.org/jdk/pull/14861/files/85588211..4a3a8d11

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

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

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

From jlu at openjdk.org  Thu Jul 13 22:44:23 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Jul 2023 22:44:23 GMT
Subject: [jdk21] Integrated: 6960866: [Fmt-Ch] ChoiceFormat claims impossible
 and unimplemented functionality
In-Reply-To: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>
References: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>
Message-ID: <UYWjluBODVkIfGKHRw_kkiri4f1maOdD69zGmyayn3Y=.aa55c8ea-66e5-43c3-b81c-188330ec9565@github.com>

On Thu, 13 Jul 2023 18:28:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which backports https://github.com/openjdk/jdk/commit/6cb9ec32a68634f0b6f7461c9dc7ef0c0e59861d
> 
> Thank you

This pull request has now been integrated.

Changeset: d370b96f
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/d370b96fb62c9aa2be9035ce1797acaaed764d45
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

6960866: [Fmt-Ch] ChoiceFormat claims impossible and unimplemented functionality

Reviewed-by: naoto, lancea, iris
Backport-of: 6cb9ec32a68634f0b6f7461c9dc7ef0c0e59861d

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

PR: https://git.openjdk.org/jdk21/pull/125

From duke at openjdk.org  Thu Jul 13 22:47:16 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 13 Jul 2023 22:47:16 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v6]
In-Reply-To: <JLu2abTrdYaA72UojilLoZe14xxNRQUAAnS_G9pGNpY=.3692be64-289d-4562-b089-e5d9b50df928@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <JLu2abTrdYaA72UojilLoZe14xxNRQUAAnS_G9pGNpY=.3692be64-289d-4562-b089-e5d9b50df928@github.com>
Message-ID: <ha8izNcLGIQr2M5FrWx01Kh4g50UKLgojqES5cA9zQs=.eea94804-bad7-4143-992c-2eaa4697c68d@github.com>

On Thu, 13 Jul 2023 19:21:01 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 with a new target base 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 JDK-8301341
>  - Simplify contention handling; fix test
>  - Fix inverted test assert; improve internal documentation; simplify code
>  - 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

Need to digest this a bit. Will give more concrete feedback ASAP :)

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 180:

> 178:      * increase CAS contention and overhead. Using the smallest
> 179:      * non-zero value of one is both simple and empirically a good
> 180:      * choice in most applicatkions.  The slack value is hard-wired: a

s/applicatkions/applications

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

PR Review: https://git.openjdk.org/jdk/pull/14317#pullrequestreview-1510867492
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1263111307

From duke at openjdk.org  Thu Jul 13 22:47:21 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 13 Jul 2023 22:47:21 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v5]
In-Reply-To: <7Imcm_Lg2tLsQs1UdndLA6xKrfRBSTRThh3LcULgpzY=.245e0de8-1035-4778-851d-12bd3d43559f@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <7Imcm_Lg2tLsQs1UdndLA6xKrfRBSTRThh3LcULgpzY=.245e0de8-1035-4778-851d-12bd3d43559f@github.com>
Message-ID: <YvSbGVe6xc6hllC71O8smG3nJa_IOWl3sPTzFXM_EGs=.f5a123ca-8c87-44d8-a918-f3383911d05d@github.com>

On Fri, 30 Jun 2023 19:38:19 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:
> 
>   Fix inverted test assert; improve internal documentation; simplify code

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 144:

> 142:      * nodes, CASing from null to a data value.  (To reduce the need
> 143:      * for re-reads, we use the compareAndExchange forms of CAS for
> 144:      * pointer updates, that provide the current value to comtinue

Suggestion:

     * pointer updates, that provide the current value to continue

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 158:

> 156:      * suffix of zero or more unmatched nodes. Note that we allow both
> 157:      * the prefix and suffix to be zero length, which in turn means
> 158:      * that we do not require a dummy header.

@DougLea Great to avoid having the dummy header ?

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 484:

> 482:      * be at least 4.
> 483:      */
> 484:     private static final int MAX_SLACK = 1 << 7;

@DougLea Any guidance on how to tune this parameter? ?

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 570:

> 568:         boolean haveData = (e != null);
> 569:         TransferNode p;                     // current traversal node
> 570:         TransferNode s = null;              // the enqueued npde, if needed

Suggestion:

        TransferNode s = null;              // the enqueued node, if needed

src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java line 133:

> 131:      *     compareAndExchange form of CAS for pointer updates to reduce
> 132:      *     memory traffic. The Fifo version accommodates lazy
> 133:      *     updates and slack as desxcribed in the LinkedTransferQueue

Suggestion:

     *     updates and slack as described in the LinkedTransferQueue

src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java line 136:

> 134:      *     internal documentation.
> 135:      *  2. SynchronousQueues must block threads waiting to become
> 136:      *     fulfilled, preceded by brief spins at/mear front positions

Suggestion:

     *     fulfilled, preceded by brief spins at/near front positions

src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java line 148:

> 146:     /**
> 147:      * Extension of LinkedTransferQueue to support Lifo (stack) mode.
> 148:      * Methods use tha "tail" field as top of stack (versus tail of

Suggestion:

     * Methods use the "tail" field as top of stack (versus tail of

src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java line 149:

> 147:      * Extension of LinkedTransferQueue to support Lifo (stack) mode.
> 148:      * Methods use tha "tail" field as top of stack (versus tail of
> 149:      * queue). Note that popped nodes are not self-linked because thay

Suggestion:

     * queue). Note that popped nodes are not self-linked because they

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1250693753
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1250699320
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1255848871
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1251121355
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1250629998
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1250630384
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1250637093
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1250637972

From duke at openjdk.org  Thu Jul 13 23:05:48 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 13 Jul 2023 23:05:48 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
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: <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@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 15 additional commits since the last revision:

 - Merge branch 'openjdk:master' into unsafe
 - add 8310843 to @bug
 - 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
 - ... and 5 more: https://git.openjdk.org/jdk/compare/c32a834b...cb56e736

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14636/files
  - new: https://git.openjdk.org/jdk/pull/14636/files/7cfef770..cb56e736

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

  Stats: 66403 lines in 1073 files changed: 14359 ins; 48801 del; 3243 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 jlu at openjdk.org  Thu Jul 13 23:31:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Jul 2023 23:31:40 GMT
Subject: RFR: 8311663: Additional refactoring of Locale tests to JUnit
Message-ID: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>

Please review this PR which refactors more java.util.Locale tests to JUnit with some minor cleanup as well.

Although some of the files could benefit from being renamed bugNNNNNNN to something more descriptive, this makes reviewing harder, and will be handled separately.

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

Commit messages:
 - Same as prev commit
 - Remove try catch in Bug8135061.java
 - Missing import in Bug8166994.java
 - Refactor HashCodeTest.java
 - Refactor Bug6989440.java
 - Refactor ThaiGov.java
 - Refactor UseOldISOCodesTest.java
 - Refactor FilteringModeTest.java
 - Refactor Bug8159420.java
 - Refactor Bug8166994.java
 - ... and 3 more: https://git.openjdk.org/jdk/compare/292ee630...933c0312

Changes: https://git.openjdk.org/jdk/pull/14881/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14881&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311663
  Stats: 575 lines in 10 files changed: 173 ins; 233 del; 169 mod
  Patch: https://git.openjdk.org/jdk/pull/14881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14881/head:pull/14881

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

From darcy at openjdk.org  Fri Jul 14 00:40:17 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jul 2023 00:40:17 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types [v2]
In-Reply-To: <kQkaCbpl40k-iwJn-omUvbcPOCVwnfe3UhGRuTuPezg=.7239465c-af53-4e08-96e5-c44f4b17cd74@github.com>
References: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
 <kQkaCbpl40k-iwJn-omUvbcPOCVwnfe3UhGRuTuPezg=.7239465c-af53-4e08-96e5-c44f4b17cd74@github.com>
Message-ID: <wXs8e3KelH_1Ho_wOQj972SWLTkTt-Zqm0Jl_QkE6Yo=.c548ec8d-8146-405d-a223-aa1cb5b00c84@github.com>

On Mon, 10 Jul 2023 20:24:30 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.
>
> 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:
> 
>  - Update API proposal.
>  - Merge branch 'master' into JDK-6361826
>  - JDK-6361826: (reflect) provide method for mapping strings to class object for primitive types

Responding to some off-list discussion, within the JDK, ObjectInputStream.resolveClass would benefit from having the proposed method; it has what amounts to an internal implementation of the method already.

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

PR Comment: https://git.openjdk.org/jdk/pull/14743#issuecomment-1635092577

From jpai at openjdk.org  Fri Jul 14 01:08:19 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Jul 2023 01:08:19 GMT
Subject: [jdk21] RFR: 8311867: StructuredTaskScope.shutdown does not
 interrupt newly started threads
In-Reply-To: <TCs3mKOaPnXUxufPKEnMQvbRSXZNJqT4YvYMs-jNHeY=.9c3729ec-950f-4262-87a6-cddd8371f33d@github.com>
References: <TCs3mKOaPnXUxufPKEnMQvbRSXZNJqT4YvYMs-jNHeY=.9c3729ec-950f-4262-87a6-cddd8371f33d@github.com>
Message-ID: <TtiZmd9W9iQ5r2FyOGi6O4VqXZzHyFKLqeyarY1D5bA=.c03926b3-b547-440e-8a90-82cff617c437@github.com>

On Thu, 13 Jul 2023 15:58:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Clean backport of https://git.openjdk.org/jdk/pull/14833

P3 bug fix, approved for backport.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/123#pullrequestreview-1529421300

From darcy at openjdk.org  Fri Jul 14 02:54:59 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jul 2023 02:54:59 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types [v3]
In-Reply-To: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
References: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
Message-ID: <_tiDblw9SaGH18fI-2L9bZmSDqrtZB0lWUP0OHtLkGE=.e531d5bf-dbe7-47d5-ad06-b82ae1d6e591@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.

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:

 - Use new API in serialization; add tests.
 - Merge branch 'master' into JDK-6361826
 - Update API proposal.
 - Merge branch 'master' into JDK-6361826
 - JDK-6361826: (reflect) provide method for mapping strings to class object for primitive types

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14743/files
  - new: https://git.openjdk.org/jdk/pull/14743/files/e16b4e90..a106b12c

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

  Stats: 2270 lines in 105 files changed: 1508 ins; 592 del; 170 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 duke at openjdk.org  Fri Jul 14 03:30:25 2023
From: duke at openjdk.org (Chris Hennick)
Date: Fri, 14 Jul 2023 03:30:25 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: <9kk58tLH_H9Hv9_GEdIxcpJzdpSMYbOgePMWETQXqOs=.bd193127-30cc-47fe-8f6d-ddeb785bbec4@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 @turbanoff @rgiulietti Could this please be merged?

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

PR Comment: https://git.openjdk.org/jdk/pull/8131#issuecomment-1635214244

From ascarpino at openjdk.org  Fri Jul 14 03:45:47 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 14 Jul 2023 03:45:47 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base [v4]
In-Reply-To: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
Message-ID: <2UmfWx8vlC4edcNuIKfx34nf8n1rZ5xKes8w4okuOQU=.288bbe5e-4b34-4e02-b29d-b8fb73bb4366@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 tier2 JLinkOptionsTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14457/files
  - new: https://git.openjdk.org/jdk/pull/14457/files/cf8e954d..b10c7ebd

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

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 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 alanb at openjdk.org  Fri Jul 14 05:16:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Jul 2023 05:16:29 GMT
Subject: [jdk21] Integrated: 8311867: StructuredTaskScope.shutdown does not
 interrupt newly started threads
In-Reply-To: <TCs3mKOaPnXUxufPKEnMQvbRSXZNJqT4YvYMs-jNHeY=.9c3729ec-950f-4262-87a6-cddd8371f33d@github.com>
References: <TCs3mKOaPnXUxufPKEnMQvbRSXZNJqT4YvYMs-jNHeY=.9c3729ec-950f-4262-87a6-cddd8371f33d@github.com>
Message-ID: <JAvMqxV1WQu1s52WUunQI2f406Lv99Tqi_4yYd5ffHQ=.5225c40d-d734-486b-9431-3f6bebc381ca@github.com>

On Thu, 13 Jul 2023 15:58:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Clean backport of https://git.openjdk.org/jdk/pull/14833

This pull request has now been integrated.

Changeset: 281aee96
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/281aee968aae70005f64dd97fa288c7ba0490e49
Stats:     99 lines in 3 files changed: 95 ins; 0 del; 4 mod

8311867: StructuredTaskScope.shutdown does not interrupt newly started threads

Reviewed-by: jpai
Backport-of: 92a04e201e68aa4d682053cef4b36180ec5620f5

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

PR: https://git.openjdk.org/jdk21/pull/123

From alanb at openjdk.org  Fri Jul 14 06:21:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Jul 2023 06:21:56 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base [v4]
In-Reply-To: <2UmfWx8vlC4edcNuIKfx34nf8n1rZ5xKes8w4okuOQU=.288bbe5e-4b34-4e02-b29d-b8fb73bb4366@github.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
 <2UmfWx8vlC4edcNuIKfx34nf8n1rZ5xKes8w4okuOQU=.288bbe5e-4b34-4e02-b29d-b8fb73bb4366@github.com>
Message-ID: <kcSuYEVOrhgP2vOHeFmGkM78gGY5Ed2X7qmRWE8qZ8g=.2bd93128-c6c8-447c-b090-f9c7e8c356da@github.com>

On Fri, 14 Jul 2023 03:45:47 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 tier2 JLinkOptionsTest

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14457#pullrequestreview-1529689186

From coffeys at openjdk.org  Fri Jul 14 07:24:58 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 14 Jul 2023 07:24:58 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v11]
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: <cxVDEAXp3wDvxrHPtGXix1U1dgp2wz35bAOd2aNfjfU=.dbbfcad3-680d-42f5-b8ce-f37c9c07aa69@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 21 additional commits since the last revision:

 - Testcase correction
 - Merge branch 'master' into 8281658-showsettings-security
 - Harden code to report lack of SSL support
 - Testcase correction
 - tweaks based on latest reviews
 - Merge branch 'master' into 8281658-showsettings-security
 - 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
 - ... and 11 more: https://git.openjdk.org/jdk/compare/5a42dce4...5b8fc0b9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14394/files
  - new: https://git.openjdk.org/jdk/pull/14394/files/559f698e..5b8fc0b9

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

  Stats: 15871 lines in 519 files changed: 8231 ins; 7026 del; 614 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 Jul 14 07:34:29 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 14 Jul 2023 07:34:29 GMT
Subject: Integrated: 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: <VeKhGl_UPFPtJWC3TNFdCZjKYRj1BlxIusTAtkXct3w=.d9584d72-825c-46c1-885f-99e8d37d91cd@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

This pull request has now been integrated.

Changeset: 2e12a123
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e12a123c9955b7360fd752a6a33d59b6271c5af
Stats:     320 lines in 5 files changed: 314 ins; 2 del; 4 mod

8281658: Add a security category to the java -XshowSettings option

Reviewed-by: rriggs, mullan

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

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

From duke at openjdk.org  Fri Jul 14 08:43:18 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 14 Jul 2023 08:43:18 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() throws UOE if invoked
 reflectively [v3]
In-Reply-To: <BhLE3dfNH4BcJr1wdYplaRLON1PAABl_Kxw9bE0S36k=.388595b3-0094-41af-ad7c-ce8183fb72b2@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
 <BhLE3dfNH4BcJr1wdYplaRLON1PAABl_Kxw9bE0S36k=.388595b3-0094-41af-ad7c-ce8183fb72b2@github.com>
Message-ID: <EIBoiXC0olHRvzKm0anSO3x1H5_NyucgZukmuJqv0xQ=.f255a370-9dec-4054-a160-3126c64295ec@github.com>

On Tue, 11 Jul 2023 15:47:35 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> As the included jtreg test demonstrates, `StackWalker.getCallerClass()` can throw an `UnsupportedOperationException` if called reflectively. Currently this only happens if we invoke `StackWalker.getCallerClass()` recursively reflectively, but this issue will become more prominent once we fix [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447). The gory details follow below:
>> 
>> The protocol between the Java API and the JVM for `StackWalker.getCallerClass()/walk()` is as follows:
>> - On the Java side, `StackWalker` calls into `StackStreamFactory` for the real work.
>> - For `StackWalker.getCallerClass()` `StackStreamFactory` basically creates a `Class[]` which will be passed down and filled in the JVM. For `StackWalker.walk()` it will normally be a `StackFrameInfo[]` (or a `LiveStackFrameInfo[]` if the internal `ExtendedOption.LOCALS_AND_OPERANDS` option was used).
>> - The default size of this arrays is currently `StackStreamFactory.SMALL_BATCH` which is 8 (but see [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447)).
>> - `StackStreamFactory` than calls `AbstractStackWalker.callStackWalk()` which is a natively implemented in the VM by `JVM_CallStackWalk()`.
>> -  `JVM_CallStackWalk()` calls `StackWalk::walk()` which calls `StackWalk::fetchFirstBatch()` which calls `StackWalk::fill_in_frames()` which walks the stack and fills in the available class/stackframe slots in the passed in array until the array is full or there are no more stack frames,
>> - Once  `StackWalk::fill_in_frames()` returns, `StackWalk::fetchFirstBatch()` calls back to Java by invoking `AbstractStackWalker::doStackWalk()` to consume the result.
>> - `AbstractStackWalker::doStackWalk()` calls `consumeFrames()` (which is overridden depending on whether we initially called `getCallerClass()` or `walk()`) which consumes the frames until it either finishes (e.g. finds the caller class) or until there are no more frames.
>> - In the latter case `consumeFrames()` will call into the the VM again by calling `AbstractStackWalker.fetchStackFrames()` to fetch additional frames from the stack.
>> - `AbstractStackWalker.fetchStackFrames()` is implemented by `JVM_MoreStackWalk()` which calls `StackWalk::fetchNextBatch()` which calls `StackWalk::fill_in_frames()` (the same method that already fetched the initial batch of frames).
>> 
>> Following is a stacktrace of what I've explained so far:
>> 
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x1...
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed case when calling getCallerClass() from a @CallerSensitive method reflectively

src/hotspot/share/prims/stackwalk.cpp line 164:

> 162:     method->method_holder()->is_subtype_of(constructor_accessor) ||
> 163:     // MethodHandle frames are not hidden and StackWalker::getCallerClass has to filter them out
> 164:     method->method_holder()->name()->starts_with("java/lang/invoke"));

Shouldn?t this?be:
Suggestion:

    method->method_holder()->name()->starts_with("java/lang/invoke/"));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14773#discussion_r1263467101

From simonis at openjdk.org  Fri Jul 14 09:38:58 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 14 Jul 2023 09:38:58 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() throws UOE if invoked
 reflectively [v3]
In-Reply-To: <EIBoiXC0olHRvzKm0anSO3x1H5_NyucgZukmuJqv0xQ=.f255a370-9dec-4054-a160-3126c64295ec@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
 <BhLE3dfNH4BcJr1wdYplaRLON1PAABl_Kxw9bE0S36k=.388595b3-0094-41af-ad7c-ce8183fb72b2@github.com>
 <EIBoiXC0olHRvzKm0anSO3x1H5_NyucgZukmuJqv0xQ=.f255a370-9dec-4054-a160-3126c64295ec@github.com>
Message-ID: <6eWskV7TxrdcO1sxuenv_afJOMj9AF-uBvtCjpNJBqY=.f20d0283-c913-46ed-879b-137b92971b48@github.com>

On Fri, 14 Jul 2023 08:39:44 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed case when calling getCallerClass() from a @CallerSensitive method reflectively
>
> src/hotspot/share/prims/stackwalk.cpp line 164:
> 
>> 162:     method->method_holder()->is_subtype_of(constructor_accessor) ||
>> 163:     // MethodHandle frames are not hidden and StackWalker::getCallerClass has to filter them out
>> 164:     method->method_holder()->name()->starts_with("java/lang/invoke"));
> 
> Shouldn?t this?be:
> Suggestion:
> 
>     method->method_holder()->name()->starts_with("java/lang/invoke/"));

Thanks, you're right, this is a copy/paste error. It currently doesn't make any difference, until somebody introduces a new package in `java.lang` that starts with `invoke*` :)

Fixed locally, will be in the next commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14773#discussion_r1263522481

From alanb at openjdk.org  Fri Jul 14 09:59:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Jul 2023 09:59:19 GMT
Subject: RFR: 8311992: Test
 java/lang/Thread/virtual/JfrEvents::testVirtualThreadPinned failed
Message-ID: <Teva40gyZFff2HILZpLYmrJxuMxPX_7hdlKa2wKsG24=.f85a15a0-d89a-4797-afae-89114e18abc5@github.com>

This is a test only update to a test for the JFR event jdk.VirtualThreadPinned event. The test we added in JDK 19 does 3 sleeps, one with a small duration, twice with a  long duration. The test enables the event with a threshold of 500ms and expects there will be two events recorded; no event for the sleep with the small duration. In extreme cases, it's possible that the short sleep takes more than 500ms so an event is recorded and the test fails. The test is changed to drop the threshold, it's not needed. It's also changed to explicitly park to avoid the long sleeps. A drive-by change is to print the events to System.err rather than System.out so they are inlined with the JUnit output (the original test was TestNG where the output went to System.out).

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

Commit messages:
 - Improve test
 - Merge
 - Initial commit

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

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

From coffeys at openjdk.org  Fri Jul 14 10:11:27 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 14 Jul 2023 10:11:27 GMT
Subject: RFR: 8310201: Reduce verbose locale output in -XshowSettings launcher
 option
Message-ID: <XXbMAO0gXhtWOhbs_iDqmQpdnus-xdEEY4sufnRb8No=.32addd37-6f00-4f63-8a9d-17784d1a405c@github.com>

Simple tweak to remove the "available locales" section from default `-XshowSettings` output.

Instead, it remains available with the `-XshowSettings:locale` option

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

Commit messages:
 - 8310201

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

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

From alanb at openjdk.org  Fri Jul 14 10:27:54 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Jul 2023 10:27:54 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base [v2]
In-Reply-To: <Lb7gqaFf_SOuR4pXtDc-Nv5HvoITkO2KwvFfKAaZmyg=.6cbdf125-b849-49cc-912b-e6878afafd88@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>
 <qNfFCDiE8DYJna7MXp77UnasD8Vg3iU6HBm5c4KVgu0=.0be8245d-3ff2-43b6-bd79-a258569013ad@github.com>
 <wcIqS-Z73fwLZICL2uhFveTBVYMYO2dtanzNtfm6PFA=.18624ed6-39fb-4b69-b777-7c293816d974@github.com>
 <Lb7gqaFf_SOuR4pXtDc-Nv5HvoITkO2KwvFfKAaZmyg=.6cbdf125-b849-49cc-912b-e6878afafd88@github.com>
Message-ID: <p75Ux1Pkzvj0y6hTkCnGu6SDj-nx0zJBmV21O93I7w8=.794977d0-1c39-49a6-a75d-6f16a2a0e3b2@github.com>

On Wed, 12 Jul 2023 16:17:49 GMT, Glavo <duke at openjdk.org> wrote:

>> Maybe a small suggestion to make it clear whats wanted here. In other projects I am involved in (Apache Lucene/Solr, Apache TIKA, PostgresSQL JDBC, Checkstyle itsself, Elasticserach/Opensearch), which use the [forbiddenapis Maven/Gradle/Ant plugin](https://github.com/policeman-tools/forbidden-apis/), we forbid all calls to several Java APIs (including toLowerCase/toUpperCase case). All bytecode using this will build failure (FYI, we also disallow other stuff like relying of default timezone or characterset).
>> To make it clear what is really intended, those projects agreed on having `toLowerCase(Locale.getDefault())`, so it is explicit what's wanted.
>> Without that it could be that somebody else starts the discussion again.
>> 
>> This is just a suggestion to be explicit as it makes maintaining the code easier.
>
>> Maybe a small suggestion to make it clear whats wanted here. In other projects I am involved in (Apache Lucene/Solr, Apache TIKA, PostgresSQL JDBC, Checkstyle itsself, Elasticserach/Opensearch), which use the [forbiddenapis Maven/Gradle/Ant plugin](https://github.com/policeman-tools/forbidden-apis/), we forbid all calls to several Java APIs (including toLowerCase/toUpperCase case). All bytecode using this will build failure (FYI, we also disallow other stuff like relying of default timezone or characterset). To make it clear what is really intended, those projects agreed on having `toLowerCase(Locale.getDefault())`, so it is explicit what's wanted. Without that it could be that somebody else starts the discussion again.
>> 
>> This is just a suggestion to be explicit as it makes maintaining the code easier.
> 
> I agree with this.
> 
> I'm working on deprecating `toLowerCase()` and `toUpperCase()`, this PR is part of that effort. I wish to convert all use cases of them to `toLowerCase(Locale)` and `toUpperCase(Locale)`.
> 
> More backstory is detailed in https://github.com/openjdk/jdk/pull/13434#issuecomment-1503989660.

> However, while I think this corrects the behavior, this caused a change in the behavior of the API, so a CSR may be required. I don't want to debate this in this PR, so I'll revert this change and open a new PR in the future.

StreamTokenizer is a very old API and changing long standing behavior may break something or be observable with existing code/usages. I see youve reverted this part (thanks) and looking at it separately is fine. It might be that the conclusion is that it's just too risky to change, in which case Uwe's suggestion is good and would avoid it showing up on someone's else radar in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1263570865

From jpai at openjdk.org  Fri Jul 14 10:28:11 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Jul 2023 10:28:11 GMT
Subject: RFR: 8311992: Test
 java/lang/Thread/virtual/JfrEvents::testVirtualThreadPinned failed
In-Reply-To: <Teva40gyZFff2HILZpLYmrJxuMxPX_7hdlKa2wKsG24=.f85a15a0-d89a-4797-afae-89114e18abc5@github.com>
References: <Teva40gyZFff2HILZpLYmrJxuMxPX_7hdlKa2wKsG24=.f85a15a0-d89a-4797-afae-89114e18abc5@github.com>
Message-ID: <DQDIPsZnlmsj3jqJGRMEpAzBE4zPh8eJaOsD_eJkxUg=.7b7e51b7-f9e8-4f54-a818-fa222df723b0@github.com>

On Fri, 14 Jul 2023 09:42:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only update to a test for the JFR event jdk.VirtualThreadPinned event. The test we added in JDK 19 does 3 sleeps, one with a small duration, twice with a  long duration. The test enables the event with a threshold of 500ms and expects there will be two events recorded; no event for the sleep with the small duration. In extreme cases, it's possible that the short sleep takes more than 500ms so an event is recorded and the test fails. The test is changed to drop the threshold, it's not needed. It's also changed to explicitly park to avoid the long sleeps. A drive-by change is to print the events to System.err rather than System.out so they are inlined with the JUnit output (the original test was TestNG where the output went to System.out).

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14884#pullrequestreview-1530046120

From jpai at openjdk.org  Fri Jul 14 11:05:13 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Jul 2023 11:05:13 GMT
Subject: RFR: 8310201: Reduce verbose locale output in -XshowSettings
 launcher option
In-Reply-To: <XXbMAO0gXhtWOhbs_iDqmQpdnus-xdEEY4sufnRb8No=.32addd37-6f00-4f63-8a9d-17784d1a405c@github.com>
References: <XXbMAO0gXhtWOhbs_iDqmQpdnus-xdEEY4sufnRb8No=.32addd37-6f00-4f63-8a9d-17784d1a405c@github.com>
Message-ID: <5kuWuwrsbNJFMhMtcRqGMbBD8YNiR5i3B4C5MUXnPf4=.e3409ab0-3a9d-4580-abf1-74d069088c0b@github.com>

On Fri, 14 Jul 2023 10:01:16 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Simple tweak to remove the "available locales" section from default `-XshowSettings` output.
> 
> Instead, it remains available with the `-XshowSettings:locale` option

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 289:

> 287:         } else {
> 288:             ostream.println("Locale settings summary:");
> 289:             ostream.println(INDENT + "Use \":locale\" " +

Hello Sean, should this instead say "Use "-XshowSettings:locale" ...." so that it's clear that this is a sub-option for the -XshowSettings option?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14885#discussion_r1263602411

From dqu at openjdk.org  Fri Jul 14 11:13:21 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Fri, 14 Jul 2023 11:13:21 GMT
Subject: Withdrawn: 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: <9sifJWoBtu5qbEABwwLzo_cjRoNSpIGHKi2dN4u_MEg=.0f9fbf9e-b78e-4f19-8062-79081b5f96cc@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.)

This pull request has been closed without being integrated.

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

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

From coffeys at openjdk.org  Fri Jul 14 11:21:02 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 14 Jul 2023 11:21:02 GMT
Subject: RFR: 8310201: Reduce verbose locale output in -XshowSettings
 launcher option [v2]
In-Reply-To: <XXbMAO0gXhtWOhbs_iDqmQpdnus-xdEEY4sufnRb8No=.32addd37-6f00-4f63-8a9d-17784d1a405c@github.com>
References: <XXbMAO0gXhtWOhbs_iDqmQpdnus-xdEEY4sufnRb8No=.32addd37-6f00-4f63-8a9d-17784d1a405c@github.com>
Message-ID: <BPrP3Pa6WhxrJ8P2FGEB3ChHNbOntS-1KGgjKTKnjWA=.099be2de-de27-4d3c-a25d-dabaaa2efcc7@github.com>

> Simple tweak to remove the "available locales" section from default `-XshowSettings` output.
> 
> Instead, it remains available with the `-XshowSettings:locale` option

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

  review feedback and bug id added to test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14885/files
  - new: https://git.openjdk.org/jdk/pull/14885/files/0366dcc5..2aeec368

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

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

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

From coffeys at openjdk.org  Fri Jul 14 11:21:04 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 14 Jul 2023 11:21:04 GMT
Subject: RFR: 8310201: Reduce verbose locale output in -XshowSettings
 launcher option [v2]
In-Reply-To: <5kuWuwrsbNJFMhMtcRqGMbBD8YNiR5i3B4C5MUXnPf4=.e3409ab0-3a9d-4580-abf1-74d069088c0b@github.com>
References: <XXbMAO0gXhtWOhbs_iDqmQpdnus-xdEEY4sufnRb8No=.32addd37-6f00-4f63-8a9d-17784d1a405c@github.com>
 <5kuWuwrsbNJFMhMtcRqGMbBD8YNiR5i3B4C5MUXnPf4=.e3409ab0-3a9d-4580-abf1-74d069088c0b@github.com>
Message-ID: <6q29rI39379DAFsTNhflahvWXpxG5tzHhRa66EODhi0=.a59641ba-a882-4352-b11e-d4b33d35602f@github.com>

On Fri, 14 Jul 2023 11:02:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review feedback and bug id added to test
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 289:
> 
>> 287:         } else {
>> 288:             ostream.println("Locale settings summary:");
>> 289:             ostream.println(INDENT + "Use \":locale\" " +
> 
> Hello Sean, should this instead say "Use "-XshowSettings:locale" ...." so that it's clear that this is a sub-option for the -XshowSettings option?

Yes, no harm to be clearer Jai. Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14885#discussion_r1263614727

From jpai at openjdk.org  Fri Jul 14 11:26:14 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Jul 2023 11:26:14 GMT
Subject: RFR: 8310201: Reduce verbose locale output in -XshowSettings
 launcher option [v2]
In-Reply-To: <BPrP3Pa6WhxrJ8P2FGEB3ChHNbOntS-1KGgjKTKnjWA=.099be2de-de27-4d3c-a25d-dabaaa2efcc7@github.com>
References: <XXbMAO0gXhtWOhbs_iDqmQpdnus-xdEEY4sufnRb8No=.32addd37-6f00-4f63-8a9d-17784d1a405c@github.com>
 <BPrP3Pa6WhxrJ8P2FGEB3ChHNbOntS-1KGgjKTKnjWA=.099be2de-de27-4d3c-a25d-dabaaa2efcc7@github.com>
Message-ID: <guaJE5bal4zVpKmCxwkVd9cApWUqlYpytQEkgRRbz8E=.c4602c3b-96b1-4725-963e-8cd72f7b2209@github.com>

On Fri, 14 Jul 2023 11:21:02 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Simple tweak to remove the "available locales" section from default `-XshowSettings` output.
>> 
>> Instead, it remains available with the `-XshowSettings:locale` option
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback and bug id added to test

Thank you Sean for the update. Looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14885#pullrequestreview-1530122813

From prappo at openjdk.org  Fri Jul 14 11:51:12 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 14 Jul 2023 11:51:12 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
Message-ID: <C8uy3l7qGSTq5jCB0q-HvUKvmsaR-is7Hx8ccw21yXw=.3ac45c28-e09d-4d03-bbd8-14e3119692bf@github.com>

On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR adds an internal method to calculate hash code from the provided integer array, offset and length into that array, and the initial hash code value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's either ArraysSupport.vectorizedHashCode with an offset, length and initial value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling. Unfortunately, it's the only hash code method that operates on an array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, behaviour which was specified but untested.

Found one more use case for hashCode on an array subrange:

https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java#L3381-L3389

Sadly, ArraysSupport cannot be used there because it's not in the same module.

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

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1635748185

From prappo at openjdk.org  Fri Jul 14 12:21:32 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 14 Jul 2023 12:21:32 GMT
Subject: RFR: 8312089: Simplify and modernize equals, hashCode,
 and compareTo in java.nio and implementation code
Message-ID: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>

Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for in java.nio and implementation code.

Please note, test results are pending.

Additional notes:

* This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements.

* java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified.

* Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it.

* This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification.

* sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose.

* Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith.

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

Commit messages:
 - Fix a doc comment
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14886/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14886&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312089
  Stats: 129 lines in 14 files changed: 12 ins; 69 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/14886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14886/head:pull/14886

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

From prappo at openjdk.org  Fri Jul 14 12:21:32 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 14 Jul 2023 12:21:32 GMT
Subject: RFR: 8312089: Simplify and modernize equals, hashCode,
 and compareTo in java.nio and implementation code
In-Reply-To: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
Message-ID: <lPQXEq6XGgYpWyGvP4FEoV3RWRetJ7wzjdck29rPjR8=.a74a8a82-0ae1-403f-9a53-f5c21796ee57@github.com>

On Fri, 14 Jul 2023 12:06:29 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 in java.nio and implementation code.
> 
> Please note, test results are pending.
> 
> Additional notes:
> 
> * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements.
> 
> * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified.
> 
> * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it.
> 
> * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification.
> 
> * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose.
> 
> * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith.

src/java.base/share/classes/java/nio/charset/Charset.java line 963:

> 961: 
> 962:     /**
> 963:      * {@return Computes a hashcode for this charset}

Oops. Should be this instead:

    {@return a hashcode for this charset}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263662782

From alanb at openjdk.org  Fri Jul 14 12:41:01 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Jul 2023 12:41:01 GMT
Subject: RFR: 8312089: Simplify and modernize equals, hashCode,
 and compareTo in java.nio and implementation code
In-Reply-To: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
Message-ID: <H_qrpdi42czYhiMJKICaLd9b44dvKH0jx2QUqL3yrs0=.3fd4f34e-3475-4d52-9a6f-580752659268@github.com>

On Fri, 14 Jul 2023 12:06:29 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 in java.nio and implementation code.
> 
> Please note, test results are pending.
> 
> Additional notes:
> 
> * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements.
> 
> * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified.
> 
> * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it.
> 
> * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification.
> 
> * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose.
> 
> * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith.

src/java.base/share/classes/java/nio/charset/Charset.java line 957:

> 955:      *         is less than, equal to, or greater than the specified charset
> 956:      */
> 957:     @Override

This PR adds `@Override` to a subset of the overridden methods, probably best to add it to all overridden methods so we don't end up with a mix.

src/java.base/share/classes/java/nio/charset/Charset.java line 963:

> 961: 
> 962:     /**
> 963:      * {@return a hashcode for this charset}

If you changing this then probably better to use "the hashcode".

src/java.base/share/classes/java/nio/file/attribute/FileTime.java line 368:

> 366:                 return cmp;
> 367:             }
> 368:             return Long.compare(toExcessNanos(days), other.toExcessNanos(daysOther));

Maybe a coin toss, but I think the original code was a bit clearer.

src/java.base/unix/classes/sun/nio/fs/UnixFileKey.java line 53:

> 51:         if (!(obj instanceof UnixFileKey other))
> 52:             return false;
> 53:         return (this.st_dev == other.st_dev) && (this.st_ino == other.st_ino);

Style-wise, I think usages like this are a bit easier to read.

        return obj instanceof UnixFileKey other
                && (this.st_dev == other.st_dev)
                && (this.st_ino == other.st_ino);

src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 712:

> 710:         int thatPos = that.offsets[0];
> 711:         return Arrays.equals(this.path, thisPos, thisLen, that.path, thatPos,
> 712:                 thatLen);

Might be cleaner to not put a line break here.

src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 731:

> 729:         if (h == 0) {
> 730:             h = ArraysSupport.vectorizedHashCode(path, 0, path.length, 0,
> 731:                     ArraysSupport.T_BOOLEAN);

Can you make this `/* unsigned bytes */ ArraysSupport.T_BOOLEAN`, or `ArraysSupport.T_BOOLEAN); // unsigned bytes`,  only because T_BOOLEAN isn't always obvious as use-sites.

src/java.base/windows/classes/sun/nio/ch/FileKey.java line 52:

> 50:         return (int)(dwVolumeSerialNumber ^ (dwVolumeSerialNumber >>> 32)) +
> 51:                (int)(nFileIndexHigh ^ (nFileIndexHigh >>> 32)) +
> 52:                (int)(nFileIndexLow ^ (nFileIndexLow >>> 32));

Well spotted, probably a cut and paste error at some point, but benign, the resulting hash code is still okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263667696
PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263666839
PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263677841
PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263671563
PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263679533
PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263684952
PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263680738

From duke at openjdk.org  Fri Jul 14 13:05:14 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 14 Jul 2023 13:05:14 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base [v2]
In-Reply-To: <p75Ux1Pkzvj0y6hTkCnGu6SDj-nx0zJBmV21O93I7w8=.794977d0-1c39-49a6-a75d-6f16a2a0e3b2@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>
 <qNfFCDiE8DYJna7MXp77UnasD8Vg3iU6HBm5c4KVgu0=.0be8245d-3ff2-43b6-bd79-a258569013ad@github.com>
 <wcIqS-Z73fwLZICL2uhFveTBVYMYO2dtanzNtfm6PFA=.18624ed6-39fb-4b69-b777-7c293816d974@github.com>
 <Lb7gqaFf_SOuR4pXtDc-Nv5HvoITkO2KwvFfKAaZmyg=.6cbdf125-b849-49cc-912b-e6878afafd88@github.com>
 <p75Ux1Pkzvj0y6hTkCnGu6SDj-nx0zJBmV21O93I7w8=.794977d0-1c39-49a6-a75d-6f16a2a0e3b2@github.com>
Message-ID: <picDy-h-ddC_h1hO0gzuV6xd-wUUnaSJdskQBlTxGIM=.0d274bff-b77d-4a0b-996b-1fd3c59b6608@github.com>

On Fri, 14 Jul 2023 10:24:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It might be that the conclusion is that it's just too risky to change, in which case Uwe's suggestion is good and would avoid it showing up on someone's else radar in the future.

Until we're sure we want to normalize a usage of `toLowerCase()` to one of `toLowerCase(Locale.ROOT)` or `toLowerCase(Locale.getDefault())`, I think it should be left here as-is, thus keeping it in an ambiguous state to remind us to continue discussing it in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1263710911

From prappo at openjdk.org  Fri Jul 14 13:16:27 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 14 Jul 2023 13:16:27 GMT
Subject: RFR: 8312089: Simplify and modernize equals, hashCode,
 and compareTo in java.nio and implementation code [v2]
In-Reply-To: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
Message-ID: <aPlljRyFAmMHxxmrnI-a9-caCvXwT-MUmZmHNuJ6wok=.76f1f291-9d99-4d4a-bac2-b89ba0c291bb@github.com>

> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for in java.nio and implementation code.
> 
> Please note, test results are pending.
> 
> Additional notes:
> 
> * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements.
> 
> * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified.
> 
> * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it.
> 
> * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification.
> 
> * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose.
> 
> * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith.

Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:

 - Address another case from feedback
 - Address feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14886/files
  - new: https://git.openjdk.org/jdk/pull/14886/files/ad22456d..a39780f5

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

  Stats: 21 lines in 6 files changed: 3 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/14886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14886/head:pull/14886

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

From duke at openjdk.org  Fri Jul 14 13:18:08 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 14 Jul 2023 13:18:08 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base [v2]
In-Reply-To: <picDy-h-ddC_h1hO0gzuV6xd-wUUnaSJdskQBlTxGIM=.0d274bff-b77d-4a0b-996b-1fd3c59b6608@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>
 <qNfFCDiE8DYJna7MXp77UnasD8Vg3iU6HBm5c4KVgu0=.0be8245d-3ff2-43b6-bd79-a258569013ad@github.com>
 <wcIqS-Z73fwLZICL2uhFveTBVYMYO2dtanzNtfm6PFA=.18624ed6-39fb-4b69-b777-7c293816d974@github.com>
 <Lb7gqaFf_SOuR4pXtDc-Nv5HvoITkO2KwvFfKAaZmyg=.6cbdf125-b849-49cc-912b-e6878afafd88@github.com>
 <p75Ux1Pkzvj0y6hTkCnGu6SDj-nx0zJBmV21O93I7w8=.794977d0-1c39-49a6-a75d-6f16a2a0e3b2@github.com>
 <picDy-h-ddC_h1hO0gzuV6xd-wUUnaSJdskQBlTxGIM=.0d274bff-b77d-4a0b-996b-1fd3c59b6608@github.com>
Message-ID: <fR-qsozihUcKtgZA3zegbWGh272Qjy48649sP0sxiB8=.627391bb-3e22-4746-99b2-4d18ac414439@github.com>

On Fri, 14 Jul 2023 13:01:46 GMT, Glavo <duke at openjdk.org> wrote:

>>> However, while I think this corrects the behavior, this caused a change in the behavior of the API, so a CSR may be required. I don't want to debate this in this PR, so I'll revert this change and open a new PR in the future.
>> 
>> StreamTokenizer is a very old API and changing long standing behavior may break something or be observable with existing code/usages. I see youve reverted this part (thanks) and looking at it separately is fine. It might be that the conclusion is that it's just too risky to change, in which case Uwe's suggestion is good and would avoid it showing up on someone's else radar in the future.
>
>> It might be that the conclusion is that it's just too risky to change, in which case Uwe's suggestion is good and would avoid it showing up on someone's else radar in the future.
> 
> Until we're sure we want to normalize a usage of `toLowerCase()` to one of `toLowerCase(Locale.ROOT)` or `toLowerCase(Locale.getDefault())`, I think it should be left here as-is, thus keeping it in an ambiguous state to remind us to continue discussing it in the future.

If we can't normalize this use case to be locale-independent, then I even think `lowerCaseMode` should be deprecated, because it's almost impossible for users to get expected behavior with this method.

In order to make it meaningful, I think it is still necessary to consider making it locale insensitive. We can allow users to fall back to the old behavior through new system properties, or introduce new API methods in `StreamTokenizer` to allow users to set the Locale to be used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1263725166

From forax at univ-mlv.fr  Fri Jul 14 13:29:27 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 14 Jul 2023 15:29:27 +0200 (CEST)
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase()
 in java.base [v2]
In-Reply-To: <wcIqS-Z73fwLZICL2uhFveTBVYMYO2dtanzNtfm6PFA=.18624ed6-39fb-4b69-b777-7c293816d974@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>
 <qNfFCDiE8DYJna7MXp77UnasD8Vg3iU6HBm5c4KVgu0=.0be8245d-3ff2-43b6-bd79-a258569013ad@github.com>
 <wcIqS-Z73fwLZICL2uhFveTBVYMYO2dtanzNtfm6PFA=.18624ed6-39fb-4b69-b777-7c293816d974@github.com>
Message-ID: <1059971530.104670971.1689341367155.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Uwe Schindler" <uschindler at openjdk.org>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>, net-dev at openjdk.org, nio-dev at openjdk.org, security-dev at openjdk.org
> Sent: Wednesday, July 12, 2023 6:08:17 PM
> Subject: Re: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v2]

> On Wed, 12 Jul 2023 14:31:53 GMT, Glavo <duke at openjdk.org> wrote:
> 
>>> src/java.base/share/classes/java/io/StreamTokenizer.java line 632:
>>> 
>>>> 630:             sval = String.copyValueOf(buf, 0, i);
>>>> 631:             if (forceLower)
>>>> 632:                 sval = sval.toLowerCase(Locale.ROOT);
>>> 
>>> I suspect this change to StreamTokenizer needs eyes. I think long standing
>>> behavior of the lowerCaseMode(true) has been to use the rules for the default
>>> locale so we need to be careful.
>>
>>> I suspect this change to StreamTokenizer needs eyes. I think long standing
>>> behavior of the lowerCaseMode(true) has been to use the rules for the default
>>> locale so we need to be careful.
>> 
>> I investigated usage of this method on GitHub:
>> 
>> https://github.com/search?q=%22lowerCaseMode%28true%29%22+language%3AJava&type=code
>> 
>> In some of the use cases I investigated, it seems that no one wants to rely on
>> the default locale.
>> 
>> However, while I think this corrects the behavior, this caused a change in the
>> behavior of the API, so a CSR may be required. I don't want to debate this in
>> this PR, so I'll revert this change and open a new PR in the future.
> 
> Maybe a small suggestion to make it clear whats wanted here. In other projects I
> am involved in (Apache Lucene/Solr, Apache TIKA, PostgresSQL JDBC, Checkstyle
> itsself, Elasticserach/Opensearch), which use the [forbiddenapis
> Maven/Gradle/Ant plugin](https://github.com/policeman-tools/forbidden-apis/),
> we forbid all calls to several Java APIs (including toLowerCase/toUpperCase
> case). All bytecode using this will build failure (FYI, we also disallow other
> stuff like relying of default timezone or characterset).
> To make it clear what is really intended, those projects agreed on having
> `toLowerCase(Locale.getDefault())`, so it is explicit what's wanted.
> Without that it could be that somebody else starts the discussion again.
> 
> This is just a suggestion to be explicit as it makes maintaining the code
> easier.

One solution is to deprecate String.toLowerCase()/toUpperCase(), forcing users to explicitly use the variants that takes a Locale.
Obviously, I'm talking about a simple deprecation not a deprecation for removal.

R?mi

> 
> -------------
> 
> PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1261404900

From rriggs at openjdk.org  Fri Jul 14 14:41:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Jul 2023 14:41:19 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types [v3]
In-Reply-To: <_tiDblw9SaGH18fI-2L9bZmSDqrtZB0lWUP0OHtLkGE=.e531d5bf-dbe7-47d5-ad06-b82ae1d6e591@github.com>
References: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
 <_tiDblw9SaGH18fI-2L9bZmSDqrtZB0lWUP0OHtLkGE=.e531d5bf-dbe7-47d5-ad06-b82ae1d6e591@github.com>
Message-ID: <fIIkh1781WKG_cwBB56ZLwsFVgONRppoZGKvo5YcClA=.f1fe86d8-8fa2-4d2c-ac23-284ba778a6f9@github.com>

On Fri, 14 Jul 2023 02:54:59 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.
>
> 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:
> 
>  - Use new API in serialization; add tests.
>  - Merge branch 'master' into JDK-6361826
>  - Update API proposal.
>  - Merge branch 'master' into JDK-6361826
>  - JDK-6361826: (reflect) provide method for mapping strings to class object for primitive types

Looks good.
The inverse of `clazz.getName()` and `clazz.toString()` for primitive classes is a useful addition.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14743#pullrequestreview-1530432811

From prappo at openjdk.org  Fri Jul 14 14:46:14 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 14 Jul 2023 14:46:14 GMT
Subject: RFR: 8312089: Simplify and modernize equals, hashCode,
 and compareTo in java.nio and implementation code [v2]
In-Reply-To: <aPlljRyFAmMHxxmrnI-a9-caCvXwT-MUmZmHNuJ6wok=.76f1f291-9d99-4d4a-bac2-b89ba0c291bb@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
 <aPlljRyFAmMHxxmrnI-a9-caCvXwT-MUmZmHNuJ6wok=.76f1f291-9d99-4d4a-bac2-b89ba0c291bb@github.com>
Message-ID: <7HA73ob9WWD-IAiPKql9ZCKi_BFlsgPmyY1xfuIxoJc=.81f2dfd6-ab26-43df-ab63-364fdc1843f9@github.com>

On Fri, 14 Jul 2023 13:16:27 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 in java.nio and implementation code.
>> 
>> Please note, test results are pending.
>> 
>> Additional notes:
>> 
>> * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements.
>> 
>> * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified.
>> 
>> * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it.
>> 
>> * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification.
>> 
>> * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose.
>> 
>> * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith.
>
> Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address another case from feedback
>  - Address feedback

> * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified.

@AlanBateman, what do you think of that? For convenience, let me paste here relevant source parts:

    /**
       ...
     * <p> Every charset has a <i>canonical name</i> and may also have one or more
     * <i>aliases</i>.  The canonical name is returned by the {@link #name() name} method
     * of this class.  Canonical names are, by convention, usually in upper case.
     * The aliases of a charset are returned by the {@link #aliases() aliases}
     * method.
       ...
     */
    public abstract class Charset implements Comparable<Charset>
    {
        ...
      
        /**
         * Compares this charset to another.
         *
         * <p> Charsets are ordered by their canonical names, without regard to
         * case.
           ...
         */
        @Override
        public final int compareTo(Charset that) {
            return (name().compareToIgnoreCase(that.name()));
        }
    
        ...
        
        /**
         * Tells whether or not this object is equal to another.
         *
         * <p> Two charsets are equal if, and only if, they have the same canonical
         * names.  A charset is never equal to any other type of object.  </p>
         *
         * @return  {@code true} if, and only if, this charset is equal to the
         *          given object
         */
        @Override
        public final boolean equals(Object ob) {
            if (this == ob)
                return true;
            return ob instanceof Charset other && name.equals(other.name());
        }
    
        ...
    }

Here's what Comparable has to say about this:

    public interface Comparable<T> {
        /**
           ...
         * @apiNote
         * It is strongly recommended, but <i>not</i> strictly required that
         * {@code (x.compareTo(y)==0) == (x.equals(y))}.  Generally speaking, any
         * class that implements the {@code Comparable} interface and violates
         * this condition should clearly indicate this fact.  The recommended
         * language is "Note: this class has a natural ordering that is
         * inconsistent with equals."
           ...
         */
        public int compareTo(T o);

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

PR Comment: https://git.openjdk.org/jdk/pull/14886#issuecomment-1635967137

From rriggs at openjdk.org  Fri Jul 14 15:16:09 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Jul 2023 15:16:09 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v8]
In-Reply-To: <6fpeJ9q0R9LTBsv9ynVXmUtuP9o0b4fVgbyGR2iZ59E=.0fe636ac-df43-4397-87d2-b9ea0ba1585a@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <6fpeJ9q0R9LTBsv9ynVXmUtuP9o0b4fVgbyGR2iZ59E=.0fe636ac-df43-4397-87d2-b9ea0ba1585a@github.com>
Message-ID: <cDB5OHy17lREOr7uWj4mvIWIBAfps-RUqLA3zZ1wWkI=.9b412aab-7f21-41bf-a9b9-616a01335261@github.com>

On Thu, 13 Jul 2023 15:07:35 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:
> 
>   Update test to check for gc.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14684#pullrequestreview-1530491186

From rriggs at openjdk.org  Fri Jul 14 15:37:08 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Jul 2023 15:37:08 GMT
Subject: RFR: 8310201: Reduce verbose locale output in -XshowSettings
 launcher option [v2]
In-Reply-To: <BPrP3Pa6WhxrJ8P2FGEB3ChHNbOntS-1KGgjKTKnjWA=.099be2de-de27-4d3c-a25d-dabaaa2efcc7@github.com>
References: <XXbMAO0gXhtWOhbs_iDqmQpdnus-xdEEY4sufnRb8No=.32addd37-6f00-4f63-8a9d-17784d1a405c@github.com>
 <BPrP3Pa6WhxrJ8P2FGEB3ChHNbOntS-1KGgjKTKnjWA=.099be2de-de27-4d3c-a25d-dabaaa2efcc7@github.com>
Message-ID: <oZA3_SXKGdsVTa0IZrybOup9bzXLtC7NFdtZ2-RX-e0=.2ab49c4f-691b-4704-afaa-8c04358e02ae@github.com>

On Fri, 14 Jul 2023 11:21:02 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Simple tweak to remove the "available locales" section from default `-XshowSettings` output.
>> 
>> Instead, it remains available with the `-XshowSettings:locale` option
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback and bug id added to test

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 173:

> 171:                 break;
> 172:             case "locale":
> 173:                 printLocale(false);

Adding the flag seems to make the coding more complex.
I'd remove the printing of all locales from the printLocale method (and maybe rename it to printLocalSummary).
And add the printing of the help test for the the verbose here also.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 187:

> 185:                 printVmSettings(initialHeapSize, maxHeapSize, stackSize);
> 186:                 printProperties();
> 187:                 printLocale(true);

Here: call `printLocaleSummary()` and then `printLocales()` and println.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 283:

> 281:      * prints the locale subopt/section
> 282:      */
> 283:     private static void printLocale(boolean summaryMode) {

Rename to printLocaleSummary (without an argument) and just print the summary.
(No help).
And drop the printing of the locales.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14885#discussion_r1263865162
PR Review Comment: https://git.openjdk.org/jdk/pull/14885#discussion_r1263865996
PR Review Comment: https://git.openjdk.org/jdk/pull/14885#discussion_r1263870691

From simonis at openjdk.org  Fri Jul 14 15:43:12 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 14 Jul 2023 15:43:12 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() throws UOE if invoked
 reflectively [v3]
In-Reply-To: <YTeOwOSdTJFmtokw3-YaH-BizLDzSbq5BWvB5-8ycYQ=.94f11e59-8b37-4f3a-8f3c-4cd9db88cdad@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
 <BhLE3dfNH4BcJr1wdYplaRLON1PAABl_Kxw9bE0S36k=.388595b3-0094-41af-ad7c-ce8183fb72b2@github.com>
 <YTeOwOSdTJFmtokw3-YaH-BizLDzSbq5BWvB5-8ycYQ=.94f11e59-8b37-4f3a-8f3c-4cd9db88cdad@github.com>
Message-ID: <QG5C7qR883pZXKv7zk_ScU7FbRbxcdm_knjp4tDgNfg=.afac0acd-c9ac-4b29-b1a1-f60dc7410558@github.com>

On Thu, 13 Jul 2023 19:27:01 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I wonder if we should move the check to throw UOE if called by caller-sensitive method in Java as a general guidance to implement the runtime in Java if desirable. That means it requires the VM to fill not only the class in the buffer but also need a flag to indicate the method is caller-sensitive or not. It's a tradeoff of the buffer size. The common case for `getCallerClass` is being invoked statically and should find the class from the first batch. Only if it's invoked reflectively and if filtered in the Java, it'll fetch more batches and hence the performance would not be as fast as filtered in VM but I think that's okay since it's uncommon.
> 
> Would you have cycle to implement this alternative and determine any performance impact to common cases? Then evaluate this further.
> 
> The benchmark is at `test/micro/org/openjdk/bench/java/lang/StackWalkBench.java`.

I'm open to investigate other approaches, but this is a real bug and I'd first like to fix it before thinking about implementation improvements. Notice also, that this issue impacts 17 and 21 as well, so the fix should be easily and quickly downportable. We already have [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447) for performance improvements of `getCallerClass()` (which I'm also working on).

I'd therefore suggest to first fix this and postpone further refactorings and improvements to [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447) or another follow-up issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/14773#issuecomment-1636039777

From alanb at openjdk.org  Fri Jul 14 15:55:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Jul 2023 15:55:16 GMT
Subject: RFR: 8312089: Simplify and modernize equals, hashCode,
 and compareTo in java.nio and implementation code [v2]
In-Reply-To: <7HA73ob9WWD-IAiPKql9ZCKi_BFlsgPmyY1xfuIxoJc=.81f2dfd6-ab26-43df-ab63-364fdc1843f9@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
 <aPlljRyFAmMHxxmrnI-a9-caCvXwT-MUmZmHNuJ6wok=.76f1f291-9d99-4d4a-bac2-b89ba0c291bb@github.com>
 <7HA73ob9WWD-IAiPKql9ZCKi_BFlsgPmyY1xfuIxoJc=.81f2dfd6-ab26-43df-ab63-364fdc1843f9@github.com>
Message-ID: <goCHyYJ44TDyB5BcI5l5TdCgTXX7bugho1NLXljbSEk=.0883acf4-e3e2-4599-bf60-3ada6b494608@github.com>

On Fri, 14 Jul 2023 14:42:47 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified.
> 
> @AlanBateman, what do you think of that? For convenience, let me paste here relevant source parts:

There are a few classes where the natural ordering is not consistent with equals. For another PR, this could be documented as it is done in other classes. n practical terms then it's probably not a concern because the canonical name will usually be a charset name registered with IANA.

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

PR Comment: https://git.openjdk.org/jdk/pull/14886#issuecomment-1636053904

From coffeys at openjdk.org  Fri Jul 14 16:00:02 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 14 Jul 2023 16:00:02 GMT
Subject: RFR: 8310201: Reduce verbose locale output in -XshowSettings
 launcher option [v2]
In-Reply-To: <BPrP3Pa6WhxrJ8P2FGEB3ChHNbOntS-1KGgjKTKnjWA=.099be2de-de27-4d3c-a25d-dabaaa2efcc7@github.com>
References: <XXbMAO0gXhtWOhbs_iDqmQpdnus-xdEEY4sufnRb8No=.32addd37-6f00-4f63-8a9d-17784d1a405c@github.com>
 <BPrP3Pa6WhxrJ8P2FGEB3ChHNbOntS-1KGgjKTKnjWA=.099be2de-de27-4d3c-a25d-dabaaa2efcc7@github.com>
Message-ID: <pLqTwJM3pbzrSBrh-YaN9pw_MnODjXxMpV04qDEj2BY=.24d53b1c-eed4-4c0d-822b-db17a7dacc98@github.com>

On Fri, 14 Jul 2023 11:21:02 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Simple tweak to remove the "available locales" section from default `-XshowSettings` output.
>> 
>> Instead, it remains available with the `-XshowSettings:locale` option
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback and bug id added to test

thanks for the review @RogerRiggs  - nice ideas but I'm not sure if it makes the code any clearer. I've implemented your suggestions but I feel we're polluting the main method with extra printlns and flow logic for the sake of locale output. Placing the help message option inside the "locale settings summary" style header works better also IMO. I think your suggestion means we print the helpful "more info with :locale " hint in the main showSettings call also,  again pollution of main method.

Best to let the flow of the locale setting logic stem from a printLocale(boolean summary) type method IMO

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

PR Comment: https://git.openjdk.org/jdk/pull/14885#issuecomment-1636060048

From alanb at openjdk.org  Fri Jul 14 16:04:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Jul 2023 16:04:21 GMT
Subject: Integrated: 8311992: Test
 java/lang/Thread/virtual/JfrEvents::testVirtualThreadPinned failed
In-Reply-To: <Teva40gyZFff2HILZpLYmrJxuMxPX_7hdlKa2wKsG24=.f85a15a0-d89a-4797-afae-89114e18abc5@github.com>
References: <Teva40gyZFff2HILZpLYmrJxuMxPX_7hdlKa2wKsG24=.f85a15a0-d89a-4797-afae-89114e18abc5@github.com>
Message-ID: <Xbu8g5cwtiFsflqrM_veopXLc9QL4BO1iQGNEbLnzog=.5bd9bf6f-f948-49e9-b7a6-9e0cf7800520@github.com>

On Fri, 14 Jul 2023 09:42:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only update to a test for the JFR event jdk.VirtualThreadPinned event. The test we added in JDK 19 does 3 sleeps, one with a small duration, twice with a  long duration. The test enables the event with a threshold of 500ms and expects there will be two events recorded; no event for the sleep with the small duration. In extreme cases, it's possible that the short sleep takes more than 500ms so an event is recorded and the test fails. The test is changed to drop the threshold, it's not needed. It's also changed to explicitly park to avoid the long sleeps. A drive-by change is to print the events to System.err rather than System.out so they are inlined with the JUnit output (the original test was TestNG where the output went to System.out).

This pull request has now been integrated.

Changeset: 0d2196f8
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0d2196f8e5b03577a14ff97505718f4fa53f3792
Stats:     42 lines in 1 file changed: 19 ins; 2 del; 21 mod

8311992: Test java/lang/Thread/virtual/JfrEvents::testVirtualThreadPinned failed

Reviewed-by: jpai

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

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

From mchung at openjdk.org  Fri Jul 14 16:11:31 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 14 Jul 2023 16:11:31 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v19]
In-Reply-To: <nJtaOmnevHioGemQCIfp25ldjI0ZV_BD2ksZp3CJKmk=.a4f1a323-aab6-4c61-bba4-3aee348648c9@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <fp9PEVNZNpBwh0yHwPC9-HhI8vbH6pjDxUd29ogWEmw=.796ded42-ba4b-4a02-86a9-08b680110168@github.com>
 <CJuqpdWdrQpn8QNiocm6EuUzVNwYmoNqX8F3ryTIZ7U=.3dbd8f38-7a5f-4001-a6c9-641d25695081@github.com>
 <nJtaOmnevHioGemQCIfp25ldjI0ZV_BD2ksZp3CJKmk=.a4f1a323-aab6-4c61-bba4-3aee348648c9@github.com>
Message-ID: <LKX6erLY9wXZSuf11pHt6R-PkqDt-NHeY3VA8p4dyVQ=.f477a6a1-fb00-427b-85b0-fd2affa68259@github.com>

On Wed, 5 Jul 2023 23:30:03 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> It's looking pretty good. 
>> 
>> About the test, I don't see `ArrayList::add` in the generated bytecode of `sub2-13`.   The dedup string set is used for the targets of qualified exports and opens and uses.   The modifiers set of `requires` is deduplicated but not the required module names.
>> 
>> I assume you want this be backported.  If so, we should give it some baked time after it's integrated to the main line.    I'm okay if you want to extend the test in a follow up.     You can extract the generated class to verify:
>> 
>> $ jimage extract --dir=dir out-jlink/lib/modules
>> $ javap -p -v dir/java.base/jdk/internal/module/SystemModules$all.class
>
>> It's looking pretty good.
> 
> Thank you!
> 
>> About the test, I don't see `ArrayList::add` in the generated bytecode of `sub2-13`. The dedup string set is used for the targets of qualified exports and opens and uses. The modifiers set of `requires` is deduplicated but not the required module names.
> 
> Thank you for the hint.
> 
>> I assume you want this be backported. If so, we should give it some baked time after it's integrated to the main line.
> 
> Sounds great!
> 
>> I'm okay if you want to extend the test in a follow up. 
> 
> That would be great. Will take time to craft a proper setting.

@koppor do you have any update on a new test for [JDK-8311591](https://bugs.openjdk.org/browse/JDK-8311591)?

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

PR Comment: https://git.openjdk.org/jdk/pull/14408#issuecomment-1636072257

From alanb at openjdk.org  Fri Jul 14 16:12:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Jul 2023 16:12:27 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v21]
In-Reply-To: <ncyqPyRO8dEypxI76YMOjO8R_BU4_PwwOzEYUrQrkL8=.de648084-40b5-40cb-aecc-9dd5ad8c4887@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <ncyqPyRO8dEypxI76YMOjO8R_BU4_PwwOzEYUrQrkL8=.de648084-40b5-40cb-aecc-9dd5ad8c4887@github.com>
Message-ID: <g6wUDXcv3jSQzh6xkqNvfFa0EdhYKbMKv1951Ftg7ho=.6ce175a7-9d68-4e9d-a77d-c6ea24924d15@github.com>

On Thu, 13 Jul 2023 11:46:39 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 one additional commit since the last revision:
> 
>   minor - remove duplicated code comment

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 666:

> 664:             return false;
> 665:         }
> 666:         return Files.isSameFile(javaBasePath, javaBaseInDefaultPath);

Files.isSameFile checks the file contents, this doesn't look right here. Shouldn't this be

return javaBasePath.toRealPath().equals(javaBaseInDefaultPath.toRealPath()) ;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1263903041

From mchung at openjdk.org  Fri Jul 14 16:20:14 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 14 Jul 2023 16:20:14 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() throws UOE if invoked
 reflectively [v3]
In-Reply-To: <BhLE3dfNH4BcJr1wdYplaRLON1PAABl_Kxw9bE0S36k=.388595b3-0094-41af-ad7c-ce8183fb72b2@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
 <BhLE3dfNH4BcJr1wdYplaRLON1PAABl_Kxw9bE0S36k=.388595b3-0094-41af-ad7c-ce8183fb72b2@github.com>
Message-ID: <W4x8FPOyGaOL_iNUPb2PEm-f0vp5wVZd5TnEl22vPfA=.5a70775a-ed8d-4e1d-ab09-57109be1a0ac@github.com>

On Tue, 11 Jul 2023 15:47:35 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> As the included jtreg test demonstrates, `StackWalker.getCallerClass()` can throw an `UnsupportedOperationException` if called reflectively. Currently this only happens if we invoke `StackWalker.getCallerClass()` recursively reflectively, but this issue will become more prominent once we fix [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447). The gory details follow below:
>> 
>> The protocol between the Java API and the JVM for `StackWalker.getCallerClass()/walk()` is as follows:
>> - On the Java side, `StackWalker` calls into `StackStreamFactory` for the real work.
>> - For `StackWalker.getCallerClass()` `StackStreamFactory` basically creates a `Class[]` which will be passed down and filled in the JVM. For `StackWalker.walk()` it will normally be a `StackFrameInfo[]` (or a `LiveStackFrameInfo[]` if the internal `ExtendedOption.LOCALS_AND_OPERANDS` option was used).
>> - The default size of this arrays is currently `StackStreamFactory.SMALL_BATCH` which is 8 (but see [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447)).
>> - `StackStreamFactory` than calls `AbstractStackWalker.callStackWalk()` which is a natively implemented in the VM by `JVM_CallStackWalk()`.
>> -  `JVM_CallStackWalk()` calls `StackWalk::walk()` which calls `StackWalk::fetchFirstBatch()` which calls `StackWalk::fill_in_frames()` which walks the stack and fills in the available class/stackframe slots in the passed in array until the array is full or there are no more stack frames,
>> - Once  `StackWalk::fill_in_frames()` returns, `StackWalk::fetchFirstBatch()` calls back to Java by invoking `AbstractStackWalker::doStackWalk()` to consume the result.
>> - `AbstractStackWalker::doStackWalk()` calls `consumeFrames()` (which is overridden depending on whether we initially called `getCallerClass()` or `walk()`) which consumes the frames until it either finishes (e.g. finds the caller class) or until there are no more frames.
>> - In the latter case `consumeFrames()` will call into the the VM again by calling `AbstractStackWalker.fetchStackFrames()` to fetch additional frames from the stack.
>> - `AbstractStackWalker.fetchStackFrames()` is implemented by `JVM_MoreStackWalk()` which calls `StackWalk::fetchNextBatch()` which calls `StackWalk::fill_in_frames()` (the same method that already fetched the initial batch of frames).
>> 
>> Following is a stacktrace of what I've explained so far:
>> 
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x1...
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed case when calling getCallerClass() from a @CallerSensitive method reflectively

I expect `getCallerClass` is rarely called via reflection.  JDK-8210375 was reported 5 years ago but no customer reports this issue since then.    This bug is not critical to be fixed immediately and so we should look into a proper solution.

I do have a question if filtering in the VM is the right thing to do.   We need to consider the alternatives and understand why this solution is chosen.

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

PR Comment: https://git.openjdk.org/jdk/pull/14773#issuecomment-1636082537

From naoto at openjdk.org  Fri Jul 14 17:06:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 14 Jul 2023 17:06:03 GMT
Subject: RFR: 8311968: Clarify Three-letter time zone IDs in
 java.util.TimeZone [v4]
In-Reply-To: <rRnlbdl-_ApQV9Nq5_VrtaYyBEFdWqan6y9ExfSa-To=.38725c42-c89b-42cf-b710-9fa37466128f@github.com>
References: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
 <rRnlbdl-_ApQV9Nq5_VrtaYyBEFdWqan6y9ExfSa-To=.38725c42-c89b-42cf-b710-9fa37466128f@github.com>
Message-ID: <q_4zE0Z_sJT3FRGdewvpzR0S-Vnn1QEEv8DqgV0aF2k=.8416de4c-7fe5-412c-8d08-2978d2be6429@github.com>

On Thu, 13 Jul 2023 22:43:27 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8311979) which links the full list of deprecated three-letter IDs in java.util.TimeZone
>> 
>> Although it is made apparent in TimeZone that certain 3-letter IDs are deprecated, it does not actually list them in the specification. In addition to linking the full list, it is clarified that not _all_ 3-letter IDs are deprecated, as there are quite a few that come from the tzdb.
>> 
>> This change links to the full list found in ZoneId.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Need only link to SHORT_IDS, mentioning tzdb beyond scope

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14861#pullrequestreview-1530652584

From naoto at openjdk.org  Fri Jul 14 17:16:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 14 Jul 2023 17:16:26 GMT
Subject: RFR: 8308591: JLine as the default Console provider
Message-ID: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>

This is to bring the JLine-based Console implementation as the default, which was the initial intention in [JDK-8295803](https://bugs.openjdk.org/browse/JDK-8295803). A corresponding CSR has also been drafted.

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

Commit messages:
 - javadoc cleanup
 - Merge branch 'master' into JDK-8308591-JLine-Console
 - Merge branch 'master' into JDK-8308591-JLine-Console
 - static to instance method
 - isPlatformConsole()
 - Restored stream
 - lazy init
 - Avoid using stream
 - test fix
 - Make jdk.internal.le the default console module

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

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

From lancea at openjdk.org  Fri Jul 14 17:18:16 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 14 Jul 2023 17:18:16 GMT
Subject: RFR: 8311968: Clarify Three-letter time zone IDs in
 java.util.TimeZone [v4]
In-Reply-To: <rRnlbdl-_ApQV9Nq5_VrtaYyBEFdWqan6y9ExfSa-To=.38725c42-c89b-42cf-b710-9fa37466128f@github.com>
References: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
 <rRnlbdl-_ApQV9Nq5_VrtaYyBEFdWqan6y9ExfSa-To=.38725c42-c89b-42cf-b710-9fa37466128f@github.com>
Message-ID: <lirCGhrryM5fZHYNk6yTlL0jc3O1eb4B2Pu6ekw1zio=.ca52e51d-0624-408b-aba1-05f25b8665cb@github.com>

On Thu, 13 Jul 2023 22:43:27 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8311979) which links the full list of deprecated three-letter IDs in java.util.TimeZone
>> 
>> Although it is made apparent in TimeZone that certain 3-letter IDs are deprecated, it does not actually list them in the specification. In addition to linking the full list, it is clarified that not _all_ 3-letter IDs are deprecated, as there are quite a few that come from the tzdb.
>> 
>> This change links to the full list found in ZoneId.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Need only link to SHORT_IDS, mentioning tzdb beyond scope

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14861#pullrequestreview-1530671148

From mchung at openjdk.org  Fri Jul 14 17:35:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 14 Jul 2023 17:35:12 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types
In-Reply-To: <_lr5QkY99wd5sCCCDEXUo_VLAT-GadSgYgYcjP4JodI=.65e54165-24a9-473f-897f-202bbd3dd09d@github.com>
References: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
 <ayBNl-W-zwTAW7KXuU8GuwW9ykspvl5EBVRSA3SitpA=.652918b0-d719-4741-9033-955ca7bd7a74@github.com>
 <_lr5QkY99wd5sCCCDEXUo_VLAT-GadSgYgYcjP4JodI=.65e54165-24a9-473f-897f-202bbd3dd09d@github.com>
Message-ID: <qRpMH_WL_tILtjSVGuMI9WX5na_HeWQvd4Luivk3Ytw=.6a8ee0e1-8780-4329-a00e-90d750a05a42@github.com>

On Mon, 10 Jul 2023 20:36:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> For discussion purposes, pushed an update where the new method returns null on a non-primitive name.

I also think returning null is saner than throwing a checked exception which avoids forcing the caller to catch and also the cost of constructing an exception being thrown away.

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

PR Comment: https://git.openjdk.org/jdk/pull/14743#issuecomment-1636169276

From mchung at openjdk.org  Fri Jul 14 17:35:17 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 14 Jul 2023 17:35:17 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types [v3]
In-Reply-To: <_tiDblw9SaGH18fI-2L9bZmSDqrtZB0lWUP0OHtLkGE=.e531d5bf-dbe7-47d5-ad06-b82ae1d6e591@github.com>
References: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
 <_tiDblw9SaGH18fI-2L9bZmSDqrtZB0lWUP0OHtLkGE=.e531d5bf-dbe7-47d5-ad06-b82ae1d6e591@github.com>
Message-ID: <wkfXo6BGKlhs7TDs4H9TadScFuOzv6bo23LfVTeOFWM=.f030ca30-28c5-4341-8ac8-2404cacd6faf@github.com>

On Fri, 14 Jul 2023 02:54:59 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.
>
> 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:
> 
>  - Use new API in serialization; add tests.
>  - Merge branch 'master' into JDK-6361826
>  - Update API proposal.
>  - Merge branch 'master' into JDK-6361826
>  - JDK-6361826: (reflect) provide method for mapping strings to class object for primitive types

src/java.base/share/classes/java/lang/Class.java line 441:

> 439:      * an attempt will be made to locate a user-defined class in the unnamed package
> 440:      * whose name is {@code I} instead.
> 441:      * To obtain a {@code Class} object for a named primitive type, use

The example above of a primitive type is `I` (the descriptor string) versus `forPrimitiveType` takes the primitive type name.  It may need some clarification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14743#discussion_r1263944106

From alanb at openjdk.org  Fri Jul 14 18:01:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Jul 2023 18:01:15 GMT
Subject: RFR: 8312089: Simplify and modernize equals, hashCode,
 and compareTo in java.nio and implementation code [v2]
In-Reply-To: <aPlljRyFAmMHxxmrnI-a9-caCvXwT-MUmZmHNuJ6wok=.76f1f291-9d99-4d4a-bac2-b89ba0c291bb@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
 <aPlljRyFAmMHxxmrnI-a9-caCvXwT-MUmZmHNuJ6wok=.76f1f291-9d99-4d4a-bac2-b89ba0c291bb@github.com>
Message-ID: <n_QuByqx_RJ-vSW_mceUefS2DoZ_xx4ozfcn7jJAV8I=.b3afdc7c-cf6a-45dd-8cb0-3e9b438f1618@github.com>

On Fri, 14 Jul 2023 13:16:27 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 in java.nio and implementation code.
>> 
>> Please note, test results are pending.
>> 
>> Additional notes:
>> 
>> * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements.
>> 
>> * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified.
>> 
>> * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it.
>> 
>> * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification.
>> 
>> * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose.
>> 
>> * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith.
>
> Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address another case from feedback
>  - Address feedback

src/java.base/share/classes/java/nio/charset/Charset.java line 987:

> 985: 
> 986:     /**
> 987:      * {@return the string describing this charset}

You've changed this to "the string", which hints of ==, I think it should be reverted to a "a string".

src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 713:

> 711: 
> 712:         return Arrays.equals(this.path, thisPos, thisLen, that.path, thatPos,
> 713:                 thatLen);

My comment here was "thatLen" ended up on its own line, it can go after thatPos without making it too long.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263932426
PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263936625

From darcy at openjdk.org  Fri Jul 14 18:06:18 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jul 2023 18:06:18 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types [v3]
In-Reply-To: <_tiDblw9SaGH18fI-2L9bZmSDqrtZB0lWUP0OHtLkGE=.e531d5bf-dbe7-47d5-ad06-b82ae1d6e591@github.com>
References: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
 <_tiDblw9SaGH18fI-2L9bZmSDqrtZB0lWUP0OHtLkGE=.e531d5bf-dbe7-47d5-ad06-b82ae1d6e591@github.com>
Message-ID: <UBFNzHRqvQ29D1t4pGaxLqq8YPoIhwKR-Q2p_ictKls=.6f32e8f3-7964-469e-a837-d966bbcec6e0@github.com>

On Fri, 14 Jul 2023 02:54:59 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.
>
> 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:
> 
>  - Use new API in serialization; add tests.
>  - Merge branch 'master' into JDK-6361826
>  - Update API proposal.
>  - Merge branch 'master' into JDK-6361826
>  - JDK-6361826: (reflect) provide method for mapping strings to class object for primitive types

CSR ready for review: https://bugs.openjdk.org/browse/JDK-8312110

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

PR Comment: https://git.openjdk.org/jdk/pull/14743#issuecomment-1636203463

From matsaave at openjdk.org  Fri Jul 14 18:14:41 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 14 Jul 2023 18:14:41 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
Message-ID: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>

Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 


 // We have finished dumping the static archive. At this point, there may be pending VM
 // operations. We have changed some global states (such as vmClasses::_klasses) that
 // may cause these VM operations to fail. For safety, forget these operations and
 // exit the VM directly.
 void MetaspaceShared::exit_after_static_dump() {
   os::_exit(0);
 } 


As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.

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

Commit messages:
 - Merge branch 'master' into remove_exit_after_dump_8306582
 - Windows fix
 - 8306582: Remove MetaspaceShared::exit_after_static_dump()

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

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

From darcy at openjdk.org  Fri Jul 14 18:25:48 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jul 2023 18:25:48 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types [v3]
In-Reply-To: <wkfXo6BGKlhs7TDs4H9TadScFuOzv6bo23LfVTeOFWM=.f030ca30-28c5-4341-8ac8-2404cacd6faf@github.com>
References: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
 <_tiDblw9SaGH18fI-2L9bZmSDqrtZB0lWUP0OHtLkGE=.e531d5bf-dbe7-47d5-ad06-b82ae1d6e591@github.com>
 <wkfXo6BGKlhs7TDs4H9TadScFuOzv6bo23LfVTeOFWM=.f030ca30-28c5-4341-8ac8-2404cacd6faf@github.com>
Message-ID: <t0c-Yp2ClWjR6D9p-2-eTyS0uLNE6yJmiZStNOqyjxA=.6b8effe3-ab62-426f-b8cd-9e64d7200e05@github.com>

On Fri, 14 Jul 2023 16:55:44 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The example above of a primitive type is `I` (the descriptor string) versus `forPrimitiveType` takes the primitive type name. It may need some clarification.

Add some clarification that argument like "int" and "long" are expected for  `forPrimitiveType`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14743#discussion_r1264019350

From darcy at openjdk.org  Fri Jul 14 18:25:45 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jul 2023 18:25:45 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types [v4]
In-Reply-To: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
References: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
Message-ID: <pqgVnN5_SkX3gOVpfb-s93w9iyPusqvw4f_mDUnagcQ=.88edf082-0a8a-4053-bf48-b00319be9945@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.

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

  Clarify docs based on review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14743/files
  - new: https://git.openjdk.org/jdk/pull/14743/files/a106b12c..8a16ec86

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

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 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 prappo at openjdk.org  Fri Jul 14 18:54:35 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 14 Jul 2023 18:54:35 GMT
Subject: RFR: 8312089: Simplify and modernize equals, hashCode,
 and compareTo in java.nio and implementation code [v3]
In-Reply-To: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
Message-ID: <6I_ZpsYUKuSLeGx-V-yXD6LmPfxZn_seP2oiloCrPgA=.d474a89d-2beb-4326-83d0-47c585cc56b1@github.com>

> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for in java.nio and implementation code.
> 
> Please note, test results are pending.
> 
> Additional notes:
> 
> * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements.
> 
> * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified.
> 
> * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it.
> 
> * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification.
> 
> * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose.
> 
> * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Re-address feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14886/files
  - new: https://git.openjdk.org/jdk/pull/14886/files/a39780f5..8c171ae5

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

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

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

From prappo at openjdk.org  Fri Jul 14 18:54:41 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 14 Jul 2023 18:54:41 GMT
Subject: RFR: 8312089: Simplify and modernize equals, hashCode,
 and compareTo in java.nio and implementation code [v2]
In-Reply-To: <n_QuByqx_RJ-vSW_mceUefS2DoZ_xx4ozfcn7jJAV8I=.b3afdc7c-cf6a-45dd-8cb0-3e9b438f1618@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
 <aPlljRyFAmMHxxmrnI-a9-caCvXwT-MUmZmHNuJ6wok=.76f1f291-9d99-4d4a-bac2-b89ba0c291bb@github.com>
 <n_QuByqx_RJ-vSW_mceUefS2DoZ_xx4ozfcn7jJAV8I=.b3afdc7c-cf6a-45dd-8cb0-3e9b438f1618@github.com>
Message-ID: <rBQpIQycxsxPQvtNlox1zQyYO9B1opFRQ7rLczE605M=.a58a3a23-f912-4464-a1e0-2c6c602c3536@github.com>

On Fri, 14 Jul 2023 16:42:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address another case from feedback
>>  - Address feedback
>
> src/java.base/share/classes/java/nio/charset/Charset.java line 987:
> 
>> 985: 
>> 986:     /**
>> 987:      * {@return the string describing this charset}
> 
> You've changed this to "the string", which hints of ==, I think it should be reverted to a "a string".

Never understood this a/the difference in doc comments, thanks for explaining it.

> src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 713:
> 
>> 711: 
>> 712:         return Arrays.equals(this.path, thisPos, thisLen, that.path, thatPos,
>> 713:                 thatLen);
> 
> My comment here was "thatLen" ended up on its own line, it can go after thatPos without making it too long.

That was surprising considering how picky you are about being on the shorter side of line widths. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1264042654
PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1264044071

From mchung at openjdk.org  Fri Jul 14 19:42:57 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 14 Jul 2023 19:42:57 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types [v4]
In-Reply-To: <pqgVnN5_SkX3gOVpfb-s93w9iyPusqvw4f_mDUnagcQ=.88edf082-0a8a-4053-bf48-b00319be9945@github.com>
References: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
 <pqgVnN5_SkX3gOVpfb-s93w9iyPusqvw4f_mDUnagcQ=.88edf082-0a8a-4053-bf48-b00319be9945@github.com>
Message-ID: <5Rr_cd72CUbYoibsXHfJTni_pmEpExBoawgK6So5_40=.2479b129-596e-4475-ae9f-10eac67835a1@github.com>

On Fri, 14 Jul 2023 18:25:45 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.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify docs based on review feedback.

Looks good to me.

test/jdk/java/lang/Class/ForPrimitiveName.java line 80:

> 78:                     "java.lang.Float",
> 79:                     "java.lang.Double",
> 80:                     "java.lang.Void");

Maybe worth adding the descriptor name for primitive types in the negative test cases serving as examples.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14743#pullrequestreview-1530897451
PR Review Comment: https://git.openjdk.org/jdk/pull/14743#discussion_r1264088315

From darcy at openjdk.org  Fri Jul 14 20:23:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jul 2023 20:23:30 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types [v5]
In-Reply-To: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
References: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
Message-ID: <C8ug9z75yuC3xmHmDaAshoyd5BUSNqR-1SbRfz_doL4=.bfa15ed1-c6c5-45a7-b29b-f182568619fb@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.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Expand test as recommended in code review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14743/files
  - new: https://git.openjdk.org/jdk/pull/14743/files/8a16ec86..3f294df7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14743&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14743&range=03-04

  Stats: 12 lines in 1 file changed: 12 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 Jul 14 20:23:31 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jul 2023 20:23:31 GMT
Subject: Integrated: 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: <kvbU1-nRiteqnkV3kp6QLm0_hi3AZTuwOWab291mpZU=.28e23c63-9204-480d-a425-af2ab786ce62@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.

This pull request has now been integrated.

Changeset: 19691fab
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/19691fab48657174a4e9768d33da2fdd532271c9
Stats:     157 lines in 3 files changed: 141 ins; 15 del; 1 mod

6361826: (reflect) provide method for mapping strings to class object for primitive types

Reviewed-by: rriggs, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/14743

From darcy at openjdk.org  Fri Jul 14 20:31:07 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jul 2023 20:31:07 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: <17I7pwoUTFrL_-PwJEx857TpyzL3T0y2wsu4LQFhcoI=.a568ad15-c574-49d4-b2ed-744421cd81f8@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

As Guy is not a capital-R reviewer for this project, marking the PR as Approved on his behalf.

-------------

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/8131#pullrequestreview-1531000208

From darcy at openjdk.org  Fri Jul 14 20:45:27 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jul 2023 20:45:27 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v21]
In-Reply-To: <9kk58tLH_H9Hv9_GEdIxcpJzdpSMYbOgePMWETQXqOs=.bd193127-30cc-47fe-8f6d-ddeb785bbec4@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <kvMZkYhviynRDKc99xX5jxgFWyX6fH9cXtTnoMhTu1E=.9979a2d4-ec47-4731-a971-41a3ae79e8fe@github.com>
 <9kk58tLH_H9Hv9_GEdIxcpJzdpSMYbOgePMWETQXqOs=.bd193127-30cc-47fe-8f6d-ddeb785bbec4@github.com>
Message-ID: <utNNjvkriO7T7BwNzB6Jnn02x9pVBQtVzKAtVI0TNd0=.e6ccfe10-adfd-4b5a-ba46-0f2e860a76e5@github.com>

On Fri, 14 Jul 2023 03:27:07 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> 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 @turbanoff @rgiulietti Could this please be merged?

@Pr0methean , please update your branch with the current contents of the master before issuing the integrate command. Assuming that succeeds as expected, myself or someone else can sponsor your changeset as described in the comment from the Skara bots.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/8131#issuecomment-1636416373

From jvernee at openjdk.org  Fri Jul 14 21:31:59 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 14 Jul 2023 21:31:59 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: <nSfHELmX3BxECMuw-xNh6oYOAsGrVsmXyhLnbbc5ciE=.4e24b129-6e81-4609-ae48-7e8eba798ae5@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

Still under review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14496#issuecomment-1636464822

From asemenyuk at openjdk.org  Fri Jul 14 22:01:14 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Jul 2023 22:01:14 GMT
Subject: RFR: 8311631: When multiple users run
 tools/jpackage/share/LicenseTest.java,
 Permission denied for writing /var/tmp/*.files [v2]
In-Reply-To: <tlogilGhgOPDCmKldD1UWGwoRqi3TYNe3tmgKG2D8EY=.0d789b18-6aac-4102-859d-653aab1cbcdf@github.com>
References: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
 <tlogilGhgOPDCmKldD1UWGwoRqi3TYNe3tmgKG2D8EY=.0d789b18-6aac-4102-859d-653aab1cbcdf@github.com>
Message-ID: <TUeytaZUrHMd3oY7bZSlvXQD1pmFbLB3yj9C1hG5S24=.fa60a3b9-faef-471b-af2e-915c022c792e@github.com>

On Thu, 13 Jul 2023 07:27:22 GMT, yaqsun <duke at openjdk.org> wrote:

>> The prerequisite is to install the rpmbuild command, when multiple users switch to write /var/tmp/*.files will have the permission forbidden.
>
> yaqsun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8311631: When multiple users run tools/jpackage/share/LicenseTest.java, Permission denied for writing /var/tmp/*.files

The fix with `%{_builddir}` looks better. Did it resolve the issue?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14802#issuecomment-1636489270

From bpb at openjdk.org  Fri Jul 14 22:32:23 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Jul 2023 22:32:23 GMT
Subject: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent
 of close but throws UncheckedIOException [v2]
In-Reply-To: <sU6xopTzco46hc8p2USnYlpqymdqK6h8oihTbebUKic=.bb31c4e0-bb1f-47ed-b1df-f0cb3b456c24@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
 <sU6xopTzco46hc8p2USnYlpqymdqK6h8oihTbebUKic=.bb31c4e0-bb1f-47ed-b1df-f0cb3b456c24@github.com>
Message-ID: <hb1n8oK6fas7naQPIndv6BZz3uX5Ztgb0eHlUYjJEAc=.f3e97889-7979-44c5-aa79-b0717ae5b1ab@github.com>

On Fri, 7 Jul 2023 15:56:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a default method `java.io.Closeable::closeUnchecked` which is equivalent to `Closeable::close` except that it instead throws `java.io.UncheckedIOException`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8066869: linkplain -> link

This work would be better performed in conjunction with language feature support and try-with-resources. Withdrawing for now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14789#issuecomment-1636512438

From bpb at openjdk.org  Fri Jul 14 22:32:23 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Jul 2023 22:32:23 GMT
Subject: Withdrawn: 8066869: Add Closeable::closeUnchecked that is the
 equivalent of close but throws UncheckedIOException
In-Reply-To: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
References: <f_U3371dD_tMF26j2Am_YYNivhaMm5fsBZpuuYV6tpY=.6731000f-e092-4f30-93dd-914843bd15ad@github.com>
Message-ID: <QyQ8mhX9MoxAuQlwA2mvxsDtc-Zi5YZ1HaxQVPvJ-mU=.c219f225-0d2d-4696-8de7-98dbf39a21d4@github.com>

On Thu, 6 Jul 2023 20:07:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a default method `java.io.Closeable::closeUnchecked` which is equivalent to `Closeable::close` except that it instead throws `java.io.UncheckedIOException`.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14789

From naoto at openjdk.org  Fri Jul 14 22:39:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 14 Jul 2023 22:39:15 GMT
Subject: RFR: 8311663: Additional refactoring of Locale tests to JUnit
In-Reply-To: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
References: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
Message-ID: <CAaDFQ9BUpLzoRfEur0oaJEw3TDsTfRoT1Sxwlu2sy4=.8925a14b-aa58-45b8-be85-d6ec4dea4f1e@github.com>

On Thu, 13 Jul 2023 23:23:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which refactors more java.util.Locale tests to JUnit with some minor cleanup as well.
> 
> Although some of the files could benefit from being renamed bugNNNNNNN to something more descriptive, this makes reviewing harder, and will be handled separately.

Thanks for the conversion, Justin. Looks good overall. Some minor comments follow.

test/jdk/java/util/Locale/Bug8135061.java line 56:

> 54:         assertNull(match, "[Locale.lookup failed on language"
> 55:                 + " range: " + ranges + " and language tags "
> 56:                 + locales + "]");

Removing try-catch will lose the information on what kind of exception was thrown

test/jdk/java/util/Locale/Bug8135061.java line 70:

> 68:         assertEquals(match.toLanguageTag(), "nv", "[Locale.lookup failed on language"
> 69:                 + " range: " + ranges + " and language tags "
> 70:                 + locales + "]");

Same as above

test/jdk/java/util/Locale/Bug8159420.java line 67:

> 65:     @BeforeAll
> 66:     static void setTurkishLocale() {
> 67:         Locale.setDefault(Locale.of("tr", "TR"));

Should the tests run under `othervm` mode?

test/jdk/java/util/Locale/Bug8179071.java line 94:

> 92:                 .map(Locale::toLanguageTag)
> 93:                 .forEach(tag -> {if(LegacyAliases.contains(tag)) {invalidTags.add(tag);}});
> 94:         assertEquals(true, invalidTags.isEmpty(),

`assertTrue()` may fit better here

test/jdk/java/util/Locale/ThaiGov.java line 51:

> 49:     // Test number formatting for thai
> 50:     @Test
> 51:     public void numberTest() throws RuntimeException {

Not your change, but this `throws` is redundant

-------------

PR Review: https://git.openjdk.org/jdk/pull/14881#pullrequestreview-1531097899
PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1264205170
PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1264205697
PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1264209622
PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1264216543
PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1264218988

From alanb at openjdk.org  Sat Jul 15 00:44:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Jul 2023 00:44:57 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v21]
In-Reply-To: <ncyqPyRO8dEypxI76YMOjO8R_BU4_PwwOzEYUrQrkL8=.de648084-40b5-40cb-aecc-9dd5ad8c4887@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <ncyqPyRO8dEypxI76YMOjO8R_BU4_PwwOzEYUrQrkL8=.de648084-40b5-40cb-aecc-9dd5ad8c4887@github.com>
Message-ID: <JxjJzCBfu87WTGXpyJJOP4nlN3gYQuHoOE0IvEaZJ4g=.059160db-18a6-4f28-9185-4534efeb2ed1@github.com>

On Thu, 13 Jul 2023 11:46:39 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 one additional commit since the last revision:
> 
>   minor - remove duplicated code comment

Overall I think this looks quite good, just isJavaBaseFromDefaultModulePath needs fixing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1636100434

From jpai at openjdk.org  Sat Jul 15 00:44:59 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 15 Jul 2023 00:44:59 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v21]
In-Reply-To: <g6wUDXcv3jSQzh6xkqNvfFa0EdhYKbMKv1951Ftg7ho=.6ce175a7-9d68-4e9d-a77d-c6ea24924d15@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <ncyqPyRO8dEypxI76YMOjO8R_BU4_PwwOzEYUrQrkL8=.de648084-40b5-40cb-aecc-9dd5ad8c4887@github.com>
 <g6wUDXcv3jSQzh6xkqNvfFa0EdhYKbMKv1951Ftg7ho=.6ce175a7-9d68-4e9d-a77d-c6ea24924d15@github.com>
Message-ID: <IzNUvukqpcFsJMAdf_XXSXHKp2XPAclAFZKj5VW1XEk=.225f929f-20aa-4477-a563-e88f0b706dd2@github.com>

On Fri, 14 Jul 2023 16:09:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor - remove duplicated code comment
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 666:
> 
>> 664:             return false;
>> 665:         }
>> 666:         return Files.isSameFile(javaBasePath, javaBaseInDefaultPath);
> 
> Files.isSameFile checks the file contents, this doesn't look right here. Shouldn't this be
> 
> return javaBasePath.toRealPath().equals(javaBaseInDefaultPath.toRealPath()) ;
> 
> 
> Also, just to say that !Files.exists should be Files.notExists.

Hello Alan,

> Files.isSameFile checks the file contents, this doesn't look right here.

I was always under the impression that `Files.isSameFile()` only checks file paths and attributes for testing whether they are same. The API doc of `Files.isSameFile()` too don't mention about contents and looking at the implementation in `UnixFileSystemProvider` and `ZipFileSystemProvider` (for example), then don't seem to check the contents either. There's however a mention in the API doc of `Files.isSameFile()` which says:

> and depending on the implementation, may require to open or access both files.

So I'm guessing that, that's what allows `FileSystemProvider` implementations to actually check the content of the files.

I'll change this to use `toRealPath()` as you noted.

> Also, just to say that !Files.exists should be Files.notExists.

I've overlooked Files.notExists. I'll update this as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1264264298

From jpai at openjdk.org  Sat Jul 15 00:52:58 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 15 Jul 2023 00:52:58 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v22]
In-Reply-To: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
Message-ID: <E03jOt_mOxQoIWYI1mzkeYqHCsZXHcvuPHRLDR2w9Fk=.1b6917cf-08df-496e-b6ee-e2f1f4a371c6@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 incrementally with one additional commit since the last revision:

  Alan's review - replace Files.isSameFile with toRealPath() checks and also use Files.notExists()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11943/files
  - new: https://git.openjdk.org/jdk/pull/11943/files/258a62d7..59c4d0cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=20-21

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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  Sat Jul 15 00:53:00 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 15 Jul 2023 00:53:00 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v21]
In-Reply-To: <IzNUvukqpcFsJMAdf_XXSXHKp2XPAclAFZKj5VW1XEk=.225f929f-20aa-4477-a563-e88f0b706dd2@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <ncyqPyRO8dEypxI76YMOjO8R_BU4_PwwOzEYUrQrkL8=.de648084-40b5-40cb-aecc-9dd5ad8c4887@github.com>
 <g6wUDXcv3jSQzh6xkqNvfFa0EdhYKbMKv1951Ftg7ho=.6ce175a7-9d68-4e9d-a77d-c6ea24924d15@github.com>
 <IzNUvukqpcFsJMAdf_XXSXHKp2XPAclAFZKj5VW1XEk=.225f929f-20aa-4477-a563-e88f0b706dd2@github.com>
Message-ID: <thc41szuEFjLjry6iKYYtpf13Tr3knsz_FfqmFLMOfc=.03573cc3-1c09-4b14-befd-5361ce099e2a@github.com>

On Sat, 15 Jul 2023 00:41:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 666:
>> 
>>> 664:             return false;
>>> 665:         }
>>> 666:         return Files.isSameFile(javaBasePath, javaBaseInDefaultPath);
>> 
>> Files.isSameFile checks the file contents, this doesn't look right here. Shouldn't this be
>> 
>> return javaBasePath.toRealPath().equals(javaBaseInDefaultPath.toRealPath()) ;
>> 
>> 
>> Also, just to say that !Files.exists should be Files.notExists.
>
> Hello Alan,
> 
>> Files.isSameFile checks the file contents, this doesn't look right here.
> 
> I was always under the impression that `Files.isSameFile()` only checks file paths and attributes for testing whether they are same. The API doc of `Files.isSameFile()` too don't mention about contents and looking at the implementation in `UnixFileSystemProvider` and `ZipFileSystemProvider` (for example), then don't seem to check the contents either. There's however a mention in the API doc of `Files.isSameFile()` which says:
> 
>> and depending on the implementation, may require to open or access both files.
> 
> So I'm guessing that, that's what allows `FileSystemProvider` implementations to actually check the content of the files.
> 
> I'll change this to use `toRealPath()` as you noted.
> 
>> Also, just to say that !Files.exists should be Files.notExists.
> 
> I've overlooked Files.notExists. I'll update this as well.

Done. The PR has been updated with these changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1264265346

From alanb at openjdk.org  Sat Jul 15 06:20:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Jul 2023 06:20:26 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v21]
In-Reply-To: <thc41szuEFjLjry6iKYYtpf13Tr3knsz_FfqmFLMOfc=.03573cc3-1c09-4b14-befd-5361ce099e2a@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <ncyqPyRO8dEypxI76YMOjO8R_BU4_PwwOzEYUrQrkL8=.de648084-40b5-40cb-aecc-9dd5ad8c4887@github.com>
 <g6wUDXcv3jSQzh6xkqNvfFa0EdhYKbMKv1951Ftg7ho=.6ce175a7-9d68-4e9d-a77d-c6ea24924d15@github.com>
 <IzNUvukqpcFsJMAdf_XXSXHKp2XPAclAFZKj5VW1XEk=.225f929f-20aa-4477-a563-e88f0b706dd2@github.com>
 <thc41szuEFjLjry6iKYYtpf13Tr3knsz_FfqmFLMOfc=.03573cc3-1c09-4b14-befd-5361ce099e2a@github.com>
Message-ID: <HHkQtH4WhjaGOg16qUiZbhEgDPPlOlykx-eskehmNPs=.55f2923f-edf1-450f-8527-270825062e0e@github.com>

On Sat, 15 Jul 2023 00:47:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello Alan,
>> 
>>> Files.isSameFile checks the file contents, this doesn't look right here.
>> 
>> I was always under the impression that `Files.isSameFile()` only checks file paths and attributes for testing whether they are same. The API doc of `Files.isSameFile()` too don't mention about contents and looking at the implementation in `UnixFileSystemProvider` and `ZipFileSystemProvider` (for example), then don't seem to check the contents either. There's however a mention in the API doc of `Files.isSameFile()` which says:
>> 
>>> and depending on the implementation, may require to open or access both files.
>> 
>> So I'm guessing that, that's what allows `FileSystemProvider` implementations to actually check the content of the files.
>> 
>> I'll change this to use `toRealPath()` as you noted.
>> 
>>> Also, just to say that !Files.exists should be Files.notExists.
>> 
>> I've overlooked Files.notExists. I'll update this as well.
>
> Done. The PR has been updated with these changes.

Apologies, I somehow had Files.mismatch in my head, which does compare contents. If the files exists, Files.isSameFile is semantically equivalent to checking if the real path to both is equal, so what you had on that file was correct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1264340368

From alanb at openjdk.org  Sat Jul 15 07:07:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Jul 2023 07:07:03 GMT
Subject: RFR: 8312089: Simplify and modernize equals, hashCode,
 and compareTo in java.nio and implementation code [v3]
In-Reply-To: <6I_ZpsYUKuSLeGx-V-yXD6LmPfxZn_seP2oiloCrPgA=.d474a89d-2beb-4326-83d0-47c585cc56b1@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
 <6I_ZpsYUKuSLeGx-V-yXD6LmPfxZn_seP2oiloCrPgA=.d474a89d-2beb-4326-83d0-47c585cc56b1@github.com>
Message-ID: <x3V45gFuV7sXlIBvMXKOtPUA0w1n2IAjteDuNuqFnVs=.9ce013b4-0716-4358-acc4-7015e3e3bb74@github.com>

On Fri, 14 Jul 2023 18:54:35 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 in java.nio and implementation code.
>> 
>> Please note, test results are pending.
>> 
>> Additional notes:
>> 
>> * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements.
>> 
>> * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified.
>> 
>> * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it.
>> 
>> * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification.
>> 
>> * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose.
>> 
>> * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-address feedback

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14886#pullrequestreview-1531305811

From duke at openjdk.org  Sat Jul 15 07:55:34 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 15 Jul 2023 07:55:34 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v19]
In-Reply-To: <nJtaOmnevHioGemQCIfp25ldjI0ZV_BD2ksZp3CJKmk=.a4f1a323-aab6-4c61-bba4-3aee348648c9@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <fp9PEVNZNpBwh0yHwPC9-HhI8vbH6pjDxUd29ogWEmw=.796ded42-ba4b-4a02-86a9-08b680110168@github.com>
 <CJuqpdWdrQpn8QNiocm6EuUzVNwYmoNqX8F3ryTIZ7U=.3dbd8f38-7a5f-4001-a6c9-641d25695081@github.com>
 <nJtaOmnevHioGemQCIfp25ldjI0ZV_BD2ksZp3CJKmk=.a4f1a323-aab6-4c61-bba4-3aee348648c9@github.com>
Message-ID: <yCacBNOi6W74TJ0aAb6wt0aIjMS5LhIJwS3CYWbPhLg=.fa774f83-850e-4c78-8369-35c039801e7a@github.com>

On Wed, 5 Jul 2023 23:30:03 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> It's looking pretty good. 
>> 
>> About the test, I don't see `ArrayList::add` in the generated bytecode of `sub2-13`.   The dedup string set is used for the targets of qualified exports and opens and uses.   The modifiers set of `requires` is deduplicated but not the required module names.
>> 
>> I assume you want this be backported.  If so, we should give it some baked time after it's integrated to the main line.    I'm okay if you want to extend the test in a follow up.     You can extract the generated class to verify:
>> 
>> $ jimage extract --dir=dir out-jlink/lib/modules
>> $ javap -p -v dir/java.base/jdk/internal/module/SystemModules$all.class
>
>> It's looking pretty good.
> 
> Thank you!
> 
>> About the test, I don't see `ArrayList::add` in the generated bytecode of `sub2-13`. The dedup string set is used for the targets of qualified exports and opens and uses. The modifiers set of `requires` is deduplicated but not the required module names.
> 
> Thank you for the hint.
> 
>> I assume you want this be backported. If so, we should give it some baked time after it's integrated to the main line.
> 
> Sounds great!
> 
>> I'm okay if you want to extend the test in a follow up. 
> 
> That would be great. Will take time to craft a proper setting.

> @koppor do you have any update on a new test for [JDK-8311591](https://bugs.openjdk.org/browse/JDK-8311591)?

Currently on a business trip. Will resume work on this next week the latest.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14408#issuecomment-1636702078

From quadhier at outlook.com  Sat Jul 15 16:53:49 2023
From: quadhier at outlook.com (Daohan Qu)
Date: Sat, 15 Jul 2023 16:53:49 +0000
Subject: Questions about using `assert` in Java
In-Reply-To: <BLAPR07MB7508C14D0D90DF38CC6CC758CB37A@BLAPR07MB7508.namprd07.prod.outlook.com>
References: <BLAPR07MB7508C14D0D90DF38CC6CC758CB37A@BLAPR07MB7508.namprd07.prod.outlook.com>
Message-ID: <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>

Dear developers,

I'm a graduate student doing software engineering research.
Recently, I came across some interesting facts about Java assert?
statements and have a few questions to ask.

Although the assert? keyword has been around for a long time and
is handy for invariant checks, it does not seem to be widely used.
For example, in the famous j.u.c? packages, nearly all assert?
statements are commented out [1].

My questions are, should assert? be heavily used in Java programs,
especially in production code? And should we enable them in the
production code?

By the way, I have read a useful article about using assertions in
Java [2], but it does not provide clear answers to my questions above.

Thank you in advance!

[1] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+assert+path%3A%2F%5Esrc%5C%2Fjava.base%5C%2Fshare%5C%2Fclasses%5C%2Fjava%5C%2Futil%5C%2Fconcurrent%5C%2F%2F&type=code
[2] https://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html

Regards,
Daohan Qu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230715/04162aac/attachment-0001.htm>

From liangchenblue at gmail.com  Sat Jul 15 23:09:48 2023
From: liangchenblue at gmail.com (-)
Date: Sun, 16 Jul 2023 07:09:48 +0800
Subject: Questions about using `assert` in Java
In-Reply-To: <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
References: <BLAPR07MB7508C14D0D90DF38CC6CC758CB37A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
Message-ID: <CABe8uE3vdchyKFKVxKHeSJeSh6ZERok1xyiYdYTHn3NeDes6Aw@mail.gmail.com>

Hi Daohan,
assert keyword is safely usable within production code. I don't think it
has a significant performance impact if it is not enabled. Thus, you should
not enable it in production unless you are debugging.

A package that uses assert extensively is java.lang.invoke package.

For me, these are the general notes for using assert:
1. They should not perform side-effects, such as changing variables. Having
-ea, -esa and no flag run differently is definitely not desirable.
2. assert should not be used to defend against incorrect user inputs; it
should only be used to ensure the correctness of internal states of your
program, as assert is optional.

Chen Liang

On Sun, Jul 16, 2023 at 12:54?AM Daohan Qu <quadhier at outlook.com> wrote:

> Dear developers,
>
> I'm a graduate student doing software engineering research.
> Recently, I came across some interesting facts about Java assert?
> statements and have a few questions to ask.
>
> Although the assert? keyword has been around for a long time and
> is handy for invariant checks, it does not seem to be widely used.
> For example, in the famous j.u.c? packages, nearly all assert?
> statements are commented out [1].
>
> My questions are, should assert? be heavily used in Java programs,
> especially in production code? And should we enable them in the
> production code?
>
> By the way, I have read a useful article about using assertions in
> Java [2], but it does not provide clear answers to my questions above.
>
> Thank you in advance!
>
> [1]
> https://github.com/search?q=repo%3Aopenjdk%2Fjdk+assert+path%3A%2F%5Esrc%5C%2Fjava.base%5C%2Fshare%5C%2Fclasses%5C%2Fjava%5C%2Futil%5C%2Fconcurrent%5C%2F%2F&type=code
> [2]
> https://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html
>
> Regards,
> Daohan Qu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230716/a4bb6541/attachment.htm>

From davidalayachew at gmail.com  Sun Jul 16 06:16:55 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 16 Jul 2023 02:16:55 -0400
Subject: Illegal field name when trying to compile with a javax.swing.Action
Message-ID: <CAA9v-_Oo39GDpyXTDFrmbEGDBEWgTbD4WALFgOO2YweRJ1Nv_g@mail.gmail.com>

Hello Core Libs Dev Team,

I tried to compile the attached project, and got the following error.

Exception in thread "main" java.lang.ClassFormatError: Illegal field name
"" in class ToDoList$2
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1027)
at
java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
at
java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
at
java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
at ToDoList.main(ToDoList.java:73)

Attached is the zip. StackOverflow was not much help, so I thought I would
reach out here.

Thank you all for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230716/b3888493/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ToDoList.zip
Type: application/x-zip-compressed
Size: 3734 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230716/b3888493/ToDoList.zip>

From jpai at openjdk.org  Sun Jul 16 06:24:59 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 16 Jul 2023 06:24:59 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v23]
In-Reply-To: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
Message-ID: <-GwCOUeSoe31ahXMdyYyex98hMT0k-jz-dKmNW5YQj4=.af94ac0f-c40d-4fad-a800-d8aa4eeda921@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 incrementally with one additional commit since the last revision:

  Revert back to Files.isSameFile()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11943/files
  - new: https://git.openjdk.org/jdk/pull/11943/files/59c4d0cc..5da4ba9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=21-22

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Sun Jul 16 06:25:01 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 16 Jul 2023 06:25:01 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v21]
In-Reply-To: <HHkQtH4WhjaGOg16qUiZbhEgDPPlOlykx-eskehmNPs=.55f2923f-edf1-450f-8527-270825062e0e@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <ncyqPyRO8dEypxI76YMOjO8R_BU4_PwwOzEYUrQrkL8=.de648084-40b5-40cb-aecc-9dd5ad8c4887@github.com>
 <g6wUDXcv3jSQzh6xkqNvfFa0EdhYKbMKv1951Ftg7ho=.6ce175a7-9d68-4e9d-a77d-c6ea24924d15@github.com>
 <IzNUvukqpcFsJMAdf_XXSXHKp2XPAclAFZKj5VW1XEk=.225f929f-20aa-4477-a563-e88f0b706dd2@github.com>
 <thc41szuEFjLjry6iKYYtpf13Tr3knsz_FfqmFLMOfc=.03573cc3-1c09-4b14-befd-5361ce099e2a@github.com>
 <HHkQtH4WhjaGOg16qUiZbhEgDPPlOlykx-eskehmNPs=.55f2923f-edf1-450f-8527-270825062e0e@github.com>
Message-ID: <AZ04Q2n2ZTGSq1OqmvJUUVV-BlIAc_0QZELXD2MLN2Q=.20c55e4e-31e8-412e-895d-b786849bad67@github.com>

On Sat, 15 Jul 2023 06:16:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Done. The PR has been updated with these changes.
>
> Apologies, I somehow had Files.mismatch in my head, which does compare contents. If the files exists, Files.isSameFile is semantically equivalent to checking if the real path to both is equal, so what you had on that file was correct.

Hello Alan,

> If the files exists, Files.isSameFile is semantically equivalent to checking if the real path to both is equal, so what you had on that file was correct.

I've updated the PR to use `Files.isSameFile()` like previously.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1264615812

From davidalayachew at gmail.com  Sun Jul 16 06:26:05 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 16 Jul 2023 02:26:05 -0400
Subject: Illegal field name when trying to compile with a
 javax.swing.Action
In-Reply-To: <CAA9v-_Oo39GDpyXTDFrmbEGDBEWgTbD4WALFgOO2YweRJ1Nv_g@mail.gmail.com>
References: <CAA9v-_Oo39GDpyXTDFrmbEGDBEWgTbD4WALFgOO2YweRJ1Nv_g@mail.gmail.com>
Message-ID: <CAA9v-_OiVNJFNMUSj191YjEB5-Qn79wRkSZTTD6fF5WEszq=tw@mail.gmail.com>

Hmmmm, this one might actually be IDE specific. Please ignore.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230716/8dbfd210/attachment.htm>

From alanb at openjdk.org  Sun Jul 16 06:58:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Jul 2023 06:58:27 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v23]
In-Reply-To: <-GwCOUeSoe31ahXMdyYyex98hMT0k-jz-dKmNW5YQj4=.af94ac0f-c40d-4fad-a800-d8aa4eeda921@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <-GwCOUeSoe31ahXMdyYyex98hMT0k-jz-dKmNW5YQj4=.af94ac0f-c40d-4fad-a800-d8aa4eeda921@github.com>
Message-ID: <6KmKg94ddPXFBaIrPkLctkJJsMzwQnfKB8HCshG8Wg8=.16b527c1-5551-429f-a9e9-3f72e0bd4dc3@github.com>

On Sun, 16 Jul 2023 06:24:59 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 one additional commit since the last revision:
> 
>   Revert back to Files.isSameFile()

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/11943#pullrequestreview-1531675604

From jpai at openjdk.org  Sun Jul 16 07:15:37 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 16 Jul 2023 07:15:37 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v23]
In-Reply-To: <-GwCOUeSoe31ahXMdyYyex98hMT0k-jz-dKmNW5YQj4=.af94ac0f-c40d-4fad-a800-d8aa4eeda921@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <-GwCOUeSoe31ahXMdyYyex98hMT0k-jz-dKmNW5YQj4=.af94ac0f-c40d-4fad-a800-d8aa4eeda921@github.com>
Message-ID: <YOcwg5A6EXKmuq1VNXwr0ZhdSfV2G7-FMiaY3Yl-8eQ=.ce6ea19e-132f-42b5-a0e8-c5a9a124119c@github.com>

On Sun, 16 Jul 2023 06:24:59 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 one additional commit since the last revision:
> 
>   Revert back to Files.isSameFile()

Thank you everyone for the multiple back and forth reviews on this one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1637002035

From jpai at openjdk.org  Sun Jul 16 07:15:40 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 16 Jul 2023 07:15:40 GMT
Subject: Integrated: 8304006: jlink should create the jimage file in the native
 endian for the target platform
In-Reply-To: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
Message-ID: <mrH_AK7eeSALZ97H9sNy4hMc6LHuOO2R3p9ennp2HzA=.27359e12-550d-400a-885f-79b1b13b9699@github.com>

On Wed, 11 Jan 2023 13:19:32 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.

This pull request has now been integrated.

Changeset: 81c4e8f9
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81c4e8f916a04582698907291b6505d4484cf9c2
Stats:     279 lines in 9 files changed: 215 ins; 32 del; 32 mod

8304006: jlink should create the jimage file in the native endian for the target platform

Co-authored-by: Mandy Chung <mchung at openjdk.org>
Reviewed-by: alanb, mchung, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/11943

From vtewari at openjdk.org  Sun Jul 16 11:34:18 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Sun, 16 Jul 2023 11:34:18 GMT
Subject: RFR: 8312089: Simplify and modernize equals, hashCode,
 and compareTo in java.nio and implementation code [v3]
In-Reply-To: <6I_ZpsYUKuSLeGx-V-yXD6LmPfxZn_seP2oiloCrPgA=.d474a89d-2beb-4326-83d0-47c585cc56b1@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
 <6I_ZpsYUKuSLeGx-V-yXD6LmPfxZn_seP2oiloCrPgA=.d474a89d-2beb-4326-83d0-47c585cc56b1@github.com>
Message-ID: <rBvDiZx6uHt4Hpfw5Jf7rC26kXN0kN9_jUT9FWSVpu8=.28a470c9-f8cf-4193-899d-b88abd84279d@github.com>

On Fri, 14 Jul 2023 18:54:35 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 in java.nio and implementation code.
>> 
>> Please note, test results are pending.
>> 
>> Additional notes:
>> 
>> * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements.
>> 
>> * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified.
>> 
>> * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it.
>> 
>> * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification.
>> 
>> * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose.
>> 
>> * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-address feedback

Looks OK to me.

-------------

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14886#pullrequestreview-1531726844

From ryan at iernst.net  Sun Jul 16 12:54:03 2023
From: ryan at iernst.net (Ryan Ernst)
Date: Sun, 16 Jul 2023 05:54:03 -0700
Subject: List extending Collection/SequencedCollection
In-Reply-To: <871a9b9a-eb27-83dc-626c-1aac379feab7@oracle.com>
References: <871a9b9a-eb27-83dc-626c-1aac379feab7@oracle.com>
Message-ID: <23DB1715-4367-4512-ADC7-F105DAA4EA35@iernst.net>

Hi Joe and Stuart,

Given the inconsistencies mentioned, I see how this change may not be worth the hassle, so I?ll drop it. I appreciate the thoughtful responses to explain your reasoning. 

Thanks!
Ryan 


> On Jul 7, 2023, at 4:21 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> ?Hi Ryan,
> 
> Thanks for trying out JDK 21 early access.
> 
> The issue you raise is indeed an inconsistency, but it's not clear which way it should be resolved, or even whether it needs to be resolved, as the consequences are quite minor.
> 
> Specifically, when the Sequenced Collections JEP was integrated, it included these changes (edited for brevity):
> 
> - public interface List<E> extends Collection<E> {
> + public interface List<E> extends SequencedCollection<E> {
> 
> - public interface SortedSet<E> extends Set<E> {
> + public interface SortedSet<E> extends Set<E>, SequencedSet<E> {
> 
> As you observed, on List, SequencedCollection has replaced Collection, but on SortedSet, SequencedSet was added alongside Set. Which way is correct? Should SequencedCollection have been added to List, instead of replacing Collection? Or on SortedSet, should SequencedSet have replaced Set instead of simply being added?
> 
> (I have to admit my first inclination was that the SortedSet change was a mistake, and that SequencedSet ought to have replaced Set. I think the reason it turned out the way it did was that, my earliest prototype, before I published anything, had a single interface OrderedCollection. This was retrofitted onto SortedSet as
> 
>    public interface SortedSet<E> extends Set<E>, OrderedCollection<E> {
> 
> Only later did I decide to add OrderedSet, and so I changed the declaration to
> 
>    public interface SortedSet<E> extends Set<E>, OrderedSet<E> {
> 
> and I didn't notice that the interfaces could be minimized. And of course there were a couple rounds of renaming subsequent to this.)
> 
> In any case, this inconsistency is of little consequence, as the members available to users of the interfaces in question are the same regardless of the way the interfaces are declared. This is true from both a source and binary compatibility standpoint.
> 
> Joe's point about compatibility is that even though such changes are *visible* to reflective code, they aren't *incompatible*. There are many compatible changes possible, such as moving the declaration of a method upward in the hierarchy. From the standpoint of reflection, that method may appear to have been removed from some interface; but that doesn't mean it's incompatible. Reflective code needs to be adjusted to take such things into account. The presence or absence of Collection as a superinterface of List is a similar case.
> 
> Perhaps in some sense the JDK itself ought to be more consistent about this. We have for example this:
> 
>    class HashSet extends AbstractSet implements Set, Cloneable, Serializable
> 
> but also this:
> 
>    class EnumSet extends AbstractSet implements Cloneable, Serializable
> 
> (That is, EnumSet is "missing" Set.)
> 
> Questions about this have been asked on Stack Overflow, and various answers there have made up a rationale about the possibly-redundant interfaces being included explicitly because it expresses intent more clearly, or some such. My own guess is that nobody has paid much attention to this issue because resolving it one way or another hardly makes any practical difference.
> 
> s'marks
> 
>> On 7/7/23 7:25 AM, Ryan Ernst wrote:
>> Thanks for laying out your thinking, Joe. I will watch your talks.
>> If I understood your response correctly, you are ok making such a change, especially since it is semantically equivalent? If that?s the case, is JDK 21 past the point of feature release, or should the change target only 22? It doesn?t matter much to me, but I thought since SequencedCollection is added in 21 it would be good to ?fix? this there so as to avoid a gap in behavior.
>>>> On Jun 30, 2023, at 6:13 PM, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
>>> 
>>> ?Hi Ryan,
>>> 
>>> Apropos of this discussion, I happened to recently give a talk to the JCP that in part covered behavioral compatibility in the JDK:
>>> 
>>> https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-06-13/JCP-EC-Public-Agenda-June-2023.html
>>> https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-06-13/Contributing_to_OpenJDK_2023_04_12.pdf
>>> 
>>> There are many observable details of the JDK implementation, including reflective details, timing, etc. there are _not_ part of the interfaces users should rely on.
>>> 
>>> My current evaluation here is that it would set an unfortunate precedent to preclude making the sort of source changes in questions because of (potential) compatibility concerns in reflective modeling, especially in a feature release. (IMO, there is a stronger argument for not making such a change in an update release, but even there as the change is a semantically equivalent refactoring, I think it is generally fine.)
>>> 
>>> HTH,
>>> 
>>> -Joe
>>> 
>>>> On 6/29/2023 11:30 AM, Ryan Ernst wrote:
>>>> 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 duke at openjdk.org  Mon Jul 17 01:11:24 2023
From: duke at openjdk.org (yaqsun)
Date: Mon, 17 Jul 2023 01:11:24 GMT
Subject: RFR: 8311631: When multiple users run
 tools/jpackage/share/LicenseTest.java,
 Permission denied for writing /var/tmp/*.files [v2]
In-Reply-To: <TUeytaZUrHMd3oY7bZSlvXQD1pmFbLB3yj9C1hG5S24=.fa60a3b9-faef-471b-af2e-915c022c792e@github.com>
References: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
 <tlogilGhgOPDCmKldD1UWGwoRqi3TYNe3tmgKG2D8EY=.0d789b18-6aac-4102-859d-653aab1cbcdf@github.com>
 <TUeytaZUrHMd3oY7bZSlvXQD1pmFbLB3yj9C1hG5S24=.fa60a3b9-faef-471b-af2e-915c022c792e@github.com>
Message-ID: <vTdZU0YqeDNZy5md1xEAYyiBUx_JpEBPlihm3NSns64=.7a2971c7-4506-4dbc-bc61-d2b8921897ff@github.com>

On Fri, 14 Jul 2023 21:58:33 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> The fix with `%{_builddir}` looks better. Did it resolve the issue?

Yes, it solved. The root of intermediate files changed to /tmp/jdk.jpackage16701381473798822/BUILD/commonlicensetest.filesystem.files.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14802#issuecomment-1637254675

From asotona at openjdk.org  Mon Jul 17 07:04:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jul 2023 07:04:56 GMT
Subject: RFR: 8311172: Classfile.PREVIEW_MINOR_VERSION doesn't match that
 read from class files
In-Reply-To: <L_EN0XDnpbMvBe2jijx1WID-983acfSY0uY7muNEdAY=.00445838-19c2-4fe2-b8d1-10e7dc00f1fb@github.com>
References: <L_EN0XDnpbMvBe2jijx1WID-983acfSY0uY7muNEdAY=.00445838-19c2-4fe2-b8d1-10e7dc00f1fb@github.com>
Message-ID: <CU0EHOi_6rtFjNp862cQan89zNf03eRxlDEtLHS0dTQ=.4326f291-9da1-4540-8ff3-794e99676fa5@github.com>

On Fri, 30 Jun 2023 13:10:55 GMT, Chen Liang <liach at openjdk.org> wrote:

> `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.

It looks good, thanks for the fix.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14731#pullrequestreview-1532114201

From coffeys at openjdk.org  Mon Jul 17 08:31:21 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 17 Jul 2023 08:31:21 GMT
Subject: Integrated: 8310201: Reduce verbose locale output in -XshowSettings
 launcher option
In-Reply-To: <XXbMAO0gXhtWOhbs_iDqmQpdnus-xdEEY4sufnRb8No=.32addd37-6f00-4f63-8a9d-17784d1a405c@github.com>
References: <XXbMAO0gXhtWOhbs_iDqmQpdnus-xdEEY4sufnRb8No=.32addd37-6f00-4f63-8a9d-17784d1a405c@github.com>
Message-ID: <kuNh4ANoAzoosny2IHAUPacMlj2uH3MAdnl18y6Ials=.08bceed8-db85-48ad-ae79-da15726959ec@github.com>

On Fri, 14 Jul 2023 10:01:16 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Simple tweak to remove the "available locales" section from default `-XshowSettings` output.
> 
> Instead, it remains available with the `-XshowSettings:locale` option

This pull request has now been integrated.

Changeset: f6e23ae4
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f6e23ae4519f8eb877ae28a0bfbb4820c9718f91
Stats:     22 lines in 2 files changed: 15 ins; 0 del; 7 mod

8310201: Reduce verbose locale output in -XshowSettings launcher option

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/14885

From Alan.Bateman at oracle.com  Mon Jul 17 09:08:23 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 17 Jul 2023 10:08:23 +0100
Subject: Questions about using `assert` in Java
In-Reply-To: <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
References: <BLAPR07MB7508C14D0D90DF38CC6CC758CB37A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
Message-ID: <91b41b49-a38c-f72e-2ad1-c52be83021f0@oracle.com>

On 15/07/2023 17:53, Daohan Qu wrote:
> :
>
> Although the |assert|? keyword has been around for a long time and
> is handy for invariant checks, it does not seem to be widely used.
> For example, in the famous |j.u.c|? packages, nearly all |assert|?
> statements are commented out [1].
>
> My questions are, should |assert|? be heavily used in Java programs,
> especially in production code? And should we enable them in the
> production code?
>
Asserts are very useful during development or when testing, e.g. the JDK 
tests run with -esa and can periodically help catch issues when testing 
a change.

You will find places in the JDK code, esp. in performance critical code, 
where assertions are commented out. The reason is that asserts, even if 
disabled, increase the method size and can impact inlining by the 
compiler at run-time.? So while useful when debugging some issue in such 
code, they are commended out to avoid increasing the method size.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230717/0b7e08dc/attachment-0001.htm>

From prappo at openjdk.org  Mon Jul 17 09:43:44 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 17 Jul 2023 09:43:44 GMT
Subject: RFR: 8312164: Refactor Arrays.hashCode for long, boolean,
 and Object arrays
Message-ID: <2fzWrAYSsxemNshKqA4md_k78mO1gmUSvylsaDSf_7w=.c9b6c8b8-8204-4bb8-a7a0-2496e5d3cf38@github.com>

Please review this PR to refactor Arrays.hashCode for long[], boolean[], and Object[]. I've been told elsewhere that it shouldn't have significant performance implications.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14900/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14900&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312164
  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14900.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14900/head:pull/14900

PR: https://git.openjdk.org/jdk/pull/14900

From john.hendrikx at gmail.com  Mon Jul 17 10:14:30 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 17 Jul 2023 12:14:30 +0200
Subject: Questions about using `assert` in Java
In-Reply-To: <91b41b49-a38c-f72e-2ad1-c52be83021f0@oracle.com>
References: <BLAPR07MB7508C14D0D90DF38CC6CC758CB37A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <91b41b49-a38c-f72e-2ad1-c52be83021f0@oracle.com>
Message-ID: <1029c4a1-148e-4469-12a6-574d62d2c9cf@gmail.com>

On 17/07/2023 11:08, Alan Bateman wrote:
> On 15/07/2023 17:53, Daohan Qu wrote:
>> :
>>
>> Although the |assert|? keyword has been around for a long time and
>> is handy for invariant checks, it does not seem to be widely used.
>> For example, in the famous |j.u.c|? packages, nearly all |assert|?
>> statements are commented out [1].
>>
>> My questions are, should |assert|? be heavily used in Java programs,
>> especially in production code? And should we enable them in the
>> production code?
>>
> Asserts are very useful during development or when testing, e.g. the 
> JDK tests run with -esa and can periodically help catch issues when 
> testing a change.
>
> You will find places in the JDK code, esp. in performance critical 
> code, where assertions are commented out. The reason is that asserts, 
> even if disabled, increase the method size and can impact inlining by 
> the compiler at run-time.? So while useful when debugging some issue 
> in such code, they are commended out to avoid increasing the method size.

I believe this can be partially alleviated by extracting the asserts to 
a method (partially as the call also increases method size).? The 
optimizer seems to be smart enough to not call the method if it does 
nothing (when ea is disabled).

--John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230717/edaf78d6/attachment.htm>

From aturbanov at openjdk.org  Mon Jul 17 11:01:03 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 17 Jul 2023 11:01:03 GMT
Subject: RFR: 8311663: Additional refactoring of Locale tests to JUnit
In-Reply-To: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
References: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
Message-ID: <D9hUKbREEU6tQR_i57jBoAmDknti1gXsd8xytsYByKI=.19f87551-1c63-4608-a10f-c9f29e9458c1@github.com>

On Thu, 13 Jul 2023 23:23:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which refactors more java.util.Locale tests to JUnit with some minor cleanup as well.
> 
> Although some of the files could benefit from being renamed bugNNNNNNN to something more descriptive, this makes reviewing harder, and will be handled separately.

test/jdk/java/util/Locale/Bug8179071.java line 78:

> 76:         return Stream.of(
> 77:                 Arguments.of("pa-PK", "\u0a1c\u0a28"),
> 78:                 Arguments.of("uz-AF" , "yan"),

Suggestion:

                Arguments.of("uz-AF", "yan"),

test/jdk/java/util/Locale/Bug8179071.java line 95:

> 93:                 .forEach(tag -> {if(LegacyAliases.contains(tag)) {invalidTags.add(tag);}});
> 94:         assertEquals(true, invalidTags.isEmpty(),
> 95:                 "Deprecated and Legacy tags found  " + invalidTags  + " in AvailableLocales ");

Suggestion:

                "Deprecated and Legacy tags found  " + invalidTags + " in AvailableLocales ");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1265185559
PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1265185856

From simonis at openjdk.org  Mon Jul 17 11:06:24 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 17 Jul 2023 11:06:24 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() throws UOE if invoked
 reflectively [v3]
In-Reply-To: <BhLE3dfNH4BcJr1wdYplaRLON1PAABl_Kxw9bE0S36k=.388595b3-0094-41af-ad7c-ce8183fb72b2@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
 <BhLE3dfNH4BcJr1wdYplaRLON1PAABl_Kxw9bE0S36k=.388595b3-0094-41af-ad7c-ce8183fb72b2@github.com>
Message-ID: <cH3L7Wp-PX2ojZ0feZSJ_jWaOfrm5CoJRXEuDUbe0Ic=.15381ede-df75-41a6-9d36-abad98618acd@github.com>

On Tue, 11 Jul 2023 15:47:35 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> As the included jtreg test demonstrates, `StackWalker.getCallerClass()` can throw an `UnsupportedOperationException` if called reflectively. Currently this only happens if we invoke `StackWalker.getCallerClass()` recursively reflectively, but this issue will become more prominent once we fix [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447). The gory details follow below:
>> 
>> The protocol between the Java API and the JVM for `StackWalker.getCallerClass()/walk()` is as follows:
>> - On the Java side, `StackWalker` calls into `StackStreamFactory` for the real work.
>> - For `StackWalker.getCallerClass()` `StackStreamFactory` basically creates a `Class[]` which will be passed down and filled in the JVM. For `StackWalker.walk()` it will normally be a `StackFrameInfo[]` (or a `LiveStackFrameInfo[]` if the internal `ExtendedOption.LOCALS_AND_OPERANDS` option was used).
>> - The default size of this arrays is currently `StackStreamFactory.SMALL_BATCH` which is 8 (but see [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447)).
>> - `StackStreamFactory` than calls `AbstractStackWalker.callStackWalk()` which is a natively implemented in the VM by `JVM_CallStackWalk()`.
>> -  `JVM_CallStackWalk()` calls `StackWalk::walk()` which calls `StackWalk::fetchFirstBatch()` which calls `StackWalk::fill_in_frames()` which walks the stack and fills in the available class/stackframe slots in the passed in array until the array is full or there are no more stack frames,
>> - Once  `StackWalk::fill_in_frames()` returns, `StackWalk::fetchFirstBatch()` calls back to Java by invoking `AbstractStackWalker::doStackWalk()` to consume the result.
>> - `AbstractStackWalker::doStackWalk()` calls `consumeFrames()` (which is overridden depending on whether we initially called `getCallerClass()` or `walk()`) which consumes the frames until it either finishes (e.g. finds the caller class) or until there are no more frames.
>> - In the latter case `consumeFrames()` will call into the the VM again by calling `AbstractStackWalker.fetchStackFrames()` to fetch additional frames from the stack.
>> - `AbstractStackWalker.fetchStackFrames()` is implemented by `JVM_MoreStackWalk()` which calls `StackWalk::fetchNextBatch()` which calls `StackWalk::fill_in_frames()` (the same method that already fetched the initial batch of frames).
>> 
>> Following is a stacktrace of what I've explained so far:
>> 
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x1...
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed case when calling getCallerClass() from a @CallerSensitive method reflectively

We actually have two problems here:
1. If called refelctively, `getCallerClass()` can throw an UOE even if it was **not** called from a `@CallerSensitive` method (see inital test case).
2. If called reflectively from a  `@CallerSensitive` method, `getCallerClass()` will currently not throw a UOE as expected (see extended test in this PR).

`getCallerClass()` **is** performance sensitive and we want to improve its performance rather than slow it down (see [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447)). I think performance-wise it would be better to do all the filtering in the VM, where we have all the required information at hand and minimize the amount of data that needs to be passed between Java and the VM.

Before starting to implement a new version of the fix which moves all the checks to Java, I'd like to hear some more opinions about whether we agree to move all the filtering and checks from the VM to Java (even at the cost of performance regressions) or if we better want to go the other way and do all the filtering/checks in the JVM. @shipilev, @dholmes-ora, @dfuch, @AlanBateman - what do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14773#issuecomment-1637900903

From pavel.rappo at oracle.com  Mon Jul 17 11:29:38 2023
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 17 Jul 2023 11:29:38 +0000
Subject: Questions about using `assert` in Java
In-Reply-To: <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
References: <BLAPR07MB7508C14D0D90DF38CC6CC758CB37A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
Message-ID: <7B791D00-C23B-4B30-8430-35E7277BC1E4@oracle.com>

In this thread, Alan has already pointed out possible runtime cost of Java assertions. But as far as the general idea goes, I find assertions to be very helpful.

There have been studies looking into correlation between assertion density and fault/defect density. Here's one such study: "Assessing the Relationship between Software Assertions and Code Quality: An Empirical Investigation" [^1].

Modern Java IDEs make use of assertions. IDEs analyse and highlight assertions that are always false or always true, helping the author to reason about their program as they type it.

That said, Java assertions are a bit anaemic. I wish they generated helpful messages automatically (though I realise that it might have security implications). Consider these assertions:

  * assert x >= 0;
  * assert x && y;
  * assert a == b;
  * assert ( f ? foo() : bar() );

I would like the compiler to transform those into these (respectively):

  * assert x >= 0 : x;
  * assert x && y : x + ", " + y;
  * assert a == b : a + ", " + b;
  * assert ( f ? foo() : bar() ) : f;

-Pavel

---

[^1]: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2006-54.pdf

> On 15 Jul 2023, at 17:53, Daohan Qu <quadhier at outlook.com> wrote:
> 
> Dear developers,
> 
> I'm a graduate student doing software engineering research.
> Recently, I came across some interesting facts about Java assert?
> statements and have a few questions to ask.
> 
> Although the assert? keyword has been around for a long time and
> is handy for invariant checks, it does not seem to be widely used.
> For example, in the famous j.u.c? packages, nearly all assert?
> statements are commented out [1].
> 
> My questions are, should assert? be heavily used in Java programs,
> especially in production code? And should we enable them in the
> production code?
> 
> By the way, I have read a useful article about using assertions in
> Java [2], but it does not provide clear answers to my questions above.
> 
> Thank you in advance!
> 
> [1] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+assert+path%3A%2F%5Esrc%5C%2Fjava.base%5C%2Fshare%5C%2Fclasses%5C%2Fjava%5C%2Futil%5C%2Fconcurrent%5C%2F%2F&type=code
> [2] https://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html
> 
> Regards,
> Daohan Qu
> 


From liach at openjdk.org  Mon Jul 17 11:57:21 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Jul 2023 11:57:21 GMT
Subject: Integrated: 8311172: Classfile.PREVIEW_MINOR_VERSION doesn't match
 that read from class files
In-Reply-To: <L_EN0XDnpbMvBe2jijx1WID-983acfSY0uY7muNEdAY=.00445838-19c2-4fe2-b8d1-10e7dc00f1fb@github.com>
References: <L_EN0XDnpbMvBe2jijx1WID-983acfSY0uY7muNEdAY=.00445838-19c2-4fe2-b8d1-10e7dc00f1fb@github.com>
Message-ID: <MOu7cZyjLqZ7H05a3pxvyma9VlAMOF198EpTlPUlP-w=.d9cc068d-04f9-4933-8cd4-35e8ed18dbd3@github.com>

On Fri, 30 Jun 2023 13:10:55 GMT, Chen Liang <liach at openjdk.org> wrote:

> `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.

This pull request has now been integrated.

Changeset: 3fb9d117
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3fb9d117e353af6f007e701a8cd635763bd3cc28
Stats:     65 lines in 2 files changed: 64 ins; 0 del; 1 mod

8311172: Classfile.PREVIEW_MINOR_VERSION doesn't match that read from class files

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/14731

From quadhier at outlook.com  Mon Jul 17 13:02:54 2023
From: quadhier at outlook.com (Daohan Qu)
Date: Mon, 17 Jul 2023 13:02:54 +0000
Subject: Questions about using `assert` in Java
In-Reply-To: <CABe8uE3vdchyKFKVxKHeSJeSh6ZERok1xyiYdYTHn3NeDes6Aw@mail.gmail.com>
References: <BLAPR07MB7508C14D0D90DF38CC6CC758CB37A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <CABe8uE3vdchyKFKVxKHeSJeSh6ZERok1xyiYdYTHn3NeDes6Aw@mail.gmail.com>
Message-ID: <BLAPR07MB7508A4351F8722260B060435CB3BA@BLAPR07MB7508.namprd07.prod.outlook.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230717/f4f8779b/attachment-0001.htm>

From quadhier at outlook.com  Mon Jul 17 13:09:29 2023
From: quadhier at outlook.com (Daohan Qu)
Date: Mon, 17 Jul 2023 13:09:29 +0000
Subject: Questions about using `assert` in Java
In-Reply-To: <CABe8uE3vdchyKFKVxKHeSJeSh6ZERok1xyiYdYTHn3NeDes6Aw@mail.gmail.com>
References: <BLAPR07MB7508C14D0D90DF38CC6CC758CB37A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <CABe8uE3vdchyKFKVxKHeSJeSh6ZERok1xyiYdYTHn3NeDes6Aw@mail.gmail.com>
Message-ID: <BLAPR07MB750883969BC913EEA095E7A6CB3BA@BLAPR07MB7508.namprd07.prod.outlook.com>

Hi Liang,

Thank you for your response! The provided guidelines are quite helpful. I have
noticed that different packages in JDK use the assert? keyword to varying degrees.
I wonder if this is more a matter of developer preference (if it is not the performance
reason mentioned by Alan). :P

Regards,
Daohan

________________________________
From: liangchenblue at gmail.com <liangchenblue at gmail.com>
Sent: Sunday, July 16, 2023 7:09
To: Daohan Qu <quadhier at outlook.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: Questions about using `assert` in Java

Hi Daohan,
assert keyword is safely usable within production code. I don't think it has a significant performance impact if it is not enabled. Thus, you should not enable it in production unless you are debugging.

A package that uses assert extensively is java.lang.invoke package.

For me, these are the general notes for using assert:
1. They should not perform side-effects, such as changing variables. Having -ea, -esa and no flag run differently is definitely not desirable.
2. assert should not be used to defend against incorrect user inputs; it should only be used to ensure the correctness of internal states of your program, as assert is optional.

Chen Liang

On Sun, Jul 16, 2023 at 12:54?AM Daohan Qu <quadhier at outlook.com<mailto:quadhier at outlook.com>> wrote:
Dear developers,

I'm a graduate student doing software engineering research.
Recently, I came across some interesting facts about Java assert?
statements and have a few questions to ask.

Although the assert? keyword has been around for a long time and
is handy for invariant checks, it does not seem to be widely used.
For example, in the famous j.u.c? packages, nearly all assert?
statements are commented out [1].

My questions are, should assert? be heavily used in Java programs,
especially in production code? And should we enable them in the
production code?

By the way, I have read a useful article about using assertions in
Java [2], but it does not provide clear answers to my questions above.

Thank you in advance!

[1] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+assert+path%3A%2F%5Esrc%5C%2Fjava.base%5C%2Fshare%5C%2Fclasses%5C%2Fjava%5C%2Futil%5C%2Fconcurrent%5C%2F%2F&type=code
[2] https://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html

Regards,
Daohan Qu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230717/57c9e3ab/attachment.htm>

From asotona at openjdk.org  Mon Jul 17 13:32:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jul 2023 13:32:48 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v10]
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: <warwY6Uc-k1ldxms-yVB6R8gbOb8SVwwIClAYglGfoI=.cb2c1dc2-a4f1-498a-98c6-dd2e6b47cef0@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 226 commits:

 - Merge branch 'master' into JDK-8294969-javap
 - fixed code printing and ConstantPoolException reporting indoex
 - added DydnamicConstantPoolEntry::bootstrapMethodIndex
   fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
 - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead
 - 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
 - ... and 216 more: https://git.openjdk.org/jdk/compare/3fb9d117...b63758dd

-------------

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=09
  Stats: 3830 lines in 29 files changed: 1001 ins; 1701 del; 1128 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 quadhier at outlook.com  Mon Jul 17 13:34:22 2023
From: quadhier at outlook.com (Daohan Qu)
Date: Mon, 17 Jul 2023 13:34:22 +0000
Subject: Questions about using `assert` in Java
In-Reply-To: <91b41b49-a38c-f72e-2ad1-c52be83021f0@oracle.com>
References: <BLAPR07MB7508C14D0D90DF38CC6CC758CB37A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <91b41b49-a38c-f72e-2ad1-c52be83021f0@oracle.com>
Message-ID: <BLAPR07MB750866A48BF199752E70219FCB3BA@BLAPR07MB7508.namprd07.prod.outlook.com>

Hi Alan,

> You will find places in the JDK code, esp. in performance critical code,
> where assertions are commented out. The reason is that asserts, even if
> disabled, increase the method size and can impact inlining by the
> compiler at run-time. So while useful when debugging some issue in such
> code, they are commended out to avoid increasing the method size.

Thanks a bunch! I didn't realize this before!

> Asserts are very useful during development or when testing, e.g. the JDK
> tests run with -esa and can periodically help catch issues when testing
> a change.

Indeed. But I am a little bit curious: unlike C/C++, which enables assert?
by default (You could define NDEBUG? to disable it during compilation),
Java disables assert? by default. I wonder why the language designers
made such a decision. Is it for backward compatibility? IMHO, enabling it by
default might potentially increase its usage among developers.

Regards,
Daohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230717/a36d1f0b/attachment.htm>

From quadhier at outlook.com  Mon Jul 17 13:40:53 2023
From: quadhier at outlook.com (Daohan Qu)
Date: Mon, 17 Jul 2023 13:40:53 +0000
Subject: Questions about using `assert` in Java
In-Reply-To: <1029c4a1-148e-4469-12a6-574d62d2c9cf@gmail.com>
References: <BLAPR07MB7508C14D0D90DF38CC6CC758CB37A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <91b41b49-a38c-f72e-2ad1-c52be83021f0@oracle.com>
 <1029c4a1-148e-4469-12a6-574d62d2c9cf@gmail.com>
Message-ID: <BLAPR07MB75082969BF9602D2970894F8CB3BA@BLAPR07MB7508.namprd07.prod.outlook.com>

Hi John,

> I believe this can be partially alleviated by extracting the asserts to a
> method (partially as the call also increases method size). The optimizer
> seems to be smart enough to not call the method if it does nothing
> (when ea is disabled).

Thanks a lot! Good to know that. I'm not sure about this but I'd like to figure out it.

Regards,
Daohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230717/280d897b/attachment.htm>

From quadhier at outlook.com  Mon Jul 17 13:54:13 2023
From: quadhier at outlook.com (Daohan Qu)
Date: Mon, 17 Jul 2023 13:54:13 +0000
Subject: Questions about using `assert` in Java
In-Reply-To: <7B791D00-C23B-4B30-8430-35E7277BC1E4@oracle.com>
References: <BLAPR07MB7508C14D0D90DF38CC6CC758CB37A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <7B791D00-C23B-4B30-8430-35E7277BC1E4@oracle.com>
Message-ID: <BLAPR07MB75084D2586AA81CBA62E0AA5CB3BA@BLAPR07MB7508.namprd07.prod.outlook.com>

Hi Pavel,

> There have been studies looking into correlation between assertion density
> and fault/defect density. Here's one such study: "Assessing the Relationship
> between Software Assertions and Code Quality: An Empirical Investigation".

Thanks and yes! And there are also some more recent studies about this [1, 2].
They all seem to imply that using assert? is beneficial.

> That said, Java assertions are a bit anaemic. I wish they generated helpful
> messages automatically (though I realise that it might have security implications).
> Consider these assertions:
>
>   * assert x >= 0;
>   * assert x && y;
>   * assert a == b;
>   * assert ( f ? foo() : bar() );
>
> I would like the compiler to transform those into these (respectively):
>
>   * assert x >= 0 : x;
>   * assert x && y : x + ", " + y;
>   * assert a == b : a + ", " + b;
>   * assert ( f ? foo() : bar() ) : f;

Interesting, this idea may also apply to assert?? statements of other languages. :P

[1] https://ieeexplore.ieee.org/document/7194623
[2] https://dl.acm.org/doi/10.1145/3084226.3084259

Regards,
Daohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230717/7a084330/attachment-0001.htm>

From alanb at openjdk.org  Mon Jul 17 14:20:23 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Jul 2023 14:20:23 GMT
Subject: RFR: 8308591: JLine as the default Console provider
In-Reply-To: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
References: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
Message-ID: <A1lYvHlwA7uuICs3O0RvRo5wwAx5p_WkL8wImSzNNiE=.c31b6539-9f57-4d4c-b8cb-b8a3d21e0218@github.com>

On Thu, 1 Jun 2023 18:53:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to bring the JLine-based Console implementation as the default, which was the initial intention in [JDK-8295803](https://bugs.openjdk.org/browse/JDK-8295803). A corresponding CSR has also been drafted.

This looks quite good. I think Console::isTerminal works as a method name but we might have to iterate a bit on the javadoc to more clearly define it.

For the CSR I think the behavior change to call out is that System::console will return a Console for cases where it didn't previously (at least not by default) and that will be observed by code that assumes non-null means isatty, cue the new method to provide a standard way to test this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14271#issuecomment-1638243162

From rriggs at openjdk.org  Mon Jul 17 14:37:04 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Jul 2023 14:37:04 GMT
Subject: RFR: 8312164: Refactor Arrays.hashCode for long, boolean,
 and Object arrays
In-Reply-To: <2fzWrAYSsxemNshKqA4md_k78mO1gmUSvylsaDSf_7w=.c9b6c8b8-8204-4bb8-a7a0-2496e5d3cf38@github.com>
References: <2fzWrAYSsxemNshKqA4md_k78mO1gmUSvylsaDSf_7w=.c9b6c8b8-8204-4bb8-a7a0-2496e5d3cf38@github.com>
Message-ID: <g5iBV1XKxGQqEgD3nwdvT8OrqGxzZetGGddWxdwk2MA=.8f9dd01b-21f3-4640-9dd8-c9413d9c8ae9@github.com>

On Mon, 17 Jul 2023 09:36:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to refactor Arrays.hashCode for long[], boolean[], and Object[]. I've been told elsewhere that it shouldn't have significant performance implications.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14900#pullrequestreview-1532954190

From aturbanov at openjdk.org  Mon Jul 17 14:49:19 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 17 Jul 2023 14:49:19 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v6]
In-Reply-To: <JLu2abTrdYaA72UojilLoZe14xxNRQUAAnS_G9pGNpY=.3692be64-289d-4562-b089-e5d9b50df928@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <JLu2abTrdYaA72UojilLoZe14xxNRQUAAnS_G9pGNpY=.3692be64-289d-4562-b089-e5d9b50df928@github.com>
Message-ID: <4-71z8kuGt3rOGevC2jvr1okpbsQmfz1cTwhRLzlJww=.76e52580-c721-4e47-bec3-7bacbe63ae33@github.com>

On Thu, 13 Jul 2023 19:21:01 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 with a new target base 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 JDK-8301341
>  - Simplify contention handling; fix test
>  - Fix inverted test assert; improve internal documentation; simplify code
>  - 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

src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java line 232:

> 230:      * The transferer. (See below about serialization.)
> 231:      */
> 232:     private transient final Transferer<E> transferer;

let's use blessed modifiers order
Suggestion:

    private final transient Transferer<E> transferer;

src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java line 234:

> 232:     private transient final Transferer<E> transferer;
> 233: 
> 234:     private transient final boolean fair;

nit
Suggestion:

    private final transient boolean fair;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1265479543
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1265480051

From jvernee at openjdk.org  Mon Jul 17 14:57:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 17 Jul 2023 14:57:27 GMT
Subject: Integrated: 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: <U1pUnNBqn1A3ecbh9yHZ89ZAKnpM8-YaoCNzatPa4EI=.d7f18999-a410-4395-9ef2-39ecbb1eefe9@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

This pull request has now been integrated.

Changeset: 69a46c25
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/69a46c25cc87d9d5495d0bb975c44f38cbb1fe13
Stats:     32 lines in 3 files changed: 8 ins; 8 del; 16 mod

8310157: Allow void-returning filters for MethodHandles::collectCoordinates

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/14496

From vtewari at openjdk.org  Mon Jul 17 15:06:53 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Mon, 17 Jul 2023 15:06:53 GMT
Subject: RFR: 8312164: Refactor Arrays.hashCode for long, boolean,
 and Object arrays
In-Reply-To: <2fzWrAYSsxemNshKqA4md_k78mO1gmUSvylsaDSf_7w=.c9b6c8b8-8204-4bb8-a7a0-2496e5d3cf38@github.com>
References: <2fzWrAYSsxemNshKqA4md_k78mO1gmUSvylsaDSf_7w=.c9b6c8b8-8204-4bb8-a7a0-2496e5d3cf38@github.com>
Message-ID: <PkElYzLk9W_BvtcMmrqmxwyLvZqQpBdelYygkcPFq50=.6c2fbffa-b1ad-415b-9d27-39141e4ce849@github.com>

On Mon, 17 Jul 2023 09:36:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to refactor Arrays.hashCode for long[], boolean[], and Object[]. I've been told elsewhere that it shouldn't have significant performance implications.

Looks OK to me.

-------------

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14900#pullrequestreview-1533023578

From alanb at openjdk.org  Mon Jul 17 15:10:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Jul 2023 15:10:33 GMT
Subject: RFR: 8312127: FileDescriptor.sync should temporarily increase
 parallelism
Message-ID: <2SDSwteRiWBEhbw3Fk7jZk0DKN-BThtnby9miCjQcas=.a82197eb-22f5-42f6-be3c-f9c1704fcda0@github.com>

If FileDescriptor::sync is invoked by a virtual thread then it doesn't release its carrier to do other work while modifications are written to the file system. For cases like this, parallelism should be temporarily increased for the duration of the operation. This one is somewhat legacy as it's only JDK 1.0/1.1 era APIs that provide access to the FileDescriptor so it wasn't done with the other methods in JDK 19. It's updated here, as it has been noticed.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14893/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14893&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312127
  Stats: 17 lines in 3 files changed: 11 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14893.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14893/head:pull/14893

PR: https://git.openjdk.org/jdk/pull/14893

From shade at openjdk.org  Mon Jul 17 15:29:25 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Jul 2023 15:29:25 GMT
Subject: RFR: 8312127: FileDescriptor.sync should temporarily increase
 parallelism
In-Reply-To: <2SDSwteRiWBEhbw3Fk7jZk0DKN-BThtnby9miCjQcas=.a82197eb-22f5-42f6-be3c-f9c1704fcda0@github.com>
References: <2SDSwteRiWBEhbw3Fk7jZk0DKN-BThtnby9miCjQcas=.a82197eb-22f5-42f6-be3c-f9c1704fcda0@github.com>
Message-ID: <ExAnHbtcd5TxXcIKrjuz38aiUPZ7UsTYnb1uPqVrdio=.1154ad1f-2fa0-4440-a38d-49bd2fe47574@github.com>

On Sat, 15 Jul 2023 13:54:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If FileDescriptor::sync is invoked by a virtual thread then it doesn't release its carrier to do other work while modifications are written to the file system. For cases like this, parallelism should be temporarily increased for the duration of the operation. This one is somewhat legacy as it's only JDK 1.0/1.1 era APIs that provide access to the FileDescriptor so it wasn't done with the other methods in JDK 19. It's updated here, as it has been noticed.

Looks okay. We are going to need this in some of our databases.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14893#pullrequestreview-1533074983

From bpb at openjdk.org  Mon Jul 17 16:30:09 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 17 Jul 2023 16:30:09 GMT
Subject: RFR: 8312127: FileDescriptor.sync should temporarily increase
 parallelism
In-Reply-To: <2SDSwteRiWBEhbw3Fk7jZk0DKN-BThtnby9miCjQcas=.a82197eb-22f5-42f6-be3c-f9c1704fcda0@github.com>
References: <2SDSwteRiWBEhbw3Fk7jZk0DKN-BThtnby9miCjQcas=.a82197eb-22f5-42f6-be3c-f9c1704fcda0@github.com>
Message-ID: <nFuRomNyddFtGJK9VfkQY4zgGywwLpKb8eFo2_Pqbm8=.17343dcc-a339-43a0-9646-66a022e8a5e1@github.com>

On Sat, 15 Jul 2023 13:54:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If FileDescriptor::sync is invoked by a virtual thread then it doesn't release its carrier to do other work while modifications are written to the file system. For cases like this, parallelism should be temporarily increased for the duration of the operation. This one is somewhat legacy as it's only JDK 1.0/1.1 era APIs that provide access to the FileDescriptor so it wasn't done with the other methods in JDK 19. It's updated here, as it has been noticed.

+1

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14893#pullrequestreview-1533184506

From mchung at openjdk.org  Mon Jul 17 16:39:29 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 17 Jul 2023 16:39:29 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v25]
In-Reply-To: <dTxPQBneimja4eNhQuamUgJNakNMzgATciUte76SK5c=.95622355-daa2-41a9-bfdf-a1527eb077a3@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <dTxPQBneimja4eNhQuamUgJNakNMzgATciUte76SK5c=.95622355-daa2-41a9-bfdf-a1527eb077a3@github.com>
Message-ID: <zDTamV8eCZoR5KEF4gkQx3eZY4ZWuEfxdLUeyuSDgG4=.e7620887-2653-4c14-abac-414e87258ccb@github.com>

On Tue, 11 Jul 2023 19:22:58 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 incrementally with one additional commit since the last revision:
> 
>   Review changees

Looks good.   As the hidden interface check is added, the spec needs update to say "The interface must be public and not sealed and not hidden." as the CSR says.  (sorry I might have confused you).

The CSR will need update as well as it no longer uses class data.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13197#pullrequestreview-1533207972

From iklam at openjdk.org  Mon Jul 17 17:20:59 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 17 Jul 2023 17:20:59 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
In-Reply-To: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
Message-ID: <cbhFq3ORQfMDCabfcDgjnqRUyBiRG3dlDbxUZiFFNjA=.50d4ccce-327b-48c4-866b-67dd144fa030@github.com>

On Thu, 13 Jul 2023 21:25:17 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 
> 
> 
>  // We have finished dumping the static archive. At this point, there may be pending VM
>  // operations. We have changed some global states (such as vmClasses::_klasses) that
>  // may cause these VM operations to fail. For safety, forget these operations and
>  // exit the VM directly.
>  void MetaspaceShared::exit_after_static_dump() {
>    os::_exit(0);
>  } 
> 
> 
> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.

Changes requested by iklam (Reviewer).

src/hotspot/share/cds/archiveBuilder.cpp line 262:

> 260:     // dynamic archive, we might need to sort the symbols alphabetically (also see
> 261:     // DynamicArchiveBuilder::sort_methods()).
> 262:     log_info(cds)("Sorting symbols and fixing identity hash ... ");

"and fixing identity hash" should be removed, as the has is no longer being fixed here.

src/hotspot/share/cds/archiveBuilder.cpp line 638:

> 636:   memcpy(dest, src, bytes);
> 637: 
> 638:   // Update the hash of buffered sorted symbols for static dump

Please append to the comments with ` so that the symbols have deterministic contents`

src/hotspot/share/cds/heapShared.cpp line 345:

> 343: void HeapShared::init_scratch_references() {
> 344:   if (_scratch_references_table == nullptr)
> 345:     _scratch_references_table = new (mtClass)ResolvedReferenceScratchTable();

These two lines are outside of a lock so you could run into a race condition. I think you can remove this function and move these two lines to just before calling `_scratch_references_table->put()` in `add_scratch_resolved_references`.

src/hotspot/share/cds/heapShared.hpp line 288:

> 286:     36137, // prime number
> 287:     AnyObj::C_HEAP,
> 288:     mtClassShared> ResolvedReferenceScratchTable;

You are using `oop->identity_hash()` as the key for this table. However, it's possible for two `resolved_references` arrays to have the exact same identity. It's better to to use `ResourceHashtable<OopHandle, OopHandle, ...` for this table. Then, you need to define two custom functions for these two parameters for `ResourceHashtable`


    unsigned (*HASH)  (K const&),
    bool     (*EQUALS)(K const&, K const&)

where the `K` type is `OopHandle`.

The `HASH` function can return `OopHandle::resolve()->identity_hash()` and the `EQUALS` function can compare the values of `OopHandle::resolve()`.

For the coding style, you can search for tables that use `HeapShared::oop_hash` for examples.

src/hotspot/share/classfile/classLoaderData.cpp line 1085:

> 1083:     guarantee(this == class_loader_data(cl) || has_class_mirror_holder(), "Must be the same");
> 1084:     guarantee(cl != nullptr || this == ClassLoaderData::the_null_class_loader_data() || has_class_mirror_holder(), "must be");
> 1085:   }

Why is this necessary?

src/java.base/share/native/libjli/java.c line 1447:

> 1445: /*
> 1446:  * Check for CDS option
> 1447:  */

Comments need to be indented.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14879#pullrequestreview-1533239235
PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1265645038
PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1265669208
PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1265653371
PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1265667818
PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1265648116
PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1265671279

From naoto at openjdk.org  Mon Jul 17 17:32:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Jul 2023 17:32:15 GMT
Subject: RFR: 8308591: JLine as the default Console provider
In-Reply-To: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
References: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
Message-ID: <0G2kLiQS38oxDf4Kshx3Uylf1x-HfvePVrUVAsT697U=.4879f7d0-a0c7-427c-abb8-8581bcd93838@github.com>

On Thu, 1 Jun 2023 18:53:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to bring the JLine-based Console implementation as the default, which was the initial intention in [JDK-8295803](https://bugs.openjdk.org/browse/JDK-8295803). A corresponding CSR has also been drafted.

Thanks, Alan.

> This looks quite good. I think Console::isTerminal works as a method name but we might have to iterate a bit on the javadoc to more clearly define it.
> 

Do you think adding an `implNote` that describes the platform behavior, e.g., on Unix it is equivalent to calling `isatty(stdin/out)` and stdin/out file descriptor are valid character devices on Windows, would help?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14271#issuecomment-1638574326

From jvernee at openjdk.org  Mon Jul 17 17:32:28 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 17 Jul 2023 17:32:28 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v25]
In-Reply-To: <dTxPQBneimja4eNhQuamUgJNakNMzgATciUte76SK5c=.95622355-daa2-41a9-bfdf-a1527eb077a3@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <dTxPQBneimja4eNhQuamUgJNakNMzgATciUte76SK5c=.95622355-daa2-41a9-bfdf-a1527eb077a3@github.com>
Message-ID: <ejyt9uHFnuVeU9P0Rn4bXGVKGtRf4DAuu-AeKuPFvKQ=.7b5a6300-0714-4437-a330-8783478afb57@github.com>

On Tue, 11 Jul 2023 19:22:58 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 incrementally with one additional commit since the last revision:
> 
>   Review changees

test/jdk/java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java line 165:

> 163:                 () -> "incorrect dynamic module name: " + implModule.getName());
> 164: 
> 165:         assertSame(implClass.getClassLoader(), implModule.getClassLoader(),

I think this should check against `ifaceModule.getClassLoader()` instead, right? Since the dynamic module is defined in the interface' class loader.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1265676425

From mchung at openjdk.org  Mon Jul 17 17:32:30 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 17 Jul 2023 17:32:30 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v25]
In-Reply-To: <ejyt9uHFnuVeU9P0Rn4bXGVKGtRf4DAuu-AeKuPFvKQ=.7b5a6300-0714-4437-a330-8783478afb57@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <dTxPQBneimja4eNhQuamUgJNakNMzgATciUte76SK5c=.95622355-daa2-41a9-bfdf-a1527eb077a3@github.com>
 <ejyt9uHFnuVeU9P0Rn4bXGVKGtRf4DAuu-AeKuPFvKQ=.7b5a6300-0714-4437-a330-8783478afb57@github.com>
Message-ID: <HcGX3-ArAn2uPCP-qAVRNHIpAkazR270T7OEvvE3Ul4=.eef1cf28-bb1d-4678-a6d1-2577240320fe@github.com>

On Mon, 17 Jul 2023 17:21:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review changees
>
> test/jdk/java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java line 165:
> 
>> 163:                 () -> "incorrect dynamic module name: " + implModule.getName());
>> 164: 
>> 165:         assertSame(implClass.getClassLoader(), implModule.getClassLoader(),
> 
> I think this should check against `ifaceModule.getClassLoader()` instead, right? Since the dynamic module is defined in the interface' class loader.

Good catch!   Yes, this should check against the interface's loader.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1265684091

From ascarpino at openjdk.org  Mon Jul 17 17:42:24 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 17 Jul 2023 17:42:24 GMT
Subject: Integrated: 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: <WNkVkSfB5CG6v-rNNgZzs7MMsn9UPOipnxneaU9sK1E=.4cdc7fea-1957-4b4c-ae73-e77c9bcabc9f@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

This pull request has now been integrated.

Changeset: e7379687
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e73796879299c6170b63edb998439db4764ceae0
Stats:     187 lines in 58 files changed: 73 ins; 41 del; 73 mod

8308398: Move SunEC crypto provider into java.base

Reviewed-by: valeriep, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14457

From duke at openjdk.org  Mon Jul 17 18:47:42 2023
From: duke at openjdk.org (Chris Hennick)
Date: Mon, 17 Jul 2023 18:47:42 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v22]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <ExbBsdLCyihjBrsaMxK2qN6G0TzQFv5Dnm7Nsc3A8hI=.db49f7ea-ad26-4481-a58e-5e85fbca864c@github.com>

> 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 21 commits:

 - Merge branch 'openjdk:master' into patch-1
 - 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
 - ... and 11 more: https://git.openjdk.org/jdk/compare/e7379687...d5ade1c7

-------------

Changes: https://git.openjdk.org/jdk/pull/8131/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=21
  Stats: 144 lines in 4 files changed: 128 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From duke at openjdk.org  Mon Jul 17 18:47:44 2023
From: duke at openjdk.org (Chris Hennick)
Date: Mon, 17 Jul 2023 18:47:44 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v21]
In-Reply-To: <utNNjvkriO7T7BwNzB6Jnn02x9pVBQtVzKAtVI0TNd0=.e6ccfe10-adfd-4b5a-ba46-0f2e860a76e5@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <kvMZkYhviynRDKc99xX5jxgFWyX6fH9cXtTnoMhTu1E=.9979a2d4-ec47-4731-a971-41a3ae79e8fe@github.com>
 <9kk58tLH_H9Hv9_GEdIxcpJzdpSMYbOgePMWETQXqOs=.bd193127-30cc-47fe-8f6d-ddeb785bbec4@github.com>
 <utNNjvkriO7T7BwNzB6Jnn02x9pVBQtVzKAtVI0TNd0=.e6ccfe10-adfd-4b5a-ba46-0f2e860a76e5@github.com>
Message-ID: <yTL8KfIIQmEBRZyk1k2CEfzfEd1MIa3dBG7O1s2UIo0=.d1972894-dd9a-4ffb-91f0-527de93dc218@github.com>

On Fri, 14 Jul 2023 20:42:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> @JimLaskey @jddarcy @turbanoff @rgiulietti Could this please be merged?
>
> @Pr0methean , please update your branch with the current contents of the master before issuing the integrate command. Assuming that succeeds as expected, myself or someone else can sponsor your changeset as described in the comment from the Skara bots.

@jddarcy Done.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/8131#issuecomment-1638679971

From duke at openjdk.org  Mon Jul 17 19:20:31 2023
From: duke at openjdk.org (duke)
Date: Mon, 17 Jul 2023 19:20:31 GMT
Subject: Withdrawn: 8301552: Use AtomicReferenceArray for caching instead of
 CHM in ZoneOffset
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <SxhVLs7WB2KbfVe8UjyMwj7M8xdCxfvW0s6Y67smWTI=.db85f97b-ee92-4602-8fc1-ce00a8d94ee2@github.com>

On Tue, 31 Jan 2023 15:57:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
> 
> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From duke at openjdk.org  Mon Jul 17 19:22:22 2023
From: duke at openjdk.org (Chris Hennick)
Date: Mon, 17 Jul 2023 19:22:22 GMT
Subject: Integrated: 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: <UYd6ieCHSwAT2C10kCRezoZbiBXE74eI-_iWhTPZE6c=.8998e8b1-5afe-48c1-b03a-bd7dc2ba9bc6@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.

This pull request has now been integrated.

Changeset: f975be44
Author:    Chris Hennick <4961925+Pr0methean at users.noreply.github.com>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f975be44a86879e1079a0066203b49d59b7a1167
Stats:     144 lines in 4 files changed: 128 ins; 0 del; 16 mod

8284493: Improve computeNextExponential tail performance and accuracy

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/8131

From naoto at openjdk.org  Mon Jul 17 19:49:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Jul 2023 19:49:04 GMT
Subject: RFR: 8308591: JLine as the default Console provider [v2]
In-Reply-To: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
References: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
Message-ID: <bssyqwK9bcS_NGwR7yARx0O4ZC297VxHRiMfDkfwufg=.b68f2de1-3223-44d1-a8b1-2bc9f799f3b1@github.com>

> This is to bring the JLine-based Console implementation as the default, which was the initial intention in [JDK-8295803](https://bugs.openjdk.org/browse/JDK-8295803). A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Refine the method description
 - Merge branch 'master' into JDK-8308591-JLine-Console
 - javadoc cleanup
 - Merge branch 'master' into JDK-8308591-JLine-Console
 - Merge branch 'master' into JDK-8308591-JLine-Console
 - static to instance method
 - isPlatformConsole()
 - Restored stream
 - lazy init
 - Avoid using stream
 - ... and 2 more: https://git.openjdk.org/jdk/compare/0b242322...f6f22d60

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14271/files
  - new: https://git.openjdk.org/jdk/pull/14271/files/057611dc..f6f22d60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14271&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14271&range=00-01

  Stats: 16701 lines in 558 files changed: 9529 ins; 6446 del; 726 mod
  Patch: https://git.openjdk.org/jdk/pull/14271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14271/head:pull/14271

PR: https://git.openjdk.org/jdk/pull/14271

From rriggs at openjdk.org  Mon Jul 17 19:49:41 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Jul 2023 19:49:41 GMT
Subject: Integrated: JDK-8312195: Changes in JDK-8284493 use wrong
 copyright syntax
In-Reply-To: <fEZKO8RFQn5121YirI4VJbhMGUuSl3YEdq_8m56oBdo=.ae0e1e22-f171-411f-8642-600b85953ac5@github.com>
References: <fEZKO8RFQn5121YirI4VJbhMGUuSl3YEdq_8m56oBdo=.ae0e1e22-f171-411f-8642-600b85953ac5@github.com>
Message-ID: <WqgiSzbKNkkKcG-DHW2IBA8W2UjeXQ13a0bqgmxdcW0=.606efc6d-fe3e-426c-86ee-5f5730dc3609@github.com>

On Mon, 17 Jul 2023 19:40:42 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update to conform to accepted syntax.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14908#pullrequestreview-1533548769

From darcy at openjdk.org  Mon Jul 17 19:49:40 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 17 Jul 2023 19:49:40 GMT
Subject: Integrated: JDK-8312195: Changes in JDK-8284493 use wrong copyright
 syntax
Message-ID: <fEZKO8RFQn5121YirI4VJbhMGUuSl3YEdq_8m56oBdo=.ae0e1e22-f171-411f-8642-600b85953ac5@github.com>

Update to conform to accepted syntax.

-------------

Commit messages:
 - JDK-8312195: Changes in JDK-8284493 use wrong copyright synta

Changes: https://git.openjdk.org/jdk/pull/14908/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14908&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312195
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14908.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14908/head:pull/14908

PR: https://git.openjdk.org/jdk/pull/14908

From darcy at openjdk.org  Mon Jul 17 19:49:44 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 17 Jul 2023 19:49:44 GMT
Subject: Integrated: JDK-8312195: Changes in JDK-8284493 use wrong copyright
 syntax
In-Reply-To: <fEZKO8RFQn5121YirI4VJbhMGUuSl3YEdq_8m56oBdo=.ae0e1e22-f171-411f-8642-600b85953ac5@github.com>
References: <fEZKO8RFQn5121YirI4VJbhMGUuSl3YEdq_8m56oBdo=.ae0e1e22-f171-411f-8642-600b85953ac5@github.com>
Message-ID: <lHHshfAVNAhrFxbSGSeLt09-r0PWtI7PkoN5hQRQ2aY=.6cc8217f-c5c9-4ce6-97b4-2333a5244cba@github.com>

On Mon, 17 Jul 2023 19:40:42 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update to conform to accepted syntax.

This pull request has now been integrated.

Changeset: 295ae119
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/295ae1190dfb6ac3d00d3cf2d8c8c131f5c319b5
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8312195: Changes in JDK-8284493 use wrong copyright syntax

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/14908

From naoto at openjdk.org  Mon Jul 17 19:55:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Jul 2023 19:55:34 GMT
Subject: RFR: 8308591: JLine as the default Console provider [v3]
In-Reply-To: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
References: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
Message-ID: <3p8zJJNsU2YORzBfIpcC88ChpuA3ZvSS-OE4fEqh9YI=.eb0255e0-ddcb-4ba5-a783-b333a5f81fc4@github.com>

> This is to bring the JLine-based Console implementation as the default, which was the initial intention in [JDK-8295803](https://bugs.openjdk.org/browse/JDK-8295803). A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  minor doc fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14271/files
  - new: https://git.openjdk.org/jdk/pull/14271/files/f6f22d60..b2a664ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14271&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14271&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14271/head:pull/14271

PR: https://git.openjdk.org/jdk/pull/14271

From naoto at openjdk.org  Mon Jul 17 19:58:00 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Jul 2023 19:58:00 GMT
Subject: RFR: 8308591: JLine as the default Console provider [v4]
In-Reply-To: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
References: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
Message-ID: <yWsfMA40jepE3oiQFkxPdcjceQLwpo_PoyPZdEtBkJg=.03468746-c2e1-483c-a928-246b298fc86b@github.com>

> This is to bring the JLine-based Console implementation as the default, which was the initial intention in [JDK-8295803](https://bugs.openjdk.org/browse/JDK-8295803). A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Unix -> POSIX

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14271/files
  - new: https://git.openjdk.org/jdk/pull/14271/files/b2a664ff..a6512a37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14271&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14271&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14271/head:pull/14271

PR: https://git.openjdk.org/jdk/pull/14271

From duke at openjdk.org  Mon Jul 17 20:00:28 2023
From: duke at openjdk.org (airsquared)
Date: Mon, 17 Jul 2023 20:00:28 GMT
Subject: RFR: JDK-8309032: jpackage does not work for module projects unless
 --module-path is specified
Message-ID: <ZHCWcpSLF1khyvrydxW8JarYKgYOj3B-9nnBVElWVpc=.4a345b50-7213-4e30-969e-280e3cd11575@github.com>

[JDK-8309032](https://bugs.openjdk.org/browse/JDK-8309032), [JDK-8306488](https://bugs.openjdk.org/browse/JDK-8306488)

-------------

Commit messages:
 - Minor code cleanup in LauncherData.java
 - Fix ClassCastException in getPathListParameter: ImmutableCollections$List12 cannot be cast to class String

Changes: https://git.openjdk.org/jdk/pull/14840/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14840&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309032
  Stats: 16 lines in 1 file changed: 0 ins; 8 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14840.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14840/head:pull/14840

PR: https://git.openjdk.org/jdk/pull/14840

From naoto at openjdk.org  Mon Jul 17 20:46:32 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Jul 2023 20:46:32 GMT
Subject: RFR: 8308591: JLine as the default Console provider [v5]
In-Reply-To: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
References: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
Message-ID: <UaaPqwRl0njNVVWBohl1gngkiA1q0L5P4Oum8fyi9rI=.a0c698bc-ef05-4f81-bd9c-d2cd7a3bc19c@github.com>

> This is to bring the JLine-based Console implementation as the default, which was the initial intention in [JDK-8295803](https://bugs.openjdk.org/browse/JDK-8295803). A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  `true`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14271/files
  - new: https://git.openjdk.org/jdk/pull/14271/files/a6512a37..df5805a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14271&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14271&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14271/head:pull/14271

PR: https://git.openjdk.org/jdk/pull/14271

From rriggs at openjdk.org  Mon Jul 17 21:02:17 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Jul 2023 21:02:17 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v12]
In-Reply-To: <PNhV9fuNjZQCC0FbZvfucuaf3D3b0FYap0z_J8mSyTA=.6b3d7540-f908-4e33-ac37-cdad1899fd80@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <PNhV9fuNjZQCC0FbZvfucuaf3D3b0FYap0z_J8mSyTA=.6b3d7540-f908-4e33-ac37-cdad1899fd80@github.com>
Message-ID: <6Z9eOwWQA7NeLDOsYW0Oh373ArzaZIGk0JaWFGWfOj4=.40bb7830-6405-4d3e-9a4e-e17b3b066871@github.com>

On Mon, 3 Jul 2023 03:49:01 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.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 (+...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Integer/Long toString test against compact strings
>   
>   Co-authored-by: liach <liach at users.noreply.github.com>

src/java.base/share/classes/java/lang/Integer.java line 528:

> 526:             i = q;
> 527:             charPos -= 2;
> 528:             UNSAFE.putShortUnaligned(buf, Unsafe.ARRAY_BYTE_BASE_OFFSET + charPos, PACKED_DIGITS[r], false);

When switching to use Unsafe, `getChars` should do the array bounds check in the loop of the store index.

src/java.base/share/classes/java/lang/Long.java line 559:

> 557:                     Unsafe.ARRAY_BYTE_BASE_OFFSET + charPos,
> 558:                     Integer.PACKED_DIGITS[(int)((q * 100) - i)],
> 559:                     false);

Add the array bound check for the store of the characters.

src/java.base/share/classes/java/lang/Long.java line 584:

> 582:                     Unsafe.ARRAY_BYTE_BASE_OFFSET + charPos,
> 583:                     Integer.PACKED_DIGITS[-i2],
> 584:                     false);

Replace the implicit array bounds check with an explicit array index check if using Unsafe.

src/java.base/share/classes/java/lang/StringUTF16.java line 1595:

> 1593:                     PACKED_DIGITS_UTF16[-i]);
> 1594:         } else {
> 1595:             putChar(buf, --charPos, '0' - i);

Ditto add explicit array bounds check when using Unsafe, especially since the method is used outside of the source file.  Here and in the uses of Unsafe below.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1265892597
PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1265893469
PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1265894471
PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1265895630

From jlu at openjdk.org  Mon Jul 17 21:04:18 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 17 Jul 2023 21:04:18 GMT
Subject: Integrated: 8311968: Clarify Three-letter time zone IDs in
 java.util.TimeZone
In-Reply-To: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
References: <kAav0bkGE-Fw2OFIWlFQtqmL-ucodm7MoOP9jkrpa0Q=.068ec354-69f7-45c2-abbf-088256157746@github.com>
Message-ID: <8lcdSBvOUt1LmsdGu93QKGfnLvUgps0wOzQ6BNpA4XU=.26000229-5003-4e6e-8cef-7d2e25d391be@github.com>

On Thu, 13 Jul 2023 06:34:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8311979) which links the full list of deprecated three-letter IDs in java.util.TimeZone
> 
> Although it is made apparent in TimeZone that certain 3-letter IDs are deprecated, it does not actually list them in the specification. In addition to linking the full list, it is clarified that not _all_ 3-letter IDs are deprecated, as there are quite a few that come from the tzdb.
> 
> This change links to the full list found in ZoneId.

This pull request has now been integrated.

Changeset: 6a09992d
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6a09992dbd957daac2d5197a9ef8ab4975ddeaa4
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8311968: Clarify Three-letter time zone IDs in java.util.TimeZone

Reviewed-by: naoto, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/14861

From jlu at openjdk.org  Mon Jul 17 21:11:36 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 17 Jul 2023 21:11:36 GMT
Subject: RFR: 8039165: [Doc] MessageFormat null locale generates
 NullPointerException
Message-ID: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>

Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8312197) which updates the javadoc for the constructor of MessageFormat regarding a `null` locale,

`MessageFormat` when created with a `null` locale may throw a `NullPointerException` either during the object creation, or later when `format()` is called by the `MessageFormat` object (test file has examples of both). This change updates the specification of MessageFormat to make this apparent. The wording is specifically chosen as 'may throw' since whether an NPE is thrown depends on the subformat used by MessageFormat (see test example of construction with null locale and no exception thrown).

The test for this change was merged with `Bug6481179.java` into `MessageFormatExceptions.java` (As they both test exceptions). In addition, some other exception testing regarding MessageFormat was added.

Thanks

-------------

Commit messages:
 - Clarify called vs invoked terminology
 - Add case of DoesNotThrow()
 - Spec and test change

Changes: https://git.openjdk.org/jdk/pull/14911/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14911&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8039165
  Stats: 149 lines in 3 files changed: 85 ins; 64 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14911/head:pull/14911

PR: https://git.openjdk.org/jdk/pull/14911

From jlu at openjdk.org  Mon Jul 17 21:31:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 17 Jul 2023 21:31:33 GMT
Subject: RFR: 8311663: Additional refactoring of Locale tests to JUnit [v2]
In-Reply-To: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
References: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
Message-ID: <SRrVjo_uiSSXblDnGLU0ER2qnjuPWrQEkqgYk9hBKa8=.e49a84d4-3a1d-481b-b0da-9982ec42b815@github.com>

> Please review this PR which refactors more java.util.Locale tests to JUnit with some minor cleanup as well.
> 
> Although some of the files could benefit from being renamed bugNNNNNNN to something more descriptive, this makes reviewing harder, and will be handled separately.

Justin Lu has updated the pull request incrementally with six additional commits since the last revision:

 - Review: Explicitly run via othervm and pass locale args in cmdline
 - Review: ws removal in Bug8179071.java
 - Review: remove redudant 'throws'
 - Review: Use assertTrue() in Bug8179071.java
 - Review: Revert "Same as prev commit"
   
   This reverts commit 933c0312ed2fa0f40a750e950c166b7e820df7ab.
 - Review: Revert "Remove try catch in Bug8135061.java"
   
   This reverts commit f213c74e37ed257a05a535b2c077af327343acb5.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14881/files
  - new: https://git.openjdk.org/jdk/pull/14881/files/933c0312..2b07e9f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14881&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14881&range=00-01

  Stats: 31 lines in 4 files changed: 9 ins; 7 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/14881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14881/head:pull/14881

PR: https://git.openjdk.org/jdk/pull/14881

From jlu at openjdk.org  Mon Jul 17 21:31:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 17 Jul 2023 21:31:33 GMT
Subject: RFR: 8311663: Additional refactoring of Locale tests to JUnit [v2]
In-Reply-To: <CAaDFQ9BUpLzoRfEur0oaJEw3TDsTfRoT1Sxwlu2sy4=.8925a14b-aa58-45b8-be85-d6ec4dea4f1e@github.com>
References: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
 <CAaDFQ9BUpLzoRfEur0oaJEw3TDsTfRoT1Sxwlu2sy4=.8925a14b-aa58-45b8-be85-d6ec4dea4f1e@github.com>
Message-ID: <Dwcq_IfS7VTKaJ9lys2v3CtITaRPeGEupWw1OpR0CrU=.06351d0f-9e96-4cc6-b441-2fc66dfe92be@github.com>

On Fri, 14 Jul 2023 21:59:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Review: Explicitly run via othervm and pass locale args in cmdline
>>  - Review: ws removal in Bug8179071.java
>>  - Review: remove redudant 'throws'
>>  - Review: Use assertTrue() in Bug8179071.java
>>  - Review: Revert "Same as prev commit"
>>    
>>    This reverts commit 933c0312ed2fa0f40a750e950c166b7e820df7ab.
>>  - Review: Revert "Remove try catch in Bug8135061.java"
>>    
>>    This reverts commit f213c74e37ed257a05a535b2c077af327343acb5.
>
> test/jdk/java/util/Locale/Bug8135061.java line 56:
> 
>> 54:         assertNull(match, "[Locale.lookup failed on language"
>> 55:                 + " range: " + ranges + " and language tags "
>> 56:                 + locales + "]");
> 
> Removing try-catch will lose the information on what kind of exception was thrown

I did a second take before pushing and mistakenly removed those blocks, I knew I had left them in there originally for a reason. Fixed.

> test/jdk/java/util/Locale/ThaiGov.java line 51:
> 
>> 49:     // Test number formatting for thai
>> 50:     @Test
>> 51:     public void numberTest() throws RuntimeException {
> 
> Not your change, but this `throws` is redundant

Thanks for the review, addressed this and your other suggestions as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1265919717
PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1265919129

From jlu at openjdk.org  Mon Jul 17 21:31:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 17 Jul 2023 21:31:33 GMT
Subject: RFR: 8311663: Additional refactoring of Locale tests to JUnit [v2]
In-Reply-To: <D9hUKbREEU6tQR_i57jBoAmDknti1gXsd8xytsYByKI=.19f87551-1c63-4608-a10f-c9f29e9458c1@github.com>
References: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
 <D9hUKbREEU6tQR_i57jBoAmDknti1gXsd8xytsYByKI=.19f87551-1c63-4608-a10f-c9f29e9458c1@github.com>
Message-ID: <c6LBeQeKOpCT01bYXLioKNr4iZxttOw1JQaLTc44O7c=.9884812b-d785-44fd-89c5-530cd66c28a4@github.com>

On Mon, 17 Jul 2023 10:58:12 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Review: Explicitly run via othervm and pass locale args in cmdline
>>  - Review: ws removal in Bug8179071.java
>>  - Review: remove redudant 'throws'
>>  - Review: Use assertTrue() in Bug8179071.java
>>  - Review: Revert "Same as prev commit"
>>    
>>    This reverts commit 933c0312ed2fa0f40a750e950c166b7e820df7ab.
>>  - Review: Revert "Remove try catch in Bug8135061.java"
>>    
>>    This reverts commit f213c74e37ed257a05a535b2c077af327343acb5.
>
> test/jdk/java/util/Locale/Bug8179071.java line 95:
> 
>> 93:                 .forEach(tag -> {if(LegacyAliases.contains(tag)) {invalidTags.add(tag);}});
>> 94:         assertEquals(true, invalidTags.isEmpty(),
>> 95:                 "Deprecated and Legacy tags found  " + invalidTags  + " in AvailableLocales ");
> 
> Suggestion:
> 
>                 "Deprecated and Legacy tags found  " + invalidTags + " in AvailableLocales ");

Thanks, updated this and the other suggested WS change

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1265919052

From naoto at openjdk.org  Mon Jul 17 21:43:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Jul 2023 21:43:52 GMT
Subject: RFR: 8311663: Additional refactoring of Locale tests to JUnit [v2]
In-Reply-To: <SRrVjo_uiSSXblDnGLU0ER2qnjuPWrQEkqgYk9hBKa8=.e49a84d4-3a1d-481b-b0da-9982ec42b815@github.com>
References: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
 <SRrVjo_uiSSXblDnGLU0ER2qnjuPWrQEkqgYk9hBKa8=.e49a84d4-3a1d-481b-b0da-9982ec42b815@github.com>
Message-ID: <bSHXzRXvzNzETeoC4VQvrC38qnmw2_rjLzFX8mGzWyM=.5b231d7c-b3be-459f-bf93-1dc569a3d658@github.com>

On Mon, 17 Jul 2023 21:31:33 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which refactors more java.util.Locale tests to JUnit with some minor cleanup as well.
>> 
>> Although some of the files could benefit from being renamed bugNNNNNNN to something more descriptive, this makes reviewing harder, and will be handled separately.
>
> Justin Lu has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Review: Explicitly run via othervm and pass locale args in cmdline
>  - Review: ws removal in Bug8179071.java
>  - Review: remove redudant 'throws'
>  - Review: Use assertTrue() in Bug8179071.java
>  - Review: Revert "Same as prev commit"
>    
>    This reverts commit 933c0312ed2fa0f40a750e950c166b7e820df7ab.
>  - Review: Revert "Remove try catch in Bug8135061.java"
>    
>    This reverts commit f213c74e37ed257a05a535b2c077af327343acb5.

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14881#pullrequestreview-1533749099

From dholmes at openjdk.org  Mon Jul 17 21:52:53 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Jul 2023 21:52:53 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
In-Reply-To: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
Message-ID: <mPb1_pZASkoC9hnfUcOiAaQRW-UPtRrHHkN3joQyPKo=.e062ba81-4485-44ac-950f-6bb12395547f@github.com>

On Thu, 13 Jul 2023 21:25:17 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 
> 
> 
>  // We have finished dumping the static archive. At this point, there may be pending VM
>  // operations. We have changed some global states (such as vmClasses::_klasses) that
>  // may cause these VM operations to fail. For safety, forget these operations and
>  // exit the VM directly.
>  void MetaspaceShared::exit_after_static_dump() {
>    os::_exit(0);
>  } 
> 
> 
> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.

Hi Matias,

I'm not keen on having to teach the launcher about `-Xshare:dump` and that it is a terminal operation. But after looking into it I have to admit it is a cleaner and more consistent termination strategy. That said you need to be aware that this will now do a clean shutdown of the VM after the dump, so shutdown hooks will now run.

Lets see what core-libs folk think too.

Thanks.

src/hotspot/share/runtime/threads.cpp line 812:

> 810:   if (DumpSharedSpaces) {
> 811:     MetaspaceShared::preload_and_dump();
> 812:     *canTryAgain = false; // don't let caller call JNI_CreateJavaVM again

This is only set when create_vm fails. A successful creation of the VM prevents subsequent re-creation attempts.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14879#pullrequestreview-1531828953
PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1264773183

From iklam at openjdk.org  Mon Jul 17 21:59:13 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 17 Jul 2023 21:59:13 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
In-Reply-To: <cbhFq3ORQfMDCabfcDgjnqRUyBiRG3dlDbxUZiFFNjA=.50d4ccce-327b-48c4-866b-67dd144fa030@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
 <cbhFq3ORQfMDCabfcDgjnqRUyBiRG3dlDbxUZiFFNjA=.50d4ccce-327b-48c4-866b-67dd144fa030@github.com>
Message-ID: <7hvK_YLrrijcBRv-7Bx1MPGr_MofMhUv-AmnHlQUzp4=.40d9fc01-7239-4a3d-a779-f900a08ad4b0@github.com>

On Mon, 17 Jul 2023 17:14:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 
>> 
>> 
>>  // We have finished dumping the static archive. At this point, there may be pending VM
>>  // operations. We have changed some global states (such as vmClasses::_klasses) that
>>  // may cause these VM operations to fail. For safety, forget these operations and
>>  // exit the VM directly.
>>  void MetaspaceShared::exit_after_static_dump() {
>>    os::_exit(0);
>>  } 
>> 
>> 
>> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
>> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
>> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
>> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.
>
> src/hotspot/share/cds/heapShared.hpp line 288:
> 
>> 286:     36137, // prime number
>> 287:     AnyObj::C_HEAP,
>> 288:     mtClassShared> ResolvedReferenceScratchTable;
> 
> You are using `oop->identity_hash()` as the key for this table. However, it's possible for two `resolved_references` arrays to have the exact same identity. It's better to to use `ResourceHashtable<OopHandle, OopHandle, ...` for this table. Then, you need to define two custom functions for these two parameters for `ResourceHashtable`
> 
> 
>     unsigned (*HASH)  (K const&),
>     bool     (*EQUALS)(K const&, K const&)
> 
> where the `K` type is `OopHandle`.
> 
> The `HASH` function can return `OopHandle::resolve()->identity_hash()` and the `EQUALS` function can compare the values of `OopHandle::resolve()`.
> 
> For the coding style, you can search for tables that use `HeapShared::oop_hash` for examples.

Actually, using `Oophandle` is too complicated. You can just use the `ConstantPool*` as the key, since each original `resolved_references` array is associated with a unique  `ConstantPool*`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1265941938

From naoto at openjdk.org  Mon Jul 17 22:01:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Jul 2023 22:01:11 GMT
Subject: RFR: 8039165: [Doc] MessageFormat null locale generates
 NullPointerException
In-Reply-To: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
Message-ID: <19axlwyNhm52NXGVYT3UUHxQbz_GNai_DZtlOdomX9w=.2ec99ccd-7bd0-4591-80a4-85bd3632a32c@github.com>

On Mon, 17 Jul 2023 21:04:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8312197) which updates the javadoc for the constructor of MessageFormat regarding a `null` locale,
> 
> `MessageFormat` when created with a `null` locale may throw a `NullPointerException` either during the object creation, or later when `format()` is called by the `MessageFormat` object (test file has examples of both). This change updates the specification of MessageFormat to make this apparent. The wording is specifically chosen as 'may throw' since whether an NPE is thrown depends on the subformat used by MessageFormat (see test example of construction with null locale and no exception thrown).
> 
> The test for this change was merged with `Bug6481179.java` into `MessageFormatExceptions.java` (As they both test exceptions). In addition, some other exception testing regarding MessageFormat was added.
> 
> Thanks

src/java.base/share/classes/java/text/MessageFormat.java line 396:

> 394:      * {@code NullPointerException} if {@code locale} is {@code null}
> 395:      * either during the creation of the {@code MessageFormat} object or later
> 396:      * when {@code format()} is called by the constructed {@code MessageFormat} object.

It looks a bit vague as it contains `may`. I think it would be clearer if it explains a bit more, e.g., it throws NPE if any of the subformats require the locale, or along with those lines. Probably the same wording is needed at `format()` and other public methods that use the `locale` field.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14911#discussion_r1265940997

From rriggs at openjdk.org  Mon Jul 17 22:11:14 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Jul 2023 22:11:14 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: <2MdsicEbxLDSQZQJkSnU0zTdhmNk3wDmPHnQlchs_M0=.e10a138e-44d3-499a-b945-946cf3a13330@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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
> 
>   8310833: Clarify the targetName parameter of Lookup::findClass

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14668#pullrequestreview-1533772261

From bchristi at openjdk.org  Mon Jul 17 22:11:14 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 17 Jul 2023 22:11:14 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: <bq5vOeRPmB6Bkxnr-l93z5KYduiJpYRWu6oZPKP7LEE=.77b03ea6-e226-4b2e-a0f3-406249a86549@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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
> 
>   8310833: Clarify the targetName parameter of Lookup::findClass

Looks fine.

-------------

Marked as reviewed by bchristi (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14668#pullrequestreview-1533774019

From mchung at openjdk.org  Mon Jul 17 22:11:15 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 17 Jul 2023 22:11:15 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: <phCjMAAA6UDJpKAveB6_Zk_IwD_HzzbdyagX8ormH_8=.aca1ad4c-aca4-46c6-8a46-382967050bca@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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
> 
>   8310833: Clarify the targetName parameter of Lookup::findClass

Thank you for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14668#issuecomment-1638953141

From prappo at openjdk.org  Mon Jul 17 22:31:17 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 17 Jul 2023 22:31:17 GMT
Subject: Integrated: 8312089: Simplify and modernize equals, hashCode,
 and compareTo in java.nio and implementation code
In-Reply-To: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
Message-ID: <nxnJNw93FH3Nxct_Tk8u0ISP-8RTeR5NcSccYV64Des=.5453c867-282c-4657-a0b6-348076885a40@github.com>

On Fri, 14 Jul 2023 12:06:29 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 in java.nio and implementation code.
> 
> Please note, test results are pending.
> 
> Additional notes:
> 
> * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements.
> 
> * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified.
> 
> * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it.
> 
> * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification.
> 
> * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose.
> 
> * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith.

This pull request has now been integrated.

Changeset: 5cc71f81
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5cc71f817ff97a17a9f1dfc72a6f10ebe701baaa
Stats:     136 lines in 14 files changed: 13 ins; 74 del; 49 mod

8312089: Simplify and modernize equals, hashCode, and compareTo in java.nio and implementation code

Reviewed-by: alanb, vtewari

-------------

PR: https://git.openjdk.org/jdk/pull/14886

From bchristi at openjdk.org  Mon Jul 17 22:37:15 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 17 Jul 2023 22:37:15 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: <heCtq8gxcLR2kk5VsSu70Zyvk9J8110-W6VDB2ZBFgA=.613f440b-49f7-457e-8c0b-a13705ab76c7@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

July already!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/8311#issuecomment-1638979092

From john.r.rose at oracle.com  Mon Jul 17 23:10:43 2023
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 17 Jul 2023 16:10:43 -0700
Subject: Questions about using `assert` in Java
In-Reply-To: <91b41b49-a38c-f72e-2ad1-c52be83021f0@oracle.com>
References: <BLAPR07MB7508C14D0D90DF38CC6CC758CB37A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <91b41b49-a38c-f72e-2ad1-c52be83021f0@oracle.com>
Message-ID: <269D44E8-D01D-423D-ACCA-817324D1BD34@oracle.com>

On 17 Jul 2023, at 2:08, Alan Bateman wrote:

> On 15/07/2023 17:53, Daohan Qu wrote:
>
> You will find places in the JDK code, esp. in performance critical 
> code, where assertions are commented out. The reason is that asserts, 
> even if disabled, increase the method size and can impact inlining by 
> the compiler at run-time.? So while useful when debugging some issue 
> in such code, they are commended out to avoid increasing the method 
> size.

In JDK code that must be hand-tuned for performance, small methods are 
sometimes broken into 2-3 even smaller methods.  This is rarely done, 
because it is a compromise against maintainability.  It can provide a 
way to introduce asserts even into performance sensitive methods, if 
there is some particular need.

The basic idea is to have the assert expression be a call to a private 
static helper method, so its code size is minimal.  Then, if necessary, 
have the actual computation (before or after the assert) moved into a 
second helper method.

Here?s an example.  (It doesn?t do anything interesting, but it has 
a few mildly complicated expressions.)

```
class AssertExample {
     public static double circleQueryFast(double x, double y) {
         assert circleQueryChecks(x, y);
         return circleQueryCompute(x, y);
     }
     private static boolean circleQueryChecks(double x, double y) {
         return x*x + y*y < 1.0;
     }
     private static double circleQueryCompute(double x, double y) {
         double x2 = x*x, y2 = y*y;
         return x2 < y2 ? y - x : x - y;
     }
     public static double circleQuerySlow(double x, double y) {
         double x2 = x*x, y2 = y*y;
         assert x2 + y2 < 1.0;
         return x2 < y2 ? y - x : x - y;
     }
}
```

In this example, the ?fast? public method will often inline and 
optimize better than the ?slow? public method.  This is because the 
all-in-one ?slow? method is rather large, and the other three, 
although they collectively are even larger, are each simple enough to 
get a very favorable rating from the inlining policy.

Specifically, if a method has 35 bytecodes or less it gets favorable 
inlining decision.  (That is, `MaxInlineSize=35`.)  All of the above 
methods except the ?slow? one are within this limit.  (Try `javac 
AssertExample.java  && javap -c -p AssertExample.class`.)

That might seem an outrageous oversimplification, but if you think about 
it, the inlining policy of an online JIT needs to be relatively simple, 
so it can make its decisions very quickly.  Getting a more balanced 
decision here would require something like a backtracking inlining 
policy, or a search over potential call graphs.  That is certainly 
possible, but it was not the practical decision 25 years ago when this 
inlining policy was designed.

Should we fix it?  Well, yes, and there are RFEs to work on for this:

https://bugs.openjdk.org/browse/JDK-6445664

But it?s not just a matter of filing RFEs or willpower or resources; 
there are risks due to the scale of Java code already deployed on 
HotSpot.  Anything we do now, after years of people tuning their Java 
code against this (implicit) contract, had better not make the existing 
code run much slower.  Or maybe there could be some user-friendly path 
to detection and remediation, perhaps using diagnostic flags.

For asserts, I think it would be relatively safe and efficient to remove 
the effects of untaken blocks (including assert logic) from the metric 
that MaxInlineSize is compared against.

That is, since an assert compiles to an if/then construct, where the 
if-condition is a constant which is usually false (only true under `java 
-ea`), it would be reasonable to note somehow (at inline policy time) 
that the relevant if/then-block will never be taken.  This analysis 
could be gated by profile information, at least in part.  The JIT does 
this sort of thing anyway, but it is not connected fully to the inlining 
policy, at present.

But this will require some research.  It could perturb even existing 
programs, with a certain number of them having a slight loss of 
performance.  The C2 inlining policy has become almost fossilized by its 
own success.  It?s easy to show cases where it gives the wrong answer, 
but hard to show an alternative that would do no harm to the millions of 
workloads out there.

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230717/e14317d5/attachment.htm>

From prappo at openjdk.org  Mon Jul 17 23:33:37 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 17 Jul 2023 23:33:37 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v5]
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <BTRuTjgqXbrydam6sjfVRIWXnwApuM-z6fS1s6drDOU=.0ae94845-0b94-45d6-8404-bc0e32ac2ebe@github.com>

> Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in the java.text area.
> 
> * Some changes to `equals` and `hashCode` are refactoring rather than modernization. Such changes can be as trivial as rearranging, adding, or commenting checks.
> 
> * java.text area contains more classes whose `equals` and `hashCode` could be simplified; for example: sun.text.CompactByteArray or java.text.DigitList. However, I found no evidence of `equals` and `hashCode` in those classes being used in source or tests. Since writing new tests in this case seems unreasonable, I **excluded** those classes from this PR.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14752/files
  - new: https://git.openjdk.org/jdk/pull/14752/files/f1ce3a10..64177d8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14752&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14752&range=03-04

  Stats: 10 lines in 1 file changed: 0 ins; 5 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14752/head:pull/14752

PR: https://git.openjdk.org/jdk/pull/14752

From prappo at openjdk.org  Tue Jul 18 00:06:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 18 Jul 2023 00:06:13 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v5]
In-Reply-To: <9yQuD4s56Jx6Ks4ORj_mGSEIPOGg2YE9lua0uzhJJgs=.1f7b4918-88b9-4246-90b1-18c463cbbafb@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
 <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
 <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
 <tB0gdwb1wJsxS3sn9FmNwvj_2HOmm6N7WBysURUYoPM=.25f1b2f6-ea63-4022-b451-aa93eb57c04b@github.com>
 <r4-dPyuclFOYil8WAkurSA0wlwSF7wlugZX8LDa2qrE=.f7cde5c3-5882-4511-8548-10dea66522c5@github.com>
 <9yQuD4s56Jx6Ks4ORj_mGSEIPOGg2YE9lua0uzhJJgs=.1f7b4918-88b9-4246-90b1-18c463cbbafb@github.com>
Message-ID: <nPme76lZmpex7O5VazJDckxGtO8xrX78Lv3EU3iPpY8=.5cbe037f-3c36-4694-93e5-a3cda48bd23c@github.com>

On Wed, 12 Jul 2023 22:26:14 GMT, John R Rose <jrose at openjdk.org> wrote:

> Yes, it would be, because `rp` has a statically observable type, `BigInteger`. And that observation will flow across the call to the helper method.

After all, my mental model is incorrect; sigh.

I read your write-up as though once we see a static method with an Object/generic parameter, which receives a call inside that static method, our "observation of a static type" is toast.

Please provide (ideally) a few examples of a refactoring that would choke "observation of a static type", so I could correct my model.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1266026286

From liach at openjdk.org  Tue Jul 18 01:01:25 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Jul 2023 01:01:25 GMT
Subject: Integrated: 8291065: Creating a VarHandle for a static field triggers
 class initialization
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <58n5okpH6tiCdvfzrxIFUrzVybVBwA5Pk4JwARGYpIo=.d8694179-fe01-4f51-a41c-6bd75d93e7ee@github.com>

On Fri, 5 May 2023 04:48:09 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

This pull request has now been integrated.

Changeset: 201e3bcf
Author:    Chen Liang <liach at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/201e3bcf52cac64510d50fbdfcd522638d1d0442
Stats:     796 lines in 10 files changed: 636 ins; 52 del; 108 mod

8291065: Creating a VarHandle for a static field triggers class initialization

Reviewed-by: mchung, psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/13821

From duke at openjdk.org  Tue Jul 18 01:20:18 2023
From: duke at openjdk.org (duke)
Date: Tue, 18 Jul 2023 01:20:18 GMT
Subject: Withdrawn: 8305538: Avoid redundant HashMap.containsKey call in
 ModuleDescriptor.Builder
In-Reply-To: <cwKHk3sU2rRXKv4jNF2Biij7dPqlFQva3hBb8ZlVm-4=.18a6501d-db9d-44f4-9297-4e6dfa39c2e8@github.com>
References: <cwKHk3sU2rRXKv4jNF2Biij7dPqlFQva3hBb8ZlVm-4=.18a6501d-db9d-44f4-9297-4e6dfa39c2e8@github.com>
Message-ID: <Vxd_kAkEIWC3ytcl3fvrxy8kc93sbkJ-7gv-XR7rdRs=.4a649635-ad77-4c8c-ba9f-d6beb8b11c4b@github.com>

On Mon, 3 Apr 2023 08:08:45 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Map.containsKey` call is sometimes unnecessary, when it's known that `Map` doesn't contain `null` values.
> Instead of pair containsKey+put we can use putIfAbsent and compare result with null.
> Result code is shorter and a bit faster.
> Same approach is used with `HashSet<String> uses` in `java.lang.module.ModuleDescriptor.Builder#uses`. Instead of separate `contains`+`add` - we can just call `add` then check what it returns.
> 
> Testing: Linux x64 `java/lang`

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/13288

From duke at openjdk.org  Tue Jul 18 01:30:14 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 18 Jul 2023 01:30:14 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v12]
In-Reply-To: <6Z9eOwWQA7NeLDOsYW0Oh373ArzaZIGk0JaWFGWfOj4=.40bb7830-6405-4d3e-9a4e-e17b3b066871@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <PNhV9fuNjZQCC0FbZvfucuaf3D3b0FYap0z_J8mSyTA=.6b3d7540-f908-4e33-ac37-cdad1899fd80@github.com>
 <6Z9eOwWQA7NeLDOsYW0Oh373ArzaZIGk0JaWFGWfOj4=.40bb7830-6405-4d3e-9a4e-e17b3b066871@github.com>
Message-ID: <42uo6hPrzs69DxtpDnJboSUFQXl-3TnCeGnpfSBdOfk=.d1f7ea17-8826-42ce-aefb-7a58dc1bf51e@github.com>

On Mon, 17 Jul 2023 20:53:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Integer/Long toString test against compact strings
>>   
>>   Co-authored-by: liach <liach at users.noreply.github.com>
>
> src/java.base/share/classes/java/lang/Integer.java line 528:
> 
>> 526:             i = q;
>> 527:             charPos -= 2;
>> 528:             UNSAFE.putShortUnaligned(buf, Unsafe.ARRAY_BYTE_BASE_OFFSET + charPos, PACKED_DIGITS[r], false);
> 
> When switching to use Unsafe, `getChars` should do the array bounds check in the loop of the store index.

The value range of the r variable is 0-99, and the length of PACKED_DIGITS is 100, There is no need to check the array boundary here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1266072419

From liach at openjdk.org  Tue Jul 18 01:42:14 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Jul 2023 01:42:14 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v12]
In-Reply-To: <42uo6hPrzs69DxtpDnJboSUFQXl-3TnCeGnpfSBdOfk=.d1f7ea17-8826-42ce-aefb-7a58dc1bf51e@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <PNhV9fuNjZQCC0FbZvfucuaf3D3b0FYap0z_J8mSyTA=.6b3d7540-f908-4e33-ac37-cdad1899fd80@github.com>
 <6Z9eOwWQA7NeLDOsYW0Oh373ArzaZIGk0JaWFGWfOj4=.40bb7830-6405-4d3e-9a4e-e17b3b066871@github.com>
 <42uo6hPrzs69DxtpDnJboSUFQXl-3TnCeGnpfSBdOfk=.d1f7ea17-8826-42ce-aefb-7a58dc1bf51e@github.com>
Message-ID: <ffmxg06jW22ITugbsx4CTErFRPCzeCAy8ylxLGkVdVI=.4321b0cc-d166-4a95-a6d0-937f5bd6f489@github.com>

On Tue, 18 Jul 2023 01:26:55 GMT, ??? <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Integer.java line 528:
>> 
>>> 526:             i = q;
>>> 527:             charPos -= 2;
>>> 528:             UNSAFE.putShortUnaligned(buf, Unsafe.ARRAY_BYTE_BASE_OFFSET + charPos, PACKED_DIGITS[r], false);
>> 
>> When switching to use Unsafe, `getChars` should do the array bounds check in the loop of the store index.
>
> The value range of the r variable is 0-99, and the length of PACKED_DIGITS is 100, There is no need to check the array boundary here.

I think he means to check the `charPos` to ensure it is not out of bounds.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1266080264

From duke at openjdk.org  Tue Jul 18 01:49:17 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 18 Jul 2023 01:49:17 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v13]
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: <Q40yhMfrkRyDx5Zfz_y6UUPXTspFUMWQuo_BPl9Dc8U=.ff88f1af-07b6-4a8f-b916-a2e4dd97f21d@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:

  assert bounds check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14699/files
  - new: https://git.openjdk.org/jdk/pull/14699/files/36f361f6..a69f6d2a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=11-12

  Stats: 10 lines in 3 files changed: 10 ins; 0 del; 0 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  Tue Jul 18 01:55:14 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 18 Jul 2023 01:55:14 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v12]
In-Reply-To: <ffmxg06jW22ITugbsx4CTErFRPCzeCAy8ylxLGkVdVI=.4321b0cc-d166-4a95-a6d0-937f5bd6f489@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <PNhV9fuNjZQCC0FbZvfucuaf3D3b0FYap0z_J8mSyTA=.6b3d7540-f908-4e33-ac37-cdad1899fd80@github.com>
 <6Z9eOwWQA7NeLDOsYW0Oh373ArzaZIGk0JaWFGWfOj4=.40bb7830-6405-4d3e-9a4e-e17b3b066871@github.com>
 <42uo6hPrzs69DxtpDnJboSUFQXl-3TnCeGnpfSBdOfk=.d1f7ea17-8826-42ce-aefb-7a58dc1bf51e@github.com>
 <ffmxg06jW22ITugbsx4CTErFRPCzeCAy8ylxLGkVdVI=.4321b0cc-d166-4a95-a6d0-937f5bd6f489@github.com>
Message-ID: <etftkpFRiMb1JsEZBYuXccJCk9pjtKtBFGuT91cVqJA=.4d5a2825-8662-40a9-80c0-555722b8fb64@github.com>

On Tue, 18 Jul 2023 01:38:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The value range of the r variable is 0-99, and the length of PACKED_DIGITS is 100, There is no need to check the array boundary here.
>
> I think he means to check the `charPos` to ensure it is not out of bounds.

Oh, I see, charPos needs to do bound checks,  I added assert with reference to the implementation of StringUTF16#putChar, is this safe enough?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1266090826

From liach at openjdk.org  Tue Jul 18 01:57:58 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Jul 2023 01:57:58 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v25]
In-Reply-To: <HcGX3-ArAn2uPCP-qAVRNHIpAkazR270T7OEvvE3Ul4=.eef1cf28-bb1d-4678-a6d1-2577240320fe@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <dTxPQBneimja4eNhQuamUgJNakNMzgATciUte76SK5c=.95622355-daa2-41a9-bfdf-a1527eb077a3@github.com>
 <ejyt9uHFnuVeU9P0Rn4bXGVKGtRf4DAuu-AeKuPFvKQ=.7b5a6300-0714-4437-a330-8783478afb57@github.com>
 <HcGX3-ArAn2uPCP-qAVRNHIpAkazR270T7OEvvE3Ul4=.eef1cf28-bb1d-4678-a6d1-2577240320fe@github.com>
Message-ID: <b4mYs33A2aWHhD1lOe9Xz1oEWGPlFBANtfXbwjOMih0=.a591a467-1380-4194-992d-e0584c72a376@github.com>

On Mon, 17 Jul 2023 17:29:09 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java line 165:
>> 
>>> 163:                 () -> "incorrect dynamic module name: " + implModule.getName());
>>> 164: 
>>> 165:         assertSame(implClass.getClassLoader(), implModule.getClassLoader(),
>> 
>> I think this should check against `ifaceModule.getClassLoader()` instead, right? Since the dynamic module is defined in the interface' class loader.
>
> Good catch!   Yes, this should check against the interface's loader.

I've added a new check for `ifaceClass.getClassLoader()`, should be functionally equivalent. This check is originally part of `ProxyForMethodHandle` test, so I decided to keep it as well as it tests impl module's behavior.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1266091042

From liach at openjdk.org  Tue Jul 18 01:58:13 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Jul 2023 01:58:13 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v12]
In-Reply-To: <etftkpFRiMb1JsEZBYuXccJCk9pjtKtBFGuT91cVqJA=.4d5a2825-8662-40a9-80c0-555722b8fb64@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <PNhV9fuNjZQCC0FbZvfucuaf3D3b0FYap0z_J8mSyTA=.6b3d7540-f908-4e33-ac37-cdad1899fd80@github.com>
 <6Z9eOwWQA7NeLDOsYW0Oh373ArzaZIGk0JaWFGWfOj4=.40bb7830-6405-4d3e-9a4e-e17b3b066871@github.com>
 <42uo6hPrzs69DxtpDnJboSUFQXl-3TnCeGnpfSBdOfk=.d1f7ea17-8826-42ce-aefb-7a58dc1bf51e@github.com>
 <ffmxg06jW22ITugbsx4CTErFRPCzeCAy8ylxLGkVdVI=.4321b0cc-d166-4a95-a6d0-937f5bd6f489@github.com>
 <etftkpFRiMb1JsEZBYuXccJCk9pjtKtBFGuT91cVqJA=.4d5a2825-8662-40a9-80c0-555722b8fb64@github.com>
Message-ID: <UCv0ewmdWgi9oQDdiR4z4Cwpqg2zGf8pZcScUOd4ZRM=.912e1ba0-d091-46ae-b23d-1eabcdcf7269@github.com>

On Tue, 18 Jul 2023 01:52:35 GMT, ??? <duke at openjdk.org> wrote:

>> I think he means to check the `charPos` to ensure it is not out of bounds.
>
> Oh, I see, charPos needs to do bound checks,  I added assert with reference to the implementation of StringUTF16#putChar, is this safe enough?

I think we might need to look into the code around to ensure user input cannot cause charPos to go out of bounds. If charPos is not touched by user code at all, I think assert suffices (which are enabled via -esa and is thus enabled in the jtreg test suite)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1266092100

From liach at openjdk.org  Tue Jul 18 01:57:56 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Jul 2023 01:57:56 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v26]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <hJ3dBq7oaRN8OtWTQS12mnGoAav0NlIuoezGYObY3b4=.624abdc9-d002-4589-933a-c43dbc474158@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 54 commits:

 - Review class loader check, restore hidden class rejection spec
 - Merge branch 'master' into explore/mhp-iface
 - Review changees
 - Fix the lazy test, thanks Jorn Vernee!
 - Clean up impl comment, reorganize tests; weak ref broken
 - Merge branch 'master' into explore/mhp-iface
 - Fix broken null behaviors
 - Merge branch 'master' into explore/mhp-iface
 - Merge branch 'mh-proxies' of https://github.com/mlchung/jdk into explore/mhp-iface
 - store a WeakReference holder in the class value
 - ... and 44 more: https://git.openjdk.org/jdk/compare/a53345ad...a12fba06

-------------

Changes: https://git.openjdk.org/jdk/pull/13197/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=25
  Stats: 1451 lines in 13 files changed: 1050 ins; 311 del; 90 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 andrewluotechnologies at outlook.com  Tue Jul 18 02:45:59 2023
From: andrewluotechnologies at outlook.com (Andrew Luo)
Date: Tue, 18 Jul 2023 02:45:59 +0000
Subject: Questions about using `assert` in Java
In-Reply-To: <91b41b49-a38c-f72e-2ad1-c52be83021f0@oracle.com>
References: <BLAPR07MB7508C14D0D90DF38CC6CC758CB37A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <91b41b49-a38c-f72e-2ad1-c52be83021f0@oracle.com>
Message-ID: <PH7PR11MB7429955F31388C5A848BB152A138A@PH7PR11MB7429.namprd11.prod.outlook.com>

This makes me wonder if it is worth introducing a compiler flag that would omit assert statements from the compiled bytecode for this scenario.  Forgive me if this has been discussed and decided before though?

Thanks,

-Andrew

From: core-libs-dev <core-libs-dev-retn at openjdk.org> On Behalf Of Alan Bateman
Sent: Monday, July 17, 2023 2:08 AM
To: Daohan Qu <quadhier at outlook.com>; core-libs-dev at openjdk.org
Subject: Re: Questions about using `assert` in Java

On 15/07/2023 17:53, Daohan Qu wrote:

:

Although the assert? keyword has been around for a long time and
is handy for invariant checks, it does not seem to be widely used.
For example, in the famous j.u.c? packages, nearly all assert?
statements are commented out [1].

My questions are, should assert? be heavily used in Java programs,
especially in production code? And should we enable them in the
production code?

Asserts are very useful during development or when testing, e.g. the JDK tests run with -esa and can periodically help catch issues when testing a change.

You will find places in the JDK code, esp. in performance critical code, where assertions are commented out. The reason is that asserts, even if disabled, increase the method size and can impact inlining by the compiler at run-time.  So while useful when debugging some issue in such code, they are commended out to avoid increasing the method size.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230718/4ad394e8/attachment-0001.htm>

From quadhier at outlook.com  Tue Jul 18 02:54:30 2023
From: quadhier at outlook.com (Daohan Qu)
Date: Tue, 18 Jul 2023 02:54:30 +0000
Subject: =?big5?B?tarOYDogUXVlc3Rpb25zIGFib3V0IHVzaW5nIGBhc3NlcnRgIGluIEphdmE=?=
In-Reply-To: <PH7PR11MB7429955F31388C5A848BB152A138A@PH7PR11MB7429.namprd11.prod.outlook.com>
References: <BLAPR07MB7508C14D0D90DF38CC6CC758CB37A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <91b41b49-a38c-f72e-2ad1-c52be83021f0@oracle.com>
 <PH7PR11MB7429955F31388C5A848BB152A138A@PH7PR11MB7429.namprd11.prod.outlook.com>
Message-ID: <BLAPR07MB7508A0D214731798602A6C1CCB38A@BLAPR07MB7508.namprd07.prod.outlook.com>

> This makes me wonder if it is worth introducing a compiler flag
> that would omit assert statements from the compiled bytecode
> for this scenario.

Hi Andrew,

Maybe the first one of this FAQ could answer your question:

https://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#design-faq-enable-disable

- Daohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230718/cc8b3399/attachment.htm>

From darcy at openjdk.org  Tue Jul 18 02:57:53 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Jul 2023 02:57:53 GMT
Subject: RFR: 8302987: Add uniform and spatially equidistributed bounded
 double streams to RandomGenerator [v10]
In-Reply-To: <X9t6_xr33svBkqZB_IKmfw4XQuo7VTQWwM6VLI0LgvM=.af9d703c-8583-4f1d-bb64-d67067807d33@github.com>
References: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
 <X9t6_xr33svBkqZB_IKmfw4XQuo7VTQWwM6VLI0LgvM=.af9d703c-8583-4f1d-bb64-d67067807d33@github.com>
Message-ID: <L11g-yXScgRfmSYFUxR7onC0h50Ox7fyqBnz17zIxH0=.890bf17f-4f58-419a-8102-777254ffa425@github.com>

On Wed, 31 May 2023 11:57:19 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.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correction in comment.

I read over the cited paper and the code in the PR.

If this new method is sufficiently used, we could considering adding and equidoubles(double a, b) overload for the [a, b) case.

src/java.base/share/classes/java/util/random/RandomGenerator.java line 398:

> 396:              * afforded by nextLong().
> 397:              */
> 398:             delta = nextUp(left) - left;

The delta computations are equivalent to some expression phrased in terms of an ulp (Math.ulp) of a the endpoint or a value adjacent to the endpoint. If the ulp method is not used for the computation, I suggest adding a comment noting the equivalence.

-------------

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12719#pullrequestreview-1534025771
PR Review Comment: https://git.openjdk.org/jdk/pull/12719#discussion_r1266129903

From andrewluotechnologies at outlook.com  Tue Jul 18 03:03:02 2023
From: andrewluotechnologies at outlook.com (Andrew Luo)
Date: Tue, 18 Jul 2023 03:03:02 +0000
Subject: Questions about using `assert` in Java
In-Reply-To: <BLAPR07MB7508A0D214731798602A6C1CCB38A@BLAPR07MB7508.namprd07.prod.outlook.com>
References: <BLAPR07MB7508C14D0D90DF38CC6CC758CB37A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <91b41b49-a38c-f72e-2ad1-c52be83021f0@oracle.com>
 <PH7PR11MB7429955F31388C5A848BB152A138A@PH7PR11MB7429.namprd11.prod.outlook.com>
 <BLAPR07MB7508A0D214731798602A6C1CCB38A@BLAPR07MB7508.namprd07.prod.outlook.com>
Message-ID: <PH7PR11MB7429DF483EBEB8E2E8A4F4D2A138A@PH7PR11MB7429.namprd11.prod.outlook.com>

Thanks, I see.  Then I wonder if we should consider the size of a function with assertions removed when making JIT inline decisions?  Since at JIT time I presume whether assertions are turned on or off is known ? or is it too inefficient to calculate this metric?

Thanks,
-Andrew

From: Daohan Qu <quadhier at outlook.com>
Sent: Monday, July 17, 2023 7:55 PM
To: Andrew Luo <andrewluotechnologies at outlook.com>; core-libs-dev at openjdk.org
Subject: ??: Questions about using `assert` in Java

> This makes me wonder if it is worth introducing a compiler flag
> that would omit assert statements from the compiled bytecode
> for this scenario.

Hi Andrew,

Maybe the first one of this FAQ could answer your question:

https://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#design-faq-enable-disable

- Daohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230718/05ab35a6/attachment-0001.htm>

From quadhier at outlook.com  Tue Jul 18 03:10:30 2023
From: quadhier at outlook.com (Daohan Qu)
Date: Tue, 18 Jul 2023 03:10:30 +0000
Subject: Questions about using `assert` in Java
In-Reply-To: <PH7PR11MB7429DF483EBEB8E2E8A4F4D2A138A@PH7PR11MB7429.namprd11.prod.outlook.com>
References: <BLAPR07MB7508C14D0D90DF38CC6CC758CB37A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <BLAPR07MB7508B6FA999645629E2A0374CB35A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <91b41b49-a38c-f72e-2ad1-c52be83021f0@oracle.com>
 <PH7PR11MB7429955F31388C5A848BB152A138A@PH7PR11MB7429.namprd11.prod.outlook.com>
 <BLAPR07MB7508A0D214731798602A6C1CCB38A@BLAPR07MB7508.namprd07.prod.outlook.com>
 <PH7PR11MB7429DF483EBEB8E2E8A4F4D2A138A@PH7PR11MB7429.namprd11.prod.outlook.com>
Message-ID: <BLAPR07MB7508BAD307CDF5D378462D66CB38A@BLAPR07MB7508.namprd07.prod.outlook.com>

> Then I wonder if we should consider the size of a function with
> assertions removed when making JIT inline decisions?  Since
> at JIT time I presume whether assertions are turned on or off
> is known ? or is it too inefficient to calculate this metric?

Hi Andrew,

This is also a good suggestion. John has provided a comprehensive
analysis for this idea. You may refer to his email in this thread.

- Daohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230718/d3148103/attachment.htm>

From jvernee at openjdk.org  Tue Jul 18 03:28:17 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 18 Jul 2023 03:28:17 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v26]
In-Reply-To: <hJ3dBq7oaRN8OtWTQS12mnGoAav0NlIuoezGYObY3b4=.624abdc9-d002-4589-933a-c43dbc474158@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <hJ3dBq7oaRN8OtWTQS12mnGoAav0NlIuoezGYObY3b4=.624abdc9-d002-4589-933a-c43dbc474158@github.com>
Message-ID: <12ih6z7744JZoqcXx6XynXfPkFlH0gMRQhVSS4IXujg=.3c2a105e-3580-4f41-b98d-882d2f6cc21b@github.com>

On Tue, 18 Jul 2023 01:57:56 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 54 commits:
> 
>  - Review class loader check, restore hidden class rejection spec
>  - Merge branch 'master' into explore/mhp-iface
>  - Review changees
>  - Fix the lazy test, thanks Jorn Vernee!
>  - Clean up impl comment, reorganize tests; weak ref broken
>  - Merge branch 'master' into explore/mhp-iface
>  - Fix broken null behaviors
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'mh-proxies' of https://github.com/mlchung/jdk into explore/mhp-iface
>  - store a WeakReference holder in the class value
>  - ... and 44 more: https://git.openjdk.org/jdk/compare/a53345ad...a12fba06

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13197#pullrequestreview-1534080242

From davidalayachew at gmail.com  Tue Jul 18 03:43:24 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 17 Jul 2023 23:43:24 -0400
Subject: Illegal field name when trying to compile with a
 javax.swing.Action
In-Reply-To: <CAA9v-_OiVNJFNMUSj191YjEB5-Qn79wRkSZTTD6fF5WEszq=tw@mail.gmail.com>
References: <CAA9v-_Oo39GDpyXTDFrmbEGDBEWgTbD4WALFgOO2YweRJ1Nv_g@mail.gmail.com>
 <CAA9v-_OiVNJFNMUSj191YjEB5-Qn79wRkSZTTD6fF5WEszq=tw@mail.gmail.com>
Message-ID: <CAA9v-_NNkg=+odbd7G6bOyy20H5rOkSBuRoa1SGSLSELEqnpRg@mail.gmail.com>

Wait, nevermind. Don't ignore. I was able to recreate this issue on the
command line using the abovementioned JDK. Could someone come back and take
a look at this please?

Sorry for jerking everyone around here. I have multiple JDK's and got mixed
up on which one I was using.

On Sun, Jul 16, 2023 at 2:26?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hmmmm, this one might actually be IDE specific. Please ignore.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230717/2becfdd5/attachment-0001.htm>

From liach at openjdk.org  Tue Jul 18 04:39:28 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Jul 2023 04:39:28 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v26]
In-Reply-To: <hJ3dBq7oaRN8OtWTQS12mnGoAav0NlIuoezGYObY3b4=.624abdc9-d002-4589-933a-c43dbc474158@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <hJ3dBq7oaRN8OtWTQS12mnGoAav0NlIuoezGYObY3b4=.624abdc9-d002-4589-933a-c43dbc474158@github.com>
Message-ID: <Sat8UPeC-GvT3vUiWEJbP0FCsx9ovWY2oGLDTRkGF_E=.a05a97ae-8bb6-48cc-8ce5-e822d8207f5f@github.com>

On Tue, 18 Jul 2023 01:57:56 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 54 commits:
> 
>  - Review class loader check, restore hidden class rejection spec
>  - Merge branch 'master' into explore/mhp-iface
>  - Review changees
>  - Fix the lazy test, thanks Jorn Vernee!
>  - Clean up impl comment, reorganize tests; weak ref broken
>  - Merge branch 'master' into explore/mhp-iface
>  - Fix broken null behaviors
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'mh-proxies' of https://github.com/mlchung/jdk into explore/mhp-iface
>  - store a WeakReference holder in the class value
>  - ... and 44 more: https://git.openjdk.org/jdk/compare/a53345ad...a12fba06

Joe Darcy asks us to consider whether a release note should be added. I think yes, since there's some behavioral differences like hidden vs non-hidden classes.

However, I think I might be able to upgrade asInterfaceInstance to accept protected abstract classes with a single public/protected abstract method(s) and a no-arg public/protected constructor, like `ClassValue`. If that's the case, do we still require a release note for this one, or do we defer and merge the notes?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1639420123

From darcy at openjdk.org  Tue Jul 18 04:49:28 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Jul 2023 04:49:28 GMT
Subject: RFR: JDK-8312203: Improve specification of Array.newInstance
Message-ID: <LtpWOTegDJATFzEXDXgv4TJ0S3eFiASN2TGuViSFgtA=.b224ceaa-1052-489a-8c31-132b853ae3e2@github.com>

Change one overload of java.lang.reflect.Array.newInstance to have an `@implSpec` of calling the other method.

I choose not to use a snippet tag here is this code is semantically only one line and doesn't need to be cut-and-pasted.

As adding an `@implSpec` is technically a (small) specification change, please also review the CSR:

https://bugs.openjdk.org/browse/JDK-8312208

-------------

Commit messages:
 - Update copyright year.
 - JDK-8312203: Improve specification of Array.newInstance

Changes: https://git.openjdk.org/jdk/pull/14917/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14917&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312203
  Stats: 6 lines in 1 file changed: 1 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14917.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14917/head:pull/14917

PR: https://git.openjdk.org/jdk/pull/14917

From liach at openjdk.org  Tue Jul 18 05:08:01 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Jul 2023 05:08:01 GMT
Subject: RFR: JDK-8312203: Improve specification of Array.newInstance
In-Reply-To: <LtpWOTegDJATFzEXDXgv4TJ0S3eFiASN2TGuViSFgtA=.b224ceaa-1052-489a-8c31-132b853ae3e2@github.com>
References: <LtpWOTegDJATFzEXDXgv4TJ0S3eFiASN2TGuViSFgtA=.b224ceaa-1052-489a-8c31-132b853ae3e2@github.com>
Message-ID: <HVMFCvpScrMMhxDsfTykfAUtKPb6VPoDvY6hEfqhIzc=.f79f6195-891c-4735-a503-9fa8e3ef4b06@github.com>

On Tue, 18 Jul 2023 04:42:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Change one overload of java.lang.reflect.Array.newInstance to have an `@implSpec` of calling the other method.
> 
> I choose not to use a snippet tag here is this code is semantically only one line and doesn't need to be cut-and-pasted.
> 
> As adding an `@implSpec` is technically a (small) specification change, please also review the CSR:
> 
> https://bugs.openjdk.org/browse/JDK-8312208

src/java.base/share/classes/java/lang/reflect/Array.java line 56:

> 54:      * as follows:
> 55:      * <blockquote>
> 56:      * {@code Array.newInstance(componentType, new int[]{length});}

Snippet is not just for cut-and-paste; it can also save us a `<blockquote>` tag as well, and syntax highlight support in IDEs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14917#discussion_r1266228014

From alanb at openjdk.org  Tue Jul 18 05:16:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Jul 2023 05:16:16 GMT
Subject: Integrated: 8312127: FileDescriptor.sync should temporarily increase
 parallelism
In-Reply-To: <2SDSwteRiWBEhbw3Fk7jZk0DKN-BThtnby9miCjQcas=.a82197eb-22f5-42f6-be3c-f9c1704fcda0@github.com>
References: <2SDSwteRiWBEhbw3Fk7jZk0DKN-BThtnby9miCjQcas=.a82197eb-22f5-42f6-be3c-f9c1704fcda0@github.com>
Message-ID: <6MOn-5DMVN0Vxy4W7YN2TikGAPctbUE09RGNpINp-C4=.8cc56259-5c82-4650-bf05-8b546e78ab42@github.com>

On Sat, 15 Jul 2023 13:54:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If FileDescriptor::sync is invoked by a virtual thread then it doesn't release its carrier to do other work while modifications are written to the file system. For cases like this, parallelism should be temporarily increased for the duration of the operation. This one is somewhat legacy as it's only JDK 1.0/1.1 era APIs that provide access to the FileDescriptor so it wasn't done with the other methods in JDK 19. It's updated here, as it has been noticed.

This pull request has now been integrated.

Changeset: fbe51e38
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fbe51e388d8a7475f162f10aa788a6d37ec4c6d8
Stats:     17 lines in 3 files changed: 11 ins; 0 del; 6 mod

8312127: FileDescriptor.sync should temporarily increase parallelism

Reviewed-by: shade, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/14893

From liangchenblue at gmail.com  Tue Jul 18 05:17:51 2023
From: liangchenblue at gmail.com (-)
Date: Tue, 18 Jul 2023 13:17:51 +0800
Subject: Illegal field name when trying to compile with a
 javax.swing.Action
In-Reply-To: <CAA9v-_NNkg=+odbd7G6bOyy20H5rOkSBuRoa1SGSLSELEqnpRg@mail.gmail.com>
References: <CAA9v-_Oo39GDpyXTDFrmbEGDBEWgTbD4WALFgOO2YweRJ1Nv_g@mail.gmail.com>
 <CAA9v-_OiVNJFNMUSj191YjEB5-Qn79wRkSZTTD6fF5WEszq=tw@mail.gmail.com>
 <CAA9v-_NNkg=+odbd7G6bOyy20H5rOkSBuRoa1SGSLSELEqnpRg@mail.gmail.com>
Message-ID: <CABe8uE0Ncw9UkqcM4QPs4kyEAG+G+6divKwGPHgWtSJYiH+YKA@mail.gmail.com>

Hi David,
Please do not ask for technical support in the development mailing list.
There's no proof that this issue is with the core libraries instead of the
Java compiler or another component.
I have already downloaded your zip, compiled the 4 files with JDK 22 (my
local dev build for another unrelated patch) javac --enable-preview
-release 22 *.java and java --enable-preview ToDoList, which just shows up
a UI without any crash. Without enable-preview, yoru code does not compile
at all for the usage of _ as an identifier.

This is most likely a problem with the compiler you are using; you have a
gpj file, which probably means you are using jGrasp. Please report this
issue to the relevant parties (i.e. the 3rd-party IDE or whatever supports
using _ as identifer without --enable-preview) instead.

Chen Liang

On Tue, Jul 18, 2023 at 11:43?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Wait, nevermind. Don't ignore. I was able to recreate this issue on the
> command line using the abovementioned JDK. Could someone come back and take
> a look at this please?
>
> Sorry for jerking everyone around here. I have multiple JDK's and got
> mixed up on which one I was using.
>
> On Sun, Jul 16, 2023 at 2:26?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Hmmmm, this one might actually be IDE specific. Please ignore.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230718/5828d62c/attachment.htm>

From davidalayachew at gmail.com  Tue Jul 18 05:54:09 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 18 Jul 2023 01:54:09 -0400
Subject: Illegal field name when trying to compile with a
 javax.swing.Action
In-Reply-To: <CABe8uE0Ncw9UkqcM4QPs4kyEAG+G+6divKwGPHgWtSJYiH+YKA@mail.gmail.com>
References: <CAA9v-_Oo39GDpyXTDFrmbEGDBEWgTbD4WALFgOO2YweRJ1Nv_g@mail.gmail.com>
 <CAA9v-_OiVNJFNMUSj191YjEB5-Qn79wRkSZTTD6fF5WEszq=tw@mail.gmail.com>
 <CAA9v-_NNkg=+odbd7G6bOyy20H5rOkSBuRoa1SGSLSELEqnpRg@mail.gmail.com>
 <CABe8uE0Ncw9UkqcM4QPs4kyEAG+G+6divKwGPHgWtSJYiH+YKA@mail.gmail.com>
Message-ID: <CAA9v-_MBDgM+Ns6iOORwF1y7Z_u4-769Psto8FZc-iY=-dJraw@mail.gmail.com>

Ok, ty for the heads up.

On Tue, Jul 18, 2023 at 1:18?AM - <liangchenblue at gmail.com> wrote:

> Hi David,
> Please do not ask for technical support in the development mailing list.
> There's no proof that this issue is with the core libraries instead of the
> Java compiler or another component.
> I have already downloaded your zip, compiled the 4 files with JDK 22 (my
> local dev build for another unrelated patch) javac --enable-preview
> -release 22 *.java and java --enable-preview ToDoList, which just shows up
> a UI without any crash. Without enable-preview, yoru code does not compile
> at all for the usage of _ as an identifier.
>
> This is most likely a problem with the compiler you are using; you have a
> gpj file, which probably means you are using jGrasp. Please report this
> issue to the relevant parties (i.e. the 3rd-party IDE or whatever supports
> using _ as identifer without --enable-preview) instead.
>
> Chen Liang
>
> On Tue, Jul 18, 2023 at 11:43?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Wait, nevermind. Don't ignore. I was able to recreate this issue on the
>> command line using the abovementioned JDK. Could someone come back and take
>> a look at this please?
>>
>> Sorry for jerking everyone around here. I have multiple JDK's and got
>> mixed up on which one I was using.
>>
>> On Sun, Jul 16, 2023 at 2:26?AM David Alayachew <davidalayachew at gmail.com>
>> wrote:
>>
>>> Hmmmm, this one might actually be IDE specific. Please ignore.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230718/2ec79f25/attachment.htm>

From jpai at openjdk.org  Tue Jul 18 07:06:30 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 18 Jul 2023 07:06:30 GMT
Subject: RFR: 8312151: Deprecate for removal the -Xdebug option
Message-ID: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>

Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8312151?

As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.

A CSR has been drafted for this change https://bugs.openjdk.org/browse/JDK-8312216

-------------

Commit messages:
 - 8312151: Deprecate for removal the -Xdebug option

Changes: https://git.openjdk.org/jdk/pull/14918/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312151
  Stats: 35 lines in 22 files changed: 0 ins; 8 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/14918.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14918/head:pull/14918

PR: https://git.openjdk.org/jdk/pull/14918

From jpai at openjdk.org  Tue Jul 18 07:06:30 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 18 Jul 2023 07:06:30 GMT
Subject: RFR: 8312151: Deprecate for removal the -Xdebug option
In-Reply-To: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
Message-ID: <SHNFy0a2Vpx8Dehtonl37EhHjUwnITQ8a1OB9cleiqQ=.ce28a88c-931a-47a0-8ee0-4cbe898d5f22@github.com>

On Tue, 18 Jul 2023 06:59:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8312151?
> 
> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.
> 
> A CSR has been drafted for this change https://bugs.openjdk.org/browse/JDK-8312216

I would like inputs on the `test/hotspot/jtreg/runtime/6294277/SourceDebugExtension.java` test. That test launches `java` passing it the `-Xdebug` option and was introduced as part of https://bugs.openjdk.org/browse/JDK-6294277. `-Xdebug` has been a no-op for many releases now. Is this test still relevant and if not, should I go ahead and remove it as part of this change?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14918#issuecomment-1639615535

From alanb at openjdk.org  Tue Jul 18 07:36:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Jul 2023 07:36:14 GMT
Subject: RFR: 8312151: Deprecate for removal the -Xdebug option
In-Reply-To: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
Message-ID: <ot4CpQPVsamVaNUZE-zOheGbQNzyq64nsm3M-cj7i14=.d97d5f1b-e7b3-44f7-89a0-28c0b75ac0d8@github.com>

On Tue, 18 Jul 2023 06:59:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8312151?
> 
> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.
> 
> A CSR has been drafted for this change https://bugs.openjdk.org/browse/JDK-8312216

The launcher option -debug is an alias for -Xdebug so should be deprecated too. The history on these options goes back a long way, but obsolete since JDK 6 and the removal of JVMDI at least.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14918#issuecomment-1639660251

From jpai at openjdk.org  Tue Jul 18 07:36:12 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 18 Jul 2023 07:36:12 GMT
Subject: RFR: 8312151: Deprecate for removal the -Xdebug option [v2]
In-Reply-To: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
Message-ID: <z5LvzUYoNMyCK69hgJwPu3rauWolx3pfc4A8ZyE5mFk=.2c1fae6f-2fd3-4527-8398-9e45fe6eb68b@github.com>

> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8312151?
> 
> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.
> 
> A CSR has been drafted for this change https://bugs.openjdk.org/browse/JDK-8312216

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  update java man page for -Xdebug deprecation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14918/files
  - new: https://git.openjdk.org/jdk/pull/14918/files/e165dc24..a8d472ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14918.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14918/head:pull/14918

PR: https://git.openjdk.org/jdk/pull/14918

From jpai at openjdk.org  Tue Jul 18 07:58:58 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 18 Jul 2023 07:58:58 GMT
Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6 [v3]
In-Reply-To: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
Message-ID: <03lsUFJ5QhNnuzzLmwbwH0-nOhehHUQRWVxvRYwwCTs=.ab7157e2-b075-4a06-9a51-9d1484765995@github.com>

> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229.
> 
> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  include -debug (alias) option in the deprecated log message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14918/files
  - new: https://git.openjdk.org/jdk/pull/14918/files/a8d472ad..e5472701

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14918.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14918/head:pull/14918

PR: https://git.openjdk.org/jdk/pull/14918

From jpai at openjdk.org  Tue Jul 18 08:11:04 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 18 Jul 2023 08:11:04 GMT
Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6 [v3]
In-Reply-To: <03lsUFJ5QhNnuzzLmwbwH0-nOhehHUQRWVxvRYwwCTs=.ab7157e2-b075-4a06-9a51-9d1484765995@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
 <03lsUFJ5QhNnuzzLmwbwH0-nOhehHUQRWVxvRYwwCTs=.ab7157e2-b075-4a06-9a51-9d1484765995@github.com>
Message-ID: <i2f3cbfD9csS_Vg4_N9zwsDHvaJtW_J8U1LZX0VFb-w=.2ec0daae-7d51-470c-8d34-32c41004b306@github.com>

On Tue, 18 Jul 2023 07:58:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229.
>> 
>> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include -debug (alias) option in the deprecated log message

Given that https://bugs.openjdk.org/browse/JDK-8227229 had more historical details about `-Xdebug` and `-debug`, I've updated this PR to link to that issue and also drafted CSR afresh https://bugs.openjdk.org/browse/JDK-8312220

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14918#issuecomment-1639725244

From rgiulietti at openjdk.org  Tue Jul 18 08:20:29 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 18 Jul 2023 08:20:29 GMT
Subject: RFR: 8302987: Add uniform and spatially equidistributed bounded
 double streams to RandomGenerator [v10]
In-Reply-To: <L11g-yXScgRfmSYFUxR7onC0h50Ox7fyqBnz17zIxH0=.890bf17f-4f58-419a-8102-777254ffa425@github.com>
References: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
 <X9t6_xr33svBkqZB_IKmfw4XQuo7VTQWwM6VLI0LgvM=.af9d703c-8583-4f1d-bb64-d67067807d33@github.com>
 <L11g-yXScgRfmSYFUxR7onC0h50Ox7fyqBnz17zIxH0=.890bf17f-4f58-419a-8102-777254ffa425@github.com>
Message-ID: <4ELX3wX52ppdJcYz-fNvlUMKngDsbV_e0NeKsvJFhmU=.f42045ed-ffe7-4170-ac7f-708cff85cb1e@github.com>

On Tue, 18 Jul 2023 02:54:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correction in comment.
>
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 398:
> 
>> 396:              * afforded by nextLong().
>> 397:              */
>> 398:             delta = nextUp(left) - left;
> 
> The delta computations are equivalent to some expression phrased in terms of an ulp (Math.ulp) of a the endpoint or a value adjacent to the endpoint. If the ulp method is not used for the computation, I suggest adding a comment noting the equivalence.

Here `left` is negative or `0.0`. What is needed is the distance to the next adjacent `double` in the direction of positive infinity. This is almost always the same as `Math.ulp(left)`, but not always.
For example, when `left` is `-1.0`, `delta` as computed here is half of `Math.ulp(left)`.

Analogously for the case covered by the `else` arm.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12719#discussion_r1266404939

From rgiulietti at openjdk.org  Tue Jul 18 09:16:14 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 18 Jul 2023 09:16:14 GMT
Subject: RFR: 8302987: Add uniform and spatially equidistributed bounded
 double streams to RandomGenerator [v11]
In-Reply-To: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
References: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
Message-ID: <Ygi6GRv6KcNg_lkPAL4fimKR-Bu2rmVNqb6L3QFmQ3s=.ef6db11a-3a6b-40ed-8366-efffb42454d0@github.com>

> 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.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Added the reason for not using Math.ulp() to compute delta.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12719/files
  - new: https://git.openjdk.org/jdk/pull/12719/files/80e49d41..390ad6b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=09-10

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12719.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12719/head:pull/12719

PR: https://git.openjdk.org/jdk/pull/12719

From rgiulietti at openjdk.org  Tue Jul 18 09:33:49 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 18 Jul 2023 09:33:49 GMT
Subject: RFR: 8302987: Add uniform and spatially equidistributed bounded
 double streams to RandomGenerator [v12]
In-Reply-To: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
References: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
Message-ID: <sRsXYXXJtoWNwbpeGqvf71HALmGpvsCDFeqd5pA5hGk=.052fd23b-f2e4-4db9-b392-fd142517ba6b@github.com>

> 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.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Made the comment about not using ulp a bit clearer.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12719/files
  - new: https://git.openjdk.org/jdk/pull/12719/files/390ad6b1..8fc7cfc6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=10-11

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12719.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12719/head:pull/12719

PR: https://git.openjdk.org/jdk/pull/12719

From alanb at openjdk.org  Tue Jul 18 11:04:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Jul 2023 11:04:18 GMT
Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6 [v3]
In-Reply-To: <03lsUFJ5QhNnuzzLmwbwH0-nOhehHUQRWVxvRYwwCTs=.ab7157e2-b075-4a06-9a51-9d1484765995@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
 <03lsUFJ5QhNnuzzLmwbwH0-nOhehHUQRWVxvRYwwCTs=.ab7157e2-b075-4a06-9a51-9d1484765995@github.com>
Message-ID: <qyTiO48chZV5aiHXfyTfTvaTHpPZQzvLQlHpd05CF0w=.57037cf5-552b-448a-9ab4-f1a81f0d3881@github.com>

On Tue, 18 Jul 2023 07:58:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229.
>> 
>> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include -debug (alias) option in the deprecated log message

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 137:

> 135: \    -Xcheck:jni       perform additional checks for JNI functions\n\
> 136: \    -Xcomp            forces compilation of methods on first invocation\n\
> 137: \    -Xdebug           deprecated and may be removed in a future release.\n\

This drops "does nothing" so no longer clear that the option doesn't do anything. It could be changed to "does nothing; deprecated for removal in a future release". Alternatively maybe it would be better to just remove it from the -X output.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14918#discussion_r1266609817

From jpai at openjdk.org  Tue Jul 18 12:41:32 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 18 Jul 2023 12:41:32 GMT
Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6 [v4]
In-Reply-To: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
Message-ID: <54o5-4Raq5oX93gQrI_hfTjwiLVJGWzSBmE8VtTvK9g=.cb4c9df8-6a17-473f-9f47-6747303ba8fe@github.com>

> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229.
> 
> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Alan's suggestion for -Xdebug output

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14918/files
  - new: https://git.openjdk.org/jdk/pull/14918/files/e5472701..78498068

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14918.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14918/head:pull/14918

PR: https://git.openjdk.org/jdk/pull/14918

From jpai at openjdk.org  Tue Jul 18 12:41:32 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 18 Jul 2023 12:41:32 GMT
Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6 [v3]
In-Reply-To: <qyTiO48chZV5aiHXfyTfTvaTHpPZQzvLQlHpd05CF0w=.57037cf5-552b-448a-9ab4-f1a81f0d3881@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
 <03lsUFJ5QhNnuzzLmwbwH0-nOhehHUQRWVxvRYwwCTs=.ab7157e2-b075-4a06-9a51-9d1484765995@github.com>
 <qyTiO48chZV5aiHXfyTfTvaTHpPZQzvLQlHpd05CF0w=.57037cf5-552b-448a-9ab4-f1a81f0d3881@github.com>
Message-ID: <U1FFkWs2jlPozd3MZqNkj8YRKD5HVP5dugcDK4M7hbk=.8445bbe0-fcb9-4586-8fbc-ab4197c66005@github.com>

On Tue, 18 Jul 2023 11:01:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   include -debug (alias) option in the deprecated log message
>
> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 137:
> 
>> 135: \    -Xcheck:jni       perform additional checks for JNI functions\n\
>> 136: \    -Xcomp            forces compilation of methods on first invocation\n\
>> 137: \    -Xdebug           deprecated and may be removed in a future release.\n\
> 
> This drops "does nothing" so no longer clear that the option doesn't do anything. It could be changed to "does nothing; deprecated for removal in a future release". Alternatively maybe it would be better to just remove it from the -X output.

Hello Alan, I updated the PR to use your suggested wording. I thought it's of no harm to let it be present in the -X output until we actually remove it (soon).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14918#discussion_r1266705837

From duke at openjdk.org  Tue Jul 18 13:13:23 2023
From: duke at openjdk.org (Cristian Vat)
Date: Tue, 18 Jul 2023 13:13:23 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array
Message-ID: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>

Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.

Original clamping to 10 possibly due to documented behavior from javadoc: 
"In this class, \1 through \9 are always interpreted as back references, "

Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
Added a match failure condition in Pattern that fixes failing tests.

As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"

A group that does not exist in the original Pattern can never match so neither can a backref to that group.
If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
So a group index outside groups array length must never match.

-------------

Commit messages:
 - 8311939: Excessive allocation of Matcher.groups array

Changes: https://git.openjdk.org/jdk/pull/14894/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14894&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311939
  Stats: 9 lines in 2 files changed: 7 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14894/head:pull/14894

PR: https://git.openjdk.org/jdk/pull/14894

From rriggs at openjdk.org  Tue Jul 18 13:14:07 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 18 Jul 2023 13:14:07 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v5]
In-Reply-To: <BTRuTjgqXbrydam6sjfVRIWXnwApuM-z6fS1s6drDOU=.0ae94845-0b94-45d6-8404-bc0e32ac2ebe@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <BTRuTjgqXbrydam6sjfVRIWXnwApuM-z6fS1s6drDOU=.0ae94845-0b94-45d6-8404-bc0e32ac2ebe@github.com>
Message-ID: <y__ota3cDIHkA3TOZP46MZzB2wC-nHTkN85lCxtwUrs=.ec64c5ba-f80f-44ee-9797-ccd3b782063e@github.com>

On Mon, 17 Jul 2023 23:33:37 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in the java.text area.
>> 
>> * Some changes to `equals` and `hashCode` are refactoring rather than modernization. Such changes can be as trivial as rearranging, adding, or commenting checks.
>> 
>> * java.text area contains more classes whose `equals` and `hashCode` could be simplified; for example: sun.text.CompactByteArray or java.text.DigitList. However, I found no evidence of `equals` and `hashCode` in those classes being used in source or tests. Since writing new tests in this case seems unreasonable, I **excluded** those classes from this PR.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14752#pullrequestreview-1535005629

From liach at openjdk.org  Tue Jul 18 15:09:01 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Jul 2023 15:09:01 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v5]
In-Reply-To: <RsQy_4b8SwkUkk-z2h_1GFv6tPb0aCp6eTsehuQbAN8=.42b4c7a6-c973-472c-9a63-64e969a37e62@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <G3gGbJEH4WMS0LOWaNFelqL0gfoeflEhi61xNSNASy8=.c6acd39a-8ecd-4b6d-a581-78e4d96158e5@github.com>
 <RsQy_4b8SwkUkk-z2h_1GFv6tPb0aCp6eTsehuQbAN8=.42b4c7a6-c973-472c-9a63-64e969a37e62@github.com>
Message-ID: <lk1-KXNxOOpn3jY8lJvlP8D1RKiTkGGHcflbbzRLzCk=.6c69500d-a7cc-4aa5-815a-bfd991586bed@github.com>

On Thu, 6 Jul 2023 19:58:09 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add flag for reference queue type
>
> src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 132:
> 
>> 130:      */
>> 131:     public static <K, V> ReferencedKeyMap<K, V>
>> 132:     create(boolean isSoft, boolean useNativeQueue, Supplier<Map<ReferenceKey<K>, V>> supplier) {
> 
> I suggest to keep the previous `create(boolean isSoft, Supplier supplier)`  factory method that defaults to non-native reference queue, which is commonly used.   Only `MethodType` needs to use native reference queue.

Mandy: The no-`NativeQueue` version is already implemented above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1266908707

From liach at openjdk.org  Tue Jul 18 15:09:06 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Jul 2023 15:09:06 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v8]
In-Reply-To: <6fpeJ9q0R9LTBsv9ynVXmUtuP9o0b4fVgbyGR2iZ59E=.0fe636ac-df43-4397-87d2-b9ea0ba1585a@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <6fpeJ9q0R9LTBsv9ynVXmUtuP9o0b4fVgbyGR2iZ59E=.0fe636ac-df43-4397-87d2-b9ea0ba1585a@github.com>
Message-ID: <JNvuYjnH3o3VIIZ1Hdi5Rt2agjsqTUGwIRDZCLAp-GI=.52241109-82c9-4fa3-825b-3bb8b0976102@github.com>

On Thu, 13 Jul 2023 15:07:35 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:
> 
>   Update test to check for gc.

src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 354:

> 352:      */
> 353:     @SuppressWarnings("unchecked")
> 354:     K intern(K key) {

Should this be made static for type safety?

public static <E> E intern(ReferencedKeyMap<E, ReferenceKey<E>> m, E key)

which will save the 2 unchecked casts at `get` and `putIfAbsent`.


In addition, it would be nice if we can compute a more proper key for interning than the query key, via a binary operator; for example, we want a `String` to go through `String::intern`, or a `BaseLocale` to format its language, script, region, and variant and intern them (see https://github.com/openjdk/jdk/pull/14404/files#diff-c0e20847ffb6e33bcf62ff52b1b5b4c8a85520ca101a6f54128d97289cd8c2f9R169-R172)

src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 71:

> 69:  * @param <T> the type of elements maintained by this set
> 70:  */
> 71: public class ReferencedKeySet<T> extends AbstractSet<T> {

Suggestion:

public final class ReferencedKeySet<T> extends AbstractSet<T> {

Make this class final.

src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 97:

> 95:      * @param <E> the type of elements maintained by this set
> 96:      */
> 97:     public static <E> jdk.internal.util.ReferencedKeySet<E>

Suggestion:

    public static <E> ReferencedKeySet<E>

src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 185:

> 183:      * @return the old element if present, otherwise, the new element
> 184:      */
> 185:     public T intern(T e) {

I would like to see an additional `T intern(T e, UnaryOperator<T> internFunction)`, where the `internFunction` behaves like `LocalObjectCache::normalizeKey`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1266902706
PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1266911305
PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1266897522
PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1266914091

From lancea at openjdk.org  Tue Jul 18 15:15:19 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Jul 2023 15:15:19 GMT
Subject: RFR: 8311188: Simplify and modernize equals and hashCode in
 java.text [v5]
In-Reply-To: <BTRuTjgqXbrydam6sjfVRIWXnwApuM-z6fS1s6drDOU=.0ae94845-0b94-45d6-8404-bc0e32ac2ebe@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <BTRuTjgqXbrydam6sjfVRIWXnwApuM-z6fS1s6drDOU=.0ae94845-0b94-45d6-8404-bc0e32ac2ebe@github.com>
Message-ID: <iTUVp7NoFNBczhWA62V2GYAnOxjMjaercHleXWLW1y0=.e0917721-3247-41c9-b8f9-7641d47c37d7@github.com>

On Mon, 17 Jul 2023 23:33:37 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in the java.text area.
>> 
>> * Some changes to `equals` and `hashCode` are refactoring rather than modernization. Such changes can be as trivial as rearranging, adding, or commenting checks.
>> 
>> * java.text area contains more classes whose `equals` and `hashCode` could be simplified; for example: sun.text.CompactByteArray or java.text.DigitList. However, I found no evidence of `equals` and `hashCode` in those classes being used in source or tests. Since writing new tests in this case seems unreasonable, I **excluded** those classes from this PR.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14752#pullrequestreview-1535273279

From prappo at openjdk.org  Tue Jul 18 15:15:20 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 18 Jul 2023 15:15:20 GMT
Subject: Integrated: 8311188: Simplify and modernize equals and hashCode in
 java.text
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <_hmWVhx75Ez5ZgquoNaMfcmYkBepIaBncxzTK5V1ysU=.91e17faa-d74e-43b7-a8f3-4783fab5fe0f@github.com>

On Mon, 3 Jul 2023 11:12:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in the java.text area.
> 
> * Some changes to `equals` and `hashCode` are refactoring rather than modernization. Such changes can be as trivial as rearranging, adding, or commenting checks.
> 
> * java.text area contains more classes whose `equals` and `hashCode` could be simplified; for example: sun.text.CompactByteArray or java.text.DigitList. However, I found no evidence of `equals` and `hashCode` in those classes being used in source or tests. Since writing new tests in this case seems unreasonable, I **excluded** those classes from this PR.

This pull request has now been integrated.

Changeset: 1dfb0fb3
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1dfb0fb3e22c3616fdfa3a8249be526c44dbe890
Stats:     127 lines in 15 files changed: 29 ins; 55 del; 43 mod

8311188: Simplify and modernize equals and hashCode in java.text

Reviewed-by: lancea, naoto, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/14752

From liach at openjdk.org  Tue Jul 18 15:19:27 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Jul 2023 15:19:27 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v4]
In-Reply-To: <_8ueUfakl3XtyZ-dDW36gd-fUokkoChbmBDqHvkSNDg=.ee46d7e2-8a11-4190-984e-31bb506d856a@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <_8ueUfakl3XtyZ-dDW36gd-fUokkoChbmBDqHvkSNDg=.ee46d7e2-8a11-4190-984e-31bb506d856a@github.com>
Message-ID: <iw4XJHZ-rph9bYQ9dzUQm-hL2ZFsNDHPJZQjO9zB5Wo=.3e4e6e7e-0134-4e49-97c1-b59b7e6c4b3e@github.com>

On Thu, 29 Jun 2023 19:28:05 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 with a new target base 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/87a0fc50...870ec1fe

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 167:

> 165:         // can subsequently be used by the Locale instance which
> 166:         // guarantees the locale components are properly cased/interned.
> 167:         return CACHE.computeIfAbsent(new BaseLocale(language, script, region, variant),

This `computeIfAbsent` will store the non-normalized base locale as a soft key in the cache, which is undesirable. I have commented on the base patch https://github.com/openjdk/jdk/pull/14684#discussion_r1266914091 to support distinct keys for querying and storing like those in the old `LocalObjectCache`, and we can then simply use a `ReferenceKeySet` for the cache.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1266923844

From asemenyuk at openjdk.org  Tue Jul 18 15:21:04 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 18 Jul 2023 15:21:04 GMT
Subject: RFR: 8311631: When multiple users run
 tools/jpackage/share/LicenseTest.java,
 Permission denied for writing /var/tmp/*.files [v2]
In-Reply-To: <tlogilGhgOPDCmKldD1UWGwoRqi3TYNe3tmgKG2D8EY=.0d789b18-6aac-4102-859d-653aab1cbcdf@github.com>
References: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
 <tlogilGhgOPDCmKldD1UWGwoRqi3TYNe3tmgKG2D8EY=.0d789b18-6aac-4102-859d-653aab1cbcdf@github.com>
Message-ID: <01xtjuaXKu7hRzhjr_kvqxEn3OA0zn07ZZnZ3U51LsY=.1ddd9e57-0928-4a6d-bda1-bf1976fccc0c@github.com>

On Thu, 13 Jul 2023 07:27:22 GMT, yaqsun <duke at openjdk.org> wrote:

>> The prerequisite is to install the rpmbuild command, when multiple users switch to write /var/tmp/*.files will have the permission forbidden.
>
> yaqsun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8311631: When multiple users run tools/jpackage/share/LicenseTest.java, Permission denied for writing /var/tmp/*.files

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14802#pullrequestreview-1535290149

From alanb at openjdk.org  Tue Jul 18 15:25:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Jul 2023 15:25:05 GMT
Subject: RFR: 8308591: JLine as the default Console provider [v5]
In-Reply-To: <UaaPqwRl0njNVVWBohl1gngkiA1q0L5P4Oum8fyi9rI=.a0c698bc-ef05-4f81-bd9c-d2cd7a3bc19c@github.com>
References: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
 <UaaPqwRl0njNVVWBohl1gngkiA1q0L5P4Oum8fyi9rI=.a0c698bc-ef05-4f81-bd9c-d2cd7a3bc19c@github.com>
Message-ID: <dMJkxEjF1vu7tYMzfutc2_bhSVIgEa8Tb-Iy1vPYQZI=.ba2e7a93-1a9e-4a1d-89b7-d97f201b654d@github.com>

On Mon, 17 Jul 2023 20:46:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to bring the JLine-based Console implementation as the default, which was the initial intention in [JDK-8295803](https://bugs.openjdk.org/browse/JDK-8295803). A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   `true`

src/java.base/share/classes/java/io/Console.java line 354:

> 352:      * character devices are available to the {@code Console}. Otherwise it could
> 353:      * mean that the implementation of the {@code Console} may simulate those
> 354:      * devices within.

The implNote helps as this is a difficult method to specify in a platform independent way.

The class description uses "interactive command line" and  "will typically be connected to the keyboard and display" and maybe we could re-use that here. Here's a suggestion for the second paragraph:

"This method returns true if the console device, associated with the current Java virtual machine, is a terminal, typically an interactive command line connected to a keyboard and display."

I don't have any other comments on the implementation changes, they look fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14271#discussion_r1266938060

From asemenyuk at openjdk.org  Tue Jul 18 15:37:12 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 18 Jul 2023 15:37:12 GMT
Subject: RFR: JDK-8309032: jpackage does not work for module projects
 unless --module-path is specified
In-Reply-To: <ZHCWcpSLF1khyvrydxW8JarYKgYOj3B-9nnBVElWVpc=.4a345b50-7213-4e30-969e-280e3cd11575@github.com>
References: <ZHCWcpSLF1khyvrydxW8JarYKgYOj3B-9nnBVElWVpc=.4a345b50-7213-4e30-969e-280e3cd11575@github.com>
Message-ID: <UIjn_K4ndSbmM-oNcPWT8x8VLNPScLerLzOc0GKNeJI=.35945e86-9a59-42be-928b-40f005acaffc@github.com>

On Tue, 11 Jul 2023 23:47:30 GMT, airsquared <duke at openjdk.org> wrote:

> [JDK-8309032](https://bugs.openjdk.org/browse/JDK-8309032), [JDK-8306488](https://bugs.openjdk.org/browse/JDK-8306488)

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14840#pullrequestreview-1535324178

From mchung at openjdk.org  Tue Jul 18 16:11:20 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 18 Jul 2023 16:11:20 GMT
Subject: Integrated: JDK-8310814: Clarify the targetName parameter of
 Lookup::findClass
In-Reply-To: <4vRzMGX2j9h8rKnHa0tPrU8CKgJxD8gkETl56W5mW28=.91aae64d-1041-4e1c-99bd-97d7574be3b1@github.com>
References: <4vRzMGX2j9h8rKnHa0tPrU8CKgJxD8gkETl56W5mW28=.91aae64d-1041-4e1c-99bd-97d7574be3b1@github.com>
Message-ID: <GnQTyIlHPprJefIiDw4RfMNBw1yopD9O-Cnk0TiY4x8=.6631f0f0-1f68-4ad9-ae99-a929a5da1cb1@github.com>

On Mon, 26 Jun 2023 21:34:40 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.

This pull request has now been integrated.

Changeset: b4dce0d6
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b4dce0d62479c2494c02570a60319cb1a5932940
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8310814: Clarify the targetName parameter of Lookup::findClass

Reviewed-by: liach, rriggs, bchristi

-------------

PR: https://git.openjdk.org/jdk/pull/14668

From mchung at openjdk.org  Tue Jul 18 16:25:06 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 18 Jul 2023 16:25:06 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v5]
In-Reply-To: <lk1-KXNxOOpn3jY8lJvlP8D1RKiTkGGHcflbbzRLzCk=.6c69500d-a7cc-4aa5-815a-bfd991586bed@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <G3gGbJEH4WMS0LOWaNFelqL0gfoeflEhi61xNSNASy8=.c6acd39a-8ecd-4b6d-a581-78e4d96158e5@github.com>
 <RsQy_4b8SwkUkk-z2h_1GFv6tPb0aCp6eTsehuQbAN8=.42b4c7a6-c973-472c-9a63-64e969a37e62@github.com>
 <lk1-KXNxOOpn3jY8lJvlP8D1RKiTkGGHcflbbzRLzCk=.6c69500d-a7cc-4aa5-815a-bfd991586bed@github.com>
Message-ID: <D6OMFTtn165mLjad9eMfF-Ho5lFOdXo5YgRxjHU27VQ=.aea41e6a-df23-4e94-bf92-8267c3a58cf9@github.com>

On Tue, 18 Jul 2023 15:01:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 132:
>> 
>>> 130:      */
>>> 131:     public static <K, V> ReferencedKeyMap<K, V>
>>> 132:     create(boolean isSoft, boolean useNativeQueue, Supplier<Map<ReferenceKey<K>, V>> supplier) {
>> 
>> I suggest to keep the previous `create(boolean isSoft, Supplier supplier)`  factory method that defaults to non-native reference queue, which is commonly used.   Only `MethodType` needs to use native reference queue.
>
> Mandy: The no-`NativeQueue` version is already implemented above.

Yes Jim made the change per this review feedback - see [8eff918](https://github.com/openjdk/jdk/pull/14684/commits/8eff91836f98cb33164046f2304185f11df12609)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1267020337

From mchung at openjdk.org  Tue Jul 18 16:32:39 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 18 Jul 2023 16:32:39 GMT
Subject: [jdk21] RFR: 8310814: Clarify the targetName parameter of
 Lookup::findClass
Message-ID: <ZUqAZv4i7Ur0EyRy53aPw_2G43gAouWViW3fvMcuFfU=.dbf85be1-6917-4a3a-8a2f-f56d1c34ae38@github.com>

Hi all,

This pull request contains a backport of commit [b4dce0d6](https://github.com/openjdk/jdk/commit/b4dce0d62479c2494c02570a60319cb1a5932940) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Mandy Chung on 18 Jul 2023 and was reviewed by Chen Liang, Roger Riggs and Brent Christian.

Thanks!

-------------

Commit messages:
 - Backport b4dce0d62479c2494c02570a60319cb1a5932940

Changes: https://git.openjdk.org/jdk21/pull/136/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=136&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310814
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk21/pull/136.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/136/head:pull/136

PR: https://git.openjdk.org/jdk21/pull/136

From darcy at openjdk.org  Tue Jul 18 16:39:11 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Jul 2023 16:39:11 GMT
Subject: [jdk21] RFR: 8310814: Clarify the targetName parameter of
 Lookup::findClass
In-Reply-To: <ZUqAZv4i7Ur0EyRy53aPw_2G43gAouWViW3fvMcuFfU=.dbf85be1-6917-4a3a-8a2f-f56d1c34ae38@github.com>
References: <ZUqAZv4i7Ur0EyRy53aPw_2G43gAouWViW3fvMcuFfU=.dbf85be1-6917-4a3a-8a2f-f56d1c34ae38@github.com>
Message-ID: <iIFGpp2Dt-23NmMHsVB2DGRD8QPo1ogQCzZLdPHReF8=.c59d6fa2-55aa-4b49-b5f5-efdc064f3acf@github.com>

On Tue, 18 Jul 2023 16:25:17 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [b4dce0d6](https://github.com/openjdk/jdk/commit/b4dce0d62479c2494c02570a60319cb1a5932940) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mandy Chung on 18 Jul 2023 and was reviewed by Chen Liang, Roger Riggs and Brent Christian.
> 
> Thanks!

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/136#pullrequestreview-1535468097

From naoto at openjdk.org  Tue Jul 18 16:41:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Jul 2023 16:41:26 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v4]
In-Reply-To: <iw4XJHZ-rph9bYQ9dzUQm-hL2ZFsNDHPJZQjO9zB5Wo=.3e4e6e7e-0134-4e49-97c1-b59b7e6c4b3e@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <_8ueUfakl3XtyZ-dDW36gd-fUokkoChbmBDqHvkSNDg=.ee46d7e2-8a11-4190-984e-31bb506d856a@github.com>
 <iw4XJHZ-rph9bYQ9dzUQm-hL2ZFsNDHPJZQjO9zB5Wo=.3e4e6e7e-0134-4e49-97c1-b59b7e6c4b3e@github.com>
Message-ID: <am8UPIo0dLThcwUsN2yb-6ErbmQidt0yyQfjDyvKkh4=.c1f0717e-0afa-45c9-8ba9-7a75a5691277@github.com>

On Tue, 18 Jul 2023 15:11:04 GMT, Chen Liang <liach 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 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/b7933f62...870ec1fe
>
> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 167:
> 
>> 165:         // can subsequently be used by the Locale instance which
>> 166:         // guarantees the locale components are properly cased/interned.
>> 167:         return CACHE.computeIfAbsent(new BaseLocale(language, script, region, variant),
> 
> This `computeIfAbsent` will store the non-normalized base locale as a soft key in the cache, which is undesirable. I have commented on the base patch https://github.com/openjdk/jdk/pull/14684#discussion_r1266914091 to support distinct keys for querying and storing like those in the old `LocalObjectCache`, and we can then simply use a `ReferenceKeySet` for the cache.

The reason I used non-normalized base locale as the key was that normalizing (interning) was slower than comparing the key. I would have to double check, and see if the distinct normalized key is faster.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1267037551

From mchung at openjdk.org  Tue Jul 18 16:52:21 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 18 Jul 2023 16:52:21 GMT
Subject: [jdk21] Integrated: 8310814: Clarify the targetName parameter of
 Lookup::findClass
In-Reply-To: <ZUqAZv4i7Ur0EyRy53aPw_2G43gAouWViW3fvMcuFfU=.dbf85be1-6917-4a3a-8a2f-f56d1c34ae38@github.com>
References: <ZUqAZv4i7Ur0EyRy53aPw_2G43gAouWViW3fvMcuFfU=.dbf85be1-6917-4a3a-8a2f-f56d1c34ae38@github.com>
Message-ID: <MaSol0Zly11qivgabdzSB-E8Se0InjANteLKU863y5M=.da5cbd62-5fa2-4550-a872-12a870a1d898@github.com>

On Tue, 18 Jul 2023 16:25:17 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [b4dce0d6](https://github.com/openjdk/jdk/commit/b4dce0d62479c2494c02570a60319cb1a5932940) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mandy Chung on 18 Jul 2023 and was reviewed by Chen Liang, Roger Riggs and Brent Christian.
> 
> Thanks!

This pull request has now been integrated.

Changeset: b8eddaba
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/b8eddabac0c0e256ad877931cfbe2cdfc1fc79aa
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8310814: Clarify the targetName parameter of Lookup::findClass

Reviewed-by: darcy
Backport-of: b4dce0d62479c2494c02570a60319cb1a5932940

-------------

PR: https://git.openjdk.org/jdk21/pull/136

From alanb at openjdk.org  Tue Jul 18 16:56:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Jul 2023 16:56:15 GMT
Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6 [v4]
In-Reply-To: <54o5-4Raq5oX93gQrI_hfTjwiLVJGWzSBmE8VtTvK9g=.cb4c9df8-6a17-473f-9f47-6747303ba8fe@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
 <54o5-4Raq5oX93gQrI_hfTjwiLVJGWzSBmE8VtTvK9g=.cb4c9df8-6a17-473f-9f47-6747303ba8fe@github.com>
Message-ID: <rUsdg41lf8zV6Xysblo1fq9RfMSHJKAFTy0mNq9GUUM=.fbb8e607-0959-4e21-8771-695a5a0bd320@github.com>

On Tue, 18 Jul 2023 12:41:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229.
>> 
>> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's suggestion for -Xdebug output

I think ParseArguments (in libjli/java.c) could be changed so that it doesn't translate -debug to -Xdebug, instead it can print a warning, like it does for -Xfuture. The reason is -debug is a java launcher option, it's not known to the VM and means that Arguments::parse_each_vm_init_arg doesn't need to mention -debug when it warns about -Xdebug.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14918#issuecomment-1640592323

From naoto at openjdk.org  Tue Jul 18 17:09:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Jul 2023 17:09:05 GMT
Subject: RFR: 8308591: JLine as the default Console provider [v5]
In-Reply-To: <dMJkxEjF1vu7tYMzfutc2_bhSVIgEa8Tb-Iy1vPYQZI=.ba2e7a93-1a9e-4a1d-89b7-d97f201b654d@github.com>
References: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
 <UaaPqwRl0njNVVWBohl1gngkiA1q0L5P4Oum8fyi9rI=.a0c698bc-ef05-4f81-bd9c-d2cd7a3bc19c@github.com>
 <dMJkxEjF1vu7tYMzfutc2_bhSVIgEa8Tb-Iy1vPYQZI=.ba2e7a93-1a9e-4a1d-89b7-d97f201b654d@github.com>
Message-ID: <b7PiLDr4ZN-oM0ZkXplibEDh9mnho1YG3n8S5X2_QvU=.0a22d422-e519-4db3-8c42-3dae40a9f3ad@github.com>

On Tue, 18 Jul 2023 15:21:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   `true`
>
> src/java.base/share/classes/java/io/Console.java line 354:
> 
>> 352:      * character devices are available to the {@code Console}. Otherwise it could
>> 353:      * mean that the implementation of the {@code Console} may simulate those
>> 354:      * devices within.
> 
> The implNote helps as this is a difficult method to specify in a platform independent way.
> 
> The class description uses "interactive command line" and  "will typically be connected to the keyboard and display" and maybe we could re-use that here. Here's a suggestion for the second paragraph:
> 
> "This method returns true if the console device, associated with the current Java virtual machine, is a terminal, typically an interactive command line connected to a keyboard and display."
> 
> I don't have any other comments on the implementation changes, they look fine.

Thanks. Replaced the second paragraph with your suggested sentence.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14271#discussion_r1267070257

From naoto at openjdk.org  Tue Jul 18 17:08:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Jul 2023 17:08:34 GMT
Subject: RFR: 8308591: JLine as the default Console provider [v6]
In-Reply-To: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
References: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
Message-ID: <E5aVsPvQsvoVLVhAUuaZyyHbu33OuWkplpP8SfresH0=.034792a1-0c6a-46c9-9a4c-cda96b8f0e3c@github.com>

> This is to bring the JLine-based Console implementation as the default, which was the initial intention in [JDK-8295803](https://bugs.openjdk.org/browse/JDK-8295803). A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:

 - @code
 - Reworded the second paragraph of the method description

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14271/files
  - new: https://git.openjdk.org/jdk/pull/14271/files/df5805a0..7065f3a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14271&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14271&range=04-05

  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14271/head:pull/14271

PR: https://git.openjdk.org/jdk/pull/14271

From darcy at openjdk.org  Tue Jul 18 17:26:39 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Jul 2023 17:26:39 GMT
Subject: RFR: JDK-8312203: Improve specification of Array.newInstance
In-Reply-To: <HVMFCvpScrMMhxDsfTykfAUtKPb6VPoDvY6hEfqhIzc=.f79f6195-891c-4735-a503-9fa8e3ef4b06@github.com>
References: <LtpWOTegDJATFzEXDXgv4TJ0S3eFiASN2TGuViSFgtA=.b224ceaa-1052-489a-8c31-132b853ae3e2@github.com>
 <HVMFCvpScrMMhxDsfTykfAUtKPb6VPoDvY6hEfqhIzc=.f79f6195-891c-4735-a503-9fa8e3ef4b06@github.com>
Message-ID: <2OgTfm0tVyp7YkEgdjX7aec9U_V8Gd-nqdpVYXWJUqg=.4b8d24c3-4a61-4ba2-bc6d-d7ae8a4b5ccf@github.com>

On Tue, 18 Jul 2023 05:05:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Change one overload of java.lang.reflect.Array.newInstance to have an `@implSpec` of calling the other method.
>> 
>> I choose not to use a snippet tag here is this code is semantically only one line and doesn't need to be cut-and-pasted.
>> 
>> As adding an `@implSpec` is technically a (small) specification change, please also review the CSR:
>> 
>> https://bugs.openjdk.org/browse/JDK-8312208
>
> src/java.base/share/classes/java/lang/reflect/Array.java line 56:
> 
>> 54:      * as follows:
>> 55:      * <blockquote>
>> 56:      * {@code Array.newInstance(componentType, new int[]{length});}
> 
> Snippet is not just for cut-and-paste; it can also save us a `<blockquote>` tag as well, and syntax highlight support in IDEs.

With the concession that more of the `<blockquote><pre>...</pre></blockquote>` blocks still in the JDK should be converted to snippets, I don't think that *all* of them should necessarily be converted.

Having done a few snippet conversions myself (JDK-8287838, JDK-8289399, JDK-8289775, JDK-8308987), I don't think this particular one is justified as a snippet.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14917#discussion_r1267096100

From mchung at openjdk.org  Tue Jul 18 17:30:25 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 18 Jul 2023 17:30:25 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v26]
In-Reply-To: <hJ3dBq7oaRN8OtWTQS12mnGoAav0NlIuoezGYObY3b4=.624abdc9-d002-4589-933a-c43dbc474158@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <hJ3dBq7oaRN8OtWTQS12mnGoAav0NlIuoezGYObY3b4=.624abdc9-d002-4589-933a-c43dbc474158@github.com>
Message-ID: <FyVTAGqIFDKg3ONVgH9CgPBgD2KY6XEW46miTGt-55s=.128b77c4-549c-4212-a9fd-e7f42959b461@github.com>

On Tue, 18 Jul 2023 01:57:56 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 54 commits:
> 
>  - Review class loader check, restore hidden class rejection spec
>  - Merge branch 'master' into explore/mhp-iface
>  - Review changees
>  - Fix the lazy test, thanks Jorn Vernee!
>  - Clean up impl comment, reorganize tests; weak ref broken
>  - Merge branch 'master' into explore/mhp-iface
>  - Fix broken null behaviors
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'mh-proxies' of https://github.com/mlchung/jdk into explore/mhp-iface
>  - store a WeakReference holder in the class value
>  - ... and 44 more: https://git.openjdk.org/jdk/compare/a53345ad...a12fba06

I think applications unlikely depend on the old implementation of dynamic proxies.   A release note may serve as a good documentation in case any application observes the performance difference because the hidden classes are GC'ed.

> However, I think I might be able to upgrade asInterfaceInstance to accept protected abstract classes with a single public/protected abstract method(s) and a no-arg public/protected constructor, like ClassValue. If that's the case, do we still require a release note for this one, or do we defer and merge the notes?

This is a separate issue and should not combine with this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1640660342

From bpb at openjdk.org  Tue Jul 18 17:33:08 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 18 Jul 2023 17:33:08 GMT
Subject: RFR: JDK-8312203: Improve specification of Array.newInstance
In-Reply-To: <LtpWOTegDJATFzEXDXgv4TJ0S3eFiASN2TGuViSFgtA=.b224ceaa-1052-489a-8c31-132b853ae3e2@github.com>
References: <LtpWOTegDJATFzEXDXgv4TJ0S3eFiASN2TGuViSFgtA=.b224ceaa-1052-489a-8c31-132b853ae3e2@github.com>
Message-ID: <PKm49SDGnjYglvhJnoRYOb95fd1l8zB9M4q3gMJBoJw=.5efd5972-87d5-44d2-ba28-de725e4b87d2@github.com>

On Tue, 18 Jul 2023 04:42:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Change one overload of java.lang.reflect.Array.newInstance to have an `@implSpec` of calling the other method.
> 
> I choose not to use a snippet tag here is this code is semantically only one line and doesn't need to be cut-and-pasted.
> 
> As adding an `@implSpec` is technically a (small) specification change, please also review the CSR:
> 
> https://bugs.openjdk.org/browse/JDK-8312208

CSR and PR look fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14917#pullrequestreview-1535584529

From alanb at openjdk.org  Tue Jul 18 17:36:37 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Jul 2023 17:36:37 GMT
Subject: RFR: 8308591: JLine as the default Console provider [v6]
In-Reply-To: <E5aVsPvQsvoVLVhAUuaZyyHbu33OuWkplpP8SfresH0=.034792a1-0c6a-46c9-9a4c-cda96b8f0e3c@github.com>
References: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
 <E5aVsPvQsvoVLVhAUuaZyyHbu33OuWkplpP8SfresH0=.034792a1-0c6a-46c9-9a4c-cda96b8f0e3c@github.com>
Message-ID: <mz88jojez5Myj2hctA-hQIQWw8Ydl_LhVzpPfC1OYho=.60c0cd9f-2050-40d4-8b18-eb9ab78f68f4@github.com>

On Tue, 18 Jul 2023 17:08:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to bring the JLine-based Console implementation as the default, which was the initial intention in [JDK-8295803](https://bugs.openjdk.org/browse/JDK-8295803). A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - @code
>  - Reworded the second paragraph of the method description

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14271#pullrequestreview-1535589025

From mchung at openjdk.org  Tue Jul 18 17:49:42 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 18 Jul 2023 17:49:42 GMT
Subject: RFR: JDK-8312203: Improve specification of Array.newInstance
In-Reply-To: <LtpWOTegDJATFzEXDXgv4TJ0S3eFiASN2TGuViSFgtA=.b224ceaa-1052-489a-8c31-132b853ae3e2@github.com>
References: <LtpWOTegDJATFzEXDXgv4TJ0S3eFiASN2TGuViSFgtA=.b224ceaa-1052-489a-8c31-132b853ae3e2@github.com>
Message-ID: <S8sMxQbgVI7XaE3eocmOhYLG6pnkKkwYl0fo9VazNKc=.9b67b2cd-db69-475b-9d4b-2d955f3ddd00@github.com>

On Tue, 18 Jul 2023 04:42:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Change one overload of java.lang.reflect.Array.newInstance to have an `@implSpec` of calling the other method.
> 
> I choose not to use a snippet tag here is this code is semantically only one line and doesn't need to be cut-and-pasted.
> 
> As adding an `@implSpec` is technically a (small) specification change, please also review the CSR:
> 
> https://bugs.openjdk.org/browse/JDK-8312208

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14917#pullrequestreview-1535607485

From almatvee at openjdk.org  Tue Jul 18 19:59:41 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 18 Jul 2023 19:59:41 GMT
Subject: RFR: 8311631: When multiple users run
 tools/jpackage/share/LicenseTest.java,
 Permission denied for writing /var/tmp/*.files [v2]
In-Reply-To: <tlogilGhgOPDCmKldD1UWGwoRqi3TYNe3tmgKG2D8EY=.0d789b18-6aac-4102-859d-653aab1cbcdf@github.com>
References: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
 <tlogilGhgOPDCmKldD1UWGwoRqi3TYNe3tmgKG2D8EY=.0d789b18-6aac-4102-859d-653aab1cbcdf@github.com>
Message-ID: <FeUWcIO1KmxSXNIQrnLI65ksXFlKNMEyuORWUQc-5ck=.3a9118c6-0c02-4bec-a986-f10fe90303ad@github.com>

On Thu, 13 Jul 2023 07:27:22 GMT, yaqsun <duke at openjdk.org> wrote:

>> The prerequisite is to install the rpmbuild command, when multiple users switch to write /var/tmp/*.files will have the permission forbidden.
>
> yaqsun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8311631: When multiple users run tools/jpackage/share/LicenseTest.java, Permission denied for writing /var/tmp/*.files

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14802#pullrequestreview-1535814977

From jlu at openjdk.org  Tue Jul 18 20:48:13 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 18 Jul 2023 20:48:13 GMT
Subject: RFR: 8039165: [Doc] MessageFormat null locale generates
 NullPointerException [v2]
In-Reply-To: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
Message-ID: <yUwg4u4-pbTS8osxbRBNOkDfm2KfX1OURICTJQRh05U=.a595371c-8939-436e-8e6a-5a725cbf5277@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8312197) which updates the javadoc for the constructor of MessageFormat regarding a `null` locale,
> 
> `MessageFormat` when created with a `null` locale may throw a `NullPointerException` either during the object creation, or later when `format()` is called by the `MessageFormat` object (test file has examples of both). This change updates the specification of MessageFormat to make this apparent. The wording is specifically chosen as 'may throw' since whether an NPE is thrown depends on the subformat used by MessageFormat (see test example of construction with null locale and no exception thrown).
> 
> The test for this change was merged with `Bug6481179.java` into `MessageFormatExceptions.java` (As they both test exceptions). In addition, some other exception testing regarding MessageFormat was added.
> 
> Thanks

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Slight wording adjustment
 - Review: Explicitly declare when NPE thrown instead of 'may'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14911/files
  - new: https://git.openjdk.org/jdk/pull/14911/files/05ac9193..4092e3ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14911&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14911&range=00-01

  Stats: 14 lines in 2 files changed: 10 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14911/head:pull/14911

PR: https://git.openjdk.org/jdk/pull/14911

From jlu at openjdk.org  Tue Jul 18 20:59:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 18 Jul 2023 20:59:43 GMT
Subject: RFR: 8039165: [Doc] MessageFormat null locale generates
 NullPointerException [v2]
In-Reply-To: <19axlwyNhm52NXGVYT3UUHxQbz_GNai_DZtlOdomX9w=.2ec99ccd-7bd0-4591-80a4-85bd3632a32c@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
 <19axlwyNhm52NXGVYT3UUHxQbz_GNai_DZtlOdomX9w=.2ec99ccd-7bd0-4591-80a4-85bd3632a32c@github.com>
Message-ID: <C-fNc4s5q_E9LY-4LdNBHklGaEDsqfWKeqh7vn1GgU8=.daddeacc-abbc-4696-b8e6-48d314f6c98f@github.com>

On Mon, 17 Jul 2023 21:54:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Slight wording adjustment
>>  - Review: Explicitly declare when NPE thrown instead of 'may'
>
> src/java.base/share/classes/java/text/MessageFormat.java line 396:
> 
>> 394:      * {@code NullPointerException} if {@code locale} is {@code null}
>> 395:      * either during the creation of the {@code MessageFormat} object or later
>> 396:      * when {@code format()} is called by the constructed {@code MessageFormat} object.
> 
> It looks a bit vague as it contains `may`. I think it would be clearer if it explains a bit more, e.g., it throws NPE if any of the subformats require the locale, or along with those lines. Probably the same wording is needed at `format()` and other public methods that use the `locale` field.

The only other public methods that use `locale` are setLocale(), getLocale(), toString(), and equals(). In all of these cases I don't believe if a MessageFormat that was created with a null locale (and did not throw NPE) calls them, a NPE will occur in any case.

Thus I have updated the spec to not use 'may' and explicitly state NPE is thrown if a subformat is localized and needed by the MessageFormat.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14911#discussion_r1267298674

From naoto at openjdk.org  Tue Jul 18 22:15:43 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Jul 2023 22:15:43 GMT
Subject: RFR: 8039165: [Doc] MessageFormat null locale generates
 NullPointerException [v2]
In-Reply-To: <yUwg4u4-pbTS8osxbRBNOkDfm2KfX1OURICTJQRh05U=.a595371c-8939-436e-8e6a-5a725cbf5277@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
 <yUwg4u4-pbTS8osxbRBNOkDfm2KfX1OURICTJQRh05U=.a595371c-8939-436e-8e6a-5a725cbf5277@github.com>
Message-ID: <TkjfooL3oTp-53EAxHoltO3ln1VugGydMJb9zVKELMY=.fc04ca6e-16f2-43e6-921e-9989f0a35c06@github.com>

On Tue, 18 Jul 2023 20:48:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8312197) which updates the javadoc for the constructor of MessageFormat regarding a `null` locale,
>> 
>> `MessageFormat` when created with a `null` locale may throw a `NullPointerException` either during the object creation, or later when `format()` is called by the `MessageFormat` object (test file has examples of both). This change updates the specification of MessageFormat to make this apparent. The wording is specifically chosen as 'may throw' since whether an NPE is thrown depends on the subformat used by MessageFormat (see test example of construction with null locale and no exception thrown).
>> 
>> The test for this change was merged with `Bug6481179.java` into `MessageFormatExceptions.java` (As they both test exceptions). In addition, some other exception testing regarding MessageFormat was added.
>> 
>> Thanks
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Slight wording adjustment
>  - Review: Explicitly declare when NPE thrown instead of 'may'

src/java.base/share/classes/java/text/MessageFormat.java line 398:

> 396:      * when {@code format()} is called by the constructed {@code MessageFormat}
> 397:      * instance and the implementation utilizes a subformat that requires
> 398:      * localization.

Sorry for the nitpick, but since localization itself is not a requirement, `locale-dependent subformat` would read better to me. (and wherever `localized` is used)

src/java.base/share/classes/java/text/MessageFormat.java line 407:

> 405:      * @throws    NullPointerException This method throws a
> 406:      *            {@code NullPointerException} if {@code locale} is {@code null}
> 407:      *            and a localized subformat is used.

NPE throws tags should be combined. Applies to other locations too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14911#discussion_r1267346080
PR Review Comment: https://git.openjdk.org/jdk/pull/14911#discussion_r1267347900

From darcy at openjdk.org  Tue Jul 18 22:42:53 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Jul 2023 22:42:53 GMT
Subject: Integrated: JDK-8312203: Improve specification of Array.newInstance
In-Reply-To: <LtpWOTegDJATFzEXDXgv4TJ0S3eFiASN2TGuViSFgtA=.b224ceaa-1052-489a-8c31-132b853ae3e2@github.com>
References: <LtpWOTegDJATFzEXDXgv4TJ0S3eFiASN2TGuViSFgtA=.b224ceaa-1052-489a-8c31-132b853ae3e2@github.com>
Message-ID: <VDIpHG1JnCjE4wfgVp12_-JLYZjEELJxRyM1BBoqRIM=.41117e4b-006b-480b-9a72-6ddcb2f09c1a@github.com>

On Tue, 18 Jul 2023 04:42:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Change one overload of java.lang.reflect.Array.newInstance to have an `@implSpec` of calling the other method.
> 
> I choose not to use a snippet tag here is this code is semantically only one line and doesn't need to be cut-and-pasted.
> 
> As adding an `@implSpec` is technically a (small) specification change, please also review the CSR:
> 
> https://bugs.openjdk.org/browse/JDK-8312208

This pull request has now been integrated.

Changeset: e5ecbff6
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e5ecbff69eeb83abbe70421b7f1540a5c382441a
Stats:     6 lines in 1 file changed: 1 ins; 3 del; 2 mod

8312203: Improve specification of Array.newInstance

Reviewed-by: bpb, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/14917

From mchung at openjdk.org  Wed Jul 19 00:20:55 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 19 Jul 2023 00:20:55 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation
Message-ID: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>

`VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported.   To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information.  Changes include:

1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported.  This check is only needed for direct var handle.
2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported

The error message looks like:

java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]

-------------

Commit messages:
 - 8199149: Improve the exception message thrown by VarHandle of unsupported operation

Changes: https://git.openjdk.org/jdk/pull/14928/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14928&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8199149
  Stats: 35 lines in 3 files changed: 31 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14928/head:pull/14928

PR: https://git.openjdk.org/jdk/pull/14928

From liach at openjdk.org  Wed Jul 19 00:55:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Jul 2023 00:55:42 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation
In-Reply-To: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
Message-ID: <cjVHqzcyVIxZLV1Y8O6OGgao2jvNQ3lFSJSmcoppTno=.be6c4390-8d24-45c1-b8b7-2aa56c1b1a26@github.com>

On Wed, 19 Jul 2023 00:12:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported.   To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information.  Changes include:
> 
> 1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported.  This check is only needed for direct var handle.
> 2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported
> 
> The error message looks like:
> 
> java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]

src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 93:

> 91:     @ForceInline
> 92:     boolean checkAccessModeThenIsDirect(VarHandle.AccessDescriptor ad) {
> 93:         if (exact && accessModeType(ad.type) != ad.symbolicMethodTypeExact) {

Can we add a comment that the detailed UOE is thrown via `directTarget.getMethodHandleUncached`?

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2020:

> 2018: 
> 2019:         static AccessMode valueFromOrdinal(int mode) {
> 2020:             return modeToAccessMode.get(mode);

Can't this be simplified to `AccessMode.values()[mode]` since this is only rarely used in the exception logic?

If we do need a cache, I would recommend a stable array like

private static final @Stable AccessMode[] VALUES = values();

and users call this accessor instead.

The code in `getMethodHandleUncached` can benefit from this caching mechanism.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14928#discussion_r1267424106
PR Review Comment: https://git.openjdk.org/jdk/pull/14928#discussion_r1267422748

From mchung at openjdk.org  Wed Jul 19 02:19:59 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 19 Jul 2023 02:19:59 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v2]
In-Reply-To: <cjVHqzcyVIxZLV1Y8O6OGgao2jvNQ3lFSJSmcoppTno=.be6c4390-8d24-45c1-b8b7-2aa56c1b1a26@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
 <cjVHqzcyVIxZLV1Y8O6OGgao2jvNQ3lFSJSmcoppTno=.be6c4390-8d24-45c1-b8b7-2aa56c1b1a26@github.com>
Message-ID: <k07b0GGeU-HTvaz0FaZ2YbTNnwGexA74Y6tvzLtXdps=.05bb6838-0a7e-4c1a-b4db-686d6db15472@github.com>

On Wed, 19 Jul 2023 00:52:49 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 feedback
>
> src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 93:
> 
>> 91:     @ForceInline
>> 92:     boolean checkAccessModeThenIsDirect(VarHandle.AccessDescriptor ad) {
>> 93:         if (exact && accessModeType(ad.type) != ad.symbolicMethodTypeExact) {
> 
> Can we add a comment that the detailed UOE is thrown via `directTarget.getMethodHandleUncached`?

Actually `VarHandle::checkAccessModeThenIsDirect` can call `isAccessModeSupported` so that this will check properly for `IndirectVarHandle`.

> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2020:
> 
>> 2018: 
>> 2019:         static AccessMode valueFromOrdinal(int mode) {
>> 2020:             return modeToAccessMode.get(mode);
> 
> Can't this be simplified to `AccessMode.values()[mode]` since this is only rarely used in the exception logic?
> 
> If we do need a cache, I would recommend a stable array like
> 
> private static final @Stable AccessMode[] VALUES = values();
> 
> and users call this accessor instead.
> 
> The code in `getMethodHandleUncached` can benefit from this caching mechanism.

Good suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14928#discussion_r1267459610
PR Review Comment: https://git.openjdk.org/jdk/pull/14928#discussion_r1267459744

From mchung at openjdk.org  Wed Jul 19 02:19:58 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 19 Jul 2023 02:19:58 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v2]
In-Reply-To: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
Message-ID: <Cw9fhPHnTaRSTiBqi2LIftNYCD1ahOtyKtTdAKw6R20=.ee8903ce-f1e3-4e52-8a8e-0828c1667579@github.com>

> `VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported.   To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information.  Changes include:
> 
> 1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported.  This check is only needed for direct var handle.
> 2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported
> 
> The error message looks like:
> 
> java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]

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/14928/files
  - new: https://git.openjdk.org/jdk/pull/14928/files/cc66b08c..176df233

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14928&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14928&range=00-01

  Stats: 15 lines in 2 files changed: 0 ins; 11 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14928/head:pull/14928

PR: https://git.openjdk.org/jdk/pull/14928

From liach at openjdk.org  Wed Jul 19 02:22:47 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Jul 2023 02:22:47 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v2]
In-Reply-To: <Cw9fhPHnTaRSTiBqi2LIftNYCD1ahOtyKtTdAKw6R20=.ee8903ce-f1e3-4e52-8a8e-0828c1667579@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
 <Cw9fhPHnTaRSTiBqi2LIftNYCD1ahOtyKtTdAKw6R20=.ee8903ce-f1e3-4e52-8a8e-0828c1667579@github.com>
Message-ID: <be4v8gCUUQrsIyXhLOCzifjGJM4Nr1Ek1q4Vqq-eCXI=.46a37f03-287a-447a-8cd4-b4c601bca4ff@github.com>

On Wed, 19 Jul 2023 02:19:58 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported.   To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information.  Changes include:
>> 
>> 1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported.  This check is only needed for direct var handle.
>> 2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported
>> 
>> The error message looks like:
>> 
>> java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14928#pullrequestreview-1536143735

From liach at openjdk.org  Wed Jul 19 02:47:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Jul 2023 02:47:05 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v26]
In-Reply-To: <hJ3dBq7oaRN8OtWTQS12mnGoAav0NlIuoezGYObY3b4=.624abdc9-d002-4589-933a-c43dbc474158@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <hJ3dBq7oaRN8OtWTQS12mnGoAav0NlIuoezGYObY3b4=.624abdc9-d002-4589-933a-c43dbc474158@github.com>
Message-ID: <ob91GQ0mCafdo8asrMlaBtjVCqvJg4G3hRsCersonRA=.b0744ece-7bb9-4334-af83-d1582b4c9c87@github.com>

On Tue, 18 Jul 2023 01:57:56 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 54 commits:
> 
>  - Review class loader check, restore hidden class rejection spec
>  - Merge branch 'master' into explore/mhp-iface
>  - Review changees
>  - Fix the lazy test, thanks Jorn Vernee!
>  - Clean up impl comment, reorganize tests; weak ref broken
>  - Merge branch 'master' into explore/mhp-iface
>  - Fix broken null behaviors
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'mh-proxies' of https://github.com/mlchung/jdk into explore/mhp-iface
>  - store a WeakReference holder in the class value
>  - ... and 44 more: https://git.openjdk.org/jdk/compare/a53345ad...a12fba06

I have made a release note documenting the potential performance impact: https://bugs.openjdk.org/browse/JDK-8312331
Please help review and revise. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1641300644

From jpai at openjdk.org  Wed Jul 19 07:05:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Jul 2023 07:05:51 GMT
Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6 [v5]
In-Reply-To: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
Message-ID: <SgNncwcMVRq1Cl1SmXB4GHol_RBiGKixLy721Ro9gn8=.5778faa0-1738-456d-8144-e0b746b64240@github.com>

> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229.
> 
> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Alan's suggestion - report -debug usage as a warning right in the java.c code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14918/files
  - new: https://git.openjdk.org/jdk/pull/14918/files/78498068..b6c867b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14918.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14918/head:pull/14918

PR: https://git.openjdk.org/jdk/pull/14918

From jpai at openjdk.org  Wed Jul 19 07:10:42 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Jul 2023 07:10:42 GMT
Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6 [v4]
In-Reply-To: <54o5-4Raq5oX93gQrI_hfTjwiLVJGWzSBmE8VtTvK9g=.cb4c9df8-6a17-473f-9f47-6747303ba8fe@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
 <54o5-4Raq5oX93gQrI_hfTjwiLVJGWzSBmE8VtTvK9g=.cb4c9df8-6a17-473f-9f47-6747303ba8fe@github.com>
Message-ID: <-J8iaBQKogoLygjEnE5-2C7ZOWtWvP6EVchg1gyEblQ=.a25ca7ca-edb6-43ea-9d99-fe647aaa51eb@github.com>

On Tue, 18 Jul 2023 12:41:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229.
>> 
>> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's suggestion for -Xdebug output

Hello Alan,

> I think ParseArguments (in libjli/java.c) could be changed so that it doesn't translate -debug to -Xdebug, instead it can print a warning, like it does for -Xfuture. The reason is -debug is a java launcher option, it's not known to the VM and means that Arguments::parse_each_vm_init_arg doesn't need to mention -debug when it warns about -Xdebug.

I had initially considered that but had noticed that there's a small difference between the generic warning message "Warning: %s option is deprecated and may be removed in a future release." printed by the launcher and the one printed by the VM "OpenJDK 64-Bit Server VM warning: Option -Xdebug was deprecated in JDK 22 and will likely be removed in a future release." But I think that small difference in the warning messages is OK when considered against your stated reasoning that `-debug` isn't known to the VM. 

I've now updated the PR to implement your suggestion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14918#issuecomment-1641532218

From jpai at openjdk.org  Wed Jul 19 07:10:44 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Jul 2023 07:10:44 GMT
Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6 [v5]
In-Reply-To: <SgNncwcMVRq1Cl1SmXB4GHol_RBiGKixLy721Ro9gn8=.5778faa0-1738-456d-8144-e0b746b64240@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
 <SgNncwcMVRq1Cl1SmXB4GHol_RBiGKixLy721Ro9gn8=.5778faa0-1738-456d-8144-e0b746b64240@github.com>
Message-ID: <nzQSP-DkA4nlibzARWldxDK7QllfbCL6C4ZX-jDvPHQ=.fcd49b3a-bef5-4377-90cb-14bac1af11d3@github.com>

On Wed, 19 Jul 2023 07:05:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229.
>> 
>> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's suggestion - report -debug usage as a warning right in the java.c code

Adding one of my previous comments again, because it's not easily visible among the bot generated comments in the GitHub UI:

> I would like inputs on the test/hotspot/jtreg/runtime/6294277/SourceDebugExtension.java test. That test launches java passing it the -Xdebug option and was introduced as part of https://bugs.openjdk.org/browse/JDK-6294277. -Xdebug has been a no-op for many releases now. Is this test still relevant and if not, should I go ahead and remove it as part of this change?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14918#issuecomment-1641534305

From alanb at openjdk.org  Wed Jul 19 08:00:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Jul 2023 08:00:43 GMT
Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6 [v5]
In-Reply-To: <nzQSP-DkA4nlibzARWldxDK7QllfbCL6C4ZX-jDvPHQ=.fcd49b3a-bef5-4377-90cb-14bac1af11d3@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
 <SgNncwcMVRq1Cl1SmXB4GHol_RBiGKixLy721Ro9gn8=.5778faa0-1738-456d-8144-e0b746b64240@github.com>
 <nzQSP-DkA4nlibzARWldxDK7QllfbCL6C4ZX-jDvPHQ=.fcd49b3a-bef5-4377-90cb-14bac1af11d3@github.com>
Message-ID: <FSApUcdiXCc3va7p9cVph_ofa3caO04J7sqs6I0IKm4=.6025e81f-62b0-49c6-98d9-2558c176b78d@github.com>

On Wed, 19 Jul 2023 07:07:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I would like inputs on the test/hotspot/jtreg/runtime/6294277/SourceDebugExtension.java test. That test launches java passing it the -Xdebug option and was introduced as part of https://bugs.openjdk.org/browse/JDK-6294277. -Xdebug has been a no-op for many releases now. Is this test still relevant and if not, should I go ahead and remove it as part of this change?

The SDE class file attribute supports debugging of other languages (see JSR-45). The VM usually skips it but it has to save the bytes when a JVMTI agent has the can_get_source_debug_extension capability enabled. The debugger agent enables this capability so running with -agentlib:jdwp is enough to ensure that it is read. The -Xdebug option can be dropped from the test but otherwise I think leave it in place as it exercises a SDE that is >64k.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14918#issuecomment-1641606804

From alanb at openjdk.org  Wed Jul 19 08:04:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Jul 2023 08:04:42 GMT
Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6 [v5]
In-Reply-To: <SgNncwcMVRq1Cl1SmXB4GHol_RBiGKixLy721Ro9gn8=.5778faa0-1738-456d-8144-e0b746b64240@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
 <SgNncwcMVRq1Cl1SmXB4GHol_RBiGKixLy721Ro9gn8=.5778faa0-1738-456d-8144-e0b746b64240@github.com>
Message-ID: <LxXjq4Ktnn8F5QesEqWgDXd4YNetzREnpUR6l4rg_lg=.1e397b4f-3d39-465e-bd14-2d94b39a489b@github.com>

On Wed, 19 Jul 2023 07:05:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229.
>> 
>> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's suggestion - report -debug usage as a warning right in the java.c code

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14918#pullrequestreview-1536495911

From alanb at openjdk.org  Wed Jul 19 08:04:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Jul 2023 08:04:44 GMT
Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6 [v4]
In-Reply-To: <-J8iaBQKogoLygjEnE5-2C7ZOWtWvP6EVchg1gyEblQ=.a25ca7ca-edb6-43ea-9d99-fe647aaa51eb@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
 <54o5-4Raq5oX93gQrI_hfTjwiLVJGWzSBmE8VtTvK9g=.cb4c9df8-6a17-473f-9f47-6747303ba8fe@github.com>
 <-J8iaBQKogoLygjEnE5-2C7ZOWtWvP6EVchg1gyEblQ=.a25ca7ca-edb6-43ea-9d99-fe647aaa51eb@github.com>
Message-ID: <xy8ZL0UL2omJWDg_0jRDjUtuRUvPLfLS8y9Ypi1-ipU=.f91a9dde-d9fe-4053-9d1a-09a9413ea529@github.com>

On Wed, 19 Jul 2023 07:05:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I had initially considered that but had noticed that there's a small difference between the generic warning message "Warning: %s option is deprecated and may be removed in a future release." printed by the launcher and the one printed by the VM "OpenJDK 64-Bit Server VM warning: Option -Xdebug was deprecated in JDK 22 and will likely be removed in a future release." But I think that small difference in the warning messages is OK when considered against your stated reasoning that `-debug` isn't known to the VM.

The different deprecation messages is a bit annoying but I think it's better than the VM printing a warning for an option that was never possible to specify to JNI CreateJavaVM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14918#issuecomment-1641612439

From jpai at openjdk.org  Wed Jul 19 10:58:58 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Jul 2023 10:58:58 GMT
Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6 [v6]
In-Reply-To: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
Message-ID: <Cq7TUnTv1VVlbeQTY3OtZD7YRt2KqIRushB7TPVvKFc=.267974d1-df00-4559-86aa-f117db520f25@github.com>

> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229.
> 
> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  remove -Xdebug usage from SourceDebugExtension test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14918/files
  - new: https://git.openjdk.org/jdk/pull/14918/files/b6c867b0..79c48cb0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14918.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14918/head:pull/14918

PR: https://git.openjdk.org/jdk/pull/14918

From jlaskey at openjdk.org  Wed Jul 19 12:07:46 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 19 Jul 2023 12:07:46 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v8]
In-Reply-To: <JNvuYjnH3o3VIIZ1Hdi5Rt2agjsqTUGwIRDZCLAp-GI=.52241109-82c9-4fa3-825b-3bb8b0976102@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <6fpeJ9q0R9LTBsv9ynVXmUtuP9o0b4fVgbyGR2iZ59E=.0fe636ac-df43-4397-87d2-b9ea0ba1585a@github.com>
 <JNvuYjnH3o3VIIZ1Hdi5Rt2agjsqTUGwIRDZCLAp-GI=.52241109-82c9-4fa3-825b-3bb8b0976102@github.com>
Message-ID: <wfHvVxKUCD0h5rSSpOV-jn2XqlPr8sXw_2g0-zJapuM=.974b3a5c-05f7-4af0-bf26-834f95ad8b34@github.com>

On Tue, 18 Jul 2023 14:53:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test to check for gc.
>
> src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 97:
> 
>> 95:      * @param <E> the type of elements maintained by this set
>> 96:      */
>> 97:     public static <E> jdk.internal.util.ReferencedKeySet<E>
> 
> Suggestion:
> 
>     public static <E> ReferencedKeySet<E>

IntelliJ has this nasty habit... Changing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1267976218

From mdonovan at openjdk.org  Wed Jul 19 12:13:04 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 19 Jul 2023 12:13:04 GMT
Subject: RFR: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java
Message-ID: <By-JilEJV4FYBvjxQ15aJnjQpzsuAaBsnk7rVnwZfaY=.dffb004a-5159-4b54-aef1-98dc9b9ce0cf@github.com>

This PR refactors the SSLSocketParametersTest by removing redundant/unnecessary classes and cleans up the logic around expected exceptions.

-------------

Commit messages:
 - added javadocs to new methods
 - 8303525: Refactor/cleanup open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java

Changes: https://git.openjdk.org/jdk/pull/14932/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14932&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303525
  Stats: 156 lines in 2 files changed: 54 ins; 85 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14932/head:pull/14932

PR: https://git.openjdk.org/jdk/pull/14932

From prappo at openjdk.org  Wed Jul 19 13:07:01 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 19 Jul 2023 13:07:01 GMT
Subject: RFR: 8312164: Refactor Arrays.hashCode for long, boolean,
 and Object arrays [v2]
In-Reply-To: <2fzWrAYSsxemNshKqA4md_k78mO1gmUSvylsaDSf_7w=.c9b6c8b8-8204-4bb8-a7a0-2496e5d3cf38@github.com>
References: <2fzWrAYSsxemNshKqA4md_k78mO1gmUSvylsaDSf_7w=.c9b6c8b8-8204-4bb8-a7a0-2496e5d3cf38@github.com>
Message-ID: <8GxmD4pcMPv0Pl0WgCB4RB_3lHX2zoxlKEUVyYWeJ3Q=.0bd9d81e-ff1d-4b97-ae37-58d19372a0eb@github.com>

> Please review this PR to refactor Arrays.hashCode for long[], boolean[], and Object[]. I've been told elsewhere that it shouldn't have significant performance implications.

Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:

 - Fix hashCode(double[]): part 2
 - Fix hashCode(double[]): part 1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14900/files
  - new: https://git.openjdk.org/jdk/pull/14900/files/5fd3bb86..81d0f0b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14900&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14900&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14900.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14900/head:pull/14900

PR: https://git.openjdk.org/jdk/pull/14900

From prappo at openjdk.org  Wed Jul 19 13:14:27 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 19 Jul 2023 13:14:27 GMT
Subject: RFR: 8312164: Refactor Arrays.hashCode for long, boolean,
 and Object arrays [v2]
In-Reply-To: <8GxmD4pcMPv0Pl0WgCB4RB_3lHX2zoxlKEUVyYWeJ3Q=.0bd9d81e-ff1d-4b97-ae37-58d19372a0eb@github.com>
References: <2fzWrAYSsxemNshKqA4md_k78mO1gmUSvylsaDSf_7w=.c9b6c8b8-8204-4bb8-a7a0-2496e5d3cf38@github.com>
 <8GxmD4pcMPv0Pl0WgCB4RB_3lHX2zoxlKEUVyYWeJ3Q=.0bd9d81e-ff1d-4b97-ae37-58d19372a0eb@github.com>
Message-ID: <GOJVxrs776hclB419SFdwkxQ-qbDbTOFKKUOHkq7qD4=.f01eadbe-afca-4346-b31c-c097fd4b470b@github.com>

On Wed, 19 Jul 2023 13:07:01 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to refactor Arrays.hashCode for long[], boolean[], and Object[]. I've been told elsewhere that it shouldn't have significant performance implications.
>
> Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix hashCode(double[]): part 2
>  - Fix hashCode(double[]): part 1

Please (re-)review this PR. The recent three commits improve readability of hashCode(double[]) and hashCode(float[]).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14900#issuecomment-1642052942

From prappo at openjdk.org  Wed Jul 19 13:14:23 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 19 Jul 2023 13:14:23 GMT
Subject: RFR: 8312164: Refactor Arrays.hashCode for long, boolean,
 and Object arrays [v3]
In-Reply-To: <2fzWrAYSsxemNshKqA4md_k78mO1gmUSvylsaDSf_7w=.c9b6c8b8-8204-4bb8-a7a0-2496e5d3cf38@github.com>
References: <2fzWrAYSsxemNshKqA4md_k78mO1gmUSvylsaDSf_7w=.c9b6c8b8-8204-4bb8-a7a0-2496e5d3cf38@github.com>
Message-ID: <3ujN1ip4oHjoMrPmL8yV7-pgiOWvtyDQMLSke1kTQSY=.9547bc9a-2db3-4057-a2cb-aa874abd8a0b@github.com>

> Please review this PR to refactor Arrays.hashCode for long[], boolean[], and Object[]. I've been told elsewhere that it shouldn't have significant performance implications.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Fix hashCode(float[])

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14900/files
  - new: https://git.openjdk.org/jdk/pull/14900/files/81d0f0b1..92d09473

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14900&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14900&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14900.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14900/head:pull/14900

PR: https://git.openjdk.org/jdk/pull/14900

From rriggs at openjdk.org  Wed Jul 19 13:30:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Jul 2023 13:30:43 GMT
Subject: RFR: 8312164: Refactor Arrays.hashCode for long, boolean,
 and Object arrays [v3]
In-Reply-To: <3ujN1ip4oHjoMrPmL8yV7-pgiOWvtyDQMLSke1kTQSY=.9547bc9a-2db3-4057-a2cb-aa874abd8a0b@github.com>
References: <2fzWrAYSsxemNshKqA4md_k78mO1gmUSvylsaDSf_7w=.c9b6c8b8-8204-4bb8-a7a0-2496e5d3cf38@github.com>
 <3ujN1ip4oHjoMrPmL8yV7-pgiOWvtyDQMLSke1kTQSY=.9547bc9a-2db3-4057-a2cb-aa874abd8a0b@github.com>
Message-ID: <QvYXcN4_oEK6n4Tj9NfMttQLcBgg_bnTKfcOIvVzE5M=.29bbe4c2-2e03-4177-8f42-79dc61274652@github.com>

On Wed, 19 Jul 2023 13:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to refactor Arrays.hashCode for long[], boolean[], and Object[]. I've been told elsewhere that it shouldn't have significant performance implications.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix hashCode(float[])

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14900#pullrequestreview-1537100084

From duke at openjdk.org  Wed Jul 19 13:40:50 2023
From: duke at openjdk.org (Andy-Tatman)
Date: Wed, 19 Jul 2023 13:40:50 GMT
Subject: RFR: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: <Wz_Ky5w_qBUdBE7zsC9pRMH3XEdHXQyti4Tk2dammPA=.932f5719-dc8d-4c87-9a8a-40397f38ae2f@github.com>
References: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
 <K-vP8vrWjuyUpU1rC5GnePZmzb5A_NCW2aiLjOI5TlY=.80309645-8031-4d82-a2be-157b78d21bdb@github.com>
 <r1YnlgqY3dpeK4Cy62dcl1OUVo9h6toSaeq48e9Jh84=.ec64f374-c469-42c1-a796-bfa7308d7fdc@github.com>
 <Wz_Ky5w_qBUdBE7zsC9pRMH3XEdHXQyti4Tk2dammPA=.932f5719-dc8d-4c87-9a8a-40397f38ae2f@github.com>
Message-ID: <9G46T77FrwT3sHyASv_j_GQskVwBM29ixn72MDmGeQ4=.ae842c66-46d8-42c9-8153-d2f822cf7cf1@github.com>

On Fri, 14 Apr 2023 15:53:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman 
>> It is a known issue that size() may return a negative integer, see [JDK-8230557](https://bugs.openjdk.org/browse/JDK-8230557), and the accepted workaround is to interpret the returned integer as an unsigned value and convert the output to a long. This same workaround works if a user would call length() with Integer.MAX_VALUE set. Changing the specification to reject setting Integer.MAX_VALUE may end up breaking the implementation of clients who rely on setting Integer.MAX_VALUE and use this workaround.
>> 
>> Furthermore, the other methods (including ones that use length()) still function correctly whether or not the Integer.MAX_VALUE bit is set, except for get(int,int) as reported here. For example, clear(int, int) works as expected if Integer.MAX_VALUE is set as length() then is not called.
>> Changing the specification to reject setting Integer.MAX_VALUE may break user code that use this bit and/or users that rely on the above workaround.
>> 
>> So while changing the specifications is possible, it can potentially break existing clients. The change suggested in this pull request avoids this and instead fixes the internal bug of the get function locally, without affecting the other methods and without affecting existing clients.
>
>> So while changing the specifications is possible, it can potentially break existing clients. The change suggested in this pull request avoids this and instead fixes the internal bug of the get function locally, without affecting the other methods and without affecting existing clients.
> 
> I think it will require re-visting the spec, maybe deprecating and/or introducing new methods, it's unfortunate that this wasn't recognised in JDK-8230557.
> 
> Update: @stuart-marks has added a comment to JDK-8230557 on the workaround that someone added to that issue in 2019.

Hi everyone @AlanBateman @liach @stuart-marks  ,

Based on the article's two main options (either banning or still allowing the Integer.MAX_VALUE bit), I have prepared two different CSRs.
These address the changes in specification that are required for each choice, as well as the change in implementation needed in `valueOf(..)`.
I have lumped Solution and Specification together here. Once we decide what we want to actually submit as the CSR, then we can look at making the proper git patch files.

### Permit Integer.MAX_VALUE
**Summary**
While still permitting setting the Integer.MAX VALUE bit in a BitSet, change the specification of `length()` to clarify that it can return Integer.MIN VALUE. 
For the `valueOf(..)` methods, change the specification to prevent the internal value of wordsInUse in BitSet from overflowing and to prevent the bitset storing bits it cannot access

**Problem**
When the Integer.MAX_VALUE bit is set in a BitSet, `length()` returns Integer.MAX_VALUE+1 which overflows to Integer.MIN_VALUE. The specification of the method does not make this clear: The "logical size" of the BitSet is not logically a negative number. 
The `valueOf(..)` methods allow any long[], LongBuffer, byte[] or ByteBuffer to make a bitset. In doing this, wordsInUse gets set to the largest element of words in the new BitSet with at least 1 bit set. However, the internal BitSet code relies on wordsInUse <= Integer.MAX_VALUE / 64 + 1 (we abbreviate this to a constant MAX_WIU), and the bitset class cannot access bits stored in words[MAX_WIU] and above.  
If this is not the case, then the return value of `length()` is no longer reliable: it is determined by the element stored in the long[] or LongBuffer or ..., but these are bits that are not accessible by the BitSet itself. 
Technically, the expression BITS_PER_WORD * (wordsInUse - 1) will overflow, and `length()` will refer to a bit (with negative index or with incorrect positive index) that is not accessible by the other methods of the BitSet class. 

**Solution/Specification** 
`length()`: Specify that the method can return Integer.MIN_VALUE, and this can be interpreted as the UNsigned integer Integer.MAX_VALUE+1.
`valueOf(..)`: There are multiple options. We use `valueOf(long[] longs)` as an example, but equivalent would apply to the other 3 `valueOf(..)` methods.
Option 1: Raise an exception if longs.length is greater than MAX_WIU.
Option 2: Raise an exception if longs.length is greater than MAX_WIU AND there is at least one non-zero element in longs[MAX_WIU]-longs[ length-1 ]
Option 3: No exception, but only take the first MAX_WIU of longs for the bitset. 

**Risk**
Low.
The change in the `length()` specification matches existing behaviour.
The change in the `valueOf(..)` only involves exceptionally large objects. If these were used regularly, it is likely that the `valueOf(..)` bug would have been discovered earlier. 


### Forbid Int.MAX
*For the `valueOf(..)` methods, the same applies here as discussed in the other CSR. The only difference is mentioned in the Solution/Specification section.

**Summary**
Forbid interacting with the Integer.MAX_VALUE bit, preventing an overflow from occurring in `length()`. This involves single-parameter methods in the BitSet class raising an exception if the class tries to access Integer.MAX_VALUE.


**Problem**
When the Integer.MAX_VALUE bit is set, length() overflows to Integer.MIN_VALUE (Integer.MAX_VALUE+1). Moreover, a method such as `set(int bitIndex)` can set the Integer.MAX_VALUE bit, while `set(int fromIndex, int toIndex)` cannot, because the method sets up to but not including toIndex. 


**Solution/Specification** 
Ban accessing the Integer.MAX_VALUE bit. This includes the following changes to the specification (and implementation):
`set(int)`, `set(int, bool)`, `clear(int)`, `get(int)`, `flip(int)`: raise an exception if bitIndex = Integer.MAX_VALUE.

`valueOf(..)`: In addition to the changes described in the **'Permit Integer.MAX_VALUE'** CSR, the `valueOf(..)` methods need to raise an exception if the Integer.MAX_VALUE bit is set (Option 1 and 2) or ignore the bit stored at index Integer.MAX_VALUE, and ensure it is 0 (option 3).


**Risk**
Medium / high?
Forbidding access to the Integer.MAX_VALUE bit is a change to the specification of the essential methods of BitSet, and potentially affects actual, existing use cases. 
This does however require people to be using Integer.MAX_VALUE bits, which is an exceptionally large amount of bits.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1642101764

From jlaskey at openjdk.org  Wed Jul 19 13:53:50 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 19 Jul 2023 13:53:50 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v8]
In-Reply-To: <JNvuYjnH3o3VIIZ1Hdi5Rt2agjsqTUGwIRDZCLAp-GI=.52241109-82c9-4fa3-825b-3bb8b0976102@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <6fpeJ9q0R9LTBsv9ynVXmUtuP9o0b4fVgbyGR2iZ59E=.0fe636ac-df43-4397-87d2-b9ea0ba1585a@github.com>
 <JNvuYjnH3o3VIIZ1Hdi5Rt2agjsqTUGwIRDZCLAp-GI=.52241109-82c9-4fa3-825b-3bb8b0976102@github.com>
Message-ID: <A5sSsVBy72mbu2f3ix2clAB650ZuHhZI_JoR0D_ZBgw=.2d48e33b-f9b5-4e54-92d8-8c4573862153@github.com>

On Tue, 18 Jul 2023 14:56:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test to check for gc.
>
> src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 354:
> 
>> 352:      */
>> 353:     @SuppressWarnings("unchecked")
>> 354:     K intern(K key) {
> 
> Should this be made static for type safety?
> 
> public static <E> E intern(ReferencedKeyMap<E, ReferenceKey<E>> m, E key)
> 
> which will save the 2 unchecked casts at `get` and `putIfAbsent`.
> 
> 
> In addition, it would be nice if we can compute a more proper key for interning than the query key, via a binary operator; for example, we want a `String` to go through `String::intern`, or a `BaseLocale` to format its language, script, region, and variant and intern them (see https://github.com/openjdk/jdk/pull/14404/files#diff-c0e20847ffb6e33bcf62ff52b1b5b4c8a85520ca101a6f54128d97289cd8c2f9R169-R172)

Changing.

> src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 71:
> 
>> 69:  * @param <T> the type of elements maintained by this set
>> 70:  */
>> 71: public class ReferencedKeySet<T> extends AbstractSet<T> {
> 
> Suggestion:
> 
> public final class ReferencedKeySet<T> extends AbstractSet<T> {
> 
> Make this class final.

Changing.

> src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 185:
> 
>> 183:      * @return the old element if present, otherwise, the new element
>> 184:      */
>> 185:     public T intern(T e) {
> 
> I would like to see an additional `T intern(T e, UnaryOperator<T> internFunction)`, where the `internFunction` behaves like `LocalObjectCache::normalizeKey`.

This was a bit tricky. Lambdas can't be used in phase1 so messed when MethodType kicked in. So I created two paths, one for normal and one for the UnaryOperator.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1268104420
PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1268104006
PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1268108150

From jlaskey at openjdk.org  Wed Jul 19 14:04:59 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 19 Jul 2023 14:04:59 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v9]
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: <ixwf_fqc32YLSj9qlNkzlazRe5Zgf60Ufdg2c1yVKTM=.1d580c15-36a5-418d-9362-16eacb9135d7@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 with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' into 8310913
 - Requested changes.
   
   Added intern with UnaryOperator<T> interning function to prepare key before adding to set.
 - Update test to check for gc.
 - Update ReferencedKeyTest.java
 - Simple versions of create
 - Add flag for reference queue type
 - Merge branch 'master' into 8310913
 - Update to use VirtualThread friendly stale queue.
 - Remove warning tied to String Templates
 - unneeded SuppressWarning
 - ... and 5 more: https://git.openjdk.org/jdk/compare/028068a6...fbb78778

-------------

Changes: https://git.openjdk.org/jdk/pull/14684/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14684&range=08
  Stats: 1520 lines in 13 files changed: 887 ins; 625 del; 8 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 martin at openjdk.org  Wed Jul 19 15:03:16 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 19 Jul 2023 15:03:16 GMT
Subject: RFR: 8312019: Simplify and modernize java.util.BitSet.equals
In-Reply-To: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
References: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
Message-ID: <NUQ0cNVhwIx0e2ox3de9a7d36iB4eJ84QwwAaDNqHz0=.c7b0bb69-51f6-4ec8-bdd5-98b569aee669@github.com>

On Thu, 13 Jul 2023 10:50:30 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify equals for BitSet. 
> 
> I couldn't see how to refactor hashCode using Arrays utility methods in a way that preserves its specification. So, aside from refactoring its doc comment and annotating it with `@Overrides`, I left it intact.

src/java.base/share/classes/java/util/BitSet.java line 1018:

> 1016: 
> 1017:     /**
> 1018:      * {@return the hash code value for this bit set}

I tried to find the (non-obvious) spec for {@return ...}
Googling led me to the now embarrassingly outdated
https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html
https://www.oracle.com/java/technologies/javase/javadoc-tool.html#javadocdocuments
before finding the "real" well-maintained doc
https://docs.oracle.com/en/java/javase/20/docs/specs/javadoc/doc-comment-spec.html
(and that would benefit from TOC and inline anchors)

Improving these docs might be the most valuable engineering work that javadoc team could do!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14868#discussion_r1268195287

From liach at openjdk.org  Wed Jul 19 15:03:59 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Jul 2023 15:03:59 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v9]
In-Reply-To: <ixwf_fqc32YLSj9qlNkzlazRe5Zgf60Ufdg2c1yVKTM=.1d580c15-36a5-418d-9362-16eacb9135d7@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <ixwf_fqc32YLSj9qlNkzlazRe5Zgf60Ufdg2c1yVKTM=.1d580c15-36a5-418d-9362-16eacb9135d7@github.com>
Message-ID: <F7-vbtAOHcDyu4wHp0n9Nh4PpcqPHHP8VWOk0bLJpMw=.bf1de997-f424-400b-ad6b-c8a9e017edd6@github.com>

On Wed, 19 Jul 2023 14:04:59 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 with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into 8310913
>  - Requested changes.
>    
>    Added intern with UnaryOperator<T> interning function to prepare key before adding to set.
>  - Update test to check for gc.
>  - Update ReferencedKeyTest.java
>  - Simple versions of create
>  - Add flag for reference queue type
>  - Merge branch 'master' into 8310913
>  - Update to use VirtualThread friendly stale queue.
>  - Remove warning tied to String Templates
>  - unneeded SuppressWarning
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/028068a6...fbb78778

Thank you for the updates.

src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 344:

> 342:      * interning values in a set.
> 343:      *
> 344:      * @implNote Requires a {@link ReferencedKeyMap} whose {@code V} type

The type safety is now ensured by the generic declaration on the static method. The `@implNote`s and `@throws ClassCastException`, including ones in other intern methods, are now redundant.

-------------

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/14684#pullrequestreview-1537170976
PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1268120174

From martin at openjdk.org  Wed Jul 19 15:08:05 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 19 Jul 2023 15:08:05 GMT
Subject: RFR: 8312019: Simplify and modernize java.util.BitSet.equals
In-Reply-To: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
References: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
Message-ID: <BeCIIsg1c2NBGNp1XLXZs0ysQ8LcRXpVAWvWRlgJ7Hc=.7931e8dd-0806-4792-957f-f4fbd5be5cff@github.com>

On Thu, 13 Jul 2023 10:50:30 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify equals for BitSet. 
> 
> I couldn't see how to refactor hashCode using Arrays utility methods in a way that preserves its specification. So, aside from refactoring its doc comment and annotating it with `@Overrides`, I left it intact.

BitSet#equals again demonstrates the brittleness of inheritance - it requires subclasses of BitSet to maintain the same private representation. (don't try to fix it!)

-------------

Marked as reviewed by martin (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14868#pullrequestreview-1537320980

From prappo at openjdk.org  Wed Jul 19 15:13:18 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 19 Jul 2023 15:13:18 GMT
Subject: RFR: 8312019: Simplify and modernize java.util.BitSet.equals
In-Reply-To: <BeCIIsg1c2NBGNp1XLXZs0ysQ8LcRXpVAWvWRlgJ7Hc=.7931e8dd-0806-4792-957f-f4fbd5be5cff@github.com>
References: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
 <BeCIIsg1c2NBGNp1XLXZs0ysQ8LcRXpVAWvWRlgJ7Hc=.7931e8dd-0806-4792-957f-f4fbd5be5cff@github.com>
Message-ID: <g6gdQdABmq4aKL-5MeShuxJiU3x_Lk6LLXDHV_GWxoI=.6900983b-28e0-44b8-9b0b-dcb454cf2208@github.com>

On Wed, 19 Jul 2023 15:05:06 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> BitSet#equals

Did you mean BitSet#hashCode?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14868#issuecomment-1642274647

From rriggs at openjdk.org  Wed Jul 19 16:05:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Jul 2023 16:05:47 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v9]
In-Reply-To: <ixwf_fqc32YLSj9qlNkzlazRe5Zgf60Ufdg2c1yVKTM=.1d580c15-36a5-418d-9362-16eacb9135d7@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <ixwf_fqc32YLSj9qlNkzlazRe5Zgf60Ufdg2c1yVKTM=.1d580c15-36a5-418d-9362-16eacb9135d7@github.com>
Message-ID: <5fmW-nxqKey_dJJMoi98mLjuemCpzFLNVV_-mlTKvW8=.2af9120c-c9c7-41ac-ab06-bed05e00ec66@github.com>

On Wed, 19 Jul 2023 14:04:59 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 with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into 8310913
>  - Requested changes.
>    
>    Added intern with UnaryOperator<T> interning function to prepare key before adding to set.
>  - Update test to check for gc.
>  - Update ReferencedKeyTest.java
>  - Simple versions of create
>  - Add flag for reference queue type
>  - Merge branch 'master' into 8310913
>  - Update to use VirtualThread friendly stale queue.
>  - Remove warning tied to String Templates
>  - unneeded SuppressWarning
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/028068a6...fbb78778

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14684#pullrequestreview-1537445666

From dl at openjdk.org  Wed Jul 19 16:26:58 2023
From: dl at openjdk.org (Doug Lea)
Date: Wed, 19 Jul 2023 16:26:58 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v7]
In-Reply-To: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
Message-ID: <vcCsDNTXWwC3bXRyfoY6ozKq4YujWeS9YL2T9om1ewI=.b707ad7d-69e7-4c11-8239-d5fe9f3f7121@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 ten additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8301341
 - Accommodate white-box tests; use consistent constructions; minor improvements
 - Merge branch 'openjdk:master' into JDK-8301341
 - Simplify contention handling; fix test
 - Fix inverted test assert; improve internal documentation; simplify code
 - 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/060e6774..94148271

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=05-06

  Stats: 9836 lines in 305 files changed: 7514 ins; 1081 del; 1241 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 rgiulietti at openjdk.org  Wed Jul 19 16:52:03 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 19 Jul 2023 16:52:03 GMT
Subject: Integrated: 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: <2UduheMt7C68o60JWCyrZif0Lr0KGb8DPv780d0IRq8=.b6cc652f-2061-4b96-904e-9ebbd2a6ee35@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 now been integrated.

Changeset: 14cf0356
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/14cf035681460e8c93d6afcaaf20aa61c8a6e3a8
Stats:     521 lines in 2 files changed: 519 ins; 1 del; 1 mod

8302987: Add uniform and spatially equidistributed bounded double streams to RandomGenerator

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/12719

From martin at openjdk.org  Wed Jul 19 17:18:40 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 19 Jul 2023 17:18:40 GMT
Subject: RFR: 8312019: Simplify and modernize java.util.BitSet.equals
In-Reply-To: <g6gdQdABmq4aKL-5MeShuxJiU3x_Lk6LLXDHV_GWxoI=.6900983b-28e0-44b8-9b0b-dcb454cf2208@github.com>
References: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
 <BeCIIsg1c2NBGNp1XLXZs0ysQ8LcRXpVAWvWRlgJ7Hc=.7931e8dd-0806-4792-957f-f4fbd5be5cff@github.com>
 <g6gdQdABmq4aKL-5MeShuxJiU3x_Lk6LLXDHV_GWxoI=.6900983b-28e0-44b8-9b0b-dcb454cf2208@github.com>
Message-ID: <dutKRLI4HWp6d8PVEKC_nW1knB8xAyFYzCYQQ4pZ_rg=.341b0b5b-48c3-4cc3-8bd2-bcb49dd8b2d9@github.com>

On Wed, 19 Jul 2023 15:10:45 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > BitSet#equals
> 
> Did you mean BitSet#hashCode?

No. BitSet#equals uses the private fields and methods of its argument, which OO purists would never allow.
If the other is a subclass with a different private representation, this code would fail.
(Don't fix it!)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14868#issuecomment-1642462274

From prappo at openjdk.org  Wed Jul 19 17:24:49 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 19 Jul 2023 17:24:49 GMT
Subject: Integrated: 8312164: Refactor Arrays.hashCode for long, boolean,
 double, float, and Object arrays
In-Reply-To: <2fzWrAYSsxemNshKqA4md_k78mO1gmUSvylsaDSf_7w=.c9b6c8b8-8204-4bb8-a7a0-2496e5d3cf38@github.com>
References: <2fzWrAYSsxemNshKqA4md_k78mO1gmUSvylsaDSf_7w=.c9b6c8b8-8204-4bb8-a7a0-2496e5d3cf38@github.com>
Message-ID: <DxEMGiJz1tuH22k14ealoj7myis1RE9p430j8WpJlBM=.73f3c580-ca2a-4dca-945c-f48aed2c94bb@github.com>

On Mon, 17 Jul 2023 09:36:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to refactor Arrays.hashCode for long[], boolean[], and Object[]. I've been told elsewhere that it shouldn't have significant performance implications.

This pull request has now been integrated.

Changeset: b5b6f4e7
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5b6f4e7a77db4d13e19e186d3cd402cd7c626ea
Stats:     7 lines in 1 file changed: 0 ins; 2 del; 5 mod

8312164: Refactor Arrays.hashCode for long, boolean, double, float, and Object arrays

Reviewed-by: rriggs, vtewari

-------------

PR: https://git.openjdk.org/jdk/pull/14900

From mdonovan at openjdk.org  Wed Jul 19 17:29:00 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 19 Jul 2023 17:29:00 GMT
Subject: RFR: 8312320: Remove javax/rmi/ssl/SSLSocketParametersTest.sh from
 ProblemList
Message-ID: <GsQwDfuaSsl5wm01SuSdvA7f5U56_8BLDmnQ7kqWUvY=.c6731bf6-2974-4269-80a1-90e37a7fed59@github.com>

This PR removes javax/rmi/ssl/SSLSocketParametersTest.sh from the ProblemList. The script was removed in JDK-8298939 and the Java code refactored to be a jtreg test.

-------------

Commit messages:
 - 8312320: Remove javax/rmi/ssl/SSLSocketParametersTest.sh from ProblemList

Changes: https://git.openjdk.org/jdk/pull/14933/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14933&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312320
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14933.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14933/head:pull/14933

PR: https://git.openjdk.org/jdk/pull/14933

From prappo at openjdk.org  Wed Jul 19 17:37:50 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 19 Jul 2023 17:37:50 GMT
Subject: RFR: 8312019: Simplify and modernize java.util.BitSet.equals
In-Reply-To: <dutKRLI4HWp6d8PVEKC_nW1knB8xAyFYzCYQQ4pZ_rg=.341b0b5b-48c3-4cc3-8bd2-bcb49dd8b2d9@github.com>
References: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
 <BeCIIsg1c2NBGNp1XLXZs0ysQ8LcRXpVAWvWRlgJ7Hc=.7931e8dd-0806-4792-957f-f4fbd5be5cff@github.com>
 <g6gdQdABmq4aKL-5MeShuxJiU3x_Lk6LLXDHV_GWxoI=.6900983b-28e0-44b8-9b0b-dcb454cf2208@github.com>
 <dutKRLI4HWp6d8PVEKC_nW1knB8xAyFYzCYQQ4pZ_rg=.341b0b5b-48c3-4cc3-8bd2-bcb49dd8b2d9@github.com>
Message-ID: <Ky2AEiZ-bYhIdg4d-2W5L5HQ-mP3Cr3tddlLygkJqFA=.cf5cfedb-d279-439e-b9f2-f30a277aed89@github.com>

On Wed, 19 Jul 2023 17:15:34 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> > > BitSet#equals
> > 
> > 
> > Did you mean BitSet#hashCode?
> 
> No. BitSet#equals uses the private fields and methods of its argument, which OO purists would never allow. If the other is a subclass with a different private representation, this code would fail. (Don't fix it!)

I see.

While both `hashCode` and `equals` use private fields, `equals` also calls the `checkInvariants` private method on `this` and the other set. I reckon, it makes `equals` quantitatively worse than `hashCode`, rather than qualitatively.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14868#issuecomment-1642486252

From jlu at openjdk.org  Wed Jul 19 18:46:44 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 19 Jul 2023 18:46:44 GMT
Subject: RFR: 8039165: [Doc] MessageFormat null locale generates
 NullPointerException [v3]
In-Reply-To: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
Message-ID: <dLCFeLtinyQRS-pJpV6MSEb5ZY8FDfQ71MLAYoV75rE=.fd19229a-eb0a-4353-8e35-2c9fd06fd2d6@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8312197) which updates the javadoc for the constructor of MessageFormat regarding a `null` locale,
> 
> `MessageFormat` when created with a `null` locale may throw a `NullPointerException` either during the object creation, or later when `format()` is called by the `MessageFormat` object (test file has examples of both). This change updates the specification of MessageFormat to make this apparent.
> 
> The test for this change was merged with `Bug6481179.java` into `MessageFormatExceptions.java` (As they both test exceptions). In addition, some other exception testing regarding MessageFormat was added.
> 
> Thanks

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Combine throws for constructor
 - Review: Combine throws and re-word localized

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14911/files
  - new: https://git.openjdk.org/jdk/pull/14911/files/4092e3ad..8fd94758

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14911&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14911&range=01-02

  Stats: 14 lines in 1 file changed: 0 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/14911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14911/head:pull/14911

PR: https://git.openjdk.org/jdk/pull/14911

From jlu at openjdk.org  Wed Jul 19 18:46:46 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 19 Jul 2023 18:46:46 GMT
Subject: RFR: 8039165: [Doc] MessageFormat null locale generates
 NullPointerException [v2]
In-Reply-To: <TkjfooL3oTp-53EAxHoltO3ln1VugGydMJb9zVKELMY=.fc04ca6e-16f2-43e6-921e-9989f0a35c06@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
 <yUwg4u4-pbTS8osxbRBNOkDfm2KfX1OURICTJQRh05U=.a595371c-8939-436e-8e6a-5a725cbf5277@github.com>
 <TkjfooL3oTp-53EAxHoltO3ln1VugGydMJb9zVKELMY=.fc04ca6e-16f2-43e6-921e-9989f0a35c06@github.com>
Message-ID: <vO4gIMeijrpqQfxoqsWtSt8zg1NXFIlaUry9x3L33xM=.918eed16-f796-4c5a-9880-0ca9a9f71ba1@github.com>

On Tue, 18 Jul 2023 22:09:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Slight wording adjustment
>>  - Review: Explicitly declare when NPE thrown instead of 'may'
>
> src/java.base/share/classes/java/text/MessageFormat.java line 407:
> 
>> 405:      * @throws    NullPointerException This method throws a
>> 406:      *            {@code NullPointerException} if {@code locale} is {@code null}
>> 407:      *            and a localized subformat is used.
> 
> NPE throws tags should be combined. Applies to other locations too.

Thanks for the follow up review, I have fixed this and the 'localized' wording. I have also updated the CSR to reflect the most recent changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14911#discussion_r1268509743

From jlaskey at openjdk.org  Wed Jul 19 19:13:19 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 19 Jul 2023 19:13:19 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
Message-ID: <I90tCzphyMJ2YIRGygj4C2mBuelkv2Vp8oK3xU_0-nM=.c815dae4-3bd0-44ca-a002-1a1f58299158@github.com>

On Thu, 13 Jul 2023 23:05:48 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 with a new target base 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 'openjdk:master' into unsafe
>  - add 8310843 to @bug
>  - 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
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/ce274692...cb56e736

Marked as reviewed by jlaskey (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14636#pullrequestreview-1537848969

From cjplummer at openjdk.org  Wed Jul 19 19:23:05 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 19 Jul 2023 19:23:05 GMT
Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6 [v6]
In-Reply-To: <Cq7TUnTv1VVlbeQTY3OtZD7YRt2KqIRushB7TPVvKFc=.267974d1-df00-4559-86aa-f117db520f25@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
 <Cq7TUnTv1VVlbeQTY3OtZD7YRt2KqIRushB7TPVvKFc=.267974d1-df00-4559-86aa-f117db520f25@github.com>
Message-ID: <Kz8KilPPiyVAlIGacLBDjgIDLpo-WxDpHGHpzpvMNCM=.197a85e9-f749-405d-9c1d-673df06b5870@github.com>

On Wed, 19 Jul 2023 10:58:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229.
>> 
>> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove -Xdebug usage from SourceDebugExtension test

Nice cleanup! Changes look good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14918#pullrequestreview-1537863690

From aturbanov at openjdk.org  Wed Jul 19 19:35:07 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 19 Jul 2023 19:35:07 GMT
Subject: RFR: 8312414: Make java.util.ServiceLoader.LANG_ACCESS final
Message-ID: <qWcyYb8lp5Vr1wwxc_TsCoLilVENs7RKj5kGl4HpYzw=.ad9a8ed8-df06-4f66-b260-a5dac50f2418@github.com>

Found opportunity to make static `ServiceLoader.LANG_ACCESS` field `final`.

-------------

Commit messages:
 - 8312414: Make java.util.ServiceLoader.LANG_ACCESS final
 - [PATCH] Make java.util.ServiceLoader.LANG_ACCESS final

Changes: https://git.openjdk.org/jdk/pull/14926/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14926&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312414
  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14926.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14926/head:pull/14926

PR: https://git.openjdk.org/jdk/pull/14926

From alanb at openjdk.org  Wed Jul 19 19:35:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Jul 2023 19:35:08 GMT
Subject: RFR: 8312414: Make java.util.ServiceLoader.LANG_ACCESS final
In-Reply-To: <qWcyYb8lp5Vr1wwxc_TsCoLilVENs7RKj5kGl4HpYzw=.ad9a8ed8-df06-4f66-b260-a5dac50f2418@github.com>
References: <qWcyYb8lp5Vr1wwxc_TsCoLilVENs7RKj5kGl4HpYzw=.ad9a8ed8-df06-4f66-b260-a5dac50f2418@github.com>
Message-ID: <ZkrTk-iRQAH5pFjyNSTekoIJOCueb2Um8C4HLHskxk4=.1d6ff849-dd89-40a7-96f1-78fa5373a90f@github.com>

On Tue, 18 Jul 2023 20:06:56 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found opportunity to make static `ServiceLoader.LANG_ACCESS` field `final`.

src/java.base/share/classes/java/util/ServiceLoader.java line 426:

> 424: 
> 425:     private static final JavaLangAccess LANG_ACCESS =
> 426:             SharedSecrets.getJavaLangAccess();

An oversight when SL was re-implemented in JDK 9. It will look better if you avoid the line break.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14926#discussion_r1267773370

From jlu at openjdk.org  Wed Jul 19 19:41:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 19 Jul 2023 19:41:57 GMT
Subject: RFR: 8039165: [Doc] MessageFormat null locale generates
 NullPointerException [v4]
In-Reply-To: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
Message-ID: <cBtznTXqufCCFh3wp1dQTQ0hLO7Aav0kus3FfUb4KRQ=.989dfca0-ec97-4a66-9d06-a00a34c082af@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8312197) which updates the javadoc for the constructor of MessageFormat regarding a `null` locale,
> 
> `MessageFormat` when created with a `null` locale may throw a `NullPointerException` either during the object creation, or later when `format()` is called by the `MessageFormat` object (test file has examples of both). This change updates the specification of MessageFormat to make this apparent.
> 
> The test for this change was merged with `Bug6481179.java` into `MessageFormatExceptions.java` (As they both test exceptions). In addition, some other exception testing regarding MessageFormat was added.
> 
> Thanks

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Account for setLocale()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14911/files
  - new: https://git.openjdk.org/jdk/pull/14911/files/8fd94758..b075f5d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14911&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14911&range=02-03

  Stats: 10 lines in 2 files changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14911/head:pull/14911

PR: https://git.openjdk.org/jdk/pull/14911

From naoto at openjdk.org  Wed Jul 19 19:51:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Jul 2023 19:51:52 GMT
Subject: RFR: 8039165: [Doc] MessageFormat null locale generates
 NullPointerException [v4]
In-Reply-To: <cBtznTXqufCCFh3wp1dQTQ0hLO7Aav0kus3FfUb4KRQ=.989dfca0-ec97-4a66-9d06-a00a34c082af@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
 <cBtznTXqufCCFh3wp1dQTQ0hLO7Aav0kus3FfUb4KRQ=.989dfca0-ec97-4a66-9d06-a00a34c082af@github.com>
Message-ID: <Zz1PMhNeX-UQNQfp8eIzXnwoElY1FsSIigf2inXoybQ=.4ec5a81c-c29d-48d6-9d57-85de63421984@github.com>

On Wed, 19 Jul 2023 19:41:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8312197) which updates the javadoc for the constructor of MessageFormat regarding a `null` locale,
>> 
>> `MessageFormat` when created with a `null` locale may throw a `NullPointerException` either during the object creation, or later when `format()` is called by the `MessageFormat` object (test file has examples of both). This change updates the specification of MessageFormat to make this apparent.
>> 
>> The test for this change was merged with `Bug6481179.java` into `MessageFormatExceptions.java` (As they both test exceptions). In addition, some other exception testing regarding MessageFormat was added.
>> 
>> Thanks
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Account for setLocale()

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14911#pullrequestreview-1537916353

From rriggs at openjdk.org  Wed Jul 19 20:07:11 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Jul 2023 20:07:11 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
Message-ID: <dSaGofeOlyly06q_BkLtJNFbBlSJpVp-xDi_vXXB4ls=.75ac8f3c-3df3-468e-af40-ef9c11cdcc00@github.com>

On Thu, 13 Jul 2023 23:05:48 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 with a new target base 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 'openjdk:master' into unsafe
>  - add 8310843 to @bug
>  - 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
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/dd563b16...cb56e736

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14636#pullrequestreview-1537939473

From jlu at openjdk.org  Wed Jul 19 20:25:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 19 Jul 2023 20:25:54 GMT
Subject: Integrated: 8311663: Additional refactoring of Locale tests to JUnit
In-Reply-To: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
References: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
Message-ID: <G5Yt9jVSv_JPKXHWwV_jWbWyyuB722-B7XCghWgXSo4=.1f89711e-4cd1-4991-9a08-4ca7cae88808@github.com>

On Thu, 13 Jul 2023 23:23:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which refactors more java.util.Locale tests to JUnit with some minor cleanup as well.
> 
> Although some of the files could benefit from being renamed bugNNNNNNN to something more descriptive, this makes reviewing harder, and will be handled separately.

This pull request has now been integrated.

Changeset: 71cac8ce
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/71cac8ce47b69a2b78d54cbceb0f0510e5ea4cdc
Stats:     549 lines in 10 files changed: 159 ins; 217 del; 173 mod

8311663: Additional refactoring of Locale tests to JUnit

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/14881

From prappo at openjdk.org  Wed Jul 19 20:50:41 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 19 Jul 2023 20:50:41 GMT
Subject: RFR: 8312019: Simplify and modernize java.util.BitSet.equals
In-Reply-To: <YQhzTnDuXSyDfqlgixyIY72WzaOycQjN2HFh6DBEV-M=.82696b69-bbba-4461-b6b2-853b2bbfab1c@github.com>
References: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
 <YQhzTnDuXSyDfqlgixyIY72WzaOycQjN2HFh6DBEV-M=.82696b69-bbba-4461-b6b2-853b2bbfab1c@github.com>
Message-ID: <5YmWPRwfqG22U-BG53JIfLGO2StXyt3rq9lvq_cZu9Y=.42bbcb64-faa3-4ccf-b99c-c7f860daee62@github.com>

On Thu, 13 Jul 2023 14:50:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Please review this PR to use modern APIs and language features to simplify equals for BitSet. 
>> 
>> I couldn't see how to refactor hashCode using Arrays utility methods in a way that preserves its specification. So, aside from refactoring its doc comment and annotating it with `@Overrides`, I left it intact.
>
> LGTM

@RogerRiggs, @Martin-Buchholz, are you okay with a few redundant range checks?

`Arrays.equals(a, aFromIndex, aToIndex, b, bFromIndex, bToIndex)` performs two range checks, which aren't needed here. However, `Arrays.equals` is readable; a less readable but leaner alternative would be `ArraysSupport.mismatch(a, aFromIndex, b, bFromIndex, length)`. Here's a diff from this PR's version, to consider:


diff --git a/src/java.base/share/classes/java/util/BitSet.java b/src/java.base/share/classes/java/util/BitSet.java
index 7189dc49228..fea9693d7ed 100644
--- a/src/java.base/share/classes/java/util/BitSet.java
+++ b/src/java.base/share/classes/java/util/BitSet.java
@@ -33,6 +33,8 @@ import java.util.function.IntConsumer;
 import java.util.stream.IntStream;
 import java.util.stream.StreamSupport;
 
+import jdk.internal.util.ArraysSupport;
+
 /**
  * This class implements a vector of bits that grows as needed. Each
  * component of the bit set has a {@code boolean} value. The
@@ -1076,8 +1078,11 @@ public class BitSet implements Cloneable, java.io.Serializable {
         checkInvariants();
         set.checkInvariants();
 
+        if (wordsInUse != set.wordsInUse)
+            return false;
+
         // Check words in use by both BitSets
-        return Arrays.equals(words, 0, wordsInUse, set.words, 0, set.wordsInUse);
+        return ArraysSupport.mismatch(words, 0, set.words, 0, wordsInUse) == -1;
     }
 
     /**

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14868#issuecomment-1642734404

From martin at openjdk.org  Wed Jul 19 20:56:44 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 19 Jul 2023 20:56:44 GMT
Subject: RFR: 8312019: Simplify and modernize java.util.BitSet.equals
In-Reply-To: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
References: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
Message-ID: <KzlfH9YaUby7ApAAkVi3mSk9zcmf1606pMMz_qhihqQ=.e139dd03-683c-40e3-9626-967b7d37f7d4@github.com>

On Thu, 13 Jul 2023 10:50:30 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify equals for BitSet. 
> 
> I couldn't see how to refactor hashCode using Arrays utility methods in a way that preserves its specification. So, aside from refactoring its doc comment and annotating it with `@Overrides`, I left it intact.

TIL about toLongArray.. BitSet#equals would be more correct if it called set.toLongArray, but at a cost of an extra copy.

---

I appreciate the desire to call checkInvariants; I've written some checkInvariants methods myself, but I comment  out any calls to them in the production copy of the code.  Optional runtime checking has not really succeeded in Java.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14868#issuecomment-1642742978

From xuelei at openjdk.org  Wed Jul 19 21:06:41 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 19 Jul 2023 21:06:41 GMT
Subject: RFR: 8312320: Remove javax/rmi/ssl/SSLSocketParametersTest.sh from
 ProblemList
In-Reply-To: <GsQwDfuaSsl5wm01SuSdvA7f5U56_8BLDmnQ7kqWUvY=.c6731bf6-2974-4269-80a1-90e37a7fed59@github.com>
References: <GsQwDfuaSsl5wm01SuSdvA7f5U56_8BLDmnQ7kqWUvY=.c6731bf6-2974-4269-80a1-90e37a7fed59@github.com>
Message-ID: <DjNHXQm88G4qn-PPoQ3xexY42X6lTJv_l7Y5_C5etKY=.5b252b4d-ff05-4c3f-a6ed-94d4a7a81751@github.com>

On Wed, 19 Jul 2023 12:58:43 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR removes javax/rmi/ssl/SSLSocketParametersTest.sh from the ProblemList. The script was removed in JDK-8298939 and the Java code refactored to be a jtreg test.

Marked as reviewed by xuelei (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14933#pullrequestreview-1538016529

From martin at openjdk.org  Wed Jul 19 21:08:39 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 19 Jul 2023 21:08:39 GMT
Subject: RFR: 8312019: Simplify and modernize java.util.BitSet.equals
In-Reply-To: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
References: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
Message-ID: <zi4gRTdNWbQnvxlkEc35mQcB3EB3Ngps-bvbhV3SiDg=.58b60f50-1679-4c59-ae03-901ddd1d5f05@github.com>

On Thu, 13 Jul 2023 10:50:30 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify equals for BitSet. 
> 
> I couldn't see how to refactor hashCode using Arrays utility methods in a way that preserves its specification. So, aside from refactoring its doc comment and annotating it with `@Overrides`, I left it intact.

Performance of core classes is very important, - I am willing to have less elegant code with better performance.
Most users would also prefer faster code "for free".
I would prefer to comment out the checkInvariants() and to not introduce new checks.
I don't trust the VM to optimize away all the trivially true checks.

But I've seen other maintainers opt for elegant cleaner slower code instead, and I've tried not to complain!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14868#issuecomment-1642759544

From rriggs at openjdk.org  Wed Jul 19 21:13:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Jul 2023 21:13:40 GMT
Subject: RFR: 8312019: Simplify and modernize java.util.BitSet.equals
In-Reply-To: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
References: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
Message-ID: <K2tJgy4Vvwev-WRDDQKjOw_J8tpGW_fRXHEOIY3hMhg=.6da4814e-2768-4416-9d02-29fd08881fcf@github.com>

On Thu, 13 Jul 2023 10:50:30 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify equals for BitSet. 
> 
> I couldn't see how to refactor hashCode using Arrays utility methods in a way that preserves its specification. So, aside from refactoring its doc comment and annotating it with `@Overrides`, I left it intact.

Using ArraySupport.mismatch is pretty straightforward and avoids the duplicate checks.  That fine by me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14868#issuecomment-1642764916

From prappo at openjdk.org  Wed Jul 19 22:08:04 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 19 Jul 2023 22:08:04 GMT
Subject: RFR: 8312019: Simplify and modernize java.util.BitSet.equals [v2]
In-Reply-To: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
References: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
Message-ID: <l-3aeVCHKE3UG_hkQ9LmVEhwjXGEKQeUSvKQbDq1lrQ=.719c9b9b-58fc-4813-a1b6-f0ecd73b7055@github.com>

> Please review this PR to use modern APIs and language features to simplify equals for BitSet. 
> 
> I couldn't see how to refactor hashCode using Arrays utility methods in a way that preserves its specification. So, aside from refactoring its doc comment and annotating it with `@Overrides`, I left it intact.

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 three additional commits since the last revision:

 - Merge branch 'master' into 8312019
 - Use a leaner utility method
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14868/files
  - new: https://git.openjdk.org/jdk/pull/14868/files/39de7d2a..0a3f1d94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14868&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14868&range=00-01

  Stats: 10505 lines in 327 files changed: 8461 ins; 958 del; 1086 mod
  Patch: https://git.openjdk.org/jdk/pull/14868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14868/head:pull/14868

PR: https://git.openjdk.org/jdk/pull/14868

From prappo at openjdk.org  Wed Jul 19 22:26:41 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 19 Jul 2023 22:26:41 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v2]
In-Reply-To: <B0bA9g1k5-los70gD6pNPWcAcmmdAH2LvoB4qNM5t2A=.642bc61c-a1ce-42fd-b575-0283e6109db8@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <pTMvEIx5UPajYBUi4pCgN6CsyzVd6tlJhqcla4D3nV4=.c8aa7c9d-4bbe-482e-8b96-1423950105eb@github.com>
 <-hRTcFsCaDtdobIiQV-dfh1eeAEcT18sk972TG0QRRU=.6aff2ebf-b146-4483-98c7-29b342d674d9@github.com>
 <B0bA9g1k5-los70gD6pNPWcAcmmdAH2LvoB4qNM5t2A=.642bc61c-a1ce-42fd-b575-0283e6109db8@github.com>
Message-ID: <63rU5bAOp-2-n5wzpiJ4JwjihI-4YQLS5Ns6CRy5zXI=.122afa19-e351-4e60-adfc-e2c447b37a80@github.com>

On Mon, 10 Jul 2023 18:29:36 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I suggest we introduce the required utility method (i.e. hashOfRange) in ArraysSupport first.

Introducing such a method might take a while. Let me push a commit that restores hash code
values, while still using modern utilities to calculate them (see this comment: https://github.com/openjdk/jdk/pull/14630#issuecomment-1621705028).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1642842302

From liach at openjdk.org  Wed Jul 19 22:46:50 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Jul 2023 22:46:50 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
Message-ID: <ARccDleySdl1X23_Z6mzE3cPEJA78ugQdHyglRkSTZc=.7b620daf-68bb-4529-888b-2f0bdd2001d5@github.com>

On Thu, 13 Jul 2023 23:05:48 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 with a new target base 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 'openjdk:master' into unsafe
>  - add 8310843 to @bug
>  - 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
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/acdf6378...cb56e736

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14636#pullrequestreview-1538150325

From mchung at openjdk.org  Wed Jul 19 23:48:03 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 19 Jul 2023 23:48:03 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v3]
In-Reply-To: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
Message-ID: <oTwWuqwMKS4_PL0jUF-seHdfaXwW0Iw0o3RuCrdSINc=.5bbe6422-d06a-4c18-88d9-41152058305c@github.com>

> `VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported.   To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information.  Changes include:
> 
> 1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported.  This check is only needed for direct var handle.
> 2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported
> 
> The error message looks like:
> 
> java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback from psandoz

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14928/files
  - new: https://git.openjdk.org/jdk/pull/14928/files/176df233..9196ccb4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14928&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14928&range=01-02

  Stats: 19 lines in 2 files changed: 2 ins; 15 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14928/head:pull/14928

PR: https://git.openjdk.org/jdk/pull/14928

From jvernee at openjdk.org  Wed Jul 19 23:48:03 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jul 2023 23:48:03 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v2]
In-Reply-To: <Cw9fhPHnTaRSTiBqi2LIftNYCD1ahOtyKtTdAKw6R20=.ee8903ce-f1e3-4e52-8a8e-0828c1667579@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
 <Cw9fhPHnTaRSTiBqi2LIftNYCD1ahOtyKtTdAKw6R20=.ee8903ce-f1e3-4e52-8a8e-0828c1667579@github.com>
Message-ID: <BYVliWxAjxCWm2AuDCvGxkdK0VGWBkpuUOkZc6eYlLE=.37b14144-417a-4d9e-b8b4-62259bde819a@github.com>

On Wed, 19 Jul 2023 02:19:58 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported.   To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information.  Changes include:
>> 
>> 1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported.  This check is only needed for direct var handle.
>> 2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported
>> 
>> The error message looks like:
>> 
>> java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback

> change VarHandle::checkAccessModeThenIsDirect to check if the access mode is unsupported. This check is only needed for direct var handle.

Note that `IndirectVarHandle` calls `super.checkAccessModeThenIsDirect`, so it ends up doing the check any way, I think?

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 36:

> 34: import java.util.HashMap;
> 35: import java.util.List;
> 36: import java.util.Map;

These two new imports seem unused.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14928#pullrequestreview-1538189132
PR Review Comment: https://git.openjdk.org/jdk/pull/14928#discussion_r1268779284

From liach at openjdk.org  Wed Jul 19 23:48:03 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Jul 2023 23:48:03 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v2]
In-Reply-To: <Cw9fhPHnTaRSTiBqi2LIftNYCD1ahOtyKtTdAKw6R20=.ee8903ce-f1e3-4e52-8a8e-0828c1667579@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
 <Cw9fhPHnTaRSTiBqi2LIftNYCD1ahOtyKtTdAKw6R20=.ee8903ce-f1e3-4e52-8a8e-0828c1667579@github.com>
Message-ID: <LGVV0toGaQ9I-lk76_rK4zCGTwh1C9nIhIWTqvrlxAo=.297c1967-d2bb-4894-903b-3a401d16111e@github.com>

On Wed, 19 Jul 2023 02:19:58 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported.   To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information.  Changes include:
>> 
>> 1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported.  This check is only needed for direct var handle.
>> 2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported
>> 
>> The error message looks like:
>> 
>> java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback

Just curious, why does Paul Sandoz recommend removing the VarHandle itself from the UOE message?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14928#issuecomment-1642900664

From liach at openjdk.org  Wed Jul 19 23:48:03 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Jul 2023 23:48:03 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v2]
In-Reply-To: <BYVliWxAjxCWm2AuDCvGxkdK0VGWBkpuUOkZc6eYlLE=.37b14144-417a-4d9e-b8b4-62259bde819a@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
 <Cw9fhPHnTaRSTiBqi2LIftNYCD1ahOtyKtTdAKw6R20=.ee8903ce-f1e3-4e52-8a8e-0828c1667579@github.com>
 <BYVliWxAjxCWm2AuDCvGxkdK0VGWBkpuUOkZc6eYlLE=.37b14144-417a-4d9e-b8b4-62259bde819a@github.com>
Message-ID: <LPtcvJnv1FDpGRPk2U4QxpTdiob_W3OSrmEKJqsB9eg=.3a8884cc-5e46-4aea-b391-61b7475d17e1@github.com>

On Wed, 19 Jul 2023 23:37:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Note that `IndirectVarHandle` calls `super.checkAccessModeThenIsDirect`, so it ends up doing the check any way, I think?

In the initial patch, it was distinct; it was migrated to call `isAccessModeSupported` in a subsequent change, so the change in `IndirectVarHandle` was rolled back and the VHs share a more consistent behavior.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14928#issuecomment-1642899720

From mchung at openjdk.org  Wed Jul 19 23:48:38 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 19 Jul 2023 23:48:38 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v2]
In-Reply-To: <Cw9fhPHnTaRSTiBqi2LIftNYCD1ahOtyKtTdAKw6R20=.ee8903ce-f1e3-4e52-8a8e-0828c1667579@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
 <Cw9fhPHnTaRSTiBqi2LIftNYCD1ahOtyKtTdAKw6R20=.ee8903ce-f1e3-4e52-8a8e-0828c1667579@github.com>
Message-ID: <PTlTKcYcqpNLJTbcaFh2ANfCGJSTacT6dyW7KquBUWI=.c576f5a1-70eb-46b5-bca9-fa18410ceefb@github.com>

On Wed, 19 Jul 2023 02:19:58 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported.   To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information.  Changes include:
>> 
>> 1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported.  This check is only needed for direct var handle.
>> 2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported
>> 
>> The error message looks like:
>> 
>> java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback

I got feedback from @PaulSandoz.   The patch is updated to include only the access mode information.

`checkAccessModeThenIsDirect` is on a performance sensitive path.   We only need to modify `VarForm::getMemberName` to print out the access mode.   Also mark `getMemberName` as `@Hidden` which then shows the call site from the top of the stack trace.    The user can find out which VarHandle from the callsite from the stack trace location.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14928#issuecomment-1642902785

From duke at openjdk.org  Wed Jul 19 23:54:38 2023
From: duke at openjdk.org (airsquared)
Date: Wed, 19 Jul 2023 23:54:38 GMT
Subject: RFR: JDK-8309032: jpackage does not work for module projects
 unless --module-path is specified
In-Reply-To: <UIjn_K4ndSbmM-oNcPWT8x8VLNPScLerLzOc0GKNeJI=.35945e86-9a59-42be-928b-40f005acaffc@github.com>
References: <ZHCWcpSLF1khyvrydxW8JarYKgYOj3B-9nnBVElWVpc=.4a345b50-7213-4e30-969e-280e3cd11575@github.com>
 <UIjn_K4ndSbmM-oNcPWT8x8VLNPScLerLzOc0GKNeJI=.35945e86-9a59-42be-928b-40f005acaffc@github.com>
Message-ID: <SRssgHk6sdaiMY3g3n33NNKaSAGEIyJWHxxAGm1_2Rw=.ca3fdd22-f902-458f-9cb1-578afe5750d2@github.com>

On Tue, 18 Jul 2023 15:33:46 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> [JDK-8309032](https://bugs.openjdk.org/browse/JDK-8309032), [JDK-8306488](https://bugs.openjdk.org/browse/JDK-8306488)
>
> Marked as reviewed by asemenyuk (Reviewer).

@alexeysemenyukoracle would you be able to sponsor this change? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14840#issuecomment-1642906510

From liach at openjdk.org  Thu Jul 20 00:00:43 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Jul 2023 00:00:43 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v3]
In-Reply-To: <oTwWuqwMKS4_PL0jUF-seHdfaXwW0Iw0o3RuCrdSINc=.5bbe6422-d06a-4c18-88d9-41152058305c@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
 <oTwWuqwMKS4_PL0jUF-seHdfaXwW0Iw0o3RuCrdSINc=.5bbe6422-d06a-4c18-88d9-41152058305c@github.com>
Message-ID: <hJpih-0J2LMy5R6LAwYhZWxmbEsdiEFanIul54FNRRU=.8d9cc0a7-a254-40d5-8768-fdc6f277e34e@github.com>

On Wed, 19 Jul 2023 23:48:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported.   To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information.  Changes include:
>> 
>> 1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported.  This check is only needed for direct var handle.
>> 2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported
>> 
>> The error message looks like:
>> 
>> java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback from psandoz

The enum values caching can be applied to `AccessType` as well; can be done in a separate patch, and I've created ticket at https://bugs.openjdk.org/browse/JDK-8312423.

-------------

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/14928#pullrequestreview-1538211524

From liach at openjdk.org  Thu Jul 20 00:02:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Jul 2023 00:02:08 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v26]
In-Reply-To: <hJ3dBq7oaRN8OtWTQS12mnGoAav0NlIuoezGYObY3b4=.624abdc9-d002-4589-933a-c43dbc474158@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <hJ3dBq7oaRN8OtWTQS12mnGoAav0NlIuoezGYObY3b4=.624abdc9-d002-4589-933a-c43dbc474158@github.com>
Message-ID: <UUtvV-PavI6uTgXsnG1KhMcZlm365yRwzAhkHz0hcCw=.31ccd2a4-c259-4644-b963-298f23102de0@github.com>

On Tue, 18 Jul 2023 01:57:56 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 54 commits:
> 
>  - Review class loader check, restore hidden class rejection spec
>  - Merge branch 'master' into explore/mhp-iface
>  - Review changees
>  - Fix the lazy test, thanks Jorn Vernee!
>  - Clean up impl comment, reorganize tests; weak ref broken
>  - Merge branch 'master' into explore/mhp-iface
>  - Fix broken null behaviors
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'mh-proxies' of https://github.com/mlchung/jdk into explore/mhp-iface
>  - store a WeakReference holder in the class value
>  - ... and 44 more: https://git.openjdk.org/jdk/compare/a53345ad...a12fba06

Looks like Mandy has cleaned up the release note. Thank you, integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1642911757

From martin at openjdk.org  Thu Jul 20 00:07:43 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 20 Jul 2023 00:07:43 GMT
Subject: RFR: 8312019: Simplify and modernize java.util.BitSet.equals [v2]
In-Reply-To: <l-3aeVCHKE3UG_hkQ9LmVEhwjXGEKQeUSvKQbDq1lrQ=.719c9b9b-58fc-4813-a1b6-f0ecd73b7055@github.com>
References: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
 <l-3aeVCHKE3UG_hkQ9LmVEhwjXGEKQeUSvKQbDq1lrQ=.719c9b9b-58fc-4813-a1b6-f0ecd73b7055@github.com>
Message-ID: <l8FbwgRvoagxQ4BeBjK9x_zfR_od_32jAb8MfLbeqRA=.a2ae591b-ab8e-41b5-9fd6-abaca7e479c9@github.com>

On Wed, 19 Jul 2023 22:08:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to use modern APIs and language features to simplify equals for BitSet. 
>> 
>> I couldn't see how to refactor hashCode using Arrays utility methods in a way that preserves its specification. So, aside from refactoring its doc comment and annotating it with `@Overrides`, I left it intact.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8312019
>  - Use a leaner utility method
>  - Initial commit

LGTM

-------------

Marked as reviewed by martin (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14868#pullrequestreview-1538218014

From liach at openjdk.org  Thu Jul 20 00:09:40 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Jul 2023 00:09:40 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v3]
In-Reply-To: <oTwWuqwMKS4_PL0jUF-seHdfaXwW0Iw0o3RuCrdSINc=.5bbe6422-d06a-4c18-88d9-41152058305c@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
 <oTwWuqwMKS4_PL0jUF-seHdfaXwW0Iw0o3RuCrdSINc=.5bbe6422-d06a-4c18-88d9-41152058305c@github.com>
Message-ID: <GsrkaPS8s1SbYYkJmsK5SGsuMGiAWarELKu5oP9QZP0=.82f61ca0-930e-47d1-84c6-124ef5ba752a@github.com>

On Wed, 19 Jul 2023 23:48:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported.   To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information.  Changes include:
>> 
>> 1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported.  This check is only needed for direct var handle.
>> 2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported
>> 
>> The error message looks like:
>> 
>> java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback from psandoz

Also just noticed copyright year of VarForm is still 2019; should be updated to 2023 with this patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14928#issuecomment-1642917567

From duke at openjdk.org  Thu Jul 20 00:29:47 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 20 Jul 2023 00:29:47 GMT
Subject: RFR: 8312164: Refactor Arrays.hashCode for long, boolean, double, 
 float, and Object arrays [v3]
In-Reply-To: <3ujN1ip4oHjoMrPmL8yV7-pgiOWvtyDQMLSke1kTQSY=.9547bc9a-2db3-4057-a2cb-aa874abd8a0b@github.com>
References: <2fzWrAYSsxemNshKqA4md_k78mO1gmUSvylsaDSf_7w=.c9b6c8b8-8204-4bb8-a7a0-2496e5d3cf38@github.com>
 <3ujN1ip4oHjoMrPmL8yV7-pgiOWvtyDQMLSke1kTQSY=.9547bc9a-2db3-4057-a2cb-aa874abd8a0b@github.com>
Message-ID: <YEOmDcCtN2gSWsO_tRxIWIc-L9qkYgh_gAZQ-fe23ts=.7757b0de-a7c4-4e61-b21e-e42d17a28e5d@github.com>

On Wed, 19 Jul 2023 13:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to refactor Arrays.hashCode for long[], boolean[], and Object[]. I've been told elsewhere that it shouldn't have significant performance implications.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix hashCode(float[])

I ran a JMH benchmark for this PR::


@Warmup(iterations = 5, time = 3)
@Measurement(iterations = 5, time = 2)
@Fork(value = 1, jvmArgsAppend = {"-XX:+UseG1GC", "-Xms8g", "-Xmx8g"})
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@State(Scope.Benchmark)
public class HashCode {
    @Param({"1", "10", "100", "10000"})
    private int size;

    private long[] longs;
    private boolean[] booleans;
    private float[] floats;
    private double[] doubles;
    private Object[] objects;

    @Setup
    public void setup() {
        longs = new long[size];
        booleans = new boolean[size];
        floats = new float[size];
        doubles = new double[size];
        objects = new Object[size];

        Random rnd = new Random(0);
        for (int i = 0; i < size; i++) {
            long next = rnd.nextLong();

            longs[i] = next;
            booleans[i] = next % 2 == 0;
            floats[i] = Float.intBitsToFloat((int) next);
            doubles[i] = Double.longBitsToDouble(next);
            objects[i] = (int) next;
        }
    }

    @Benchmark
    public int longs() {
        return Arrays.hashCode(longs);
    }

    @Benchmark
    public int booleans() {
        return Arrays.hashCode(booleans);
    }

    @Benchmark
    public int floats() {
        return Arrays.hashCode(floats);
    }

    @Benchmark
    public int doubles() {
        return Arrays.hashCode(doubles);
    }

    @Benchmark
    public int objects() {
        return Arrays.hashCode(objects);
    }
}



Result:

                                                 (Baseline)                        (This PR)   

Benchmark          (size)   Mode  Cnt       Score       Error   Units         Score       Error   Units
HashCode.booleans       1  thrpt    5  472358.594 ?  5037.260  ops/ms    473356.084 ?  1780.600  ops/ms
HashCode.booleans      10  thrpt    5  118457.276 ?   848.886  ops/ms    118470.818 ?   342.023  ops/ms
HashCode.booleans     100  thrpt    5   13140.346 ?    46.869  ops/ms     13153.643 ?     1.226  ops/ms
HashCode.booleans   10000  thrpt    5     133.090 ?     0.027  ops/ms       133.041 ?     0.032  ops/ms
HashCode.doubles        1  thrpt    5  438869.947 ?  1806.730  ops/ms    441611.989 ?   692.622  ops/ms
HashCode.doubles       10  thrpt    5   76418.134 ?    42.834  ops/ms     76432.141 ?   368.953  ops/ms
HashCode.doubles      100  thrpt    5    7364.920 ?     6.941  ops/ms      7339.776 ?    28.448  ops/ms
HashCode.doubles    10000  thrpt    5      76.689 ?     0.037  ops/ms        76.787 ?     0.188  ops/ms
HashCode.floats         1  thrpt    5  443741.068 ?  1773.736  ops/ms    444085.364 ?   557.545  ops/ms
HashCode.floats        10  thrpt    5   86047.878 ?   306.709  ops/ms     86306.681 ?   908.752  ops/ms
HashCode.floats       100  thrpt    5    8263.785 ?    37.091  ops/ms      8254.055 ?     3.427  ops/ms
HashCode.floats     10000  thrpt    5      86.146 ?     0.018  ops/ms        86.121 ?     0.022  ops/ms
HashCode.longs          1  thrpt    5  462198.590 ? 27224.002  ops/ms    460673.957 ? 26979.630  ops/ms
HashCode.longs         10  thrpt    5  124744.207 ?   262.268  ops/ms    130367.753 ?   257.766  ops/ms
HashCode.longs        100  thrpt    5   13552.607 ?     2.545  ops/ms     13454.362 ?     8.991  ops/ms
HashCode.longs      10000  thrpt    5     133.122 ?     0.038  ops/ms       133.114 ?     0.016  ops/ms
HashCode.objects        1  thrpt    5  230303.967 ?   919.637  ops/ms    647597.213 ?  2652.002  ops/ms
HashCode.objects       10  thrpt    5   25724.486 ?   111.422  ops/ms    121222.501 ?   270.073  ops/ms
HashCode.objects      100  thrpt    5    2497.018 ?     6.201  ops/ms     11889.717 ?   264.730  ops/ms
HashCode.objects    10000  thrpt    5      27.673 ?     0.012  ops/ms       130.903 ?     0.714  ops/ms


This PR looks great.

For primitive type arrays, there is no change in performance. But for arrays of objects, the performance is improved by about 370%.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14900#pullrequestreview-1538239479

From duke at openjdk.org  Thu Jul 20 00:37:55 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 20 Jul 2023 00:37:55 GMT
Subject: RFR: 8312164: Refactor Arrays.hashCode for long, boolean, double, 
 float, and Object arrays [v3]
In-Reply-To: <3ujN1ip4oHjoMrPmL8yV7-pgiOWvtyDQMLSke1kTQSY=.9547bc9a-2db3-4057-a2cb-aa874abd8a0b@github.com>
References: <2fzWrAYSsxemNshKqA4md_k78mO1gmUSvylsaDSf_7w=.c9b6c8b8-8204-4bb8-a7a0-2496e5d3cf38@github.com>
 <3ujN1ip4oHjoMrPmL8yV7-pgiOWvtyDQMLSke1kTQSY=.9547bc9a-2db3-4057-a2cb-aa874abd8a0b@github.com>
Message-ID: <OdQFqVO89etPRDq5-E66SeUjhudzEKHECPLecH8P_4g=.0bb27f6b-7dba-48cd-88e1-e7fb26816e4f@github.com>

On Wed, 19 Jul 2023 13:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to refactor Arrays.hashCode for long[], boolean[], and Object[]. I've been told elsewhere that it shouldn't have significant performance implications.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix hashCode(float[])

I ran a JMH benchmark for this PR:


@Warmup(iterations = 5, time = 3)
@Measurement(iterations = 5, time = 2)
@Fork(value = 1, jvmArgsAppend = {"-XX:+UseG1GC", "-Xms8g", "-Xmx8g"})
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@State(Scope.Benchmark)
public class HashCode {
    @Param({"1", "10", "100", "10000"})
    private int size;

    private long[] longs;
    private boolean[] booleans;
    private float[] floats;
    private double[] doubles;
    private Object[] objects;

    @Setup
    public void setup() {
        longs = new long[size];
        booleans = new boolean[size];
        floats = new float[size];
        doubles = new double[size];
        objects = new Object[size];

        Random rnd = new Random(0);
        for (int i = 0; i < size; i++) {
            long next = rnd.nextLong();

            longs[i] = next;
            booleans[i] = next % 2 == 0;
            floats[i] = Float.intBitsToFloat((int) next);
            doubles[i] = Double.longBitsToDouble(next);
            objects[i] = (int) next;
        }
    }

    @Benchmark
    public int longs() {
        return Arrays.hashCode(longs);
    }

    @Benchmark
    public int booleans() {
        return Arrays.hashCode(booleans);
    }

    @Benchmark
    public int floats() {
        return Arrays.hashCode(floats);
    }

    @Benchmark
    public int doubles() {
        return Arrays.hashCode(doubles);
    }

    @Benchmark
    public int objects() {
        return Arrays.hashCode(objects);
    }
}



Result:

                                                 (This PR)                        (Baseline)   

Benchmark          (size)   Mode  Cnt       Score       Error   Units         Score       Error   Units
HashCode.booleans       1  thrpt    5  472358.594 ?  5037.260  ops/ms    473356.084 ?  1780.600  ops/ms
HashCode.booleans      10  thrpt    5  118457.276 ?   848.886  ops/ms    118470.818 ?   342.023  ops/ms
HashCode.booleans     100  thrpt    5   13140.346 ?    46.869  ops/ms     13153.643 ?     1.226  ops/ms
HashCode.booleans   10000  thrpt    5     133.090 ?     0.027  ops/ms       133.041 ?     0.032  ops/ms
HashCode.doubles        1  thrpt    5  438869.947 ?  1806.730  ops/ms    441611.989 ?   692.622  ops/ms
HashCode.doubles       10  thrpt    5   76418.134 ?    42.834  ops/ms     76432.141 ?   368.953  ops/ms
HashCode.doubles      100  thrpt    5    7364.920 ?     6.941  ops/ms      7339.776 ?    28.448  ops/ms
HashCode.doubles    10000  thrpt    5      76.689 ?     0.037  ops/ms        76.787 ?     0.188  ops/ms
HashCode.floats         1  thrpt    5  443741.068 ?  1773.736  ops/ms    444085.364 ?   557.545  ops/ms
HashCode.floats        10  thrpt    5   86047.878 ?   306.709  ops/ms     86306.681 ?   908.752  ops/ms
HashCode.floats       100  thrpt    5    8263.785 ?    37.091  ops/ms      8254.055 ?     3.427  ops/ms
HashCode.floats     10000  thrpt    5      86.146 ?     0.018  ops/ms        86.121 ?     0.022  ops/ms
HashCode.longs          1  thrpt    5  462198.590 ? 27224.002  ops/ms    460673.957 ? 26979.630  ops/ms
HashCode.longs         10  thrpt    5  124744.207 ?   262.268  ops/ms    130367.753 ?   257.766  ops/ms
HashCode.longs        100  thrpt    5   13552.607 ?     2.545  ops/ms     13454.362 ?     8.991  ops/ms
HashCode.longs      10000  thrpt    5     133.122 ?     0.038  ops/ms       133.114 ?     0.016  ops/ms
HashCode.objects        1  thrpt    5  230303.967 ?   919.637  ops/ms    647597.213 ?  2652.002  ops/ms
HashCode.objects       10  thrpt    5   25724.486 ?   111.422  ops/ms    121222.501 ?   270.073  ops/ms
HashCode.objects      100  thrpt    5    2497.018 ?     6.201  ops/ms     11889.717 ?   264.730  ops/ms
HashCode.objects    10000  thrpt    5      27.673 ?     0.012  ops/ms       130.903 ?     0.714  ops/ms


I think there is a performance issue with this PR. For object arrays, the performance is reduced by about 80%.

(I got the result reversed in a previous comment, so I hid it.)

-------------

PR Review: https://git.openjdk.org/jdk/pull/14900#pullrequestreview-1538245804

From mchung at openjdk.org  Thu Jul 20 01:03:20 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 20 Jul 2023 01:03:20 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v26]
In-Reply-To: <hJ3dBq7oaRN8OtWTQS12mnGoAav0NlIuoezGYObY3b4=.624abdc9-d002-4589-933a-c43dbc474158@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <hJ3dBq7oaRN8OtWTQS12mnGoAav0NlIuoezGYObY3b4=.624abdc9-d002-4589-933a-c43dbc474158@github.com>
Message-ID: <Ixs0AaL3vPqUvfo6zuttZBYjqExun_f2i8E9pX_T3zk=.bd324461-bad6-4078-b449-f9e526a3aebe@github.com>

On Tue, 18 Jul 2023 01:57:56 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 54 commits:
> 
>  - Review class loader check, restore hidden class rejection spec
>  - Merge branch 'master' into explore/mhp-iface
>  - Review changees
>  - Fix the lazy test, thanks Jorn Vernee!
>  - Clean up impl comment, reorganize tests; weak ref broken
>  - Merge branch 'master' into explore/mhp-iface
>  - Fix broken null behaviors
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'mh-proxies' of https://github.com/mlchung/jdk into explore/mhp-iface
>  - store a WeakReference holder in the class value
>  - ... and 44 more: https://git.openjdk.org/jdk/compare/a53345ad...a12fba06

yes, I made some modification to the release note in particular the performance regression seems alarming.   If this becomes a real issue, we could change it to soft reference.

This is great work!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1642953064

From liach at openjdk.org  Thu Jul 20 01:03:22 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Jul 2023 01:03:22 GMT
Subject: Integrated: 6983726: Reimplement
 MethodHandleProxies.asInterfaceInstance
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <hS5I1zjBGKxK6nrzisxp06FNn6sZQt8v1S7Sp04W1gc=.0ec0187f-aee0-4b95-bab0-adfc82c594ca@github.com>

On Mon, 27 Mar 2023 23:34:52 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  ns/op
> MethodHandleProxiesAsIFInstanceCreate.createCallL...

This pull request has now been integrated.

Changeset: 5d57b5c2
Author:    Chen Liang <liach at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d57b5c2f0ef77f994fbc8c4f09e66f217f06f85
Stats:     1451 lines in 13 files changed: 1050 ins; 311 del; 90 mod

6983726: Reimplement MethodHandleProxies.asInterfaceInstance

Co-authored-by: Mandy Chung <mchung at openjdk.org>
Reviewed-by: jvernee, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/13197

From mchung at openjdk.org  Thu Jul 20 01:04:08 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 20 Jul 2023 01:04:08 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v4]
In-Reply-To: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
Message-ID: <QShP3BrYVmCo0PXBTGxc4VfdZzwtCSXccDASl3getg8=.328c111a-e693-408f-a693-404ff8f4f023@github.com>

> `VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported.   To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information.  Changes include:
> 
> 1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported.  This check is only needed for direct var handle.
> 2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported
> 
> The error message looks like:
> 
> java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  update copyright header

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14928/files
  - new: https://git.openjdk.org/jdk/pull/14928/files/9196ccb4..f82b2146

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14928&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14928&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14928/head:pull/14928

PR: https://git.openjdk.org/jdk/pull/14928

From duke at openjdk.org  Thu Jul 20 01:17:48 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 20 Jul 2023 01:17:48 GMT
Subject: RFR: 8312164: Refactor Arrays.hashCode for long, boolean, double, 
 float, and Object arrays [v3]
In-Reply-To: <3ujN1ip4oHjoMrPmL8yV7-pgiOWvtyDQMLSke1kTQSY=.9547bc9a-2db3-4057-a2cb-aa874abd8a0b@github.com>
References: <2fzWrAYSsxemNshKqA4md_k78mO1gmUSvylsaDSf_7w=.c9b6c8b8-8204-4bb8-a7a0-2496e5d3cf38@github.com>
 <3ujN1ip4oHjoMrPmL8yV7-pgiOWvtyDQMLSke1kTQSY=.9547bc9a-2db3-4057-a2cb-aa874abd8a0b@github.com>
Message-ID: <_4r0YwCB3B4j94rcPO1gHKtOQWFzBQ1OOpGUxjyeWOs=.2257d0fe-09f8-4b99-bc72-22e433161a27@github.com>

On Wed, 19 Jul 2023 13:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to refactor Arrays.hashCode for long[], boolean[], and Object[]. I've been told elsewhere that it shouldn't have significant performance implications.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix hashCode(float[])

I created #14944 to revert changes to `Arrays.hashCode(Object[])`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14900#issuecomment-1642963240

From duke at openjdk.org  Thu Jul 20 01:34:51 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 20 Jul 2023 01:34:51 GMT
Subject: RFR: 8312424: 80% throughput decrease in Arrays.hashCode(Object[])
 after JDK-8312164
Message-ID: <Xmw2EkJWc8jtAqIWB_GDEImqThcXUt6flEqPRQgfaVk=.be0d46d1-7833-4abb-903f-27129ac6f737@github.com>

The changes to `Arrays.hashCode(Object[])` in JDK-8312164 caused its performance  is reduced by about 80%.

This PR reverts this change.

-------------

Commit messages:
 - Add benchmark
 - Revert changes to Arrays.hashCode(Object[]) in JDK-8312164

Changes: https://git.openjdk.org/jdk/pull/14944/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14944&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312424
  Stats: 9 lines in 2 files changed: 8 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14944/head:pull/14944

PR: https://git.openjdk.org/jdk/pull/14944

From duke at openjdk.org  Thu Jul 20 01:34:52 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 20 Jul 2023 01:34:52 GMT
Subject: RFR: 8312424: 80% throughput decrease in Arrays.hashCode(Object[])
 after JDK-8312164
In-Reply-To: <Xmw2EkJWc8jtAqIWB_GDEImqThcXUt6flEqPRQgfaVk=.be0d46d1-7833-4abb-903f-27129ac6f737@github.com>
References: <Xmw2EkJWc8jtAqIWB_GDEImqThcXUt6flEqPRQgfaVk=.be0d46d1-7833-4abb-903f-27129ac6f737@github.com>
Message-ID: <xld3UjdwlprEGb__-JZs1x0a4N10ntUNDlkNfs-XPXY=.ec2a0687-5a65-4787-9ecf-dd06696adc44@github.com>

On Thu, 20 Jul 2023 01:11:43 GMT, Glavo <duke at openjdk.org> wrote:

> The changes to `Arrays.hashCode(Object[])` in JDK-8312164 caused its performance  is reduced by about 80%.
> 
> This PR reverts this change.

JMH Benchmark:


public class HashCode {
    @Param({"1", "10", "100", "10000"})
    private int size;

    private Object[] objects;

    @Setup
    public void setup() {
        objects = new Object[size];

        Random rnd = new Random(0);
        for (int i = 0; i < size; i++) {
            int next = rnd.nextInt();
            objects[i] = next;
        }
    }
    @Benchmark
    public int objects() {
        return Arrays.hashCode(objects);
    }
}



                                                (JDK-8312164)                      (This PR)
Benchmark         (size)   Mode  Cnt       Score      Error   Units           Score      Error   Units
HashCode.objects       1  thrpt    5  230185.853 ? 3452.863  ops/ms      646049.006 ? 3964.138  ops/ms
HashCode.objects      10  thrpt    5   25745.466 ?   38.342  ops/ms      121587.901 ? 1114.723  ops/ms
HashCode.objects     100  thrpt    5    2558.474 ?   21.726  ops/ms       11914.620 ?  233.365  ops/ms
HashCode.objects   10000  thrpt    5      27.592 ?    0.116  ops/ms         125.938 ?    0.145  ops/ms

> A similar performance decrease have been discussed here: [#14752 (comment)](https://github.com/openjdk/jdk/pull/14752#discussion_r1250888931)
> 
> Can you check whether adding `@ForceInline` on `Objects.equals` help with JIT? If it helps, then I think adding `@ForceInline` might be a better solution.

I added `@ForceInline` on `Objects.hashCode(Object)`, but the JMH results did not change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14944#issuecomment-1642962527
PR Comment: https://git.openjdk.org/jdk/pull/14944#issuecomment-1642971201

From liach at openjdk.org  Thu Jul 20 01:34:52 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Jul 2023 01:34:52 GMT
Subject: RFR: 8312424: 80% throughput decrease in Arrays.hashCode(Object[])
 after JDK-8312164
In-Reply-To: <Xmw2EkJWc8jtAqIWB_GDEImqThcXUt6flEqPRQgfaVk=.be0d46d1-7833-4abb-903f-27129ac6f737@github.com>
References: <Xmw2EkJWc8jtAqIWB_GDEImqThcXUt6flEqPRQgfaVk=.be0d46d1-7833-4abb-903f-27129ac6f737@github.com>
Message-ID: <spVFC8lNi2wbUaqW5q4XL_SVOb49FUEqrxBDep3dWSY=.9e871564-1640-40c5-9915-ad7e00bb6d17@github.com>

On Thu, 20 Jul 2023 01:11:43 GMT, Glavo <duke at openjdk.org> wrote:

> The changes to `Arrays.hashCode(Object[])` in JDK-8312164 caused its performance  is reduced by about 80%.
> 
> This PR reverts this change.

A similar performance decrease have been discussed here: https://github.com/openjdk/jdk/pull/14752#discussion_r1250888931

Can you check whether adding `@ForceInline` on `Objects.equals` help with JIT? If it helps, then I think adding `@ForceInline` might be a better solution.

Created JBS issue for you: https://bugs.openjdk.org/browse/JDK-8312424

I chose a generic title which applies to both reverting the last patch or updating Objects methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14944#issuecomment-1642966265
PR Comment: https://git.openjdk.org/jdk/pull/14944#issuecomment-1642971538

From liach at openjdk.org  Thu Jul 20 02:07:44 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Jul 2023 02:07:44 GMT
Subject: RFR: 8312424: 80% throughput decrease in Arrays.hashCode(Object[])
 after JDK-8312164
In-Reply-To: <xld3UjdwlprEGb__-JZs1x0a4N10ntUNDlkNfs-XPXY=.ec2a0687-5a65-4787-9ecf-dd06696adc44@github.com>
References: <Xmw2EkJWc8jtAqIWB_GDEImqThcXUt6flEqPRQgfaVk=.be0d46d1-7833-4abb-903f-27129ac6f737@github.com>
 <xld3UjdwlprEGb__-JZs1x0a4N10ntUNDlkNfs-XPXY=.ec2a0687-5a65-4787-9ecf-dd06696adc44@github.com>
Message-ID: <ETaIakZptacl_JmAh9iYD-aoDTitAUhK_-nFQFHhp1E=.75fc65b3-ab5f-46b1-a951-2a3800ca5c6f@github.com>

On Thu, 20 Jul 2023 01:27:41 GMT, Glavo <duke at openjdk.org> wrote:

>> The changes to `Arrays.hashCode(Object[])` in JDK-8312164 caused its performance  is reduced by about 80%.
>> 
>> This PR reverts this change.
>
>> A similar performance decrease have been discussed here: [#14752 (comment)](https://github.com/openjdk/jdk/pull/14752#discussion_r1250888931)
>> 
>> Can you check whether adding `@ForceInline` on `Objects.equals` help with JIT? If it helps, then I think adding `@ForceInline` might be a better solution.
> 
> I added `@ForceInline` on `Objects.hashCode(Object)`, but the JMH results did not change.

@Glavo I have created a test case with polymorphic objects in an array: https://github.com/liachmodded/jdk/tree/explore/arrays-hash-poly
Can you see if you can produce the same outcome on your patch, and how the existing `Objects.equals` behave on the polymorphicObjects case?


Benchmark               (size)  Mode  Cnt     Score    Error  Units
ArraysHashCode.objects       1  avgt   15     0.770 ?  0.011  ns/op
ArraysHashCode.objects      10  avgt   15     4.704 ?  0.059  ns/op
ArraysHashCode.objects     100  avgt   15    54.610 ?  0.384  ns/op
ArraysHashCode.objects   10000  avgt   15  6053.742 ? 35.244  ns/op



Benchmark                          (size)  Mode  Cnt      Score      Error  Units
ArraysHashCode.polymorphicObjects       1  avgt   15      0.921 ?    0.069  ns/op
ArraysHashCode.polymorphicObjects      10  avgt   15     23.322 ?    1.076  ns/op
ArraysHashCode.polymorphicObjects     100  avgt   15    211.325 ?    2.200  ns/op
ArraysHashCode.polymorphicObjects   10000  avgt   15  81850.916 ? 2427.661  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14944#issuecomment-1642998263

From asemenyuk at openjdk.org  Thu Jul 20 02:07:40 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 20 Jul 2023 02:07:40 GMT
Subject: RFR: JDK-8309032: jpackage does not work for module projects
 unless --module-path is specified
In-Reply-To: <ZHCWcpSLF1khyvrydxW8JarYKgYOj3B-9nnBVElWVpc=.4a345b50-7213-4e30-969e-280e3cd11575@github.com>
References: <ZHCWcpSLF1khyvrydxW8JarYKgYOj3B-9nnBVElWVpc=.4a345b50-7213-4e30-969e-280e3cd11575@github.com>
Message-ID: <RFcPz_HnPYIHlQWUlokZq5ut8npzt9Wq9MWWDUvnwkM=.092870f4-c801-4b10-8b71-125e538e087f@github.com>

On Tue, 11 Jul 2023 23:47:30 GMT, airsquared <duke at openjdk.org> wrote:

> [JDK-8309032](https://bugs.openjdk.org/browse/JDK-8309032), [JDK-8306488](https://bugs.openjdk.org/browse/JDK-8306488)

@sashamatveev would you like to review the change before I sponsor it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14840#issuecomment-1642998270

From almatvee at openjdk.org  Thu Jul 20 02:17:49 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 20 Jul 2023 02:17:49 GMT
Subject: RFR: JDK-8309032: jpackage does not work for module projects
 unless --module-path is specified
In-Reply-To: <ZHCWcpSLF1khyvrydxW8JarYKgYOj3B-9nnBVElWVpc=.4a345b50-7213-4e30-969e-280e3cd11575@github.com>
References: <ZHCWcpSLF1khyvrydxW8JarYKgYOj3B-9nnBVElWVpc=.4a345b50-7213-4e30-969e-280e3cd11575@github.com>
Message-ID: <TRiLnxVg2EV7GTPptAIFMgybnMCqP7SSyueJAcF-Xao=.436e863a-e68a-4d38-8f96-d0b4983a0dec@github.com>

On Tue, 11 Jul 2023 23:47:30 GMT, airsquared <duke at openjdk.org> wrote:

> [JDK-8309032](https://bugs.openjdk.org/browse/JDK-8309032), [JDK-8306488](https://bugs.openjdk.org/browse/JDK-8306488)

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14840#pullrequestreview-1538311227

From almatvee at openjdk.org  Thu Jul 20 02:17:50 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 20 Jul 2023 02:17:50 GMT
Subject: RFR: JDK-8309032: jpackage does not work for module projects
 unless --module-path is specified
In-Reply-To: <RFcPz_HnPYIHlQWUlokZq5ut8npzt9Wq9MWWDUvnwkM=.092870f4-c801-4b10-8b71-125e538e087f@github.com>
References: <ZHCWcpSLF1khyvrydxW8JarYKgYOj3B-9nnBVElWVpc=.4a345b50-7213-4e30-969e-280e3cd11575@github.com>
 <RFcPz_HnPYIHlQWUlokZq5ut8npzt9Wq9MWWDUvnwkM=.092870f4-c801-4b10-8b71-125e538e087f@github.com>
Message-ID: <-DbFKYwKhJhzWEjGw44T8fbNFwD-feSJ_xnvSNK32Wc=.665880a6-dcae-497f-aeb3-2e08a6b57260@github.com>

On Thu, 20 Jul 2023 02:04:53 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> [JDK-8309032](https://bugs.openjdk.org/browse/JDK-8309032), [JDK-8306488](https://bugs.openjdk.org/browse/JDK-8306488)
>
> @sashamatveev would you like to review the change before I sponsor it?

@alexeysemenyukoracle Looks good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14840#issuecomment-1643003305

From duke at openjdk.org  Thu Jul 20 02:17:51 2023
From: duke at openjdk.org (airsquared)
Date: Thu, 20 Jul 2023 02:17:51 GMT
Subject: Integrated: JDK-8309032: jpackage does not work for module projects
 unless --module-path is specified
In-Reply-To: <ZHCWcpSLF1khyvrydxW8JarYKgYOj3B-9nnBVElWVpc=.4a345b50-7213-4e30-969e-280e3cd11575@github.com>
References: <ZHCWcpSLF1khyvrydxW8JarYKgYOj3B-9nnBVElWVpc=.4a345b50-7213-4e30-969e-280e3cd11575@github.com>
Message-ID: <yEBPS3lX8boUvLdprE8Xj__c2oQQ_J_zsY9CO9ZPoVs=.82482633-54d7-4900-8072-59d2c388ff9c@github.com>

On Tue, 11 Jul 2023 23:47:30 GMT, airsquared <duke at openjdk.org> wrote:

> [JDK-8309032](https://bugs.openjdk.org/browse/JDK-8309032), [JDK-8306488](https://bugs.openjdk.org/browse/JDK-8306488)

This pull request has now been integrated.

Changeset: dfe764e3
Author:    airsquared <36649395+airsquared at users.noreply.github.com>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dfe764e3f85784752d69fd51306644732e808d38
Stats:     16 lines in 1 file changed: 0 ins; 8 del; 8 mod

8309032: jpackage does not work for module projects unless --module-path is specified

Reviewed-by: asemenyuk, almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/14840

From duke at openjdk.org  Thu Jul 20 02:38:40 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 20 Jul 2023 02:38:40 GMT
Subject: RFR: 8312424: 80% throughput decrease in Arrays.hashCode(Object[])
 after JDK-8312164
In-Reply-To: <ETaIakZptacl_JmAh9iYD-aoDTitAUhK_-nFQFHhp1E=.75fc65b3-ab5f-46b1-a951-2a3800ca5c6f@github.com>
References: <Xmw2EkJWc8jtAqIWB_GDEImqThcXUt6flEqPRQgfaVk=.be0d46d1-7833-4abb-903f-27129ac6f737@github.com>
 <xld3UjdwlprEGb__-JZs1x0a4N10ntUNDlkNfs-XPXY=.ec2a0687-5a65-4787-9ecf-dd06696adc44@github.com>
 <ETaIakZptacl_JmAh9iYD-aoDTitAUhK_-nFQFHhp1E=.75fc65b3-ab5f-46b1-a951-2a3800ca5c6f@github.com>
Message-ID: <sEpKmAI1RlUZiGp1syXmN4O99nFkwlZDe6DtJg0Yf0A=.04590141-a3c4-4f4b-9226-d241872fba6a@github.com>

On Thu, 20 Jul 2023 02:04:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>>> A similar performance decrease have been discussed here: [#14752 (comment)](https://github.com/openjdk/jdk/pull/14752#discussion_r1250888931)
>>> 
>>> Can you check whether adding `@ForceInline` on `Objects.equals` help with JIT? If it helps, then I think adding `@ForceInline` might be a better solution.
>> 
>> I added `@ForceInline` on `Objects.hashCode(Object)`, but the JMH results did not change.
>
> @Glavo I have created a test case with polymorphic objects in an array: https://github.com/liachmodded/jdk/tree/explore/arrays-hash-poly
> Can you see if you can produce the same outcome on your patch, and how the existing `Objects.equals` behave on the polymorphicObjects case?
> 
> 
> Benchmark               (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.objects       1  avgt   15     0.770 ?  0.011  ns/op
> ArraysHashCode.objects      10  avgt   15     4.704 ?  0.059  ns/op
> ArraysHashCode.objects     100  avgt   15    54.610 ?  0.384  ns/op
> ArraysHashCode.objects   10000  avgt   15  6053.742 ? 35.244  ns/op
> 
> 
> 
> Benchmark                          (size)  Mode  Cnt      Score      Error  Units
> ArraysHashCode.polymorphicObjects       1  avgt   15      0.921 ?    0.069  ns/op
> ArraysHashCode.polymorphicObjects      10  avgt   15     23.322 ?    1.076  ns/op
> ArraysHashCode.polymorphicObjects     100  avgt   15    211.325 ?    2.200  ns/op
> ArraysHashCode.polymorphicObjects   10000  avgt   15  81850.916 ? 2427.661  ns/op

@liach 

JMH Result:


                                                           (JDK-8312164)                  (This PR)
Benchmark                    (size)   Mode  Cnt       Score    Error   Units         Score      Error   Units
HashCode.polymorphicObjects       1  thrpt    5  148056.877 ?  8.046  ops/ms    546370.781 ? 2682.146  ops/ms
HashCode.polymorphicObjects      10  thrpt    5   21207.629 ? 39.585  ops/ms     21491.320 ?   66.698  ops/ms
HashCode.polymorphicObjects     100  thrpt    5    1467.886 ? 21.025  ops/ms      1509.838 ?   11.098  ops/ms
HashCode.polymorphicObjects   10000  thrpt    5       9.037 ?  0.006  ops/ms         9.123 ?    0.022  ops/ms


It looks like calling `Objects.hashCode(Object)` is preventing the JIT from monomorphizing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14944#issuecomment-1643016889

From duke at openjdk.org  Thu Jul 20 02:41:38 2023
From: duke at openjdk.org (airsquared)
Date: Thu, 20 Jul 2023 02:41:38 GMT
Subject: [jdk21] RFR: 8309032: jpackage does not work for module projects
 unless --module-path is specified
Message-ID: <H9una8oci7mgFejlqQHPTMQjMXcHr8eG3A1dNMzUwjg=.24a2b5bb-0918-487f-8bec-c3809f6376c3@github.com>

8309032: jpackage does not work for module projects unless --module-path is specified

-------------

Commit messages:
 - Backport dfe764e3f85784752d69fd51306644732e808d38

Changes: https://git.openjdk.org/jdk21/pull/140/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=140&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309032
  Stats: 16 lines in 1 file changed: 0 ins; 8 del; 8 mod
  Patch: https://git.openjdk.org/jdk21/pull/140.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/140/head:pull/140

PR: https://git.openjdk.org/jdk21/pull/140

From dholmes at openjdk.org  Thu Jul 20 02:52:43 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Jul 2023 02:52:43 GMT
Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6 [v6]
In-Reply-To: <Cq7TUnTv1VVlbeQTY3OtZD7YRt2KqIRushB7TPVvKFc=.267974d1-df00-4559-86aa-f117db520f25@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
 <Cq7TUnTv1VVlbeQTY3OtZD7YRt2KqIRushB7TPVvKFc=.267974d1-df00-4559-86aa-f117db520f25@github.com>
Message-ID: <nPOpzq8JP78doLCFXm7rWLMpCMZCugbAxm8XUYoEJJU=.3522d26f-0331-4e3a-99b7-d297f4087197@github.com>

On Wed, 19 Jul 2023 10:58:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229.
>> 
>> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove -Xdebug usage from SourceDebugExtension test

Sorry for being late to the party :) Looks good. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14918#pullrequestreview-1538335630

From duke at openjdk.org  Thu Jul 20 03:03:01 2023
From: duke at openjdk.org (airsquared)
Date: Thu, 20 Jul 2023 03:03:01 GMT
Subject: RFR: JDK-8309032: jpackage does not work for module projects
 unless --module-path is specified
In-Reply-To: <ZHCWcpSLF1khyvrydxW8JarYKgYOj3B-9nnBVElWVpc=.4a345b50-7213-4e30-969e-280e3cd11575@github.com>
References: <ZHCWcpSLF1khyvrydxW8JarYKgYOj3B-9nnBVElWVpc=.4a345b50-7213-4e30-969e-280e3cd11575@github.com>
Message-ID: <aNKFzhgnSTqcVfYm-ou_cyhMwJxFarlyWmb47ikzwd4=.7df5fac7-3e95-4d0d-a841-85e829963d5d@github.com>

On Tue, 11 Jul 2023 23:47:30 GMT, airsquared <duke at openjdk.org> wrote:

> [JDK-8309032](https://bugs.openjdk.org/browse/JDK-8309032), [JDK-8306488](https://bugs.openjdk.org/browse/JDK-8306488)

This also resolved [JDK-8306488](https://bugs.openjdk.org/browse/JDK-8306488), if someone can mark it as such.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14840#issuecomment-1643032180

From alanb at openjdk.org  Thu Jul 20 06:09:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Jul 2023 06:09:42 GMT
Subject: RFR: 8312414: Make java.util.ServiceLoader.LANG_ACCESS final
In-Reply-To: <qWcyYb8lp5Vr1wwxc_TsCoLilVENs7RKj5kGl4HpYzw=.ad9a8ed8-df06-4f66-b260-a5dac50f2418@github.com>
References: <qWcyYb8lp5Vr1wwxc_TsCoLilVENs7RKj5kGl4HpYzw=.ad9a8ed8-df06-4f66-b260-a5dac50f2418@github.com>
Message-ID: <2Me7aDFA1olsGW8AIJ0_RGRT0bsRBQvMyNdy995xc3Q=.0b952e9c-6412-4fde-8792-e97070fe63ed@github.com>

On Tue, 18 Jul 2023 20:06:56 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found opportunity to make static `ServiceLoader.LANG_ACCESS` field `final`.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14926#pullrequestreview-1538485598

From alanb at openjdk.org  Thu Jul 20 06:19:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Jul 2023 06:19:46 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
Message-ID: <Dn3kkrQoIDLlObI1Wdj-sZrITd2tSxweeoX2lZ7XN2E=.3c82dab2-d033-4730-9157-da9152254b9a@github.com>

On Thu, 13 Jul 2023 23:05:48 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 with a new target base 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 'openjdk:master' into unsafe
>  - add 8310843 to @bug
>  - 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
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/1673465d...cb56e736

I don't think this change should be integrated without further discussion on what problems you are running into. Code that runs is initPhase1 needs to have as few dependences as possible and can use Unsafe directly when needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1643312489

From jpai at openjdk.org  Thu Jul 20 07:57:39 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Jul 2023 07:57:39 GMT
Subject: RFR: 8312414: Make java.util.ServiceLoader.LANG_ACCESS final
In-Reply-To: <qWcyYb8lp5Vr1wwxc_TsCoLilVENs7RKj5kGl4HpYzw=.ad9a8ed8-df06-4f66-b260-a5dac50f2418@github.com>
References: <qWcyYb8lp5Vr1wwxc_TsCoLilVENs7RKj5kGl4HpYzw=.ad9a8ed8-df06-4f66-b260-a5dac50f2418@github.com>
Message-ID: <UtuTBQvTwm-KO37Y1pvP79X2aTR-ZbrECGy0zPJHrJE=.089868e0-203b-4e1b-8e81-aaccc7baed03@github.com>

On Tue, 18 Jul 2023 20:06:56 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found opportunity to make static `ServiceLoader.LANG_ACCESS` field `final`.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14926#pullrequestreview-1538660335

From jpai at openjdk.org  Thu Jul 20 08:01:41 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Jul 2023 08:01:41 GMT
Subject: RFR: 8312320: Remove javax/rmi/ssl/SSLSocketParametersTest.sh from
 ProblemList
In-Reply-To: <GsQwDfuaSsl5wm01SuSdvA7f5U56_8BLDmnQ7kqWUvY=.c6731bf6-2974-4269-80a1-90e37a7fed59@github.com>
References: <GsQwDfuaSsl5wm01SuSdvA7f5U56_8BLDmnQ7kqWUvY=.c6731bf6-2974-4269-80a1-90e37a7fed59@github.com>
Message-ID: <ca74dbVeeoCjyUzAyGAYhcOIQYOSL35cFk3uhGq-WcQ=.7d26ebd6-68f8-420b-9dd7-3778a09a7302@github.com>

On Wed, 19 Jul 2023 12:58:43 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR removes javax/rmi/ssl/SSLSocketParametersTest.sh from the ProblemList. The script was removed in JDK-8298939 and the Java code refactored to be a jtreg test.

Looks fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14933#pullrequestreview-1538675460

From liach at openjdk.org  Thu Jul 20 08:22:46 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Jul 2023 08:22:46 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
Message-ID: <wuq46Lx6TRHM3aPXmA1Ixprx-P2Z54lOWoylIwQxtxQ=.dcaea27f-43a6-4e9a-9ab6-ef78890fbaba@github.com>

On Thu, 13 Jul 2023 23:05:48 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 with a new target base 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 'openjdk:master' into unsafe
>  - add 8310843 to @bug
>  - 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
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/0a426cd6...cb56e736

This patch merely allows `ByteArray` and `ByteArrayLittleEndian` to be used before `VarHandle` is ready. An example is the Classfile API (which will be used to generate `LambdaForm`s for `VarHandle`), as shown in #14637.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1643489302

From duke at openjdk.org  Thu Jul 20 08:26:59 2023
From: duke at openjdk.org (duke)
Date: Thu, 20 Jul 2023 08:26:59 GMT
Subject: Withdrawn: 8174722: Wrong behavior of DecimalFormat with
 RoundingMode.UP in special case
In-Reply-To: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
Message-ID: <uACzUIIlGzNNhCXOuGY45jzmPgqJjrgvuKTTpFZ0Ptg=.0d30a954-b573-4d4a-bdee-92d1fcd37ccc@github.com>

On Tue, 23 May 2023 23:16:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which addresses a case where Decimal Format would violate certain RoundingMode contracts given the right pattern and double.
> 
> For example,
> 
> 
> DecimalFormat df = new DecimalFormat();
> df.setRoundingMode(RoundingMode.UP);
> double small = 0.0001;
> double big = 1.0001;
> df.applyPattern("0.00");
> df.format(small); // returns 0.00, which violates UP
> df.format(big); // returns 1.01, which does not violate UP
> 
> 
> In this example `0.0001` becomes `0.00`, a decrease in magnitude. This violates the RoundingMode.UP contract as RoundingMode.UP states "Note that this rounding mode never decreases the magnitude of the calculated value."
> 
> This edge case is a result of when values smaller than the absolute value of `.1` have more leading zeros between the decimal and the first non-zero digit (_0.0001 -> **3**_) than maximum fractional digits in the pattern (_0.00 -> **2**_).
> 
> The change to Decimal Format ensures that during this case, the rounding mode is considered before truncation, which dictates if the formatted number should insert a 1 in the least significant digit location.
> 
> The test validates the change by using data from larger counterparts. For example, If we are testing `0.0009`, we can format `1.0009` with the same pattern and mode that we use on `0.0009`, then compare the fractional portions to each other and ensure they are equal.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14110

From alanb at openjdk.org  Thu Jul 20 08:33:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Jul 2023 08:33:49 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
Message-ID: <HsqHYDzVeCGEuKfs_Va8Ej1yCt0eBT7b9pNAslTCG8M=.83ea3552-d759-4320-af79-a3621bb5989a@github.com>

On Thu, 13 Jul 2023 23:05:48 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 with a new target base 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 'openjdk:master' into unsafe
>  - add 8310843 to @bug
>  - 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
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/1d09702e...cb56e736

src/java.base/share/classes/jdk/internal/util/ByteArray.java line 49:

> 47:      * can be used in fundamental classes, {@code VarHandle} exercise many other
> 48:      * code at VM startup, this could lead a recursive calls when fundamental
> 49:      * classes is used in {@code VarHandle}.

This comment is confusing. If this code is changed then the comment can be very simple to say that it uses Unsafe to allow it be used in early startup and the VarHandle implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269126431

From asotona at openjdk.org  Thu Jul 20 09:11:20 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 20 Jul 2023 09:11:20 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v11]
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: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@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 227 commits:

 - Merge branch 'master' into JDK-8294969-javap
 - Merge branch 'master' into JDK-8294969-javap
 - fixed code printing and ConstantPoolException reporting indoex
 - added DydnamicConstantPoolEntry::bootstrapMethodIndex
   fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
 - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead
 - 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
 - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b

-------------

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=10
  Stats: 3830 lines in 29 files changed: 1001 ins; 1701 del; 1128 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 duke at openjdk.org  Thu Jul 20 09:22:48 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 20 Jul 2023 09:22:48 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v12]
In-Reply-To: <6Z9eOwWQA7NeLDOsYW0Oh373ArzaZIGk0JaWFGWfOj4=.40bb7830-6405-4d3e-9a4e-e17b3b066871@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <PNhV9fuNjZQCC0FbZvfucuaf3D3b0FYap0z_J8mSyTA=.6b3d7540-f908-4e33-ac37-cdad1899fd80@github.com>
 <6Z9eOwWQA7NeLDOsYW0Oh373ArzaZIGk0JaWFGWfOj4=.40bb7830-6405-4d3e-9a4e-e17b3b066871@github.com>
Message-ID: <RlmJSoieagc9Zn-QHqwqt8J7o6egUYIuls-42vEcaus=.a62e526a-b771-4df9-ac27-3bb27f21fd85@github.com>

On Mon, 17 Jul 2023 20:54:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Integer/Long toString test against compact strings
>>   
>>   Co-authored-by: liach <liach at users.noreply.github.com>
>
> src/java.base/share/classes/java/lang/Long.java line 559:
> 
>> 557:                     Unsafe.ARRAY_BYTE_BASE_OFFSET + charPos,
>> 558:                     Integer.PACKED_DIGITS[(int)((q * 100) - i)],
>> 559:                     false);
> 
> Add the array bound check for the store of the characters.

I added assert with reference to the implementation of StringUTF16#putChar, is this safe enough?

> src/java.base/share/classes/java/lang/Long.java line 584:
> 
>> 582:                     Unsafe.ARRAY_BYTE_BASE_OFFSET + charPos,
>> 583:                     Integer.PACKED_DIGITS[-i2],
>> 584:                     false);
> 
> Replace the implicit array bounds check with an explicit array index check if using Unsafe.

I added assert with reference to the implementation of StringUTF16#putChar, is this safe enough?

> src/java.base/share/classes/java/lang/StringUTF16.java line 1595:
> 
>> 1593:                     PACKED_DIGITS_UTF16[-i]);
>> 1594:         } else {
>> 1595:             putChar(buf, --charPos, '0' - i);
> 
> Ditto add explicit array bounds check when using Unsafe, especially since the method is used outside of the source file.  Here and in the uses of Unsafe below.

I added assert with reference to the implementation of StringUTF16#putChar, is this safe enough?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1269188797
PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1269188920
PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1269189024

From mcimadamore at openjdk.org  Thu Jul 20 09:28:46 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 09:28:46 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
Message-ID: <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>

On Thu, 13 Jul 2023 23:05:48 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 with a new target base 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 'openjdk:master' into unsafe
>  - add 8310843 to @bug
>  - 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
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/7d6c3848...cb56e736

src/java.base/share/classes/jdk/internal/util/ByteArray.java line 54:

> 52: 
> 53:     @ForceInline
> 54:     static long arrayOffset(byte[] array, int typeBytes, int offset) {

IMHO, this is the really interesting thing that this class does - e.g. it introduces a way to translate a (logical) offset into a byte array into a physical offset that can be used for unsafe. After you have an helper method like this, it seems like the client can just do what it wants by using Unsafe directly (which would remove the need for having this class) ? Was some experiment of that kind done (e.g. replacing usage of ByteArray with Unsafe + helpers) - or does it lead to code that is too cumbersome on the client?

Also, were ByteBuffers considered as an alternative? (I'm not suggesting MemorySegment as those depend on VarHandle again, but a heap ByteBuffer is just a thin wrapper around an array which uses Unsafe). ByteBuffer will have a bound check, but so does your code (which call checkIndex). I believe that, at least in hot code, wrapping a ByteBuffer around a byte array should be routinely scalarized, as there's no control flow inside these little methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269195526

From mcimadamore at openjdk.org  Thu Jul 20 09:35:51 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 09:35:51 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
Message-ID: <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>

On Thu, 20 Jul 2023 09:25:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 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 15 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into unsafe
>>  - add 8310843 to @bug
>>  - 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
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/3f1edf8c...cb56e736
>
> src/java.base/share/classes/jdk/internal/util/ByteArray.java line 54:
> 
>> 52: 
>> 53:     @ForceInline
>> 54:     static long arrayOffset(byte[] array, int typeBytes, int offset) {
> 
> IMHO, this is the really interesting thing that this class does - e.g. it introduces a way to translate a (logical) offset into a byte array into a physical offset that can be used for unsafe. After you have an helper method like this, it seems like the client can just do what it wants by using Unsafe directly (which would remove the need for having this class) ? Was some experiment of that kind done (e.g. replacing usage of ByteArray with Unsafe + helpers) - or does it lead to code that is too cumbersome on the client?
> 
> Also, were ByteBuffers considered as an alternative? (I'm not suggesting MemorySegment as those depend on VarHandle again, but a heap ByteBuffer is just a thin wrapper around an array which uses Unsafe). ByteBuffer will have a bound check, but so does your code (which call checkIndex). I believe that, at least in hot code, wrapping a ByteBuffer around a byte array should be routinely scalarized, as there's no control flow inside these little methods.

Actually, a byte buffer is big endian, so some extra code would be required. But maybe that's another helper function:


@ForceInline
ByteBuffer asBuffer(byte[] array) { return ByteBuffer.wrap(array).order(ByteOrder.nativeOrder()); }


And then replace:


ByteArray.getChar(array, 42)

With

asBuffer(array).getChar(42);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269204424

From mcimadamore at openjdk.org  Thu Jul 20 09:41:46 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 09:41:46 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
Message-ID: <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>

On Thu, 20 Jul 2023 09:33:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/ByteArray.java line 54:
>> 
>>> 52: 
>>> 53:     @ForceInline
>>> 54:     static long arrayOffset(byte[] array, int typeBytes, int offset) {
>> 
>> IMHO, this is the really interesting thing that this class does - e.g. it introduces a way to translate a (logical) offset into a byte array into a physical offset that can be used for unsafe. After you have an helper method like this, it seems like the client can just do what it wants by using Unsafe directly (which would remove the need for having this class) ? Was some experiment of that kind done (e.g. replacing usage of ByteArray with Unsafe + helpers) - or does it lead to code that is too cumbersome on the client?
>> 
>> Also, were ByteBuffers considered as an alternative? (I'm not suggesting MemorySegment as those depend on VarHandle again, but a heap ByteBuffer is just a thin wrapper around an array which uses Unsafe). ByteBuffer will have a bound check, but so does your code (which call checkIndex). I believe that, at least in hot code, wrapping a ByteBuffer around a byte array should be routinely scalarized, as there's no control flow inside these little methods.
>
> Actually, a byte buffer is big endian, so some extra code would be required. But maybe that's another helper function:
> 
> 
> @ForceInline
> ByteBuffer asBuffer(byte[] array) { return ByteBuffer.wrap(array).order(ByteOrder.nativeOrder()); }
> 
> 
> And then replace:
> 
> 
> ByteArray.getChar(array, 42)
> 
> With
> 
> asBuffer(array).getChar(42);

Also... in a lot of cases where ByteArray is used (DataXYZStream, ObjectXYZStream) the array being used is a field in the class. So the byte buffer creation can definitively be amortized (or the code changed to work on buffers instead of arrays).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269210990

From mcimadamore at openjdk.org  Thu Jul 20 09:54:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 09:54:55 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe
In-Reply-To: <4a_HN7D6FVCe6AA-WTq21CdpwxVFkaJ7GV5T3VX3oME=.38c380bd-7bb8-4e61-8122-8940466c39f4@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <4a_HN7D6FVCe6AA-WTq21CdpwxVFkaJ7GV5T3VX3oME=.38c380bd-7bb8-4e61-8122-8940466c39f4@github.com>
Message-ID: <D5TEQCTUFaMXYQgilPUpvqUuJaeb3RBbhCzNpKtt_gc=.abb34f64-14bd-442c-807f-521759c194ef@github.com>

On Sat, 24 Jun 2023 09:02:59 GMT, Chen Liang <liach at openjdk.org> wrote:

> 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.

Is `BufWriterImpl` what you are looking to refactor using this class? Any reason why that implementation doesn't internally rely on a ByteBuffer, rather than a plain array?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1643621178

From dl at openjdk.org  Thu Jul 20 10:26:03 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 20 Jul 2023 10:26:03 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v8]
In-Reply-To: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
Message-ID: <QXX0pY3HHUHnMCJQ-c_JSBRJmpe8_3KcYLscidPPNK0=.f36819ab-1fb7-4a18-ad38-c2829b385b89@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:

  nitpicks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14317/files
  - new: https://git.openjdk.org/jdk/pull/14317/files/94148271..b5e7e8b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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  Thu Jul 20 10:26:09 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 20 Jul 2023 10:26:09 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v6]
In-Reply-To: <4-71z8kuGt3rOGevC2jvr1okpbsQmfz1cTwhRLzlJww=.76e52580-c721-4e47-bec3-7bacbe63ae33@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <JLu2abTrdYaA72UojilLoZe14xxNRQUAAnS_G9pGNpY=.3692be64-289d-4562-b089-e5d9b50df928@github.com>
 <4-71z8kuGt3rOGevC2jvr1okpbsQmfz1cTwhRLzlJww=.76e52580-c721-4e47-bec3-7bacbe63ae33@github.com>
Message-ID: <JrtqO72hl9pYfl9OtALLVh27gzc8pyI_2goqcJ6Mo9Q=.cac910b3-5935-4817-b1de-3d459af9575d@github.com>

On Mon, 17 Jul 2023 14:45:57 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> 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 seven additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8301341
>>  - Simplify contention handling; fix test
>>  - Fix inverted test assert; improve internal documentation; simplify code
>>  - 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
>
> src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java line 232:
> 
>> 230:      * The transferer. (See below about serialization.)
>> 231:      */
>> 232:     private transient final Transferer<E> transferer;
> 
> let's use blessed modifiers order
> Suggestion:
> 
>     private final transient Transferer<E> transferer;

Thanks. Done

> src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java line 234:
> 
>> 232:     private transient final Transferer<E> transferer;
>> 233: 
>> 234:     private transient final boolean fair;
> 
> nit
> Suggestion:
> 
>     private final transient boolean fair;

Thanks. Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1269256519
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1269257030

From liach at openjdk.org  Thu Jul 20 10:33:44 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Jul 2023 10:33:44 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe
In-Reply-To: <D5TEQCTUFaMXYQgilPUpvqUuJaeb3RBbhCzNpKtt_gc=.abb34f64-14bd-442c-807f-521759c194ef@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <4a_HN7D6FVCe6AA-WTq21CdpwxVFkaJ7GV5T3VX3oME=.38c380bd-7bb8-4e61-8122-8940466c39f4@github.com>
 <D5TEQCTUFaMXYQgilPUpvqUuJaeb3RBbhCzNpKtt_gc=.abb34f64-14bd-442c-807f-521759c194ef@github.com>
Message-ID: <aeThBRLsL-kuikU_ZOcbrKwN0uLHNXUx_Ojpxof9LRI=.5a6c06bc-0102-4285-a796-4f650f04dfdb@github.com>

On Thu, 20 Jul 2023 09:51:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Is `BufWriterImpl` what you are looking to refactor using this class? Any reason why that implementation doesn't internally rely on a ByteBuffer, rather than a plain array?

Good point. Not only that, `ClassReaderImpl` should be migrated to read U2/S2 and U4/S4 via `ByteBuffer` as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1643674651

From liach at openjdk.org  Thu Jul 20 10:33:45 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Jul 2023 10:33:45 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
Message-ID: <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>

On Thu, 20 Jul 2023 09:39:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Actually, a byte buffer is big endian, so some extra code would be required. But maybe that's another helper function:
>> 
>> 
>> @ForceInline
>> ByteBuffer asBuffer(byte[] array) { return ByteBuffer.wrap(array).order(ByteOrder.nativeOrder()); }
>> 
>> 
>> And then replace:
>> 
>> 
>> ByteArray.getChar(array, 42)
>> 
>> With
>> 
>> asBuffer(array).getChar(42);
>
> Also... in a lot of cases where ByteArray is used (DataXYZStream, ObjectXYZStream) the array being used is a field in the class. So the byte buffer creation can definitively be amortized (or the code changed to work on buffers instead of arrays).

The Unsafe-based writing will be used by `Integer.toString` and `Long.toString` as well; in those cases, will creating a ByteBuffer wrapper be overkill?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269265267

From dl at openjdk.org  Thu Jul 20 10:49:43 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 20 Jul 2023 10:49:43 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v8]
In-Reply-To: <QXX0pY3HHUHnMCJQ-c_JSBRJmpe8_3KcYLscidPPNK0=.f36819ab-1fb7-4a18-ad38-c2829b385b89@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <QXX0pY3HHUHnMCJQ-c_JSBRJmpe8_3KcYLscidPPNK0=.f36819ab-1fb7-4a18-ad38-c2829b385b89@github.com>
Message-ID: <touSIfxXOhMucmd6rs0KRpaYOPTqOooSZFLG4IKBUdc=.000882b9-74fe-47e4-93e1-76e85ff12e84@github.com>

On Thu, 20 Jul 2023 10:26:03 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This update addresses performance issues across both LinkedTransferQueue and SynchronousQueue by creating a common basis for implementation across them (mainly in LinkedTransferQueue).  Pasting from internal doc summary of changes:
>>      * * Class DualNode replaces Qnode, with fields and methods
>>      *   that apply to any match-based dual data structure, and now
>>      *   usable in other j.u.c classes. in particular, SynchronousQueue.
>>      * * Blocking control (in class DualNode) accommodates
>>      *   VirtualThreads and (perhaps virtualized) uniprocessors.
>>      * * All fields of this class (LinkedTransferQueue) are
>>      *   default-initializable (to null), allowing further extension
>>      *   (in particular, SynchronousQueue.Transferer)
>>      * * Head and tail fields are lazily initialized rather than set
>>      *   to a dummy node, while also reducing retries under heavy
>>      *   contention and misorderings, and relaxing some accesses,
>>      *   requiring accommodation in many places (as well as
>>      *   adjustments in WhiteBox tests).
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nitpicks

A backport note: This set of changes may be applied jdk19+ by removing only the lines (currently L423-424) in LinkedTransferQueue:
            if w.isVirtual())             // don't spin
                spin = false;

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14317#issuecomment-1643696658

From mdonovan at openjdk.org  Thu Jul 20 11:10:48 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 20 Jul 2023 11:10:48 GMT
Subject: Integrated: 8312320: Remove javax/rmi/ssl/SSLSocketParametersTest.sh
 from ProblemList
In-Reply-To: <GsQwDfuaSsl5wm01SuSdvA7f5U56_8BLDmnQ7kqWUvY=.c6731bf6-2974-4269-80a1-90e37a7fed59@github.com>
References: <GsQwDfuaSsl5wm01SuSdvA7f5U56_8BLDmnQ7kqWUvY=.c6731bf6-2974-4269-80a1-90e37a7fed59@github.com>
Message-ID: <KnoqxquQQn3VXz07Dtc4q5JLs0LmzK5DlGfHdA60X1w=.97eed98e-998c-4921-b4e6-7ac0fcea0342@github.com>

On Wed, 19 Jul 2023 12:58:43 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR removes javax/rmi/ssl/SSLSocketParametersTest.sh from the ProblemList. The script was removed in JDK-8298939 and the Java code refactored to be a jtreg test.

This pull request has now been integrated.

Changeset: 8d293291
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d29329138d44800ee4c0c02dacc01a06097de66
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8312320: Remove javax/rmi/ssl/SSLSocketParametersTest.sh from ProblemList

Reviewed-by: xuelei, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/14933

From dl at openjdk.org  Thu Jul 20 11:32:45 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 20 Jul 2023 11:32:45 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v5]
In-Reply-To: <YvSbGVe6xc6hllC71O8smG3nJa_IOWl3sPTzFXM_EGs=.f5a123ca-8c87-44d8-a918-f3383911d05d@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <7Imcm_Lg2tLsQs1UdndLA6xKrfRBSTRThh3LcULgpzY=.245e0de8-1035-4778-851d-12bd3d43559f@github.com>
 <YvSbGVe6xc6hllC71O8smG3nJa_IOWl3sPTzFXM_EGs=.f5a123ca-8c87-44d8-a918-f3383911d05d@github.com>
Message-ID: <nb5g533pUTIxGYuvOOXfD1e3y2Far9fyFWfpXvC1pqM=.5a01ed11-53f2-4c3e-8727-cef75e5568e3@github.com>

On Fri, 7 Jul 2023 13:45:25 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> 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
>
> src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 484:
> 
>> 482:      * be at least 4.
>> 483:      */
>> 484:     private static final int MAX_SLACK = 1 << 7;
> 
> @DougLea Any guidance on how to tune this parameter? ?

I removed this after finding ways to reduce slack accumulation so it isn't needed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1269328732

From alanb at openjdk.org  Thu Jul 20 13:37:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Jul 2023 13:37:44 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
Message-ID: <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>

On Thu, 20 Jul 2023 10:29:25 GMT, Chen Liang <liach at openjdk.org> wrote:

> The Unsafe-based writing will be used by `Integer.toString` and `Long.toString` as well; in those cases, will creating a ByteBuffer wrapper be overkill?

Integer/Long are very core classes so I assume they can use Unsafe if needed, they probably want as few dependences as possible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269469885

From mcimadamore at openjdk.org  Thu Jul 20 13:40:41 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 13:40:41 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
Message-ID: <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>

On Thu, 20 Jul 2023 13:34:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> in those cases, will creating a ByteBuffer wrapper be overkill?

Perhaps - but do we have any benchmark to back up that claim (or backing up the fact that Integer.toString would benefit from using ByteArray in the first place) ? It is likely that in code that is compiled and inlined, this will make no difference at all, as an object that is created, and then disposed of will be routinely scalarized (since there's no meaningful control flow).

If in some cases we have reason to believe that we need more performance, we could always fall back and use Unsafe directly.

I guess in general I'm a bit skeptical re. creating a class that wraps an array and exposes get/setXYZ that are implemented by Unsafe, adding some bound checks on top. That's 99.99% of what an heap buffer does. I've benchmarked BB quite a extensively given my work on Panama and I can assure that, if accessed using the right API (e.g. absolute addressing scheme, which takes an offset) and the right endianness (ByteOrder::NATIVE_ORDER), the performance of BB access is very very very close to Unsafe (esp. here, given that ByteArray also introduces some kind of bound check).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269474889

From mcimadamore at openjdk.org  Thu Jul 20 13:48:58 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 13:48:58 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
Message-ID: <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>

On Thu, 20 Jul 2023 13:38:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> The Unsafe-based writing will be used by `Integer.toString` and `Long.toString` as well; in those cases, will creating a ByteBuffer wrapper be overkill?
>> 
>> Integer/Long are very core classes so I assume they can use Unsafe if needed, they probably want as few dependences as possible.
>
>> in those cases, will creating a ByteBuffer wrapper be overkill?
> 
> Perhaps - but do we have any benchmark to back up that claim (or backing up the fact that Integer.toString would benefit from using ByteArray in the first place) ? It is likely that in code that is compiled and inlined, this will make no difference at all, as an object that is created, and then disposed of will be routinely scalarized (since there's no meaningful control flow).
> 
> If in some cases we have reason to believe that we need more performance, we could always fall back and use Unsafe directly.
> 
> I guess in general I'm a bit skeptical re. creating a class that wraps an array and exposes get/setXYZ that are implemented by Unsafe, adding some bound checks on top. That's 99.99% of what an heap buffer does. I've benchmarked BB quite a extensively given my work on Panama and I can assure that, if accessed using the right API (e.g. absolute addressing scheme, which takes an offset) and the right endianness (ByteOrder::NATIVE_ORDER), the performance of BB access is very very very close to Unsafe (esp. here, given that ByteArray also introduces some kind of bound check).

Also... `Integer::toString` seems to be `@IntrinsicCandidate` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269488090

From rriggs at openjdk.org  Thu Jul 20 13:51:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Jul 2023 13:51:47 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
Message-ID: <KP1c1axWv3MF88LAfrrmcaLnhxqPuQmZtR2AMYJaryk=.38065b0a-2707-4b36-8ee4-f5e5017753f9@github.com>

On Thu, 13 Jul 2023 23:05:48 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 with a new target base 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 'openjdk:master' into unsafe
>  - add 8310843 to @bug
>  - 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
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/074896ed...cb56e736

Til the comments settle down; don't integrate or sponsor.

-------------

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14636#pullrequestreview-1539317413

From prappo at openjdk.org  Thu Jul 20 13:57:50 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 20 Jul 2023 13:57:50 GMT
Subject: Integrated: 8312019: Simplify and modernize java.util.BitSet.equals
In-Reply-To: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
References: <gEtXfGr_gkPrNq7xHR3MzlqCiRjRHJZedCfJtvS2y7w=.c74798e0-0c37-4e44-94fc-ab1bf929e813@github.com>
Message-ID: <M8AmQr-95Gy2qZg6Vv9uRv8Fwsv1lPbvF5lJTw9NNL0=.406e3d8f-a35b-4d04-a949-f9802387f7a5@github.com>

On Thu, 13 Jul 2023 10:50:30 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify equals for BitSet. 
> 
> I couldn't see how to refactor hashCode using Arrays utility methods in a way that preserves its specification. So, aside from refactoring its doc comment and annotating it with `@Overrides`, I left it intact.

This pull request has now been integrated.

Changeset: 9fa944e6
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9fa944e63f7bec76eab21f85cc5109ed7419a0ab
Stats:     21 lines in 1 file changed: 8 ins; 8 del; 5 mod

8312019: Simplify and modernize java.util.BitSet.equals

Reviewed-by: rriggs, martin

-------------

PR: https://git.openjdk.org/jdk/pull/14868

From duke at openjdk.org  Thu Jul 20 13:59:45 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 20 Jul 2023 13:59:45 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
Message-ID: <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>

On Thu, 20 Jul 2023 13:46:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Also... `Integer::toString` seems to be `@IntrinsicCandidate` ?

It's just a bytecode intrinsics, it is only replaced when used in a fluent-chain of StringBuilder/Buffer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269503321

From rriggs at openjdk.org  Thu Jul 20 14:05:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Jul 2023 14:05:48 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
Message-ID: <XbMTPiPHAv5FGwajpz5MSHZF866D0wfQuKg1zAcGH-Q=.72242c75-dbff-4768-ba48-97f456ec4b27@github.com>

On Thu, 13 Jul 2023 23:05:48 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 with a new target base 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 'openjdk:master' into unsafe
>  - add 8310843 to @bug
>  - 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
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/29f2390f...cb56e736

These classes are used where numbers are being formatted into existing byte arrays and may be assembled with other strings.
For example, StringConcatHelper and AbstractStringBuilder, both optimized for assembling LATIN1 and UTF16 strings.
Switching to use a different implementation would result in more allocation and/or copying the strings.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1643986050

From mcimadamore at openjdk.org  Thu Jul 20 14:17:43 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 14:17:43 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
Message-ID: <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>

On Thu, 20 Jul 2023 13:57:04 GMT, Glavo <duke at openjdk.org> wrote:

>> Also... `Integer::toString` seems to be `@IntrinsicCandidate` ?
>
>> Also... `Integer::toString` seems to be `@IntrinsicCandidate` ?
> 
> It's just a bytecode intrinsics, it is only replaced when used in a fluent-chain of StringBuilder/Buffer.

Also, note that ByteBuffer exposes its backing array (at least if the buffer is not read only) via ByteBuffer::array. This does no copy. So in all the various stream implementations, I believe we can really just use a ByteBuffer instead of an array - and use ByteBuffer::array when we really need an array.

This makes it very easy to migrate some of the classes that use ByteArray. Here's the patch for DataInputStream:


diff --git a/src/java.base/share/classes/java/io/DataInputStream.java b/src/java.base/share/classes/java/io/DataInputStream.java
index 7192b30d5f2..b5b013cdd50 100644
--- a/src/java.base/share/classes/java/io/DataInputStream.java
+++ b/src/java.base/share/classes/java/io/DataInputStream.java
@@ -27,6 +27,8 @@ package java.io;
 
 import jdk.internal.util.ByteArray;
 
+import java.nio.ByteBuffer;
+import java.nio.ByteOrder;
 import java.util.Objects;
 
 /**
@@ -59,7 +61,7 @@ public class DataInputStream extends FilterInputStream implements DataInput {
         super(in);
     }
 
-    private final byte[] readBuffer = new byte[8];
+    private final ByteBuffer readBuffer = ByteBuffer.allocate(8); // BIG_ENDIAN
 
     /**
      * working arrays initialized on demand by readUTF
@@ -316,8 +318,8 @@ public class DataInputStream extends FilterInputStream implements DataInput {
      * @see        java.io.FilterInputStream#in
      */
     public final short readShort() throws IOException {
-        readFully(readBuffer, 0, 2);
-        return ByteArray.getShort(readBuffer, 0);
+        readFully(readBuffer.array(), 0, 2);
+        return readBuffer.getShort(0);
     }
 
     /**
@@ -338,8 +340,8 @@ public class DataInputStream extends FilterInputStream implements DataInput {
      * @see        java.io.FilterInputStream#in
      */
     public final int readUnsignedShort() throws IOException {
-        readFully(readBuffer, 0, 2);
-        return ByteArray.getUnsignedShort(readBuffer, 0);
+        readFully(readBuffer.array(), 0, 2);
+        return Short.toUnsignedInt(readBuffer.getShort(0));
     }
 
     /**
@@ -360,8 +362,8 @@ public class DataInputStream extends FilterInputStream implements DataInput {
      * @see        java.io.FilterInputStream#in
      */
     public final char readChar() throws IOException {
-        readFully(readBuffer, 0, 2);
-        return ByteArray.getChar(readBuffer, 0);
+        readFully(readBuffer.array(), 0, 2);
+        return readBuffer.getChar(0);
     }
 
     /**
@@ -382,8 +384,8 @@ public class DataInputStream extends FilterInputStream implements DataInput {
      * @see        java.io.FilterInputStream#in
      */
     public final int readInt() throws IOException {
-        readFully(readBuffer, 0, 4);
-        return ByteArray.getInt(readBuffer, 0);
+        readFully(readBuffer.array(), 0, 4);
+        return readBuffer.getInt(0);
     }
 
     /**
@@ -404,8 +406,8 @@ public class DataInputStream extends FilterInputStream implements DataInput {
      * @see        java.io.FilterInputStream#in
      */
     public final long readLong() throws IOException {
-        readFully(readBuffer, 0, 8);
-        return ByteArray.getLong(readBuffer, 0);
+        readFully(readBuffer.array(), 0, 8);
+        return readBuffer.getLong(0);
     }
 
     /**
@@ -427,8 +429,8 @@ public class DataInputStream extends FilterInputStream implements DataInput {
      * @see        java.lang.Float#intBitsToFloat(int)
      */
     public final float readFloat() throws IOException {
-        readFully(readBuffer, 0, 4);
-        return ByteArray.getFloat(readBuffer, 0);
+        readFully(readBuffer.array(), 0, 4);
+        return readBuffer.getFloat(0);
     }
 
     /**
@@ -450,8 +452,8 @@ public class DataInputStream extends FilterInputStream implements DataInput {
      * @see        java.lang.Double#longBitsToDouble(long)
      */
     public final double readDouble() throws IOException {
-        readFully(readBuffer, 0, 8);
-        return ByteArray.getDouble(readBuffer, 0);
+        readFully(readBuffer.array(), 0, 8);
+        return readBuffer.getDouble(0);
     }
 
     private char[] lineBuffer;


It is very mechanical, and seems to pass all the jdk_io tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269527839

From jvernee at openjdk.org  Thu Jul 20 14:44:42 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Jul 2023 14:44:42 GMT
Subject: RFR: 8312424: 80% throughput decrease in Arrays.hashCode(Object[])
 after JDK-8312164
In-Reply-To: <Xmw2EkJWc8jtAqIWB_GDEImqThcXUt6flEqPRQgfaVk=.be0d46d1-7833-4abb-903f-27129ac6f737@github.com>
References: <Xmw2EkJWc8jtAqIWB_GDEImqThcXUt6flEqPRQgfaVk=.be0d46d1-7833-4abb-903f-27129ac6f737@github.com>
Message-ID: <bySspcdzHW6mjDSm9xH9dUdDZIHLOYeYxHYsWR27ERQ=.88991f31-58af-4d62-bf22-9692431096db@github.com>

On Thu, 20 Jul 2023 01:11:43 GMT, Glavo <duke at openjdk.org> wrote:

> The changes to `Arrays.hashCode(Object[])` in JDK-8312164 caused its performance  is reduced by about 80%.
> 
> This PR reverts this change.

With a size of `1`, the polymorphic version is not really polymorphic. This seems to be about profile pollution inside `Objects.hashCode(Object)`. But, the same pollution can happen for `Arrays.hashCode(Object[])` as well, unless an application only ever calls this method with arrays with the same element type (seems unlikely).

To create a representative 'polluted' benchmark, you should create at least 2 other arrays that hold instances of another type than `Integer`, and then call `Arrays.hashCode` a bunch (like 10K times) in the setup method. [1]. Note how the polluted case is exactly the same with the old code:


Objects.hashCode(Object)

Benchmark               (pollute)  (size)  Mode  Cnt      Score    Error  Units
ArraysHashCode.objects       true       1  avgt   15      3.053 ?  0.011  ns/op
ArraysHashCode.objects       true      10  avgt   15     26.955 ?  0.192  ns/op
ArraysHashCode.objects       true     100  avgt   15    269.441 ?  1.788  ns/op
ArraysHashCode.objects       true   10000  avgt   15  26419.822 ? 56.444  ns/op
ArraysHashCode.objects      false       1  avgt   15      3.049 ?  0.007  ns/op
ArraysHashCode.objects      false      10  avgt   15     26.797 ?  0.040  ns/op
ArraysHashCode.objects      false     100  avgt   15    268.127 ?  0.351  ns/op
ArraysHashCode.objects      false   10000  avgt   15  26446.978 ? 66.340  ns/op


(element == null ? 0 : element.hashCode())

Benchmark               (pollute)  (size)  Mode  Cnt      Score     Error  Units
ArraysHashCode.objects       true       1  avgt   15      3.056 ?   0.015  ns/op
ArraysHashCode.objects       true      10  avgt   15     26.840 ?   0.081  ns/op
ArraysHashCode.objects       true     100  avgt   15    268.204 ?   0.462  ns/op
ArraysHashCode.objects       true   10000  avgt   15  26410.336 ?  77.897  ns/op
ArraysHashCode.objects      false       1  avgt   15      0.818 ?   0.001  ns/op
ArraysHashCode.objects      false      10  avgt   15      5.130 ?   0.013  ns/op
ArraysHashCode.objects      false     100  avgt   15     58.394 ?   0.508  ns/op
ArraysHashCode.objects      false   10000  avgt   15   6274.471 ? 427.928  ns/op


If you look at `PrintInlining` output for the `(element == null ? 0 : element.hashCode())` version of the code:

Non-polluted:
    
                            @ 1   java.util.Arrays::hashCode (56 bytes)   inline (hot)
                              @ 43   java.lang.Integer::hashCode (8 bytes)   inline (hot)
                               -> TypeProfile (15360/15360 counts) = java/lang/Integer
                                @ 4   java.lang.Integer::hashCode (2 bytes)   inline (hot)
                                
 Polluted:
 
                             @ 1   java.util.Arrays::hashCode (56 bytes)   inline (hot)
                              @ 43   java.lang.Object::hashCode (0 bytes)   (intrinsic, virtual)

i.e. `Arrays::hashCode(Object[])` is still susceptible to pollution, and I don't really think that the benchmark you've added in this PR is representative of a real world scenario since it only uses one element type. I don't think using `Objects.hashCode` is really that much of a problem here. Though, I'll grant that it at least has an observable difference.

[1]: https://github.com/openjdk/jdk/compare/master...JornVernee:jdk:PollutedBenchmark

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14944#issuecomment-1644050455

From duke at openjdk.org  Thu Jul 20 14:52:43 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 20 Jul 2023 14:52:43 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
Message-ID: <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>

On Thu, 20 Jul 2023 14:15:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Also... `Integer::toString` seems to be `@IntrinsicCandidate` ?
>> 
>> It's just a bytecode intrinsics, it is only replaced when used in a fluent-chain of StringBuilder/Buffer.
>
> Also, note that ByteBuffer exposes its backing array (at least if the buffer is not read only) via ByteBuffer::array. This does no copy. So in all the various stream implementations, I believe we can really just use a ByteBuffer instead of an array - and use ByteBuffer::array when we really need an array.
> 
> This makes it very easy to migrate some of the classes that use ByteArray. Here's the patch for DataInputStream:
> 
> 
> diff --git a/src/java.base/share/classes/java/io/DataInputStream.java b/src/java.base/share/classes/java/io/DataInputStream.java
> index 7192b30d5f2..b5b013cdd50 100644
> --- a/src/java.base/share/classes/java/io/DataInputStream.java
> +++ b/src/java.base/share/classes/java/io/DataInputStream.java
> @@ -27,6 +27,8 @@ package java.io;
>  
>  import jdk.internal.util.ByteArray;
>  
> +import java.nio.ByteBuffer;
> +import java.nio.ByteOrder;
>  import java.util.Objects;
>  
>  /**
> @@ -59,7 +61,7 @@ public class DataInputStream extends FilterInputStream implements DataInput {
>          super(in);
>      }
>  
> -    private final byte[] readBuffer = new byte[8];
> +    private final ByteBuffer readBuffer = ByteBuffer.allocate(8); // BIG_ENDIAN
>  
>      /**
>       * working arrays initialized on demand by readUTF
> @@ -316,8 +318,8 @@ public class DataInputStream extends FilterInputStream implements DataInput {
>       * @see        java.io.FilterInputStream#in
>       */
>      public final short readShort() throws IOException {
> -        readFully(readBuffer, 0, 2);
> -        return ByteArray.getShort(readBuffer, 0);
> +        readFully(readBuffer.array(), 0, 2);
> +        return readBuffer.getShort(0);
>      }
>  
>      /**
> @@ -338,8 +340,8 @@ public class DataInputStream extends FilterInputStream implements DataInput {
>       * @see        java.io.FilterInputStream#in
>       */
>      public final int readUnsignedShort() throws IOException {
> -        readFully(readBuffer, 0, 2);
> -        return ByteArray.getUnsignedShort(readBuffer, 0);
> +        readFully(readBuffer.array(), 0, 2);
> +        return Short.toUnsignedInt(readBuffer.getShort(0));
>      }
>  
>      /**
> @@ -360,8 +362,8 @@ public class DataInputStream extends FilterInputStream implements DataInput {
>       * @see        java.io.FilterInputStream#in
>       */
>      public final char readChar() throws IOException {
> -        readFully(readBuffer, 0, 2);
> -        return ByteArray.getChar(readBuffer, 0);
> +        readFully(readBuffer.array(), 0, 2);
> +        return readBuffer.getChar(0);
>      }
>  
>      /**
> @@ -382,8 +384,8 @@ public class DataInputS...

@mcimadamore I compared the performance of `ByteBuffer` and `VarHandle` using a JMH benchmark:


public class ByteArray {

    private byte[] array;
    private ByteBuffer byteBuffer;

    private static final VarHandle INT = MethodHandles.byteArrayViewVarHandle(int[].class, LITTLE_ENDIAN);
    private static final VarHandle LONG = MethodHandles.byteArrayViewVarHandle(long[].class, LITTLE_ENDIAN);

    @Setup
    public void setup() {
        array = new byte[8];
        byteBuffer = ByteBuffer.wrap(array).order(LITTLE_ENDIAN);

        new Random(0).nextBytes(array);
    }

    @Benchmark
    public byte readByte() {
        return array[0];
    }

    @Benchmark
    public byte readByteFromBuffer() {
        return byteBuffer.get(0);
    }

    @Benchmark
    public int readInt() {
        return (int) INT.get(array, 0);
    }

    @Benchmark
    public int readIntFromBuffer() {
        return byteBuffer.getInt(0);
    }


    @Benchmark
    public long readLong() {
        return (long) LONG.get(array, 0);
    }

    @Benchmark
    public long readLongFromBuffer() {
        return byteBuffer.getLong(0);
    }
}


Result:

Benchmark                      Mode  Cnt        Score       Error   Units
ByteArray.readByte            thrpt    5  1270230.180 ? 29172.551  ops/ms
ByteArray.readByteFromBuffer  thrpt    5   623862.080 ? 12167.410  ops/ms
ByteArray.readInt             thrpt    5  1252719.463 ? 77598.672  ops/ms
ByteArray.readIntFromBuffer   thrpt    5   571070.474 ?  1500.426  ops/ms
ByteArray.readLong            thrpt    5  1262720.686 ?   728.100  ops/ms
ByteArray.readLongFromBuffer  thrpt    5   571594.800 ?  3376.735  ops/ms


In this result, ByteBuffer is much slower than VarHandle. Am I doing something wrong? What conditions are needed to make the performance of ByteBuffer close to that of Unsafe?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269578107

From duke at openjdk.org  Thu Jul 20 14:56:46 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 20 Jul 2023 14:56:46 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
Message-ID: <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>

On Thu, 20 Jul 2023 14:49:48 GMT, Glavo <duke at openjdk.org> wrote:

>> Also, note that ByteBuffer exposes its backing array (at least if the buffer is not read only) via ByteBuffer::array. This does no copy. So in all the various stream implementations, I believe we can really just use a ByteBuffer instead of an array - and use ByteBuffer::array when we really need an array.
>> 
>> This makes it very easy to migrate some of the classes that use ByteArray. Here's the patch for DataInputStream:
>> 
>> 
>> diff --git a/src/java.base/share/classes/java/io/DataInputStream.java b/src/java.base/share/classes/java/io/DataInputStream.java
>> index 7192b30d5f2..b5b013cdd50 100644
>> --- a/src/java.base/share/classes/java/io/DataInputStream.java
>> +++ b/src/java.base/share/classes/java/io/DataInputStream.java
>> @@ -27,6 +27,8 @@ package java.io;
>>  
>>  import jdk.internal.util.ByteArray;
>>  
>> +import java.nio.ByteBuffer;
>> +import java.nio.ByteOrder;
>>  import java.util.Objects;
>>  
>>  /**
>> @@ -59,7 +61,7 @@ public class DataInputStream extends FilterInputStream implements DataInput {
>>          super(in);
>>      }
>>  
>> -    private final byte[] readBuffer = new byte[8];
>> +    private final ByteBuffer readBuffer = ByteBuffer.allocate(8); // BIG_ENDIAN
>>  
>>      /**
>>       * working arrays initialized on demand by readUTF
>> @@ -316,8 +318,8 @@ public class DataInputStream extends FilterInputStream implements DataInput {
>>       * @see        java.io.FilterInputStream#in
>>       */
>>      public final short readShort() throws IOException {
>> -        readFully(readBuffer, 0, 2);
>> -        return ByteArray.getShort(readBuffer, 0);
>> +        readFully(readBuffer.array(), 0, 2);
>> +        return readBuffer.getShort(0);
>>      }
>>  
>>      /**
>> @@ -338,8 +340,8 @@ public class DataInputStream extends FilterInputStream implements DataInput {
>>       * @see        java.io.FilterInputStream#in
>>       */
>>      public final int readUnsignedShort() throws IOException {
>> -        readFully(readBuffer, 0, 2);
>> -        return ByteArray.getUnsignedShort(readBuffer, 0);
>> +        readFully(readBuffer.array(), 0, 2);
>> +        return Short.toUnsignedInt(readBuffer.getShort(0));
>>      }
>>  
>>      /**
>> @@ -360,8 +362,8 @@ public class DataInputStream extends FilterInputStream implements DataInput {
>>       * @see        java.io.FilterInputStream#in
>>       */
>>      public final char readChar() throws IOException {
>> -        readFully(readBuffer, 0, 2);
>> -        return ByteArray.getChar(readBuffer, 0);
>> +        readFully(readBuffer.arra...
>
> @mcimadamore I compared the performance of `ByteBuffer` and `VarHandle` using a JMH benchmark:
> 
> 
> public class ByteArray {
> 
>     private byte[] array;
>     private ByteBuffer byteBuffer;
> 
>     private static final VarHandle INT = MethodHandles.byteArrayViewVarHandle(int[].class, LITTLE_ENDIAN);
>     private static final VarHandle LONG = MethodHandles.byteArrayViewVarHandle(long[].class, LITTLE_ENDIAN);
> 
>     @Setup
>     public void setup() {
>         array = new byte[8];
>         byteBuffer = ByteBuffer.wrap(array).order(LITTLE_ENDIAN);
> 
>         new Random(0).nextBytes(array);
>     }
> 
>     @Benchmark
>     public byte readByte() {
>         return array[0];
>     }
> 
>     @Benchmark
>     public byte readByteFromBuffer() {
>         return byteBuffer.get(0);
>     }
> 
>     @Benchmark
>     public int readInt() {
>         return (int) INT.get(array, 0);
>     }
> 
>     @Benchmark
>     public int readIntFromBuffer() {
>         return byteBuffer.getInt(0);
>     }
> 
> 
>     @Benchmark
>     public long readLong() {
>         return (long) LONG.get(array, 0);
>     }
> 
>     @Benchmark
>     public long readLongFromBuffer() {
>         return byteBuffer.getLong(0);
>     }
> }
> 
> 
> Result:
> 
> Benchmark                      Mode  Cnt        Score       Error   Units
> ByteArray.readByte            thrpt    5  1270230.180 ? 29172.551  ops/ms
> ByteArray.readByteFromBuffer  thrpt    5   623862.080 ? 12167.410  ops/ms
> ByteArray.readInt             thrpt    5  1252719.463 ? 77598.672  ops/ms
> ByteArray.readIntFromBuffer   thrpt    5   571070.474 ?  1500.426  ops/ms
> ByteArray.readLong            thrpt    5  1262720.686 ?   728.100  ops/ms
> ByteArray.readLongFromBuffer  thrpt    5   571594.800 ?  3376.735  ops/ms
> 
> 
> In this result, ByteBuffer is much slower than VarHandle. Am I doing something wrong? What conditions are needed to make the performance of ByteBuffer close to that of Unsafe?

I tried a few more. It looks like the JIT is able to optimize the ByteBuffer away pretty well by keeping it only as a local variable without escaping.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269582991

From daniel at wwwmaster.at  Thu Jul 20 15:11:26 2023
From: daniel at wwwmaster.at (Daniel Schmid)
Date: Thu, 20 Jul 2023 17:11:26 +0200
Subject: 8311517: Adapt ArrayList Javadoc for sequenced collections
In-Reply-To: <f0a75163-31b1-ef79-32a3-f57dfca04737@wwwmaster.at>
References: <5486e8e6-d600-187d-5370-b69dc7cc198c@oracle.com>
 <f0a75163-31b1-ef79-32a3-f57dfca04737@wwwmaster.at>
Message-ID: <231c6985-c110-70cc-3e9f-a0a43f09369a@wwwmaster.at>

I could create a PR for this if wanted.

I would suggest changing

 > 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.

to

 > The size, isEmpty, get, set, iterator, listIterator, and reversed 
operations run in constant time. The add, addLast, and removeLast 
operations 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.


Is there any other part of the documentation that should be changed?

Note that I do not have an OpenJDK account as I haven't contributed to 
OpenJDK projects before (Though I did sign the OCA).

Yours,
Daniel

Am 20.07.2023 um 17:04 schrieb Daniel Schmid:
>
> I could create a PR for this if wanted.
>
> I would suggest changing
>
> > 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.
>
> to
>
> > The size, isEmpty, get, set, iterator, listIterator, and reversed 
> operations run in constant time. The add, addLast, and removeLast 
> operations 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.
>
>
> Is there any other
>
> ---
> Hi Daniel,
>
> Core-libs-dev is indeed the correct alias for this documentation issue.
>
> Create an issue to track: JDK-8311517
> <https://bugs.openjdk.org/browse/JDK-8311517>
>
> Regards, Roger
>
> On 7/1/23 3:35 PM, Daniel Schmid wrote:
>
> 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.
>
> I originally posted this in the core-libs-dev mailing list
> (https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html)
> but it seems like that mail has been overlooked due to the amount of
> other content with PRs etc. there.
>
> Yours,
> Daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230720/f7ff9876/attachment-0001.htm>
-------------- 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/20230720/f7ff9876/smime-0001.p7s>

From jvernee at openjdk.org  Thu Jul 20 15:13:46 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Jul 2023 15:13:46 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v4]
In-Reply-To: <QShP3BrYVmCo0PXBTGxc4VfdZzwtCSXccDASl3getg8=.328c111a-e693-408f-a693-404ff8f4f023@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
 <QShP3BrYVmCo0PXBTGxc4VfdZzwtCSXccDASl3getg8=.328c111a-e693-408f-a693-404ff8f4f023@github.com>
Message-ID: <XkMRbnY-GkqbSGP7Fa-rSijwCM7m_Oh8JTe9FzFsy0k=.2487641b-89af-4c10-925e-6671ca8a6327@github.com>

On Thu, 20 Jul 2023 01:04:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported.   To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information.  Changes include:
>> 
>> 1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported.  This check is only needed for direct var handle.
>> 2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported
>> 
>> The error message looks like:
>> 
>> java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright header

Marked as reviewed by jvernee (Reviewer).

src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java line 2:

> 1: /*
> 2:  * Copyright (c) 2014, 2023, Oracle and/or its affiliates. All rights reserved.

I think you've updated the wrong copyright header?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14928#pullrequestreview-1539490370
PR Review Comment: https://git.openjdk.org/jdk/pull/14928#discussion_r1269597027

From duke at openjdk.org  Thu Jul 20 15:19:45 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 20 Jul 2023 15:19:45 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
Message-ID: <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>

On Thu, 20 Jul 2023 14:53:36 GMT, Glavo <duke at openjdk.org> wrote:

>> @mcimadamore I compared the performance of `ByteBuffer` and `VarHandle` using a JMH benchmark:
>> 
>> 
>> public class ByteArray {
>> 
>>     private byte[] array;
>>     private ByteBuffer byteBuffer;
>> 
>>     private static final VarHandle INT = MethodHandles.byteArrayViewVarHandle(int[].class, LITTLE_ENDIAN);
>>     private static final VarHandle LONG = MethodHandles.byteArrayViewVarHandle(long[].class, LITTLE_ENDIAN);
>> 
>>     @Setup
>>     public void setup() {
>>         array = new byte[8];
>>         byteBuffer = ByteBuffer.wrap(array).order(LITTLE_ENDIAN);
>> 
>>         new Random(0).nextBytes(array);
>>     }
>> 
>>     @Benchmark
>>     public byte readByte() {
>>         return array[0];
>>     }
>> 
>>     @Benchmark
>>     public byte readByteFromBuffer() {
>>         return byteBuffer.get(0);
>>     }
>> 
>>     @Benchmark
>>     public int readInt() {
>>         return (int) INT.get(array, 0);
>>     }
>> 
>>     @Benchmark
>>     public int readIntFromBuffer() {
>>         return byteBuffer.getInt(0);
>>     }
>> 
>> 
>>     @Benchmark
>>     public long readLong() {
>>         return (long) LONG.get(array, 0);
>>     }
>> 
>>     @Benchmark
>>     public long readLongFromBuffer() {
>>         return byteBuffer.getLong(0);
>>     }
>> }
>> 
>> 
>> Result:
>> 
>> Benchmark                      Mode  Cnt        Score       Error   Units
>> ByteArray.readByte            thrpt    5  1270230.180 ? 29172.551  ops/ms
>> ByteArray.readByteFromBuffer  thrpt    5   623862.080 ? 12167.410  ops/ms
>> ByteArray.readInt             thrpt    5  1252719.463 ? 77598.672  ops/ms
>> ByteArray.readIntFromBuffer   thrpt    5   571070.474 ?  1500.426  ops/ms
>> ByteArray.readLong            thrpt    5  1262720.686 ?   728.100  ops/ms
>> ByteArray.readLongFromBuffer  thrpt    5   571594.800 ?  3376.735  ops/ms
>> 
>> 
>> In this result, ByteBuffer is much slower than VarHandle. Am I doing something wrong? What conditions are needed to make the performance of ByteBuffer close to that of Unsafe?
>
> I tried a few more. It looks like the JIT is able to optimize the ByteBuffer away pretty well by keeping it only as a local variable without escaping.

It seems that as long as the `ByteBuffer` is stored in a field (even if it is `static final`), the JIT compiler cannot completely eliminate the overhead of the `ByteBuffer`.

@mcimadamore I think your suggested changes for `DataInputStream` is dubious, it's likely to introduce non-trivial additional overhead. The correct change may be like this:


public final double readDouble() throws IOException {
    readFully(readBuffer, 0, 8);
-   return ByteArray.getDouble(readBuffer, 0);
+   return ByteBuffer.wrap(readBuffer).getDouble(0);
}


However this change can also increase the warmup time and allocate many small objects before C2 compiles it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269617039

From jvernee at openjdk.org  Thu Jul 20 15:19:46 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Jul 2023 15:19:46 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v4]
In-Reply-To: <QShP3BrYVmCo0PXBTGxc4VfdZzwtCSXccDASl3getg8=.328c111a-e693-408f-a693-404ff8f4f023@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
 <QShP3BrYVmCo0PXBTGxc4VfdZzwtCSXccDASl3getg8=.328c111a-e693-408f-a693-404ff8f4f023@github.com>
Message-ID: <Ov_cZHUo_idpvVZrOFj8iXLYdP-JXnkYTjfFnRKHSU4=.52d0eee1-e925-4465-b289-5985eca0eea8@github.com>

On Thu, 20 Jul 2023 01:04:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported.   To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information.  Changes include:
>> 
>> 1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported.  This check is only needed for direct var handle.
>> 2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported
>> 
>> The error message looks like:
>> 
>> java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright header

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2010:

> 2008:         static AccessMode valueFromOrdinal(int mode) {
> 2009:             return VALUES[mode];
> 2010:         }

Also, I'll throw this out there, though I'm not sure how big of an issue it is: this array creation might have an effect on startup. But, since it is only used on a slow path right before we throw an exception (at least, at the moment), calling `values()` every time inside the `valueFromOrdinal` method, and avoiding the array creation on startup, might be 'better'.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14928#discussion_r1269616973

From prappo at openjdk.org  Thu Jul 20 15:32:09 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 20 Jul 2023 15:32:09 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v3]
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <88Kwu14Vu6OOS0JKrmI_ckerccDOCPJlWt9NumwVLjg=.c8c890bd-03ec-444d-8f55-b2a8bd11110e@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.

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:

 - Restore hash code values
   
   BigInteger is old and ubiquitous enough so that there might be
   inadvertent dependencies on its hash code.
   
   This commit also includes a test, to make sure hash code is
   unchanged.
 - Merge branch 'master' into 8310813
 - Add a benchmark
 - Merge branch 'master' into 8310813
 - Use fewer range checks to improve performance
 - Improve
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14630/files
  - new: https://git.openjdk.org/jdk/pull/14630/files/9f838612..d087a592

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=01-02

  Stats: 71081 lines in 934 files changed: 19355 ins; 49233 del; 2493 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  Thu Jul 20 15:32:09 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 20 Jul 2023 15:32:09 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v3]
In-Reply-To: <-hRTcFsCaDtdobIiQV-dfh1eeAEcT18sk972TG0QRRU=.6aff2ebf-b146-4483-98c7-29b342d674d9@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <pTMvEIx5UPajYBUi4pCgN6CsyzVd6tlJhqcla4D3nV4=.c8aa7c9d-4bbe-482e-8b96-1423950105eb@github.com>
 <-hRTcFsCaDtdobIiQV-dfh1eeAEcT18sk972TG0QRRU=.6aff2ebf-b146-4483-98c7-29b342d674d9@github.com>
Message-ID: <i_Ri7zYQ_yq5eb5qzErt_wqm3elFdz2eZGSICyaRCNw=.6469b181-a444-44a1-ade1-33723e5e91d5@github.com>

On Mon, 10 Jul 2023 17:07:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> LGTM; I assume the comment about aarch64 perf was a 10% improvement.
>
>> Here's some explanation for the recent commits I've added since @RogerRiggs reviewed this PR.
>> 
>>     1. Since `BigInteger.hashCode()` is unspecified, we can change it. Again: I think that the proposed implementation is no worse in hashing quality than the current one; if you disagree, please voice your concerns.
>> 
>> 
>> FWIW, we can keep the existing `BigInteger.hashCode()` values whilst still improving the implementation, using JDK-internal support:
>> 
>> ```
>> @Override
>> public int hashCode() {
>>     return ArraysSupport.vectorizedHashCode(mag, 0, mag.length, 1,
>>             ArraysSupport.T_INT) * signum;
>> }
>> ```
>> 
>> AFAIU, such an implementation would always yield exactly the same values the current (i.e. mainline) implementation does. But that could be a little slower than the original proposal, especially for a smaller BigInteger.
>> 
>> The key thing that allows to keep the current hash-code values in the above implementation is that `1` argument, which is the initial hash-code value, which cannot be specified in `Arrays.hashCode`. Unfortunately, we don't have mid-layer methods in between Arrays.hashCode and ArraysSupport.vectorizedHashCode like that of Arrays.mismatch and ArraysSupport.vectorizedMismatch. It's either all the null check but short-circuits or unconditional vectorization but the initial value. I wonder if we could consider `ArraysSupport.hashCode($type[] array, int fromIndex, int length, int initialValue)` overloads, which could be useful beyond BigInteger, as I've already seen in JDK. Contributors to ArraysSupport, @PaulSandoz, @ChrisHegarty, @cl4es, @stuart-marks; thoughts?
>> 
>>     2. Maybe surprisingly, but we don't have microbenchmarks for BigInteger's equals, hashCode, and compareTo. While I don't know how often people use the former two methods, I reckon, the latter method is essential. Anyway, I added benchmarks to cover all three. Note: benchmark for hashCode shows only its performance, not its hashing quality. Again: if you think the current version is in any way worse than the mainline version, please voice your concerns.
>> 
>> 
>> AFAIK, the biggest consumer of BigInteger in JDK is security area. So, I assume a good way to judge this change is to run security benchmarks to make sure they haven't slipped.
> 
> I would be in favor of keeping the current hash behavior for now, even if it is updated in subsequent work. Users have had more than two decades to become, accidentally, reliant on the hash algorithms.

@jddarcy would you be okay with the change and the test in [d087a59](https://github.com/openjdk/jdk/pull/14630/commits/d087a592c8996e90a5754f023c2eac3a194d007f)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1644134205

From mcimadamore at openjdk.org  Thu Jul 20 15:37:42 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 15:37:42 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
 <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
Message-ID: <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>

On Thu, 20 Jul 2023 15:16:36 GMT, Glavo <duke at openjdk.org> wrote:

> it's likely to introduce non-trivial additional overhead

What do you mean? E.g. where would the overhead come from?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269643645

From duke at openjdk.org  Thu Jul 20 15:45:42 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 20 Jul 2023 15:45:42 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
 <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
 <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>
Message-ID: <rTB4ZN2L094-B1iuBjktkhvQn1OXxnw8M83gGxXIhh4=.fb1c085c-b714-4ec1-9dda-2d099e838430@github.com>

On Thu, 20 Jul 2023 15:34:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > it's likely to introduce non-trivial additional overhead
> 
> What do you mean? E.g. where would the overhead come from?

You suggested changes stored the ByteBuffer into a field. I measured throughput with JMH, and it shows that using ByteBuffer like this results in over 50% drop in throughput.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269653896

From mcimadamore at openjdk.org  Thu Jul 20 15:51:41 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 15:51:41 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <rTB4ZN2L094-B1iuBjktkhvQn1OXxnw8M83gGxXIhh4=.fb1c085c-b714-4ec1-9dda-2d099e838430@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
 <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
 <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>
 <rTB4ZN2L094-B1iuBjktkhvQn1OXxnw8M83gGxXIhh4=.fb1c085c-b714-4ec1-9dda-2d099e838430@github.com>
Message-ID: <5vWADWw1xEPg0Rmq6cgvKRj9CN5cSTBRYOPkDBlkBxk=.b20fed4c-12fe-4dbc-b51e-2d672d74c070@github.com>

On Thu, 20 Jul 2023 15:43:01 GMT, Glavo <duke at openjdk.org> wrote:

>>> it's likely to introduce non-trivial additional overhead
>> 
>> What do you mean? E.g. where would the overhead come from?
>
>> > it's likely to introduce non-trivial additional overhead
>> 
>> What do you mean? E.g. where would the overhead come from?
> 
> You suggested changes stored the ByteBuffer into a field. I measured throughput with JMH, and it shows that using ByteBuffer like this results in over 50% drop in throughput.

> In this result, ByteBuffer is much slower than VarHandle. Am I doing something wrong? What conditions are needed to make the performance of ByteBuffer close to that of Unsafe?

These are some benchmarks we have in the JDK:

Off-heap access:


Benchmark                       Mode  Cnt  Score   Error  Units
LoopOverNonConstant.BB_get      avgt   30  3.837 ? 0.045  ns/op
LoopOverNonConstant.unsafe_get  avgt   30  3.425 ? 0.032  ns/op


On-heap access:


Benchmark                           (polluteProfile)  Mode  Cnt  Score   Error  Units
LoopOverNonConstantHeap.BB_get                 false  avgt   30  3.897 ? 0.055  ns/op
LoopOverNonConstantHeap.unsafe_get             false  avgt   30  3.446 ? 0.027  ns/op


BB is almost on par with unsafe. There's of course an extra bound check which you pay for. These benchmark are almost idential to the one you shared, so not sure what's going on.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269661065

From liach at openjdk.org  Thu Jul 20 15:55:52 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Jul 2023 15:55:52 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v4]
In-Reply-To: <Ov_cZHUo_idpvVZrOFj8iXLYdP-JXnkYTjfFnRKHSU4=.52d0eee1-e925-4465-b289-5985eca0eea8@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
 <QShP3BrYVmCo0PXBTGxc4VfdZzwtCSXccDASl3getg8=.328c111a-e693-408f-a693-404ff8f4f023@github.com>
 <Ov_cZHUo_idpvVZrOFj8iXLYdP-JXnkYTjfFnRKHSU4=.52d0eee1-e925-4465-b289-5985eca0eea8@github.com>
Message-ID: <7TiWqq5e3YGY603WP9RA_-2opD6xoKNm4N31X2Z5Avg=.cd56f086-5489-46cf-8212-3fc7ad88ed77@github.com>

On Thu, 20 Jul 2023 15:16:33 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright header
>
> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2010:
> 
>> 2008:         static AccessMode valueFromOrdinal(int mode) {
>> 2009:             return VALUES[mode];
>> 2010:         }
> 
> Also, I'll throw this out there, though I'm not sure how big of an issue it is: this array creation might have an effect on startup. But, since it is only used on a slow path right before we throw an exception (at least, at the moment), calling `values()` every time inside the `valueFromOrdinal` method, and avoiding the array creation on startup, might be 'better'.

I think this is a worthy change: see https://github.com/openjdk/jdk/pull/14943/files#diff-556b309ea2df3f5bfe8229de944183ef19750ce4511d0328cd59af2ce2b61ae2R135
that `VarHandle.AccessMode.values()` is called every time a polymorphic VH call is linked.

If the startup cost from array allocation is really problematic, we can make it stable and allocate `VALUES` on demand (at `valueFromOrdinal` calls).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14928#discussion_r1269665939

From duke at openjdk.org  Thu Jul 20 15:59:42 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 20 Jul 2023 15:59:42 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <5vWADWw1xEPg0Rmq6cgvKRj9CN5cSTBRYOPkDBlkBxk=.b20fed4c-12fe-4dbc-b51e-2d672d74c070@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
 <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
 <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>
 <rTB4ZN2L094-B1iuBjktkhvQn1OXxnw8M83gGxXIhh4=.fb1c085c-b714-4ec1-9dda-2d099e838430@github.com>
 <5vWADWw1xEPg0Rmq6cgvKRj9CN5cSTBRYOPkDBlkBxk=.b20fed4c-12fe-4dbc-b51e-2d672d74c070@github.com>
Message-ID: <y2JG_qO6Y_jJyjXraNEOAbl2_SJuUh1elJSm0GFxAH0=.77e0757b-eec9-49ad-ad52-c37d3e3e67a6@github.com>

On Thu, 20 Jul 2023 15:49:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> > it's likely to introduce non-trivial additional overhead
>>> 
>>> What do you mean? E.g. where would the overhead come from?
>> 
>> You suggested changes stored the ByteBuffer into a field. I measured throughput with JMH, and it shows that using ByteBuffer like this results in over 50% drop in throughput.
>
>> In this result, ByteBuffer is much slower than VarHandle. Am I doing something wrong? What conditions are needed to make the performance of ByteBuffer close to that of Unsafe?
> 
> These are some benchmarks we have in the JDK:
> 
> Off-heap access:
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> LoopOverNonConstant.BB_get      avgt   30  3.837 ? 0.045  ns/op
> LoopOverNonConstant.unsafe_get  avgt   30  3.425 ? 0.032  ns/op
> 
> 
> On-heap access:
> 
> 
> Benchmark                           (polluteProfile)  Mode  Cnt  Score   Error  Units
> LoopOverNonConstantHeap.BB_get                 false  avgt   30  3.897 ? 0.055  ns/op
> LoopOverNonConstantHeap.unsafe_get             false  avgt   30  3.446 ? 0.027  ns/op
> 
> 
> BB is almost on par with unsafe. There's of course an extra bound check which you pay for. These benchmark are almost idential to the one you shared, so not sure what's going on.

@mcimadamore I ran a series of experiments. When `ByteBuffer` is only used as a local variable without escaping, it is very close to `VarHandle`(`Unsafe`). However, any attempt to put the `ByteBuffer` into a field (even a static final field) resulted in the throughput drop of more than 50%.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269668539

From mcimadamore at openjdk.org  Thu Jul 20 16:04:44 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 16:04:44 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <y2JG_qO6Y_jJyjXraNEOAbl2_SJuUh1elJSm0GFxAH0=.77e0757b-eec9-49ad-ad52-c37d3e3e67a6@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
 <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
 <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>
 <rTB4ZN2L094-B1iuBjktkhvQn1OXxnw8M83gGxXIhh4=.fb1c085c-b714-4ec1-9dda-2d099e838430@github.com>
 <5vWADWw1xEPg0Rmq6cgvKRj9CN5cSTBRYOPkDBlkBxk=.b20fed4c-12fe-4dbc-b51e-2d672d74c070@github.com>
 <y2JG_qO6Y_jJyjXraNEOAbl2_SJuUh1elJSm0GFxAH0=.77e0757b-eec9-49ad-ad52-c37d3e3e67a6@github.com>
Message-ID: <Q2tgKNyIUTLAdt3MdARsHFmz5PLhYcdxyNzaFZyCsK0=.de22d165-0ed0-43b8-8ece-5779fa5bcc78@github.com>

On Thu, 20 Jul 2023 15:55:18 GMT, Glavo <duke at openjdk.org> wrote:

>>> In this result, ByteBuffer is much slower than VarHandle. Am I doing something wrong? What conditions are needed to make the performance of ByteBuffer close to that of Unsafe?
>> 
>> These are some benchmarks we have in the JDK:
>> 
>> Off-heap access:
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> LoopOverNonConstant.BB_get      avgt   30  3.837 ? 0.045  ns/op
>> LoopOverNonConstant.unsafe_get  avgt   30  3.425 ? 0.032  ns/op
>> 
>> 
>> On-heap access:
>> 
>> 
>> Benchmark                           (polluteProfile)  Mode  Cnt  Score   Error  Units
>> LoopOverNonConstantHeap.BB_get                 false  avgt   30  3.897 ? 0.055  ns/op
>> LoopOverNonConstantHeap.unsafe_get             false  avgt   30  3.446 ? 0.027  ns/op
>> 
>> 
>> BB is almost on par with unsafe. There's of course an extra bound check which you pay for. These benchmark are almost idential to the one you shared, so not sure what's going on.
>
> @mcimadamore I ran a series of experiments. When `ByteBuffer` is only used as a local variable without escaping, it is very close to `VarHandle`(`Unsafe`). However, any attempt to put the `ByteBuffer` into a field (even a static final field) resulted in the throughput drop of more than 50%.

I just ran your benchmark above - which is similar as I said to the ones we already have in the JDK. Results:

Benchmark                     Mode  Cnt  Score   Error  Units
ByteArray.readByte            avgt   30  3.619 ? 0.051  ns/op
ByteArray.readByteFromBuffer  avgt   30  3.936 ? 0.071  ns/op
ByteArray.readInt             avgt   30  3.653 ? 0.054  ns/op
ByteArray.readIntFromBuffer   avgt   30  3.798 ? 0.019  ns/op
ByteArray.readLong            avgt   30  3.637 ? 0.053  ns/op
ByteArray.readLongFromBuffer  avgt   30  3.922 ? 0.012  ns/op


I don't see 2x slowdown. Which JDK are you using? Which platform?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269675593

From naoto at openjdk.org  Thu Jul 20 16:13:47 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Jul 2023 16:13:47 GMT
Subject: Integrated: 8308591: JLine as the default Console provider
In-Reply-To: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
References: <dgxfbS2VBBpNAUslrJJZkZNjfrGPGQKiqkJxlWL45C4=.953b8a65-4d16-4d20-b870-2e83e385e010@github.com>
Message-ID: <AgiSJogqoapJ1KcSKJimIXhU9mancqFp1Y7Y3wsOl0g=.68ef9e3f-8fe1-4dc2-ad65-f5ee0ef6a0a8@github.com>

On Thu, 1 Jun 2023 18:53:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to bring the JLine-based Console implementation as the default, which was the initial intention in [JDK-8295803](https://bugs.openjdk.org/browse/JDK-8295803). A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: bae22479
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bae224793812cb0a0aa67e399062498d3b13fdb3
Stats:     68 lines in 5 files changed: 53 ins; 6 del; 9 mod

8308591: JLine as the default Console provider

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14271

From duke at openjdk.org  Thu Jul 20 16:14:42 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 20 Jul 2023 16:14:42 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <Q2tgKNyIUTLAdt3MdARsHFmz5PLhYcdxyNzaFZyCsK0=.de22d165-0ed0-43b8-8ece-5779fa5bcc78@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
 <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
 <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>
 <rTB4ZN2L094-B1iuBjktkhvQn1OXxnw8M83gGxXIhh4=.fb1c085c-b714-4ec1-9dda-2d099e838430@github.com>
 <5vWADWw1xEPg0Rmq6cgvKRj9CN5cSTBRYOPkDBlkBxk=.b20fed4c-12fe-4dbc-b51e-2d672d74c070@github.com>
 <y2JG_qO6Y_jJyjXraNEOAbl2_SJuUh1elJSm0GFxAH0=.77e0757b-eec9-49ad-ad52-c37d3e3e67a6@github.com>
 <Q2tgKNyIUTLAdt3MdARsHFmz5PLhYcdxyNzaFZyCsK0=.de22d165-0ed0-43b8-8ece-5779fa5bcc78@github.com>
Message-ID: <Lzi9EKlcwY36SBqlVCN6bYSGatbUBVQiQIYv5Nbzmj0=.c7928875-f0b4-4fd6-816e-8e0357b8a92c@github.com>

On Thu, 20 Jul 2023 16:01:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I don't see 2x slowdown. Which JDK are you using? Which platform?

I tried running the benchmarks with OpenJDK 20.0.1 and my own jdk built from master and the results were similar. The test platform is based on Ubuntu 23.04, and the CPU is AMD Ryzen 7 3700X.

Here's the benchmark configuration I use:


@Warmup(iterations = 5, time = 3)
@Measurement(iterations = 5, time = 2)
@Fork(value = 1, jvmArgsAppend = {"-XX:+UseG1GC", "-Xms4g", "-Xmx4g"})
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@State(Scope.Benchmark)


Also, I just ran the benchmarks on my ARM machine (Ubuntu 22.04, RK3588) and here are the results:


Benchmark                      Mode  Cnt       Score       Error   Units
ByteArray.readByte            thrpt    5  637843.606 ? 23657.623  ops/ms
ByteArray.readByteFromBuffer  thrpt    5  350328.152 ?  3635.769  ops/ms
ByteArray.readInt             thrpt    5  633518.784 ?  2558.021  ops/ms
ByteArray.readIntFromBuffer   thrpt    5  327456.830 ?  4588.002  ops/ms
ByteArray.readLong            thrpt    5  627409.162 ? 29301.498  ops/ms
ByteArray.readLongFromBuffer  thrpt    5  328154.906 ?  1067.439  ops/ms

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269686978

From mcimadamore at openjdk.org  Thu Jul 20 16:26:43 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 16:26:43 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <Lzi9EKlcwY36SBqlVCN6bYSGatbUBVQiQIYv5Nbzmj0=.c7928875-f0b4-4fd6-816e-8e0357b8a92c@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
 <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
 <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>
 <rTB4ZN2L094-B1iuBjktkhvQn1OXxnw8M83gGxXIhh4=.fb1c085c-b714-4ec1-9dda-2d099e838430@github.com>
 <5vWADWw1xEPg0Rmq6cgvKRj9CN5cSTBRYOPkDBlkBxk=.b20fed4c-12fe-4dbc-b51e-2d672d74c070@github.com>
 <y2JG_qO6Y_jJyjXraNEOAbl2_SJuUh1elJSm0GFxAH0=.77e0757b-eec9-49ad-ad52-c37d3e3e67a6@github.com>
 <Q2tgKNyIUTLAdt3MdARsHFmz5PLhYcdxyNzaFZyCsK0=.de22d165-0ed0-43b8-8ece-5779fa5bcc78@github.com>
 <Lzi9EKlcwY36SBqlVCN6bYSGatbUBVQiQIYv5Nbzmj0=.c7928875-f0b4-4fd6-816e-8e0357b8a92c@github.com>
Message-ID: <wCL4vOROLQFoktk5IESaD4CpTnBAxiEq9qq7mDO41S0=.690ff507-32ee-402f-b727-5f6ea5f669b4@github.com>

On Thu, 20 Jul 2023 16:12:12 GMT, Glavo <duke at openjdk.org> wrote:

>> I just ran your benchmark above - which is similar as I said to the ones we already have in the JDK. Results:
>> 
>> Benchmark                     Mode  Cnt  Score   Error  Units
>> ByteArray.readByte            avgt   30  3.619 ? 0.051  ns/op
>> ByteArray.readByteFromBuffer  avgt   30  3.936 ? 0.071  ns/op
>> ByteArray.readInt             avgt   30  3.653 ? 0.054  ns/op
>> ByteArray.readIntFromBuffer   avgt   30  3.798 ? 0.019  ns/op
>> ByteArray.readLong            avgt   30  3.637 ? 0.053  ns/op
>> ByteArray.readLongFromBuffer  avgt   30  3.922 ? 0.012  ns/op
>> 
>> 
>> I don't see 2x slowdown. Which JDK are you using? Which platform?
>
>> I don't see 2x slowdown. Which JDK are you using? Which platform?
> 
> I tried running the benchmarks with OpenJDK 20.0.1 and my own jdk built from master and the results were similar. The test platform is based on Ubuntu 23.04, and the CPU is AMD Ryzen 7 3700X.
> 
> Here's the benchmark configuration I use:
> 
> 
> @Warmup(iterations = 5, time = 3)
> @Measurement(iterations = 5, time = 2)
> @Fork(value = 1, jvmArgsAppend = {"-XX:+UseG1GC", "-Xms4g", "-Xmx4g"})
> @BenchmarkMode(Mode.Throughput)
> @OutputTimeUnit(TimeUnit.MILLISECONDS)
> @State(Scope.Benchmark)
> 
> 
> Also, I just ran the benchmarks on my ARM machine (Ubuntu 22.04, RK3588) and here are the results:
> 
> 
> Benchmark                      Mode  Cnt       Score       Error   Units
> ByteArray.readByte            thrpt    5  637843.606 ? 23657.623  ops/ms
> ByteArray.readByteFromBuffer  thrpt    5  350328.152 ?  3635.769  ops/ms
> ByteArray.readInt             thrpt    5  633518.784 ?  2558.021  ops/ms
> ByteArray.readIntFromBuffer   thrpt    5  327456.830 ?  4588.002  ops/ms
> ByteArray.readLong            thrpt    5  627409.162 ? 29301.498  ops/ms
> ByteArray.readLongFromBuffer  thrpt    5  328154.906 ?  1067.439  ops/ms

Here's with the same parameters as the one you are using:

Benchmark                      Mode  Cnt       Score       Error   Units
ByteArray.readByte            thrpt    5  268722.378 ?  5979.787  ops/ms
ByteArray.readByteFromBuffer  thrpt    5  254333.844 ?  6975.034  ops/ms
ByteArray.readInt             thrpt    5  271849.915 ?  4746.869  ops/ms
ByteArray.readIntFromBuffer   thrpt    5  263109.760 ?  2764.372  ops/ms
ByteArray.readLong            thrpt    5  271635.129 ? 14705.673  ops/ms
ByteArray.readLongFromBuffer  thrpt    5  252633.826 ?  2950.184  ops/ms

(Java 22/Ubuntu 20.04 on Ryzen 3900X here).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269699609

From jvernee at openjdk.org  Thu Jul 20 16:29:41 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Jul 2023 16:29:41 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v4]
In-Reply-To: <7TiWqq5e3YGY603WP9RA_-2opD6xoKNm4N31X2Z5Avg=.cd56f086-5489-46cf-8212-3fc7ad88ed77@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
 <QShP3BrYVmCo0PXBTGxc4VfdZzwtCSXccDASl3getg8=.328c111a-e693-408f-a693-404ff8f4f023@github.com>
 <Ov_cZHUo_idpvVZrOFj8iXLYdP-JXnkYTjfFnRKHSU4=.52d0eee1-e925-4465-b289-5985eca0eea8@github.com>
 <7TiWqq5e3YGY603WP9RA_-2opD6xoKNm4N31X2Z5Avg=.cd56f086-5489-46cf-8212-3fc7ad88ed77@github.com>
Message-ID: <9crb5lQ86ziHOA6YizgRBqN0-DqYr-cbmDqWfwEoGqQ=.f8d8bf01-8afe-4d91-8fae-ae3b73fa3a55@github.com>

On Thu, 20 Jul 2023 15:53:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2010:
>> 
>>> 2008:         static AccessMode valueFromOrdinal(int mode) {
>>> 2009:             return VALUES[mode];
>>> 2010:         }
>> 
>> Also, I'll throw this out there, though I'm not sure how big of an issue it is: this array creation might have an effect on startup. But, since it is only used on a slow path right before we throw an exception (at least, at the moment), calling `values()` every time inside the `valueFromOrdinal` method, and avoiding the array creation on startup, might be 'better'.
>
> I think this is a worthy change: see https://github.com/openjdk/jdk/pull/14943/files#diff-556b309ea2df3f5bfe8229de944183ef19750ce4511d0328cd59af2ce2b61ae2R135
> that `VarHandle.AccessMode.values()` is called every time a polymorphic VH call is linked.
> 
> If the startup cost from array allocation is really problematic, we can make it stable and allocate `VALUES` on demand (at `valueFromOrdinal` calls).

Ah, so it looks like we are creating this array already, in adding the `valueFromOrdinal` method allows sharing. That sounds good!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14928#discussion_r1269702376

From duke at openjdk.org  Thu Jul 20 16:42:45 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 20 Jul 2023 16:42:45 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <wCL4vOROLQFoktk5IESaD4CpTnBAxiEq9qq7mDO41S0=.690ff507-32ee-402f-b727-5f6ea5f669b4@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
 <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
 <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>
 <rTB4ZN2L094-B1iuBjktkhvQn1OXxnw8M83gGxXIhh4=.fb1c085c-b714-4ec1-9dda-2d099e838430@github.com>
 <5vWADWw1xEPg0Rmq6cgvKRj9CN5cSTBRYOPkDBlkBxk=.b20fed4c-12fe-4dbc-b51e-2d672d74c070@github.com>
 <y2JG_qO6Y_jJyjXraNEOAbl2_SJuUh1elJSm0GFxAH0=.77e0757b-eec9-49ad-ad52-c37d3e3e67a6@github.com>
 <Q2tgKNyIUTLAdt3MdARsHFmz5PLhYcdxyNzaFZyCsK0=.de22d165-0ed0-43b8-8ece-5779fa5bcc78@github.com>
 <Lzi9EKlcwY36SBqlVCN6bYSGatbUBVQiQIYv5Nbzmj0=.c7928875-f0b4-4fd6-816e-8e0357b8a92c@github.com>
 <wCL4vOROLQFoktk5IESaD4CpTnBAxiEq9qq7mDO41S0=.690ff507-32ee-402f-b727-5f6ea5f669b4@
 github.com>
Message-ID: <qHehDUvqpRaBr51w9ZlfWYmT-RmiJ_UVi3AoUEOztmU=.b220ce4f-9807-48af-874b-cb0e03361c5f@github.com>

On Thu, 20 Jul 2023 16:24:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Here's with the same parameters as the one you are using:

I don't understand why there is such a difference. I have replicated similar results on several other devices:

Apple M1:

Benchmark                      Mode  Cnt        Score       Error   Units
ByteArray.readByte            thrpt    5  1418606.665 ?  2308.711  ops/ms
ByteArray.readByteFromBuffer  thrpt    5   879084.678 ? 20981.303  ops/ms
ByteArray.readInt             thrpt    5  1404164.063 ?  4845.412  ops/ms
ByteArray.readIntFromBuffer   thrpt    5   829768.843 ?  8730.467  ops/ms
ByteArray.readLong            thrpt    5  1400713.660 ?  1924.752  ops/ms
ByteArray.readLongFromBuffer  thrpt    5   825721.508 ?  4146.961  ops/ms



Intel Celeron N5105:

Benchmark                      Mode  Cnt       Score        Error   Units
ByteArray.readByte            thrpt    5  927248.807 ?  29630.442  ops/ms
ByteArray.readByteFromBuffer  thrpt    5  448374.359 ?   3210.571  ops/ms
ByteArray.readInt             thrpt    5  719143.935 ? 183584.747  ops/ms
ByteArray.readIntFromBuffer   thrpt    5  398578.488 ?    100.058  ops/ms
ByteArray.readLong            thrpt    5  742555.147 ?  13006.710  ops/ms
ByteArray.readLongFromBuffer  thrpt    5  398771.660 ?   1673.524  ops/ms


AMD Ryzen 7 5800X:

Benchmark                      Mode  Cnt        Score       Error   Units
ByteArray.readByte            thrpt    5  1784096.905 ? 47611.535  ops/ms
ByteArray.readByteFromBuffer  thrpt    5   992974.747 ? 19389.011  ops/ms
ByteArray.readInt             thrpt    5  1719368.129 ? 70606.284  ops/ms
ByteArray.readIntFromBuffer   thrpt    5   919654.075 ?  9292.283  ops/ms
ByteArray.readLong            thrpt    5  1719873.280 ? 18441.122  ops/ms
ByteArray.readLongFromBuffer  thrpt    5   921992.992 ?  6439.747  ops/ms

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269714639

From mcimadamore at openjdk.org  Thu Jul 20 16:42:45 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 16:42:45 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <qHehDUvqpRaBr51w9ZlfWYmT-RmiJ_UVi3AoUEOztmU=.b220ce4f-9807-48af-874b-cb0e03361c5f@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
 <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
 <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>
 <rTB4ZN2L094-B1iuBjktkhvQn1OXxnw8M83gGxXIhh4=.fb1c085c-b714-4ec1-9dda-2d099e838430@github.com>
 <5vWADWw1xEPg0Rmq6cgvKRj9CN5cSTBRYOPkDBlkBxk=.b20fed4c-12fe-4dbc-b51e-2d672d74c070@github.com>
 <y2JG_qO6Y_jJyjXraNEOAbl2_SJuUh1elJSm0GFxAH0=.77e0757b-eec9-49ad-ad52-c37d3e3e67a6@github.com>
 <Q2tgKNyIUTLAdt3MdARsHFmz5PLhYcdxyNzaFZyCsK0=.de22d165-0ed0-43b8-8ece-5779fa5bcc78@github.com>
 <Lzi9EKlcwY36SBqlVCN6bYSGatbUBVQiQIYv5Nbzmj0=.c7928875-f0b4-4fd6-816e-8e0357b8a92c@github.com>
 <wCL4vOROLQFoktk5IESaD4CpTnBAxiEq9qq7mDO41S0=.690ff507-32ee-402f-b727-5f6ea5f669b4@
 github.com>
 <qHehDUvqpRaBr51w9ZlfWYmT-RmiJ_UVi3AoUEOztmU=.b220ce4f-9807-48af-874b-cb0e03361c5f@github.com>
Message-ID: <2Z46WAHv8N0fSBJFgg0-iBXHBM13-9jYYw5mV7i4yMo=.e30c1ff1-fdfb-4883-b612-f1f0d637dc73@github.com>

On Thu, 20 Jul 2023 16:39:31 GMT, Glavo <duke at openjdk.org> wrote:

>> Here's with the same parameters as the one you are using:
>> 
>> Benchmark                      Mode  Cnt       Score       Error   Units
>> ByteArray.readByte            thrpt    5  268722.378 ?  5979.787  ops/ms
>> ByteArray.readByteFromBuffer  thrpt    5  254333.844 ?  6975.034  ops/ms
>> ByteArray.readInt             thrpt    5  271849.915 ?  4746.869  ops/ms
>> ByteArray.readIntFromBuffer   thrpt    5  263109.760 ?  2764.372  ops/ms
>> ByteArray.readLong            thrpt    5  271635.129 ? 14705.673  ops/ms
>> ByteArray.readLongFromBuffer  thrpt    5  252633.826 ?  2950.184  ops/ms
>> 
>> (Java 22/Ubuntu 20.04 on Ryzen 3900X here).
>
>> Here's with the same parameters as the one you are using:
> 
> I don't understand why there is such a difference. I have replicated similar results on several other devices:
> 
> Apple M1:
> 
> Benchmark                      Mode  Cnt        Score       Error   Units
> ByteArray.readByte            thrpt    5  1418606.665 ?  2308.711  ops/ms
> ByteArray.readByteFromBuffer  thrpt    5   879084.678 ? 20981.303  ops/ms
> ByteArray.readInt             thrpt    5  1404164.063 ?  4845.412  ops/ms
> ByteArray.readIntFromBuffer   thrpt    5   829768.843 ?  8730.467  ops/ms
> ByteArray.readLong            thrpt    5  1400713.660 ?  1924.752  ops/ms
> ByteArray.readLongFromBuffer  thrpt    5   825721.508 ?  4146.961  ops/ms
> 
> 
> 
> Intel Celeron N5105:
> 
> Benchmark                      Mode  Cnt       Score        Error   Units
> ByteArray.readByte            thrpt    5  927248.807 ?  29630.442  ops/ms
> ByteArray.readByteFromBuffer  thrpt    5  448374.359 ?   3210.571  ops/ms
> ByteArray.readInt             thrpt    5  719143.935 ? 183584.747  ops/ms
> ByteArray.readIntFromBuffer   thrpt    5  398578.488 ?    100.058  ops/ms
> ByteArray.readLong            thrpt    5  742555.147 ?  13006.710  ops/ms
> ByteArray.readLongFromBuffer  thrpt    5  398771.660 ?   1673.524  ops/ms
> 
> 
> AMD Ryzen 7 5800X:
> 
> Benchmark                      Mode  Cnt        Score       Error   Units
> ByteArray.readByte            thrpt    5  1784096.905 ? 47611.535  ops/ms
> ByteArray.readByteFromBuffer  thrpt    5   992974.747 ? 19389.011  ops/ms
> ByteArray.readInt             thrpt    5  1719368.129 ? 70606.284  ops/ms
> ByteArray.readIntFromBuffer   thrpt    5   919654.075 ?  9292.283  ops/ms
> ByteArray.readLong            thrpt    5  1719873.280 ? 18441.122  ops/ms
> ByteArray.readLongFromBuffer  thrpt    5   921992.992 ?  6439.747  ops/ms

On a newer processor/OS (Alder Lake/Ubuntu 22.04) I see a bit more difference:


Benchmark                      Mode  Cnt       Score       Error   Units
ByteArray.readByte            thrpt    5  680397.046 ? 27504.022  ops/ms
ByteArray.readByteFromBuffer  thrpt    5  576449.569 ?  3633.135  ops/ms
ByteArray.readInt             thrpt    5  685419.089 ?  6740.268  ops/ms
ByteArray.readIntFromBuffer   thrpt    5  542887.418 ?  2863.907  ops/ms
ByteArray.readLong            thrpt    5  687949.037 ?  3510.613  ops/ms
ByteArray.readLongFromBuffer  thrpt    5  548120.950 ?  5461.145  ops/ms


But still far from 2x.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269715099

From mcimadamore at openjdk.org  Thu Jul 20 16:49:48 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 16:49:48 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <2Z46WAHv8N0fSBJFgg0-iBXHBM13-9jYYw5mV7i4yMo=.e30c1ff1-fdfb-4883-b612-f1f0d637dc73@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
 <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
 <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>
 <rTB4ZN2L094-B1iuBjktkhvQn1OXxnw8M83gGxXIhh4=.fb1c085c-b714-4ec1-9dda-2d099e838430@github.com>
 <5vWADWw1xEPg0Rmq6cgvKRj9CN5cSTBRYOPkDBlkBxk=.b20fed4c-12fe-4dbc-b51e-2d672d74c070@github.com>
 <y2JG_qO6Y_jJyjXraNEOAbl2_SJuUh1elJSm0GFxAH0=.77e0757b-eec9-49ad-ad52-c37d3e3e67a6@github.com>
 <Q2tgKNyIUTLAdt3MdARsHFmz5PLhYcdxyNzaFZyCsK0=.de22d165-0ed0-43b8-8ece-5779fa5bcc78@github.com>
 <Lzi9EKlcwY36SBqlVCN6bYSGatbUBVQiQIYv5Nbzmj0=.c7928875-f0b4-4fd6-816e-8e0357b8a92c@github.com>
 <wCL4vOROLQFoktk5IESaD4CpTnBAxiEq9qq7mDO41S0=.690ff507-32ee-402f-b727-5f6ea5f669b4@
 github.com>
 <qHehDUvqpRaBr51w9ZlfWYmT-RmiJ_UVi3AoUEOztmU=.b220ce4f-9807-48af-874b-cb0e03361c5f@github.com>
 <2Z46WAHv8N0fSBJFgg0-iBXHBM13-9jYYw5mV7i4yMo=.e30c1ff1-fdfb-4883-b612-f1f0d637dc73@github.com>
Message-ID: <l_4-vwLQ3kHO-jA7-ajsZNCXPNUNRIK574Xa8efvD6s=.da0ae935-7978-4c30-90e6-c784f6c60b1e@github.com>

On Thu, 20 Jul 2023 16:39:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Here's with the same parameters as the one you are using:
>> 
>> I don't understand why there is such a difference. I have replicated similar results on several other devices:
>> 
>> Apple M1:
>> 
>> Benchmark                      Mode  Cnt        Score       Error   Units
>> ByteArray.readByte            thrpt    5  1418606.665 ?  2308.711  ops/ms
>> ByteArray.readByteFromBuffer  thrpt    5   879084.678 ? 20981.303  ops/ms
>> ByteArray.readInt             thrpt    5  1404164.063 ?  4845.412  ops/ms
>> ByteArray.readIntFromBuffer   thrpt    5   829768.843 ?  8730.467  ops/ms
>> ByteArray.readLong            thrpt    5  1400713.660 ?  1924.752  ops/ms
>> ByteArray.readLongFromBuffer  thrpt    5   825721.508 ?  4146.961  ops/ms
>> 
>> 
>> 
>> Intel Celeron N5105:
>> 
>> Benchmark                      Mode  Cnt       Score        Error   Units
>> ByteArray.readByte            thrpt    5  927248.807 ?  29630.442  ops/ms
>> ByteArray.readByteFromBuffer  thrpt    5  448374.359 ?   3210.571  ops/ms
>> ByteArray.readInt             thrpt    5  719143.935 ? 183584.747  ops/ms
>> ByteArray.readIntFromBuffer   thrpt    5  398578.488 ?    100.058  ops/ms
>> ByteArray.readLong            thrpt    5  742555.147 ?  13006.710  ops/ms
>> ByteArray.readLongFromBuffer  thrpt    5  398771.660 ?   1673.524  ops/ms
>> 
>> 
>> AMD Ryzen 7 5800X:
>> 
>> Benchmark                      Mode  Cnt        Score       Error   Units
>> ByteArray.readByte            thrpt    5  1784096.905 ? 47611.535  ops/ms
>> ByteArray.readByteFromBuffer  thrpt    5   992974.747 ? 19389.011  ops/ms
>> ByteArray.readInt             thrpt    5  1719368.129 ? 70606.284  ops/ms
>> ByteArray.readIntFromBuffer   thrpt    5   919654.075 ?  9292.283  ops/ms
>> ByteArray.readLong            thrpt    5  1719873.280 ? 18441.122  ops/ms
>> ByteArray.readLongFromBuffer  thrpt    5   921992.992 ?  6439.747  ops/ms
>
> On a newer processor/OS (Alder Lake/Ubuntu 22.04) I see a bit more difference:
> 
> 
> Benchmark                      Mode  Cnt       Score       Error   Units
> ByteArray.readByte            thrpt    5  680397.046 ? 27504.022  ops/ms
> ByteArray.readByteFromBuffer  thrpt    5  576449.569 ?  3633.135  ops/ms
> ByteArray.readInt             thrpt    5  685419.089 ?  6740.268  ops/ms
> ByteArray.readIntFromBuffer   thrpt    5  542887.418 ?  2863.907  ops/ms
> ByteArray.readLong            thrpt    5  687949.037 ?  3510.613  ops/ms
> ByteArray.readLongFromBuffer  thrpt    5  548120.950 ?  5461.145  ops/ms
> 
> 
> But still far from 2x.

For full disclosure, I'm running the benchmark using the JDK microbenchmark support. My JMH version is a bit behind. I've updated it to 1.35 (which is the latest I see being used around here) and getting similar results.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269722383

From mchung at openjdk.org  Thu Jul 20 16:58:01 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 20 Jul 2023 16:58:01 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v5]
In-Reply-To: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
Message-ID: <WVxvFDJCdEqfGB8x5pEF4ex2O4BnE_RAUW4rcPNvGdQ=.5ac480e8-be85-4c92-8ccd-b8ce6359c941@github.com>

> `VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported.   To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information.  Changes include:
> 
> 1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported.  This check is only needed for direct var handle.
> 2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported
> 
> The error message looks like:
> 
> java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  replace other use of AccessMode.values() with valueFromOrdinal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14928/files
  - new: https://git.openjdk.org/jdk/pull/14928/files/f82b2146..cd46a75a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14928&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14928&range=03-04

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14928/head:pull/14928

PR: https://git.openjdk.org/jdk/pull/14928

From jvernee at openjdk.org  Thu Jul 20 16:58:01 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Jul 2023 16:58:01 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v5]
In-Reply-To: <WVxvFDJCdEqfGB8x5pEF4ex2O4BnE_RAUW4rcPNvGdQ=.5ac480e8-be85-4c92-8ccd-b8ce6359c941@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
 <WVxvFDJCdEqfGB8x5pEF4ex2O4BnE_RAUW4rcPNvGdQ=.5ac480e8-be85-4c92-8ccd-b8ce6359c941@github.com>
Message-ID: <shZt6dzmOjeNdEbYiW3diWfFZMHAkLvAqekW4Iu-yQE=.aa2bf1b9-5871-44f1-b6a6-97546b1a8684@github.com>

On Thu, 20 Jul 2023 16:53:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported.   To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information.  Changes include:
>> 
>> 1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported.  This check is only needed for direct var handle.
>> 2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported
>> 
>> The error message looks like:
>> 
>> java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace other use of AccessMode.values() with valueFromOrdinal

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14928#pullrequestreview-1539700552

From mchung at openjdk.org  Thu Jul 20 16:58:01 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 20 Jul 2023 16:58:01 GMT
Subject: RFR: 8199149: Improve the exception message thrown by VarHandle of
 unsupported operation [v4]
In-Reply-To: <9crb5lQ86ziHOA6YizgRBqN0-DqYr-cbmDqWfwEoGqQ=.f8d8bf01-8afe-4d91-8fae-ae3b73fa3a55@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
 <QShP3BrYVmCo0PXBTGxc4VfdZzwtCSXccDASl3getg8=.328c111a-e693-408f-a693-404ff8f4f023@github.com>
 <Ov_cZHUo_idpvVZrOFj8iXLYdP-JXnkYTjfFnRKHSU4=.52d0eee1-e925-4465-b289-5985eca0eea8@github.com>
 <7TiWqq5e3YGY603WP9RA_-2opD6xoKNm4N31X2Z5Avg=.cd56f086-5489-46cf-8212-3fc7ad88ed77@github.com>
 <9crb5lQ86ziHOA6YizgRBqN0-DqYr-cbmDqWfwEoGqQ=.f8d8bf01-8afe-4d91-8fae-ae3b73fa3a55@github.com>
Message-ID: <YBt7He-Ik9kCrTy8LpyXVoQGP_BMAC3YzNRItXvp57g=.2f9b1668-ae8f-411f-ac97-9e9a0fe8b023@github.com>

On Thu, 20 Jul 2023 16:26:51 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I think this is a worthy change: see https://github.com/openjdk/jdk/pull/14943/files#diff-556b309ea2df3f5bfe8229de944183ef19750ce4511d0328cd59af2ce2b61ae2R135
>> that `VarHandle.AccessMode.values()` is called every time a polymorphic VH call is linked.
>> 
>> If the startup cost from array allocation is really problematic, we can make it stable and allocate `VALUES` on demand (at `valueFromOrdinal` calls).
>
> Ah, so it looks like we are creating this array already, in adding the `valueFromOrdinal` method allows sharing. That sounds good!

The overhead is just one time allocation of an array of length 31, which is a very small array which I don't think such small array creation impacts as much.

I should have replaced other uses of `AccessMode.values()`.   I will include that change in this patch. 

@liach  I don't know about `AccessType.values()` which seems to me not worth the change to add `valueFromOrdinal` as only calls that 6 times.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14928#discussion_r1269725114

From duke at openjdk.org  Thu Jul 20 17:01:45 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 20 Jul 2023 17:01:45 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <l_4-vwLQ3kHO-jA7-ajsZNCXPNUNRIK574Xa8efvD6s=.da0ae935-7978-4c30-90e6-c784f6c60b1e@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
 <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
 <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>
 <rTB4ZN2L094-B1iuBjktkhvQn1OXxnw8M83gGxXIhh4=.fb1c085c-b714-4ec1-9dda-2d099e838430@github.com>
 <5vWADWw1xEPg0Rmq6cgvKRj9CN5cSTBRYOPkDBlkBxk=.b20fed4c-12fe-4dbc-b51e-2d672d74c070@github.com>
 <y2JG_qO6Y_jJyjXraNEOAbl2_SJuUh1elJSm0GFxAH0=.77e0757b-eec9-49ad-ad52-c37d3e3e67a6@github.com>
 <Q2tgKNyIUTLAdt3MdARsHFmz5PLhYcdxyNzaFZyCsK0=.de22d165-0ed0-43b8-8ece-5779fa5bcc78@github.com>
 <Lzi9EKlcwY36SBqlVCN6bYSGatbUBVQiQIYv5Nbzmj0=.c7928875-f0b4-4fd6-816e-8e0357b8a92c@github.com>
 <wCL4vOROLQFoktk5IESaD4CpTnBAxiEq9qq7mDO41S0=.690ff507-32ee-402f-b727-5f6ea5f669b4@
 github.com>
 <qHehDUvqpRaBr51w9ZlfWYmT-RmiJ_UVi3AoUEOztmU=.b220ce4f-9807-48af-874b-cb0e03361c5f@github.com>
 <2Z46WAHv8N0fSBJFgg0-iBXHBM13-9jYYw5mV7i4yMo=.e30c1ff1-fdfb-4883-b612-f1f0d637dc73@github.com>
 <l_4-vwLQ3kHO-jA7-ajsZNCXPNUNRIK574Xa8efvD6s=.da0ae935-7978-4c30-90e6-c784f6c60b1e@github.com>
Message-ID: <qsl35SFoAlrzBj_CJlxtYOEUHqP-zIR7GZtAO9nVmrI=.a87d32f8-8ba0-4ccd-aba8-42199c4fd8c2@github.com>

On Thu, 20 Jul 2023 16:47:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> On a newer processor/OS (Alder Lake/Ubuntu 22.04) I see a bit more difference:
>> 
>> 
>> Benchmark                      Mode  Cnt       Score       Error   Units
>> ByteArray.readByte            thrpt    5  680397.046 ? 27504.022  ops/ms
>> ByteArray.readByteFromBuffer  thrpt    5  576449.569 ?  3633.135  ops/ms
>> ByteArray.readInt             thrpt    5  685419.089 ?  6740.268  ops/ms
>> ByteArray.readIntFromBuffer   thrpt    5  542887.418 ?  2863.907  ops/ms
>> ByteArray.readLong            thrpt    5  687949.037 ?  3510.613  ops/ms
>> ByteArray.readLongFromBuffer  thrpt    5  548120.950 ?  5461.145  ops/ms
>> 
>> 
>> But still far from 2x.
>
> For full disclosure, I'm running the benchmark using the JDK microbenchmark support. My JMH version is a bit behind. I've updated it to 1.35 (which is the latest I see being used around here) and getting similar results.

By the way, I ran `LoopOverNonConstantHeap` on the 3700x platform, and the performance of ByteBuffer was also poor:


Benchmark                                                (polluteProfile)  Mode  Cnt  Score    Error  Units
LoopOverNonConstantHeap.BB_get                                      false  avgt   30  1.855 ?  0.092  ns/op
LoopOverNonConstantHeap.BB_get                                       true  avgt   30  1.655 ?  0.010  ns/op
LoopOverNonConstantHeap.BB_loop                                     false  avgt   30  0.254 ?  0.001  ms/op
LoopOverNonConstantHeap.BB_loop                                      true  avgt   30  0.254 ?  0.001  ms/op
LoopOverNonConstantHeap.segment_get                                 false  avgt   30  2.333 ?  0.043  ns/op
LoopOverNonConstantHeap.segment_get                                  true  avgt   30  2.362 ?  0.006  ns/op
LoopOverNonConstantHeap.segment_loop                                false  avgt   30  0.251 ?  0.001  ms/op
LoopOverNonConstantHeap.segment_loop                                 true  avgt   30  0.251 ?  0.001  ms/op
LoopOverNonConstantHeap.segment_loop_instance                       false  avgt   30  0.254 ?  0.001  ms/op
LoopOverNonConstantHeap.segment_loop_instance                        true  avgt   30  0.254 ?  0.001  ms/op
LoopOverNonConstantHeap.segment_loop_instance_unaligned             false  avgt   30  0.254 ?  0.001  ms/op
LoopOverNonConstantHeap.segment_loop_instance_unaligned              true  avgt   30  0.254 ?  0.001  ms/op
LoopOverNonConstantHeap.segment_loop_readonly                       false  avgt   30  0.252 ?  0.001  ms/op
LoopOverNonConstantHeap.segment_loop_readonly                        true  avgt   30  0.251 ?  0.001  ms/op
LoopOverNonConstantHeap.segment_loop_slice                          false  avgt   30  0.251 ?  0.001  ms/op
LoopOverNonConstantHeap.segment_loop_slice                           true  avgt   30  0.252 ?  0.001  ms/op
LoopOverNonConstantHeap.segment_loop_unaligned                      false  avgt   30  0.251 ?  0.001  ms/op
LoopOverNonConstantHeap.segment_loop_unaligned                       true  avgt   30  0.252 ?  0.001  ms/op
LoopOverNonConstantHeap.unsafe_get                                  false  avgt   30  0.628 ?  0.004  ns/op
LoopOverNonConstantHeap.unsafe_get                                   true  avgt   30  0.628 ?  0.003  ns/op
LoopOverNonConstantHeap.unsafe_loop                                 false  avgt   30  0.255 ?  0.001  ms/op
LoopOverNonConstantHeap.unsafe_loop                                  true  avgt   30  0.256 ?  0.001  ms/op

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269733363

From mcimadamore at openjdk.org  Thu Jul 20 17:30:44 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 17:30:44 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <qsl35SFoAlrzBj_CJlxtYOEUHqP-zIR7GZtAO9nVmrI=.a87d32f8-8ba0-4ccd-aba8-42199c4fd8c2@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
 <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
 <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>
 <rTB4ZN2L094-B1iuBjktkhvQn1OXxnw8M83gGxXIhh4=.fb1c085c-b714-4ec1-9dda-2d099e838430@github.com>
 <5vWADWw1xEPg0Rmq6cgvKRj9CN5cSTBRYOPkDBlkBxk=.b20fed4c-12fe-4dbc-b51e-2d672d74c070@github.com>
 <y2JG_qO6Y_jJyjXraNEOAbl2_SJuUh1elJSm0GFxAH0=.77e0757b-eec9-49ad-ad52-c37d3e3e67a6@github.com>
 <Q2tgKNyIUTLAdt3MdARsHFmz5PLhYcdxyNzaFZyCsK0=.de22d165-0ed0-43b8-8ece-5779fa5bcc78@github.com>
 <Lzi9EKlcwY36SBqlVCN6bYSGatbUBVQiQIYv5Nbzmj0=.c7928875-f0b4-4fd6-816e-8e0357b8a92c@github.com>
 <wCL4vOROLQFoktk5IESaD4CpTnBAxiEq9qq7mDO41S0=.690ff507-32ee-402f-b727-5f6ea5f669b4@
 github.com>
 <qHehDUvqpRaBr51w9ZlfWYmT-RmiJ_UVi3AoUEOztmU=.b220ce4f-9807-48af-874b-cb0e03361c5f@github.com>
 <2Z46WAHv8N0fSBJFgg0-iBXHBM13-9jYYw5mV7i4yMo=.e30c1ff1-fdfb-4883-b612-f1f0d637dc73@github.com>
 <l_4-vwLQ3kHO-jA7-ajsZNCXPNUNRIK574Xa8efvD6s=.da0ae935-7978-4c30-90e6-c784f6c60b1e@github.com>
 <qsl35SFoAlrzBj_CJlxtYOEUHqP-zIR7GZtAO9nVmrI=.a87d32f8-8ba0-4ccd-aba8-42199c4fd8c2@github.com>
Message-ID: <sbB0IUGrHgz0Gj9rPYB_rYcJlTc1dUMhvbYDvi_1N7o=.0cc2938b-aaf5-4dd6-96ba-c0bb0d0d6581@github.com>

On Thu, 20 Jul 2023 16:58:44 GMT, Glavo <duke at openjdk.org> wrote:

> By the way, I ran `LoopOverNonConstantHeap` on the 3700x platform, and the performance of ByteBuffer was also poor:

I finally see it.


Benchmark                           (polluteProfile)  Mode  Cnt  Score   Error  Units
LoopOverNonConstantHeap.BB_get                 false  avgt   30  1.801 ? 0.020  ns/op
LoopOverNonConstantHeap.unsafe_get             false  avgt   30  0.567 ? 0.007  


It seems that, between updating JMH and rebuilding the JDK from scratch, *something* did the trick.

While I knew that random access on a BB is slower than Unsafe (as there's an extra check), whereas looped access is as fast (as C2 is good at hoisting the checks outside the loop, as shown in the benchmark). Note also that we are in the nanosecond realm, so each instruction here counts.

Is there any benchmark for DataInput/Output stream that can be used? I mean, it would be interesting to understand how these numbers translate when running the stuff that is built on top.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269763302

From rriggs at openjdk.org  Thu Jul 20 18:52:45 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Jul 2023 18:52:45 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v7]
In-Reply-To: <1dEun4T-zq47Un7WaIYRz2vbGECpwcGw2bhCDc-Ggrg=.6ce9b8b7-7895-4c5a-a00e-e7b9a6dfc000@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <1dEun4T-zq47Un7WaIYRz2vbGECpwcGw2bhCDc-Ggrg=.6ce9b8b7-7895-4c5a-a00e-e7b9a6dfc000@github.com>
Message-ID: <f7LLThLK_m0d5djuOolhF58_e4O5F0v_Xeq_KZiosQw=.b1eda404-64e6-413f-b338-44dd990eaffc@github.com>

On Tue, 11 Jul 2023 17:54:23 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 12 additional commits since the last revision:
> 
>  - Improve wording and remove markup for clarity
>  - Merge branch 'master' into 8310033-time-compareto
>  - Correct the descriptions to correctly identify the compareTo return
>    value < 0 as this is before that, and > 0 as this is after that.
>    Thanks to a careful reviewer spotting my reversing of the conditions.
>  - Improve the grammar of "the comparator value is" -> "the comparator value, that is"
>    Thanks for the reminder.
>  - Merge branch 'master' into 8310033-time-compareto
>  - Improve descriptions to be more specific and remove inappropriate use of before/after
>    Remove extra blank lines
>  - Clarify return values of date time classes
>  - 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
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/cbbf7dea...1d39e2d4

Please re-review; its doc-only so can be still included in JDK 21.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14479#issuecomment-1644428298

From scolebourne at openjdk.org  Thu Jul 20 19:37:46 2023
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Thu, 20 Jul 2023 19:37:46 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v7]
In-Reply-To: <1dEun4T-zq47Un7WaIYRz2vbGECpwcGw2bhCDc-Ggrg=.6ce9b8b7-7895-4c5a-a00e-e7b9a6dfc000@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <1dEun4T-zq47Un7WaIYRz2vbGECpwcGw2bhCDc-Ggrg=.6ce9b8b7-7895-4c5a-a00e-e7b9a6dfc000@github.com>
Message-ID: <m8Ra--daQNdWItn6Cr-KdNYq7Nq53Ie2CwrKbu9Ef6w=.730a6c46-250e-43ed-bf32-34ef33ad2b31@github.com>

On Tue, 11 Jul 2023 17:54:23 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 12 additional commits since the last revision:
> 
>  - Improve wording and remove markup for clarity
>  - Merge branch 'master' into 8310033-time-compareto
>  - Correct the descriptions to correctly identify the compareTo return
>    value < 0 as this is before that, and > 0 as this is after that.
>    Thanks to a careful reviewer spotting my reversing of the conditions.
>  - Improve the grammar of "the comparator value is" -> "the comparator value, that is"
>    Thanks for the reminder.
>  - Merge branch 'master' into 8310033-time-compareto
>  - Improve descriptions to be more specific and remove inappropriate use of before/after
>    Remove extra blank lines
>  - Clarify return values of date time classes
>  - 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
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/cbfb208d...1d39e2d4

Changes requested by scolebourne (Author).

src/java.base/share/classes/java/time/LocalDate.java line 1991:

> 1989:      *
> 1990:      * @param other  the other date to compare to, not null
> 1991:      * @return the comparator value, that is less than zero if this is before {@code other},

This text is incorrect. It does not match the description above re chronologies.

src/java.base/share/classes/java/time/LocalDateTime.java line 1810:

> 1808:      *
> 1809:      * @param other  the other date-time to compare to, not null
> 1810:      * @return the comparator value, that is less than zero if this is before {@code other},

This text is incorrect. It does not match the description above re chronologies.

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, that is the comparison with the {@code other}'s instant, if they are not equal;

This text is incorrect. It does not match the description above re offsets. (This would be a suitable description for `compareInstant`)

src/java.base/share/classes/java/time/OffsetTime.java line 1286:

> 1284:      * @return the comparator value, that is the comparison of the UTC equivalent {@code other} instant,
> 1285:      *          if they are not equal, and if the UTC equivalent {@code other} instant is equal,
> 1286:      *          the comparison of this local date-time with {@code other} local date-time

This text is incorrect. It compares the local time, not the local date-time, when  the instants are equal

src/java.base/share/classes/java/time/chrono/ChronoLocalDate.java line 703:

> 701:      *
> 702:      * @param other  the other date to compare to, not null
> 703:      * @return the comparator value, that is less than zero if this is before {@code other},

This text is incorrect. It does not match the description above re chronologies.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14479#pullrequestreview-1539950887
PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1269880032
PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1269879973
PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1269881117
PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1269883364
PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1269884657

From mchung at openjdk.org  Thu Jul 20 20:24:53 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 20 Jul 2023 20:24:53 GMT
Subject: Integrated: 8199149: Improve the exception message thrown by VarHandle
 of unsupported operation
In-Reply-To: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
References: <jXaZ-dMRYo8dm8XMFv7TpgyU-VdhwC_rkteJWu0NCq8=.bf526c7a-f620-4036-bbc0-3f7fd560a1a8@github.com>
Message-ID: <uOXOdq-ZF2s0EY4f_scgSj1owWToMn7hgBjKov6YxQQ=.bada46e7-f3fb-4ba8-84d4-752ce233d884@github.com>

On Wed, 19 Jul 2023 00:12:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported.   To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information.  Changes include:
> 
> 1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported.  This check is only needed for direct var handle.
> 2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported
> 
> The error message looks like:
> 
> java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]

This pull request has now been integrated.

Changeset: d7b94164
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d7b941640638b35f9ac1ef11cd6bf6ccb795c29a
Stats:     12 lines in 4 files changed: 7 ins; 0 del; 5 mod

8199149: Improve the exception message thrown by VarHandle of unsupported operation

Reviewed-by: liach, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/14928

From mcimadamore at openjdk.org  Thu Jul 20 21:46:43 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 21:46:43 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <sbB0IUGrHgz0Gj9rPYB_rYcJlTc1dUMhvbYDvi_1N7o=.0cc2938b-aaf5-4dd6-96ba-c0bb0d0d6581@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
 <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
 <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>
 <rTB4ZN2L094-B1iuBjktkhvQn1OXxnw8M83gGxXIhh4=.fb1c085c-b714-4ec1-9dda-2d099e838430@github.com>
 <5vWADWw1xEPg0Rmq6cgvKRj9CN5cSTBRYOPkDBlkBxk=.b20fed4c-12fe-4dbc-b51e-2d672d74c070@github.com>
 <y2JG_qO6Y_jJyjXraNEOAbl2_SJuUh1elJSm0GFxAH0=.77e0757b-eec9-49ad-ad52-c37d3e3e67a6@github.com>
 <Q2tgKNyIUTLAdt3MdARsHFmz5PLhYcdxyNzaFZyCsK0=.de22d165-0ed0-43b8-8ece-5779fa5bcc78@github.com>
 <Lzi9EKlcwY36SBqlVCN6bYSGatbUBVQiQIYv5Nbzmj0=.c7928875-f0b4-4fd6-816e-8e0357b8a92c@github.com>
 <wCL4vOROLQFoktk5IESaD4CpTnBAxiEq9qq7mDO41S0=.690ff507-32ee-402f-b727-5f6ea5f669b4@
 github.com>
 <qHehDUvqpRaBr51w9ZlfWYmT-RmiJ_UVi3AoUEOztmU=.b220ce4f-9807-48af-874b-cb0e03361c5f@github.com>
 <2Z46WAHv8N0fSBJFgg0-iBXHBM13-9jYYw5mV7i4yMo=.e30c1ff1-fdfb-4883-b612-f1f0d637dc73@github.com>
 <l_4-vwLQ3kHO-jA7-ajsZNCXPNUNRIK574Xa8efvD6s=.da0ae935-7978-4c30-90e6-c784f6c60b1e@github.com>
 <qsl35SFoAlrzBj_CJlxtYOEUHqP-zIR7GZtAO9nVmrI=.a87d32f8-8ba0-4ccd-aba8-42199c4fd8c2@github.com>
 <sbB0IUGrHgz0Gj9rPYB_rYcJlTc1dUMhvbYDvi_1N7o=.0cc2938b-aaf5-4dd6-96ba-c0bb0d0d6581@github.com>
Message-ID: <JZAJRO1jljQ5G_qVDIEVUCeNsn1EBuZjaRmbTqTAHxc=.9d850bed-02cb-4abf-af26-f39ccced98de@github.com>

On Thu, 20 Jul 2023 17:27:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Is there any benchmark for DataInput/Output stream that can be used? I mean, it would be interesting to understand how these numbers translate when running the stuff that is built on top.

I've tried to run the benchmark in test/micro/java/io/DataInputStream.java. This is the baseline:


Benchmark                     Mode  Cnt  Score   Error  Units
DataInputStreamTest.readChar  avgt   20  7.583 ? 0.026  us/op
DataInputStreamTest.readInt   avgt   20  3.804 ? 0.045  us/op


And this is with a patch similar to the one I shared above, to use ByteBuffer internally:


Benchmark                     Mode  Cnt  Score   Error  Units
DataInputStreamTest.readChar  avgt   20  7.594 ? 0.106  us/op
DataInputStreamTest.readInt   avgt   20  3.795 ? 0.030  us/op


There does not seem to be any extra overhead. That said, access occurs in a counted loop, and in these cases we know buffer/segment access is optimized quite well.

I believe the question here is: do we have benchmark which are representative of the kind of gain that would be introduced by micro-optimizing ByteArray? It can be quite tricky to estimate real benefits from synthetic benchmark on the ByteArray class, especially when fetching a single element outside of a loop - as those are not representative of how the clients will use this. I note that the original benchmark made by Per used a loop with two iterations to assess the cost of the ByteArray operations:

http://minborgsjavapot.blogspot.com/2023/01/java-21-performance-improvements.html

If I change the benchmark to do 2 iterations, I see this:


Benchmark                      Mode  Cnt       Score       Error   Units
ByteArray.readByte            thrpt    5  704199.172 ? 34101.508  ops/ms
ByteArray.readByteFromBuffer  thrpt    5  474321.828 ?  6588.471  ops/ms
ByteArray.readInt             thrpt    5  662411.181 ?  4470.951  ops/ms
ByteArray.readIntFromBuffer   thrpt    5  496900.429 ?  3705.737  ops/ms
ByteArray.readLong            thrpt    5  665138.063 ?  5944.814  ops/ms
ByteArray.readLongFromBuffer  thrpt    5  517781.548 ? 27106.331  ops/ms

The more the iterations, the less the cost (and you don't need many iterations to break even). This probably explains why the DataInputStream benchmark doesn't change - there's 1024 iterations in there.

I guess all this is to say that excessively focussing on microbenchmark of a simple class such as ByteArray in conditions that are likely unrealistic (e.g. single access) is IMHO the wrong way to look at things, as ByteArray is mostly used by classes that most definitively will read more than one value at a time (including classfile API). 

So, also IMHO, we should try to measure the use cases we care about of the higher-level API we care about (I/O streams, classfile) and then see if adding Unsafe/VarHandle/ByteBuffer access in here is going to lead to any benefit at all.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269993992

From liach at openjdk.org  Thu Jul 20 23:56:45 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Jul 2023 23:56:45 GMT
Subject: RFR: 8312486: Allow abstract classes for
 MethodHandleProxies::asInterfaceInstance
Message-ID: <v8BUgB-cm0BNnEzDc-iXfwcdJ-yUIfF_ZZB5CbIpXRY=.40d4e14e-d3a6-45b3-886d-764e544c99b2@github.com>

With the reimplementation of MHP.asIFInstance, now it can easily adapt to abstract classes as well. Repurposed PublicMethods from java.lang to track method inheritance for MHP to reduce redundancies.

-------------

Commit messages:
 - Merge branch 'master' into explore/mhp-samclass
 - Minor spec updates, tests, Security Manager fixed
 - try fix security manager
 - First draft of interface instance for SAM no-arg ctor abstract classes

Changes: https://git.openjdk.org/jdk/pull/14966/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14966&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312486
  Stats: 287 lines in 6 files changed: 213 ins; 17 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/14966.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14966/head:pull/14966

PR: https://git.openjdk.org/jdk/pull/14966

From duke at openjdk.org  Fri Jul 21 09:33:44 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 21 Jul 2023 09:33:44 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v8]
In-Reply-To: <QXX0pY3HHUHnMCJQ-c_JSBRJmpe8_3KcYLscidPPNK0=.f36819ab-1fb7-4a18-ad38-c2829b385b89@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <QXX0pY3HHUHnMCJQ-c_JSBRJmpe8_3KcYLscidPPNK0=.f36819ab-1fb7-4a18-ad38-c2829b385b89@github.com>
Message-ID: <9c_CbQGsIFn8wlww8eVC_yqBC9U1mvdCvd3apnOkpBI=.b8f1e25e-d096-4c64-9324-f80c991de445@github.com>

On Thu, 20 Jul 2023 10:26:03 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This update addresses performance issues across both LinkedTransferQueue and SynchronousQueue by creating a common basis for implementation across them (mainly in LinkedTransferQueue).  Pasting from internal doc summary of changes:
>>      * * Class DualNode replaces Qnode, with fields and methods
>>      *   that apply to any match-based dual data structure, and now
>>      *   usable in other j.u.c classes. in particular, SynchronousQueue.
>>      * * Blocking control (in class DualNode) accommodates
>>      *   VirtualThreads and (perhaps virtualized) uniprocessors.
>>      * * All fields of this class (LinkedTransferQueue) are
>>      *   default-initializable (to null), allowing further extension
>>      *   (in particular, SynchronousQueue.Transferer)
>>      * * Head and tail fields are lazily initialized rather than set
>>      *   to a dummy node, while also reducing retries under heavy
>>      *   contention and misorderings, and relaxing some accesses,
>>      *   requiring accommodation in many places (as well as
>>      *   adjustments in WhiteBox tests).
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nitpicks

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 397:

> 395:          * True if system is a uniprocessor, occasionally rechecked.
> 396:          */
> 397:         private static boolean isUniprocessor =

@DougLea  If this is intentionally non-volatile, I think it is worth documenting the rationale.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270466743

From duke at openjdk.org  Fri Jul 21 09:37:57 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 21 Jul 2023 09:37:57 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v8]
In-Reply-To: <QXX0pY3HHUHnMCJQ-c_JSBRJmpe8_3KcYLscidPPNK0=.f36819ab-1fb7-4a18-ad38-c2829b385b89@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <QXX0pY3HHUHnMCJQ-c_JSBRJmpe8_3KcYLscidPPNK0=.f36819ab-1fb7-4a18-ad38-c2829b385b89@github.com>
Message-ID: <D4Hu-toNeRhEqXoKhpqPkC00LDnrIfkdlGapoL3zKUw=.0c0bf134-3aab-407a-981d-198afcb168ca@github.com>

On Thu, 20 Jul 2023 10:26:03 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This update addresses performance issues across both LinkedTransferQueue and SynchronousQueue by creating a common basis for implementation across them (mainly in LinkedTransferQueue).  Pasting from internal doc summary of changes:
>>      * * Class DualNode replaces Qnode, with fields and methods
>>      *   that apply to any match-based dual data structure, and now
>>      *   usable in other j.u.c classes. in particular, SynchronousQueue.
>>      * * Blocking control (in class DualNode) accommodates
>>      *   VirtualThreads and (perhaps virtualized) uniprocessors.
>>      * * All fields of this class (LinkedTransferQueue) are
>>      *   default-initializable (to null), allowing further extension
>>      *   (in particular, SynchronousQueue.Transferer)
>>      * * Head and tail fields are lazily initialized rather than set
>>      *   to a dummy node, while also reducing retries under heavy
>>      *   contention and misorderings, and relaxing some accesses,
>>      *   requiring accommodation in many places (as well as
>>      *   adjustments in WhiteBox tests).
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nitpicks

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 446:

> 444:                         Thread.onSpinWait();
> 445:                     else
> 446:                         LockSupport.parkNanos(ns);

@DougLea If `ns` is sufficiently large, would it not make sense to use managed blocking in case the current thread is a FJWT as below? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270470268

From duke at openjdk.org  Fri Jul 21 09:42:42 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 21 Jul 2023 09:42:42 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v8]
In-Reply-To: <QXX0pY3HHUHnMCJQ-c_JSBRJmpe8_3KcYLscidPPNK0=.f36819ab-1fb7-4a18-ad38-c2829b385b89@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <QXX0pY3HHUHnMCJQ-c_JSBRJmpe8_3KcYLscidPPNK0=.f36819ab-1fb7-4a18-ad38-c2829b385b89@github.com>
Message-ID: <VrQL8M_bN3VJU5RJm75XHCtNUzKVY4AqI0sB5UpjJCA=.8977e3d7-b167-40c5-a2e2-fbfc4768c850@github.com>

On Thu, 20 Jul 2023 10:26:03 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This update addresses performance issues across both LinkedTransferQueue and SynchronousQueue by creating a common basis for implementation across them (mainly in LinkedTransferQueue).  Pasting from internal doc summary of changes:
>>      * * Class DualNode replaces Qnode, with fields and methods
>>      *   that apply to any match-based dual data structure, and now
>>      *   usable in other j.u.c classes. in particular, SynchronousQueue.
>>      * * Blocking control (in class DualNode) accommodates
>>      *   VirtualThreads and (perhaps virtualized) uniprocessors.
>>      * * All fields of this class (LinkedTransferQueue) are
>>      *   default-initializable (to null), allowing further extension
>>      *   (in particular, SynchronousQueue.Transferer)
>>      * * Head and tail fields are lazily initialized rather than set
>>      *   to a dummy node, while also reducing retries under heavy
>>      *   contention and misorderings, and relaxing some accesses,
>>      *   requiring accommodation in many places (as well as
>>      *   adjustments in WhiteBox tests).
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nitpicks

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 612:

> 610:         else if (m != null)
> 611:             s.selfLinkItem();
> 612:         return m;

@DougLea I'd probably add a newline before the return statement to visually distinguish that it isn't intended to be read as a part of the if-else branches.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270476396

From uschindler at openjdk.org  Fri Jul 21 09:46:43 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Fri, 21 Jul 2023 09:46:43 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <JZAJRO1jljQ5G_qVDIEVUCeNsn1EBuZjaRmbTqTAHxc=.9d850bed-02cb-4abf-af26-f39ccced98de@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
 <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
 <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>
 <rTB4ZN2L094-B1iuBjktkhvQn1OXxnw8M83gGxXIhh4=.fb1c085c-b714-4ec1-9dda-2d099e838430@github.com>
 <5vWADWw1xEPg0Rmq6cgvKRj9CN5cSTBRYOPkDBlkBxk=.b20fed4c-12fe-4dbc-b51e-2d672d74c070@github.com>
 <y2JG_qO6Y_jJyjXraNEOAbl2_SJuUh1elJSm0GFxAH0=.77e0757b-eec9-49ad-ad52-c37d3e3e67a6@github.com>
 <Q2tgKNyIUTLAdt3MdARsHFmz5PLhYcdxyNzaFZyCsK0=.de22d165-0ed0-43b8-8ece-5779fa5bcc78@github.com>
 <Lzi9EKlcwY36SBqlVCN6bYSGatbUBVQiQIYv5Nbzmj0=.c7928875-f0b4-4fd6-816e-8e0357b8a92c@github.com>
 <wCL4vOROLQFoktk5IESaD4CpTnBAxiEq9qq7mDO41S0=.690ff507-32ee-402f-b727-5f6ea5f669b4@
 github.com>
 <qHehDUvqpRaBr51w9ZlfWYmT-RmiJ_UVi3AoUEOztmU=.b220ce4f-9807-48af-874b-cb0e03361c5f@github.com>
 <2Z46WAHv8N0fSBJFgg0-iBXHBM13-9jYYw5mV7i4yMo=.e30c1ff1-fdfb-4883-b612-f1f0d637dc73@github.com>
 <l_4-vwLQ3kHO-jA7-ajsZNCXPNUNRIK574Xa8efvD6s=.da0ae935-7978-4c30-90e6-c784f6c60b1e@github.com>
 <qsl35SFoAlrzBj_CJlxtYOEUHqP-zIR7GZtAO9nVmrI=.a87d32f8-8ba0-4ccd-aba8-42199c4fd8c2@github.com>
 <sbB0IUGrHgz0Gj9rPYB_rYcJlTc1dUMhvbYDvi_1N7o=.0cc2938b-aaf5-4dd6-96ba-c0bb0d0d6581@github.com>
 <JZAJRO1jljQ5G_qVDIEVUCeNsn1EBuZjaRmbTqTAHxc=.9d850bed-02cb-4abf-af26-f39ccced98de@github.com>
Message-ID: <8ehoqZ03U2jtaV19chg-02fJjQ1i4umzzrIZUqL8MF8=.bd1d24ea-38ae-49a1-a26d-cffed575e72b@github.com>

On Thu, 20 Jul 2023 21:43:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> By the way, I ran `LoopOverNonConstantHeap` on the 3700x platform, and the performance of ByteBuffer was also poor:
>> 
>> I finally see it.
>> 
>> 
>> Benchmark                           (polluteProfile)  Mode  Cnt  Score   Error  Units
>> LoopOverNonConstantHeap.BB_get                 false  avgt   30  1.801 ? 0.020  ns/op
>> LoopOverNonConstantHeap.unsafe_get             false  avgt   30  0.567 ? 0.007  
>> 
>> 
>> It seems that, between updating JMH and rebuilding the JDK from scratch, *something* did the trick.
>> 
>> While I knew that random access on a BB is slower than Unsafe (as there's an extra check), whereas looped access is as fast (as C2 is good at hoisting the checks outside the loop, as shown in the benchmark). Note also that we are in the nanosecond realm, so each instruction here counts.
>> 
>> Is there any benchmark for DataInput/Output stream that can be used? I mean, it would be interesting to understand how these numbers translate when running the stuff that is built on top.
>
>> Is there any benchmark for DataInput/Output stream that can be used? I mean, it would be interesting to understand how these numbers translate when running the stuff that is built on top.
> 
> I've tried to run the benchmark in test/micro/java/io/DataInputStream.java. This is the baseline:
> 
> 
> Benchmark                     Mode  Cnt  Score   Error  Units
> DataInputStreamTest.readChar  avgt   20  7.583 ? 0.026  us/op
> DataInputStreamTest.readInt   avgt   20  3.804 ? 0.045  us/op
> 
> 
> And this is with a patch similar to the one I shared above, to use ByteBuffer internally:
> 
> 
> Benchmark                     Mode  Cnt  Score   Error  Units
> DataInputStreamTest.readChar  avgt   20  7.594 ? 0.106  us/op
> DataInputStreamTest.readInt   avgt   20  3.795 ? 0.030  us/op
> 
> 
> There does not seem to be any extra overhead. That said, access occurs in a counted loop, and in these cases we know buffer/segment access is optimized quite well.
> 
> I believe the question here is: do we have benchmark which are representative of the kind of gain that would be introduced by micro-optimizing ByteArray? It can be quite tricky to estimate real benefits from synthetic benchmark on the ByteArray class, especially when fetching a single element outside of a loop - as those are not representative of how the clients will use this. I note that the original benchmark made by Per used a loop with two iterations to assess the cost of the ByteArray operations:
> 
> http://minborgsjavapot.blogspot.com/2023/01/java-21-performance-improvements.html
> 
> If I change the benchmark to do 2 iterations, I see this:
> 
> 
> Benchmark                      Mode  Cnt       Score       Error   Units
> ByteArray.readByte            thrpt    5  704199.172 ? 34101.508  ops/ms
> ByteArray.readByteFromBuffer  thrpt    5  474321.828 ?  6588.471  ops/ms
> ByteArray.readInt             thrpt    5  662411.181 ?  4470.951  ops/ms
> ByteArray.readIntFromBuffer   thrpt    5  496900.429 ?  3705.737  ops/ms
> ByteArray.readLong            thrpt    5  665138.063 ?  5944.814  ops/ms
> ByteArray.readLongFromBuffer  thrpt    5  517781.548 ? 27106.331  ops/ms
> 
> The more the iterations, the less the cost (and you don't need many iterations to break even). This probably explains why the DataInputStream benchmark doesn't change - there's 1024 iterations in there.
> 
> I guess all this is to say that excessively focussing on microbenchmark of a simple class such as ByteArray in conditions that are likely unrealistic (e.g. single access) is IMHO the wrong way to look at thing...

Just some feedback about this discussion:
- I agree that the DataInput/OutputStreams should maybe use `ByteBuffer` directly as they use buffering already. So the patch above looks fine. In my project Apache Lucene (which has many performance critical methods like this), we have already implemented ByteBuffer based access like this for all IO-stream-based classes (we call then `DataInput/DataOutput`). I don't know why you have seen differences in using a `ByteBuffer` as final field in the class. That's common and used in most frameworks out there (NETTY,...) and is bullet proof (unless theres a bug in optimizer which sometimes happened in the past).
- We noticed that wrapping a byte array on each access by ByteBuffer causes a lot of overhead and GC activity if used in hot loops. In addition we have seen cases where it is not optimized anymore (not sure why). @mcimadamore: You remember the similar discussions about the `MemorySegment` slices and copying them around between heap/foreign? Maybe inside the JDK you can do better by using `@ForceInline`. Our code can't do this, so we try to avoid creating instances of classes in such low-level code.
- The original VarHandle approach is now used in Lucene's code at all places (basically the idea to use VarHandles for this class was suggested by me a while back). We often have byte arrays and can't wrap them as ByteBuffer on each call (because its not always inlined). For code outside of the JDK this looks like the best approach to have fast access to short/int/long values at specific (not necessarily aligned) positions. We have seen LZ4 compression getting much faster after changing the code from manually constructing logs/floats from bytes like in the reference code. With ByteBuffer it was often getting slower (depending on how it was called, I think because we can't do `@ForceInline` in code outside the JDK.

Generally: A class like this is very nice and also very much needed in code outside the JDK. A lot of code like encoding/decoding network bytes or compression algorithms often has the pattern that they want to read primitive types from byte arrays from. The overhead with wrapping looks bad in code and also causes long startup times and sometimes also OOM (if used multithreaded from different threads hammering the byte array accessors). Also you don not want to write a LZ4 decompressor using ByteBuffer as its only source of data... :-(

So have you thought of making this low-level classes public so we outside users no longer need to deal with VarHandles?

Maybe `java.util.ByteArrays` with solely static methods. The internal implementation of such a useful basic utility class could definitly be using `Unsafe` internally, so I would leave out the discussion here. If you use Unsafe there are no surprises! Personally I have no problem with the current implementation in this PR! I would just put little/big endian impl in the same class and move it to java.util (this is just my comment about this, coming from a library which does this low level stuff all the time).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1270479763

From mdoerr at openjdk.org  Fri Jul 21 10:50:43 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 21 Jul 2023 10:50:43 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
Message-ID: <NW7xYbDlM0iKOUZwYfUeEw0wV2LjdsL0dw0Z4YvwBxQ=.7e6012ed-d63f-4456-b666-2fdf04922688@github.com>

On Sat, 8 Jul 2023 10:48:15 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address suggestions from Jorn Vernee

I've seen

java/foreign/StdLibTest.java
Total tests run: 41388, Passes: 39378, Failures: 2010, Skips: 0

(slowdebug build). Is this a known problem?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14801#issuecomment-1645384285

From dl at openjdk.org  Fri Jul 21 10:58:51 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 21 Jul 2023 10:58:51 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v8]
In-Reply-To: <9c_CbQGsIFn8wlww8eVC_yqBC9U1mvdCvd3apnOkpBI=.b8f1e25e-d096-4c64-9324-f80c991de445@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <QXX0pY3HHUHnMCJQ-c_JSBRJmpe8_3KcYLscidPPNK0=.f36819ab-1fb7-4a18-ad38-c2829b385b89@github.com>
 <9c_CbQGsIFn8wlww8eVC_yqBC9U1mvdCvd3apnOkpBI=.b8f1e25e-d096-4c64-9324-f80c991de445@github.com>
Message-ID: <ZHjM_QMToogOTDGT71jvt_N1pytXxeW91mdo_PY2LSI=.88c7af4c-c409-43a9-9ea4-6962a02e60e8@github.com>

On Fri, 21 Jul 2023 09:30:53 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   nitpicks
>
> src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 397:
> 
>> 395:          * True if system is a uniprocessor, occasionally rechecked.
>> 396:          */
>> 397:         private static boolean isUniprocessor =
> 
> @DougLea  If this is intentionally non-volatile, I think it is worth documenting the rationale.

Added: (L348)
     * than unnecessarily requiring volatile accesses elsewhere. This
     * fence also separates accesses to field isUniprocessor.

> src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 446:
> 
>> 444:                         Thread.onSpinWait();
>> 445:                     else
>> 446:                         LockSupport.parkNanos(ns);
> 
> @DougLea If `ns` is sufficiently large, would it not make sense to use managed blocking in case the current thread is a FJWT as below? ?

It's a good point, but we don't normally do this. Added (L336):
     * returns just barely too soon. As is the case in most j.u.c
     * blocking support, untimed waits use ManagedBlockers when
     * callers are ForkJoin threads, but timed waits use plain
     * parkNanos, under the rationale that known-to-be transient
     * blocking doesn't require compensation. (This decision should be
     * revisited here and elsewhere to deal with very long timeouts.)

> src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 612:
> 
>> 610:         else if (m != null)
>> 611:             s.selfLinkItem();
>> 612:         return m;
> 
> @DougLea I'd probably add a newline before the return statement to visually distinguish that it isn't intended to be read as a part of the if-else branches.

Thanks. Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270541557
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270543495
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270543842

From vpetko at openjdk.org  Fri Jul 21 11:02:52 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Fri, 21 Jul 2023 11:02:52 GMT
Subject: RFR: 8312488: tools/jpackage/share/AppLauncherEnvTest.java fails with
 dynamically linked libstdc++
Message-ID: <RMaWupHshwbpWmIsBXfRG9swzBbJ3nGeDiloyDJLiRk=.d1f80bff-3e44-4060-8958-3d4f0f1f63a3@github.com>

Use the  same approach as Logger::defaultLogger() to ensure that the appender is not destroyed before shared object destructor function is executed.

The alternative is to delete dcon() function, but we might run into a similiar tear-down issue later (e.g. logging from some object's destructor).


==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/tools                                215   215     0     0   
==============================
TEST SUCCESS

-------------

Commit messages:
 - Avoid destroying log appenders set in launch() function.

Changes: https://git.openjdk.org/jdk/pull/14971/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14971&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312488
  Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14971/head:pull/14971

PR: https://git.openjdk.org/jdk/pull/14971

From smarks at openjdk.org  Fri Jul 21 11:18:26 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 21 Jul 2023 11:18:26 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
Message-ID: <sk50_pWh11xf0Mf3aEIcjSLJm0nDmRPsEgM7iXk5s8I=.ff76dbb4-39e8-4454-998e-5bb4ff04f982@github.com>

On Tue, 28 Mar 2023 02:37:22 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify handling of cached keySet, values, and entrySet views.

Removing the `client` label because the `IdentityLinkedList` stuff that was previously affected has now been addressed in the mainline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1502140313

From dl at openjdk.org  Fri Jul 21 11:19:43 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 21 Jul 2023 11:19:43 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v8]
In-Reply-To: <ZHjM_QMToogOTDGT71jvt_N1pytXxeW91mdo_PY2LSI=.88c7af4c-c409-43a9-9ea4-6962a02e60e8@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <QXX0pY3HHUHnMCJQ-c_JSBRJmpe8_3KcYLscidPPNK0=.f36819ab-1fb7-4a18-ad38-c2829b385b89@github.com>
 <9c_CbQGsIFn8wlww8eVC_yqBC9U1mvdCvd3apnOkpBI=.b8f1e25e-d096-4c64-9324-f80c991de445@github.com>
 <ZHjM_QMToogOTDGT71jvt_N1pytXxeW91mdo_PY2LSI=.88c7af4c-c409-43a9-9ea4-6962a02e60e8@github.com>
Message-ID: <clwKaTzhM-sBotiULrDPykE6FuBb5U7zL-jA8gM8Bo4=.173d7fdb-98bb-4561-8e09-11fae3655447@github.com>

On Fri, 21 Jul 2023 10:55:19 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 446:
>> 
>>> 444:                         Thread.onSpinWait();
>>> 445:                     else
>>> 446:                         LockSupport.parkNanos(ns);
>> 
>> @DougLea If `ns` is sufficiently large, would it not make sense to use managed blocking in case the current thread is a FJWT as below? ?
>
> It's a good point, but we don't normally do this. Added (L336):
>      * returns just barely too soon. As is the case in most j.u.c
>      * blocking support, untimed waits use ManagedBlockers when
>      * callers are ForkJoin threads, but timed waits use plain
>      * parkNanos, under the rationale that known-to-be transient
>      * blocking doesn't require compensation. (This decision should be
>      * revisited here and elsewhere to deal with very long timeouts.)

I should have mentioned that the tradeoffs include that using ManagedBlocking for timed waits here adds overhead: -- constructing of another object just to track the time, and duplicate checks of other parts of await(. Which requires choosing a threshold where it would be worthwhile. Which is  a hard-to-win decision.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270561315

From duke at openjdk.org  Fri Jul 21 11:20:31 2023
From: duke at openjdk.org (Hollis Waite)
Date: Fri, 21 Jul 2023 11:20:31 GMT
Subject: RFR: 8266571: Sequenced Collections [v12]
In-Reply-To: <BkwnYQwsK_lnfHEmAIVU4X0fkubfXd4IDL8OxJHClEQ=.6af19d63-c8a1-492c-960d-cb5735eaedcf@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <BkwnYQwsK_lnfHEmAIVU4X0fkubfXd4IDL8OxJHClEQ=.6af19d63-c8a1-492c-960d-cb5735eaedcf@github.com>
Message-ID: <njyriDXwBK4AI-dex1CA3IWdSbjAwCMzEkUKWIvih-k=.af83514b-405a-4350-a93a-f89ebcd6846c@github.com>

On Mon, 24 Apr 2023 21:39:43 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
> 
>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>  - Optimizations for ReverseOrderListView; check indexes in reversed domain.
>  - Wording tweaks to SequencedMap / NavigableMap.
>  - Change "The implementation in this class" to "... interface."
>  - Delegate more methods in the views of ReverseOrderSortedMapView.
>  - Add missing @throws and @since tags.
>  - Convert code samples to snippets.
>  - Various editorial changes.
>  - Fix up toArray(T[]) on reverse-ordered views.
>  - Remove unnecessary 'final' from a couple places.
>  - ... and 86 more: https://git.openjdk.org/jdk/compare/2ea62c13...2827aa69

It'd be convenient if SequencedCollection overrode Iterable.iterator() to return a ListIterator. That would make it simpler to derive a List from LinkedHashMap.values().

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1645423663

From duke at openjdk.org  Fri Jul 21 11:46:47 2023
From: duke at openjdk.org (sid8606)
Date: Fri, 21 Jul 2023 11:46:47 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <NW7xYbDlM0iKOUZwYfUeEw0wV2LjdsL0dw0Z4YvwBxQ=.7e6012ed-d63f-4456-b666-2fdf04922688@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
 <NW7xYbDlM0iKOUZwYfUeEw0wV2LjdsL0dw0Z4YvwBxQ=.7e6012ed-d63f-4456-b666-2fdf04922688@github.com>
Message-ID: <strb0yawBbtzepp2vc6xIivMgQcu5bI7um6fyN6Jwz8=.d6061d40-56a8-4b2e-b2f4-a914dc04f516@github.com>

On Fri, 21 Jul 2023 10:46:14 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address suggestions from Jorn Vernee
>
> I've seen
> 
> java/foreign/StdLibTest.java
> Total tests run: 41388, Passes: 39378, Failures: 2010, Skips: 0
> 
> (slowdebug build). Is this a known problem?

@TheRealMDoerr Thank you looking into this PR. I have tested again java/foreign/StdLibTest.java on my end. I see that it passes with slowdebug build (rebased with master).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14801#issuecomment-1645452677

From mdoerr at openjdk.org  Fri Jul 21 12:20:47 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 21 Jul 2023 12:20:47 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
Message-ID: <5ifOngKE41_DMQw35KiJQzf8L1MP_smglYyyNCipf_k=.5c7aad97-0615-4ef4-a61a-98d3ecb282b3@github.com>

On Sat, 8 Jul 2023 10:48:15 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address suggestions from Jorn Vernee

I can see it failing with `make run-test TEST="jdk/java/foreign"` on g9-z15 (patch applied to jdk head).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14801#issuecomment-1645492542

From dl at openjdk.org  Fri Jul 21 12:31:07 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 21 Jul 2023 12:31:07 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v9]
In-Reply-To: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
Message-ID: <jBBBtaRewKHlQ9jGa7ZtDZaj3lvZk1HdfjW4fRagPT0=.33acee50-6314-4ee1-9763-b55596813684@github.com>

> This update addresses performance issues across both LinkedTransferQueue and SynchronousQueue by creating a common basis for implementation across them (mainly in LinkedTransferQueue).  Pasting from internal doc summary of changes:
>      * * Class DualNode replaces Qnode, with fields and methods
>      *   that apply to any match-based dual data structure, and now
>      *   usable in other j.u.c classes. in particular, SynchronousQueue.
>      * * Blocking control (in class DualNode) accommodates
>      *   VirtualThreads and (perhaps virtualized) uniprocessors.
>      * * All fields of this class (LinkedTransferQueue) are
>      *   default-initializable (to null), allowing further extension
>      *   (in particular, SynchronousQueue.Transferer)
>      * * Head and tail fields are lazily initialized rather than set
>      *   to a dummy node, while also reducing retries under heavy
>      *   contention and misorderings, and relaxing some accesses,
>      *   requiring accommodation in many places (as well as
>      *   adjustments in WhiteBox tests).

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14317/files
  - new: https://git.openjdk.org/jdk/pull/14317/files/b5e7e8b8..7c64a933

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=07-08

  Stats: 13 lines in 1 file changed: 7 ins; 0 del; 6 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 jpai at openjdk.org  Fri Jul 21 13:01:49 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Jul 2023 13:01:49 GMT
Subject: Integrated: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6
In-Reply-To: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
Message-ID: <dB9wTBAqUFtMBk9-XtKa1-4UybsLh-KpW6CJuxhyDeY=.dadc980d-c9c6-4d2a-ac43-0d340733fbf9@github.com>

On Tue, 18 Jul 2023 06:59:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229.
> 
> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.

This pull request has now been integrated.

Changeset: 842d6329
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/842d6329cf5a3da8df7eddb195b5fcb7baadbdc3
Stats:     41 lines in 25 files changed: 0 ins; 9 del; 32 mod

8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6

Reviewed-by: alanb, cjplummer, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/14918

From duke at openjdk.org  Fri Jul 21 13:39:43 2023
From: duke at openjdk.org (sid8606)
Date: Fri, 21 Jul 2023 13:39:43 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
Message-ID: <jdo13wMmnZHf777O4ci1s-faeGyiHmqjprdNN9GDcdI=.eb6eee84-29a6-40a6-a579-05d2273ab09f@github.com>

On Sat, 8 Jul 2023 10:48:15 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address suggestions from Jorn Vernee

I am using below configure to build jdk 

        --with-boot-jdk=~/jdk-20+36 \
	--with-jtreg=../../jtreg/build/images/jtreg/ \
	--with-gtest=../../googletest \
	--with-debug-level=slowdebug \
	--with-native-debug-symbols=internal \

With this build I see somehow all test cases are passing.
In case any extra flags to set to jdk build let me know.
`make run-test TEST="jdk/java/foreign" `on g9-z15, glibc 2.35 (patch applied to jdk head)


   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/java/foreign                          88    88     0     0

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14801#issuecomment-1645601051

From duke at openjdk.org  Fri Jul 21 14:02:46 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 21 Jul 2023 14:02:46 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v9]
In-Reply-To: <jBBBtaRewKHlQ9jGa7ZtDZaj3lvZk1HdfjW4fRagPT0=.33acee50-6314-4ee1-9763-b55596813684@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <jBBBtaRewKHlQ9jGa7ZtDZaj3lvZk1HdfjW4fRagPT0=.33acee50-6314-4ee1-9763-b55596813684@github.com>
Message-ID: <Yr_CqO3bNS3wz0zWsWnaRqkAsqllX_VSG0x-la3vr_s=.9b72ada3-6c39-484c-91e0-d5562249ff98@github.com>

On Fri, 21 Jul 2023 12:31:07 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This update addresses performance issues across both LinkedTransferQueue and SynchronousQueue by creating a common basis for implementation across them (mainly in LinkedTransferQueue).  Pasting from internal doc summary of changes:
>>      * * Class DualNode replaces Qnode, with fields and methods
>>      *   that apply to any match-based dual data structure, and now
>>      *   usable in other j.u.c classes. in particular, SynchronousQueue.
>>      * * Blocking control (in class DualNode) accommodates
>>      *   VirtualThreads and (perhaps virtualized) uniprocessors.
>>      * * All fields of this class (LinkedTransferQueue) are
>>      *   default-initializable (to null), allowing further extension
>>      *   (in particular, SynchronousQueue.Transferer)
>>      * * Head and tail fields are lazily initialized rather than set
>>      *   to a dummy node, while also reducing retries under heavy
>>      *   contention and misorderings, and relaxing some accesses,
>>      *   requiring accommodation in many places (as well as
>>      *   adjustments in WhiteBox tests).
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 639:

> 637:             else {
> 638:                 if (p != h && cmpExHead(h, p) == h)
> 639:                     h.next = h; // h.selfLink();

@DougLea Too expensive with the call? ?

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 667:

> 665:         else if (cmpExHead(c, p) != c)
> 666:             return false;
> 667:         if (c != null)

@DougLea If this `if` is not related to the above if-tree, I'd put a newline between them. (Also makes sense to add a newline before the last `return` as well (to indicate that it is standalone from the if)

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 726:

> 724:             else if (p == h)                  // traverse past header
> 725:                 p = q;
> 726:             else if ((u = cmpExHead(h, q)) != h)

@DougLea Always nice to see `compareAndExchange` being used :)

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 896:

> 894:             for (DualNode p = (pred == null) ? head : pred.next, c = p;
> 895:                  p != null; ) {
> 896:                 boolean isData = p.isData;

@DougLea Are you finding that manual hoisting of reads to final members has a perf edge? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270704711
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270707826
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270709052
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270711614

From forax at openjdk.org  Fri Jul 21 14:10:25 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 21 Jul 2023 14:10:25 GMT
Subject: RFR: 8266571: Sequenced Collections [v12]
In-Reply-To: <njyriDXwBK4AI-dex1CA3IWdSbjAwCMzEkUKWIvih-k=.af83514b-405a-4350-a93a-f89ebcd6846c@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <BkwnYQwsK_lnfHEmAIVU4X0fkubfXd4IDL8OxJHClEQ=.6af19d63-c8a1-492c-960d-cb5735eaedcf@github.com>
 <njyriDXwBK4AI-dex1CA3IWdSbjAwCMzEkUKWIvih-k=.af83514b-405a-4350-a93a-f89ebcd6846c@github.com>
Message-ID: <_1TTgDWt8NnQB0aHDpaCHsQLc0g99tfbDS35doI39V0=.3204afe8-362c-47ad-9fff-33c4d5b53866@github.com>

On Fri, 21 Jul 2023 11:16:11 GMT, Hollis Waite <duke at openjdk.org> wrote:

>> Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
>> 
>>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>>  - Optimizations for ReverseOrderListView; check indexes in reversed domain.
>>  - Wording tweaks to SequencedMap / NavigableMap.
>>  - Change "The implementation in this class" to "... interface."
>>  - Delegate more methods in the views of ReverseOrderSortedMapView.
>>  - Add missing @throws and @since tags.
>>  - Convert code samples to snippets.
>>  - Various editorial changes.
>>  - Fix up toArray(T[]) on reverse-ordered views.
>>  - Remove unnecessary 'final' from a couple places.
>>  - ... and 86 more: https://git.openjdk.org/jdk/compare/2ea62c13...2827aa69
>
> It'd be convenient if SequencedCollection overrode Iterable.iterator() to return a ListIterator. That would make it simpler to derive a List from LinkedHashMap.values().

@hwaite, the problem is that the derived List will not be a random access List, so it will perform badly with any code that loop over List.get() (yes, you are not supposed to do that but sadly a lot of people do).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1645649005

From prappo at openjdk.org  Fri Jul 21 14:14:31 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 21 Jul 2023 14:14:31 GMT
Subject: RFR: 8266571: Sequenced Collections [v12]
In-Reply-To: <njyriDXwBK4AI-dex1CA3IWdSbjAwCMzEkUKWIvih-k=.af83514b-405a-4350-a93a-f89ebcd6846c@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <BkwnYQwsK_lnfHEmAIVU4X0fkubfXd4IDL8OxJHClEQ=.6af19d63-c8a1-492c-960d-cb5735eaedcf@github.com>
 <njyriDXwBK4AI-dex1CA3IWdSbjAwCMzEkUKWIvih-k=.af83514b-405a-4350-a93a-f89ebcd6846c@github.com>
Message-ID: <VpwqF4i7LsPYwdi3PTGfuPLT0YLyloftFHNrKpQfoqw=.4ef024f3-f69d-4336-a3b5-37467a573739@github.com>

On Fri, 21 Jul 2023 11:16:11 GMT, Hollis Waite <duke at openjdk.org> wrote:

> It'd be convenient if SequencedCollection overrode Iterable.iterator() to return a ListIterator. That would make it simpler to derive a List from LinkedHashMap.values().

What stops you from deriving a list from LinkedHashMap.values() as follows?

    new ArrayList<>(map.values());

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1645654540

From duke at openjdk.org  Fri Jul 21 14:20:47 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 21 Jul 2023 14:20:47 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v9]
In-Reply-To: <clwKaTzhM-sBotiULrDPykE6FuBb5U7zL-jA8gM8Bo4=.173d7fdb-98bb-4561-8e09-11fae3655447@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <QXX0pY3HHUHnMCJQ-c_JSBRJmpe8_3KcYLscidPPNK0=.f36819ab-1fb7-4a18-ad38-c2829b385b89@github.com>
 <9c_CbQGsIFn8wlww8eVC_yqBC9U1mvdCvd3apnOkpBI=.b8f1e25e-d096-4c64-9324-f80c991de445@github.com>
 <ZHjM_QMToogOTDGT71jvt_N1pytXxeW91mdo_PY2LSI=.88c7af4c-c409-43a9-9ea4-6962a02e60e8@github.com>
 <clwKaTzhM-sBotiULrDPykE6FuBb5U7zL-jA8gM8Bo4=.173d7fdb-98bb-4561-8e09-11fae3655447@github.com>
Message-ID: <_XQQbCxs5TZw2Htf28fPcBGzKea66G4HEjyKGUP6Kgw=.24825339-cc26-472d-b25e-68f8e1b4d56e@github.com>

On Fri, 21 Jul 2023 11:16:55 GMT, Doug Lea <dl at openjdk.org> wrote:

>> It's a good point, but we don't normally do this. Added (L336):
>>      * returns just barely too soon. As is the case in most j.u.c
>>      * blocking support, untimed waits use ManagedBlockers when
>>      * callers are ForkJoin threads, but timed waits use plain
>>      * parkNanos, under the rationale that known-to-be transient
>>      * blocking doesn't require compensation. (This decision should be
>>      * revisited here and elsewhere to deal with very long timeouts.)
>
> I should have mentioned that the tradeoffs include that using ManagedBlocking for timed waits here adds overhead: -- constructing of another object just to track the time, and duplicate checks of other parts of await(. Which requires choosing a threshold where it would be worthwhile. Which is  a hard-to-win decision.

@DougLea I suspect that a good "governing principle" here is: is the timed park expected to be prematurely unparked, and is the delay sufficiently large to warrant compensation?use ManagedBlocker. Ideally (perhaps) the call to ManagedBlocker takes an "expected conservative estimate of blocking"-nanos, and then that behavior could be completely enclosed within the ManagedBlocker-construct itself (and thus be uniformly applied). It could also use heuristics about expected lifetime of compensating threads to see if it is justified to add one... Just thoughts off of the top of my head. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270730372

From duke at openjdk.org  Fri Jul 21 14:20:50 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 21 Jul 2023 14:20:50 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v9]
In-Reply-To: <jBBBtaRewKHlQ9jGa7ZtDZaj3lvZk1HdfjW4fRagPT0=.33acee50-6314-4ee1-9763-b55596813684@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <jBBBtaRewKHlQ9jGa7ZtDZaj3lvZk1HdfjW4fRagPT0=.33acee50-6314-4ee1-9763-b55596813684@github.com>
Message-ID: <PBvEk-5KBUwcSXWeH45zQ3DDjg9tA89DneCKO2UEfmg=.2b413bbc-9abf-4d8f-921d-fe3f2b97507d@github.com>

On Fri, 21 Jul 2023 12:31:07 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This update addresses performance issues across both LinkedTransferQueue and SynchronousQueue by creating a common basis for implementation across them (mainly in LinkedTransferQueue).  Pasting from internal doc summary of changes:
>>      * * Class DualNode replaces Qnode, with fields and methods
>>      *   that apply to any match-based dual data structure, and now
>>      *   usable in other j.u.c classes. in particular, SynchronousQueue.
>>      * * Blocking control (in class DualNode) accommodates
>>      *   VirtualThreads and (perhaps virtualized) uniprocessors.
>>      * * All fields of this class (LinkedTransferQueue) are
>>      *   default-initializable (to null), allowing further extension
>>      *   (in particular, SynchronousQueue.Transferer)
>>      * * Head and tail fields are lazily initialized rather than set
>>      *   to a dummy node, while also reducing retries under heavy
>>      *   contention and misorderings, and relaxing some accesses,
>>      *   requiring accommodation in many places (as well as
>>      *   adjustments in WhiteBox tests).
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 1584:

> 1582:                 if (isData) {
> 1583:                     action.accept((E) item);
> 1584:                     pred = p; p = q; continue;

@DougLea These three statements deserve their own lines, I'd say. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270715057

From prappo at openjdk.org  Fri Jul 21 14:21:42 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 21 Jul 2023 14:21:42 GMT
Subject: RFR: 8266571: Sequenced Collections [v12]
In-Reply-To: <njyriDXwBK4AI-dex1CA3IWdSbjAwCMzEkUKWIvih-k=.af83514b-405a-4350-a93a-f89ebcd6846c@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <BkwnYQwsK_lnfHEmAIVU4X0fkubfXd4IDL8OxJHClEQ=.6af19d63-c8a1-492c-960d-cb5735eaedcf@github.com>
 <njyriDXwBK4AI-dex1CA3IWdSbjAwCMzEkUKWIvih-k=.af83514b-405a-4350-a93a-f89ebcd6846c@github.com>
Message-ID: <0C1CfbLLS1BGeNIkuDXLTgKnXO8Blh0t7aUh2DXyl04=.ee2c8681-e542-43da-9ddc-5ea546cdf508@github.com>

On Fri, 21 Jul 2023 11:16:11 GMT, Hollis Waite <duke at openjdk.org> wrote:

>> Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
>> 
>>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>>  - Optimizations for ReverseOrderListView; check indexes in reversed domain.
>>  - Wording tweaks to SequencedMap / NavigableMap.
>>  - Change "The implementation in this class" to "... interface."
>>  - Delegate more methods in the views of ReverseOrderSortedMapView.
>>  - Add missing @throws and @since tags.
>>  - Convert code samples to snippets.
>>  - Various editorial changes.
>>  - Fix up toArray(T[]) on reverse-ordered views.
>>  - Remove unnecessary 'final' from a couple places.
>>  - ... and 86 more: https://git.openjdk.org/jdk/compare/2ea62c13...2827aa69
>
> It'd be convenient if SequencedCollection overrode Iterable.iterator() to return a ListIterator. That would make it simpler to derive a List from LinkedHashMap.values().

> @hwaite, the problem is that the derived List will not be a random access List, so it will perform badly with any code that loop over List.get() (yes, you are not supposed to do that but sadly a lot of people do).

Pardon? What about semantics mismatch and compatibility issues? If SequencedCollection were to redefine `iterator` as follows, it would break all the existing implementations of List out there:

    @Override
    ListIterator<E> iterator();

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1645667941

From asemenyuk at openjdk.org  Fri Jul 21 15:05:41 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 21 Jul 2023 15:05:41 GMT
Subject: RFR: 8312488: tools/jpackage/share/AppLauncherEnvTest.java fails
 with dynamically linked libstdc++
In-Reply-To: <RMaWupHshwbpWmIsBXfRG9swzBbJ3nGeDiloyDJLiRk=.d1f80bff-3e44-4060-8958-3d4f0f1f63a3@github.com>
References: <RMaWupHshwbpWmIsBXfRG9swzBbJ3nGeDiloyDJLiRk=.d1f80bff-3e44-4060-8958-3d4f0f1f63a3@github.com>
Message-ID: <iD3tClkhWcXU4fOqQfswgaLdjHkdNpnmJmJHdqGZ4z0=.e3055a55-6e15-412e-a296-277c64d6309c@github.com>

On Fri, 21 Jul 2023 10:55:13 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> Use the  same approach as Logger::defaultLogger() to ensure that the appender is not destroyed before shared object destructor function is executed.
> 
> The alternative is to delete dcon() function, but we might run into a similiar tear-down issue later (e.g. logging from some object's destructor).
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/tools                                215   215     0     0   
> ==============================
> TEST SUCCESS

Great catch!

-------------

Marked as reviewed by asemenyuk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14971#pullrequestreview-1541331538

From jvernee at openjdk.org  Fri Jul 21 15:08:46 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 21 Jul 2023 15:08:46 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
Message-ID: <DVJikHwHfrFQIFfLuMYaUdjHTvqvVIVocsZ7yBEjXKE=.29f86042-47c0-408e-87f7-c92fe991ac8a@github.com>

On Sat, 8 Jul 2023 10:48:15 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address suggestions from Jorn Vernee

StdLibTest tests several standard library functions. I suggest comment out some of the test methods to narrow down which function is problematic. I suspect it's `printf`. If that's the case, make sure you have the fix for: https://bugs.openjdk.org/browse/JDK-8308031 as well

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14801#issuecomment-1645734481

From mcimadamore at openjdk.org  Fri Jul 21 15:16:46 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Jul 2023 15:16:46 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <8ehoqZ03U2jtaV19chg-02fJjQ1i4umzzrIZUqL8MF8=.bd1d24ea-38ae-49a1-a26d-cffed575e72b@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
 <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
 <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>
 <rTB4ZN2L094-B1iuBjktkhvQn1OXxnw8M83gGxXIhh4=.fb1c085c-b714-4ec1-9dda-2d099e838430@github.com>
 <5vWADWw1xEPg0Rmq6cgvKRj9CN5cSTBRYOPkDBlkBxk=.b20fed4c-12fe-4dbc-b51e-2d672d74c070@github.com>
 <y2JG_qO6Y_jJyjXraNEOAbl2_SJuUh1elJSm0GFxAH0=.77e0757b-eec9-49ad-ad52-c37d3e3e67a6@github.com>
 <Q2tgKNyIUTLAdt3MdARsHFmz5PLhYcdxyNzaFZyCsK0=.de22d165-0ed0-43b8-8ece-5779fa5bcc78@github.com>
 <Lzi9EKlcwY36SBqlVCN6bYSGatbUBVQiQIYv5Nbzmj0=.c7928875-f0b4-4fd6-816e-8e0357b8a92c@github.com>
 <wCL4vOROLQFoktk5IESaD4CpTnBAxiEq9qq7mDO41S0=.690ff507-32ee-402f-b727-5f6ea5f669b4@
 github.com>
 <qHehDUvqpRaBr51w9ZlfWYmT-RmiJ_UVi3AoUEOztmU=.b220ce4f-9807-48af-874b-cb0e03361c5f@github.com>
 <2Z46WAHv8N0fSBJFgg0-iBXHBM13-9jYYw5mV7i4yMo=.e30c1ff1-fdfb-4883-b612-f1f0d637dc73@github.com>
 <l_4-vwLQ3kHO-jA7-ajsZNCXPNUNRIK574Xa8efvD6s=.da0ae935-7978-4c30-90e6-c784f6c60b1e@github.com>
 <qsl35SFoAlrzBj_CJlxtYOEUHqP-zIR7GZtAO9nVmrI=.a87d32f8-8ba0-4ccd-aba8-42199c4fd8c2@github.com>
 <sbB0IUGrHgz0Gj9rPYB_rYcJlTc1dUMhvbYDvi_1N7o=.0cc2938b-aaf5-4dd6-96ba-c0bb0d0d6581@github.com>
 <JZAJRO1jljQ5G_qVDIEVUCeNsn1EBuZjaRmbTqTAHxc=.9d850bed-02cb-4abf-af26-f39ccced98de@github.com>
 <8ehoqZ03U2jtaV19chg-02fJjQ1i4umzzrIZUqL8MF8=.bd1d24ea-38ae-49a1-a26d-cffed575e72b@github.com>
Message-ID: <5G6Mzx_lhv2RE5BrFCmZU8DH0JjRGoPS3XkWfpLV5Gs=.03064bde-fbe8-4e4f-ba38-b0c6e4309214@github.com>

On Fri, 21 Jul 2023 09:43:43 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

> 
> So have you thought of making this low-level classes public so we outside users no longer need to deal with VarHandles?
> 
I believe this is beyond the scope of this PR.

As for what do we do in the JDK, I can see few options:

1. We keep things as they are in current mainline.
2. We keep changes in this PR.
3. We rewrite most uses of ByteArray in java.io to use BB and remove ByteArray
4. We remove ByteArray and provide some static helper function to generate an unsafe offset from an array

I agree with @uschindler that wrapping stuff in ByteBuffer "on the fly" might be problematic for code that is not inlined, so I don't think we should do that.

I have to admit that I'm a little unclear as to what the goal of this PR is. Initially, it started as an "improve startup" effort, which then morphed into a "let's make ByteArray" more usable, even for other clients (like classfile API), or Long::toString. I'm unsure about the latter use cases, because (a) Long/Integer are core classes and should probably use Unsafe directly, where needed and (b) for classfile API, using ByteBuffer seems a good candidate on paper (of course there is the unknown of how well the byte buffer access will optimize in the classfile API code - but if there's more than one access on the same buffer, we should be more than ok).

I'd like to add some more words of caution against the synthetic benchmarks that we tried above. These benchmarks are quite peculiar, for at least two reasons:

* we only ever access one element
* the accessed offset is always zero

No general API can equal Unsafe under this set of conditions. When playing with the benchmark I realize that every little thing mattered (we're really measuring the number of instructions emitted by C2)  - for instance, the fact that when access occurs with a byte buffer, the underlying array and limit have to be fetched from their fields has a cost. Also, the fact that ByteBuffer has a hierarchy has an even bigger cost (as C2 has to make sure you are really invoking HeapByteBuffer). The mutable endianness state in byte buffer also adds up to the noise. The above is what ends up in a big fat "2x slower" label.

That said, all these "factors" are only relevant because we're looking at a _single_ buffer operation. In fact, all such costs can be easily be amortized as soon as there more than one access. Or as soon as you start accessing offsets that are not known statically (unlike in the benchmark).

So, there's a question of what's the code idiom that leads to the absolute fastest code (and I agree that Unsafe + static wrappers seems the best here). And then there's the question of "but, what do we need to get the performance number/startup behavior we want". I feel the important question is the second, but we keep arguing about the former.

And, to assess that second question, we need to understand better what the goals are (which, so far, seems a bit fuzzy).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1270795253

From rriggs at openjdk.org  Fri Jul 21 15:46:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 21 Jul 2023 15:46:47 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v7]
In-Reply-To: <m8Ra--daQNdWItn6Cr-KdNYq7Nq53Ie2CwrKbu9Ef6w=.730a6c46-250e-43ed-bf32-34ef33ad2b31@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <1dEun4T-zq47Un7WaIYRz2vbGECpwcGw2bhCDc-Ggrg=.6ce9b8b7-7895-4c5a-a00e-e7b9a6dfc000@github.com>
 <m8Ra--daQNdWItn6Cr-KdNYq7Nq53Ie2CwrKbu9Ef6w=.730a6c46-250e-43ed-bf32-34ef33ad2b31@github.com>
Message-ID: <uc3y7qP_zUhC20LK7_f33WwL5xnsnsME5TX_ZtZltHE=.b5858b7b-be3e-4ae1-a2b0-419740e9533c@github.com>

On Thu, 20 Jul 2023 19:29:33 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 12 additional commits since the last revision:
>> 
>>  - Improve wording and remove markup for clarity
>>  - Merge branch 'master' into 8310033-time-compareto
>>  - Correct the descriptions to correctly identify the compareTo return
>>    value < 0 as this is before that, and > 0 as this is after that.
>>    Thanks to a careful reviewer spotting my reversing of the conditions.
>>  - Improve the grammar of "the comparator value is" -> "the comparator value, that is"
>>    Thanks for the reminder.
>>  - Merge branch 'master' into 8310033-time-compareto
>>  - Improve descriptions to be more specific and remove inappropriate use of before/after
>>    Remove extra blank lines
>>  - Clarify return values of date time classes
>>  - 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
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/4ab3be9f...1d39e2d4
>
> 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, that is the comparison with the {@code other}'s instant, if they are not equal;
> 
> This text is incorrect. It does not match the description above re offsets. (This would be a suitable description for `compareInstant`)

Line 1806 describes the comparison of the local time if the instants are equal.
```and if equal to the {@code other}'s instant, the comparison of the {@code other}'s local date-time```

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1270826575

From rriggs at openjdk.org  Fri Jul 21 15:57:00 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 21 Jul 2023 15:57:00 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v8]
In-Reply-To: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
Message-ID: <8OjhZa03MLD1AVHNtckPBxcgfVzvU6FB3EVmQCnnAa4=.1c513f53-f313-44a3-b971-7911b22e98bc@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:

  Corrected descriptions with respect to chronology and the concrete temporary type.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14479/files
  - new: https://git.openjdk.org/jdk/pull/14479/files/1d39e2d4..1f7ba75d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14479&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14479&range=06-07

  Stats: 10 lines in 4 files changed: 3 ins; 0 del; 7 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 Jul 21 15:59:42 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 21 Jul 2023 15:59:42 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v9]
In-Reply-To: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
Message-ID: <geqHOjkYp5gHbAux41pM7yBEAYmi0p80LBEkNqbC_5g=.40bba6b3-0dfa-4651-9ebd-ebc6f4f0d444@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 14 additional commits since the last revision:

 - Merge branch 'master' into 8310033-time-compareto
 - Corrected descriptions with respect to chronology and the concrete temporary type.
 - Improve wording and remove markup for clarity
 - Merge branch 'master' into 8310033-time-compareto
 - Correct the descriptions to correctly identify the compareTo return
   value < 0 as this is before that, and > 0 as this is after that.
   Thanks to a careful reviewer spotting my reversing of the conditions.
 - Improve the grammar of "the comparator value is" -> "the comparator value, that is"
   Thanks for the reminder.
 - Merge branch 'master' into 8310033-time-compareto
 - Improve descriptions to be more specific and remove inappropriate use of before/after
   Remove extra blank lines
 - Clarify return values of date time classes
 - Use {@code xxx} to highlight the comparison against the arg.
   Update copyrights.
 - ... and 4 more: https://git.openjdk.org/jdk/compare/80098b04...5ecd7aeb

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14479/files
  - new: https://git.openjdk.org/jdk/pull/14479/files/1f7ba75d..5ecd7aeb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14479&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14479&range=07-08

  Stats: 32041 lines in 966 files changed: 20571 ins; 9058 del; 2412 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 scolebourne at openjdk.org  Fri Jul 21 16:11:46 2023
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Fri, 21 Jul 2023 16:11:46 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v9]
In-Reply-To: <geqHOjkYp5gHbAux41pM7yBEAYmi0p80LBEkNqbC_5g=.40bba6b3-0dfa-4651-9ebd-ebc6f4f0d444@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <geqHOjkYp5gHbAux41pM7yBEAYmi0p80LBEkNqbC_5g=.40bba6b3-0dfa-4651-9ebd-ebc6f4f0d444@github.com>
Message-ID: <lZH9SGFY7cHS6pSiguzQwKIkQlInOXwI7ihd8M5KgAg=.e466f420-58c1-46ce-a123-b68206dd66cd@github.com>

On Fri, 21 Jul 2023 15:59:42 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 14 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8310033-time-compareto
>  - Corrected descriptions with respect to chronology and the concrete temporary type.
>  - Improve wording and remove markup for clarity
>  - Merge branch 'master' into 8310033-time-compareto
>  - Correct the descriptions to correctly identify the compareTo return
>    value < 0 as this is before that, and > 0 as this is after that.
>    Thanks to a careful reviewer spotting my reversing of the conditions.
>  - Improve the grammar of "the comparator value is" -> "the comparator value, that is"
>    Thanks for the reminder.
>  - Merge branch 'master' into 8310033-time-compareto
>  - Improve descriptions to be more specific and remove inappropriate use of before/after
>    Remove extra blank lines
>  - Clarify return values of date time classes
>  - Use {@code xxx} to highlight the comparison against the arg.
>    Update copyrights.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/f4b0e559...5ecd7aeb

LGTM

-------------

Marked as reviewed by scolebourne (Author).

PR Review: https://git.openjdk.org/jdk/pull/14479#pullrequestreview-1541440889

From rriggs at openjdk.org  Fri Jul 21 16:15:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 21 Jul 2023 16:15:48 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v9]
In-Reply-To: <geqHOjkYp5gHbAux41pM7yBEAYmi0p80LBEkNqbC_5g=.40bba6b3-0dfa-4651-9ebd-ebc6f4f0d444@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <geqHOjkYp5gHbAux41pM7yBEAYmi0p80LBEkNqbC_5g=.40bba6b3-0dfa-4651-9ebd-ebc6f4f0d444@github.com>
Message-ID: <uLPkenzTsNZqe2rllM3bXy719uyVsmQ5LI1p8kziM-Q=.19772e7c-a5f9-45b2-a37f-5ee8bc4633c9@github.com>

On Fri, 21 Jul 2023 15:59:42 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 14 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8310033-time-compareto
>  - Corrected descriptions with respect to chronology and the concrete temporary type.
>  - Improve wording and remove markup for clarity
>  - Merge branch 'master' into 8310033-time-compareto
>  - Correct the descriptions to correctly identify the compareTo return
>    value < 0 as this is before that, and > 0 as this is after that.
>    Thanks to a careful reviewer spotting my reversing of the conditions.
>  - Improve the grammar of "the comparator value is" -> "the comparator value, that is"
>    Thanks for the reminder.
>  - Merge branch 'master' into 8310033-time-compareto
>  - Improve descriptions to be more specific and remove inappropriate use of before/after
>    Remove extra blank lines
>  - Clarify return values of date time classes
>  - Use {@code xxx} to highlight the comparison against the arg.
>    Update copyrights.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/f358af09...5ecd7aeb

Thank you for your careful review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14479#issuecomment-1645856361

From dl at openjdk.org  Fri Jul 21 16:16:46 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 21 Jul 2023 16:16:46 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v9]
In-Reply-To: <Yr_CqO3bNS3wz0zWsWnaRqkAsqllX_VSG0x-la3vr_s=.9b72ada3-6c39-484c-91e0-d5562249ff98@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <jBBBtaRewKHlQ9jGa7ZtDZaj3lvZk1HdfjW4fRagPT0=.33acee50-6314-4ee1-9763-b55596813684@github.com>
 <Yr_CqO3bNS3wz0zWsWnaRqkAsqllX_VSG0x-la3vr_s=.9b72ada3-6c39-484c-91e0-d5562249ff98@github.com>
Message-ID: <cxO49UvDkxiMo-pnwQE21aHMw_srbSOhh4RGvlkYFjI=.14d5a15c-830e-4c96-8c4a-212f78068245@github.com>

On Fri, 21 Jul 2023 13:53:57 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 639:
> 
>> 637:             else {
>> 638:                 if (p != h && cmpExHead(h, p) == h)
>> 639:                     h.next = h; // h.selfLink();
> 
> @DougLea Too expensive with the call? ?

Not really; just a undeleted remnant of a previous factoring. Fixed.

> src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 667:
> 
>> 665:         else if (cmpExHead(c, p) != c)
>> 666:             return false;
>> 667:         if (c != null)
> 
> @DougLea If this `if` is not related to the above if-tree, I'd put a newline between them. (Also makes sense to add a newline before the last `return` as well (to indicate that it is standalone from the if)

Thanks. Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270855580
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270855756

From duke at openjdk.org  Fri Jul 21 16:22:29 2023
From: duke at openjdk.org (Hollis Waite)
Date: Fri, 21 Jul 2023 16:22:29 GMT
Subject: RFR: 8266571: Sequenced Collections [v12]
In-Reply-To: <BkwnYQwsK_lnfHEmAIVU4X0fkubfXd4IDL8OxJHClEQ=.6af19d63-c8a1-492c-960d-cb5735eaedcf@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <BkwnYQwsK_lnfHEmAIVU4X0fkubfXd4IDL8OxJHClEQ=.6af19d63-c8a1-492c-960d-cb5735eaedcf@github.com>
Message-ID: <aW2T1MTXdqC2wfgtaCyUy9y7EAnfA-9bmaU5npUhGbs=.8815e1c3-6cab-4a41-bd0b-43ee6ae8103d@github.com>

On Mon, 24 Apr 2023 21:39:43 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
> 
>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>  - Optimizations for ReverseOrderListView; check indexes in reversed domain.
>  - Wording tweaks to SequencedMap / NavigableMap.
>  - Change "The implementation in this class" to "... interface."
>  - Delegate more methods in the views of ReverseOrderSortedMapView.
>  - Add missing @throws and @since tags.
>  - Convert code samples to snippets.
>  - Various editorial changes.
>  - Fix up toArray(T[]) on reverse-ordered views.
>  - Remove unnecessary 'final' from a couple places.
>  - ... and 86 more: https://git.openjdk.org/jdk/compare/2ea62c13...2827aa69

Backwards compatibility is indeed an issue. Nevertheless, it feels like there ought to be some way to navigate backwards and forwards during iteration. `AbstractSequentialList.listIterator(int)` provides this functionality, even though usage of this method isn't always efficient. In many cases, a SequencedCollection is backed by a doubly linked list. It's up to the user to understand performance implications. Maybe add new method `SequencedCollection.listIterator()`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1645914406

From dl at openjdk.org  Fri Jul 21 16:32:48 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 21 Jul 2023 16:32:48 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v9]
In-Reply-To: <Yr_CqO3bNS3wz0zWsWnaRqkAsqllX_VSG0x-la3vr_s=.9b72ada3-6c39-484c-91e0-d5562249ff98@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <jBBBtaRewKHlQ9jGa7ZtDZaj3lvZk1HdfjW4fRagPT0=.33acee50-6314-4ee1-9763-b55596813684@github.com>
 <Yr_CqO3bNS3wz0zWsWnaRqkAsqllX_VSG0x-la3vr_s=.9b72ada3-6c39-484c-91e0-d5562249ff98@github.com>
Message-ID: <02ApaLehIPDvRXPZsXO8hWntK8xmRCgRBdyOQXAyy_A=.702c6ee0-c91a-44b6-802c-7326cd50bd91@github.com>

On Fri, 21 Jul 2023 14:00:06 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 896:
> 
>> 894:             for (DualNode p = (pred == null) ? head : pred.next, c = p;
>> 895:                  p != null; ) {
>> 896:                 boolean isData = p.isData;
> 
> @DougLea Are you finding that manual hoisting of reads to final members has a perf edge? ?

Collection-support code from method countOfMode on down was minimally touched from its previous version. This shows up as a style clash into very branchy self-link-coping code. Changing might require more changes to WhiteBox tests that are finicky about node counts and self-links expected in traversals etc.  (These tests are useful but are themselves hard to change to accommodate small implementation differences.)

> src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 1584:
> 
>> 1582:                 if (isData) {
>> 1583:                     action.accept((E) item);
>> 1584:                     pred = p; p = q; continue;
> 
> @DougLea These three statements deserve their own lines, I'd say. :)

Same answer as above. Left as they were.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270868924
PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1270869931

From dl at openjdk.org  Fri Jul 21 16:42:25 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 21 Jul 2023 16:42:25 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v10]
In-Reply-To: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
Message-ID: <-6vf_XiZtv-LeQuln9iCrvwr1bZDWgaseqjfUENOpwE=.21f2d872-8b75-4f5b-be2a-1e27f8c109e2@github.com>

> This update addresses performance issues across both LinkedTransferQueue and SynchronousQueue by creating a common basis for implementation across them (mainly in LinkedTransferQueue).  Pasting from internal doc summary of changes:
>      * * Class DualNode replaces Qnode, with fields and methods
>      *   that apply to any match-based dual data structure, and now
>      *   usable in other j.u.c classes. in particular, SynchronousQueue.
>      * * Blocking control (in class DualNode) accommodates
>      *   VirtualThreads and (perhaps virtualized) uniprocessors.
>      * * All fields of this class (LinkedTransferQueue) are
>      *   default-initializable (to null), allowing further extension
>      *   (in particular, SynchronousQueue.Transferer)
>      * * Head and tail fields are lazily initialized rather than set
>      *   to a dummy node, while also reducing retries under heavy
>      *   contention and misorderings, and relaxing some accesses,
>      *   requiring accommodation in many places (as well as
>      *   adjustments in WhiteBox tests).

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 13 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8301341
 - Address more review comments
 - Address review comments
 - nitpicks
 - Merge branch 'openjdk:master' into JDK-8301341
 - Accommodate white-box tests; use consistent constructions; minor improvements
 - Merge branch 'openjdk:master' into JDK-8301341
 - Simplify contention handling; fix test
 - Fix inverted test assert; improve internal documentation; simplify code
 - Merge branch 'openjdk:master' into JDK-8301341
 - ... and 3 more: https://git.openjdk.org/jdk/compare/3e585ff1...f53cee67

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14317/files
  - new: https://git.openjdk.org/jdk/pull/14317/files/7c64a933..f53cee67

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=08-09

  Stats: 5915 lines in 182 files changed: 4676 ins; 702 del; 537 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 prappo at openjdk.org  Fri Jul 21 16:48:30 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 21 Jul 2023 16:48:30 GMT
Subject: RFR: 8266571: Sequenced Collections [v12]
In-Reply-To: <BkwnYQwsK_lnfHEmAIVU4X0fkubfXd4IDL8OxJHClEQ=.6af19d63-c8a1-492c-960d-cb5735eaedcf@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <BkwnYQwsK_lnfHEmAIVU4X0fkubfXd4IDL8OxJHClEQ=.6af19d63-c8a1-492c-960d-cb5735eaedcf@github.com>
Message-ID: <3fWZsZYaSsgOEw83b_nh-6aS12T7GQukUQWD4cjmObI=.a8b3716f-fdd3-4255-bec2-119f65a43e83@github.com>

On Mon, 24 Apr 2023 21:39:43 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
> 
>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>  - Optimizations for ReverseOrderListView; check indexes in reversed domain.
>  - Wording tweaks to SequencedMap / NavigableMap.
>  - Change "The implementation in this class" to "... interface."
>  - Delegate more methods in the views of ReverseOrderSortedMapView.
>  - Add missing @throws and @since tags.
>  - Convert code samples to snippets.
>  - Various editorial changes.
>  - Fix up toArray(T[]) on reverse-ordered views.
>  - Remove unnecessary 'final' from a couple places.
>  - ... and 86 more: https://git.openjdk.org/jdk/compare/2ea62c13...2827aa69

Maybe there's a case for simpler bidirectional iteration, but IMO, ListIterator has no business being a part of SequencedCollection. Do you have a specific use case, or it's general "it feels like there ought to be some way to navigate backwards and forwards"?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1645976239

From smarks at openjdk.org  Fri Jul 21 16:51:37 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 21 Jul 2023 16:51:37 GMT
Subject: RFR: 8266571: Sequenced Collections [v12]
In-Reply-To: <aW2T1MTXdqC2wfgtaCyUy9y7EAnfA-9bmaU5npUhGbs=.8815e1c3-6cab-4a41-bd0b-43ee6ae8103d@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <BkwnYQwsK_lnfHEmAIVU4X0fkubfXd4IDL8OxJHClEQ=.6af19d63-c8a1-492c-960d-cb5735eaedcf@github.com>
 <aW2T1MTXdqC2wfgtaCyUy9y7EAnfA-9bmaU5npUhGbs=.8815e1c3-6cab-4a41-bd0b-43ee6ae8103d@github.com>
Message-ID: <g-YSFh1MMreSozsQ1NsCwnPNRN7kkLKmzRmPDqrrpt0=.2446d498-70e8-4167-b48b-2ddddc9c4c88@github.com>

On Fri, 21 Jul 2023 16:19:35 GMT, Hollis Waite <duke at openjdk.org> wrote:

>> Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
>> 
>>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>>  - Optimizations for ReverseOrderListView; check indexes in reversed domain.
>>  - Wording tweaks to SequencedMap / NavigableMap.
>>  - Change "The implementation in this class" to "... interface."
>>  - Delegate more methods in the views of ReverseOrderSortedMapView.
>>  - Add missing @throws and @since tags.
>>  - Convert code samples to snippets.
>>  - Various editorial changes.
>>  - Fix up toArray(T[]) on reverse-ordered views.
>>  - Remove unnecessary 'final' from a couple places.
>>  - ... and 86 more: https://git.openjdk.org/jdk/compare/2ea62c13...2827aa69
>
> Backwards compatibility is indeed an issue. Nevertheless, it feels like there ought to be some way to navigate backwards and forwards during iteration. `AbstractSequentialList.listIterator(int)` provides this functionality, even though usage of this method isn't always efficient. In many cases, a SequencedCollection is backed by a doubly linked list. It's up to the user to understand performance implications. Maybe add new method `SequencedCollection.listIterator()`?
> 
>> What stops you from deriving a list from LinkedHashMap.values() as follows?
> 
> I wouldn't want to copy the whole collection. Furthermore, deletions wouldn't be backed by original collection.

@hwaite 

As @pavelrappo suggested previously, changing the return type of a method within the hierarchy is an incompatible change. The issue is that doing so would invalidate all existing subclasses and subinterfaces. Suppose for example we were to change the iterator() method of SequencedCollection and List to return ListIterator (along with all the concrete classes in the JDK). Existing List subclasses would still have an iterator() method that returned an Iterator. If anybody called it expecting to get a ListIterator, they'd get NoSuchMethodError.

I went through a bunch of similar analysis when I attempted to change SequencedMap's keySet/values/entrySet methods to return SequencedSet and SequencedCollection. The cases are pretty complicated but bottom line is that it's impractical. In retrospect though this is kind of obvious. We'd be changing the contract of an existing interface, but there's no way any existing implementation binary can fulfill this modified contract.

Stepping away from this actual change, it'd be good to understand what you're trying to do here. ListIterator fuses three different concepts: the ability to traverse forwards and backwards, the ability to mutate the underlying List at the current location (add/remove/set), and the index of the current location. Which of these is important to your use case? What operations would be helpful?

Note that ListIterator doesn't actually reverse its direction. Instead, the calling code needs to call different methods to traverse forwards (hasNext/next) vs backwards (hasPrevious/previous). In some unpublished prototypes I did experiment with a ReversibleIterator (a precursor to the original ReversibleCollection proposal) where you could switch directions in the middle of iteration. I eventually abandoned it. I forget the exact reason, but I seem to recall that the difficulty was with maintaining the right position when iteration is reversed, from within a default method.

Finally, I have feedback that ListIterator is pretty clumsy to use. I kind of suspect that a putative ReversibleIterator would also be pretty clumsy.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1645981312

From forax at openjdk.org  Fri Jul 21 16:51:38 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 21 Jul 2023 16:51:38 GMT
Subject: RFR: 8266571: Sequenced Collections [v12]
In-Reply-To: <aW2T1MTXdqC2wfgtaCyUy9y7EAnfA-9bmaU5npUhGbs=.8815e1c3-6cab-4a41-bd0b-43ee6ae8103d@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <BkwnYQwsK_lnfHEmAIVU4X0fkubfXd4IDL8OxJHClEQ=.6af19d63-c8a1-492c-960d-cb5735eaedcf@github.com>
 <aW2T1MTXdqC2wfgtaCyUy9y7EAnfA-9bmaU5npUhGbs=.8815e1c3-6cab-4a41-bd0b-43ee6ae8103d@github.com>
Message-ID: <7pJLRQdSujcaqh0LF9Qfq4bd5jpSUqHl3n97qTBUosg=.d99c5630-64f5-4bcc-b40a-4eadc5bb48cb@github.com>

On Fri, 21 Jul 2023 16:19:35 GMT, Hollis Waite <duke at openjdk.org> wrote:

>  a SequencedCollection is backed by a doubly linked list. It's up to the user to understand performance implications.

Beware of this kind of thinking, implementations of collections in the JDK change.
Many hashtable implementations in other langages are not using chaining anymore  because open adressing allows collisions to stay in the same cache line and/or the code to be vectorized, so HashMap/linkedHashMap implementations may not be the same in a future version of the JDK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1645982619

From aturbanov at openjdk.org  Fri Jul 21 16:52:53 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 21 Jul 2023 16:52:53 GMT
Subject: Integrated: 8312414: Make java.util.ServiceLoader.LANG_ACCESS final
In-Reply-To: <qWcyYb8lp5Vr1wwxc_TsCoLilVENs7RKj5kGl4HpYzw=.ad9a8ed8-df06-4f66-b260-a5dac50f2418@github.com>
References: <qWcyYb8lp5Vr1wwxc_TsCoLilVENs7RKj5kGl4HpYzw=.ad9a8ed8-df06-4f66-b260-a5dac50f2418@github.com>
Message-ID: <YNL8hUcqn0wyNk4L9C_aJBrqoMCk4lRPvpZaemWydrM=.336dcae1-501f-42bb-9321-469139e4e05f@github.com>

On Tue, 18 Jul 2023 20:06:56 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found opportunity to make static `ServiceLoader.LANG_ACCESS` field `final`.

This pull request has now been integrated.

Changeset: f4ba7b21
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f4ba7b219851217c48e46258d9977d51a757a1a6
Stats:     5 lines in 1 file changed: 0 ins; 3 del; 2 mod

8312414: Make java.util.ServiceLoader.LANG_ACCESS final

Reviewed-by: alanb, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/14926

From prappo at openjdk.org  Fri Jul 21 16:58:28 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 21 Jul 2023 16:58:28 GMT
Subject: RFR: 8266571: Sequenced Collections [v12]
In-Reply-To: <BkwnYQwsK_lnfHEmAIVU4X0fkubfXd4IDL8OxJHClEQ=.6af19d63-c8a1-492c-960d-cb5735eaedcf@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <BkwnYQwsK_lnfHEmAIVU4X0fkubfXd4IDL8OxJHClEQ=.6af19d63-c8a1-492c-960d-cb5735eaedcf@github.com>
Message-ID: <SSM8oBBeCAWlQVEPp88TC66DUXKsTzJCADpdx9bLGqo=.0015391b-6844-4980-b61b-eda2742df8d4@github.com>

On Mon, 24 Apr 2023 21:39:43 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
> 
>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>  - Optimizations for ReverseOrderListView; check indexes in reversed domain.
>  - Wording tweaks to SequencedMap / NavigableMap.
>  - Change "The implementation in this class" to "... interface."
>  - Delegate more methods in the views of ReverseOrderSortedMapView.
>  - Add missing @throws and @since tags.
>  - Convert code samples to snippets.
>  - Various editorial changes.
>  - Fix up toArray(T[]) on reverse-ordered views.
>  - Remove unnecessary 'final' from a couple places.
>  - ... and 86 more: https://git.openjdk.org/jdk/compare/2ea62c13...2827aa69

Additional observation. List API is highly expressive and combinable like Lego&reg; bricks. Have a list? Have a subrange in mind that you want to iterate backwards in a for 
-loop? No problem!

    for (var e : list.subList(from, to).reversed())
        ...

SequencedCollection is weaker than List, but stronger than Collection. If you want maximum flexibility and convenience use the strongest type you possibly can.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1645990527

From prappo at openjdk.org  Fri Jul 21 17:13:47 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 21 Jul 2023 17:13:47 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v9]
In-Reply-To: <geqHOjkYp5gHbAux41pM7yBEAYmi0p80LBEkNqbC_5g=.40bba6b3-0dfa-4651-9ebd-ebc6f4f0d444@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <geqHOjkYp5gHbAux41pM7yBEAYmi0p80LBEkNqbC_5g=.40bba6b3-0dfa-4651-9ebd-ebc6f4f0d444@github.com>
Message-ID: <21QnoIQP4Cho5l27COnLi1vZsjf1gLGRK_dXAEbiZ5A=.dc46ca16-7771-4aa5-b0da-d58fdd841038@github.com>

On Fri, 21 Jul 2023 15:59:42 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 14 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8310033-time-compareto
>  - Corrected descriptions with respect to chronology and the concrete temporary type.
>  - Improve wording and remove markup for clarity
>  - Merge branch 'master' into 8310033-time-compareto
>  - Correct the descriptions to correctly identify the compareTo return
>    value < 0 as this is before that, and > 0 as this is after that.
>    Thanks to a careful reviewer spotting my reversing of the conditions.
>  - Improve the grammar of "the comparator value is" -> "the comparator value, that is"
>    Thanks for the reminder.
>  - Merge branch 'master' into 8310033-time-compareto
>  - Improve descriptions to be more specific and remove inappropriate use of before/after
>    Remove extra blank lines
>  - Clarify return values of date time classes
>  - Use {@code xxx} to highlight the comparison against the arg.
>    Update copyrights.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/62616dc3...5ecd7aeb

Looks good to me.

-------------

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14479#pullrequestreview-1541529827

From duke at openjdk.org  Fri Jul 21 17:19:25 2023
From: duke at openjdk.org (Hollis Waite)
Date: Fri, 21 Jul 2023 17:19:25 GMT
Subject: RFR: 8266571: Sequenced Collections [v12]
In-Reply-To: <g-YSFh1MMreSozsQ1NsCwnPNRN7kkLKmzRmPDqrrpt0=.2446d498-70e8-4167-b48b-2ddddc9c4c88@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <BkwnYQwsK_lnfHEmAIVU4X0fkubfXd4IDL8OxJHClEQ=.6af19d63-c8a1-492c-960d-cb5735eaedcf@github.com>
 <aW2T1MTXdqC2wfgtaCyUy9y7EAnfA-9bmaU5npUhGbs=.8815e1c3-6cab-4a41-bd0b-43ee6ae8103d@github.com>
 <g-YSFh1MMreSozsQ1NsCwnPNRN7kkLKmzRmPDqrrpt0=.2446d498-70e8-4167-b48b-2ddddc9c4c88@github.com>
Message-ID: <1GU-JyJkWfB9YGztmMYVt3DDd0gnqMAOUM7viTjYsu4=.8b99773d-7fcf-4904-bf51-b01336340e63@github.com>

On Fri, 21 Jul 2023 16:48:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> ListIterator fuses three different concepts: the ability to traverse forwards and
> backwards, the ability to mutate the underlying List at the current location
> (add/remove/set), and the index of the current location. Which of these is important
> to your use case? What operations would be helpful?

My specific use case requires bidirectional iteration of a LinkedHashMap along with ability to remove items. It wouldn't need to be a ListIterator specifically, but once one has a collection with both a size and bidirectional iterator, it's trivial to turn it into a List via an AbstractSequentialList adapter. If this has already been looked into, by all means leave as is. I thought maybe it was an unexplored oversight.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1646013953

From naoto at openjdk.org  Fri Jul 21 17:23:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Jul 2023 17:23:48 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v9]
In-Reply-To: <geqHOjkYp5gHbAux41pM7yBEAYmi0p80LBEkNqbC_5g=.40bba6b3-0dfa-4651-9ebd-ebc6f4f0d444@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <geqHOjkYp5gHbAux41pM7yBEAYmi0p80LBEkNqbC_5g=.40bba6b3-0dfa-4651-9ebd-ebc6f4f0d444@github.com>
Message-ID: <X5anZRI1MlqeeiaYTG4uCFeY_RdHS9WNNNmcXlSHTUM=.5745d344-1efc-46e8-9cd2-f31bed372cdf@github.com>

On Fri, 21 Jul 2023 15:59:42 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 14 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8310033-time-compareto
>  - Corrected descriptions with respect to chronology and the concrete temporary type.
>  - Improve wording and remove markup for clarity
>  - Merge branch 'master' into 8310033-time-compareto
>  - Correct the descriptions to correctly identify the compareTo return
>    value < 0 as this is before that, and > 0 as this is after that.
>    Thanks to a careful reviewer spotting my reversing of the conditions.
>  - Improve the grammar of "the comparator value is" -> "the comparator value, that is"
>    Thanks for the reminder.
>  - Merge branch 'master' into 8310033-time-compareto
>  - Improve descriptions to be more specific and remove inappropriate use of before/after
>    Remove extra blank lines
>  - Clarify return values of date time classes
>  - Use {@code xxx} to highlight the comparison against the arg.
>    Update copyrights.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/16857910...5ecd7aeb

+1

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14479#pullrequestreview-1541541771

From jvernee at openjdk.org  Fri Jul 21 17:24:45 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 21 Jul 2023 17:24:45 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
Message-ID: <pG4rRRh1yef2sQH1_eiTzwOMc9B6teJ0O5fE2-3rwCY=.bf9b25d9-aa7f-43ec-ad74-42258482b1c4@github.com>

On Sat, 8 Jul 2023 10:48:15 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address suggestions from Jorn Vernee

FWIW, I found a bug in StdLibTest while working on something else: the format string for `LONG` is `%d` while it should be `%lld`. This might mess up some printf implementation I think. 

This might fix your issue as well:


diff --git a/test/jdk/java/foreign/StdLibTest.java b/test/jdk/java/foreign/StdLibTest.java
index 0732f60525d9..c9ce60bfc09b 100644
--- a/test/jdk/java/foreign/StdLibTest.java
+++ b/test/jdk/java/foreign/StdLibTest.java
@@ -120,16 +119,20 @@ void test_rand() throws Throwable {
 
     @Test(dataProvider = "printfArgs")
     void test_printf(List<PrintfArg> args) throws Throwable {
-        String formatArgs = args.stream()
-                .map(a -> a.format)
+        String javaFormatArgs = args.stream()
+                .map(a -> a.javaFormat)
+                .collect(Collectors.joining(","));
+        String nativeFormatArgs = args.stream()
+                .map(a -> a.nativeFormat)
                 .collect(Collectors.joining(","));
 
-        String formatString = "hello(" + formatArgs + ")\n";
+        String javaFormatString = "hello(" + javaFormatArgs + ")\n";
+        String nativeFormatString = "hello(" + nativeFormatArgs + ")\n";
 
-        String expected = String.format(formatString, args.stream()
+        String expected = String.format(javaFormatString, args.stream()
                 .map(a -> a.javaValue).toArray());
 
-        int found = stdLibHelper.printf(formatString, args);
+        int found = stdLibHelper.printf(nativeFormatString, args);
         assertEquals(found, expected.length());
     }
 
@@ -377,21 +385,24 @@ public static Object[][] printfArgs() {
     }
 
     enum PrintfArg {
-        INT(int.class, C_INT, "%d", arena -> 42, 42),
-        LONG(long.class, C_LONG_LONG, "%d", arena -> 84L, 84L),
-        DOUBLE(double.class, C_DOUBLE, "%.4f", arena -> 1.2345d, 1.2345d),
-        STRING(MemorySegment.class, C_POINTER, "%s", arena -> arena.allocateFrom("str"), "str");
+        INT(int.class, C_INT, "%d", "%d", arena -> 42, 42),
+        LONG(long.class, C_LONG_LONG, "%lld", "%d", arena -> 84L, 84L),
+        DOUBLE(double.class, C_DOUBLE, "%.4f", "%.4f", arena -> 1.2345d, 1.2345d),
+        STRING(MemorySegment.class, C_POINTER, "%s", "%s", arena -> arena.allocateFrom("str"), "str");
 
         final Class<?> carrier;
         final ValueLayout layout;
-        final String format;
+        final String nativeFormat;
+        final String javaFormat;
         final Function<Arena, ?> nativeValueFactory;
         final Object javaValue;
 
-        <Z, L extends ValueLayout> PrintfArg(Class<?> carrier, L layout, String format, Function<Arena, Z> nativeValueFactory, Object javaValue) {
+        <Z, L extends ValueLayout> PrintfArg(Class<?> carrier, L layout, String nativeFormat, String javaFormat,
+                                             Function<Arena, Z> nativeValueFactory, Object javaValue) {
             this.carrier = carrier;
             this.layout = layout;
-            this.format = format;
+            this.nativeFormat = nativeFormat;
+            this.javaFormat = javaFormat;
             this.nativeValueFactory = nativeValueFactory;
             this.javaValue = javaValue;
         }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14801#issuecomment-1646020324

From uschindler at openjdk.org  Fri Jul 21 18:54:45 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Fri, 21 Jul 2023 18:54:45 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <5G6Mzx_lhv2RE5BrFCmZU8DH0JjRGoPS3XkWfpLV5Gs=.03064bde-fbe8-4e4f-ba38-b0c6e4309214@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
 <fk9xibELcU7aQCrGKInnPNymVhQtn6TMwKM6_v__DKY=.8f9fb360-0b1d-48fd-8c6d-0e038cb91597@github.com>
 <mWjaEDNaEnLF68Onv_GxycjtrA-_00mbeM4jKtIKGKw=.c6ba7713-b2f9-420d-8a03-aaa0f60774a6@github.com>
 <ZUYrddGWvizlur41EON8eaklamXsX9vwmpe8KwGQvrI=.d169d052-cd5e-41ee-8022-d672ed38aaaf@github.com>
 <FF2Z3PXfUTc_6LS0UUwK0eYUUHUCBlTWmPGfTybHPoY=.e6566bb6-92ee-4b4f-a4a6-136f6b6af378@github.com>
 <0zgFncA09YCmjGPjhf_3KxSN_aQP68qc4MaQSNkQtFo=.3b0b7b34-b875-4c86-9b23-174259f86131@github.com>
 <8Or7d1O8BpmU85MJlMmEkdrQGYqdZRf3sSq8oQ_bqNM=.2a9f8769-9547-4e0b-b4c7-ba96769504e9@github.com>
 <GJBJnIgGQti7f2wvw4IK_1Sq5cQBOl780hN7J2EcRcU=.b9827357-83e9-4d09-9bce-a6599b00b51f@github.com>
 <TDAKCS2Kbl3pgJym4uKQjna214FYxqhAfAaH9v3IV-8=.d85a9ce4-03d4-4173-9d36-ba54c5479223@github.com>
 <4XabEyeVwDm5EylwIRMC5wi6SuwvJv3cFb_
 3_WTo__4=.b803d040-593e-4b20-8ea9-46076e350967@github.com>
 <w3BZoLr2-bIXj7IGMzEslOIQjq_3TqOhjajq60eCOJA=.94c9563b-e7a0-459f-b35b-a75827e116b9@github.com>
 <cgKNos9xwkbnBIIyvCqIJPSOIutSHTTAUWj7DOK8D48=.4684ec4e-a8f0-4b3d-b8a5-f08fa7b7508f@github.com>
 <VqHdP02PekCag5ZNnKLE2yGtAsBGJGz3jO9vZL-mPbI=.47679ad9-2909-4d05-9471-e1049dcdde59@github.com>
 <U9GHgas2isEAlCux1T_QfuVj7kub-gLMhAYEqnz4twE=.0574ba0e-ef3f-4328-8b23-cba42034d47d@github.com>
 <rTB4ZN2L094-B1iuBjktkhvQn1OXxnw8M83gGxXIhh4=.fb1c085c-b714-4ec1-9dda-2d099e838430@github.com>
 <5vWADWw1xEPg0Rmq6cgvKRj9CN5cSTBRYOPkDBlkBxk=.b20fed4c-12fe-4dbc-b51e-2d672d74c070@github.com>
 <y2JG_qO6Y_jJyjXraNEOAbl2_SJuUh1elJSm0GFxAH0=.77e0757b-eec9-49ad-ad52-c37d3e3e67a6@github.com>
 <Q2tgKNyIUTLAdt3MdARsHFmz5PLhYcdxyNzaFZyCsK0=.de22d165-0ed0-43b8-8ece-5779fa5bcc78@github.com>
 <Lzi9EKlcwY36SBqlVCN6bYSGatbUBVQiQIYv5Nbzmj0=.c7928875-f0b4-4fd6-816e-8e0357b8a92c@github.com>
 <wCL4vOROLQFoktk5IESaD4CpTnBAxiEq9qq7mDO41S0=.690ff507-32ee-402f-b727-5f6ea5f669b4@
 github.com>
 <qHehDUvqpRaBr51w9ZlfWYmT-RmiJ_UVi3AoUEOztmU=.b220ce4f-9807-48af-874b-cb0e03361c5f@github.com>
 <2Z46WAHv8N0fSBJFgg0-iBXHBM13-9jYYw5mV7i4yMo=.e30c1ff1-fdfb-4883-b612-f1f0d637dc73@github.com>
 <l_4-vwLQ3kHO-jA7-ajsZNCXPNUNRIK574Xa8efvD6s=.da0ae935-7978-4c30-90e6-c784f6c60b1e@github.com>
 <qsl35SFoAlrzBj_CJlxtYOEUHqP-zIR7GZtAO9nVmrI=.a87d32f8-8ba0-4ccd-aba8-42199c4fd8c2@github.com>
 <sbB0IUGrHgz0Gj9rPYB_rYcJlTc1dUMhvbYDvi_1N7o=.0cc2938b-aaf5-4dd6-96ba-c0bb0d0d6581@github.com>
 <JZAJRO1jljQ5G_qVDIEVUCeNsn1EBuZjaRmbTqTAHxc=.9d850bed-02cb-4abf-af26-f39ccced98de@github.com>
 <8ehoqZ03U2jtaV19chg-02fJjQ1i4umzzrIZUqL8MF8=.bd1d24ea-38ae-49a1-a26d-cffed575e72b@github.com>
 <5G6Mzx_lhv2RE5BrFCmZU8DH0JjRGoPS3XkWfpLV5Gs=.03064bde-fbe8-4e4f-ba38-b0c6e4309214@github.com>
Message-ID: <bO1K2QIRFU2bHJCbjlR8KLjxHOgVbUCVXq99K9NtS7c=.69476a3d-1743-4faf-aa66-a7ab1b1571d9@github.com>

On Fri, 21 Jul 2023 15:14:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> So have you thought of making this low-level classes public so we outside users no longer need to deal with VarHandles?

> I believe this is beyond the scope of this PR.

Sure, I brought this up here but yes, it is not really the scope of this PR. It is just another idea that this class could be of more wide use although outside of this PR and also outside of Lucene. Actually it would be nice to have it public, but I know this involves creating a JEP and so on. If there's interest I could start on proposing something like this on mailing list, later creating a JEP or whatever else is needed.

P.S.: Actually for a 3rd party user the whole thing is not much complicated. You only need a class to allocate the VarHandles and then use them from code, you don't even need the wrapper methods (although the ymake it nicer to read and you don't need the cast of return value). As there is no security involved, one can have those VarHandles as public static fields in some utility class: https://lucene.apache.org/core/9_7_0/core/org/apache/lucene/util/BitUtil.html; Usage of them is quite simple then: https://github.com/apache/lucene/blob/59c56a0aed9a43d24c676376b5d50c5c6518e3bc/lucene/core/src/java/org/apache/lucene/store/ByteArrayDataInput.java#L96 (there are many of those throughout Lucene's code)

So I agree with your ideas, we have to decide what is best for this PR. I tend to think that those 2 options are good:
- Use ByteBuffer in classfile API
- commit the PR as proposed here (looks fine to me).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1270985286

From duke at openjdk.org  Fri Jul 21 20:20:44 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 21 Jul 2023 20:20:44 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v10]
In-Reply-To: <02ApaLehIPDvRXPZsXO8hWntK8xmRCgRBdyOQXAyy_A=.702c6ee0-c91a-44b6-802c-7326cd50bd91@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <jBBBtaRewKHlQ9jGa7ZtDZaj3lvZk1HdfjW4fRagPT0=.33acee50-6314-4ee1-9763-b55596813684@github.com>
 <Yr_CqO3bNS3wz0zWsWnaRqkAsqllX_VSG0x-la3vr_s=.9b72ada3-6c39-484c-91e0-d5562249ff98@github.com>
 <02ApaLehIPDvRXPZsXO8hWntK8xmRCgRBdyOQXAyy_A=.702c6ee0-c91a-44b6-802c-7326cd50bd91@github.com>
Message-ID: <9QLGt6nOU992EBni8jJ-3kgQ5tq5gI2oHTm4Dd5B5ts=.77b1700f-47d8-4f21-87ed-524ef97fa216@github.com>

On Fri, 21 Jul 2023 16:29:24 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 896:
>> 
>>> 894:             for (DualNode p = (pred == null) ? head : pred.next, c = p;
>>> 895:                  p != null; ) {
>>> 896:                 boolean isData = p.isData;
>> 
>> @DougLea Are you finding that manual hoisting of reads to final members has a perf edge? ?
>
> Collection-support code from method countOfMode on down was minimally touched from its previous version. This shows up as a style clash into very branchy self-link-coping code. Changing might require more changes to WhiteBox tests that are finicky about node counts and self-links expected in traversals etc.  (These tests are useful but are themselves hard to change to accommodate small implementation differences.)

@DougLea Alright, good to know :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1271061647

From almatvee at openjdk.org  Fri Jul 21 20:55:41 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 21 Jul 2023 20:55:41 GMT
Subject: RFR: 8312488: tools/jpackage/share/AppLauncherEnvTest.java fails
 with dynamically linked libstdc++
In-Reply-To: <RMaWupHshwbpWmIsBXfRG9swzBbJ3nGeDiloyDJLiRk=.d1f80bff-3e44-4060-8958-3d4f0f1f63a3@github.com>
References: <RMaWupHshwbpWmIsBXfRG9swzBbJ3nGeDiloyDJLiRk=.d1f80bff-3e44-4060-8958-3d4f0f1f63a3@github.com>
Message-ID: <qjQ12NAwD-sH1J3uGTo39ZinI2yzwLsZYY04kLlw-yc=.2d00b9a7-d5ab-42f2-915c-d625fbf3df79@github.com>

On Fri, 21 Jul 2023 10:55:13 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> Use the  same approach as Logger::defaultLogger() to ensure that the appender is not destroyed before shared object destructor function is executed.
> 
> The alternative is to delete dcon() function, but we might run into a similiar tear-down issue later (e.g. logging from some object's destructor).
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/tools                                215   215     0     0   
> ==============================
> TEST SUCCESS

src/jdk.jpackage/share/native/common/app.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2023 Oracle and/or its affiliates. All rights reserved.

Missing "," after 2023. Should be: "Copyright (c) 2020, 2023, Oracle and/or its affiliates.".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14971#discussion_r1271102509

From bpb at openjdk.org  Fri Jul 21 21:18:45 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 21 Jul 2023 21:18:45 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: <TkxKKVZlHAgOlDLJ1jc6rFD_GcooxwY_UvzOkJvulGQ=.121e38b1-555b-4b4a-9a18-a54d982ebaf3@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 will sponsor this on Monday if it is still needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14589#issuecomment-1646246328

From bpb at openjdk.org  Fri Jul 21 22:46:53 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 21 Jul 2023 22:46:53 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available
Message-ID: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>

Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.

-------------

Commit messages:
 - 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

Changes: https://git.openjdk.org/jdk/pull/14981/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14981&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6478546
  Stats: 81 lines in 7 files changed: 29 ins; 15 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/14981.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14981/head:pull/14981

PR: https://git.openjdk.org/jdk/pull/14981

From bpb at openjdk.org  Fri Jul 21 22:46:54 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 21 Jul 2023 22:46:54 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available
In-Reply-To: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
Message-ID: <VvQc12-r1-bBmNb4o-RejqyeCIdP0ZVNaTHdS_IH01o=.5e614e4a-54c1-4d88-b256-d1b8b9afd02a@github.com>

On Fri, 21 Jul 2023 22:40:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.

The cost of native memory allocation appears to degrade the throughput of reads and writes of larger arrays. Above a certain size, allocating and looping over a smaller array was measured to achieve higher throughput.

As `Objects::checkFromIndexSize` now guards against out of bounds conditions, and obtaining the array length as its third parameter provides a null check, the NULL and bounds checks could be removed from the C code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14981#issuecomment-1646312987

From smarks at openjdk.org  Sat Jul 22 04:46:51 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 22 Jul 2023 04:46:51 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: <D2AX-7h3RwRnYZj_z6vSj0EVDjmMeMI-q15uFsEYycU=.29755c8c-a008-4484-84d0-56fc5c5a4b03@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 and https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8311905

Hi, thanks for the background and the discussion of the alternatives. I'm not sure that drafting the CSR is the right next step; there are a number of foibles about editing the specifications that come into play when preparing the CSR. However, what you've written above is a good design discussion about the different alternatives and how they affect the specification and the implementation.

One thing that we need to consider is compatibility. From an excessively pedantic standpoint, any change in behavior is a potential incompatibility (somebody might be relying on that bug!) but I think that fixing obviously incorrect behavior is reasonable. As much as possible I'd like to make sure that things that worked, at least partially, continue to work.

With this in mind I'm leaning toward allowing a BitSet to contain bits including the Integer.MAX_VALUE bit, and adjusting various specs accordingly. I think the best way to specify this is to say that length() returns an int in the range [0, 2^31] as an unsigned value. In practice of course this means it can return any Java `int` value in the range [0, MAX_VALUE] and also Integer.MIN_VALUE. A sufficiently careful programmer can use such values correctly, as long as they avoid doing certain things such as comparing against zero. (We might want to have a note in the spec to that effect.)

It's good that you analyzed the `valueOf` methods. It looks to me like the implementation will store an actual array potentially containing bits beyond the MAX_VALUE bit, and this will affect things like length() and size() and such bits won't be accessible via get() or set(). So, on the one hand, this behavior seems clearly broken and ought to be fixed by limiting the input array along the lines suggested by your three options.

On the other hand, it seems that from looking at the code, it's possible to create an "over-size" BitSet with valueOf(), and perform bulk bit manipulations on it and other BitSets using methods like and(), or(), and xor(). It also appears possible to read out the bits successfully using toByteArray() or toLongArray(). Thus an application might be able to manipulate bit arrays of up to about 2^37 bits long by using BitSet with long arrays or LongBuffers. Restricting the input of valueOf() to 2^31 bits would break such applications.

Also note that the specification says the bits are numbered by nonnegative integers (that is, zero to 2^31) which would seem to preclude longer bit arrays. However, if somebody does have an application that works with longer bit arrays, it seems unreasonable for us to break that application, unless we have good justification for doing so. I think it's a bit unlikely that somebody is actually relying on the feature of over-size arrays, but it seems possible, and I don't see any evidence otherwise (but I haven't looked too hard yet).

If we were to restrict BitSet to 2^31 bits, I'd rule out (2) from the three options. It doesn't seem sensible to check for and throw an exception only if certain bits are set. If the system did that, it might mean that code sometimes works but sometimes fails, depending on the _values_ contained in the array or buffer. Seems like it would make things hard to diagnose. Of the remaining options, I'd prefer option (1) to rejecting long arrays over (3) ignoring the extra values in the array. (1) is fail-fast but arguably not very friendly. However, (3) could potentially could result in silent data loss, which definitely seems like a bad idea.

However I'm still uncomfortable with restricting BitSet to 2^31 bits and thus changing the behavior of the various valueOf() methods. I'd welcome further discussion or evidence regarding whether applications might or might not be relying on the over-sized behavior. I did a quick survey of open source code but I haven't found anything conclusive yet.

Another approach would be to adjust the specifications to allow for over-size arrays. Methods that operate on bit indexes would for the most part not be able to read or write to the areas of the array beyond 2^31, but the bulk operations (and/or/xor) would work. Methods such as cardinality(), length(), nextSetBit(), and similar would be more difficult. We can accommodate the full 31-bit range using the "unsigned" carve-out mentioned previously. But that doesn't work for larger values.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1646454706

From duke at openjdk.org  Sat Jul 22 06:15:44 2023
From: duke at openjdk.org (sid8606)
Date: Sat, 22 Jul 2023 06:15:44 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
Message-ID: <4-SkKe526mi_69V5zOsgHsLNTp1_vHzNaPFJluPXppM=.4ed68247-ac70-41b1-a4b6-e0daf864ab9f@github.com>

On Sat, 8 Jul 2023 10:48:15 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address suggestions from Jorn Vernee

I have narrowed down the issue failing on  glibc 2.31 but passes on glibc 2.35 on s390x. 
Two tests methods are failing **test_time** and **test_qsort**.
@JornVernee test_printf test method is passing as it is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14801#issuecomment-1646500956

From aoqi at openjdk.org  Sat Jul 22 07:32:52 2023
From: aoqi at openjdk.org (Ao Qi)
Date: Sat, 22 Jul 2023 07:32:52 GMT
Subject: RFR: 8311631: When multiple users run
 tools/jpackage/share/LicenseTest.java,
 Permission denied for writing /var/tmp/*.files [v2]
In-Reply-To: <TUeytaZUrHMd3oY7bZSlvXQD1pmFbLB3yj9C1hG5S24=.fa60a3b9-faef-471b-af2e-915c022c792e@github.com>
References: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
 <tlogilGhgOPDCmKldD1UWGwoRqi3TYNe3tmgKG2D8EY=.0d789b18-6aac-4102-859d-653aab1cbcdf@github.com>
 <TUeytaZUrHMd3oY7bZSlvXQD1pmFbLB3yj9C1hG5S24=.fa60a3b9-faef-471b-af2e-915c022c792e@github.com>
Message-ID: <yAzh2-UM5siVhoRHt5hfZ77Z3BpFCpN_r4_YwDRrSDg=.b43320ff-05aa-4d27-bf3f-289d4ac85c3a@github.com>

On Fri, 14 Jul 2023 21:58:33 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> yaqsun has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8311631: When multiple users run tools/jpackage/share/LicenseTest.java, Permission denied for writing /var/tmp/*.files
>
> The fix with `%{_builddir}` looks better. Did it resolve the issue?

@alexeysemenyukoracle , could you help to sponsor this? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14802#issuecomment-1646515669

From aoqi at openjdk.org  Sat Jul 22 07:44:41 2023
From: aoqi at openjdk.org (Ao Qi)
Date: Sat, 22 Jul 2023 07:44:41 GMT
Subject: RFR: 8311631: When multiple users run
 tools/jpackage/share/LicenseTest.java,
 Permission denied for writing /var/tmp/*.files [v2]
In-Reply-To: <vTdZU0YqeDNZy5md1xEAYyiBUx_JpEBPlihm3NSns64=.7a2971c7-4506-4dbc-bc61-d2b8921897ff@github.com>
References: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
 <tlogilGhgOPDCmKldD1UWGwoRqi3TYNe3tmgKG2D8EY=.0d789b18-6aac-4102-859d-653aab1cbcdf@github.com>
 <TUeytaZUrHMd3oY7bZSlvXQD1pmFbLB3yj9C1hG5S24=.fa60a3b9-faef-471b-af2e-915c022c792e@github.com>
 <vTdZU0YqeDNZy5md1xEAYyiBUx_JpEBPlihm3NSns64=.7a2971c7-4506-4dbc-bc61-d2b8921897ff@github.com>
Message-ID: <LClOVfcOhTrFrKfdxwe-GWbOvvIltw3bp9yZcU-BuPM=.fa7985e4-b279-4858-ac4b-1e3e43ec4234@github.com>

On Mon, 17 Jul 2023 01:08:15 GMT, yaqsun <duke at openjdk.org> wrote:

>> The fix with `%{_builddir}` looks better. Did it resolve the issue?
>
>> The fix with `%{_builddir}` looks better. Did it resolve the issue?
> 
> Yes, it solved. The root of intermediate files changed to /tmp/jdk.jpackage16701381473798822/BUILD/commonlicensetest.filesystem.files.

@yaqsun , I suggest you enable GHA and trigger a run, before this patch is merged.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14802#issuecomment-1646517714

From duke at openjdk.org  Sat Jul 22 07:56:53 2023
From: duke at openjdk.org (yaqsun)
Date: Sat, 22 Jul 2023 07:56:53 GMT
Subject: RFR: 8311631: When multiple users run
 tools/jpackage/share/LicenseTest.java,
 Permission denied for writing /var/tmp/*.files [v3]
In-Reply-To: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
References: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
Message-ID: <jhTelbjgIYTxYFllBYdbX-FJbydzsMn8Lxlxg1yfp48=.85d2113b-74e8-4676-b7c7-673dfbedc5e7@github.com>

> The prerequisite is to install the rpmbuild command, when multiple users switch to write /var/tmp/*.files will have the permission forbidden.

yaqsun has updated the pull request incrementally with one additional commit since the last revision:

  8311631: When multiple users run tools/jpackage/share/LicenseTest.java, Permission denied for writing /var/tmp/*.files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14802/files
  - new: https://git.openjdk.org/jdk/pull/14802/files/fcab800d..0e3e6a25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14802&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14802&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14802/head:pull/14802

PR: https://git.openjdk.org/jdk/pull/14802

From duke at openjdk.org  Sat Jul 22 08:14:47 2023
From: duke at openjdk.org (yaqsun)
Date: Sat, 22 Jul 2023 08:14:47 GMT
Subject: RFR: 8311631: When multiple users run
 tools/jpackage/share/LicenseTest.java,
 Permission denied for writing /var/tmp/*.files [v4]
In-Reply-To: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
References: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
Message-ID: <BzCM4LcaEE33CuSJIr9uifkaseGLaa-d45HpkxgJiR0=.1dd05a87-bb4c-415c-91a6-4ef7a124cfe3@github.com>

> The prerequisite is to install the rpmbuild command, when multiple users switch to write /var/tmp/*.files will have the permission forbidden.

yaqsun has updated the pull request incrementally with one additional commit since the last revision:

  8311631: restore to final patch and trigger a run

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14802/files
  - new: https://git.openjdk.org/jdk/pull/14802/files/0e3e6a25..d7396168

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14802&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14802&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14802/head:pull/14802

PR: https://git.openjdk.org/jdk/pull/14802

From dl at openjdk.org  Sat Jul 22 10:44:49 2023
From: dl at openjdk.org (Doug Lea)
Date: Sat, 22 Jul 2023 10:44:49 GMT
Subject: Integrated: 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: <BgwV2nn_3ZCghEYmH9Taj1_2YeeWwfU585C_Dv1wTL4=.ec796de2-6e4a-4c52-8bef-4cf420fcd988@github.com>

On Mon, 5 Jun 2023 18:52:00 GMT, Doug Lea <dl at openjdk.org> wrote:

> This update addresses performance issues across both LinkedTransferQueue and SynchronousQueue by creating a common basis for implementation across them (mainly in LinkedTransferQueue).  Pasting from internal doc summary of changes:
>      * * Class DualNode replaces Qnode, with fields and methods
>      *   that apply to any match-based dual data structure, and now
>      *   usable in other j.u.c classes. in particular, SynchronousQueue.
>      * * Blocking control (in class DualNode) accommodates
>      *   VirtualThreads and (perhaps virtualized) uniprocessors.
>      * * All fields of this class (LinkedTransferQueue) are
>      *   default-initializable (to null), allowing further extension
>      *   (in particular, SynchronousQueue.Transferer)
>      * * Head and tail fields are lazily initialized rather than set
>      *   to a dummy node, while also reducing retries under heavy
>      *   contention and misorderings, and relaxing some accesses,
>      *   requiring accommodation in many places (as well as
>      *   adjustments in WhiteBox tests).

This pull request has now been integrated.

Changeset: 8d1ab570
Author:    Doug Lea <dl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d1ab57065c7ebcc650b5fb4ae098f8b0a35f112
Stats:     1714 lines in 3 files changed: 331 ins; 930 del; 453 mod

8301341: LinkedTransferQueue does not respect timeout for poll()
8300663: java/util/concurrent/SynchronousQueue/Fairness.java failed with "Error: fair=true i=0 j=1"
8267502: JDK-8246677 caused 16x performance regression in SynchronousQueue

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14317

From duke at openjdk.org  Sat Jul 22 12:13:10 2023
From: duke at openjdk.org (Cristian Vat)
Date: Sat, 22 Jul 2023 12:13:10 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v2]
In-Reply-To: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
Message-ID: <PsTu5E6ACWA3qBtfWidauo_1uCFAQ7S7xZPjeVMxTwU=.0e76e9ae-2ea7-4b5d-820d-a6b5d1eb46f1@github.com>

> Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.
> 
> Original clamping to 10 possibly due to documented behavior from javadoc: 
> "In this class, \1 through \9 are always interpreted as back references, "
> 
> Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
> Added a match failure condition in Pattern that fixes failing tests.
> 
> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"
> 
> A group that does not exist in the original Pattern can never match so neither can a backref to that group.
> If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
> So a group index outside groups array length must never match.

Cristian Vat has updated the pull request incrementally with one additional commit since the last revision:

  reduce allocations also for Matcher.usePattern

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14894/files
  - new: https://git.openjdk.org/jdk/pull/14894/files/a19ed81a..596eb3db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14894&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14894&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14894/head:pull/14894

PR: https://git.openjdk.org/jdk/pull/14894

From duke at openjdk.org  Sat Jul 22 12:29:39 2023
From: duke at openjdk.org (Cristian Vat)
Date: Sat, 22 Jul 2023 12:29:39 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v2]
In-Reply-To: <PsTu5E6ACWA3qBtfWidauo_1uCFAQ7S7xZPjeVMxTwU=.0e76e9ae-2ea7-4b5d-820d-a6b5d1eb46f1@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
 <PsTu5E6ACWA3qBtfWidauo_1uCFAQ7S7xZPjeVMxTwU=.0e76e9ae-2ea7-4b5d-820d-a6b5d1eb46f1@github.com>
Message-ID: <7myjXoEWtZpY72wO3xJ8qRYruiHjayOv0-4MoK9D7qs=.17db38c1-3457-4b13-81f0-f05fe7f3a805@github.com>

On Sat, 22 Jul 2023 12:13:10 GMT, Cristian Vat <duke at openjdk.org> wrote:

>> Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.
>> 
>> Original clamping to 10 possibly due to documented behavior from javadoc: 
>> "In this class, \1 through \9 are always interpreted as back references, "
>> 
>> Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
>> Added a match failure condition in Pattern that fixes failing tests.
>> 
>> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"
>> 
>> A group that does not exist in the original Pattern can never match so neither can a backref to that group.
>> If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
>> So a group index outside groups array length must never match.
>
> Cristian Vat has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce allocations also for Matcher.usePattern

updated to also reduce allocation in `java.util.regex.Matcher#usePattern`

all jdk_util tests passing

ran JMH `java.util.regex.FindPattern` test and times seem better but test is pretty light (large errors compared to avg score)

ran JMH with `-prof gc`:


Benchmark                                 (patternString)                                      (text)  Mode  Cnt    Score    Error   Units
FindPattern.testFind:?gc.alloc.rate.norm     [^A-Za-z0-9]  abcdefghijklmnop1234567890ABCDEFGHIJKLMNOP  avgt    3  207.999 ?  0.030    B/op
FindPattern.testFind:?gc.alloc.rate.norm     [^A-Za-z0-9]  ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,  avgt    3  208.000 ?  0.001    B/op
FindPattern.testFind:?gc.alloc.rate.norm      [A-Za-z0-9]  abcdefghijklmnop1234567890ABCDEFGHIJKLMNOP  avgt    3  207.861 ?  4.395    B/op
FindPattern.testFind:?gc.alloc.rate.norm      [A-Za-z0-9]  ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,  avgt    3  207.999 ?  0.031    B/op


Benchmark                                 (patternString)                                      (text)  Mode  Cnt    Score     Error   Units
FindPattern.testFind:?gc.alloc.rate.norm     [^A-Za-z0-9]  abcdefghijklmnop1234567890ABCDEFGHIJKLMNOP  avgt    3   56.181 ?   5.713    B/op
FindPattern.testFind:?gc.alloc.rate.norm     [^A-Za-z0-9]  ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,  avgt    3  136.000 ?   0.001    B/op
FindPattern.testFind:?gc.alloc.rate.norm      [A-Za-z0-9]  abcdefghijklmnop1234567890ABCDEFGHIJKLMNOP  avgt    3   56.000 ?   0.010    B/op
FindPattern.testFind:?gc.alloc.rate.norm      [A-Za-z0-9]  ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,  avgt    3  135.999 ?   0.028    B/op



As expected 72 byte/op reduction for case when pattern doesn't match.
Unexpected: seems double reduction in allocations for the case when pattern matches. Not completely sure where that is coming from. Maybe some optimizations in loops since these don't have groups and array is always 2 elements?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14894#issuecomment-1646572525

From vpetko at openjdk.org  Sat Jul 22 21:41:06 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Sat, 22 Jul 2023 21:41:06 GMT
Subject: RFR: 8312488: tools/jpackage/share/AppLauncherEnvTest.java fails
 with dynamically linked libstdc++ [v2]
In-Reply-To: <RMaWupHshwbpWmIsBXfRG9swzBbJ3nGeDiloyDJLiRk=.d1f80bff-3e44-4060-8958-3d4f0f1f63a3@github.com>
References: <RMaWupHshwbpWmIsBXfRG9swzBbJ3nGeDiloyDJLiRk=.d1f80bff-3e44-4060-8958-3d4f0f1f63a3@github.com>
Message-ID: <Y6aUOoLoQqkTfoDVSXxiNzt2brpty_-VEI8yq2DCnjU=.1667db55-f96d-4b74-8957-0d312426cc74@github.com>

> Use the  same approach as Logger::defaultLogger() to ensure that the appender is not destroyed before shared object destructor function is executed.
> 
> The alternative is to delete dcon() function, but we might run into a similiar tear-down issue later (e.g. logging from some object's destructor).
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/tools                                215   215     0     0   
> ==============================
> TEST SUCCESS

Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:

  copyright typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14971/files
  - new: https://git.openjdk.org/jdk/pull/14971/files/cd2e0ef0..5436f7d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14971&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14971&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14971/head:pull/14971

PR: https://git.openjdk.org/jdk/pull/14971

From vpetko at openjdk.org  Sat Jul 22 21:41:07 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Sat, 22 Jul 2023 21:41:07 GMT
Subject: RFR: 8312488: tools/jpackage/share/AppLauncherEnvTest.java fails
 with dynamically linked libstdc++ [v2]
In-Reply-To: <qjQ12NAwD-sH1J3uGTo39ZinI2yzwLsZYY04kLlw-yc=.2d00b9a7-d5ab-42f2-915c-d625fbf3df79@github.com>
References: <RMaWupHshwbpWmIsBXfRG9swzBbJ3nGeDiloyDJLiRk=.d1f80bff-3e44-4060-8958-3d4f0f1f63a3@github.com>
 <qjQ12NAwD-sH1J3uGTo39ZinI2yzwLsZYY04kLlw-yc=.2d00b9a7-d5ab-42f2-915c-d625fbf3df79@github.com>
Message-ID: <t5Rc8nyGFAEUN1wpqDF9zEEU8LQMicIWqX7yQTODMe0=.3c60a247-db2b-421b-95f4-b39f6c9ec7b4@github.com>

On Fri, 21 Jul 2023 20:52:32 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright typo
>
> src/jdk.jpackage/share/native/common/app.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, 2023 Oracle and/or its affiliates. All rights reserved.
> 
> Missing "," after 2023. Should be: "Copyright (c) 2020, 2023, Oracle and/or its affiliates.".

Thank you!!!! Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14971#discussion_r1271346382

From alanb at openjdk.org  Sun Jul 23 06:41:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 23 Jul 2023 06:41:47 GMT
Subject: [jdk21] RFR: 8309032: jpackage does not work for module projects
 unless --module-path is specified
In-Reply-To: <H9una8oci7mgFejlqQHPTMQjMXcHr8eG3A1dNMzUwjg=.24a2b5bb-0918-487f-8bec-c3809f6376c3@github.com>
References: <H9una8oci7mgFejlqQHPTMQjMXcHr8eG3A1dNMzUwjg=.24a2b5bb-0918-487f-8bec-c3809f6376c3@github.com>
Message-ID: <X0LNZgrIpfr8RFJNMAovT1_Lr1pJus9ChaQhOJdWNzg=.a279b12f-e979-4b39-8a2f-6fe61872f565@github.com>

On Thu, 20 Jul 2023 02:34:05 GMT, airsquared <duke at openjdk.org> wrote:

> 8309032: jpackage does not work for module projects unless --module-path is specified

JDK 21 is in rampdown phase two so only P1/P2 bugs (with approval) at this time, maybe this is one for JDK 21u instead.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/140#issuecomment-1646760599

From duke at openjdk.org  Mon Jul 24 09:02:47 2023
From: duke at openjdk.org (Benjamin Marwell)
Date: Mon, 24 Jul 2023 09:02:47 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: <X3umdU9CLMNZk667ZZLEsKmYl4fXZ7p4jxtvfv7Ztmw=.0d124aeb-7636-4c69-bdec-bc37cd60ce83@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)

Ping @shipilev as mentioned on Twitter ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11718#issuecomment-1647502579

From vtewari at openjdk.org  Mon Jul 24 09:18:40 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Mon, 24 Jul 2023 09:18:40 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available
In-Reply-To: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
Message-ID: <zMQNkK2EUBDbckG10CD4Yy_Bs1eYACqdSDqWeEKx1Po=.112a2094-c25c-45cd-9485-c032e9b3c042@github.com>

On Fri, 21 Jul 2023 22:40:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.

src/java.base/share/native/libjava/io_util.c line 99:

> 97:         return 0;
> 98:     } else if (len > BUF_SIZE) {
> 99:         if (len > MAX_MALLOC_SIZE)

Hi Brian if I am reading code correctly then with the current code change FIS.read(byte[] b, int off, int len) will always read (MAX_MALLOC_SIZE 2097152) bytes if len > MAX_MALLOC_SIZE. 

The java doc of read  as below

public?int?read(byte[]?b,
                int?off,
                int?len)
         throws IOException
Reads up to len bytes of data from the input stream into an array of bytes. An attempt is made to read as many as len bytes, but a smaller number may be read. The number of bytes actually read is returned as an integer.

I think  if you are limiting the internal dynamic buffer to 2097152 byte then you have  to at least attempt to read as many as len bytes if possible before returning.

If I simply the run the following code 

	    int size = 501 * 501 * 501 * 3;

            FileInputStream fis = new FileInputStream("/home/vyom1/test.img"); // Any file with size >= 501*501*501*2

            System.out.println("size: " + size);

            byte buf[] = new byte[size];

            System.out.println("buf ok");

            int bytesRead = fis.read(buf, 0, size);
            System.out.println("Bytes read " + bytesRead);

It will always print ?Bytes read 2097152? which is not as per Java specification of InputStream.read(byte[]b, int off, int len).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1271976654

From shade at openjdk.org  Mon Jul 24 09:31:45 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 24 Jul 2023 09:31:45 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: <wsbM_IpOlTlaRFjfwcBTgXvNQAcP0B5NshS_9AC_Qsk=.da8b685d-4569-417e-badd-238256aab8e0@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)

I guess it can be counted as micro-optimization, seeing that `Collections.enumeration` actually wraps the underlying `Iterator` into `Enumeration`, and this allows to use that `Iterator` directly in case of two-stream concatenation. The majority of JDK uses cases are 2-stream concats.

Minor nits:

src/java.base/share/classes/java/io/SequenceInputStream.java line 47:

> 45:  */
> 46: public class SequenceInputStream extends InputStream {
> 47:     private final Iterator<? extends InputStream> e;

Should be `iter` now, not `e`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/11718#pullrequestreview-1543054058
PR Review Comment: https://git.openjdk.org/jdk/pull/11718#discussion_r1271984209

From shade at openjdk.org  Mon Jul 24 09:34:41 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 24 Jul 2023 09:34:41 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: <lo8ppdbb-Cd2kkC4t7Ql1kb3RynvP9m0eQ4SaGdhxF0=.839d5a25-5801-4856-af0e-8bb6924c55e2@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)

Also, please go to https://github.com/rmannibucau/jdk/actions and enabled the testing workflows.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11718#issuecomment-1647556125

From pminborg at openjdk.org  Mon Jul 24 09:58:50 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 24 Jul 2023 09:58:50 GMT
Subject: RFR: JDK-8311822: AIX : test/jdk/java/foreign/TestLayouts.java fails
 because of different output - expected [[i4](struct)] but found
 [[I4](struct)]
Message-ID: <3GkWQ2ZAfpEE8E_sO1d7OkRI1ZozanduTEo1c9p6_fw=.74357f71-f25f-4817-b2ef-c6301c5f8208@github.com>

This PR suggests making a test independent of the underlying platform byte ordering and to test both ordering variants rather than just one.

-------------

Commit messages:
 - Make test independent of platform byte ordering

Changes: https://git.openjdk.org/jdk/pull/14994/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14994&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311822
  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14994.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14994/head:pull/14994

PR: https://git.openjdk.org/jdk/pull/14994

From pminborg at openjdk.org  Mon Jul 24 12:38:57 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 24 Jul 2023 12:38:57 GMT
Subject: RFR: 8298095: Refine implSpec for SegmentAllocator
Message-ID: <MYKIf86teO-EoEjeqII6aRsex4ZBxS9bOAQHRS5c59o=.39a950db-d4e6-40a8-bd40-80822fea06da@github.com>

This PR suggests refining the `@implSpec` for the SegmentAllocator::allocate methods as well as clarifying the docs a bit more. Also, a local variable is renamed.

-------------

Commit messages:
 - Improve javadocs
 - Update javadocs for SegmentAllocator::allocate methods

Changes: https://git.openjdk.org/jdk/pull/14997/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14997&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298095
  Stats: 105 lines in 1 file changed: 48 ins; 8 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/14997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14997/head:pull/14997

PR: https://git.openjdk.org/jdk/pull/14997

From alanb at openjdk.org  Mon Jul 24 13:19:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 24 Jul 2023 13:19:42 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available
In-Reply-To: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
Message-ID: <p-UNQRGHEN3aUQTyJljJBcH_gz_N8alzc4yp_jixWDk=.25d9352b-2e8f-4b19-9083-7d1f77e14cf0@github.com>

On Fri, 21 Jul 2023 22:40:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.

src/java.base/share/classes/java/io/FileOutputStream.java line 366:

> 364:                 int n = writeBytes(b, off, len, append);
> 365:                 if (n == -1)
> 366:                     break;

Checking if n is -1 doesn't look right here. Isn't return -1 just to keep the compiler happy when an exception is thrown.

src/java.base/share/native/libjava/io_util.c line 62:

> 60: /* The maximum size of a dynamically-allocated buffer.
> 61:  */
> 62: #define MAX_MALLOC_SIZE 2097152

How did you choose 2Mb, it seems high.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1272230776
PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1272250651

From alanb at openjdk.org  Mon Jul 24 13:19:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 24 Jul 2023 13:19:45 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available
In-Reply-To: <zMQNkK2EUBDbckG10CD4Yy_Bs1eYACqdSDqWeEKx1Po=.112a2094-c25c-45cd-9485-c032e9b3c042@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <zMQNkK2EUBDbckG10CD4Yy_Bs1eYACqdSDqWeEKx1Po=.112a2094-c25c-45cd-9485-c032e9b3c042@github.com>
Message-ID: <tB7cOCs5Ou8EBcmXkKYalC7eVhatB6VXIozTTIYTLGM=.f9e3763d-013d-4213-b471-98a0e7723526@github.com>

On Mon, 24 Jul 2023 09:16:23 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.
>
> src/java.base/share/native/libjava/io_util.c line 99:
> 
>> 97:         return 0;
>> 98:     } else if (len > BUF_SIZE) {
>> 99:         if (len > MAX_MALLOC_SIZE)
> 
> Hi Brian if I am reading code correctly then with the current code change FIS.read(byte[] b, int off, int len) will always read (MAX_MALLOC_SIZE 2097152) bytes if len > MAX_MALLOC_SIZE. 
> 
> The java doc of read  as below
> 
> public?int?read(byte[]?b,
>                 int?off,
>                 int?len)
>          throws IOException
> Reads up to len bytes of data from the input stream into an array of bytes. An attempt is made to read as many as len bytes, but a smaller number may be read. The number of bytes actually read is returned as an integer.
> 
> I think  if you are limiting the internal dynamic buffer to 2097152 byte then you have  to at least attempt to read as many as len bytes if possible before returning.
> 
> If I simply the run the following code 
> 
> 	    int size = 501 * 501 * 501 * 3;
> 
>             FileInputStream fis = new FileInputStream("/home/vyom1/test.img"); // Any file with size >= 501*501*501*2
> 
>             System.out.println("size: " + size);
> 
>             byte buf[] = new byte[size];
> 
>             System.out.println("buf ok");
> 
>             int bytesRead = fis.read(buf, 0, size);
>             System.out.println("Bytes read " + bytesRead);
> 
> It will always print ?Bytes read 2097152? which is not as per Java specification of InputStream.read(byte[]b, int off, int len).

A short read is okay but changing long standing behavior could potentially break already broken code that calls the method with a large byte array and assumes it will read to EOF. So I think it's a forced move to read until there is no space remaining or EOF is reached. This is logic for the Java level, not the native code of course. If an I/O exception is on the second/subsequent reads then it will have to return the bytes that are read, not throw with bytes in the buffer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1272236807

From amitkumar at openjdk.org  Mon Jul 24 13:31:47 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 24 Jul 2023 13:31:47 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <4-SkKe526mi_69V5zOsgHsLNTp1_vHzNaPFJluPXppM=.4ed68247-ac70-41b1-a4b6-e0daf864ab9f@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
 <4-SkKe526mi_69V5zOsgHsLNTp1_vHzNaPFJluPXppM=.4ed68247-ac70-41b1-a4b6-e0daf864ab9f@github.com>
Message-ID: <UF-LXjX9pIS_512oQwZA6vJm6vVoM91JPLyaEphAWTA=.00807458-3439-4655-b7f6-a391649d150d@github.com>

On Sat, 22 Jul 2023 06:13:01 GMT, sid8606 <duke at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address suggestions from Jorn Vernee
>
> I have narrowed down the issue failing on  glibc 2.31 but passes on glibc 2.35 on s390x. 
>  **test_time** test method is failing in StdLibTest.java.
> @JornVernee test_printf test method is passing as it is.

@sid8606, there is separate PR #14994 submitted for TestLayouts.java for handling the endian-ness issue. You may want to restore it from here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14801#issuecomment-1647910965

From pminborg at openjdk.org  Mon Jul 24 13:32:58 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 24 Jul 2023 13:32:58 GMT
Subject: RFR: 8298095: Refine implSpec for SegmentAllocator [v2]
In-Reply-To: <MYKIf86teO-EoEjeqII6aRsex4ZBxS9bOAQHRS5c59o=.39a950db-d4e6-40a8-bd40-80822fea06da@github.com>
References: <MYKIf86teO-EoEjeqII6aRsex4ZBxS9bOAQHRS5c59o=.39a950db-d4e6-40a8-bd40-80822fea06da@github.com>
Message-ID: <dTtP5HR9c-EqFkoq7SXYYLGMoVXXwFhW0jIyLeV23D4=.505e5ea9-9bcb-4d9b-b57f-c915b350cbbc@github.com>

> This PR suggests refining the `@implSpec` for the SegmentAllocator::allocate methods as well as clarifying the docs a bit more. Also, a local variable is renamed.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update array methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14997/files
  - new: https://git.openjdk.org/jdk/pull/14997/files/1154344d..e4d0a4bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14997&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14997&range=00-01

  Stats: 92 lines in 1 file changed: 49 ins; 7 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/14997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14997/head:pull/14997

PR: https://git.openjdk.org/jdk/pull/14997

From jvernee at openjdk.org  Mon Jul 24 13:38:41 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 24 Jul 2023 13:38:41 GMT
Subject: RFR: JDK-8311822: AIX : test/jdk/java/foreign/TestLayouts.java
 fails because of different output - expected [[i4](struct)] but found
 [[I4](struct)]
In-Reply-To: <3GkWQ2ZAfpEE8E_sO1d7OkRI1ZozanduTEo1c9p6_fw=.74357f71-f25f-4817-b2ef-c6301c5f8208@github.com>
References: <3GkWQ2ZAfpEE8E_sO1d7OkRI1ZozanduTEo1c9p6_fw=.74357f71-f25f-4817-b2ef-c6301c5f8208@github.com>
Message-ID: <N7jeb0NpasL5_HOZ-daM7bi2zPC8vnbGRRWMnBBFp30=.172930ce-edb9-4b25-87f4-5740f58b044d@github.com>

On Mon, 24 Jul 2023 09:51:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests making a test independent of the underlying platform byte ordering and to test both ordering variants rather than just one.

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14994#pullrequestreview-1543507248

From mbaesken at openjdk.org  Mon Jul 24 13:57:40 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Jul 2023 13:57:40 GMT
Subject: RFR: JDK-8311822: AIX : test/jdk/java/foreign/TestLayouts.java
 fails because of different output - expected [[i4](struct)] but found
 [[I4](struct)]
In-Reply-To: <3GkWQ2ZAfpEE8E_sO1d7OkRI1ZozanduTEo1c9p6_fw=.74357f71-f25f-4817-b2ef-c6301c5f8208@github.com>
References: <3GkWQ2ZAfpEE8E_sO1d7OkRI1ZozanduTEo1c9p6_fw=.74357f71-f25f-4817-b2ef-c6301c5f8208@github.com>
Message-ID: <t9BRZttDUZKGUCk_jXp5MtY9UTqDujKbOB-KQ5hSvTA=.0b0170c4-87e4-4192-9bb9-e1657b5bcda5@github.com>

On Mon, 24 Jul 2023 09:51:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests making a test independent of the underlying platform byte ordering and to test both ordering variants rather than just one.

Hi Per-Ake, I put this patch into our internal test queue to see how it works on AIX.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14994#issuecomment-1647966305

From pminborg at openjdk.org  Mon Jul 24 15:03:48 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 24 Jul 2023 15:03:48 GMT
Subject: Integrated: JDK-8311822: AIX : test/jdk/java/foreign/TestLayouts.java
 fails because of different output - expected [[i4](struct)] but found
 [[I4](struct)]
In-Reply-To: <3GkWQ2ZAfpEE8E_sO1d7OkRI1ZozanduTEo1c9p6_fw=.74357f71-f25f-4817-b2ef-c6301c5f8208@github.com>
References: <3GkWQ2ZAfpEE8E_sO1d7OkRI1ZozanduTEo1c9p6_fw=.74357f71-f25f-4817-b2ef-c6301c5f8208@github.com>
Message-ID: <zJsBcztNAG1SlbEideRPE5YO6OSslRE8XF8nFMgwVKw=.573299fd-0af8-4e03-bdfe-1762c1a3afc1@github.com>

On Mon, 24 Jul 2023 09:51:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests making a test independent of the underlying platform byte ordering and to test both ordering variants rather than just one.

This pull request has now been integrated.

Changeset: d1cc2782
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d1cc2782606e8a3cfead9055aa845e48e851edd4
Stats:     7 lines in 1 file changed: 3 ins; 0 del; 4 mod

8311822: AIX : test/jdk/java/foreign/TestLayouts.java fails because of different output - expected [[i4](struct)] but found [[I4](struct)]

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/14994

From mcimadamore at openjdk.org  Mon Jul 24 15:09:42 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 24 Jul 2023 15:09:42 GMT
Subject: RFR: 8298095: Refine implSpec for SegmentAllocator [v2]
In-Reply-To: <dTtP5HR9c-EqFkoq7SXYYLGMoVXXwFhW0jIyLeV23D4=.505e5ea9-9bcb-4d9b-b57f-c915b350cbbc@github.com>
References: <MYKIf86teO-EoEjeqII6aRsex4ZBxS9bOAQHRS5c59o=.39a950db-d4e6-40a8-bd40-80822fea06da@github.com>
 <dTtP5HR9c-EqFkoq7SXYYLGMoVXXwFhW0jIyLeV23D4=.505e5ea9-9bcb-4d9b-b57f-c915b350cbbc@github.com>
Message-ID: <cEYS_JeyVI2wby4HJgXab8thlI747VEDsa0xtA3MXzc=.478e528a-9bdb-4bbf-8e20-3aa71bcdedb0@github.com>

On Mon, 24 Jul 2023 13:32:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests refining the `@implSpec` for the SegmentAllocator::allocate methods as well as clarifying the docs a bit more. Also, a local variable is renamed.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update array methods

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 104:

> 102: 
> 103:     /**
> 104:      * {@return a newly allocated memory segment with a {@linkplain MemorySegment#byteSize() byteSize()} of 1

The emphasis of "newly allocated" is IMHO wrong (although that was there even before). Recycling allocators do not "allocate" - so we should make this more neutral. Perhaps just "return a new memory segment..."

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 107:

> 105:      * initialized with the provided byte {@code value}}.
> 106:      *
> 107:      * @implSpec The default implementation of this method first calls {@code this.allocate(layout)} to

would it be useful to describe what the implementation does in terms of code, rather than narrative text?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14997#discussion_r1272396488
PR Review Comment: https://git.openjdk.org/jdk/pull/14997#discussion_r1272395128

From mcimadamore at openjdk.org  Mon Jul 24 15:15:42 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 24 Jul 2023 15:15:42 GMT
Subject: RFR: 8298095: Refine implSpec for SegmentAllocator [v2]
In-Reply-To: <dTtP5HR9c-EqFkoq7SXYYLGMoVXXwFhW0jIyLeV23D4=.505e5ea9-9bcb-4d9b-b57f-c915b350cbbc@github.com>
References: <MYKIf86teO-EoEjeqII6aRsex4ZBxS9bOAQHRS5c59o=.39a950db-d4e6-40a8-bd40-80822fea06da@github.com>
 <dTtP5HR9c-EqFkoq7SXYYLGMoVXXwFhW0jIyLeV23D4=.505e5ea9-9bcb-4d9b-b57f-c915b350cbbc@github.com>
Message-ID: <dFDnLMEte-r-S7z7tkVosa799km3eQYTnPcOsj-PDUc=.c55bcd56-00cf-4dd5-a080-dcdf44ab9f81@github.com>

On Mon, 24 Jul 2023 13:32:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests refining the `@implSpec` for the SegmentAllocator::allocate methods as well as clarifying the docs a bit more. Also, a local variable is renamed.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update array methods

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 223:

> 221: 
> 222:     /**
> 223:      * {@return a newly allocated memory segment with a {@linkplain MemorySegment#byteSize() byteSize()} of 4

Size should be 8 here - but in general I think I'd rather leave it more general and not to specify sizes. The reader should be able to follow the javadoc, and get that we end up calling `allocate(long, long)` with certain parameters (which are derived from the layout). I don't think being extra precise here helps - and also opens up to issues: note that the alignment of double/long layout constants is platform-specific, which I don't think you want to get into here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14997#discussion_r1272403749

From ecki at zusammenkunft.net  Mon Jul 24 15:33:31 2023
From: ecki at zusammenkunft.net (Bernd)
Date: Mon, 24 Jul 2023 17:33:31 +0200
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError
 when there is plenty available
In-Reply-To: <tB7cOCs5Ou8EBcmXkKYalC7eVhatB6VXIozTTIYTLGM=.f9e3763d-013d-4213-b471-98a0e7723526@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <zMQNkK2EUBDbckG10CD4Yy_Bs1eYACqdSDqWeEKx1Po=.112a2094-c25c-45cd-9485-c032e9b3c042@github.com>,
 <tB7cOCs5Ou8EBcmXkKYalC7eVhatB6VXIozTTIYTLGM=.f9e3763d-013d-4213-b471-98a0e7723526@github.com>
Message-ID: <65CB143B-81BD-9D4B-90CE-C4A1E7AC90A0@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230724/2f814319/attachment.htm>

From coffeys at openjdk.org  Mon Jul 24 16:08:55 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 24 Jul 2023 16:08:55 GMT
Subject: RFR: 8311653: Modify -XshowSettings launcher behavior
Message-ID: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>

Modify the -XshowSettings launcher option to print non-verbose settings details of all components by default. Verbose settings details will be printed via the -XshowSettings:all option. Modify the -XshowSettings option to reject bad values passed to it. Print an error message in such scenarios and abort the VM launch.

-------------

Commit messages:
 - restore imports
 - Abort if bad options input
 - 8311653

Changes: https://git.openjdk.org/jdk/pull/15001/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15001&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311653
  Stats: 142 lines in 4 files changed: 72 ins; 35 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/15001.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15001/head:pull/15001

PR: https://git.openjdk.org/jdk/pull/15001

From duke at openjdk.org  Mon Jul 24 16:25:54 2023
From: duke at openjdk.org (yaqsun)
Date: Mon, 24 Jul 2023 16:25:54 GMT
Subject: Integrated: 8311631: When multiple users run
 tools/jpackage/share/LicenseTest.java,
 Permission denied for writing /var/tmp/*.files
In-Reply-To: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
References: <myIr4AqnvT35oMjIQCiBR5EjGeoWdN6RsmL5fzbpV-o=.90e75181-579c-4dfb-9518-99d6c73eb524@github.com>
Message-ID: <gBLSAMlTkA7hNgkiuQ6u22FYjih76zWzy6mUZJ0JbAQ=.c77d9f65-b5f9-487f-acd5-69b6ef805fc7@github.com>

On Fri, 7 Jul 2023 09:51:23 GMT, yaqsun <duke at openjdk.org> wrote:

> The prerequisite is to install the rpmbuild command, when multiple users switch to write /var/tmp/*.files will have the permission forbidden.

This pull request has now been integrated.

Changeset: fac9f88c
Author:    sunyaqi <sunyaqi at loongson.cn>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fac9f88c52a07d972bad48d9ec116cb7e0fc5052
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8311631: When multiple users run tools/jpackage/share/LicenseTest.java, Permission denied for writing /var/tmp/*.files

Reviewed-by: asemenyuk, almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/14802

From stsypanov at openjdk.org  Mon Jul 24 16:27:50 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 24 Jul 2023 16:27:50 GMT
Subject: Integrated: 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: <k4zUa9e6JwVSvqwv3im2uz2DRs3O7KBXrZuxjgROOBc=.4961d5b4-a682-470d-acd0-bf5d150325f8@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

This pull request has now been integrated.

Changeset: d8f2e9ae
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8f2e9ae3b47b27e51680d88b774183cd156b073
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8310530: PipedOutputStream.flush() accesses sink racily

Reviewed-by: dfuchs, bpb, liach, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/14589

From asemenyuk at openjdk.org  Mon Jul 24 16:28:40 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 24 Jul 2023 16:28:40 GMT
Subject: RFR: 8312488: tools/jpackage/share/AppLauncherEnvTest.java fails
 with dynamically linked libstdc++ [v2]
In-Reply-To: <Y6aUOoLoQqkTfoDVSXxiNzt2brpty_-VEI8yq2DCnjU=.1667db55-f96d-4b74-8957-0d312426cc74@github.com>
References: <RMaWupHshwbpWmIsBXfRG9swzBbJ3nGeDiloyDJLiRk=.d1f80bff-3e44-4060-8958-3d4f0f1f63a3@github.com>
 <Y6aUOoLoQqkTfoDVSXxiNzt2brpty_-VEI8yq2DCnjU=.1667db55-f96d-4b74-8957-0d312426cc74@github.com>
Message-ID: <zvzfnH2OFmYfi-1r4CCJhjAfGH9yDlZ0yC0gn5UnOBI=.4f29d6a8-b78a-4142-9a83-5293bbef29ef@github.com>

On Sat, 22 Jul 2023 21:41:06 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> Use the  same approach as Logger::defaultLogger() to ensure that the appender is not destroyed before shared object destructor function is executed.
>> 
>> The alternative is to delete dcon() function, but we might run into a similiar tear-down issue later (e.g. logging from some object's destructor).
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/tools                                215   215     0     0   
>> ==============================
>> TEST SUCCESS
>
> Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright typo

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14971#pullrequestreview-1543850268

From almatvee at openjdk.org  Mon Jul 24 17:06:41 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 24 Jul 2023 17:06:41 GMT
Subject: RFR: 8312488: tools/jpackage/share/AppLauncherEnvTest.java fails
 with dynamically linked libstdc++ [v2]
In-Reply-To: <Y6aUOoLoQqkTfoDVSXxiNzt2brpty_-VEI8yq2DCnjU=.1667db55-f96d-4b74-8957-0d312426cc74@github.com>
References: <RMaWupHshwbpWmIsBXfRG9swzBbJ3nGeDiloyDJLiRk=.d1f80bff-3e44-4060-8958-3d4f0f1f63a3@github.com>
 <Y6aUOoLoQqkTfoDVSXxiNzt2brpty_-VEI8yq2DCnjU=.1667db55-f96d-4b74-8957-0d312426cc74@github.com>
Message-ID: <QVUmDaJj79KQAcHRC-rNxdWCy2VhK21QaPh3bJiC38U=.5a89e10e-3db0-4adc-bb3e-e0478156196f@github.com>

On Sat, 22 Jul 2023 21:41:06 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> Use the  same approach as Logger::defaultLogger() to ensure that the appender is not destroyed before shared object destructor function is executed.
>> 
>> The alternative is to delete dcon() function, but we might run into a similiar tear-down issue later (e.g. logging from some object's destructor).
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/tools                                215   215     0     0   
>> ==============================
>> TEST SUCCESS
>
> Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright typo

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14971#pullrequestreview-1543908185

From alanb at openjdk.org  Mon Jul 24 18:30:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 24 Jul 2023 18:30:41 GMT
Subject: RFR: 8311653: Modify -XshowSettings launcher behavior
In-Reply-To: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
References: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
Message-ID: <ipQzseTSyuGXBBPe7ULzaZDexvr0JKvpZ7l43fyShZE=.2c2c117f-a558-4d98-983f-12c508dfe02b@github.com>

On Mon, 24 Jul 2023 16:00:52 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Modify the -XshowSettings launcher option to print non-verbose settings details of all components by default. Verbose settings details will be printed via the -XshowSettings:all option. Modify the -XshowSettings option to reject bad values passed to it. Print an error message in such scenarios and abort the VM launch.

This looks quit good,  I'm just wondering about the usage messages for -XshowSetting and -XshowSetting:all as they both say "show all settings and continue". I think we'll need to adjust the first one to say that it just shows a summary of the settings.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15001#issuecomment-1648395988

From alanb at openjdk.org  Mon Jul 24 18:37:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 24 Jul 2023 18:37:56 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should return
 TIMED_WAITING virtual thread is timed parked
Message-ID: <Ar-k3n5Awr02ccVZvwJkL9VyUVnHZbKW0ln9K5oZmp0=.98dfd87b-a04a-4fae-ad90-055131d8438e@github.com>

Thread::getState is an API for monitoring and management purposes to report the thread state. If a virtual thread is parked with LockSupport.parkNanos, its state is reported as  WAITING when it should be TIMED_WAITING. JVM TI GetThreadState has the same issue in that it returns JVMTI_THREAD_STATE_WAITING_INDEFINITELY instead of the JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT bit set. Not a very visible issue because JDWP maps both states to "WAIT" but it may be noticed by tools using other JVM TI agents.

The change is straight-forward, it's just additional state bit to indicate that park is timed. The existing virtual/ThreadAPI.java test is expanded to this scenario. A new test is added for JVM TI GetThreadState to test waiting/timed-waited cases (including pinned) as test coverage seems patchy here.

-------------

Commit messages:
 - Remove tab
 - Cleanup comments
 - Merge
 - Spurious tab
 - Test improvements
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14978/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14978&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312498
  Stats: 729 lines in 9 files changed: 647 ins; 41 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/14978.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14978/head:pull/14978

PR: https://git.openjdk.org/jdk/pull/14978

From mchung at openjdk.org  Mon Jul 24 18:50:46 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 24 Jul 2023 18:50:46 GMT
Subject: RFR: 8311653: Modify -XshowSettings launcher behavior
In-Reply-To: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
References: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
Message-ID: <HDE3yOv-LN_453Y5kCeRe3RGVYuXsc1y8M_6z1kMios=.01b2bf2c-539f-405d-8897-7db4df8cbeb4@github.com>

On Mon, 24 Jul 2023 16:00:52 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Modify the -XshowSettings launcher option to print non-verbose settings details of all components by default. Verbose settings details will be printed via the -XshowSettings:all option. Modify the -XshowSettings option to reject bad values passed to it. Print an error message in such scenarios and abort the VM launch.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 156:

> 154:         initOutput(printToStderr);
> 155:         String[] opts = optionFlag.split(":");
> 156:         String optStr = Arrays.stream(opts).skip(1).findFirst().orElse("").trim();

`-XshowSettings:locale:junk` should abort but `printLocale` will be called instead.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 322:

> 320:         // only Linux supported
> 321:         if (!OperatingSystem.isLinux()) {
> 322:             abort(null, "java.launcher.bad.option");

Suggestion:

            abort(null, "java.launcher.bad.option", "system");


maybe the `isLinux` check can be moved to `showSettings` and fall through to abort with the unmatched case.

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 233:

> 231: Unrecognized showSettings option: {0}.\n\
> 232:     Valid values are \"all\", \"locale\", \"properties\",\"security\",\
> 233:     \"system\"(Linux only), \"vm\".\n\

Nit:  space after commas missing.
Suggestion:

    Valid values are "all", "locale", "properties", "security", \
    "system"(Linux only), "vm".\n\

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15001#discussion_r1272628881
PR Review Comment: https://git.openjdk.org/jdk/pull/15001#discussion_r1272615445
PR Review Comment: https://git.openjdk.org/jdk/pull/15001#discussion_r1272611276

From rriggs at openjdk.org  Mon Jul 24 19:00:49 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 24 Jul 2023 19:00:49 GMT
Subject: RFR: 8311653: Modify -XshowSettings launcher behavior
In-Reply-To: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
References: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
Message-ID: <R34rjRXbwZegir2RNlWv8r15-EMajohkRjO5HjbPUjg=.3a09dfdc-b5be-4b6e-91eb-a91eab28615b@github.com>

On Mon, 24 Jul 2023 16:00:52 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Modify the -XshowSettings launcher option to print non-verbose settings details of all components by default. Verbose settings details will be printed via the -XshowSettings:all option. Modify the -XshowSettings option to reject bad values passed to it. Print an error message in such scenarios and abort the VM launch.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 132:

> 130:      *
> 131:      * suboption values include "all", "locale", "properties", "security",
> 132:      * "system"(Linux only) and "vm". Help message printed for bad value.

Suggestion:

     * Suboption values include "all", "locale", "properties", "security",
     * "system" (Linux only) and "vm". A help message is printed for an unknown suboption value.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 164:

> 162:             case "system" -> printSystemMetrics();
> 163:             case "vm" -> printVmSettings(initialHeapSize, maxHeapSize, stackSize);
> 164:             case "" -> printAllSettings(false, initialHeapSize, maxHeapSize, stackSize);

There's mix in the arguments of where the "verbose" option is included.
Can they be consistent?  (For example put the verbose option as the last argument).

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 170:

> 168: 
> 169:     /*
> 170:      * prints all available settings. Verbose option.

Don't take too many shortcuts in writing the description. Complete sentences are nice.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15001#discussion_r1272622823
PR Review Comment: https://git.openjdk.org/jdk/pull/15001#discussion_r1272627486
PR Review Comment: https://git.openjdk.org/jdk/pull/15001#discussion_r1272630327

From brian.burkhalter at oracle.com  Mon Jul 24 20:37:56 2023
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 24 Jul 2023 20:37:56 +0000
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available
In-Reply-To: <65CB143B-81BD-9D4B-90CE-C4A1E7AC90A0@hxcore.ol>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <zMQNkK2EUBDbckG10CD4Yy_Bs1eYACqdSDqWeEKx1Po=.112a2094-c25c-45cd-9485-c032e9b3c042@github.com>
 <tB7cOCs5Ou8EBcmXkKYalC7eVhatB6VXIozTTIYTLGM=.f9e3763d-013d-4213-b471-98a0e7723526@github.com>
 <65CB143B-81BD-9D4B-90CE-C4A1E7AC90A0@hxcore.ol>
Message-ID: <E10DF392-7514-4C81-98E6-A29A9E36CA9A@oracle.com>

I think the idea is to treat an IOException thrown by any but the first invocation of readBytes() as equivalent to end-of-file such as described for InputStream::read(byte[],int,int)<https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/io/InputStream.html#read(byte%5B%5D,int,int)> with respect to its invocation of InputStream::read()<https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/io/InputStream.html#read()>.

On Jul 24, 2023, at 8:33 AM, Bernd <ecki at zusammenkunft.net<mailto:ecki at zusammenkunft.net>> wrote:

If you return the short buffer (on IOException), does it need to cache the pending exception or can you just rely on the next read hitting that underlying exception again? (Is there an actual guarantee somewhere that the read position is not altered on IOExceptions or that you always get lending bytes before this report? (If so, does the native code do that as well?)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230724/5df088ff/attachment-0001.htm>

From matsaave at openjdk.org  Mon Jul 24 21:20:42 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 24 Jul 2023 21:20:42 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
In-Reply-To: <cbhFq3ORQfMDCabfcDgjnqRUyBiRG3dlDbxUZiFFNjA=.50d4ccce-327b-48c4-866b-67dd144fa030@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
 <cbhFq3ORQfMDCabfcDgjnqRUyBiRG3dlDbxUZiFFNjA=.50d4ccce-327b-48c4-866b-67dd144fa030@github.com>
Message-ID: <xV0twUc2XLO0g2STijTENgpVX5wmcfszGJkjhZpautA=.f10d395c-e71c-44ee-81f0-8c88efb64fe8@github.com>

On Mon, 17 Jul 2023 16:55:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 
>> 
>> 
>>  // We have finished dumping the static archive. At this point, there may be pending VM
>>  // operations. We have changed some global states (such as vmClasses::_klasses) that
>>  // may cause these VM operations to fail. For safety, forget these operations and
>>  // exit the VM directly.
>>  void MetaspaceShared::exit_after_static_dump() {
>>    os::_exit(0);
>>  } 
>> 
>> 
>> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
>> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
>> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
>> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.
>
> src/hotspot/share/classfile/classLoaderData.cpp line 1085:
> 
>> 1083:     guarantee(this == class_loader_data(cl) || has_class_mirror_holder(), "Must be the same");
>> 1084:     guarantee(cl != nullptr || this == ClassLoaderData::the_null_class_loader_data() || has_class_mirror_holder(), "must be");
>> 1085:   }
> 
> Why is this necessary?

This seems to be a band-aid solution to a deeper problem: the java platform and system loaders are reset. I believe the correct solution is to restore these values after dumping completes

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1272766119

From liach at openjdk.org  Mon Jul 24 21:27:47 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Jul 2023 21:27:47 GMT
Subject: Withdrawn: 8312486: Allow abstract classes for
 MethodHandleProxies::asInterfaceInstance
In-Reply-To: <v8BUgB-cm0BNnEzDc-iXfwcdJ-yUIfF_ZZB5CbIpXRY=.40d4e14e-d3a6-45b3-886d-764e544c99b2@github.com>
References: <v8BUgB-cm0BNnEzDc-iXfwcdJ-yUIfF_ZZB5CbIpXRY=.40d4e14e-d3a6-45b3-886d-764e544c99b2@github.com>
Message-ID: <29U3XJixj_Z8R21qYIQy_pSI3FlFff4mxNjFgbgQ1Qo=.f2ace19e-f8ed-42a0-b91b-d1b0657eaf85@github.com>

On Thu, 20 Jul 2023 23:50:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> With the reimplementation of MHP.asIFInstance, now it can easily adapt to abstract classes as well. Repurposed PublicMethods from java.lang to track method inheritance for MHP to reduce redundancies.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14966

From bpb at openjdk.org  Tue Jul 25 02:08:42 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 25 Jul 2023 02:08:42 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available
In-Reply-To: <p-UNQRGHEN3aUQTyJljJBcH_gz_N8alzc4yp_jixWDk=.25d9352b-2e8f-4b19-9083-7d1f77e14cf0@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <p-UNQRGHEN3aUQTyJljJBcH_gz_N8alzc4yp_jixWDk=.25d9352b-2e8f-4b19-9083-7d1f77e14cf0@github.com>
Message-ID: <FDmB78T3fQEDYQ5A2t90zsdGHpcMw5bmwfQorqdSpOM=.3151ea03-78b0-4b9f-8017-39b2cbacc170@github.com>

On Mon, 24 Jul 2023 12:59:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.
>
> src/java.base/share/classes/java/io/FileOutputStream.java line 366:
> 
>> 364:                 int n = writeBytes(b, off, len, append);
>> 365:                 if (n == -1)
>> 366:                     break;
> 
> Checking if n is -1 doesn't look right here. Isn't return -1 just to keep the compiler happy when an exception is thrown.

This is a copy-paste vestige; will remove.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1272919429

From bpb at openjdk.org  Tue Jul 25 02:12:52 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 25 Jul 2023 02:12:52 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available
In-Reply-To: <p-UNQRGHEN3aUQTyJljJBcH_gz_N8alzc4yp_jixWDk=.25d9352b-2e8f-4b19-9083-7d1f77e14cf0@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <p-UNQRGHEN3aUQTyJljJBcH_gz_N8alzc4yp_jixWDk=.25d9352b-2e8f-4b19-9083-7d1f77e14cf0@github.com>
Message-ID: <6XShzHu2amAup0TTtPTFTkZMdVVjU1Pr4N2RefUgYmw=.ed3432c4-7376-4295-b9bf-f4709eecd986@github.com>

On Mon, 24 Jul 2023 13:16:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.
>
> src/java.base/share/native/libjava/io_util.c line 62:
> 
>> 60: /* The maximum size of a dynamically-allocated buffer.
>> 61:  */
>> 62: #define MAX_MALLOC_SIZE 2097152
> 
> How did you choose 2Mb, it seems high.

It's based on micro-benchmarks. Having the loops in Java reduces throughput but allocating memory using `malloc(len)` also reduces throughput as `len` gets larger and this threshold appears to balance the two.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1272921060

From dholmes at openjdk.org  Tue Jul 25 05:24:42 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 25 Jul 2023 05:24:42 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked
In-Reply-To: <Ar-k3n5Awr02ccVZvwJkL9VyUVnHZbKW0ln9K5oZmp0=.98dfd87b-a04a-4fae-ad90-055131d8438e@github.com>
References: <Ar-k3n5Awr02ccVZvwJkL9VyUVnHZbKW0ln9K5oZmp0=.98dfd87b-a04a-4fae-ad90-055131d8438e@github.com>
Message-ID: <2rTLX86raFjJBNOlUysJoxGB8UaGLH7szSa_EOmXEDE=.e545fc08-9354-4173-b88f-b8173c3878b7@github.com>

On Fri, 21 Jul 2023 18:01:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread::getState is an API for monitoring and management purposes to report the thread state. If a virtual thread is parked with LockSupport.parkNanos, its state is reported as  WAITING when it should be TIMED_WAITING. JVM TI GetThreadState has the same issue in that it returns JVMTI_THREAD_STATE_WAITING_INDEFINITELY instead of the JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT bit set. Not a very visible issue because JDWP maps both states to "WAIT" but it may be noticed by tools using other JVM TI agents.
> 
> The change is straight-forward, it's just additional state bit to indicate that park is timed. The existing virtual/ThreadAPI.java test is expanded to this scenario. A new test is added for JVM TI GetThreadState to test waiting/timed-waited cases (including pinned) as test coverage seems patchy here.

src/hotspot/share/classfile/javaClasses.hpp line 536:

> 534: 
> 535:     // additional state bits
> 536:     TIMED        = 1 << 8,   // timed parked

Why handle TIMED this way instead of just making TIMED_PARKED/PARKING states?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1273010956

From alanb at openjdk.org  Tue Jul 25 05:52:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Jul 2023 05:52:42 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked
In-Reply-To: <2rTLX86raFjJBNOlUysJoxGB8UaGLH7szSa_EOmXEDE=.e545fc08-9354-4173-b88f-b8173c3878b7@github.com>
References: <Ar-k3n5Awr02ccVZvwJkL9VyUVnHZbKW0ln9K5oZmp0=.98dfd87b-a04a-4fae-ad90-055131d8438e@github.com>
 <2rTLX86raFjJBNOlUysJoxGB8UaGLH7szSa_EOmXEDE=.e545fc08-9354-4173-b88f-b8173c3878b7@github.com>
Message-ID: <ixsswHs5-fsFogmPvJ56KHonX9VbsAYnA8laPcoZ09M=.afe8edfd-168b-4134-8932-603244bae3a4@github.com>

On Tue, 25 Jul 2023 05:21:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Why handle TIMED this way instead of just making TIMED_PARKED/PARKING states?

Been there but it is 3 additional states and a lot simpler to just use the additional state bits, like we do with SUSPENDED. We might use another one for special casing sleeping, if the need arises.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1273027305

From alanb at openjdk.org  Tue Jul 25 05:54:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Jul 2023 05:54:41 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available
In-Reply-To: <6XShzHu2amAup0TTtPTFTkZMdVVjU1Pr4N2RefUgYmw=.ed3432c4-7376-4295-b9bf-f4709eecd986@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <p-UNQRGHEN3aUQTyJljJBcH_gz_N8alzc4yp_jixWDk=.25d9352b-2e8f-4b19-9083-7d1f77e14cf0@github.com>
 <6XShzHu2amAup0TTtPTFTkZMdVVjU1Pr4N2RefUgYmw=.ed3432c4-7376-4295-b9bf-f4709eecd986@github.com>
Message-ID: <YyfHF6nPOuC-03hxdTcDbW_IpZJ7QnjidzmceldcOx4=.1fd31021-fae7-4125-aa83-7e2a4e5b9c7a@github.com>

On Tue, 25 Jul 2023 02:09:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> It's based on micro-benchmarks. Having the loops in Java reduces throughput but allocating memory using `malloc(len)` also reduces throughput as `len` gets larger and this threshold appears to balance the two.

Are these micro benchmarks dropping the file system cache so there is real file I/O? I wasn't expecting to see a buffer larger than 1Mb so curious what the benchmarks say.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1273028051

From duke at openjdk.org  Tue Jul 25 06:10:52 2023
From: duke at openjdk.org (duke)
Date: Tue, 25 Jul 2023 06:10:52 GMT
Subject: Withdrawn: JDK-8303794: IEEEremainder problems are causing test
 failures after JDK-8302801
In-Reply-To: <F7464Bq6rXzwD0j6qGxsA0eN2lOlHAHfn_2zzbHsO5w=.54e07f52-254f-4788-828d-507be15b1d1e@github.com>
References: <F7464Bq6rXzwD0j6qGxsA0eN2lOlHAHfn_2zzbHsO5w=.54e07f52-254f-4788-828d-507be15b1d1e@github.com>
Message-ID: <2YMLxQ_Yw06j6BJzkScCmRbRfHCjGlAQgrgPiB6Ym8k=.c3610e73-f020-4e17-865d-ac066b49979f@github.com>

On Wed, 8 Mar 2023 01:30:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Quick port of IEEEremainder; sorry for missing this earlier. Will add targeted tests in a follow-up fix.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12915

From duke at openjdk.org  Tue Jul 25 07:01:46 2023
From: duke at openjdk.org (airsquared)
Date: Tue, 25 Jul 2023 07:01:46 GMT
Subject: [jdk21] RFR: 8309032: jpackage does not work for module projects
 unless --module-path is specified
In-Reply-To: <H9una8oci7mgFejlqQHPTMQjMXcHr8eG3A1dNMzUwjg=.24a2b5bb-0918-487f-8bec-c3809f6376c3@github.com>
References: <H9una8oci7mgFejlqQHPTMQjMXcHr8eG3A1dNMzUwjg=.24a2b5bb-0918-487f-8bec-c3809f6376c3@github.com>
Message-ID: <8tCfZUruCLvcPAGgFAi9dr2ArYH6QfowX3CKgUrFITQ=.21d77d8e-cd1d-4ee4-ba50-4b1f1b68803d@github.com>

On Thu, 20 Jul 2023 02:34:05 GMT, airsquared <duke at openjdk.org> wrote:

> 8309032: jpackage does not work for module projects unless --module-path is specified

How likely is it that this can get approved in RDP 2? This is only a tiny change that fixes a minor bug in jpackage.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/140#issuecomment-1649234148

From alanb at openjdk.org  Tue Jul 25 07:09:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Jul 2023 07:09:55 GMT
Subject: [jdk21] RFR: 8309032: jpackage does not work for module projects
 unless --module-path is specified
In-Reply-To: <8tCfZUruCLvcPAGgFAi9dr2ArYH6QfowX3CKgUrFITQ=.21d77d8e-cd1d-4ee4-ba50-4b1f1b68803d@github.com>
References: <H9una8oci7mgFejlqQHPTMQjMXcHr8eG3A1dNMzUwjg=.24a2b5bb-0918-487f-8bec-c3809f6376c3@github.com>
 <8tCfZUruCLvcPAGgFAi9dr2ArYH6QfowX3CKgUrFITQ=.21d77d8e-cd1d-4ee4-ba50-4b1f1b68803d@github.com>
Message-ID: <hyMPY_45-OkqNfArVSGx2DrFQ3TiuyzaVsBVhW6_M_A=.6e7fdad3-1fc8-4220-ac97-a50d451aec57@github.com>

On Tue, 25 Jul 2023 06:56:26 GMT, airsquared <duke at openjdk.org> wrote:

> How likely is it that this can get approved in RDP 2? This is only a tiny change that fixes a minor bug in jpackage.

Unlikely as this is a P4 and not a regression in JDK 21. I think you should be aiming for jdk21u with this backport.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/140#issuecomment-1649245308

From duke at openjdk.org  Tue Jul 25 07:12:51 2023
From: duke at openjdk.org (airsquared)
Date: Tue, 25 Jul 2023 07:12:51 GMT
Subject: [jdk21] RFR: 8309032: jpackage does not work for module projects
 unless --module-path is specified
In-Reply-To: <H9una8oci7mgFejlqQHPTMQjMXcHr8eG3A1dNMzUwjg=.24a2b5bb-0918-487f-8bec-c3809f6376c3@github.com>
References: <H9una8oci7mgFejlqQHPTMQjMXcHr8eG3A1dNMzUwjg=.24a2b5bb-0918-487f-8bec-c3809f6376c3@github.com>
Message-ID: <khVEunM-YRHazea_VYfd_SX8Vqy83K0wNhRSuxWmVQY=.e1c5052d-3c9d-4fa5-a3fb-0d5456df56d0@github.com>

On Thu, 20 Jul 2023 02:34:05 GMT, airsquared <duke at openjdk.org> wrote:

> 8309032: jpackage does not work for module projects unless --module-path is specified

I see. I'll create a PR there. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/140#issuecomment-1649249253

From mbaesken at openjdk.org  Tue Jul 25 11:00:53 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Jul 2023 11:00:53 GMT
Subject: RFR: JDK-8311822: AIX : test/jdk/java/foreign/TestLayouts.java
 fails because of different output - expected [[i4](struct)] but found
 [[I4](struct)]
In-Reply-To: <t9BRZttDUZKGUCk_jXp5MtY9UTqDujKbOB-KQ5hSvTA=.0b0170c4-87e4-4192-9bb9-e1657b5bcda5@github.com>
References: <3GkWQ2ZAfpEE8E_sO1d7OkRI1ZozanduTEo1c9p6_fw=.74357f71-f25f-4817-b2ef-c6301c5f8208@github.com>
 <t9BRZttDUZKGUCk_jXp5MtY9UTqDujKbOB-KQ5hSvTA=.0b0170c4-87e4-4192-9bb9-e1657b5bcda5@github.com>
Message-ID: <hIRQgE53FZ2OZCNSfDvf1YXHsRqvB8mntpiYx6TUW74=.214fa7eb-be3d-4371-aab6-0fe6704fc98f@github.com>

On Mon, 24 Jul 2023 13:55:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>  I put this patch into our internal test queue to see how it works on AIX.

AIX tests are fine too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14994#issuecomment-1649612399

From pminborg at openjdk.org  Tue Jul 25 11:04:48 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 25 Jul 2023 11:04:48 GMT
Subject: RFR: JDK-8311822: AIX : test/jdk/java/foreign/TestLayouts.java
 fails because of different output - expected [[i4](struct)] but found
 [[I4](struct)]
In-Reply-To: <hIRQgE53FZ2OZCNSfDvf1YXHsRqvB8mntpiYx6TUW74=.214fa7eb-be3d-4371-aab6-0fe6704fc98f@github.com>
References: <3GkWQ2ZAfpEE8E_sO1d7OkRI1ZozanduTEo1c9p6_fw=.74357f71-f25f-4817-b2ef-c6301c5f8208@github.com>
 <t9BRZttDUZKGUCk_jXp5MtY9UTqDujKbOB-KQ5hSvTA=.0b0170c4-87e4-4192-9bb9-e1657b5bcda5@github.com>
 <hIRQgE53FZ2OZCNSfDvf1YXHsRqvB8mntpiYx6TUW74=.214fa7eb-be3d-4371-aab6-0fe6704fc98f@github.com>
Message-ID: <B0ZdS6FVWyjERa58Hb4tn6b5yMN_7ieRJS1yHSDqwxQ=.7d97481c-58cb-4897-8e0d-6cc026e2962c@github.com>

On Tue, 25 Jul 2023 10:57:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > I put this patch into our internal test queue to see how it works on AIX.
> 
> AIX tests are fine too.

Great! Thanks for testing this!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14994#issuecomment-1649617257

From dl at openjdk.org  Tue Jul 25 11:25:42 2023
From: dl at openjdk.org (Doug Lea)
Date: Tue, 25 Jul 2023 11:25:42 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: <1HH0mgrC72NDPByRp5SvRk6C6_X4cCgwsl5NplTNm0w=.596eea02-5677-4d1a-b46b-5bf25fcfc010@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.

Just a keep-alive comment

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14301#issuecomment-1649644972

From prappo at openjdk.org  Tue Jul 25 13:51:11 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 25 Jul 2023 13:51:11 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v4]
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <vtPCnDoqglJNpGwVAxAcwW2kDVCXI2ZPRPQpXin_Ft8=.6af9fe29-e049-4233-9842-ea2e8c423bf8@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.

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 ten additional commits since the last revision:

 - Improve benchmarks
 - Merge branch 'master' into 8310813
 - Restore hash code values
   
   BigInteger is old and ubiquitous enough so that there might be
   inadvertent dependencies on its hash code.
   
   This commit also includes a test, to make sure hash code is
   unchanged.
 - Merge branch 'master' into 8310813
 - Add a benchmark
 - Merge branch 'master' into 8310813
 - Use fewer range checks to improve performance
 - Improve
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14630/files
  - new: https://git.openjdk.org/jdk/pull/14630/files/d087a592..eb4b9775

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=02-03

  Stats: 21595 lines in 350 files changed: 9928 ins; 10405 del; 1262 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  Tue Jul 25 13:51:12 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 25 Jul 2023 13:51:12 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v3]
In-Reply-To: <88Kwu14Vu6OOS0JKrmI_ckerccDOCPJlWt9NumwVLjg=.c8c890bd-03ec-444d-8f55-b2a8bd11110e@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <88Kwu14Vu6OOS0JKrmI_ckerccDOCPJlWt9NumwVLjg=.c8c890bd-03ec-444d-8f55-b2a8bd11110e@github.com>
Message-ID: <aAG0Ig5IFM81YnEla8yLX7LJIL-PQWvEaHwAtcr87yE=.bfce9c05-3b05-44d0-a22f-51b3495d7a27@github.com>

On Thu, 20 Jul 2023 15:32:09 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.
>
> 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:
> 
>  - Restore hash code values
>    
>    BigInteger is old and ubiquitous enough so that there might be
>    inadvertent dependencies on its hash code.
>    
>    This commit also includes a test, to make sure hash code is
>    unchanged.
>  - Merge branch 'master' into 8310813
>  - Add a benchmark
>  - Merge branch 'master' into 8310813
>  - Use fewer range checks to improve performance
>  - Improve
>  - Initial commit

Made benchmarks more sensible. Bit length, which is a sole benchmark parameter, is now based on stats I gathered from running tests in the security area, which seems to be the biggest client of BigInteger in JDK. `equals` and `compareTo` now benchmark the worst-case scenario: each method compares two numbers whose binary representations differ minimally.

<details>
<summary>Here's how to replicate my stats, if required...</summary>

1. Add logging to `equals`, `hashCode`, and `compareTo`:

   ```
   diff --git a/src/java.base/share/classes/java/math/BigInteger.java b/src/java.base/share/classes/java/math/BigInteger.java
   index 1803b77df54..214a9ce4e4f 100644
   --- a/src/java.base/share/classes/java/math/BigInteger.java
   +++ b/src/java.base/share/classes/java/math/BigInteger.java
   @@ -3924,6 +3924,7 @@ public class BigInteger extends Number implements Comparable<BigInteger> {
         */
        @Override
        public int compareTo(BigInteger val) {
   +        System.out.println("#cmp#" + Math.min(this.bitLength(), val.bitLength()));
            if (signum == val.signum) {
                return switch (signum) {
                    case 1  -> compareMagnitude(val);
   @@ -4016,6 +4017,8 @@ public class BigInteger extends Number implements Comparable<BigInteger> {
            if (!(x instanceof BigInteger xInt))
                return false;
    
   +        System.out.println("#eq#" + Math.min(this.bitLength(), xInt.bitLength()));
   +
            if (xInt.signum != signum)
                return false;
    
   @@ -4055,6 +4058,7 @@ public class BigInteger extends Number implements Comparable<BigInteger> {
         */
        @Override
        public int hashCode() {
   +        System.out.println("#hc#" + bitLength());
            return ArraysSupport.vectorizedHashCode(mag, 0, mag.length, 0,
                    ArraysSupport.T_INT) * signum;
        }
   ```

2. Run tests:

   ```
   jtreg -J-Djavatest.maxOutputSize=999999999 -retain:all -verbose:summary -testjdk:build/macosx-aarch64/images/jdk/ test/jdk/:jdk_security
   ```

3. Ensure that the output is complete, that is, there are no "Output overflow:" in the jtr files. If there are, you might not be seeing the full data; increase the `maxOutputValue`, repeat step 2.

**Note: besides taking considerable time to run, this test configuration results in the JTwork directory whose size is 4G.**
</details>

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1649878980

From jlu at openjdk.org  Tue Jul 25 18:30:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 25 Jul 2023 18:30:00 GMT
Subject: Integrated: 8039165: [Doc] MessageFormat null locale generates
 NullPointerException
In-Reply-To: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
Message-ID: <Q54LXCRu_Q4ym91Ai0dcPfsM6l_H0NxBVcCy6HDCYXk=.73288791-ff20-4d71-afd7-358e7a3db81e@github.com>

On Mon, 17 Jul 2023 21:04:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8312197) which updates the javadoc for the constructor of MessageFormat regarding a `null` locale,
> 
> `MessageFormat` when created with a `null` locale may throw a `NullPointerException` either during the object creation, or later when `format()` is called by the `MessageFormat` object (test file has examples of both). This change updates the specification of MessageFormat to make this apparent.
> 
> The test for this change was merged with `Bug6481179.java` into `MessageFormatExceptions.java` (As they both test exceptions). In addition, some other exception testing regarding MessageFormat was added.
> 
> Thanks

This pull request has now been integrated.

Changeset: c6396dce
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6396dceb9a64578d5b335af27ad1d968190a1fa
Stats:     164 lines in 3 files changed: 97 ins; 64 del; 3 mod

8039165: [Doc] MessageFormat null locale generates NullPointerException

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/14911

From matsaave at openjdk.org  Tue Jul 25 18:48:58 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 25 Jul 2023 18:48:58 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v2]
In-Reply-To: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
Message-ID: <PlLziaxnr3lJpWWJTb8cNXhNVRXIjZhW3RyWCudUYvE=.0720bfaf-6401-461f-bdb0-06ce7b097d87@github.com>

> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 
> 
> 
>  // We have finished dumping the static archive. At this point, there may be pending VM
>  // operations. We have changed some global states (such as vmClasses::_klasses) that
>  // may cause these VM operations to fail. For safety, forget these operations and
>  // exit the VM directly.
>  void MetaspaceShared::exit_after_static_dump() {
>    os::_exit(0);
>  } 
> 
> 
> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.
> 
> Verified with tier 1-9 tests.

Matias Saavedra Silva has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge fix
 - Restores java loaders
 - Ioi and David comments
 - Windows fix
 - 8306582: Remove MetaspaceShared::exit_after_static_dump()

-------------

Changes: https://git.openjdk.org/jdk/pull/14879/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14879&range=01
  Stats: 127 lines in 9 files changed: 95 ins; 27 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14879/head:pull/14879

PR: https://git.openjdk.org/jdk/pull/14879

From matsaave at openjdk.org  Tue Jul 25 18:48:59 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 25 Jul 2023 18:48:59 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
In-Reply-To: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
Message-ID: <YEixUzvF8R54SGgwBHUAHEh72gYe4jTcldto_YkgocA=.e5d03465-3d9b-4b8c-980b-1119106c25a2@github.com>

On Thu, 13 Jul 2023 21:25:17 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 
> 
> 
>  // We have finished dumping the static archive. At this point, there may be pending VM
>  // operations. We have changed some global states (such as vmClasses::_klasses) that
>  // may cause these VM operations to fail. For safety, forget these operations and
>  // exit the VM directly.
>  void MetaspaceShared::exit_after_static_dump() {
>    os::_exit(0);
>  } 
> 
> 
> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.
> 
> Verified with tier 1-9 tests.

I messed up a merge and pushed the incorrect contents to this PR. It will be temporarily reverted to a draft and force pushed to undo my mistake.

The existing comments should be addressed in the most recent commits.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14879#issuecomment-1649978355

From coffeys at openjdk.org  Tue Jul 25 19:47:16 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 25 Jul 2023 19:47:16 GMT
Subject: RFR: 8311653: Modify -XshowSettings launcher behavior [v2]
In-Reply-To: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
References: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
Message-ID: <NLlC66xzaMKJ_6it6UzFt2zkOpUZ5_cT_VdfI7pTXkM=.8946220f-975c-4753-b8d7-1956af463a64@github.com>

> Modify the -XshowSettings launcher option to print non-verbose settings details of all components by default. Verbose settings details will be printed via the -XshowSettings:all option. Modify the -XshowSettings option to reject bad values passed to it. Print an error message in such scenarios and abort the VM launch.

Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:

 - Incorporate review feedback
 - modify -X output for :all

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15001/files
  - new: https://git.openjdk.org/jdk/pull/15001/files/6994dd04..688b856d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15001&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15001&range=00-01

  Stats: 125 lines in 4 files changed: 78 ins; 13 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/15001.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15001/head:pull/15001

PR: https://git.openjdk.org/jdk/pull/15001

From coffeys at openjdk.org  Tue Jul 25 19:47:36 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 25 Jul 2023 19:47:36 GMT
Subject: RFR: 8311653: Modify -XshowSettings launcher behavior
In-Reply-To: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
References: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
Message-ID: <qfcKO4aTpzgcVgoiQbfGHqIF0keD0a0TjNrVzcGzJac=.c310f65c-8067-458b-a359-7ef9026f6cd7@github.com>

On Mon, 24 Jul 2023 16:00:52 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Modify the -XshowSettings launcher option to print non-verbose settings details of all components by default. Verbose settings details will be printed via the -XshowSettings:all option. Modify the -XshowSettings option to reject bad values passed to it. Print an error message in such scenarios and abort the VM launch.

Thanks for the feedback to date. I think I've captured all of it in recent update.

main changes: 
I've tightened up validation of input values to -XshowSettings and improved testing in this area. 
Updated java -X output to highlight difference between -XshowSettings and -XshowSettings:all

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15001#issuecomment-1650433071

From vpetko at openjdk.org  Tue Jul 25 20:15:56 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Tue, 25 Jul 2023 20:15:56 GMT
Subject: Integrated: 8312488: tools/jpackage/share/AppLauncherEnvTest.java
 fails with dynamically linked libstdc++
In-Reply-To: <RMaWupHshwbpWmIsBXfRG9swzBbJ3nGeDiloyDJLiRk=.d1f80bff-3e44-4060-8958-3d4f0f1f63a3@github.com>
References: <RMaWupHshwbpWmIsBXfRG9swzBbJ3nGeDiloyDJLiRk=.d1f80bff-3e44-4060-8958-3d4f0f1f63a3@github.com>
Message-ID: <RIWZpwiLc49HE1iQFsWrlvm7ZXs7PhPTF2wHm-Bgd74=.48fc7606-5bd7-4c9e-b054-e72c0d4d0ba3@github.com>

On Fri, 21 Jul 2023 10:55:13 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> Use the  same approach as Logger::defaultLogger() to ensure that the appender is not destroyed before shared object destructor function is executed.
> 
> The alternative is to delete dcon() function, but we might run into a similiar tear-down issue later (e.g. logging from some object's destructor).
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/tools                                215   215     0     0   
> ==============================
> TEST SUCCESS

This pull request has now been integrated.

Changeset: 78a8a99d
Author:    Vladimir Petko <vpetko at openjdk.org>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78a8a99d990dcc0b77c096bb2ca2c1bb86462e3f
Stats:     10 lines in 1 file changed: 5 ins; 0 del; 5 mod

8312488: tools/jpackage/share/AppLauncherEnvTest.java fails with dynamically linked libstdc++

Reviewed-by: asemenyuk, almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/14971

From jvernee at openjdk.org  Tue Jul 25 20:18:10 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 25 Jul 2023 20:18:10 GMT
Subject: RFR: 8313023: Return value corrupted when using CCS + isTrivial
 (mainline)
Message-ID: <OO6MXUJA8WN4KaZQ5s8f09My73TaVD8Fd4uqVTpRpdo=.ca97bc20-6eff-4855-8fde-cde634c71236@github.com>

Port of: https://github.com/openjdk/panama-foreign/pull/848 from the panama-foreign repo.

Copying the PR body here for convenience:

Due to a bug in the downcall linker stub generation, we don't save the return value when capturing call state for trivial functions, and the return value gets corrupted.

We try not to save the return register around calls on the return path of a downcall stub, if it is not needed. Currently we don't save the return register when we're using a return buffer, since we write the return value to the return buffer before the calls on the return path, which means it is safe for those calls to overwrite the return register. But, the current logic also says we don't need to save the return register if the function is trivial (_needs_transition == false). The logic behind this was initially that, since we don't have any calls on the return path, we don't need to save the return register. But, after adding support for capturing call state, we now also have a call on the return path for trivial functions that capture call state, and around that call, we might need to save the return register.

The fix is to simply save the return register when capturing call state, regardless of whether the function is trivial or not. In the case of just a trivial function that doesn't capture call state, we still don't save the return register around the return path calls for the thread state transition (which is not needed), since we don't generate those thread state transitions in the first first place.

Testing: jdk-tier1, jdk-tier2, jdk-tier5.

-------------

Commit messages:
 - 8312473: Return value corrupted when using CCS + isTrivial

Changes: https://git.openjdk.org/jdk/pull/15025/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15025&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313023
  Stats: 39 lines in 5 files changed: 12 ins; 0 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/15025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15025/head:pull/15025

PR: https://git.openjdk.org/jdk/pull/15025

From serb at openjdk.org  Tue Jul 25 21:02:56 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 25 Jul 2023 21:02:56 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v3]
In-Reply-To: <0wUuynDia128uyCaMmWi7BltH8HQcyI-CKcyGcP_Ucc=.89942c4d-b2a5-4fd2-8599-0c43745057a6@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
 <Tve0iW0pLnP3F4ZzUhSWwI6XxEH-e1xPhUpXT1hQwqI=.39a8204c-842e-45a2-9b62-760582f62382@github.com>
 <iFdzsokxjgv0NGYH-8o-9U8e6ItaBgoUxmii-I4ZcRE=.00b23800-fe28-485b-95bc-0a6ab3777852@github.com>
 <0wUuynDia128uyCaMmWi7BltH8HQcyI-CKcyGcP_Ucc=.89942c4d-b2a5-4fd2-8599-0c43745057a6@github.com>
Message-ID: <y3Y-Vrm93m_dKQBorebU3umX7l6cpdjhTNeyWP_WaNI=.8c9279d2-f1d0-463c-bc56-0100824eb408@github.com>

On Thu, 13 Oct 2022 14:34:25 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Looks good. Thanks.
>
> @dholmes-ora could I trouble you for a sponsor? Thanks!

@TheShermanTanker Working on a similar cleanup, and wonder if is it correct to assume that the "snprintf" adds "nul" even in case of error.
For example, this code was removed by this patch:


    if (rc < 0) {
        /* apply ansi semantics */
        buffer[size - 1] = '\0';
        return (int)size;
    } else if (rc == size) {
        /* force a null terminator */
        buffer[size - 1] = '\0';
    }


If the result of "snprintf" was negative we always set the '\0'. But what about default "snprintf"?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10625#issuecomment-1650553077

From mchung at openjdk.org  Tue Jul 25 21:04:54 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 25 Jul 2023 21:04:54 GMT
Subject: RFR: 8311653: Modify -XshowSettings launcher behavior [v2]
In-Reply-To: <NLlC66xzaMKJ_6it6UzFt2zkOpUZ5_cT_VdfI7pTXkM=.8946220f-975c-4753-b8d7-1956af463a64@github.com>
References: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
 <NLlC66xzaMKJ_6it6UzFt2zkOpUZ5_cT_VdfI7pTXkM=.8946220f-975c-4753-b8d7-1956af463a64@github.com>
Message-ID: <QJEVGgSn4V03XNkhTAy1WRzwXEYxkTWt-ZXIeNgPiqY=.31f4f333-3b12-416b-88fb-cd440377afac@github.com>

On Tue, 25 Jul 2023 19:47:16 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Modify the -XshowSettings launcher option to print non-verbose settings details of all components by default. Verbose settings details will be printed via the -XshowSettings:all option. Modify the -XshowSettings option to reject bad values passed to it. Print an error message in such scenarios and abort the VM launch.
>
> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Incorporate review feedback
>  - modify -X output for :all

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 170:

> 168:                  SECURITY_PROVIDERS,
> 169:                  SECURITY_TLS -> SecuritySettings.printSecuritySettings(component, ostream, true);
> 170:             case SYSTEM-> printSystemMetrics();

Nit: space before `->`
Suggestion:

            case SYSTEM -> printSystemMetrics();

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 172:

> 170:             case SYSTEM-> printSystemMetrics();
> 171:             case VM -> printVmSettings(initialHeapSize, maxHeapSize, stackSize);
> 172:             case EMPTY -> printAllSettings(initialHeapSize, maxHeapSize, stackSize, false);

Nit: It seems clearer to name this as `DEFAULT`.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 191:

> 189: 
> 190:         // case-sensitive check of input flag
> 191:         List<String> validOpts = Arrays.stream(Option.values())

The logic can be simplified by building a map of option name to `Option`.


        Map<String, Option> validOpts = Arrays.stream(Option.values())
                .filter(o -> !o.equals(Option.EMPTY)) // non-valid option
                .collect(Collectors.toMap(o -> o.name()
                                                .toLowerCase(Locale.ROOT)
                                                .replace("_", ":"), Function.identity()));

        String optStr = optionFlag.substring("-XshowSettings:".length());
        Option component = validOpts.get(optStr);
        if (component == null) {
            abort(null, "java.launcher.bad.option", optStr);
        }
        return component;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15001#discussion_r1274078900
PR Review Comment: https://git.openjdk.org/jdk/pull/15001#discussion_r1274081324
PR Review Comment: https://git.openjdk.org/jdk/pull/15001#discussion_r1274116417

From jvernee at openjdk.org  Tue Jul 25 21:28:45 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 25 Jul 2023 21:28:45 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
Message-ID: <Yrs1mKpyZQZrXqCFtSxOemkcvrh4xMyCr2mydFSU9Nc=.ca809339-95de-4e1a-8324-f93fb9cb8b72@github.com>

On Sat, 8 Jul 2023 10:48:15 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address suggestions from Jorn Vernee

src/hotspot/cpu/s390/downcallLinker_s390.cpp line 162:

> 160: 
> 161:   assert(!_needs_return_buffer, "unexpected needs_return_buffer");
> 162:   bool should_save_return_value = _needs_transition;;

This should always be `true`, so I don't think you need the `if` statements around the spill/fill code below.

See: https://github.com/openjdk/jdk/pull/15025 (`should_save_return_value` being dependent on `_needs_transition` is a bug).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1274138222

From jvernee at openjdk.org  Tue Jul 25 21:30:49 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 25 Jul 2023 21:30:49 GMT
Subject: RFR: 8313023: Return value corrupted when using CCS + isTrivial
 (mainline)
In-Reply-To: <OO6MXUJA8WN4KaZQ5s8f09My73TaVD8Fd4uqVTpRpdo=.ca97bc20-6eff-4855-8fde-cde634c71236@github.com>
References: <OO6MXUJA8WN4KaZQ5s8f09My73TaVD8Fd4uqVTpRpdo=.ca97bc20-6eff-4855-8fde-cde634c71236@github.com>
Message-ID: <OwWNDImcriXbajG2A2BHejjBEg5qG3Cb79DaYKOhLHs=.7fc035e7-046b-462a-b2c2-e6d312f34dbd@github.com>

On Tue, 25 Jul 2023 19:17:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Port of: https://github.com/openjdk/panama-foreign/pull/848 from the panama-foreign repo.
> 
> Copying the PR body here for convenience:
> 
> Due to a bug in the downcall linker stub generation, we don't save the return value when capturing call state for trivial functions, and the return value gets corrupted.
> 
> We try not to save the return register around calls on the return path of a downcall stub, if it is not needed. Currently we don't save the return register when we're using a return buffer, since we write the return value to the return buffer before the calls on the return path, which means it is safe for those calls to overwrite the return register. But, the current logic also says we don't need to save the return register if the function is trivial (_needs_transition == false). The logic behind this was initially that, since we don't have any calls on the return path, we don't need to save the return register. But, after adding support for capturing call state, we now also have a call on the return path for trivial functions that capture call state, and around that call, we might need to save the return register.
> 
> The fix is to simply save the return register when capturing call state, regardless of whether the function is trivial or not. In the case of just a trivial function that doesn't capture call state, we still don't save the return register around the return path calls for the thread state transition (which is not needed), since we don't generate those thread state transitions in the first first place.
> 
> Testing: jdk-tier1, jdk-tier2, jdk-tier5.

@TheRealMDoerr @feilongjiang Just a heads up: this patch touches the PPC and RISC-V ports as well, which I'm not able to test. I've just eye-balled the needed changes. I don't think there will be an issue since the code structure is almost identical, but you might want to run the `java/foreign/capturecallstate/TestCaptureCallState.java` test with this patch just to be sure.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15025#issuecomment-1650586454

From jwaters at openjdk.org  Tue Jul 25 23:30:56 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 25 Jul 2023 23:30:56 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v3]
In-Reply-To: <y3Y-Vrm93m_dKQBorebU3umX7l6cpdjhTNeyWP_WaNI=.8c9279d2-f1d0-463c-bc56-0100824eb408@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
 <Tve0iW0pLnP3F4ZzUhSWwI6XxEH-e1xPhUpXT1hQwqI=.39a8204c-842e-45a2-9b62-760582f62382@github.com>
 <iFdzsokxjgv0NGYH-8o-9U8e6ItaBgoUxmii-I4ZcRE=.00b23800-fe28-485b-95bc-0a6ab3777852@github.com>
 <0wUuynDia128uyCaMmWi7BltH8HQcyI-CKcyGcP_Ucc=.89942c4d-b2a5-4fd2-8599-0c43745057a6@github.com>
 <y3Y-Vrm93m_dKQBorebU3umX7l6cpdjhTNeyWP_WaNI=.8c9279d2-f1d0-463c-bc56-0100824eb408@github.com>
Message-ID: <Nn3GpJVsQE1hJaHzf-DHHsytikZf4AsEttLQKLjl6OU=.722ab4a7-a6fa-4482-9360-7370c7298aa6@github.com>

On Tue, 25 Jul 2023 21:00:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @dholmes-ora could I trouble you for a sponsor? Thanks!
>
> @TheShermanTanker Working on a similar cleanup, and wonder if is it correct to assume that the "snprintf" adds "nul" even in case of error.
> For example, this code was removed by this patch:
> 
> 
>     if (rc < 0) {
>         /* apply ansi semantics */
>         buffer[size - 1] = '\0';
>         return (int)size;
>     } else if (rc == size) {
>         /* force a null terminator */
>         buffer[size - 1] = '\0';
>     }
> 
> 
> If the result of "snprintf" was negative we always set the '\0'. But what about default "snprintf"?

@mrserb snprintf in the UCRT does indeed null terminate the buffer, conforming to C99. The relevant behaviour can be found documented under https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170#behavior-summary

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10625#issuecomment-1650700451

From bpb at openjdk.org  Tue Jul 25 23:50:07 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 25 Jul 2023 23:50:07 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <FDmB78T3fQEDYQ5A2t90zsdGHpcMw5bmwfQorqdSpOM=.3151ea03-78b0-4b9f-8017-39b2cbacc170@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <p-UNQRGHEN3aUQTyJljJBcH_gz_N8alzc4yp_jixWDk=.25d9352b-2e8f-4b19-9083-7d1f77e14cf0@github.com>
 <FDmB78T3fQEDYQ5A2t90zsdGHpcMw5bmwfQorqdSpOM=.3151ea03-78b0-4b9f-8017-39b2cbacc170@github.com>
Message-ID: <tzmBsxiBWCqY46aG0iqYwqCnvrRtpL86TvGjIvPqHhE=.c2a5d2b0-e80f-4a9b-ba62-150d853df52f@github.com>

On Tue, 25 Jul 2023 02:05:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/FileOutputStream.java line 366:
>> 
>>> 364:                 int n = writeBytes(b, off, len, append);
>>> 365:                 if (n == -1)
>>> 366:                     break;
>> 
>> Checking if n is -1 doesn't look right here. Isn't return -1 just to keep the compiler happy when an exception is thrown.
>
> This is a copy-paste vestige; will remove.

Removed in 973e848a84113f8d6eb65702a148138f2edca1ee.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1274219972

From bpb at openjdk.org  Tue Jul 25 23:50:07 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 25 Jul 2023 23:50:07 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <tB7cOCs5Ou8EBcmXkKYalC7eVhatB6VXIozTTIYTLGM=.f9e3763d-013d-4213-b471-98a0e7723526@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <zMQNkK2EUBDbckG10CD4Yy_Bs1eYACqdSDqWeEKx1Po=.112a2094-c25c-45cd-9485-c032e9b3c042@github.com>
 <tB7cOCs5Ou8EBcmXkKYalC7eVhatB6VXIozTTIYTLGM=.f9e3763d-013d-4213-b471-98a0e7723526@github.com>
Message-ID: <eaFQb9VkNHo_epTg8yjIfr8eKUzjBwV2Khz2l10ZAnM=.c1e2bc9e-694e-49ac-b6e7-fb59f69f9ae0@github.com>

On Mon, 24 Jul 2023 13:04:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/native/libjava/io_util.c line 99:
>> 
>>> 97:         return 0;
>>> 98:     } else if (len > BUF_SIZE) {
>>> 99:         if (len > MAX_MALLOC_SIZE)
>> 
>> Hi Brian if I am reading code correctly then with the current code change FIS.read(byte[] b, int off, int len) will always read (MAX_MALLOC_SIZE 2097152) bytes if len > MAX_MALLOC_SIZE. 
>> 
>> The java doc of read  as below
>> 
>> public?int?read(byte[]?b,
>>                 int?off,
>>                 int?len)
>>          throws IOException
>> Reads up to len bytes of data from the input stream into an array of bytes. An attempt is made to read as many as len bytes, but a smaller number may be read. The number of bytes actually read is returned as an integer.
>> 
>> I think  if you are limiting the internal dynamic buffer to 2097152 byte then you have  to at least attempt to read as many as len bytes if possible before returning.
>> 
>> If I simply the run the following code 
>> 
>> 	    int size = 501 * 501 * 501 * 3;
>> 
>>             FileInputStream fis = new FileInputStream("/home/vyom1/test.img"); // Any file with size >= 501*501*501*2
>> 
>>             System.out.println("size: " + size);
>> 
>>             byte buf[] = new byte[size];
>> 
>>             System.out.println("buf ok");
>> 
>>             int bytesRead = fis.read(buf, 0, size);
>>             System.out.println("Bytes read " + bytesRead);
>> 
>> It will always print ?Bytes read 2097152? which is not as per Java specification of InputStream.read(byte[]b, int off, int len).
>
> A short read is okay but changing long standing behavior could potentially break already broken code that calls the method with a large byte array and assumes it will read to EOF. So I think it's a forced move to read until there is no space remaining or EOF is reached. This is logic for the Java level, not the native code of course. If an I/O exception is on the second/subsequent reads then it will have to return the bytes that are read, not throw with bytes in the buffer.

Addressed in 973e848a84113f8d6eb65702a148138f2edca1ee.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1274219415

From bpb at openjdk.org  Tue Jul 25 23:50:07 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 25 Jul 2023 23:50:07 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
Message-ID: <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>

> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.

Brian Burkhalter has updated the pull request incrementally with three additional commits since the last revision:

 - 6478546: Decrease malloc limit to 1.5 MB
 - 6478546: Minor refactoring
 - 6478546: Prevent short read

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14981/files
  - new: https://git.openjdk.org/jdk/pull/14981/files/8d7b3478..69941de4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14981&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14981&range=00-01

  Stats: 99 lines in 6 files changed: 57 ins; 28 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/14981.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14981/head:pull/14981

PR: https://git.openjdk.org/jdk/pull/14981

From serb at openjdk.org  Tue Jul 25 23:55:00 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 25 Jul 2023 23:55:00 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v5]
In-Reply-To: <LAdK3zAvSQiFX2AAa4BvHwfNUUeSG8ye-qbEKWlmzbc=.968c8988-6132-4cf1-b81c-4e9274bfd5c8@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
 <LAdK3zAvSQiFX2AAa4BvHwfNUUeSG8ye-qbEKWlmzbc=.968c8988-6132-4cf1-b81c-4e9274bfd5c8@github.com>
Message-ID: <iLS4ffVMPWQPbIzJxQI-AiUkK0Q-JNFvGycOXlyI2oo=.598ea3d2-626b-410b-ae23-f8c1d2f8b445@github.com>

On Thu, 13 Oct 2022 14:48:29 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> The C99 snprintf is available with Visual Studio 2015 and above, alongside Windows 10 and the UCRT, and is no longer identical to the outdated Windows _snprintf. Since support for the Visual C++ 2017 compiler was removed a while ago, we can now safely remove the compatibility workaround on Windows and have JLI_Snprintf simply delegate to snprintf.
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-1
>  - Merge branch 'openjdk:master' into patch-1
>  - Comment documenting change isn't required
>  - Merge branch 'openjdk:master' into patch-1
>  - Comment formatting
>  - Remove Windows specific JLI_Snprintf implementation
>  - Remove Windows JLI_Snprintf definition

Thank you!

>If processing string specifier s, S, or Z, format specification processing stops, a NULL is placed at the beginning of the buffer.

I hope this is not an MS extension/implementation detail since I did not find this in any other places.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10625#issuecomment-1650717499

From bpb at openjdk.org  Wed Jul 26 00:03:41 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 26 Jul 2023 00:03:41 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <YyfHF6nPOuC-03hxdTcDbW_IpZJ7QnjidzmceldcOx4=.1fd31021-fae7-4125-aa83-7e2a4e5b9c7a@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <p-UNQRGHEN3aUQTyJljJBcH_gz_N8alzc4yp_jixWDk=.25d9352b-2e8f-4b19-9083-7d1f77e14cf0@github.com>
 <6XShzHu2amAup0TTtPTFTkZMdVVjU1Pr4N2RefUgYmw=.ed3432c4-7376-4295-b9bf-f4709eecd986@github.com>
 <YyfHF6nPOuC-03hxdTcDbW_IpZJ7QnjidzmceldcOx4=.1fd31021-fae7-4125-aa83-7e2a4e5b9c7a@github.com>
Message-ID: <TQKdF1tK-JX69deHl8AOrpWqLXqB6d_XTMhm9n4YWZU=.25ebdb14-24a6-42c2-b05f-f1eb74694b62@github.com>

On Tue, 25 Jul 2023 05:51:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It's based on micro-benchmarks. Having the loops in Java reduces throughput but allocating memory using `malloc(len)` also reduces throughput as `len` gets larger and this threshold appears to balance the two.
>
>> It's based on micro-benchmarks. Having the loops in Java reduces throughput but allocating memory using `malloc(len)` also reduces throughput as `len` gets larger and this threshold appears to balance the two.
> 
> Are these micro benchmarks dropping the file system cache so there is real file I/O? I wasn't expecting to see a buffer larger than 1Mb so curious what the benchmarks say.

There was no dropping of the file system cache. I would think this would have more of an effect on measuring the throughput of writing than reading.

I since modified the benchmark to invoke `FileChannel::force` in a `@TearDown` at the invocation level. That is not really copacetic but appears to give more believable results.

New runs show that if the malloc limit is 1Mb, then the revised code underperforms the current code until the size of array surpasses 1.5Mb. If the limit is 1.5Mb however, the new code improved throughput for all sizes tested. Based on this I reduced the malloc limit to 1572864.

These results are for macOS only thus far.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1274227677

From dholmes at openjdk.org  Wed Jul 26 03:36:48 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Jul 2023 03:36:48 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v5]
In-Reply-To: <iLS4ffVMPWQPbIzJxQI-AiUkK0Q-JNFvGycOXlyI2oo=.598ea3d2-626b-410b-ae23-f8c1d2f8b445@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
 <LAdK3zAvSQiFX2AAa4BvHwfNUUeSG8ye-qbEKWlmzbc=.968c8988-6132-4cf1-b81c-4e9274bfd5c8@github.com>
 <iLS4ffVMPWQPbIzJxQI-AiUkK0Q-JNFvGycOXlyI2oo=.598ea3d2-626b-410b-ae23-f8c1d2f8b445@github.com>
Message-ID: <3hsPveYeVHuicgxUzShA-jeSXZFfkO_amBC8iAdOSt8=.db95b1f4-0b7c-4bd9-8989-3463c7058e0e@github.com>

On Tue, 25 Jul 2023 23:51:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I hope this is not an MS extension/implementation detail since I did not find this in any other places.

@mrserb this change was to a Windows specific file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10625#issuecomment-1650925566

From serb at openjdk.org  Wed Jul 26 04:34:57 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Jul 2023 04:34:57 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v5]
In-Reply-To: <iLS4ffVMPWQPbIzJxQI-AiUkK0Q-JNFvGycOXlyI2oo=.598ea3d2-626b-410b-ae23-f8c1d2f8b445@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
 <LAdK3zAvSQiFX2AAa4BvHwfNUUeSG8ye-qbEKWlmzbc=.968c8988-6132-4cf1-b81c-4e9274bfd5c8@github.com>
 <iLS4ffVMPWQPbIzJxQI-AiUkK0Q-JNFvGycOXlyI2oo=.598ea3d2-626b-410b-ae23-f8c1d2f8b445@github.com>
Message-ID: <k90PIdsxICfr_LW3ISaEL_KpY39ODXdwju-zXicf4xM=.5e0cb22b-b6e0-4589-ba6d-5542fe9033d8@github.com>

On Tue, 25 Jul 2023 23:51:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into patch-1
>>  - Merge branch 'openjdk:master' into patch-1
>>  - Comment documenting change isn't required
>>  - Merge branch 'openjdk:master' into patch-1
>>  - Comment formatting
>>  - Remove Windows specific JLI_Snprintf implementation
>>  - Remove Windows JLI_Snprintf definition
>
> Thank you!
> 
>>If processing string specifier s, S, or Z, format specification processing stops, a NULL is placed at the beginning of the buffer.
> 
> I hope this is not an MS extension/implementation detail since I did not find this in any other places.

>@mrserb this change was to a Windows specific file.

That change removed the windows specific version of the JLI_Snprintf, and now we use
`#define JLI_Snprintf   snprintf` on all platforms. And my question was about that "cross-platform" `snprintf`. As linked in the comment above on Windows it adds the null at the start of the buffer in case of error when a negative value is returned. But is that specified by the c99?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10625#issuecomment-1650963715

From vtewari at openjdk.org  Wed Jul 26 05:29:54 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 26 Jul 2023 05:29:54 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
Message-ID: <2MM-OcX_oc5491kksCMjJhXE3c0eYCYLwBdj-9MZ2cA=.9b082e4f-1df7-4e29-8176-722cd86d349c@github.com>

On Tue, 25 Jul 2023 23:50:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.
>
> Brian Burkhalter has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 6478546: Decrease malloc limit to 1.5 MB
>  - 6478546: Minor refactoring
>  - 6478546: Prevent short read

src/java.base/share/native/libjava/io_util.c line 163:

> 161:     }
> 162: 
> 163:     if (outOfBounds(env, off, len, bytes)) {

we are already performing this check at Java level, do we need the perform this check again ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1274390203

From vtewari at openjdk.org  Wed Jul 26 05:35:04 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 26 Jul 2023 05:35:04 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
Message-ID: <7jYPsgbYJLiMIA-ZhtlS-jZKatNX58pVD9mcMFw2Jzc=.4fd7dfb6-44be-4b58-9ba3-ff3f58e372a8@github.com>

On Tue, 25 Jul 2023 23:50:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.
>
> Brian Burkhalter has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 6478546: Decrease malloc limit to 1.5 MB
>  - 6478546: Minor refactoring
>  - 6478546: Prevent short read

src/java.base/share/native/libjava/io_util.c line 173:

> 171:         if (len > MAX_MALLOC_SIZE)
> 172:             len = MAX_MALLOC_SIZE;
> 173:         buf = (char*)malloc(len*sizeof(char));

please reformat line 173

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1274392919

From dholmes at openjdk.org  Wed Jul 26 06:13:56 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Jul 2023 06:13:56 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v5]
In-Reply-To: <k90PIdsxICfr_LW3ISaEL_KpY39ODXdwju-zXicf4xM=.5e0cb22b-b6e0-4589-ba6d-5542fe9033d8@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
 <LAdK3zAvSQiFX2AAa4BvHwfNUUeSG8ye-qbEKWlmzbc=.968c8988-6132-4cf1-b81c-4e9274bfd5c8@github.com>
 <iLS4ffVMPWQPbIzJxQI-AiUkK0Q-JNFvGycOXlyI2oo=.598ea3d2-626b-410b-ae23-f8c1d2f8b445@github.com>
 <k90PIdsxICfr_LW3ISaEL_KpY39ODXdwju-zXicf4xM=.5e0cb22b-b6e0-4589-ba6d-5542fe9033d8@github.com>
Message-ID: <a-TU7W7w0Fof2PXdDZTdfr5yBpU3zGxhOofvxT-UfAw=.157412b9-189d-4a59-a903-b8e3d5c4759a@github.com>

On Wed, 26 Jul 2023 04:31:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Thank you!
>> 
>>>If processing string specifier s, S, or Z, format specification processing stops, a NULL is placed at the beginning of the buffer.
>> 
>> I hope this is not an MS extension/implementation detail since I did not find this in any other places.
>
>>@mrserb this change was to a Windows specific file.
> 
> That change removed the windows specific version of the JLI_Snprintf, and now we use
> `#define JLI_Snprintf   snprintf` on all platforms. And my question was about that "cross-platform" `snprintf`. As linked in the comment above on Windows it adds the null at the start of the buffer in case of error when a negative value is returned. But is that specified by the c99?

@mrserb we already had the define for non-Windows, this change just made it unconditional. This change only had an affect on Windows where we removed the custom `JLI_Snprintf` and started using `snprintf` the same as all other platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10625#issuecomment-1651039136

From vtewari at openjdk.org  Wed Jul 26 06:19:54 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 26 Jul 2023 06:19:54 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
Message-ID: <1AElBiUU7l0pjIFxEOrjkUkmkLiGGD8VMxLe9R4vUME=.ddf56e86-8b8a-4db9-abd2-1e7c5d722584@github.com>

On Tue, 25 Jul 2023 23:50:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.
>
> Brian Burkhalter has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 6478546: Decrease malloc limit to 1.5 MB
>  - 6478546: Minor refactoring
>  - 6478546: Prevent short read

src/java.base/share/classes/java/io/FileInputStream.java line 266:

> 264:         } catch (IOException e) {
> 265:             // Throw only if no bytes have been read
> 266:             if (off == start)

If i am reading code correctly then with the new implementation, until client issue the next "FIS.read" he may or may not know if there was exception pending in previous 'read' call ?.
I am not sure in case of partial read we have suppress the exception.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1274424360

From dholmes at openjdk.org  Wed Jul 26 06:26:08 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Jul 2023 06:26:08 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v5]
In-Reply-To: <LAdK3zAvSQiFX2AAa4BvHwfNUUeSG8ye-qbEKWlmzbc=.968c8988-6132-4cf1-b81c-4e9274bfd5c8@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
 <LAdK3zAvSQiFX2AAa4BvHwfNUUeSG8ye-qbEKWlmzbc=.968c8988-6132-4cf1-b81c-4e9274bfd5c8@github.com>
Message-ID: <DL0d8S9oz4ug50dQH3KxnWHhUoi9do6XmXW-ZfFmYHA=.271cb2a4-34d4-4638-b8e8-25593a7113cb@github.com>

On Thu, 13 Oct 2022 14:48:29 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> The C99 snprintf is available with Visual Studio 2015 and above, alongside Windows 10 and the UCRT, and is no longer identical to the outdated Windows _snprintf. Since support for the Visual C++ 2017 compiler was removed a while ago, we can now safely remove the compatibility workaround on Windows and have JLI_Snprintf simply delegate to snprintf.
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-1
>  - Merge branch 'openjdk:master' into patch-1
>  - Comment documenting change isn't required
>  - Merge branch 'openjdk:master' into patch-1
>  - Comment formatting
>  - Remove Windows specific JLI_Snprintf implementation
>  - Remove Windows JLI_Snprintf definition

That said C99 snprintf does not say anything about writing a NUL terminator in the case where nothing at all is written.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10625#issuecomment-1651052351

From alanb at openjdk.org  Wed Jul 26 06:36:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Jul 2023 06:36:42 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <1AElBiUU7l0pjIFxEOrjkUkmkLiGGD8VMxLe9R4vUME=.ddf56e86-8b8a-4db9-abd2-1e7c5d722584@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
 <1AElBiUU7l0pjIFxEOrjkUkmkLiGGD8VMxLe9R4vUME=.ddf56e86-8b8a-4db9-abd2-1e7c5d722584@github.com>
Message-ID: <Qhx_wIxCbkrT0-FXn9U7II44SAz6MsIPm0Nn9b2qMjs=.af35c186-6b5d-42ee-a029-cb293331b703@github.com>

On Wed, 26 Jul 2023 06:17:13 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> If i am reading code correctly then with the new implementation, until client issue the next "FIS.read" he may or may not know if there was exception pending in previous 'read' call ?.
> I am not sure in case of partial read we have suppress the exception.

It's a forced move because bytes have already been copied into user's byte[].

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1274438315

From dholmes at openjdk.org  Wed Jul 26 07:17:59 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Jul 2023 07:17:59 GMT
Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that
 have not done anything since Java 6 [v6]
In-Reply-To: <Cq7TUnTv1VVlbeQTY3OtZD7YRt2KqIRushB7TPVvKFc=.267974d1-df00-4559-86aa-f117db520f25@github.com>
References: <DBX8URjVSiAPULb1udGr9eyFOkx8K8nGADqrLTr-6ic=.3bb6a248-b889-4347-b39c-b164691d8f69@github.com>
 <Cq7TUnTv1VVlbeQTY3OtZD7YRt2KqIRushB7TPVvKFc=.267974d1-df00-4559-86aa-f117db520f25@github.com>
Message-ID: <7l5s1UCDgEt4c34NVusIhI9fdXsoJPhuUtdHV9FMnaM=.ee4b077d-ddd0-4430-8e1d-61379b46b239@github.com>

On Wed, 19 Jul 2023 10:58:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to deprecate for removal the  `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229.
>> 
>> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove -Xdebug usage from SourceDebugExtension test

Sorry wrong browser tab

-------------

PR Review: https://git.openjdk.org/jdk/pull/14918#pullrequestreview-1546982502

From jlu at openjdk.org  Wed Jul 26 07:18:22 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Jul 2023 07:18:22 GMT
Subject: RFR: 8312416: Tests in Locale should have more descriptive names
Message-ID: <PrykfUm6DeNNoi2uQ9YR74Ae5Y0Fcn7S1-45ola7Qeo=.d158464f-ed6c-4cec-bcdd-2c998bc0934d@github.com>

Please review this change which renames tests for Locale from `bugNNNNNNN.java` to something more descriptive.

In addition to the name changes, accompanying copyright year, name usage within the test, and other minor changes were included. The test `bug4123285.java` was also removed, as it was never actually ran and java.applet.Applet is deprecated and marked for removal.

-------------

Commit messages:
 - Copyright years, import cleanup, name within file, etc.
 - Rename files and remove unusued test files

Changes: https://git.openjdk.org/jdk/pull/15032/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15032&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312416
  Stats: 265 lines in 16 files changed: 93 ins; 138 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/15032.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15032/head:pull/15032

PR: https://git.openjdk.org/jdk/pull/15032

From jlu at openjdk.org  Wed Jul 26 07:44:58 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Jul 2023 07:44:58 GMT
Subject: RFR: 8312411: MessageFormat.formatToCharacterIterator() can be
 improved
Message-ID: <SvBOR63sGUuLf0dWrmAV9vbyHNN2mf3wZIefKffPGl0=.05694f16-665d-407c-87b8-6b19041cf2d3@github.com>

Please review this change which makes `MessageFormat.formatToCharacterIterator` fail fast(er). The return statement is also modified to call  toArray() as `toArray(new T[0])` over `toArray(new T[size])`.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/15035/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15035&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312411
  Stats: 7 lines in 1 file changed: 1 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15035/head:pull/15035

PR: https://git.openjdk.org/jdk/pull/15035

From coffeys at openjdk.org  Wed Jul 26 09:22:14 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 26 Jul 2023 09:22:14 GMT
Subject: RFR: 8311653: Modify -XshowSettings launcher behavior [v3]
In-Reply-To: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
References: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
Message-ID: <zn2oxWS8ta0cSnq3r1HT33TmO3Du8GG1-5uPHlxJ20g=.2ff58fe1-91cb-4495-8c20-82bfba59c2eb@github.com>

> Modify the -XshowSettings launcher option to print non-verbose settings details of all components by default. Verbose settings details will be printed via the -XshowSettings:all option. Modify the -XshowSettings option to reject bad values passed to it. Print an error message in such scenarios and abort the VM launch.

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 seven additional commits since the last revision:

 - Merge branch 'master' into 8311653-showSettings-tweak
 - Incorporate changes from Mandys review
 - Incorporate review feedback
 - modify -X output for :all
 - restore imports
 - Abort if bad options input
 - 8311653

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15001/files
  - new: https://git.openjdk.org/jdk/pull/15001/files/688b856d..2df0f0a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15001&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15001&range=01-02

  Stats: 19144 lines in 255 files changed: 7666 ins; 10330 del; 1148 mod
  Patch: https://git.openjdk.org/jdk/pull/15001.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15001/head:pull/15001

PR: https://git.openjdk.org/jdk/pull/15001

From coffeys at openjdk.org  Wed Jul 26 09:22:14 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 26 Jul 2023 09:22:14 GMT
Subject: RFR: 8311653: Modify -XshowSettings launcher behavior [v2]
In-Reply-To: <QJEVGgSn4V03XNkhTAy1WRzwXEYxkTWt-ZXIeNgPiqY=.31f4f333-3b12-416b-88fb-cd440377afac@github.com>
References: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
 <NLlC66xzaMKJ_6it6UzFt2zkOpUZ5_cT_VdfI7pTXkM=.8946220f-975c-4753-b8d7-1956af463a64@github.com>
 <QJEVGgSn4V03XNkhTAy1WRzwXEYxkTWt-ZXIeNgPiqY=.31f4f333-3b12-416b-88fb-cd440377afac@github.com>
Message-ID: <VwbJicDwqrc6Zv_6XijHLtCwPU6tg_qezysDMAQtGeo=.68c13afb-4d06-4fbf-985b-a926a291c128@github.com>

On Tue, 25 Jul 2023 21:01:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Incorporate review feedback
>>  - modify -X output for :all
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 191:
> 
>> 189: 
>> 190:         // case-sensitive check of input flag
>> 191:         List<String> validOpts = Arrays.stream(Option.values())
> 
> The logic can be simplified by building a map of option name to `Option`.
> 
> 
>         Map<String, Option> validOpts = Arrays.stream(Option.values())
>                 .filter(o -> !o.equals(Option.EMPTY)) // non-valid option
>                 .collect(Collectors.toMap(o -> o.name()
>                                                 .toLowerCase(Locale.ROOT)
>                                                 .replace("_", ":"), Function.identity()));
> 
>         String optStr = optionFlag.substring("-XshowSettings:".length());
>         Option component = validOpts.get(optStr);
>         if (component == null) {
>             abort(null, "java.launcher.bad.option", optStr);
>         }
>         return component;

good suggestion Mandy! Incorporated this with latest changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15001#discussion_r1274649094

From alanb at openjdk.org  Wed Jul 26 09:32:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Jul 2023 09:32:43 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
Message-ID: <8i_NF3xA4t8bZnYAJAHVoqNnZGipNqHyvWJJNzY2yC0=.99bd097d-30de-418a-85d0-f212b8b2e842@github.com>

On Tue, 25 Jul 2023 23:50:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.
>
> Brian Burkhalter has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 6478546: Decrease malloc limit to 1.5 MB
>  - 6478546: Minor refactoring
>  - 6478546: Prevent short read

I looked through the latest version (69941de4).

I think the main issue with this version is that it changes behavior of the read methods to work like "read fully", I don't think we should do that. To preserve long standing behavior it should attempt a second/subsequent read when the clamped buffer is filled. I think this is close to what you want here:

    private int readBytes(byte[] b, final int off, int len) throws IOException {
        Objects.checkFromIndexSize(off, len, b.length);
        int nread = 0;
        int pos = off;
        int remaining = len;
        do {
            int size = Math.min(remaining, 64 * 1024);
            try {
                int n = readBytes0(b, pos, size);
                if (n < 0) {
                    // EOF
                    break;
                }
                nread += n;
                if (n < size) {
                    // buffer not filled
                    break;
                }
                pos += n;
                remaining -= n;
            } catch (IOException ioe) {
                if (nread > 0) {
                    break;
                }
                throw ioe;
            }
        } while (remaining > 0);
        return nread;
    }


The changes in 69941de4 are also using nested blockers, this is benign, but if this code is change then they can be dropped from the callers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14981#issuecomment-1651352313

From alanb at openjdk.org  Wed Jul 26 09:32:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Jul 2023 09:32:45 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <TQKdF1tK-JX69deHl8AOrpWqLXqB6d_XTMhm9n4YWZU=.25ebdb14-24a6-42c2-b05f-f1eb74694b62@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <p-UNQRGHEN3aUQTyJljJBcH_gz_N8alzc4yp_jixWDk=.25d9352b-2e8f-4b19-9083-7d1f77e14cf0@github.com>
 <6XShzHu2amAup0TTtPTFTkZMdVVjU1Pr4N2RefUgYmw=.ed3432c4-7376-4295-b9bf-f4709eecd986@github.com>
 <YyfHF6nPOuC-03hxdTcDbW_IpZJ7QnjidzmceldcOx4=.1fd31021-fae7-4125-aa83-7e2a4e5b9c7a@github.com>
 <TQKdF1tK-JX69deHl8AOrpWqLXqB6d_XTMhm9n4YWZU=.25ebdb14-24a6-42c2-b05f-f1eb74694b62@github.com>
Message-ID: <Gpo-foHyzSYXdoV0kY1g5tib_jl7vTGo1fFahTjKcgw=.4706b614-f3f0-4608-80b1-ae3da162c140@github.com>

On Wed, 26 Jul 2023 00:00:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> There was no dropping of the file system cache. I would think this would have more of an effect on measuring the throughput of writing than reading.

In that case, I assume the benchmarks are just reading from the file system cache so there isn't any actual file I/O.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1274666144

From sspitsyn at openjdk.org  Wed Jul 26 09:44:54 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 26 Jul 2023 09:44:54 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked
In-Reply-To: <Ar-k3n5Awr02ccVZvwJkL9VyUVnHZbKW0ln9K5oZmp0=.98dfd87b-a04a-4fae-ad90-055131d8438e@github.com>
References: <Ar-k3n5Awr02ccVZvwJkL9VyUVnHZbKW0ln9K5oZmp0=.98dfd87b-a04a-4fae-ad90-055131d8438e@github.com>
Message-ID: <WiT7SARAp5YlF3Rt7sNt9wfpGAtSEoPgMDjE18-v--g=.14a3969b-09fe-46a5-8792-5b11a6766e82@github.com>

On Fri, 21 Jul 2023 18:01:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread::getState is an API for monitoring and management purposes to report the thread state. If a virtual thread is parked with LockSupport.parkNanos, its state is reported as  WAITING when it should be TIMED_WAITING. JVM TI GetThreadState has the same issue in that it returns JVMTI_THREAD_STATE_WAITING_INDEFINITELY instead of the JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT bit set. Not a very visible issue because JDWP maps both states to "WAIT" but it may be noticed by tools using other JVM TI agents.
> 
> The change is straight-forward, it's just additional state bit to indicate that park is timed. The existing virtual/ThreadAPI.java test is expanded to this scenario. A new test is added for JVM TI GetThreadState to test waiting/timed-waited cases (including pinned) as test coverage seems patchy here.

test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java line 133:

> 131:         } finally {
> 132:             thread.join();
> 133:             Reference.reachabilityFence(lock);

It would be nice to add a short comment why this is needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1274681311

From alanb at openjdk.org  Wed Jul 26 10:17:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Jul 2023 10:17:55 GMT
Subject: [jdk21] RFR: 8309032: jpackage does not work for module projects
 unless --module-path is specified
In-Reply-To: <khVEunM-YRHazea_VYfd_SX8Vqy83K0wNhRSuxWmVQY=.e1c5052d-3c9d-4fa5-a3fb-0d5456df56d0@github.com>
References: <H9una8oci7mgFejlqQHPTMQjMXcHr8eG3A1dNMzUwjg=.24a2b5bb-0918-487f-8bec-c3809f6376c3@github.com>
 <khVEunM-YRHazea_VYfd_SX8Vqy83K0wNhRSuxWmVQY=.e1c5052d-3c9d-4fa5-a3fb-0d5456df56d0@github.com>
Message-ID: <bJEOtJSL5oAMyv1gxtK2PMp1q56bcegOvX-3b3LOOKE=.36229463-5d83-484d-a50f-730ffb1bc808@github.com>

On Tue, 25 Jul 2023 07:09:55 GMT, airsquared <duke at openjdk.org> wrote:

> I see. I'll create a PR there. Thanks.

Thanks, I assume this PR can be closed.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/140#issuecomment-1651454738

From duke at openjdk.org  Wed Jul 26 11:08:58 2023
From: duke at openjdk.org (dan1st)
Date: Wed, 26 Jul 2023 11:08:58 GMT
Subject: RFR: 8311517: ArrayList javadoc improvements related to sequenced
 collection updates
Message-ID: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>

The [JEP for sequenced collections](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 PR updates that Javadoc to factor in the new methods introduced by JEP 431.

https://bugs.openjdk.org/browse/JDK-8311517
https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html
https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109637.html

This PR only affects documentation.

-------------

Commit messages:
 - 8311517: ArrayList javadoc improvements related to sequenced collection updates

Changes: https://git.openjdk.org/jdk/pull/15040/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15040&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311517
  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15040/head:pull/15040

PR: https://git.openjdk.org/jdk/pull/15040

From cstein at openjdk.org  Wed Jul 26 12:02:08 2023
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 26 Jul 2023 12:02:08 GMT
Subject: RFR: 8313155: Problem list some JUnit-based tests in
 test/jdk/java/lang/invoke
Message-ID: <ahYVgQBP9ZxcylzJdDa8wEkKc65LnmKitTWTSKcML8g=.a5938804-dfa0-4197-8e8f-25320ba896a2@github.com>

Problem list some JUnit-based tests in `test/jdk/java/lang/invoke/MethodHandleProxies/` for the time being - until `jtreg` 7.3 with a fix for the underlying race condition is released. That fix is tracked via https://bugs.openjdk.org/browse/CODETOOLS-7903507

-------------

Commit messages:
 - Use correct bug ID number
 - 8313155: Problem list some JUnit-based tests in test/jdk/java/lang/invoke

Changes: https://git.openjdk.org/jdk/pull/15034/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15034&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313155
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15034.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15034/head:pull/15034

PR: https://git.openjdk.org/jdk/pull/15034

From dholmes at openjdk.org  Wed Jul 26 12:04:48 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Jul 2023 12:04:48 GMT
Subject: RFR: 8313155: Problem list some JUnit-based tests in
 test/jdk/java/lang/invoke
In-Reply-To: <ahYVgQBP9ZxcylzJdDa8wEkKc65LnmKitTWTSKcML8g=.a5938804-dfa0-4197-8e8f-25320ba896a2@github.com>
References: <ahYVgQBP9ZxcylzJdDa8wEkKc65LnmKitTWTSKcML8g=.a5938804-dfa0-4197-8e8f-25320ba896a2@github.com>
Message-ID: <64Ah_-eJ2RCTdT6a7sMVXzzS0ceBur3kMh6hoknUjRM=.ddde89fb-cf2e-4792-b3e2-5314e18d8005@github.com>

On Wed, 26 Jul 2023 07:25:20 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Problem list some JUnit-based tests in `test/jdk/java/lang/invoke/MethodHandleProxies/` for the time being - until `jtreg` 7.3 with a fix for the underlying race condition is released. That fix is tracked via https://bugs.openjdk.org/browse/CODETOOLS-7903507

Looks good. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15034#pullrequestreview-1547567820

From dholmes at openjdk.org  Wed Jul 26 12:23:42 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Jul 2023 12:23:42 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked
In-Reply-To: <ixsswHs5-fsFogmPvJ56KHonX9VbsAYnA8laPcoZ09M=.afe8edfd-168b-4134-8932-603244bae3a4@github.com>
References: <Ar-k3n5Awr02ccVZvwJkL9VyUVnHZbKW0ln9K5oZmp0=.98dfd87b-a04a-4fae-ad90-055131d8438e@github.com>
 <2rTLX86raFjJBNOlUysJoxGB8UaGLH7szSa_EOmXEDE=.e545fc08-9354-4173-b88f-b8173c3878b7@github.com>
 <ixsswHs5-fsFogmPvJ56KHonX9VbsAYnA8laPcoZ09M=.afe8edfd-168b-4134-8932-603244bae3a4@github.com>
Message-ID: <ubo8BmAq_enLfoetleR9Ny21H2TR5mHMzIBUmXFJV5w=.6a2a2e37-df20-4c1f-87c6-dc438d531cae@github.com>

On Tue, 25 Jul 2023 05:50:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.hpp line 536:
>> 
>>> 534: 
>>> 535:     // additional state bits
>>> 536:     TIMED        = 1 << 8,   // timed parked
>> 
>> Why handle TIMED this way instead of just making TIMED_PARKED/PARKING states?
>
>> Why handle TIMED this way instead of just making TIMED_PARKED/PARKING states?
> 
> Been there but it is 3 additional states and a lot simpler to just use the additional state bits, like we do with SUSPENDED. We might use another one for special casing sleeping, if the need arises.

Yes but TIMED and SUSPENDED are not alike. I assume SUSPENDED is a stand-alone bit because you can be in various states and suspended at the same time. But TIMED isn't like that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1274871863

From dholmes at openjdk.org  Wed Jul 26 12:23:45 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Jul 2023 12:23:45 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked
In-Reply-To: <WiT7SARAp5YlF3Rt7sNt9wfpGAtSEoPgMDjE18-v--g=.14a3969b-09fe-46a5-8792-5b11a6766e82@github.com>
References: <Ar-k3n5Awr02ccVZvwJkL9VyUVnHZbKW0ln9K5oZmp0=.98dfd87b-a04a-4fae-ad90-055131d8438e@github.com>
 <WiT7SARAp5YlF3Rt7sNt9wfpGAtSEoPgMDjE18-v--g=.14a3969b-09fe-46a5-8792-5b11a6766e82@github.com>
Message-ID: <F38MG81847StSmL4MfHFuf92ios5gEQDyZTyk_4exuQ=.22d4f222-d86f-4804-a148-8bf83c3877e4@github.com>

On Wed, 26 Jul 2023 09:42:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Thread::getState is an API for monitoring and management purposes to report the thread state. If a virtual thread is parked with LockSupport.parkNanos, its state is reported as  WAITING when it should be TIMED_WAITING. JVM TI GetThreadState has the same issue in that it returns JVMTI_THREAD_STATE_WAITING_INDEFINITELY instead of the JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT bit set. Not a very visible issue because JDWP maps both states to "WAIT" but it may be noticed by tools using other JVM TI agents.
>> 
>> The change is straight-forward, it's just additional state bit to indicate that park is timed. The existing virtual/ThreadAPI.java test is expanded to this scenario. A new test is added for JVM TI GetThreadState to test waiting/timed-waited cases (including pinned) as test coverage seems patchy here.
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java line 133:
> 
>> 131:         } finally {
>> 132:             thread.join();
>> 133:             Reference.reachabilityFence(lock);
> 
> It would be nice to add a short comment why this is needed.

I can't see why it would be needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1274874943

From jpai at openjdk.org  Wed Jul 26 12:33:39 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Jul 2023 12:33:39 GMT
Subject: RFR: 8313155: Problem list some JUnit-based tests in
 test/jdk/java/lang/invoke
In-Reply-To: <ahYVgQBP9ZxcylzJdDa8wEkKc65LnmKitTWTSKcML8g=.a5938804-dfa0-4197-8e8f-25320ba896a2@github.com>
References: <ahYVgQBP9ZxcylzJdDa8wEkKc65LnmKitTWTSKcML8g=.a5938804-dfa0-4197-8e8f-25320ba896a2@github.com>
Message-ID: <qOtdUjTrMfbvZK2fpsq_Wa-8ZOM2HwGERM0OdNDq5CE=.10c3bf26-c9ec-4467-9112-2b218da9fd96@github.com>

On Wed, 26 Jul 2023 07:25:20 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Problem list some JUnit-based tests in `test/jdk/java/lang/invoke/MethodHandleProxies/` for the time being - until `jtreg` 7.3 with a fix for the underlying race condition is released. That fix is tracked via https://bugs.openjdk.org/browse/CODETOOLS-7903507

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15034#pullrequestreview-1547618592

From cstein at openjdk.org  Wed Jul 26 13:44:54 2023
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 26 Jul 2023 13:44:54 GMT
Subject: Integrated: 8313155: Problem list some JUnit-based tests in
 test/jdk/java/lang/invoke
In-Reply-To: <ahYVgQBP9ZxcylzJdDa8wEkKc65LnmKitTWTSKcML8g=.a5938804-dfa0-4197-8e8f-25320ba896a2@github.com>
References: <ahYVgQBP9ZxcylzJdDa8wEkKc65LnmKitTWTSKcML8g=.a5938804-dfa0-4197-8e8f-25320ba896a2@github.com>
Message-ID: <_d1ahSej-FghUyj6u9IAHDmD-xfYpJTWVEJmGaTVHxs=.036827d8-e982-4a96-82ac-fdfdb005b044@github.com>

On Wed, 26 Jul 2023 07:25:20 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Problem list some JUnit-based tests in `test/jdk/java/lang/invoke/MethodHandleProxies/` for the time being - until `jtreg` 7.3 with a fix for the underlying race condition is released. That fix is tracked via https://bugs.openjdk.org/browse/CODETOOLS-7903507

This pull request has now been integrated.

Changeset: e7726fbd
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7726fbd69232bfa34725c87a7dfd387cce118a0
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8313155: Problem list some JUnit-based tests in test/jdk/java/lang/invoke

Reviewed-by: dholmes, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/15034

From mcimadamore at openjdk.org  Wed Jul 26 14:23:51 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 26 Jul 2023 14:23:51 GMT
Subject: RFR: 8313023: Return value corrupted when using CCS + isTrivial
 (mainline)
In-Reply-To: <OO6MXUJA8WN4KaZQ5s8f09My73TaVD8Fd4uqVTpRpdo=.ca97bc20-6eff-4855-8fde-cde634c71236@github.com>
References: <OO6MXUJA8WN4KaZQ5s8f09My73TaVD8Fd4uqVTpRpdo=.ca97bc20-6eff-4855-8fde-cde634c71236@github.com>
Message-ID: <vLSdWZDIByKhbfFl8-SV7ozzkiIUJk__nll506CUcPc=.1f0de150-2d41-4a1b-9501-e29424add57b@github.com>

On Tue, 25 Jul 2023 19:17:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Port of: https://github.com/openjdk/panama-foreign/pull/848 from the panama-foreign repo.
> 
> Copying the PR body here for convenience:
> 
> Due to a bug in the downcall linker stub generation, we don't save the return value when capturing call state for trivial functions, and the return value gets corrupted.
> 
> We try not to save the return register around calls on the return path of a downcall stub, if it is not needed. Currently we don't save the return register when we're using a return buffer, since we write the return value to the return buffer before the calls on the return path, which means it is safe for those calls to overwrite the return register. But, the current logic also says we don't need to save the return register if the function is trivial (_needs_transition == false). The logic behind this was initially that, since we don't have any calls on the return path, we don't need to save the return register. But, after adding support for capturing call state, we now also have a call on the return path for trivial functions that capture call state, and around that call, we might need to save the return register.
> 
> The fix is to simply save the return register when capturing call state, regardless of whether the function is trivial or not. In the case of just a trivial function that doesn't capture call state, we still don't save the return register around the return path calls for the thread state transition (which is not needed), since we don't generate those thread state transitions in the first first place.
> 
> Testing: jdk-tier1, jdk-tier2, jdk-tier5.

Looks good (already approved in panama repo)

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15025#pullrequestreview-1547859411

From pminborg at openjdk.org  Wed Jul 26 14:44:01 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 26 Jul 2023 14:44:01 GMT
Subject: RFR: 8298095: Refine implSpec for SegmentAllocator [v3]
In-Reply-To: <MYKIf86teO-EoEjeqII6aRsex4ZBxS9bOAQHRS5c59o=.39a950db-d4e6-40a8-bd40-80822fea06da@github.com>
References: <MYKIf86teO-EoEjeqII6aRsex4ZBxS9bOAQHRS5c59o=.39a950db-d4e6-40a8-bd40-80822fea06da@github.com>
Message-ID: <0IrtNsnUT5e2byRsb28hFPso7jWPXY3vgXnCeGcPSP0=.02fbec3c-d078-47b6-9330-0425b7ffb52c@github.com>

> This PR suggests refining the `@implSpec` for the SegmentAllocator::allocate methods as well as clarifying the docs a bit more. Also, a local variable is renamed.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update after comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14997/files
  - new: https://git.openjdk.org/jdk/pull/14997/files/e4d0a4bc..66b1c8e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14997&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14997&range=01-02

  Stats: 139 lines in 1 file changed: 39 ins; 5 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/14997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14997/head:pull/14997

PR: https://git.openjdk.org/jdk/pull/14997

From bpb at openjdk.org  Wed Jul 26 15:11:51 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 26 Jul 2023 15:11:51 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <2MM-OcX_oc5491kksCMjJhXE3c0eYCYLwBdj-9MZ2cA=.9b082e4f-1df7-4e29-8176-722cd86d349c@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
 <2MM-OcX_oc5491kksCMjJhXE3c0eYCYLwBdj-9MZ2cA=.9b082e4f-1df7-4e29-8176-722cd86d349c@github.com>
Message-ID: <991lmzFzxd6btX7s6rCSyaCPL6Bh0J_KwBUIshFwT10=.4100e3a0-40a5-4fa9-920b-0343582dbd22@github.com>

On Wed, 26 Jul 2023 05:26:52 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - 6478546: Decrease malloc limit to 1.5 MB
>>  - 6478546: Minor refactoring
>>  - 6478546: Prevent short read
>
> src/java.base/share/native/libjava/io_util.c line 163:
> 
>> 161:     }
>> 162: 
>> 163:     if (outOfBounds(env, off, len, bytes)) {
> 
> we are already performing this check at Java level, do we need the perform this check again ?

Please refer to my prior [comment](https://github.com/openjdk/jdk/pull/14981#issuecomment-1646312987).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1275120710

From bpb at openjdk.org  Wed Jul 26 15:48:53 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 26 Jul 2023 15:48:53 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <8i_NF3xA4t8bZnYAJAHVoqNnZGipNqHyvWJJNzY2yC0=.99bd097d-30de-418a-85d0-f212b8b2e842@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
 <8i_NF3xA4t8bZnYAJAHVoqNnZGipNqHyvWJJNzY2yC0=.99bd097d-30de-418a-85d0-f212b8b2e842@github.com>
Message-ID: <pNk9HkSBQ5aiTxXfZl-AbLMrIZuXUsl3_XLXxWrLJ88=.8b1d43e3-b713-4fb3-83b0-bf2c093f5106@github.com>

On Wed, 26 Jul 2023 09:29:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think the main issue with this version is that it changes behavior of the read methods to work like "read fully", I don't think we should do that.

To me it looks more like `readNBytes`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14981#issuecomment-1652080776

From pminborg at openjdk.org  Wed Jul 26 15:50:10 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 26 Jul 2023 15:50:10 GMT
Subject: RFR: 8310643: Misformatted copyright messages in FFM
Message-ID: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>

This PR suggests updating some of the ill-formed copyright headers in the FFM API and the implementation and test thereof.

Some of the test files will have now the "classpath" exception. Is this correct?

-------------

Commit messages:
 - Update copyright formatting

Changes: https://git.openjdk.org/jdk/pull/15042/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15042&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310643
  Stats: 1083 lines in 54 files changed: 169 ins; 114 del; 800 mod
  Patch: https://git.openjdk.org/jdk/pull/15042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15042/head:pull/15042

PR: https://git.openjdk.org/jdk/pull/15042

From bpb at openjdk.org  Wed Jul 26 15:52:54 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 26 Jul 2023 15:52:54 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <7jYPsgbYJLiMIA-ZhtlS-jZKatNX58pVD9mcMFw2Jzc=.4fd7dfb6-44be-4b58-9ba3-ff3f58e372a8@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
 <7jYPsgbYJLiMIA-ZhtlS-jZKatNX58pVD9mcMFw2Jzc=.4fd7dfb6-44be-4b58-9ba3-ff3f58e372a8@github.com>
Message-ID: <tEQKWU1g4H2AicWT4VjkVcZKBwGQHvdHVYyI-DZRMNs=.05f3fc13-bd54-4adc-821a-4a6c6c4bba7a@github.com>

On Wed, 26 Jul 2023 05:31:57 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> please reformat line 173

Why?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1275174632

From dcubed at openjdk.org  Wed Jul 26 15:53:25 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 26 Jul 2023 15:53:25 GMT
Subject: [jdk21] RFR: 8313193: ProblemList
 java/util/concurrent/SynchronousQueue/Fairness.java on X64
Message-ID: <vCAVfsxieuJX568xekuvWGPJasdVbhzyi-eRUIVIEgY=.e8270fbe-3124-4322-ba22-193a7a295120@github.com>

A trivial fix to ProblemList java/util/concurrent/SynchronousQueue/Fairness.java on X64.

-------------

Commit messages:
 - 8313193: ProblemList java/util/concurrent/SynchronousQueue/Fairness.java on X64

Changes: https://git.openjdk.org/jdk21/pull/144/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=144&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313193
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk21/pull/144.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/144/head:pull/144

PR: https://git.openjdk.org/jdk21/pull/144

From vtewari at openjdk.org  Wed Jul 26 16:00:52 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 26 Jul 2023 16:00:52 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <tEQKWU1g4H2AicWT4VjkVcZKBwGQHvdHVYyI-DZRMNs=.05f3fc13-bd54-4adc-821a-4a6c6c4bba7a@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
 <7jYPsgbYJLiMIA-ZhtlS-jZKatNX58pVD9mcMFw2Jzc=.4fd7dfb6-44be-4b58-9ba3-ff3f58e372a8@github.com>
 <tEQKWU1g4H2AicWT4VjkVcZKBwGQHvdHVYyI-DZRMNs=.05f3fc13-bd54-4adc-821a-4a6c6c4bba7a@github.com>
Message-ID: <6OemrpkFaGPYsX6Bftibu3choJWoR3tJCx0lNkLMX0s=.b4d313fc-a245-400d-a2f9-1c84df7a205e@github.com>

On Wed, 26 Jul 2023 15:49:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/native/libjava/io_util.c line 173:
>> 
>>> 171:         if (len > MAX_MALLOC_SIZE)
>>> 172:             len = MAX_MALLOC_SIZE;
>>> 173:         buf = (char*)malloc(len*sizeof(char));
>> 
>> please reformat line 173
>
>> please reformat line 173
> 
> Why?

"buf = (char*)malloc(len*sizeof(char));" --> "buf = (char*)malloc(len * sizeof(char));"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1275185140

From bpb at openjdk.org  Wed Jul 26 16:08:56 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 26 Jul 2023 16:08:56 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <6OemrpkFaGPYsX6Bftibu3choJWoR3tJCx0lNkLMX0s=.b4d313fc-a245-400d-a2f9-1c84df7a205e@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
 <7jYPsgbYJLiMIA-ZhtlS-jZKatNX58pVD9mcMFw2Jzc=.4fd7dfb6-44be-4b58-9ba3-ff3f58e372a8@github.com>
 <tEQKWU1g4H2AicWT4VjkVcZKBwGQHvdHVYyI-DZRMNs=.05f3fc13-bd54-4adc-821a-4a6c6c4bba7a@github.com>
 <6OemrpkFaGPYsX6Bftibu3choJWoR3tJCx0lNkLMX0s=.b4d313fc-a245-400d-a2f9-1c84df7a205e@github.com>
Message-ID: <cDAHB0HVbov8h8x5tL8zqBOOT8K7_S5kbfj_HechjP4=.ca189564-7345-4477-ba04-2bb878b74817@github.com>

On Wed, 26 Jul 2023 15:58:15 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>>> please reformat line 173
>> 
>> Why?
>
> "buf = (char*)malloc(len*sizeof(char));" --> "buf = (char*)malloc(len * sizeof(char));"

> "buf = (char*)malloc(len_sizeof(char));" --> "buf = (char_)malloc(len * sizeof(char));"

Both sides of this are wrong.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1275193937

From mchung at openjdk.org  Wed Jul 26 16:30:53 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 26 Jul 2023 16:30:53 GMT
Subject: RFR: 8311653: Modify -XshowSettings launcher behavior [v3]
In-Reply-To: <zn2oxWS8ta0cSnq3r1HT33TmO3Du8GG1-5uPHlxJ20g=.2ff58fe1-91cb-4495-8c20-82bfba59c2eb@github.com>
References: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
 <zn2oxWS8ta0cSnq3r1HT33TmO3Du8GG1-5uPHlxJ20g=.2ff58fe1-91cb-4495-8c20-82bfba59c2eb@github.com>
Message-ID: <d0SGWJuoHzJWqsO1YV1b1gCtBSkAWNJSzX6_6c9df4w=.bc05bd14-9941-40df-aa43-4b00ec296333@github.com>

On Wed, 26 Jul 2023 09:22:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Modify the -XshowSettings launcher option to print non-verbose settings details of all components by default. Verbose settings details will be printed via the -XshowSettings:all option. Modify the -XshowSettings option to reject bad values passed to it. Print an error message in such scenarios and abort the VM launch.
>
> 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into 8311653-showSettings-tweak
>  - Incorporate changes from Mandys review
>  - Incorporate review feedback
>  - modify -X output for :all
>  - restore imports
>  - Abort if bad options input
>  - 8311653

Looks good.

Regarding the CSR, the specification change says:

> Bad options such as -XshowSettings:bad will no longer print any settings information. Instead a warning and help message is printed and the VM launch is aborted.

This should be updated as it will abort with an error message if the option is invalid.  No warning and help message is printed.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15001#pullrequestreview-1548154706

From rriggs at openjdk.org  Wed Jul 26 16:46:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 26 Jul 2023 16:46:54 GMT
Subject: RFR: 8311653: Modify -XshowSettings launcher behavior [v3]
In-Reply-To: <zn2oxWS8ta0cSnq3r1HT33TmO3Du8GG1-5uPHlxJ20g=.2ff58fe1-91cb-4495-8c20-82bfba59c2eb@github.com>
References: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
 <zn2oxWS8ta0cSnq3r1HT33TmO3Du8GG1-5uPHlxJ20g=.2ff58fe1-91cb-4495-8c20-82bfba59c2eb@github.com>
Message-ID: <EXRfigTnVdClpO7oG0IiLo4RZxRWRogvciymaKKz7fg=.12a3840f-6384-4f03-8550-3b2ffdf6a5e1@github.com>

On Wed, 26 Jul 2023 09:22:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Modify the -XshowSettings launcher option to print non-verbose settings details of all components by default. Verbose settings details will be printed via the -XshowSettings:all option. Modify the -XshowSettings option to reject bad values passed to it. Print an error message in such scenarios and abort the VM launch.
>
> 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into 8311653-showSettings-tweak
>  - Incorporate changes from Mandys review
>  - Incorporate review feedback
>  - modify -X output for :all
>  - restore imports
>  - Abort if bad options input
>  - 8311653

Looks good

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15001#pullrequestreview-1548182284

From rriggs at openjdk.org  Wed Jul 26 16:48:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 26 Jul 2023 16:48:02 GMT
Subject: [jdk21] RFR: 8313193: ProblemList
 java/util/concurrent/SynchronousQueue/Fairness.java on X64
In-Reply-To: <vCAVfsxieuJX568xekuvWGPJasdVbhzyi-eRUIVIEgY=.e8270fbe-3124-4322-ba22-193a7a295120@github.com>
References: <vCAVfsxieuJX568xekuvWGPJasdVbhzyi-eRUIVIEgY=.e8270fbe-3124-4322-ba22-193a7a295120@github.com>
Message-ID: <qlbqaueeRabQlDSi0dP3Mq2sieGPGZeF74zLg4GN7Bw=.d2c620d0-d7d5-4dee-b344-15bf4380f317@github.com>

On Wed, 26 Jul 2023 15:47:48 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/SynchronousQueue/Fairness.java on X64.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/144#pullrequestreview-1548184357

From dcubed at openjdk.org  Wed Jul 26 16:51:58 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 26 Jul 2023 16:51:58 GMT
Subject: [jdk21] RFR: 8313193: ProblemList
 java/util/concurrent/SynchronousQueue/Fairness.java on X64
In-Reply-To: <qlbqaueeRabQlDSi0dP3Mq2sieGPGZeF74zLg4GN7Bw=.d2c620d0-d7d5-4dee-b344-15bf4380f317@github.com>
References: <vCAVfsxieuJX568xekuvWGPJasdVbhzyi-eRUIVIEgY=.e8270fbe-3124-4322-ba22-193a7a295120@github.com>
 <qlbqaueeRabQlDSi0dP3Mq2sieGPGZeF74zLg4GN7Bw=.d2c620d0-d7d5-4dee-b344-15bf4380f317@github.com>
Message-ID: <01N9Ju13KHgdxEt6Hufe7AMQlGRsBZgZQetdSyxtoNk=.a52f7667-c37e-4a59-a5dd-062e827fc290@github.com>

On Wed, 26 Jul 2023 16:44:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> A trivial fix to ProblemList java/util/concurrent/SynchronousQueue/Fairness.java on X64.
>
> Marked as reviewed by rriggs (Reviewer).

@RogerRiggs - Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/144#issuecomment-1652170819

From iklam at openjdk.org  Wed Jul 26 17:22:41 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 26 Jul 2023 17:22:41 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v2]
In-Reply-To: <PlLziaxnr3lJpWWJTb8cNXhNVRXIjZhW3RyWCudUYvE=.0720bfaf-6401-461f-bdb0-06ce7b097d87@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
 <PlLziaxnr3lJpWWJTb8cNXhNVRXIjZhW3RyWCudUYvE=.0720bfaf-6401-461f-bdb0-06ce7b097d87@github.com>
Message-ID: <qTsD40Pd3UMDJ6nZwhnyxY9iUcgZ5I8ysXLgyiN4T8c=.4f7eeb07-fe1b-4865-bfcc-bfd4b40675e5@github.com>

On Tue, 25 Jul 2023 18:48:58 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 
>> 
>> 
>>  // We have finished dumping the static archive. At this point, there may be pending VM
>>  // operations. We have changed some global states (such as vmClasses::_klasses) that
>>  // may cause these VM operations to fail. For safety, forget these operations and
>>  // exit the VM directly.
>>  void MetaspaceShared::exit_after_static_dump() {
>>    os::_exit(0);
>>  } 
>> 
>> 
>> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
>> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
>> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
>> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.
>> 
>> Verified with tier 1-9 tests.
>
> Matias Saavedra Silva has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge fix
>  - Restores java loaders
>  - Ioi and David comments
>  - Windows fix
>  - 8306582: Remove MetaspaceShared::exit_after_static_dump()

Looks good overall. Some suggestions for code refactoring.

src/hotspot/share/cds/heapShared.cpp line 377:

> 375:   return *(_scratch_references_table->get(src));
> 376: }
> 377: 

The logic of these two new functions are covered by the KlassToOopHandleTable class, so I would suggest refactoring   KlassToOopHandleTable to


class MetaspaceObjToOopHandleTable: public ResourceHashtable<MetaspaceObj*, OopHandle, ...


So your new "scratch_resolved_references" functions can be similar to `HeapShared::scratch_java_mirror/set_scratch_java_mirror`.

Also, this function needs to be updated


void HeapShared::remove_scratch_objects(Klass* k) {
  _scratch_java_mirror_table->remove_oop(k);
  if (k->is_instance_klass()) {
    _scratch_resolved_references_table->remove(InstanceKlass::cast(k)->constants());
  }
}

src/hotspot/share/oops/constantPool.cpp line 303:

> 301:     for (int i = 0; i < rr_len; i++) {
> 302:       oop obj = rr->obj_at(i);
> 303:       HeapShared::add_scratch_resolved_reference(orig_pool, i, nullptr);

I think the logic can be more obvious of the the management of the contents of the `scratch_rr` array is moved here. Something like:


if (rr != nullptr) {
  scratch_rr = HeapShared::scratch_resolved_references(orig_pool);
  
  .... scratch_rr->obj_at_put(i, nullptr);
  ....
  return scratch_rr;
 } 


That way, you won't have two functions with similar sounding names `add_scratch_resolved_reference` and `add_scratch_resolved_references`. HeapShared is now solely responsible for keeping track of the scratch arrays, but ConstantPool will be responsible for the contents of the scratch arrays.

Also, it's not necessary to put the `scratch_rr` in an `OopHandle` as we won't safepoint in this loop.

-------------

Changes requested by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14879#pullrequestreview-1548221065
PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1275271843
PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1275259540

From bpb at openjdk.org  Wed Jul 26 17:30:51 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 26 Jul 2023 17:30:51 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
Message-ID: <AFltMhAqcKmc7Y6u6A6V14R8lJWfE6WeIsAYy9mWyPQ=.33633ee2-68ce-494c-9fd6-1b5e5f5d4418@github.com>

On Tue, 25 Jul 2023 23:50:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.
>
> Brian Burkhalter has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 6478546: Decrease malloc limit to 1.5 MB
>  - 6478546: Minor refactoring
>  - 6478546: Prevent short read

> The changes in [69941de](https://github.com/openjdk/jdk/commit/69941de4aa27ee34d957621d73c77942237c33cd) are also using nested blockers, this is benign, but if this code is change then they can be dropped from the callers.

I don't see where this is happening.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14981#issuecomment-1652223466

From alanb at openjdk.org  Wed Jul 26 17:40:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Jul 2023 17:40:41 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked
In-Reply-To: <F38MG81847StSmL4MfHFuf92ios5gEQDyZTyk_4exuQ=.22d4f222-d86f-4804-a148-8bf83c3877e4@github.com>
References: <Ar-k3n5Awr02ccVZvwJkL9VyUVnHZbKW0ln9K5oZmp0=.98dfd87b-a04a-4fae-ad90-055131d8438e@github.com>
 <WiT7SARAp5YlF3Rt7sNt9wfpGAtSEoPgMDjE18-v--g=.14a3969b-09fe-46a5-8792-5b11a6766e82@github.com>
 <F38MG81847StSmL4MfHFuf92ios5gEQDyZTyk_4exuQ=.22d4f222-d86f-4804-a148-8bf83c3877e4@github.com>
Message-ID: <c_Zt5keGMFPn8C7FX9j_JHO5wduFyrid8nXMJLyk7hM=.fbda8336-04c6-4225-84d7-d5b3d2bc99d0@github.com>

On Wed, 26 Jul 2023 12:20:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java line 133:
>> 
>>> 131:         } finally {
>>> 132:             thread.join();
>>> 133:             Reference.reachabilityFence(lock);
>> 
>> It would be nice to add a short comment why this is needed.
>
> I can't see why it would be needed.

> It would be nice to add a short comment why this is needed.

It's not needed here, it was needed in another version of the tests. While benign, I can remove it to avoid any confusion. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1275293060

From bpb at openjdk.org  Wed Jul 26 17:44:55 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 26 Jul 2023 17:44:55 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
Message-ID: <goZYHrr80pqKBC7v_nhB42yMIHqdPzWu0gjgk5g4J68=.f9dc4dba-c371-42e9-a801-b0b4e5ce77e9@github.com>

On Tue, 25 Jul 2023 23:50:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.
>
> Brian Burkhalter has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 6478546: Decrease malloc limit to 1.5 MB
>  - 6478546: Minor refactoring
>  - 6478546: Prevent short read

The EOF handling in the above should be

                    if (n < 0) {
                        // EOF
                        if (nread == 0)
                            return -1;
                        break;
                    }

or zero will be returned if EOF is encountered on the first read (I made the same mistake in code that was not checked in).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14981#issuecomment-1652242356

From dcubed at openjdk.org  Wed Jul 26 18:54:58 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 26 Jul 2023 18:54:58 GMT
Subject: [jdk21] Integrated: 8313193: ProblemList
 java/util/concurrent/SynchronousQueue/Fairness.java on X64
In-Reply-To: <vCAVfsxieuJX568xekuvWGPJasdVbhzyi-eRUIVIEgY=.e8270fbe-3124-4322-ba22-193a7a295120@github.com>
References: <vCAVfsxieuJX568xekuvWGPJasdVbhzyi-eRUIVIEgY=.e8270fbe-3124-4322-ba22-193a7a295120@github.com>
Message-ID: <gas4b1JB5XQ14kPad79KdmCe7Bh8Y76EDy-mOUdxuvM=.47db53dd-458a-48fd-a4d2-bed4dea30d08@github.com>

On Wed, 26 Jul 2023 15:47:48 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/SynchronousQueue/Fairness.java on X64.

This pull request has now been integrated.

Changeset: f666e606
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/f666e606810a0a32864c1dbd8ea493da7e980d8a
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8313193: ProblemList java/util/concurrent/SynchronousQueue/Fairness.java on X64

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk21/pull/144

From alanb at openjdk.org  Wed Jul 26 18:55:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Jul 2023 18:55:56 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v2]
In-Reply-To: <PlLziaxnr3lJpWWJTb8cNXhNVRXIjZhW3RyWCudUYvE=.0720bfaf-6401-461f-bdb0-06ce7b097d87@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
 <PlLziaxnr3lJpWWJTb8cNXhNVRXIjZhW3RyWCudUYvE=.0720bfaf-6401-461f-bdb0-06ce7b097d87@github.com>
Message-ID: <f6-guImxr7rHF3KKRBCdPOXl2Yq7EE3I2lQ-5ipFHl8=.6bee70e0-a0e9-433d-bb54-864fd199a9ff@github.com>

On Tue, 25 Jul 2023 18:48:58 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 
>> 
>> 
>>  // We have finished dumping the static archive. At this point, there may be pending VM
>>  // operations. We have changed some global states (such as vmClasses::_klasses) that
>>  // may cause these VM operations to fail. For safety, forget these operations and
>>  // exit the VM directly.
>>  void MetaspaceShared::exit_after_static_dump() {
>>    os::_exit(0);
>>  } 
>> 
>> 
>> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
>> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
>> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
>> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.
>> 
>> Verified with tier 1-9 tests.
>
> Matias Saavedra Silva has updated the pull request with a new target base 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 fix
>  - Restores java loaders
>  - Ioi and David comments
>  - Windows fix
>  - 8306582: Remove MetaspaceShared::exit_after_static_dump()

src/java.base/share/native/libjli/java.c line 464:

> 462:     if (dumpSharedSpaces) {
> 463:       CHECK_EXCEPTION_LEAVE(0);
> 464:       LEAVE();

What is exit status ($?) when -Xshare:dump fails. It looks like any pending exception will be printed and it will exit with 0 but maybe I've missed something.

In passing, the java launcher uses 4-space indent rather than 2.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1275366634

From asemenyuk at openjdk.org  Wed Jul 26 18:56:58 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 26 Jul 2023 18:56:58 GMT
Subject: RFR: 8311104: dangling-gsl warning in libwixhelper.cpp
Message-ID: <NQQrL4Ek8bE-ERRKK24i-5ktl2Fu1g-Vi0-DSK7wgI8=.e35b1911-46c5-4e49-b1c6-d97886782abb@github.com>

8311104: dangling-gsl warning in libwixhelper.cpp

-------------

Commit messages:
 - 8311104: dangling-gsl warning in libwixhelper.cpp

Changes: https://git.openjdk.org/jdk/pull/15044/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15044&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311104
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15044/head:pull/15044

PR: https://git.openjdk.org/jdk/pull/15044

From asemenyuk at openjdk.org  Wed Jul 26 18:56:58 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 26 Jul 2023 18:56:58 GMT
Subject: RFR: 8311104: dangling-gsl warning in libwixhelper.cpp
In-Reply-To: <NQQrL4Ek8bE-ERRKK24i-5ktl2Fu1g-Vi0-DSK7wgI8=.e35b1911-46c5-4e49-b1c6-d97886782abb@github.com>
References: <NQQrL4Ek8bE-ERRKK24i-5ktl2Fu1g-Vi0-DSK7wgI8=.e35b1911-46c5-4e49-b1c6-d97886782abb@github.com>
Message-ID: <mL_IaON1TUMXf2Tuck1Iijj5160Dx27Fijjq6Sgbuew=.8135add8-0b5d-4172-83a8-5b1729c02900@github.com>

On Wed, 26 Jul 2023 18:42:47 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8311104: dangling-gsl warning in libwixhelper.cpp

@sashamatveev please review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15044#issuecomment-1652324135

From alanb at openjdk.org  Wed Jul 26 19:13:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Jul 2023 19:13:00 GMT
Subject: [jdk21] RFR: 8313193: ProblemList
 java/util/concurrent/SynchronousQueue/Fairness.java on X64
In-Reply-To: <vCAVfsxieuJX568xekuvWGPJasdVbhzyi-eRUIVIEgY=.e8270fbe-3124-4322-ba22-193a7a295120@github.com>
References: <vCAVfsxieuJX568xekuvWGPJasdVbhzyi-eRUIVIEgY=.e8270fbe-3124-4322-ba22-193a7a295120@github.com>
Message-ID: <nELPzkkBtedEmA_qSAHTGl6ea-EEGh_svSNk5Qi2w1M=.20e8cf95-55ea-41a8-bba4-40507c7dd3ec@github.com>

On Wed, 26 Jul 2023 15:47:48 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/SynchronousQueue/Fairness.java on X64.

Are all the sightings -XX:+UseZGC -Xcomp? Only asking in case you meant to add it to ProblemList-zgc.txt.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/144#issuecomment-1652347577

From lancea at openjdk.org  Wed Jul 26 19:23:39 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 26 Jul 2023 19:23:39 GMT
Subject: RFR: 8312416: Tests in Locale should have more descriptive names
In-Reply-To: <PrykfUm6DeNNoi2uQ9YR74Ae5Y0Fcn7S1-45ola7Qeo=.d158464f-ed6c-4cec-bcdd-2c998bc0934d@github.com>
References: <PrykfUm6DeNNoi2uQ9YR74Ae5Y0Fcn7S1-45ola7Qeo=.d158464f-ed6c-4cec-bcdd-2c998bc0934d@github.com>
Message-ID: <j4ljx72CpCaZZFV4nV7j-xVjH04IRAySijrYL49KpV4=.03b6aee1-4055-4828-a728-16ac51ea537d@github.com>

On Wed, 26 Jul 2023 07:11:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this change which renames tests for Locale from `bugNNNNNNN.java` to something more descriptive.
> 
> In addition to the name changes, accompanying copyright year, name usage within the test, and other minor changes were included. The test `bug4123285.java` was also removed, as it was never actually ran and java.applet.Applet is deprecated and marked for removal.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15032#pullrequestreview-1548440407

From jvernee at openjdk.org  Wed Jul 26 19:30:53 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Jul 2023 19:30:53 GMT
Subject: RFR: 8310643: Misformatted copyright messages in FFM
In-Reply-To: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>
References: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>
Message-ID: <XuLUV0QxFOMpR-k7nMhfu0oX5cZHFt6T67AJZzSSjP8=.ca6760b0-01b3-4456-8ca5-af7f390a3ef6@github.com>

On Wed, 26 Jul 2023 15:43:12 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Some of the test files will have now the "classpath" exception. Is this correct?

No. The test files should not have the classpath exception.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15042#issuecomment-1652367609

From dcubed at openjdk.org  Wed Jul 26 19:32:09 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 26 Jul 2023 19:32:09 GMT
Subject: [jdk21] Integrated: 8313208: ProblemList
 java/util/concurrent/tck/JSR166TestCase.java on select platforms
Message-ID: <Ezbjh7kDBaOvJJjNT7Zv1U-Kubclcm-AzotGm-p53vg=.2c9897a5-63cc-4d80-884b-0373bbe4f77b@github.com>

A trivial fix to ProblemList java/util/concurrent/tck/JSR166TestCase.java on select platforms.

-------------

Commit messages:
 - 8313208: ProblemList java/util/concurrent/tck/JSR166TestCase.java on select platforms

Changes: https://git.openjdk.org/jdk21/pull/145/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=145&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313208
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk21/pull/145.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/145/head:pull/145

PR: https://git.openjdk.org/jdk21/pull/145

From darcy at openjdk.org  Wed Jul 26 19:32:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 26 Jul 2023 19:32:09 GMT
Subject: [jdk21] Integrated: 8313208: ProblemList
 java/util/concurrent/tck/JSR166TestCase.java on select platforms
In-Reply-To: <Ezbjh7kDBaOvJJjNT7Zv1U-Kubclcm-AzotGm-p53vg=.2c9897a5-63cc-4d80-884b-0373bbe4f77b@github.com>
References: <Ezbjh7kDBaOvJJjNT7Zv1U-Kubclcm-AzotGm-p53vg=.2c9897a5-63cc-4d80-884b-0373bbe4f77b@github.com>
Message-ID: <lEp0J3M56VP2eE6KUi2W3Jrauk4Pq9--fJ5liQDX0O0=.99f28098-3f73-4f08-b01a-4eaa2aceb5ac@github.com>

On Wed, 26 Jul 2023 19:22:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/tck/JSR166TestCase.java on select platforms.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/145#pullrequestreview-1548445218

From dcubed at openjdk.org  Wed Jul 26 19:32:09 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 26 Jul 2023 19:32:09 GMT
Subject: [jdk21] Integrated: 8313208: ProblemList
 java/util/concurrent/tck/JSR166TestCase.java on select platforms
In-Reply-To: <lEp0J3M56VP2eE6KUi2W3Jrauk4Pq9--fJ5liQDX0O0=.99f28098-3f73-4f08-b01a-4eaa2aceb5ac@github.com>
References: <Ezbjh7kDBaOvJJjNT7Zv1U-Kubclcm-AzotGm-p53vg=.2c9897a5-63cc-4d80-884b-0373bbe4f77b@github.com>
 <lEp0J3M56VP2eE6KUi2W3Jrauk4Pq9--fJ5liQDX0O0=.99f28098-3f73-4f08-b01a-4eaa2aceb5ac@github.com>
Message-ID: <YRYCLE3330eEKffw2XiyoUGqBkXKklH9TfllVD9M36g=.e5b06944-4c96-410c-8065-cd136ab62b69@github.com>

On Wed, 26 Jul 2023 19:24:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A trivial fix to ProblemList java/util/concurrent/tck/JSR166TestCase.java on select platforms.
>
> Marked as reviewed by darcy (Reviewer).

@jddarcy - Thanks for the lightning fast review!

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/145#issuecomment-1652365817

From dcubed at openjdk.org  Wed Jul 26 19:32:09 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 26 Jul 2023 19:32:09 GMT
Subject: [jdk21] Integrated: 8313208: ProblemList
 java/util/concurrent/tck/JSR166TestCase.java on select platforms
In-Reply-To: <Ezbjh7kDBaOvJJjNT7Zv1U-Kubclcm-AzotGm-p53vg=.2c9897a5-63cc-4d80-884b-0373bbe4f77b@github.com>
References: <Ezbjh7kDBaOvJJjNT7Zv1U-Kubclcm-AzotGm-p53vg=.2c9897a5-63cc-4d80-884b-0373bbe4f77b@github.com>
Message-ID: <cnPVJV6BWxb7Nm_9oxKaHFTlINmMh6KEWsMebM7PrdQ=.805c2e98-f19d-4c11-a62d-44f5f6e9ccc1@github.com>

On Wed, 26 Jul 2023 19:22:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/tck/JSR166TestCase.java on select platforms.

This pull request has now been integrated.

Changeset: a10dbcec
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/a10dbcecdba59d0ddabec2d37e62b5fb82138dae
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8313208: ProblemList java/util/concurrent/tck/JSR166TestCase.java on select platforms

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk21/pull/145

From dcubed at openjdk.org  Wed Jul 26 19:35:00 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 26 Jul 2023 19:35:00 GMT
Subject: [jdk21] RFR: 8313193: ProblemList
 java/util/concurrent/SynchronousQueue/Fairness.java on X64
In-Reply-To: <vCAVfsxieuJX568xekuvWGPJasdVbhzyi-eRUIVIEgY=.e8270fbe-3124-4322-ba22-193a7a295120@github.com>
References: <vCAVfsxieuJX568xekuvWGPJasdVbhzyi-eRUIVIEgY=.e8270fbe-3124-4322-ba22-193a7a295120@github.com>
Message-ID: <tUcZoZMDQXsS-bqpGti0TyxFrU0mEAkEvUsqt1WzU_c=.09e1d1a0-d688-4b67-8dfe-e4175ccb5ce8@github.com>

On Wed, 26 Jul 2023 15:47:48 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/SynchronousQueue/Fairness.java on X64.

They are (so far), but the fix that Doug Lea integrated did not seem to be
specific to ZGC or -Xcomp so I went wider... I'm hoping that Doug's fix
gets backported to JDK21u. He integrated his fix for  8300663 with a much
larger fix for another bug so I thought that the odds of that changeset being
backported to JDK21 was low (especially since it is a P3).

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/144#issuecomment-1652373120

From naoto at openjdk.org  Wed Jul 26 19:49:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Jul 2023 19:49:50 GMT
Subject: RFR: 8312416: Tests in Locale should have more descriptive names
In-Reply-To: <PrykfUm6DeNNoi2uQ9YR74Ae5Y0Fcn7S1-45ola7Qeo=.d158464f-ed6c-4cec-bcdd-2c998bc0934d@github.com>
References: <PrykfUm6DeNNoi2uQ9YR74Ae5Y0Fcn7S1-45ola7Qeo=.d158464f-ed6c-4cec-bcdd-2c998bc0934d@github.com>
Message-ID: <nNE0HY8PwyYXQBHPUGcBV6-rMr4UZIMZPLmQF44P2M4=.487ec6b2-98f3-47d2-8137-1afc516de1f5@github.com>

On Wed, 26 Jul 2023 07:11:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this change which renames tests for Locale from `bugNNNNNNN.java` to something more descriptive.
> 
> In addition to the name changes, accompanying copyright year, name usage within the test, and other minor changes were included. The test `bug4123285.java` was also removed, as it was never actually ran and java.applet.Applet is deprecated and marked for removal.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15032#pullrequestreview-1548484877

From naoto at openjdk.org  Wed Jul 26 19:50:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Jul 2023 19:50:41 GMT
Subject: RFR: 8312411: MessageFormat.formatToCharacterIterator() can be
 improved
In-Reply-To: <SvBOR63sGUuLf0dWrmAV9vbyHNN2mf3wZIefKffPGl0=.05694f16-665d-407c-87b8-6b19041cf2d3@github.com>
References: <SvBOR63sGUuLf0dWrmAV9vbyHNN2mf3wZIefKffPGl0=.05694f16-665d-407c-87b8-6b19041cf2d3@github.com>
Message-ID: <zuRoZHwbtAjoOYs9QO_OTyQgxmNzgM6FBDw4JJ9Ewy8=.52699377-c7c0-4009-93c4-8e6ab3390dbf@github.com>

On Wed, 26 Jul 2023 07:39:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this change which makes `MessageFormat.formatToCharacterIterator` fail fast(er). The return statement is also modified to call  toArray() as `toArray(new T[0])` over `toArray(new T[size])`.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15035#pullrequestreview-1548486880

From almatvee at openjdk.org  Wed Jul 26 20:07:50 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 26 Jul 2023 20:07:50 GMT
Subject: RFR: 8311104: dangling-gsl warning in libwixhelper.cpp
In-Reply-To: <NQQrL4Ek8bE-ERRKK24i-5ktl2Fu1g-Vi0-DSK7wgI8=.e35b1911-46c5-4e49-b1c6-d97886782abb@github.com>
References: <NQQrL4Ek8bE-ERRKK24i-5ktl2Fu1g-Vi0-DSK7wgI8=.e35b1911-46c5-4e49-b1c6-d97886782abb@github.com>
Message-ID: <h9sRdllMDryPHLt2lRTMRXTdtJsGlZqKbSXZkDIYWuc=.92c9e51a-5fee-403b-835e-ff06dfbcdf74@github.com>

On Wed, 26 Jul 2023 18:42:47 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8311104: dangling-gsl warning in libwixhelper.cpp

src/jdk.jpackage/windows/native/libwixhelper/libwixhelper.cpp line 75:

> 73: void findInstalledProducts(const Guid& upgradeCode,
> 74:                                             std::vector<ProductInfo>& products) {
> 75:     const tstring upgradeCodeStr = upgradeCode.toMsiString();

I am not familiar with this warning. Does it mean that in original `const LPCTSTR upgradeCodeStr = upgradeCode.toMsiString().c_str();`, `tstring` retuned from `toMsiString()` will get destroyed right after` c_str()` completed? Which will make `upgradeCodeStr` invalid?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15044#discussion_r1275432462

From qamai at openjdk.org  Wed Jul 26 20:33:54 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 26 Jul 2023 20:33:54 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v13]
In-Reply-To: <Q40yhMfrkRyDx5Zfz_y6UUPXTspFUMWQuo_BPl9Dc8U=.ff88f1af-07b6-4a8f-b916-a2e4dd97f21d@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <Q40yhMfrkRyDx5Zfz_y6UUPXTspFUMWQuo_BPl9Dc8U=.ff88f1af-07b6-4a8f-b916-a2e4dd97f21d@github.com>
Message-ID: <hZjX7BCpWrgwBcfxt316gsEzQClFtX7DqsiSwqrJBmA=.fd1e1a9e-88b4-4a47-8b95-56eb360a8238@github.com>

On Tue, 18 Jul 2023 01:49:17 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.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 (+...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assert bounds check

It could be worth it to have a cache for small integers to skip the calculations altogether.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1652451460

From jlu at openjdk.org  Wed Jul 26 20:47:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Jul 2023 20:47:11 GMT
Subject: RFR: 8312572: JDK 21 RDP2 L10n resource files update
Message-ID: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>

Please review this PR which contains the IPS translations for updates to localized resources in the JDK since RDP1.

Included in this change are improved translations for certain values, which also includes global updates for translations of the words 'annotation' and 'file' for zh_CN.

The following files contain key/value resources that were added, updated, or removed in the original file. (This means that the localized versions of these files contain changes to translations that are a reflection of the original key/value changing, and are not just improved translations).

- src/java.base/share/classes/sun/launcher/resources/launcher.properties
- src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
- src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties
- src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
- src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties

It is recommended to view the changes in UTF-8 native at https://cr.openjdk.org/~jlu/RDP2_Diffs/.

-------------

Commit messages:
 - Revert zh_CN translation of 'private' for consistency
 - Revert IPS newline changes to MsiInstallerStrings_en.wxl
 - Move CurrencyNames_xx.properties to jdk.localedata (no changes)
 - Remove extra quotes in 'main.usage' values in jdeprscan
 - Revert WinResources changing of 'resource.wxl-file-name' value
 - Standardize trailing WS in l10n.properties
 - Revert MsiInstallerStrings culture value changes
 - Apply WS Tool
 - Apply IPS translations

Changes: https://git.openjdk.org/jdk/pull/15047/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15047&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312572
  Stats: 223 lines in 32 files changed: 36 ins; 15 del; 172 mod
  Patch: https://git.openjdk.org/jdk/pull/15047.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15047/head:pull/15047

PR: https://git.openjdk.org/jdk/pull/15047

From asemenyuk at openjdk.org  Wed Jul 26 20:48:51 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 26 Jul 2023 20:48:51 GMT
Subject: RFR: 8311104: dangling-gsl warning in libwixhelper.cpp
In-Reply-To: <h9sRdllMDryPHLt2lRTMRXTdtJsGlZqKbSXZkDIYWuc=.92c9e51a-5fee-403b-835e-ff06dfbcdf74@github.com>
References: <NQQrL4Ek8bE-ERRKK24i-5ktl2Fu1g-Vi0-DSK7wgI8=.e35b1911-46c5-4e49-b1c6-d97886782abb@github.com>
 <h9sRdllMDryPHLt2lRTMRXTdtJsGlZqKbSXZkDIYWuc=.92c9e51a-5fee-403b-835e-ff06dfbcdf74@github.com>
Message-ID: <4Ws4-s1dMfYtmAppA16xxk_rw8rruCsN4ckLLm1L0gI=.f2142718-d431-4a2f-8e6a-f4712f6f1a4e@github.com>

On Wed, 26 Jul 2023 20:05:11 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> 8311104: dangling-gsl warning in libwixhelper.cpp
>
> src/jdk.jpackage/windows/native/libwixhelper/libwixhelper.cpp line 75:
> 
>> 73: void findInstalledProducts(const Guid& upgradeCode,
>> 74:                                             std::vector<ProductInfo>& products) {
>> 75:     const tstring upgradeCodeStr = upgradeCode.toMsiString();
> 
> I am not familiar with this warning. Does it mean that in original `const LPCTSTR upgradeCodeStr = upgradeCode.toMsiString().c_str();`, `tstring` retuned from `toMsiString()` will get destroyed right after` c_str()` completed? Which will make `upgradeCodeStr` invalid?

Yep, that is correct

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15044#discussion_r1275467144

From alanb at openjdk.org  Wed Jul 26 21:21:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Jul 2023 21:21:56 GMT
Subject: [jdk21] Integrated: 8313208: ProblemList
 java/util/concurrent/tck/JSR166TestCase.java on select platforms
In-Reply-To: <Ezbjh7kDBaOvJJjNT7Zv1U-Kubclcm-AzotGm-p53vg=.2c9897a5-63cc-4d80-884b-0373bbe4f77b@github.com>
References: <Ezbjh7kDBaOvJJjNT7Zv1U-Kubclcm-AzotGm-p53vg=.2c9897a5-63cc-4d80-884b-0373bbe4f77b@github.com>
Message-ID: <lMSDeACb_PzmlqJtsqZU6vgf0PCYdbUlLoqZnBdMEH4=.5f6bd215-02d1-4e01-97ed-12d934fca71d@github.com>

On Wed, 26 Jul 2023 19:22:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/tck/JSR166TestCase.java on select platforms.

JSR166TestCase.java runs >4000 tests so excluding this discussion is not good. Maybe JDK-8312980 needs to be bumped to a P1/P2 or a workaround put in for the bailing case that would not assert while it is under investigation.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/145#issuecomment-1652509902

From almatvee at openjdk.org  Wed Jul 26 21:53:39 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 26 Jul 2023 21:53:39 GMT
Subject: RFR: 8311104: dangling-gsl warning in libwixhelper.cpp
In-Reply-To: <NQQrL4Ek8bE-ERRKK24i-5ktl2Fu1g-Vi0-DSK7wgI8=.e35b1911-46c5-4e49-b1c6-d97886782abb@github.com>
References: <NQQrL4Ek8bE-ERRKK24i-5ktl2Fu1g-Vi0-DSK7wgI8=.e35b1911-46c5-4e49-b1c6-d97886782abb@github.com>
Message-ID: <gYdObCoqR4BMHG87EFqNIAYZgPprdzLnChhyjgtoS2I=.d60d76e8-3ec9-43fc-92ff-7bd8f54bdcc2@github.com>

On Wed, 26 Jul 2023 18:42:47 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8311104: dangling-gsl warning in libwixhelper.cpp

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15044#pullrequestreview-1548666131

From matsaave at openjdk.org  Wed Jul 26 21:54:42 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 26 Jul 2023 21:54:42 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v2]
In-Reply-To: <f6-guImxr7rHF3KKRBCdPOXl2Yq7EE3I2lQ-5ipFHl8=.6bee70e0-a0e9-433d-bb54-864fd199a9ff@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
 <PlLziaxnr3lJpWWJTb8cNXhNVRXIjZhW3RyWCudUYvE=.0720bfaf-6401-461f-bdb0-06ce7b097d87@github.com>
 <f6-guImxr7rHF3KKRBCdPOXl2Yq7EE3I2lQ-5ipFHl8=.6bee70e0-a0e9-433d-bb54-864fd199a9ff@github.com>
Message-ID: <Os6npzmUF1vg6JoqDyiRQtMrRENts4XYXYTKRaLmcV4=.2342937c-3e75-4686-b082-bd895cbebc1e@github.com>

On Wed, 26 Jul 2023 18:52:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge fix
>>  - Restores java loaders
>>  - Ioi and David comments
>>  - Windows fix
>>  - 8306582: Remove MetaspaceShared::exit_after_static_dump()
>
> src/java.base/share/native/libjli/java.c line 464:
> 
>> 462:     if (dumpSharedSpaces) {
>> 463:       CHECK_EXCEPTION_LEAVE(0);
>> 464:       LEAVE();
> 
> What is exit status ($?) when -Xshare:dump fails. It looks like any pending exception will be printed and it will exit with 0 but maybe I've missed something.
> 
> In passing, the java launcher uses 4-space indent rather than 2.

I am not incredibly familiar with the java launcher but I believe what I have is a mistake. I will change it to `CHECK_EXCEPTION_LEAVE(1)` instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1275516774

From smarks at openjdk.org  Wed Jul 26 22:02:51 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 26 Jul 2023 22:02:51 GMT
Subject: RFR: 8311517: ArrayList javadoc improvements related to sequenced
 collection updates
In-Reply-To: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
References: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
Message-ID: <Jvxfyqa_Jl42gYIKO9Omju1EGeTir5oCFFcO10rzcBk=.3ec82ff3-d21e-44bc-837c-f57b114bdb94@github.com>

On Wed, 26 Jul 2023 11:02:20 GMT, dan1st <duke at openjdk.org> wrote:

> The [JEP for sequenced collections](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 PR updates that Javadoc to factor in the new methods introduced by JEP 431.
> 
> https://bugs.openjdk.org/browse/JDK-8311517
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109637.html
> 
> This PR only affects documentation.

Hi, thanks for working on this.

I've changed the bug summary line to be more descriptive:

> Add performance information to ArrayList javadoc

The PR title needs to be changed to match. I hope this is ok.

Regarding the text of the change: should getFirst() and getLast() be mentioned? They were added by Sequenced Collections, and they run in constant time. Also, while add() and addLast() run in amortized constant time (because of the possibility of array growth) removeLast() runs in absolute constant time; it never copies or reallocates the array.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15040#issuecomment-1652555426

From smarks at openjdk.org  Wed Jul 26 22:14:40 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 26 Jul 2023 22:14:40 GMT
Subject: RFR: 8311517: ArrayList javadoc improvements related to sequenced
 collection updates
In-Reply-To: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
References: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
Message-ID: <cYciW2iO7xXv0x3X7Rb1Iu42zElAzklimN6lMvEGvJc=.3ea7e722-38a9-4148-8b97-c6c2d8a828c4@github.com>

On Wed, 26 Jul 2023 11:02:20 GMT, dan1st <duke at openjdk.org> wrote:

> The [JEP for sequenced collections](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 PR updates that Javadoc to factor in the new methods introduced by JEP 431.
> 
> https://bugs.openjdk.org/browse/JDK-8311517
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109637.html
> 
> This PR only affects documentation.

A CSR is required for this change, as these are normative statements about the performance of this implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15040#issuecomment-1652577184

From duke at openjdk.org  Wed Jul 26 22:22:41 2023
From: duke at openjdk.org (dan1st)
Date: Wed, 26 Jul 2023 22:22:41 GMT
Subject: RFR: 8311517: ArrayList javadoc improvements related to sequenced
 collection updates
In-Reply-To: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
References: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
Message-ID: <GtjFHgUAJPOzKy3Xqo39mcGYPUk5EDu3DcKnmzKYOKc=.d3231f55-484c-4646-9194-5a569dc36ab7@github.com>

On Wed, 26 Jul 2023 11:02:20 GMT, dan1st <duke at openjdk.org> wrote:

> The [JEP for sequenced collections](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 PR updates that Javadoc to factor in the new methods introduced by JEP 431.
> 
> https://bugs.openjdk.org/browse/JDK-8311517
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109637.html
> 
> This PR only affects documentation.

I don't think I can create a CSR request without an OpenJDK/JBS account. Is this correct?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15040#issuecomment-1652600934

From smarks at openjdk.org  Wed Jul 26 23:04:50 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 26 Jul 2023 23:04:50 GMT
Subject: RFR: 8311517: ArrayList javadoc improvements related to sequenced
 collection updates
In-Reply-To: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
References: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
Message-ID: <hLcXeITOhEvzQQVy_KjZSay2oq4EzL8ZyNOB4uLuS8U=.1eb99aa7-f93f-4a72-be6c-2c4ae1584365@github.com>

On Wed, 26 Jul 2023 11:02:20 GMT, dan1st <duke at openjdk.org> wrote:

> The [JEP for sequenced collections](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 PR updates that Javadoc to factor in the new methods introduced by JEP 431.
> 
> https://bugs.openjdk.org/browse/JDK-8311517
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109637.html
> 
> This PR only affects documentation.

Yes, that's correct. I'll create a CSR for this when the change settles down.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15040#issuecomment-1652655848

From dnguyen at openjdk.org  Thu Jul 27 00:24:42 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 27 Jul 2023 00:24:42 GMT
Subject: RFR: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
References: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
Message-ID: <-EvTASKrIweBzLE7uRXAtnLmG4XXp5oN4Q6Qq4ETm3M=.37d25be2-2296-499e-a925-7ab24be4e99e@github.com>

On Wed, 26 Jul 2023 20:41:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the translations for updates to localized resources in the JDK since RDP1.
> 
> Included in this change are improved translations for certain values, which also includes global updates for translations of the words 'annotation' and 'file' for zh_CN.
> 
> The following files contain key/value resources that were added, updated, or removed in the original file. (This means that the localized versions of these files contain changes to translations that are a reflection of the original key/value changing, and are not just improved translations).
> 
> - src/java.base/share/classes/sun/launcher/resources/launcher.properties
> - src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
> - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
> - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties
> - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
> - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties
> 
> It is recommended to view the changes in UTF-8 native at https://cr.openjdk.org/~jlu/RDP2_Diffs/.

src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties line 185:

> 183: jshell.console.no.javadoc = <no documentation found>
> 184: jshell.console.do.nothing = Do nothing
> 185: jshell.console.choice = Choice:\u0020

I see this backslash is also being removed. It does seem misplaced since none of the other lines use it. But just double checking with you that this is the desired change because for the other locales, the change was to just translate the space to unicode.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15047#discussion_r1275600311

From mcimadamore at openjdk.org  Thu Jul 27 00:40:58 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 27 Jul 2023 00:40:58 GMT
Subject: RFR: 8310643: Misformatted copyright messages in FFM
In-Reply-To: <XuLUV0QxFOMpR-k7nMhfu0oX5cZHFt6T67AJZzSSjP8=.ca6760b0-01b3-4456-8ca5-af7f390a3ef6@github.com>
References: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>
 <XuLUV0QxFOMpR-k7nMhfu0oX5cZHFt6T67AJZzSSjP8=.ca6760b0-01b3-4456-8ca5-af7f390a3ef6@github.com>
Message-ID: <0stIrJYJLcbRKd_xtjMB5VgGHr6q34AusYu_6aHZvbU=.beb7ddf4-878e-48d4-b36a-0f8def24bb3d@github.com>

On Wed, 26 Jul 2023 19:28:04 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR suggests updating some of the ill-formed copyright headers in the FFM API and the implementation and test thereof.
>> 
>> Some of the test files will have now the "classpath" exception. Is this correct?
>
>> Some of the test files will have now the "classpath" exception. Is this correct?
> 
> No. The test files should not have the classpath exception.

Thanks for looking into this. As commented by @JornVernee, it is deliberate that tests do not have CP exception. So the fix there is the opposite: we should be looking for text with the exception text, and drop it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15042#issuecomment-1652736990

From mcimadamore at openjdk.org  Thu Jul 27 00:44:52 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 27 Jul 2023 00:44:52 GMT
Subject: RFR: 8298095: Refine implSpec for SegmentAllocator [v3]
In-Reply-To: <0IrtNsnUT5e2byRsb28hFPso7jWPXY3vgXnCeGcPSP0=.02fbec3c-d078-47b6-9330-0425b7ffb52c@github.com>
References: <MYKIf86teO-EoEjeqII6aRsex4ZBxS9bOAQHRS5c59o=.39a950db-d4e6-40a8-bd40-80822fea06da@github.com>
 <0IrtNsnUT5e2byRsb28hFPso7jWPXY3vgXnCeGcPSP0=.02fbec3c-d078-47b6-9330-0425b7ffb52c@github.com>
Message-ID: <37ZM2Tk8JBoCtYZfpQIRXjte8-lSk29hFyoYXDmIWHg=.d018a7d7-4058-4d35-938b-cad21da492bd@github.com>

On Wed, 26 Jul 2023 14:44:01 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests refining the `@implSpec` for the SegmentAllocator::allocate methods as well as clarifying the docs a bit more. Also, a local variable is renamed.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after comments

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 110:

> 108:      * {@snippet lang=java :
> 109:      *  Objects.requireNonNull(layout);
> 110:      *  VarHandle handle = layout.varHandle();

We can make this simpler by using MemorySegment::set ?

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 303:

> 301:      * specified by the provided {@code layout} (i.e. byte ordering, alignment and size)}
> 302:      *
> 303:      * @implSpec The default implementation of this method first calls {@code this.allocateArray(layout, array.length)}

This should probably use code too. I'd suggest to use allocate + MemorySegment::copy

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 472:

> 470:      * @param byteAlignment the alignment (in bytes) of the block of memory to be allocated.
> 471:      * @throws IllegalArgumentException if {@code byteSize < 0}, {@code byteAlignment <= 0},
> 472:      *                                  or if {@code byteAlignment} is not a power of 2.

I'd leave this out. Not because I disagree stylistically, but simply because it's a style that we don't adhere with in this package. If we want to change that, it's ok, but perhaps better to deal with it in another PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14997#discussion_r1275610750
PR Review Comment: https://git.openjdk.org/jdk/pull/14997#discussion_r1275611327
PR Review Comment: https://git.openjdk.org/jdk/pull/14997#discussion_r1275611839

From mcimadamore at openjdk.org  Thu Jul 27 00:49:51 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 27 Jul 2023 00:49:51 GMT
Subject: RFR: 8298095: Refine implSpec for SegmentAllocator [v3]
In-Reply-To: <0IrtNsnUT5e2byRsb28hFPso7jWPXY3vgXnCeGcPSP0=.02fbec3c-d078-47b6-9330-0425b7ffb52c@github.com>
References: <MYKIf86teO-EoEjeqII6aRsex4ZBxS9bOAQHRS5c59o=.39a950db-d4e6-40a8-bd40-80822fea06da@github.com>
 <0IrtNsnUT5e2byRsb28hFPso7jWPXY3vgXnCeGcPSP0=.02fbec3c-d078-47b6-9330-0425b7ffb52c@github.com>
Message-ID: <Mmpd5BXKCIVsNetBtQESVkZkI-XcVz045ZpR6EnmtDw=.0bb2a9b5-f26f-4ff3-8a6c-b52c412cbe54@github.com>

On Wed, 26 Jul 2023 14:44:01 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests refining the `@implSpec` for the SegmentAllocator::allocate methods as well as clarifying the docs a bit more. Also, a local variable is renamed.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after comments

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 90:

> 88:      * If the given string contains any {@code '\0'} characters, they will be
> 89:      * copied as well. This means that, depending on the method used to read
> 90:      * the string, such as {@link MemorySegment#getUtf8String(long)}, the string

The initial text in the javadoc of `allocateUtf8String` should be updated as well. It should start with "return a new memory segment that ...". Note also that this text has changed a bit in the panama repo, as a result of https://github.com/openjdk/panama-foreign/pull/836

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14997#discussion_r1275615534

From sspitsyn at openjdk.org  Thu Jul 27 01:33:02 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 27 Jul 2023 01:33:02 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked
In-Reply-To: <c_Zt5keGMFPn8C7FX9j_JHO5wduFyrid8nXMJLyk7hM=.fbda8336-04c6-4225-84d7-d5b3d2bc99d0@github.com>
References: <Ar-k3n5Awr02ccVZvwJkL9VyUVnHZbKW0ln9K5oZmp0=.98dfd87b-a04a-4fae-ad90-055131d8438e@github.com>
 <WiT7SARAp5YlF3Rt7sNt9wfpGAtSEoPgMDjE18-v--g=.14a3969b-09fe-46a5-8792-5b11a6766e82@github.com>
 <F38MG81847StSmL4MfHFuf92ios5gEQDyZTyk_4exuQ=.22d4f222-d86f-4804-a148-8bf83c3877e4@github.com>
 <c_Zt5keGMFPn8C7FX9j_JHO5wduFyrid8nXMJLyk7hM=.fbda8336-04c6-4225-84d7-d5b3d2bc99d0@github.com>
Message-ID: <ckx0-kRWihsZKJuAd7KtPNMzAbME8xg-4gOxTUISTBo=.5cad8051-62f5-4d4c-9172-fb0e8e010ddb@github.com>

On Wed, 26 Jul 2023 17:38:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I can't see why it would be needed.
>
>> It would be nice to add a short comment why this is needed.
> 
> It's not needed here, it was needed in another version of the tests. While benign, I can remove it to avoid any confusion. Thanks.

There are more such lines: 176, 219, 313,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1275634253

From sspitsyn at openjdk.org  Thu Jul 27 01:33:02 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 27 Jul 2023 01:33:02 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked
In-Reply-To: <Ar-k3n5Awr02ccVZvwJkL9VyUVnHZbKW0ln9K5oZmp0=.98dfd87b-a04a-4fae-ad90-055131d8438e@github.com>
References: <Ar-k3n5Awr02ccVZvwJkL9VyUVnHZbKW0ln9K5oZmp0=.98dfd87b-a04a-4fae-ad90-055131d8438e@github.com>
Message-ID: <R3o7WViEjl68lpD5VBaIcJGpf1dHej2a-EeFuEXEcdY=.d6f0e394-bf1f-460c-b4df-b00e13a844c4@github.com>

On Fri, 21 Jul 2023 18:01:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread::getState is an API for monitoring and management purposes to report the thread state. If a virtual thread is parked with LockSupport.parkNanos, its state is reported as  WAITING when it should be TIMED_WAITING. JVM TI GetThreadState has the same issue in that it returns JVMTI_THREAD_STATE_WAITING_INDEFINITELY instead of the JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT bit set. Not a very visible issue because JDWP maps both states to "WAIT" but it may be noticed by tools using other JVM TI agents.
> 
> The change is straight-forward, it's just additional state bit to indicate that park is timed. The existing virtual/ThreadAPI.java test is expanded to this scenario. A new test is added for JVM TI GetThreadState to test waiting/timed-waited cases (including pinned) as test coverage seems patchy here.

test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/libGetThreadStateTest.c line 50:

> 48:         (*env)->FatalError(env, "GetThreadState failed");
> 49:     }
> 50:     return state;

Normal indent for native code is 2.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1275634875

From sspitsyn at openjdk.org  Thu Jul 27 01:57:59 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 27 Jul 2023 01:57:59 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked
In-Reply-To: <Ar-k3n5Awr02ccVZvwJkL9VyUVnHZbKW0ln9K5oZmp0=.98dfd87b-a04a-4fae-ad90-055131d8438e@github.com>
References: <Ar-k3n5Awr02ccVZvwJkL9VyUVnHZbKW0ln9K5oZmp0=.98dfd87b-a04a-4fae-ad90-055131d8438e@github.com>
Message-ID: <aBlm6Q6Y4fl1hdEJA-YBeJx0Xo1B_03K_C9BrOdLw4I=.8a16321f-0275-43ae-8014-e34b8cd23d70@github.com>

On Fri, 21 Jul 2023 18:01:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread::getState is an API for monitoring and management purposes to report the thread state. If a virtual thread is parked with LockSupport.parkNanos, its state is reported as  WAITING when it should be TIMED_WAITING. JVM TI GetThreadState has the same issue in that it returns JVMTI_THREAD_STATE_WAITING_INDEFINITELY instead of the JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT bit set. Not a very visible issue because JDWP maps both states to "WAIT" but it may be noticed by tools using other JVM TI agents.
> 
> The change is straight-forward, it's just additional state bit to indicate that park is timed. The existing virtual/ThreadAPI.java test is expanded to this scenario. A new test is added for JVM TI GetThreadState to test waiting/timed-waited cases (including pinned) as test coverage seems patchy here.

Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14978#pullrequestreview-1548866690

From duke at openjdk.org  Thu Jul 27 05:08:54 2023
From: duke at openjdk.org (sid8606)
Date: Thu, 27 Jul 2023 05:08:54 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <Yrs1mKpyZQZrXqCFtSxOemkcvrh4xMyCr2mydFSU9Nc=.ca809339-95de-4e1a-8324-f93fb9cb8b72@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
 <Yrs1mKpyZQZrXqCFtSxOemkcvrh4xMyCr2mydFSU9Nc=.ca809339-95de-4e1a-8324-f93fb9cb8b72@github.com>
Message-ID: <WKe92pA4Ts6x49_jX5NoV5WBy4tSgXAAKH1owWfl7dU=.f57ae55c-05f1-45ef-a14d-5c52085bf898@github.com>

On Tue, 25 Jul 2023 21:26:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address suggestions from Jorn Vernee
>
> src/hotspot/cpu/s390/downcallLinker_s390.cpp line 162:
> 
>> 160: 
>> 161:   assert(!_needs_return_buffer, "unexpected needs_return_buffer");
>> 162:   bool should_save_return_value = _needs_transition;;
> 
> This should always be `true`, so I don't think you need the `if` statements around the spill/fill code below.
> 
> See: https://github.com/openjdk/jdk/pull/15025 (`should_save_return_value` being dependent on `_needs_transition` is a bug).

Thank you, I'll make changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1275736710

From alanb at openjdk.org  Thu Jul 27 05:48:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Jul 2023 05:48:42 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v2]
In-Reply-To: <Os6npzmUF1vg6JoqDyiRQtMrRENts4XYXYTKRaLmcV4=.2342937c-3e75-4686-b082-bd895cbebc1e@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
 <PlLziaxnr3lJpWWJTb8cNXhNVRXIjZhW3RyWCudUYvE=.0720bfaf-6401-461f-bdb0-06ce7b097d87@github.com>
 <f6-guImxr7rHF3KKRBCdPOXl2Yq7EE3I2lQ-5ipFHl8=.6bee70e0-a0e9-433d-bb54-864fd199a9ff@github.com>
 <Os6npzmUF1vg6JoqDyiRQtMrRENts4XYXYTKRaLmcV4=.2342937c-3e75-4686-b082-bd895cbebc1e@github.com>
Message-ID: <6_vq-zO6qwPdKTwVAvyooF5dcVIQRadZEIj8QoVd8uk=.f37fb049-86a5-40e7-babd-e3ce8e402dda@github.com>

On Wed, 26 Jul 2023 21:52:04 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> src/java.base/share/native/libjli/java.c line 464:
>> 
>>> 462:     if (dumpSharedSpaces) {
>>> 463:       CHECK_EXCEPTION_LEAVE(0);
>>> 464:       LEAVE();
>> 
>> What is exit status ($?) when -Xshare:dump fails. It looks like any pending exception will be printed and it will exit with 0 but maybe I've missed something.
>> 
>> In passing, the java launcher uses 4-space indent rather than 2.
>
> I am not incredibly familiar with the java launcher but I believe what I have is a mistake. I will change it to `CHECK_EXCEPTION_LEAVE(1)` instead.

Yes, if you change it CHECK_EXCEPTION_LEAVE(1)then any pending exception will be printed and it will exit with 1; if there is no pending exception then it exit with the value of `ret` as the exit status, which will be 0 here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1275758802

From alanb at openjdk.org  Thu Jul 27 06:05:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Jul 2023 06:05:51 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked
In-Reply-To: <R3o7WViEjl68lpD5VBaIcJGpf1dHej2a-EeFuEXEcdY=.d6f0e394-bf1f-460c-b4df-b00e13a844c4@github.com>
References: <Ar-k3n5Awr02ccVZvwJkL9VyUVnHZbKW0ln9K5oZmp0=.98dfd87b-a04a-4fae-ad90-055131d8438e@github.com>
 <R3o7WViEjl68lpD5VBaIcJGpf1dHej2a-EeFuEXEcdY=.d6f0e394-bf1f-460c-b4df-b00e13a844c4@github.com>
Message-ID: <8JFWFD97pCbORC2NBTwbK78eRbZtMYk3q3FX9rQ-LDk=.e462167a-4673-445c-ac74-87fad868d0bd@github.com>

On Thu, 27 Jul 2023 01:30:01 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Nit: normal indent for native code is 2.

The .c files I sampled in test/hotspot/jtreg/serviceability/jvmti/** used 4, either is okay as this is just two tiny JNI functions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1275769814

From dholmes at openjdk.org  Thu Jul 27 06:10:42 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 27 Jul 2023 06:10:42 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v2]
In-Reply-To: <6_vq-zO6qwPdKTwVAvyooF5dcVIQRadZEIj8QoVd8uk=.f37fb049-86a5-40e7-babd-e3ce8e402dda@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
 <PlLziaxnr3lJpWWJTb8cNXhNVRXIjZhW3RyWCudUYvE=.0720bfaf-6401-461f-bdb0-06ce7b097d87@github.com>
 <f6-guImxr7rHF3KKRBCdPOXl2Yq7EE3I2lQ-5ipFHl8=.6bee70e0-a0e9-433d-bb54-864fd199a9ff@github.com>
 <Os6npzmUF1vg6JoqDyiRQtMrRENts4XYXYTKRaLmcV4=.2342937c-3e75-4686-b082-bd895cbebc1e@github.com>
 <6_vq-zO6qwPdKTwVAvyooF5dcVIQRadZEIj8QoVd8uk=.f37fb049-86a5-40e7-babd-e3ce8e402dda@github.com>
Message-ID: <HlI1XXnBK-UbognnnW2uloWeqex8o-SoGByOOet9b0s=.2ed25354-f64e-49a0-b696-bfe4e76eeb94@github.com>

On Thu, 27 Jul 2023 05:45:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I am not incredibly familiar with the java launcher but I believe what I have is a mistake. I will change it to `CHECK_EXCEPTION_LEAVE(1)` instead.
>
> Yes, if you change it CHECK_EXCEPTION_LEAVE(1)then any pending exception will be printed and it will exit with 1; if there is no pending exception then it exit with the value of `ret` as the exit status, which will be 0 here.

Sorry I missed this. Unclear when `CHECK_EXCEPTION_LEAVE(0)` would ever be appropriate???

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1275772680

From fjiang at openjdk.org  Thu Jul 27 06:13:39 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Thu, 27 Jul 2023 06:13:39 GMT
Subject: RFR: 8313023: Return value corrupted when using CCS + isTrivial
 (mainline)
In-Reply-To: <OwWNDImcriXbajG2A2BHejjBEg5qG3Cb79DaYKOhLHs=.7fc035e7-046b-462a-b2c2-e6d312f34dbd@github.com>
References: <OO6MXUJA8WN4KaZQ5s8f09My73TaVD8Fd4uqVTpRpdo=.ca97bc20-6eff-4855-8fde-cde634c71236@github.com>
 <OwWNDImcriXbajG2A2BHejjBEg5qG3Cb79DaYKOhLHs=.7fc035e7-046b-462a-b2c2-e6d312f34dbd@github.com>
Message-ID: <fpmAAW1a_9MTgz4EJxO_A-zLAyde16917d_6hLXCZEc=.46122ce7-8dca-4671-9b75-4bc64ab31c06@github.com>

On Tue, 25 Jul 2023 21:28:23 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> @TheRealMDoerr @feilongjiang Just a heads up: this patch touches the PPC and RISC-V ports as well, which I'm not able to test. I've just eye-balled the needed changes. I don't think there will be an issue since the code structure is almost identical, but you might want to run the `java/foreign/capturecallstate/TestCaptureCallState.java` test with this patch just to be sure.

I have tested the release build and `TestCaptureCallState.java` you mentioned, still good and passed on RISC-V, Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15025#issuecomment-1652970090

From alanb at openjdk.org  Thu Jul 27 06:25:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Jul 2023 06:25:48 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v2]
In-Reply-To: <HlI1XXnBK-UbognnnW2uloWeqex8o-SoGByOOet9b0s=.2ed25354-f64e-49a0-b696-bfe4e76eeb94@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
 <PlLziaxnr3lJpWWJTb8cNXhNVRXIjZhW3RyWCudUYvE=.0720bfaf-6401-461f-bdb0-06ce7b097d87@github.com>
 <f6-guImxr7rHF3KKRBCdPOXl2Yq7EE3I2lQ-5ipFHl8=.6bee70e0-a0e9-433d-bb54-864fd199a9ff@github.com>
 <Os6npzmUF1vg6JoqDyiRQtMrRENts4XYXYTKRaLmcV4=.2342937c-3e75-4686-b082-bd895cbebc1e@github.com>
 <6_vq-zO6qwPdKTwVAvyooF5dcVIQRadZEIj8QoVd8uk=.f37fb049-86a5-40e7-babd-e3ce8e402dda@github.com>
 <HlI1XXnBK-UbognnnW2uloWeqex8o-SoGByOOet9b0s=.2ed25354-f64e-49a0-b696-bfe4e76eeb94@github.com>
Message-ID: <R9Uv5n3xT7Dkvrsj1sB2WRWFQ1kA5qMGOt_CDk7rDqc=.7a0b4f16-767d-414e-b294-de5fee08f00e@github.com>

On Thu, 27 Jul 2023 06:07:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yes, if you change it CHECK_EXCEPTION_LEAVE(1)then any pending exception will be printed and it will exit with 1; if there is no pending exception then it exit with the value of `ret` as the exit status, which will be 0 here.
>
> Sorry I missed this. Unclear when `CHECK_EXCEPTION_LEAVE(0)` would ever be appropriate???

I can't think of any case where `CHECK_EXCEPTION_LEAVE(0)` would be useful, in which case we need to check the -version/-showversion handling in the unlikely event that VersionProps.print completes with an exception (nothing to do this PR of course).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1275784806

From duke at openjdk.org  Thu Jul 27 06:31:06 2023
From: duke at openjdk.org (dan1st)
Date: Thu, 27 Jul 2023 06:31:06 GMT
Subject: RFR: 8311517: Add performance information to ArrayList javadoc
 [v2]
In-Reply-To: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
References: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
Message-ID: <pamKySAQGsJyiCtY4CBrXBv_lzJzM-BjF_NGyjVSlWc=.eda95e0d-d496-40c1-a9d6-b6724269cce4@github.com>

> The [JEP for sequenced collections](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 PR updates that Javadoc to factor in the new methods introduced by JEP 431.
> 
> https://bugs.openjdk.org/browse/JDK-8311517
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109637.html
> 
> This PR only affects documentation.

dan1st has updated the pull request incrementally with one additional commit since the last revision:

  8311517: ArrayList Javadoc of getFirst/getLast/removeLast
  
  as requested by https://github.com/openjdk/jdk/pull/15040#issuecomment-1652555426

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15040/files
  - new: https://git.openjdk.org/jdk/pull/15040/files/ba07ee63..20fddb19

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15040&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15040&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15040/head:pull/15040

PR: https://git.openjdk.org/jdk/pull/15040

From duke at openjdk.org  Thu Jul 27 06:31:06 2023
From: duke at openjdk.org (dan1st)
Date: Thu, 27 Jul 2023 06:31:06 GMT
Subject: RFR: 8311517: Add performance information to ArrayList javadoc
In-Reply-To: <Jvxfyqa_Jl42gYIKO9Omju1EGeTir5oCFFcO10rzcBk=.3ec82ff3-d21e-44bc-837c-f57b114bdb94@github.com>
References: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
 <Jvxfyqa_Jl42gYIKO9Omju1EGeTir5oCFFcO10rzcBk=.3ec82ff3-d21e-44bc-837c-f57b114bdb94@github.com>
Message-ID: <MT89V0rJymaaX17XXpbF2OnInIaLco-BKsbHPxDndJk=.6b7e32d7-a704-4294-a652-4c48e769a5d8@github.com>

On Wed, 26 Jul 2023 21:59:41 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Regarding the text of the change: should getFirst() and getLast() be mentioned? They were added by Sequenced Collections, and they run in constant time. Also, while add() and addLast() run in amortized constant time (because of the possibility of array growth) removeLast() runs in absolute constant time; it never copies or reallocates the array.

I fully agree with that and made the requested changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15040#issuecomment-1652985173

From coffeys at openjdk.org  Thu Jul 27 06:35:55 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 27 Jul 2023 06:35:55 GMT
Subject: RFR: 8311653: Modify -XshowSettings launcher behavior [v3]
In-Reply-To: <zn2oxWS8ta0cSnq3r1HT33TmO3Du8GG1-5uPHlxJ20g=.2ff58fe1-91cb-4495-8c20-82bfba59c2eb@github.com>
References: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
 <zn2oxWS8ta0cSnq3r1HT33TmO3Du8GG1-5uPHlxJ20g=.2ff58fe1-91cb-4495-8c20-82bfba59c2eb@github.com>
Message-ID: <kT-gEpALH8BCz37QydKmF9t_LKVUO0tE7T6BlZFJ-zs=.64096788-8530-471f-86f4-ca241398fe4c@github.com>

On Wed, 26 Jul 2023 09:22:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Modify the -XshowSettings launcher option to print non-verbose settings details of all components by default. Verbose settings details will be printed via the -XshowSettings:all option. Modify the -XshowSettings option to reject bad values passed to it. Print an error message in such scenarios and abort the VM launch.
>
> 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into 8311653-showSettings-tweak
>  - Incorporate changes from Mandys review
>  - Incorporate review feedback
>  - modify -X output for :all
>  - restore imports
>  - Abort if bad options input
>  - 8311653

Thanks Mandy. CSR updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15001#issuecomment-1652991837

From coffeys at openjdk.org  Thu Jul 27 06:35:57 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 27 Jul 2023 06:35:57 GMT
Subject: Integrated: 8311653: Modify -XshowSettings launcher behavior
In-Reply-To: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
References: <SnDphlxkTBNILloTJ2T2B84BrH9SR5siQ7maAWO7PIk=.accfac9b-16b0-4afd-953c-c565841cb1b4@github.com>
Message-ID: <M7fMFp5Abxfl9qYP9mr67xQAhxgYPAE4njxuNRB6A28=.4b6b67dc-aca5-4bef-933d-d2122260eb8d@github.com>

On Mon, 24 Jul 2023 16:00:52 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Modify the -XshowSettings launcher option to print non-verbose settings details of all components by default. Verbose settings details will be printed via the -XshowSettings:all option. Modify the -XshowSettings option to reject bad values passed to it. Print an error message in such scenarios and abort the VM launch.

This pull request has now been integrated.

Changeset: 36d578cd
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/36d578cddb3ae196fb7d4d8e9be6af3520c1d45f
Stats:     192 lines in 4 files changed: 114 ins; 20 del; 58 mod

8311653: Modify -XshowSettings launcher behavior

Reviewed-by: mchung, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/15001

From jlu at openjdk.org  Thu Jul 27 06:51:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 27 Jul 2023 06:51:48 GMT
Subject: RFR: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <-EvTASKrIweBzLE7uRXAtnLmG4XXp5oN4Q6Qq4ETm3M=.37d25be2-2296-499e-a925-7ab24be4e99e@github.com>
References: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
 <-EvTASKrIweBzLE7uRXAtnLmG4XXp5oN4Q6Qq4ETm3M=.37d25be2-2296-499e-a925-7ab24be4e99e@github.com>
Message-ID: <BTGa-RsKKoRdt_7wbgU_LRoenJQtW_bLV1ifxXxrFY4=.08d867b7-6363-4b1f-9e07-d886e075cdd6@github.com>

On Thu, 27 Jul 2023 00:16:34 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Please review this PR which contains the translations for updates to localized resources in the JDK since RDP1.
>> 
>> Included in this change are improved translations for certain values, which also includes global updates for translations of the words 'annotation' and 'file' for zh_CN.
>> 
>> The following files contain key/value resources that were added, updated, or removed in the original file. (This means that the localized versions of these files contain changes to translations that are a reflection of the original key/value changing, and are not just improved translations).
>> 
>> - src/java.base/share/classes/sun/launcher/resources/launcher.properties
>> - src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>> - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
>> - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties
>> - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
>> - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties
>> 
>> It is recommended to view the changes in UTF-8 native at https://cr.openjdk.org/~jlu/RDP2_Diffs/.
>
> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties line 185:
> 
>> 183: jshell.console.no.javadoc = <no documentation found>
>> 184: jshell.console.do.nothing = Do nothing
>> 185: jshell.console.choice = Choice:\u0020
> 
> I see this backslash is also being removed. It does seem misplaced since none of the other lines use it. But just double checking with you that this is the desired change because for the other locales, the change was to just translate the space to unicode.

Thanks for reviewing Damon, the `` is used to signify the white space after the `:` is intentional. However, using a trailing `\u0020` is more intentional and clear, and allows for consistency between the original and localized versions, so I manually made this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15047#discussion_r1275806234

From jjiang at openjdk.org  Thu Jul 27 06:52:48 2023
From: jjiang at openjdk.org (John Jiang)
Date: Thu, 27 Jul 2023 06:52:48 GMT
Subject: RFR: 8313231: Redundant if statement in ZoneInfoFile
Message-ID: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>

if (i < savingsInstantTransitions.length) {
    // javazic writes the last GMT offset into index 0!
    if (i < savingsInstantTransitions.length) {
        offsets[0] = standardOffsets[standardOffsets.length - 1] * 1000;
        nOffsets = 1;
    }
    ...
}


The second if statement looks unnecessary.

-------------

Commit messages:
 - 8313231: Redundant if statement in ZoneInfoFile

Changes: https://git.openjdk.org/jdk/pull/15052/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15052&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313231
  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15052.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15052/head:pull/15052

PR: https://git.openjdk.org/jdk/pull/15052

From jiefu at openjdk.org  Thu Jul 27 07:07:40 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 27 Jul 2023 07:07:40 GMT
Subject: RFR: 8313231: Redundant if statement in ZoneInfoFile
In-Reply-To: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
References: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
Message-ID: <_SPmmWS-rmB5DVb-0_3zYEV5VARVrGncaK2qiwOrcBc=.9ecdb2e3-de41-40a4-9b41-ee04d909b280@github.com>

On Thu, 27 Jul 2023 06:46:46 GMT, John Jiang <jjiang at openjdk.org> wrote:

> if (i < savingsInstantTransitions.length) {
>     // javazic writes the last GMT offset into index 0!
>     if (i < savingsInstantTransitions.length) {
>         offsets[0] = standardOffsets[standardOffsets.length - 1] * 1000;
>         nOffsets = 1;
>     }
>     ...
> }
> 
> 
> The second if statement looks unnecessary.

LGTM

-------------

Marked as reviewed by jiefu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15052#pullrequestreview-1549140091

From thartmann at openjdk.org  Thu Jul 27 08:10:59 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 27 Jul 2023 08:10:59 GMT
Subject: [jdk21] Integrated: 8313208: ProblemList
 java/util/concurrent/tck/JSR166TestCase.java on select platforms
In-Reply-To: <Ezbjh7kDBaOvJJjNT7Zv1U-Kubclcm-AzotGm-p53vg=.2c9897a5-63cc-4d80-884b-0373bbe4f77b@github.com>
References: <Ezbjh7kDBaOvJJjNT7Zv1U-Kubclcm-AzotGm-p53vg=.2c9897a5-63cc-4d80-884b-0373bbe4f77b@github.com>
Message-ID: <w9eVCpPJt-gZ9vdPMT0r9BpdM5n_efLscLw3vZ1gM0U=.33b23efc-0bdb-4e4f-9d34-71c9a6c34609@github.com>

On Wed, 26 Jul 2023 19:22:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/tck/JSR166TestCase.java on select platforms.

I agree, we will temporarily disable the assert in JDK 21 and revert the problem listing change with https://github.com/openjdk/jdk21/pull/146.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/145#issuecomment-1653109332

From lbourges at openjdk.org  Thu Jul 27 08:33:53 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 27 Jul 2023 08:33:53 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v7]
In-Reply-To: <LLW8WZYmQGyRSJWZlQxdEF9hgdowA2zENlTrdvemUXE=.fa7740c5-f020-46ab-8bd1-3dd6c6c38f17@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <LLW8WZYmQGyRSJWZlQxdEF9hgdowA2zENlTrdvemUXE=.fa7740c5-f020-46ab-8bd1-3dd6c6c38f17@github.com>
Message-ID: <KgnuhW5HLt27TPbamay4Tmz6rxtNbKRfWs1m5JPTaXM=.29694a03-96c5-43fc-8c88-954c949ca2de@github.com>

On Thu, 15 Jun 2023 09:21:13 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> * improved  mixed insertion sort (makes whole sorting faster)
>> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
>> * improved merging sort for almost sorted data
>> * optimized parallel sorting
>> * improved step for pivot candidates and pivot partitioning
>> * extended existing tests
>> * added benchmarking JMH tests
>> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
>> 
>> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938
>
> Laurent Bourg?s has updated the pull request incrementally with 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

Please @AlanBateman could you review this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1653144787

From prappo at openjdk.org  Thu Jul 27 11:03:40 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 27 Jul 2023 11:03:40 GMT
Subject: RFR: 8313231: Redundant if statement in ZoneInfoFile
In-Reply-To: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
References: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
Message-ID: <WkXEKK2noE080KzBMxfg-2xDGqUglB_zA267OpdC6gY=.fa7eeba9-2bb7-4f36-8c5e-20137a0ff9a1@github.com>

On Thu, 27 Jul 2023 06:46:46 GMT, John Jiang <jjiang at openjdk.org> wrote:

> if (i < savingsInstantTransitions.length) {
>     // javazic writes the last GMT offset into index 0!
>     if (i < savingsInstantTransitions.length) {
>         offsets[0] = standardOffsets[standardOffsets.length - 1] * 1000;
>         nOffsets = 1;
>     }
>     ...
> }
> 
> 
> The second if statement looks unnecessary.

src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 471:

> 469:             if (i < savingsInstantTransitions.length) {
> 470:                 // javazic writes the last GMT offset into index 0!
> 471:                 if (i < savingsInstantTransitions.length) {

Even my IDE flags it as always true. While it surely is redundant, I wonder if some other check was intended instead. @jodastephen?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15052#discussion_r1276120009

From rgiulietti at openjdk.org  Thu Jul 27 11:34:07 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 27 Jul 2023 11:34:07 GMT
Subject: RFR: 8312976: MatchResult produces StringIndexOutOfBoundsException for
 groups outside match
Message-ID: <x8ghNv-MsXGwtDhqgBCPbXQFGLTr3x0cWa4qUapadhY=.fa9e7f4f-744f-44aa-85c6-495a76eb2388@github.com>

Fixes a bug showing up after [JDK-8132995](https://bugs.openjdk.org/browse/JDK-8132995) when there are capturing groups outside the match.

-------------

Commit messages:
 - 8312976: MatchResult produces StringIndexOutOfBoundsException for groups outside match

Changes: https://git.openjdk.org/jdk/pull/15053/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15053&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312976
  Stats: 75 lines in 2 files changed: 67 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/15053.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15053/head:pull/15053

PR: https://git.openjdk.org/jdk/pull/15053

From rgiulietti at openjdk.org  Thu Jul 27 11:34:07 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 27 Jul 2023 11:34:07 GMT
Subject: RFR: 8312976: MatchResult produces StringIndexOutOfBoundsException
 for groups outside match
In-Reply-To: <x8ghNv-MsXGwtDhqgBCPbXQFGLTr3x0cWa4qUapadhY=.fa9e7f4f-744f-44aa-85c6-495a76eb2388@github.com>
References: <x8ghNv-MsXGwtDhqgBCPbXQFGLTr3x0cWa4qUapadhY=.fa9e7f4f-744f-44aa-85c6-495a76eb2388@github.com>
Message-ID: <ZNsFKsG6K6PbCQ0njyNjsoM1HGFqrt0CaGaqg-ryRvY=.d5d6a9af-7ba0-4777-ae40-f4a506c6fcf7@github.com>

On Thu, 27 Jul 2023 11:25:57 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Fixes a bug showing up after [JDK-8132995](https://bugs.openjdk.org/browse/JDK-8132995) when there are capturing groups outside the match.

Once integrated in mainline, the fix should be backported to 21, where the bug was introduced.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15053#issuecomment-1653430446

From duke at openjdk.org  Thu Jul 27 11:43:52 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 27 Jul 2023 11:43:52 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v13]
In-Reply-To: <hZjX7BCpWrgwBcfxt316gsEzQClFtX7DqsiSwqrJBmA=.fd1e1a9e-88b4-4a47-8b95-56eb360a8238@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <Q40yhMfrkRyDx5Zfz_y6UUPXTspFUMWQuo_BPl9Dc8U=.ff88f1af-07b6-4a8f-b916-a2e4dd97f21d@github.com>
 <hZjX7BCpWrgwBcfxt316gsEzQClFtX7DqsiSwqrJBmA=.fd1e1a9e-88b4-4a47-8b95-56eb360a8238@github.com>
Message-ID: <_8VBwzIvMfIj2sHCUaOL0jzMryAODzOGHrba42YicTk=.aa9226dd-c5fa-4fcd-ab1c-d61c99b92026@github.com>

On Wed, 26 Jul 2023 20:31:16 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> It could be worth it to have a cache for small integers to skip the calculations altogether.

this PR is only for calculation optimization. caching small values should be a separate PR

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1653445373

From jpstotz at gmx.de  Thu Jul 27 12:51:23 2023
From: jpstotz at gmx.de (Jan Peter Stotz)
Date: Thu, 27 Jul 2023 14:51:23 +0200
Subject: Question on "Improved ZIP64 Extra Field Validation" (JDK-8302483)
Message-ID: <d76e9819-54bc-af64-da73-72d064d66674@gmx.de>

Hi,

could somebody please explain to me how JDK-8302483 made it into all JDK
versions? This patch breaks hundred of software systems as it modifies
the behavior of java.util.zip.ZipFile, making it unable to read
perfectly valid ZIP files.
Even more this behavior can not be changed at run-time (e.g. from within
a library), only by setting a property on the command-line this
additional check can be disabled.

Effectively this means you can no longer use java.util.zip.ZipFile for
reading arbitrary ZIP files and have to switch to alternative
implementations like Apache Commons compress.

Please be aware that a lot auf Android APK files trigger the exception
java.util.zip.ZipException: Invalid CEN header
This means all Java based software processing Android APK files now have
a problem...

And everything just because someone wrote a patch to "Enhance ZIP
performance" (according to the commit message)!?
https://github.com/openjdk/jdk/commit/fff7e1ad00be07810bf948b8a6f94e83c435fa1f

Sorry, but I really don't understand how this patch made it's way into
OpenJDK. Also why is JDK-8302483 non-public - is it security related? If
yes what CVE does it fix?

Jan

From matsaave at openjdk.org  Thu Jul 27 13:40:56 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 27 Jul 2023 13:40:56 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v3]
In-Reply-To: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
Message-ID: <ICAzw_PZum9JfcJ5yHmCjYhr_pDG_gS-XITGKHQLI1E=.a9aa5900-39c5-413b-8187-63cea2731fdf@github.com>

> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 
> 
> 
>  // We have finished dumping the static archive. At this point, there may be pending VM
>  // operations. We have changed some global states (such as vmClasses::_klasses) that
>  // may cause these VM operations to fail. For safety, forget these operations and
>  // exit the VM directly.
>  void MetaspaceShared::exit_after_static_dump() {
>    os::_exit(0);
>  } 
> 
> 
> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.
> 
> Verified with tier 1-9 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Refactored KlassToOopHandleTable, Ioi and Alan comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14879/files
  - new: https://git.openjdk.org/jdk/pull/14879/files/900fa187..dc1915dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14879&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14879&range=01-02

  Stats: 56 lines in 4 files changed: 6 ins; 21 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/14879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14879/head:pull/14879

PR: https://git.openjdk.org/jdk/pull/14879

From stsypanov at openjdk.org  Thu Jul 27 13:45:54 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 27 Jul 2023 13:45:54 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
Message-ID: <OVzRu_LvLmkIa1owohLgzL-fR3SfV6BYToERxWiLEdA=.15a6a092-1c89-44f3-9554-dc7e1714b465@github.com>

On Tue, 25 Jul 2023 23:50:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.
>
> Brian Burkhalter has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 6478546: Decrease malloc limit to 1.5 MB
>  - 6478546: Minor refactoring
>  - 6478546: Prevent short read

src/java.base/share/native/libjava/io_util.c line 199:

> 197:     }
> 198: 
> 199:     if (buf != stackBuf)

Wouldn't this cause a leak when if-condition is not met and `free(buf)` is not called?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1276302042

From rriggs at openjdk.org  Thu Jul 27 14:04:59 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 27 Jul 2023 14:04:59 GMT
Subject: Integrated: 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: <qb5l1fDvpnaV-25vM_IJ5wF205rbwoYF6M0tcmJMuTs=.ec6bc097-1593-4ed7-bdfb-62aeb823f3ad@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.

This pull request has now been integrated.

Changeset: 8650026f
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8650026ff16e5c5eff897f9fd39c0c35fd8b7367
Stats:     84 lines in 17 files changed: 49 ins; 0 del; 35 mod

8310033: Clarify return value of Java Time compareTo methods

Reviewed-by: bpb, scolebourne, prappo, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/14479

From asotona at openjdk.org  Thu Jul 27 14:23:10 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Jul 2023 14:23:10 GMT
Subject: RFR: 8312491: Update Classfile API snippets and examples
Message-ID: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>

8312491: Update Classfile API snippets and examples

-------------

Commit messages:
 - 8312491: Update Classfile API snippets and examples

Changes: https://git.openjdk.org/jdk/pull/14968/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312491
  Stats: 73 lines in 3 files changed: 40 ins; 0 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/14968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14968/head:pull/14968

PR: https://git.openjdk.org/jdk/pull/14968

From briangoetz at openjdk.org  Thu Jul 27 15:02:42 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 27 Jul 2023 15:02:42 GMT
Subject: RFR: 8312491: Update Classfile API snippets and examples
In-Reply-To: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
References: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
Message-ID: <Ttl1J3FLIh4BoYUbpVUUxkjRoU5isQFVMfIAhrK3MKI=.eecd68ae-4b04-465e-afc1-d2d33d39da83@github.com>

On Fri, 21 Jul 2023 09:37:10 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> 8312491: Update Classfile API snippets and examples

src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 1239:

> 1237:         return ldc(BytecodeHelpers.constantEntry(constantPool(), value));
> 1238:     }
> 1239: 

Method needs specification

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14968#discussion_r1276420853

From asotona at openjdk.org  Thu Jul 27 15:19:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Jul 2023 15:19:54 GMT
Subject: RFR: 8312491: Update Classfile API snippets and examples
In-Reply-To: <Ttl1J3FLIh4BoYUbpVUUxkjRoU5isQFVMfIAhrK3MKI=.eecd68ae-4b04-465e-afc1-d2d33d39da83@github.com>
References: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
 <Ttl1J3FLIh4BoYUbpVUUxkjRoU5isQFVMfIAhrK3MKI=.eecd68ae-4b04-465e-afc1-d2d33d39da83@github.com>
Message-ID: <pfPJrvOo1qLD_ixLjMBHSNgLmAYOk_GmRLjdeQk8Nlg=.1f75b896-a16d-4f38-b464-1f1de25525a0@github.com>

On Thu, 27 Jul 2023 14:59:49 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

>> 8312491: Update Classfile API snippets and examples
>
> src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 1239:
> 
>> 1237:         return ldc(BytecodeHelpers.constantEntry(constantPool(), value));
>> 1238:     }
>> 1239: 
> 
> Method needs specification

Right, we need to add a lot of missing javadoc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14968#discussion_r1276442803

From bpb at openjdk.org  Thu Jul 27 15:57:56 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 27 Jul 2023 15:57:56 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <OVzRu_LvLmkIa1owohLgzL-fR3SfV6BYToERxWiLEdA=.15a6a092-1c89-44f3-9554-dc7e1714b465@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
 <OVzRu_LvLmkIa1owohLgzL-fR3SfV6BYToERxWiLEdA=.15a6a092-1c89-44f3-9554-dc7e1714b465@github.com>
Message-ID: <jv0KOoNUvHIwe9XRhkosRM-SKuMcdu0gsAnQeb8U6aM=.5dc29b2c-1e03-4147-9775-28ece98ef11e@github.com>

On Thu, 27 Jul 2023 13:42:43 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - 6478546: Decrease malloc limit to 1.5 MB
>>  - 6478546: Minor refactoring
>>  - 6478546: Prevent short read
>
> src/java.base/share/native/libjava/io_util.c line 199:
> 
>> 197:     }
>> 198: 
>> 199:     if (buf != stackBuf)
> 
> Wouldn't this cause a leak when if-condition is not met and `free(buf)` is not called?

I don't see how this is possible. The value of `buf` is either `stackBuf` or a value returned by `malloc()`. In any case, this code will be superseded.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1276493893

From asemenyuk at openjdk.org  Thu Jul 27 16:10:58 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 27 Jul 2023 16:10:58 GMT
Subject: Integrated: 8311104: dangling-gsl warning in libwixhelper.cpp
In-Reply-To: <NQQrL4Ek8bE-ERRKK24i-5ktl2Fu1g-Vi0-DSK7wgI8=.e35b1911-46c5-4e49-b1c6-d97886782abb@github.com>
References: <NQQrL4Ek8bE-ERRKK24i-5ktl2Fu1g-Vi0-DSK7wgI8=.e35b1911-46c5-4e49-b1c6-d97886782abb@github.com>
Message-ID: <TMeqmtrekIwsNr_FJ-SlF-2u6UQYjIpbr2CANCh7n0Q=.7f58dd55-4265-439b-bbef-69144a642037@github.com>

On Wed, 26 Jul 2023 18:42:47 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8311104: dangling-gsl warning in libwixhelper.cpp

This pull request has now been integrated.

Changeset: 0ca2bfd7
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ca2bfd77960a84486d10d910aa47b2aa9c14e22
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8311104: dangling-gsl warning in libwixhelper.cpp

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/15044

From stsypanov at openjdk.org  Thu Jul 27 16:37:52 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 27 Jul 2023 16:37:52 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <jv0KOoNUvHIwe9XRhkosRM-SKuMcdu0gsAnQeb8U6aM=.5dc29b2c-1e03-4147-9775-28ece98ef11e@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
 <OVzRu_LvLmkIa1owohLgzL-fR3SfV6BYToERxWiLEdA=.15a6a092-1c89-44f3-9554-dc7e1714b465@github.com>
 <jv0KOoNUvHIwe9XRhkosRM-SKuMcdu0gsAnQeb8U6aM=.5dc29b2c-1e03-4147-9775-28ece98ef11e@github.com>
Message-ID: <bxo9b0xNo3CC9f5lIQJPnJdBT6UUUGspbStGVa6Q6g8=.1fe323b6-4bad-4eb9-8b9c-c609b313421b@github.com>

On Thu, 27 Jul 2023 15:54:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/native/libjava/io_util.c line 199:
>> 
>>> 197:     }
>>> 198: 
>>> 199:     if (buf != stackBuf)
>> 
>> Wouldn't this cause a leak when if-condition is not met and `free(buf)` is not called?
>
> I don't see how this is possible. The value of `buf` is either `stackBuf` or a value returned by `malloc()`. In any case, this code will be superseded.

Then I guess we don't need this `if`-clause

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1276544537

From dnguyen at openjdk.org  Thu Jul 27 16:55:51 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 27 Jul 2023 16:55:51 GMT
Subject: RFR: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <BTGa-RsKKoRdt_7wbgU_LRoenJQtW_bLV1ifxXxrFY4=.08d867b7-6363-4b1f-9e07-d886e075cdd6@github.com>
References: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
 <-EvTASKrIweBzLE7uRXAtnLmG4XXp5oN4Q6Qq4ETm3M=.37d25be2-2296-499e-a925-7ab24be4e99e@github.com>
 <BTGa-RsKKoRdt_7wbgU_LRoenJQtW_bLV1ifxXxrFY4=.08d867b7-6363-4b1f-9e07-d886e075cdd6@github.com>
Message-ID: <UOrz91rra5bod31BzvAbODUb2nlHlqYxe_lqWX4cPHs=.edffbff6-f814-4f57-9eaa-089cf59f841a@github.com>

On Thu, 27 Jul 2023 06:48:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties line 185:
>> 
>>> 183: jshell.console.no.javadoc = <no documentation found>
>>> 184: jshell.console.do.nothing = Do nothing
>>> 185: jshell.console.choice = Choice:\u0020
>> 
>> I see this backslash is also being removed. It does seem misplaced since none of the other lines use it. But just double checking with you that this is the desired change because for the other locales, the change was to just translate the space to unicode.
>
> Thanks for reviewing Damon, the `` is used to signify the white space after the `:` is intentional. However, using a trailing `\u0020` is more intentional and clear, and allows for consistency between the original and localized versions, so I manually made this change.

Sure, I agree. Just checking to see if this was a product of the translation tool used, because if so, this might've been a mistake or issue with the tool. Looks fine here then

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15047#discussion_r1276566404

From bpb at openjdk.org  Thu Jul 27 17:02:57 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 27 Jul 2023 17:02:57 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <bxo9b0xNo3CC9f5lIQJPnJdBT6UUUGspbStGVa6Q6g8=.1fe323b6-4bad-4eb9-8b9c-c609b313421b@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
 <OVzRu_LvLmkIa1owohLgzL-fR3SfV6BYToERxWiLEdA=.15a6a092-1c89-44f3-9554-dc7e1714b465@github.com>
 <jv0KOoNUvHIwe9XRhkosRM-SKuMcdu0gsAnQeb8U6aM=.5dc29b2c-1e03-4147-9775-28ece98ef11e@github.com>
 <bxo9b0xNo3CC9f5lIQJPnJdBT6UUUGspbStGVa6Q6g8=.1fe323b6-4bad-4eb9-8b9c-c609b313421b@github.com>
Message-ID: <Yqxz5yq_lvgQ2f4mPLfaEvfsWbotsJYcSPpp6Kk719w=.d9f5ac68-4cec-4cd9-8bcf-a66b56f4967b@github.com>

On Thu, 27 Jul 2023 16:35:05 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> I don't see how this is possible. The value of `buf` is either `stackBuf` or a value returned by `malloc()`. In any case, this code will be superseded.
>
> Then I guess we don't need this `if`-clause

Then I think one gets an error if `0 < len < BUF_SIZE`:


$ cat free.c
#include <stdlib.h>

int main(int argc, char** argv)
{
    char stackBuf[8];
    char* buf;

    buf = stackBuf;
    free(buf);
}
bpb:test{175}$ ./free
free(14365,0x10e6a1600) malloc: *** error for object 0x7ff7b7d38280: pointer being freed was not allocated
free(14365,0x10e6a1600) malloc: *** set a breakpoint in malloc_error_break to debug
Abort trap: 6

This is on macOS.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1276573889

From asotona at openjdk.org  Thu Jul 27 17:15:08 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Jul 2023 17:15:08 GMT
Subject: RFR: 8312491: Update Classfile API snippets and examples [v2]
In-Reply-To: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
References: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
Message-ID: <Cj20q8jwD-wM5oq9IHQQtegzOieNgtVQqPlSehp7NPc=.dc2bded4-2e38-49e6-ba77-25d46bf619fb@github.com>

> 8312491: Update Classfile API snippets and examples

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixing javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14968/files
  - new: https://git.openjdk.org/jdk/pull/14968/files/a81d1829..9d94af19

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=00-01

  Stats: 499 lines in 24 files changed: 495 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14968/head:pull/14968

PR: https://git.openjdk.org/jdk/pull/14968

From asotona at openjdk.org  Thu Jul 27 17:20:01 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Jul 2023 17:20:01 GMT
Subject: RFR: 8312491: Update Classfile API snippets and examples [v3]
In-Reply-To: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
References: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
Message-ID: <ipp7ZCSADQySoPoL0-V_43JUgEgnXXEL4uuE8Fm8NE4=.fa732900-6858-4fa7-9e7a-c17984c04c54@github.com>

> 8312491: Update Classfile API snippets and examples

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixing javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14968/files
  - new: https://git.openjdk.org/jdk/pull/14968/files/9d94af19..3ccee5f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=01-02

  Stats: 214 lines in 1 file changed: 0 ins; 214 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14968/head:pull/14968

PR: https://git.openjdk.org/jdk/pull/14968

From asotona at openjdk.org  Thu Jul 27 17:23:53 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Jul 2023 17:23:53 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v11]
In-Reply-To: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
 <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
Message-ID: <DqlLJxk7U1rSzrnWk6lVU1Q9vTR3hToCUXfWbhdbYaE=.d5759c84-a5bb-4caf-808d-6f48f10569e0@github.com>

On Thu, 20 Jul 2023 09:11:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> 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 227 commits:
> 
>  - Merge branch 'master' into JDK-8294969-javap
>  - Merge branch 'master' into JDK-8294969-javap
>  - fixed code printing and ConstantPoolException reporting indoex
>  - added DydnamicConstantPoolEntry::bootstrapMethodIndex
>    fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
>  - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead
>  - 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
>  - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b

Important fixes have been integrated and all tests are now passing.

Please review.

Thanks,
Adam

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11411#issuecomment-1654064732

From duke at openjdk.org  Thu Jul 27 17:28:52 2023
From: duke at openjdk.org (Qing Xiao)
Date: Thu, 27 Jul 2023 17:28:52 GMT
Subject: RFR: 8294979: test/jdk/tools/jlink 3 test classes use ASM library
Message-ID: <TJWelTKjz_OMRNneuSFsHM5Uu-aoJQtis3eEwDiM88k=.0af87a97-78d2-48d4-ab17-3f1efba4033f@github.com>

Modified 3 of 3 test/jdk/tools/jlink test classes to replace com.sun.tools.classfile library.

-------------

Commit messages:
 - Dropped unnecessary exports.
 - Rollback the original format
 - 8294979: test/jdk/tools/jlink 3 test classes use ASM library

Changes: https://git.openjdk.org/jdk/pull/14877/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14877&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294979
  Stats: 11 lines in 3 files changed: 0 ins; 10 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14877.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14877/head:pull/14877

PR: https://git.openjdk.org/jdk/pull/14877

From asotona at openjdk.org  Thu Jul 27 17:28:53 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Jul 2023 17:28:53 GMT
Subject: RFR: 8294979: test/jdk/tools/jlink 3 test classes use ASM library
In-Reply-To: <TJWelTKjz_OMRNneuSFsHM5Uu-aoJQtis3eEwDiM88k=.0af87a97-78d2-48d4-ab17-3f1efba4033f@github.com>
References: <TJWelTKjz_OMRNneuSFsHM5Uu-aoJQtis3eEwDiM88k=.0af87a97-78d2-48d4-ab17-3f1efba4033f@github.com>
Message-ID: <6M_4nGlqqAfvSp18rRcTx_WxD8JQFEpqpDjSn_bB1HA=.f01a9329-d7e6-41e5-8504-767a5e517618@github.com>

On Thu, 13 Jul 2023 18:35:42 GMT, Qing Xiao <duke at openjdk.org> wrote:

> Modified 3 of 3 test/jdk/tools/jlink test classes to replace com.sun.tools.classfile library.

I would suggest to minimise footprint of the patch and do not change unrelated code.
Any unnecessary reformat can cause conflicts when merging into or from another project or when backporting.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14877#issuecomment-1636089108

From liach at openjdk.org  Thu Jul 27 17:28:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Jul 2023 17:28:53 GMT
Subject: RFR: 8294979: test/jdk/tools/jlink 3 test classes use ASM library
In-Reply-To: <TJWelTKjz_OMRNneuSFsHM5Uu-aoJQtis3eEwDiM88k=.0af87a97-78d2-48d4-ab17-3f1efba4033f@github.com>
References: <TJWelTKjz_OMRNneuSFsHM5Uu-aoJQtis3eEwDiM88k=.0af87a97-78d2-48d4-ab17-3f1efba4033f@github.com>
Message-ID: <fX9TTwn0D_mGd76ZlBc6Xmp53WsdS3PRtLbmLT9koDo=.c4c0cff0-990f-4059-b8bb-a4265794b7d8@github.com>

On Thu, 13 Jul 2023 18:35:42 GMT, Qing Xiao <duke at openjdk.org> wrote:

> Modified 3 of 3 test/jdk/tools/jlink test classes to replace com.sun.tools.classfile library.

I think these exports can probably be removed completely; no test code uses ASM, meaning the export was likely redundant from the very beginning.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14877#issuecomment-1637073997

From asotona at openjdk.org  Thu Jul 27 17:28:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Jul 2023 17:28:54 GMT
Subject: RFR: 8294979: test/jdk/tools/jlink 3 test classes use ASM library
In-Reply-To: <fX9TTwn0D_mGd76ZlBc6Xmp53WsdS3PRtLbmLT9koDo=.c4c0cff0-990f-4059-b8bb-a4265794b7d8@github.com>
References: <TJWelTKjz_OMRNneuSFsHM5Uu-aoJQtis3eEwDiM88k=.0af87a97-78d2-48d4-ab17-3f1efba4033f@github.com>
 <fX9TTwn0D_mGd76ZlBc6Xmp53WsdS3PRtLbmLT9koDo=.c4c0cff0-990f-4059-b8bb-a4265794b7d8@github.com>
Message-ID: <JsIKtR9VvQplTVAiZza1IIIHLxiZT6sDU_OoG-LXIfU=.8cc43803-a6de-4582-bfe8-1c44d24381e8@github.com>

On Sun, 16 Jul 2023 12:37:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think these exports can probably be removed completely; no test code uses ASM, meaning the export was likely redundant from the very beginning.

I can confirm, the tests are passing even without the exports.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14877#issuecomment-1649312283

From naoto at openjdk.org  Thu Jul 27 17:59:40 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 27 Jul 2023 17:59:40 GMT
Subject: RFR: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
References: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
Message-ID: <_lkKzTNMcBXmMJ12xdYHuY7huc4G4sM7nPdN6ZtmrOk=.7b163449-bf71-4f74-a0aa-3881f0645dec@github.com>

On Wed, 26 Jul 2023 20:41:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the translations for updates to localized resources in the JDK since RDP1.
> 
> Included in this change are improved translations for certain values, which also includes global updates for translations of the words 'annotation' and 'file' for zh_CN.
> 
> The following files contain key/value resources that were added, updated, or removed in the original file. (This means that the localized versions of these files contain changes to translations that are a reflection of the original key/value changing, and are not just improved translations).
> 
> - src/java.base/share/classes/sun/launcher/resources/launcher.properties
> - src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
> - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
> - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties
> - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
> - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties
> 
> It is recommended to view the changes in UTF-8 native at https://cr.openjdk.org/~jlu/RDP2_Diffs/.

Haven't looked at each translation, but good to me overall.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15047#pullrequestreview-1550448645

From iklam at openjdk.org  Thu Jul 27 18:09:51 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 27 Jul 2023 18:09:51 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v3]
In-Reply-To: <ICAzw_PZum9JfcJ5yHmCjYhr_pDG_gS-XITGKHQLI1E=.a9aa5900-39c5-413b-8187-63cea2731fdf@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
 <ICAzw_PZum9JfcJ5yHmCjYhr_pDG_gS-XITGKHQLI1E=.a9aa5900-39c5-413b-8187-63cea2731fdf@github.com>
Message-ID: <Uiisv3lkGh_SjPcTWzkagSLARIjBpZ4tjweNOBL_hWk=.3d87a2d3-fc6a-4128-b299-6201573a1394@github.com>

On Thu, 27 Jul 2023 13:40:56 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 
>> 
>> 
>>  // We have finished dumping the static archive. At this point, there may be pending VM
>>  // operations. We have changed some global states (such as vmClasses::_klasses) that
>>  // may cause these VM operations to fail. For safety, forget these operations and
>>  // exit the VM directly.
>>  void MetaspaceShared::exit_after_static_dump() {
>>    os::_exit(0);
>>  } 
>> 
>> 
>> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
>> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
>> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
>> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.
>> 
>> Verified with tier 1-9 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactored KlassToOopHandleTable, Ioi and Alan comments

Looks good. Just a couple of nits.

src/hotspot/share/cds/heapShared.cpp line 331:

> 329:     mtClassShared> {
> 330: public:
> 331:   oop get_oop(MetaspaceObj* obj) {

The word `obj` may be confusing here as it may look like an oop. I think it's better to change it to `ptr`.

A bit of background:

CDS copies two types of objects:  oops (archiveHeapWriter.cpp and heapShared.cpp) and MetsapceObjs (in archiveBuilder.cpp) 

In the former two files, the convention is to use `obj` to refer to oops, and `ptr` to refer to MetsapceObjs.

In archiveBuilder.cpp, since we never use a mix of oops and MetsapceObjs, we use `obj` to refer to MetsapceObjs. This is mostly for historical purposes, and we might some day change it to use `ptr` to be more consistent.

src/hotspot/share/oops/constantPool.cpp line 226:

> 224:       // Handle scratch_handle(THREAD, scratch_references);
> 225:       //HeapShared::add_scratch_resolved_references(this, loader_data->add_handle(scratch_handle));
> 226:       HeapShared::add_scratch_resolved_references(this, scratch_references);

Comments should be removed?

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14879#pullrequestreview-1550470579
PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1276637489
PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1276639485

From roger.riggs at oracle.com  Thu Jul 27 18:35:57 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 27 Jul 2023 14:35:57 -0400
Subject: CFV: New Core Libraries Group Member: Brian Burkhalter
Message-ID: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>

|I hereby nominate |Brian Burkhalter|to Membership in the Core Libraries Group Brian has been working in the 
Core Library team since 2012. Brian's many contributions to the OpenJDK 
libraries include java.io subsystems, NIO channels, files, and buffers. 
He applies his background in math and image processing to OpenJDK 
development. ||Previously, he led JavaFX Media team. Co-designed and implemented 
successor Java audio and video playback and recording API using 
GStreamer, AV Foundation, and libav. Votes are due by August 11th, 2023. 
Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
Votes must be cast in the open by replying to this mailing list For Lazy 
Consensus voting instructions, see [2]. Roger Riggs [1] 
https://openjdk.org/census#core-libs [2] 
https://openjdk.org/groups/#member-vote|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230727/1b5b3275/attachment-0001.htm>

From roger.riggs at oracle.com  Thu Jul 27 18:36:19 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 27 Jul 2023 14:36:19 -0400
Subject: CFV: New Core Libraries Group Member: Brent Christian
Message-ID: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>

|I hereby nominate |Brent Christian|to Membership in the Core Libraries Group Brent has been working in the 
Core Library team at Oracle since 2012. He has made contributions to 
many areas of OpenJDK including java.lang strings, class loader, NIO 
Jar, and many more. Most recently he has been working on steps to 
deprecate and phase out finalization.|
||Previously he worked on OpenJDK AWT, Swing, and JavaFX before joining 
the Core Libraries group.| Votes are due by August 11th, 2023. Only 
current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
Votes must be cast in the open by replying to this mailing list For Lazy 
Consensus voting instructions, see [2]. Roger Riggs [1] 
https://openjdk.org/census#core-libs [2] 
https://openjdk.org/groups/#member-vote|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230727/c1610dfe/attachment.htm>

From roger.riggs at oracle.com  Thu Jul 27 18:36:50 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 27 Jul 2023 14:36:50 -0400
Subject: CFV: New Core Libraries Group Member: Joe Wang
Message-ID: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>

|I hereby nominate Joe Wang||to Membership in the Core Libraries Group Joe has been working in the 
core library team since 2012. He has been maintaining and improving the 
XML library APIs and implementations including ||DOM, SAX, StAX, Transform, Validation, XPath and Catalog. Recently he 
has been updating and improving XML Security. Votes are due by August 
11th, 2023. Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
Votes must be cast in the open by replying to this mailing list For Lazy 
Consensus voting instructions, see [2]. Roger Riggs [1] 
https://openjdk.org/census#core-libs [2] 
https://openjdk.org/groups/#member-vote|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230727/5dd8dd5a/attachment.htm>

From joe.darcy at oracle.com  Thu Jul 27 18:58:32 2023
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 27 Jul 2023 11:58:32 -0700
Subject: CFV: New Core Libraries Group Member: Brian Burkhalter
In-Reply-To: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
References: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
Message-ID: <f943551f-cdd3-625c-f28d-22b13ec2bb2a@oracle.com>

Vote: yes

On 7/27/2023 11:35 AM, Roger Riggs wrote:
> |I hereby nominate |Brian Burkhalter|to Membership in the Core Libraries Group Brian has been working in 
> the Core Library team since 2012. Brian's many contributions to the 
> OpenJDK libraries include java.io subsystems, NIO channels, files, and 
> buffers. He applies his background in math and image processing to 
> OpenJDK development. ||Previously, he led JavaFX Media team. Co-designed and implemented 
> successor Java audio and video playback and recording API using 
> GStreamer, AV Foundation, and libav. Votes are due by August 11th, 
> 2023. Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list For 
> Lazy Consensus voting instructions, see [2]. Roger Riggs [1] 
> https://openjdk.org/census#core-libs [2] 
> https://openjdk.org/groups/#member-vote|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230727/1b2d93ea/attachment-0001.htm>

From joe.darcy at oracle.com  Thu Jul 27 18:58:49 2023
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 27 Jul 2023 11:58:49 -0700
Subject: CFV: New Core Libraries Group Member: Brent Christian
In-Reply-To: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
References: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
Message-ID: <5d517195-d979-ad43-bb3d-389665eba264@oracle.com>

Vote: yes

On 7/27/2023 11:36 AM, Roger Riggs wrote:
> |I hereby nominate |Brent Christian|to Membership in the Core Libraries Group Brent has been working in 
> the Core Library team at Oracle since 2012. He has made contributions 
> to many areas of OpenJDK including java.lang strings, class loader, 
> NIO Jar, and many more. Most recently he has been working on steps to 
> deprecate and phase out finalization.|
> ||Previously he worked on OpenJDK AWT, Swing, and JavaFX before 
> joining the Core Libraries group.| Votes are due by August 11th, 2023. 
> Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list For 
> Lazy Consensus voting instructions, see [2]. Roger Riggs [1] 
> https://openjdk.org/census#core-libs [2] 
> https://openjdk.org/groups/#member-vote|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230727/bda12766/attachment.htm>

From joe.darcy at oracle.com  Thu Jul 27 18:59:00 2023
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 27 Jul 2023 11:59:00 -0700
Subject: CFV: New Core Libraries Group Member: Joe Wang
In-Reply-To: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
References: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
Message-ID: <450d288a-98c4-80aa-c624-39f0732e9408@oracle.com>

Vote: yes

On 7/27/2023 11:36 AM, Roger Riggs wrote:
> |I hereby nominate Joe Wang||to Membership in the Core Libraries Group Joe has been working in the 
> core library team since 2012. He has been maintaining and improving 
> the XML library APIs and implementations including ||DOM, SAX, StAX, Transform, Validation, XPath and Catalog. Recently he 
> has been updating and improving XML Security. Votes are due by August 
> 11th, 2023. Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list For 
> Lazy Consensus voting instructions, see [2]. Roger Riggs [1] 
> https://openjdk.org/census#core-libs [2] 
> https://openjdk.org/groups/#member-vote|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230727/aa58e926/attachment.htm>

From naoto.sato at oracle.com  Thu Jul 27 18:59:09 2023
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 27 Jul 2023 11:59:09 -0700
Subject: CFV: New Core Libraries Group Member: Brian Burkhalter
In-Reply-To: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
References: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
Message-ID: <3e4d58b9-9fe5-e43a-b364-cde939a2a03a@oracle.com>

Vote: yes

Naoto

On 7/27/23 11:35 AM, Roger Riggs wrote:
> |I hereby nominate |Brian Burkhalter|to Membership in the Core Libraries Group Brian has been working in the 
> Core Library team since 2012. Brian's many contributions to the OpenJDK 
> libraries include java.io subsystems, NIO channels, files, and buffers. 
> He applies his background in math and image processing to OpenJDK 
> development. ||Previously, he led JavaFX Media team. Co-designed and implemented 
> successor Java audio and video playback and recording API using 
> GStreamer, AV Foundation, and libav. Votes are due by August 11th, 2023. 
> Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list For Lazy 
> Consensus voting instructions, see [2]. Roger Riggs [1] 
> https://openjdk.org/census#core-libs [2] 
> https://openjdk.org/groups/#member-vote|
> 

From roger.riggs at oracle.com  Thu Jul 27 18:59:44 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 27 Jul 2023 14:59:44 -0400
Subject: CFV: New Core Libraries Group Member: Joe Wang
In-Reply-To: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
References: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
Message-ID: <173572df-4e80-5c6b-d70b-e0d686d397f4@oracle.com>

Vote: Yes

On 7/27/23 2:36 PM, Roger Riggs wrote:
> |I hereby nominate Joe Wang||to Membership in the Core Libraries Group|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230727/edba41bf/attachment.htm>

From naoto.sato at oracle.com  Thu Jul 27 18:59:45 2023
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 27 Jul 2023 11:59:45 -0700
Subject: CFV: New Core Libraries Group Member: Brent Christian
In-Reply-To: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
References: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
Message-ID: <e2b165cd-8228-9c3f-cdc2-00c0d44ffe58@oracle.com>

Vote: yes

Naoto

On 7/27/23 11:36 AM, Roger Riggs wrote:
> |I hereby nominate |Brent Christian|to Membership in the Core Libraries Group Brent has been working in the 
> Core Library team at Oracle since 2012. He has made contributions to 
> many areas of OpenJDK including java.lang strings, class loader, NIO 
> Jar, and many more. Most recently he has been working on steps to 
> deprecate and phase out finalization.|
> ||Previously he worked on OpenJDK AWT, Swing, and JavaFX before joining 
> the Core Libraries group.| Votes are due by August 11th, 2023. Only 
> current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list For Lazy 
> Consensus voting instructions, see [2]. Roger Riggs [1] 
> https://openjdk.org/census#core-libs [2] 
> https://openjdk.org/groups/#member-vote|
> 

From roger.riggs at oracle.com  Thu Jul 27 19:00:28 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 27 Jul 2023 15:00:28 -0400
Subject: CFV: New Core Libraries Group Member: Brian Burkhalter
In-Reply-To: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
References: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
Message-ID: <a255da53-bd62-95ae-adda-302ee8810b42@oracle.com>

Vote: Yes

On 7/27/23 2:35 PM, Roger Riggs wrote:
> |I hereby nominate |Brian Burkhalter|to Membership in the Core Libraries Group|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230727/5f86c20b/attachment-0001.htm>

From naoto.sato at oracle.com  Thu Jul 27 19:00:36 2023
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 27 Jul 2023 12:00:36 -0700
Subject: CFV: New Core Libraries Group Member: Joe Wang
In-Reply-To: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
References: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
Message-ID: <167540cc-9643-2531-b08d-668d7baf82a4@oracle.com>

Vote: yes

Naoto

On 7/27/23 11:36 AM, Roger Riggs wrote:
> |I hereby nominate Joe Wang||to Membership in the Core Libraries Group Joe has been working in the 
> core library team since 2012. He has been maintaining and improving the 
> XML library APIs and implementations including ||DOM, SAX, StAX, Transform, Validation, XPath and Catalog. Recently he 
> has been updating and improving XML Security. Votes are due by August 
> 11th, 2023. Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list For Lazy 
> Consensus voting instructions, see [2]. Roger Riggs [1] 
> https://openjdk.org/census#core-libs [2] 
> https://openjdk.org/groups/#member-vote|
> 

From roger.riggs at oracle.com  Thu Jul 27 19:00:52 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 27 Jul 2023 15:00:52 -0400
Subject: CFV: New Core Libraries Group Member: Brent Christian
In-Reply-To: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
References: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
Message-ID: <522ec405-f07e-1446-a6a5-c2415c5b8993@oracle.com>

Vote: Yes

On 7/27/23 2:36 PM, Roger Riggs wrote:
> |I hereby nominate |Brent Christian|to Membership in the Core Libraries Group|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230727/c4283a9b/attachment.htm>

From matsaave at openjdk.org  Thu Jul 27 19:09:00 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 27 Jul 2023 19:09:00 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v4]
In-Reply-To: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
Message-ID: <JNmxvM9LYO3qt1Eccce9fX3f2_9s7FzDEGNZHlaVQ88=.05986efe-f203-4b64-bb33-7f4db762773b@github.com>

> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 
> 
> 
>  // We have finished dumping the static archive. At this point, there may be pending VM
>  // operations. We have changed some global states (such as vmClasses::_klasses) that
>  // may cause these VM operations to fail. For safety, forget these operations and
>  // exit the VM directly.
>  void MetaspaceShared::exit_after_static_dump() {
>    os::_exit(0);
>  } 
> 
> 
> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.
> 
> Verified with tier 1-9 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Ioi comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14879/files
  - new: https://git.openjdk.org/jdk/pull/14879/files/dc1915dc..64d8c638

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14879&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14879&range=02-03

  Stats: 10 lines in 2 files changed: 0 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14879/head:pull/14879

PR: https://git.openjdk.org/jdk/pull/14879

From mandy.chung at oracle.com  Thu Jul 27 19:20:58 2023
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 27 Jul 2023 12:20:58 -0700
Subject: CFV: New Core Libraries Group Member: Brian Burkhalter
In-Reply-To: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
References: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
Message-ID: <ca8a2a0b-beb7-6293-89b6-a3aeaf925a77@oracle.com>

Vote: Yes

Mandy

On 7/27/23 11:35 AM, Roger Riggs wrote:
> |I hereby nominate |Brian Burkhalter|to Membership in the Core Libraries Group Brian has been working in 
> the Core Library team since 2012. Brian's many contributions to the 
> OpenJDK libraries include java.io subsystems, NIO channels, files, and 
> buffers. He applies his background in math and image processing to 
> OpenJDK development. ||Previously, he led JavaFX Media team. Co-designed and implemented 
> successor Java audio and video playback and recording API using 
> GStreamer, AV Foundation, and libav. Votes are due by August 11th, 
> 2023. Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list For 
> Lazy Consensus voting instructions, see [2]. Roger Riggs [1] 
> https://openjdk.org/census#core-libs [2] 
> https://openjdk.org/groups/#member-vote|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230727/dee8b764/attachment.htm>

From mandy.chung at oracle.com  Thu Jul 27 19:21:06 2023
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 27 Jul 2023 12:21:06 -0700
Subject: CFV: New Core Libraries Group Member: Brent Christian
In-Reply-To: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
References: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
Message-ID: <1324a795-b9a0-fbd2-aebc-c4fdd7d0671b@oracle.com>

Vote: Yes

Mandy

On 7/27/23 11:36 AM, Roger Riggs wrote:
> |I hereby nominate |Brent Christian|to Membership in the Core Libraries Group Brent has been working in 
> the Core Library team at Oracle since 2012. He has made contributions 
> to many areas of OpenJDK including java.lang strings, class loader, 
> NIO Jar, and many more. Most recently he has been working on steps to 
> deprecate and phase out finalization.|
> ||Previously he worked on OpenJDK AWT, Swing, and JavaFX before 
> joining the Core Libraries group.| Votes are due by August 11th, 2023. 
> Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list For 
> Lazy Consensus voting instructions, see [2]. Roger Riggs [1] 
> https://openjdk.org/census#core-libs [2] 
> https://openjdk.org/groups/#member-vote|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230727/03d562f2/attachment.htm>

From mandy.chung at oracle.com  Thu Jul 27 19:21:19 2023
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 27 Jul 2023 12:21:19 -0700
Subject: CFV: New Core Libraries Group Member: Joe Wang
In-Reply-To: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
References: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
Message-ID: <f075dec4-7b29-1e28-4e65-3ba1790940dd@oracle.com>

Vote: Yes

Mandy

On 7/27/23 11:36 AM, Roger Riggs wrote:
> |I hereby nominate Joe Wang||to Membership in the Core Libraries Group Joe has been working in the 
> core library team since 2012. He has been maintaining and improving 
> the XML library APIs and implementations including ||DOM, SAX, StAX, Transform, Validation, XPath and Catalog. Recently he 
> has been updating and improving XML Security. Votes are due by August 
> 11th, 2023. Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list For 
> Lazy Consensus voting instructions, see [2]. Roger Riggs [1] 
> https://openjdk.org/census#core-libs [2] 
> https://openjdk.org/groups/#member-vote|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230727/f3fd73e4/attachment-0001.htm>

From stsypanov at openjdk.org  Thu Jul 27 19:44:40 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 27 Jul 2023 19:44:40 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <Yqxz5yq_lvgQ2f4mPLfaEvfsWbotsJYcSPpp6Kk719w=.d9f5ac68-4cec-4cd9-8bcf-a66b56f4967b@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
 <OVzRu_LvLmkIa1owohLgzL-fR3SfV6BYToERxWiLEdA=.15a6a092-1c89-44f3-9554-dc7e1714b465@github.com>
 <jv0KOoNUvHIwe9XRhkosRM-SKuMcdu0gsAnQeb8U6aM=.5dc29b2c-1e03-4147-9775-28ece98ef11e@github.com>
 <bxo9b0xNo3CC9f5lIQJPnJdBT6UUUGspbStGVa6Q6g8=.1fe323b6-4bad-4eb9-8b9c-c609b313421b@github.com>
 <Yqxz5yq_lvgQ2f4mPLfaEvfsWbotsJYcSPpp6Kk719w=.d9f5ac68-4cec-4cd9-8bcf-a66b56f4967b@github.com>
Message-ID: <7tlSYFjj4Pox7sG9GFRpGGUwrRT42TgNPXMARSh4Efo=.6b16c15c-85a7-499c-b838-a04294482e73@github.com>

On Thu, 27 Jul 2023 16:59:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Then I guess we don't need this `if`-clause
>
> Then I think one gets an error if `0 < len < BUF_SIZE`:
> 
> 
> $ cat free.c
> #include <stdlib.h>
> 
> int main(int argc, char** argv)
> {
>     char stackBuf[8];
>     char* buf;
> 
>     buf = stackBuf;
>     free(buf);
> }
> bpb:test{175}$ ./free
> free(14365,0x10e6a1600) malloc: *** error for object 0x7ff7b7d38280: pointer being freed was not allocated
> free(14365,0x10e6a1600) malloc: *** set a breakpoint in malloc_error_break to debug
> Abort trap: 6
> 
> This is on macOS.

Right!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1276747895

From mchung at openjdk.org  Thu Jul 27 23:04:51 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 27 Jul 2023 23:04:51 GMT
Subject: RFR: 8294979: test/jdk/tools/jlink 3 test classes use ASM library
In-Reply-To: <TJWelTKjz_OMRNneuSFsHM5Uu-aoJQtis3eEwDiM88k=.0af87a97-78d2-48d4-ab17-3f1efba4033f@github.com>
References: <TJWelTKjz_OMRNneuSFsHM5Uu-aoJQtis3eEwDiM88k=.0af87a97-78d2-48d4-ab17-3f1efba4033f@github.com>
Message-ID: <yxv5jXQOFxPAFU6wPvoZl99aFkwlm7NsyJvWc0HCSAo=.d54534a7-ec4b-43d8-9ead-83c55f6f98c4@github.com>

On Thu, 13 Jul 2023 18:35:42 GMT, Qing Xiao <duke at openjdk.org> wrote:

> Modified 3 of 3 test/jdk/tools/jlink test classes to replace com.sun.tools.classfile library.

Looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14877#pullrequestreview-1550959571

From duke at openjdk.org  Fri Jul 28 02:20:03 2023
From: duke at openjdk.org (duke)
Date: Fri, 28 Jul 2023 02:20:03 GMT
Subject: Withdrawn: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access
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: <OQ_vR1tRs-oozvsyQkteIdIbG_xcNn5EVXTrVUk32fs=.0320797b-f479-4b53-9f48-82a095d8c4f9@github.com>

On Wed, 24 May 2023 19:36:44 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   15  3.661 ? 0.008  ops/us
> UUIDRandomBench.max     thrpt   15  2.400 ? 0.031  ops/us...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14135

From duke at openjdk.org  Fri Jul 28 03:43:33 2023
From: duke at openjdk.org (sid8606)
Date: Fri, 28 Jul 2023 03:43:33 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v4]
In-Reply-To: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
Message-ID: <TyjBVa7RY5Cou1bgzVxWAcQESutIP8xpy8cEmLDx-DY=.127f103f-2cca-4ab7-87e2-2c4d46227cb3@github.com>

> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).

sid8606 has updated the pull request incrementally with one additional commit since the last revision:

  revert platform byte ordering changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14801/files
  - new: https://git.openjdk.org/jdk/pull/14801/files/f916864d..75229b4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14801/head:pull/14801

PR: https://git.openjdk.org/jdk/pull/14801

From duke at openjdk.org  Fri Jul 28 03:50:18 2023
From: duke at openjdk.org (sid8606)
Date: Fri, 28 Jul 2023 03:50:18 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v5]
In-Reply-To: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
Message-ID: <qBtY6vfdLNxNM5riUABOeuyg2KQb0PM8hUPd7m3pgUU=.996e58fc-d052-46c7-aaec-33fc0bacfa2e@github.com>

> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).

sid8606 has updated the pull request incrementally with one additional commit since the last revision:

  remove if statements around the spill/fill code
  
  See: #15025 (should_save_return_value being dependent on _needs_transition is a bug).

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14801/files
  - new: https://git.openjdk.org/jdk/pull/14801/files/75229b4c..107b971f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=03-04

  Stats: 15 lines in 1 file changed: 0 ins; 15 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14801/head:pull/14801

PR: https://git.openjdk.org/jdk/pull/14801

From duke at openjdk.org  Fri Jul 28 03:59:26 2023
From: duke at openjdk.org (sid8606)
Date: Fri, 28 Jul 2023 03:59:26 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v6]
In-Reply-To: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
Message-ID: <CRkpBSFzMIMI4km33WN9nLGSp7JuMM5s-2GdotfdeV8=.c6b252f1-74c5-4747-b528-26f787152fe2@github.com>

> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).

sid8606 has updated the pull request incrementally with one additional commit since the last revision:

  Preserve and restore register Z_R6
  
  Though Z_R6 is argument register it is a saved register
  so preserve and restore Z_R6 register

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14801/files
  - new: https://git.openjdk.org/jdk/pull/14801/files/107b971f..cc2292dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=04-05

  Stats: 13 lines in 2 files changed: 3 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/14801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14801/head:pull/14801

PR: https://git.openjdk.org/jdk/pull/14801

From duke at openjdk.org  Fri Jul 28 04:00:46 2023
From: duke at openjdk.org (sid8606)
Date: Fri, 28 Jul 2023 04:00:46 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <WKe92pA4Ts6x49_jX5NoV5WBy4tSgXAAKH1owWfl7dU=.f57ae55c-05f1-45ef-a14d-5c52085bf898@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
 <Yrs1mKpyZQZrXqCFtSxOemkcvrh4xMyCr2mydFSU9Nc=.ca809339-95de-4e1a-8324-f93fb9cb8b72@github.com>
 <WKe92pA4Ts6x49_jX5NoV5WBy4tSgXAAKH1owWfl7dU=.f57ae55c-05f1-45ef-a14d-5c52085bf898@github.com>
Message-ID: <OxDi1l-7yBRBFba8vC9qYPT5CLj9P8P6cJCIUDgad4M=.cacb392c-a836-4999-a9aa-09127c963532@github.com>

On Thu, 27 Jul 2023 05:05:57 GMT, sid8606 <duke at openjdk.org> wrote:

>> src/hotspot/cpu/s390/downcallLinker_s390.cpp line 162:
>> 
>>> 160: 
>>> 161:   assert(!_needs_return_buffer, "unexpected needs_return_buffer");
>>> 162:   bool should_save_return_value = _needs_transition;;
>> 
>> This should always be `true`, so I don't think you need the `if` statements around the spill/fill code below.
>> 
>> See: https://github.com/openjdk/jdk/pull/15025 (`should_save_return_value` being dependent on `_needs_transition` is a bug).
>
> Thank you, I'll make changes.

Made the changes in a new commit

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1277065390

From duke at openjdk.org  Fri Jul 28 04:04:02 2023
From: duke at openjdk.org (sid8606)
Date: Fri, 28 Jul 2023 04:04:02 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <5ifOngKE41_DMQw35KiJQzf8L1MP_smglYyyNCipf_k=.5c7aad97-0615-4ef4-a61a-98d3ecb282b3@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
 <5ifOngKE41_DMQw35KiJQzf8L1MP_smglYyyNCipf_k=.5c7aad97-0615-4ef4-a61a-98d3ecb282b3@github.com>
Message-ID: <Zn31yVLXbW9WQ8rOjiQ4MJW4n42sg1wJhY0m4Da_ymM=.c482d5a9-944e-4010-b5f2-bbbc828d39f1@github.com>

On Fri, 21 Jul 2023 12:17:55 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address suggestions from Jorn Vernee
>
> I can see it failing with `make run-test TEST="jdk/java/foreign"` on g9-z15, glibc 2.31 (patch applied to jdk head).

@TheRealMDoerr I have fixed StdLibTest.java fails on glib2.31 version in a new commit. I have tested on my end now it passes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14801#issuecomment-1654964500

From serb at openjdk.org  Fri Jul 28 05:54:24 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 28 Jul 2023 05:54:24 GMT
Subject: [jdk21] RFR: 8313260: JDK21: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java on linux-x86
Message-ID: <aAe2EfwCbhBufeuKFbNp1N9bwoUolT04vzI1ujZgIt0=.e3fdc7e0-feb2-480d-a0cd-52f8cfef1856@github.com>

This patch adds the  java/lang/ScopedValue/StressStackOverflow.java to the problem list for linux-x86 where it intermittently fails on a GA, ex: https://github.com/openjdk/jdk21/pull/148

This is only for JDK 21, test passes on JDK 22.

-------------

Commit messages:
 - use linux-i586
 - 8313260:  JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on linux-x86

Changes: https://git.openjdk.org/jdk21/pull/149/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=149&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313260
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk21/pull/149.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/149/head:pull/149

PR: https://git.openjdk.org/jdk21/pull/149

From jpai at openjdk.org  Fri Jul 28 06:13:53 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 28 Jul 2023 06:13:53 GMT
Subject: [jdk21] RFR: 8313260: JDK21: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java on linux-x86
In-Reply-To: <aAe2EfwCbhBufeuKFbNp1N9bwoUolT04vzI1ujZgIt0=.e3fdc7e0-feb2-480d-a0cd-52f8cfef1856@github.com>
References: <aAe2EfwCbhBufeuKFbNp1N9bwoUolT04vzI1ujZgIt0=.e3fdc7e0-feb2-480d-a0cd-52f8cfef1856@github.com>
Message-ID: <jqFJHdikyuq6jxuloFghoPJfufqXSq7mynwalCdkcp0=.970985d5-d96b-4b77-b958-ea744fd1365b@github.com>

On Thu, 27 Jul 2023 18:21:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds the  java/lang/ScopedValue/StressStackOverflow.java to the problem list for linux-x86 where it intermittently fails on a GA, ex: https://github.com/openjdk/jdk21/pull/148
> 
> This is only for JDK 21, test passes on JDK 22.

Hello Sergey, 8308609 which is being referenced here in the problem list is already a resolved bug https://bugs.openjdk.org/browse/JDK-8308609. Did you mean to use some other bug id in the problem list? 

> This is only for JDK 21, test passes on JDK 22.

Would you happen to know why it passes on 22 but not on 21? There are several JBS issues and discussions around this `StressStackOverflow.java` test case, so it's a bit hard to determine if there's something else that needs to be backported to 21.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/149#issuecomment-1655086189

From serb at openjdk.org  Fri Jul 28 06:38:57 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 28 Jul 2023 06:38:57 GMT
Subject: [jdk21] RFR: 8313260: JDK21: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java on linux-x86
In-Reply-To: <aAe2EfwCbhBufeuKFbNp1N9bwoUolT04vzI1ujZgIt0=.e3fdc7e0-feb2-480d-a0cd-52f8cfef1856@github.com>
References: <aAe2EfwCbhBufeuKFbNp1N9bwoUolT04vzI1ujZgIt0=.e3fdc7e0-feb2-480d-a0cd-52f8cfef1856@github.com>
Message-ID: <6aVUE7uhn7tzr-XY6fbi90AtupwvnyHfJsmoxTZ4O74=.62e7a0db-92e5-4c04-928c-b61494758e4c@github.com>

On Thu, 27 Jul 2023 18:21:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds the  java/lang/ScopedValue/StressStackOverflow.java to the problem list for linux-x86 where it intermittently fails on a GA, ex: https://github.com/openjdk/jdk21/pull/148
> 
> This is only for JDK 21, test passes on JDK 22.

That bug is resolved in JDK 22 and was not backported to JDK21, one of the reasons described here:
https://bugs.openjdk.org/browse/JDK-8310822

At the same time, the test was updated in JDK22 by https://bugs.openjdk.org/browse/JDK-8311926. I think one of them solves the problem.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/149#issuecomment-1655112430

From clanger at openjdk.org  Fri Jul 28 06:42:57 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 28 Jul 2023 06:42:57 GMT
Subject: [jdk21] RFR: 8313260: JDK21: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java on linux-x86
In-Reply-To: <aAe2EfwCbhBufeuKFbNp1N9bwoUolT04vzI1ujZgIt0=.e3fdc7e0-feb2-480d-a0cd-52f8cfef1856@github.com>
References: <aAe2EfwCbhBufeuKFbNp1N9bwoUolT04vzI1ujZgIt0=.e3fdc7e0-feb2-480d-a0cd-52f8cfef1856@github.com>
Message-ID: <R7_YmfuEtZn_Xc0mpiz8tpbGfKmDMiipwaUQfR3P4kc=.3a6545ec-e4f9-4d6b-b901-7aff33a15520@github.com>

On Thu, 27 Jul 2023 18:21:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds the  java/lang/ScopedValue/StressStackOverflow.java to the problem list for linux-x86 where it intermittently fails on a GA, ex: https://github.com/openjdk/jdk21/pull/148
> 
> This is only for JDK 21, test passes on JDK 22.

This is good. Thanks for doing it. I guess we should backport the real fixes to jdk21u.

-------------

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/149#pullrequestreview-1551465386

From duke at openjdk.org  Fri Jul 28 08:00:47 2023
From: duke at openjdk.org (Cristian Vat)
Date: Fri, 28 Jul 2023 08:00:47 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v2]
In-Reply-To: <PsTu5E6ACWA3qBtfWidauo_1uCFAQ7S7xZPjeVMxTwU=.0e76e9ae-2ea7-4b5d-820d-a6b5d1eb46f1@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
 <PsTu5E6ACWA3qBtfWidauo_1uCFAQ7S7xZPjeVMxTwU=.0e76e9ae-2ea7-4b5d-820d-a6b5d1eb46f1@github.com>
Message-ID: <Iqp6jcm08DyZCbC3yIBkOiG6H4Z70RSS5ObjUjGl94c=.0f81015d-e231-415c-9cc8-ebcfec4cdef3@github.com>

On Sat, 22 Jul 2023 12:13:10 GMT, Cristian Vat <duke at openjdk.org> wrote:

>> Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.
>> 
>> Original clamping to 10 possibly due to documented behavior from javadoc: 
>> "In this class, \1 through \9 are always interpreted as back references, "
>> 
>> Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
>> Added a match failure condition in Pattern that fixes failing tests.
>> 
>> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"
>> 
>> A group that does not exist in the original Pattern can never match so neither can a backref to that group.
>> If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
>> So a group index outside groups array length must never match.
>
> Cristian Vat has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce allocations also for Matcher.usePattern

ping @shipilev, if you could take a look here

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14894#issuecomment-1655226415

From asotona at openjdk.org  Fri Jul 28 08:32:11 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 28 Jul 2023 08:32:11 GMT
Subject: RFR: 8312491: Update Classfile API snippets and examples [v4]
In-Reply-To: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
References: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
Message-ID: <oxJpUpHGM0daFJbMVR61mR-FnXetriX8Qiu3MUt_0o8=.16260801-f78d-4188-8eca-e6af5180f488@github.com>

> 8312491: Update Classfile API snippets and examples

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixing javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14968/files
  - new: https://git.openjdk.org/jdk/pull/14968/files/3ccee5f7..8071164a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=02-03

  Stats: 225 lines in 2 files changed: 185 ins; 29 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/14968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14968/head:pull/14968

PR: https://git.openjdk.org/jdk/pull/14968

From shade at openjdk.org  Fri Jul 28 08:43:52 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Jul 2023 08:43:52 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v2]
In-Reply-To: <PsTu5E6ACWA3qBtfWidauo_1uCFAQ7S7xZPjeVMxTwU=.0e76e9ae-2ea7-4b5d-820d-a6b5d1eb46f1@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
 <PsTu5E6ACWA3qBtfWidauo_1uCFAQ7S7xZPjeVMxTwU=.0e76e9ae-2ea7-4b5d-820d-a6b5d1eb46f1@github.com>
Message-ID: <EQXyOHqtSlA0c7UIhuAuwy5yHWYbOHLmPPVgDp7a9Ns=.50771041-f734-4674-9b55-6df4ea582f9b@github.com>

On Sat, 22 Jul 2023 12:13:10 GMT, Cristian Vat <duke at openjdk.org> wrote:

>> Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.
>> 
>> Original clamping to 10 possibly due to documented behavior from javadoc: 
>> "In this class, \1 through \9 are always interpreted as back references, "
>> 
>> Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
>> Added a match failure condition in Pattern that fixes failing tests.
>> 
>> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"
>> 
>> A group that does not exist in the original Pattern can never match so neither can a backref to that group.
>> If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
>> So a group index outside groups array length must never match.
>
> Cristian Vat has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce allocations also for Matcher.usePattern

Shouldn't the similar change be in `CIBackRef.match` too? The fact current tests do not catch it makes me uneasy: the test coverage seems to be rather low there. 

We need a regex expert to look at it. @rgiulietti @igraves might help us out here?

src/java.base/share/classes/java/util/regex/Pattern.java line 5190:

> 5188:         }
> 5189:         boolean match(Matcher matcher, int i, CharSequence seq) {
> 5190: 

Excess new line.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14894#pullrequestreview-1551614576
PR Review Comment: https://git.openjdk.org/jdk/pull/14894#discussion_r1277261871

From shade at openjdk.org  Fri Jul 28 08:56:08 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Jul 2023 08:56:08 GMT
Subject: RFR: 8313307: java/util/Formatter/Padding.java fails on some Locales
Message-ID: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>

Fails like this:


$ CONF=macosx-aarch64-server-fastdebug make images test TEST=java/util/Formatter/Padding.java

...
STARTED Padding::padding '[216] -0000001.2, % 010.1f, -1.2'
org.opentest4j.AssertionFailedError: expected: <-0000001.2> but was: <-0000001,2>


Looks like a locale problem in test, so the simplest fix is to ask for a neutral Locale there.

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/15066/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15066&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313307
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15066/head:pull/15066

PR: https://git.openjdk.org/jdk/pull/15066

From alanb at openjdk.org  Fri Jul 28 09:12:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Jul 2023 09:12:56 GMT
Subject: [jdk21] RFR: 8313260: JDK21: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java on linux-x86
In-Reply-To: <aAe2EfwCbhBufeuKFbNp1N9bwoUolT04vzI1ujZgIt0=.e3fdc7e0-feb2-480d-a0cd-52f8cfef1856@github.com>
References: <aAe2EfwCbhBufeuKFbNp1N9bwoUolT04vzI1ujZgIt0=.e3fdc7e0-feb2-480d-a0cd-52f8cfef1856@github.com>
Message-ID: <mimxRr66BIrTDBuBqE9hZmX9aswPT0mSQaaQP9PgFa8=.6535385c-1056-40fe-88ce-8fe237a98303@github.com>

On Thu, 27 Jul 2023 18:21:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds the  java/lang/ScopedValue/StressStackOverflow.java to the problem list for linux-x86 where it intermittently fails on a GA, ex: https://github.com/openjdk/jdk21/pull/148
> 
> This is only for JDK 21, test passes on JDK 22.

JDK-8308609 was meant to back ported to jdk21, info jdk12u. If you are temporarily excluding the test on platforms that don't have a port of VM Continuations when JDK-8308609 is the issue to use. I assume JDK-8303498 can be closed.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/149#issuecomment-1655341421

From duke at openjdk.org  Fri Jul 28 09:29:48 2023
From: duke at openjdk.org (Cristian Vat)
Date: Fri, 28 Jul 2023 09:29:48 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v3]
In-Reply-To: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
Message-ID: <JIOMgOYbqejdVw1w-2c9VpyNzsar1LZ4GnaalCOZSgE=.36d40d19-9e2b-4154-adcc-b3c0378d44d6@github.com>

> Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.
> 
> Original clamping to 10 possibly due to documented behavior from javadoc: 
> "In this class, \1 through \9 are always interpreted as back references, "
> 
> Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
> Added a match failure condition in Pattern that fixes failing tests.
> 
> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"
> 
> A group that does not exist in the original Pattern can never match so neither can a backref to that group.
> If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
> So a group index outside groups array length must never match.

Cristian Vat has updated the pull request incrementally with one additional commit since the last revision:

  remove new line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14894/files
  - new: https://git.openjdk.org/jdk/pull/14894/files/596eb3db..4c6c3ec0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14894&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14894&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14894/head:pull/14894

PR: https://git.openjdk.org/jdk/pull/14894

From duke at openjdk.org  Fri Jul 28 09:32:52 2023
From: duke at openjdk.org (Cristian Vat)
Date: Fri, 28 Jul 2023 09:32:52 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v3]
In-Reply-To: <JIOMgOYbqejdVw1w-2c9VpyNzsar1LZ4GnaalCOZSgE=.36d40d19-9e2b-4154-adcc-b3c0378d44d6@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
 <JIOMgOYbqejdVw1w-2c9VpyNzsar1LZ4GnaalCOZSgE=.36d40d19-9e2b-4154-adcc-b3c0378d44d6@github.com>
Message-ID: <1eL8CBMcp2KXLRjR0iWLxfXZA3yUSGPCBklXCgCHm4s=.d95b9ef1-0de8-4b09-baed-3aa62b0b03ef@github.com>

On Fri, 28 Jul 2023 09:29:48 GMT, Cristian Vat <duke at openjdk.org> wrote:

>> Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.
>> 
>> Original clamping to 10 possibly due to documented behavior from javadoc: 
>> "In this class, \1 through \9 are always interpreted as back references, "
>> 
>> Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
>> Added a match failure condition in Pattern that fixes failing tests.
>> 
>> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"
>> 
>> A group that does not exist in the original Pattern can never match so neither can a backref to that group.
>> If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
>> So a group index outside groups array length must never match.
>
> Cristian Vat has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove new line

`RegExTest#backRefTest` seems to be pretty extensive but only for `BackRef` not `CIBackRef`

I saw one `CIBackRef` related test added in https://github.com/openjdk/jdk/pull/7501 but it's very simple/specific.

I triggered test failure locally by duplicating `backRefTest` 1-9 loop with `(?i)` in pattern so yes it seems like `CIBackRef` needs same change.

But not sure about the test, duplicating loop seems odd. Maybe entire `RegExTest#backRefTest` needs to be duplicated into a `ciBackRefTest` with all patterns preprended with `(?i)` ? Wouldn't look too clean.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14894#issuecomment-1655371709

From redestad at openjdk.org  Fri Jul 28 10:07:50 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 28 Jul 2023 10:07:50 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
Message-ID: <EjOjcDzSPQv8ZrQFAlPvvmlgTTDtkBqzACPE3EytX0w=.35b981f2-28e8-4680-91c7-00d1612616b8@github.com>

On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR adds an internal method to calculate hash code from the provided integer array, offset and length into that array, and the initial hash code value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's either ArraysSupport.vectorizedHashCode with an offset, length and initial value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling. Unfortunately, it's the only hash code method that operates on an array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, behaviour which was specified but untested.

I think we could consider dropping `vectorized` from `vectorizedHashCode`: there's nothing in the library-side implementation for this that is explicitly setting up for vectorization of each case (unlike the `mismatch/vectorizedMismatch` pair). Handling of short arrays is dealt with in the intrinsic, and care was taken to make sure that the implementation is as fast or faster for small as well as large inputs.

It might make sense to move the tiny-input case switch to `ArraysSupport` though, and have it delegate to the IntrinsicCandidate method (the point of those is to avoid calling into the intrinsic routine for tiny inputs).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1655426453

From prappo at openjdk.org  Fri Jul 28 10:49:43 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 28 Jul 2023 10:49:43 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <EjOjcDzSPQv8ZrQFAlPvvmlgTTDtkBqzACPE3EytX0w=.35b981f2-28e8-4680-91c7-00d1612616b8@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
 <EjOjcDzSPQv8ZrQFAlPvvmlgTTDtkBqzACPE3EytX0w=.35b981f2-28e8-4680-91c7-00d1612616b8@github.com>
Message-ID: <SJlCUuRBmZB0FUMYAYKoGa9UMCp6mR-nY5FPZsVOkEA=.5b3c9b3a-af59-45a8-a45b-751b4f748e71@github.com>

On Fri, 28 Jul 2023 10:05:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I think we could consider dropping `vectorized` from `vectorizedHashCode`: there's nothing in the library-side implementation for this that is explicitly setting up for vectorization of each case (unlike the `mismatch/vectorizedMismatch` pair).

Sounds good; I specifically dislike "vectorized" being in the name of the method that is called by clients who don't seem to require that behaviour. It's misleading.

Method naming aside, `ArraysSupport.vectorizedHashCode` has one additional wrinkle. One of its arguments, `int basicType`, accepts untyped constants whose names might be so counterintuitive that a reviewer might insist on adding an inline comment to indicate that a particular combination of arguments is not a typo, but an intended case of _unsigned bytes_, for example:

https://github.com/openjdk/jdk/blob/2bdfa836adbeba3319bee4ee61017907d6d84d58/src/java.base/unix/classes/sun/nio/fs/UnixPath.java#L801-L811

Could we hide that `int basicType` behind overloads that have static safety better than `Object array` and are appropriately named? For example:

    public static int hashCode(byte[] array, int fromIndex, int length, int initialValue);
    public static int unsignedHashCode(byte[] array, int fromIndex, int length, int initialValue);

Related, I assume this is a typo

    jdk.internal.util.ArraysSupport#signedHashCode

and it should've been

    jdk.internal.util.ArraysSupport#unsignedHashCode
                                    ^^^
?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1655477396

From prappo at openjdk.org  Fri Jul 28 10:52:52 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 28 Jul 2023 10:52:52 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
Message-ID: <ogq2xwuFL0hIb2tMw2w84PF8p7RYuuiaRCuRZlgL7L4=.b6baa56f-e685-4f83-af8a-b190a2221706@github.com>

On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR adds an internal method to calculate hash code from the provided integer array, offset and length into that array, and the initial hash code value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's either ArraysSupport.vectorizedHashCode with an offset, length and initial value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling. Unfortunately, it's the only hash code method that operates on an array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, behaviour which was specified but untested.

Perhaps surprisingly, we don't need int[]; what JDK seems to use is these:

 * byte[]
 * unsigned byte[]
 * Object[]

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1655481239

From clanger at openjdk.org  Fri Jul 28 11:19:53 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 28 Jul 2023 11:19:53 GMT
Subject: [jdk21] RFR: 8313260: JDK21: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java on linux-x86
In-Reply-To: <mimxRr66BIrTDBuBqE9hZmX9aswPT0mSQaaQP9PgFa8=.6535385c-1056-40fe-88ce-8fe237a98303@github.com>
References: <aAe2EfwCbhBufeuKFbNp1N9bwoUolT04vzI1ujZgIt0=.e3fdc7e0-feb2-480d-a0cd-52f8cfef1856@github.com>
 <mimxRr66BIrTDBuBqE9hZmX9aswPT0mSQaaQP9PgFa8=.6535385c-1056-40fe-88ce-8fe237a98303@github.com>
Message-ID: <ZABMjTMJ7SRWohYos8wJ5XL0igM-pJg0xdD7FWX5V_M=.54c680f3-2f2d-49ff-af53-680a9a177b7a@github.com>

On Fri, 28 Jul 2023 09:10:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> JDK-8308609

I added a comment on https://bugs.openjdk.org/browse/JDK-8303498, cc @offamitkumar

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/149#issuecomment-1655513822

From asotona at openjdk.org  Fri Jul 28 12:01:05 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 28 Jul 2023 12:01:05 GMT
Subject: RFR: 8312491: Update Classfile API snippets and examples [v5]
In-Reply-To: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
References: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
Message-ID: <NTbdT_OEebXCL-WodxM7L_OIY_ORFMh84IuOWbfUepc=.924903dc-80a0-46b4-b2e0-c28c78d46deb@github.com>

> 8312491: Update Classfile API snippets and examples

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - fixing javadoc
 - fixing javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14968/files
  - new: https://git.openjdk.org/jdk/pull/14968/files/8071164a..30d0507a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=03-04

  Stats: 1326 lines in 3 files changed: 1316 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/14968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14968/head:pull/14968

PR: https://git.openjdk.org/jdk/pull/14968

From duke at openjdk.org  Fri Jul 28 12:15:21 2023
From: duke at openjdk.org (Cristian Vat)
Date: Fri, 28 Jul 2023 12:15:21 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v4]
In-Reply-To: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
Message-ID: <-4FNO-SDSVY6y13UHp8ws0rMPmfU7I4U_lGwUSZ_Qs0=.bef74326-cd0a-4f2c-a41a-6fa84b1dc0fb@github.com>

> Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.
> 
> Original clamping to 10 possibly due to documented behavior from javadoc: 
> "In this class, \1 through \9 are always interpreted as back references, "
> 
> Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
> Added a match failure condition in Pattern that fixes failing tests.
> 
> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"
> 
> A group that does not exist in the original Pattern can never match so neither can a backref to that group.
> If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
> So a group index outside groups array length must never match.

Cristian Vat has updated the pull request incrementally with one additional commit since the last revision:

  changes and test for CIBackRef

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14894/files
  - new: https://git.openjdk.org/jdk/pull/14894/files/4c6c3ec0..b591b2ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14894&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14894&range=02-03

  Stats: 58 lines in 2 files changed: 58 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14894/head:pull/14894

PR: https://git.openjdk.org/jdk/pull/14894

From duke at openjdk.org  Fri Jul 28 12:15:21 2023
From: duke at openjdk.org (Cristian Vat)
Date: Fri, 28 Jul 2023 12:15:21 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v2]
In-Reply-To: <EQXyOHqtSlA0c7UIhuAuwy5yHWYbOHLmPPVgDp7a9Ns=.50771041-f734-4674-9b55-6df4ea582f9b@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
 <PsTu5E6ACWA3qBtfWidauo_1uCFAQ7S7xZPjeVMxTwU=.0e76e9ae-2ea7-4b5d-820d-a6b5d1eb46f1@github.com>
 <EQXyOHqtSlA0c7UIhuAuwy5yHWYbOHLmPPVgDp7a9Ns=.50771041-f734-4674-9b55-6df4ea582f9b@github.com>
Message-ID: <3HHBKD9eBRKyAU0frsZwY62nFj5bF6Lsey-dZ_ZrDzk=.1044d4ba-6463-49ed-961d-5ab3b2cad499@github.com>

On Fri, 28 Jul 2023 08:25:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Cristian Vat has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reduce allocations also for Matcher.usePattern
>
> src/java.base/share/classes/java/util/regex/Pattern.java line 5190:
> 
>> 5188:         }
>> 5189:         boolean match(Matcher matcher, int i, CharSequence seq) {
>> 5190: 
> 
> Excess new line.

line removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14894#discussion_r1277471042

From duke at openjdk.org  Fri Jul 28 12:18:43 2023
From: duke at openjdk.org (Cristian Vat)
Date: Fri, 28 Jul 2023 12:18:43 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v4]
In-Reply-To: <-4FNO-SDSVY6y13UHp8ws0rMPmfU7I4U_lGwUSZ_Qs0=.bef74326-cd0a-4f2c-a41a-6fa84b1dc0fb@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
 <-4FNO-SDSVY6y13UHp8ws0rMPmfU7I4U_lGwUSZ_Qs0=.bef74326-cd0a-4f2c-a41a-6fa84b1dc0fb@github.com>
Message-ID: <C_faJfEHTCEMH0P0S4dt8skXz--9YYcieDzF5KXksMQ=.59944fca-f76e-4bc9-bb8d-074781fe63cc@github.com>

On Fri, 28 Jul 2023 12:15:21 GMT, Cristian Vat <duke at openjdk.org> wrote:

>> Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.
>> 
>> Original clamping to 10 possibly due to documented behavior from javadoc: 
>> "In this class, \1 through \9 are always interpreted as back references, "
>> 
>> Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
>> Added a match failure condition in Pattern that fixes failing tests.
>> 
>> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"
>> 
>> A group that does not exist in the original Pattern can never match so neither can a backref to that group.
>> If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
>> So a group index outside groups array length must never match.
>
> Cristian Vat has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes and test for CIBackRef

Made changes also in `CIBackRef` and copied/changed test into new `ciBackRefTest`

Not pretty since changes to one could miss the other, but all patterns are different. (for what it's worth tests pass...)

There's also a special case with supplementary character tests since `toSupplementaries` given `(?i)` generates invalid pattern, so I had to change those like:
``
pattern = Pattern.compile("(?i)" + toSupplementaries("(a*)bc\\1"));
``

Definitely needs a close look by a regex expert.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14894#issuecomment-1655581689

From redestad at openjdk.org  Fri Jul 28 12:34:53 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 28 Jul 2023 12:34:53 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
Message-ID: <LOvdAvaF4xtyA8FlEkpm7WAqCFva5COY8hbn_-HqAvQ=.bced8964-ded6-45cc-9e5f-d814a1ed2f3b@github.com>

On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR adds an internal method to calculate hash code from the provided integer array, offset and length into that array, and the initial hash code value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's either ArraysSupport.vectorizedHashCode with an offset, length and initial value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling. Unfortunately, it's the only hash code method that operates on an array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, behaviour which was specified but untested.

Yes, it should have been `unsignedHashCode`. 

Adding a layer of `ArraysSupport.hashCode` methods with no `basicType` parameter exposed, which in turn calls a renamed `vectorizedHashCode` (`@IntrinsicCandidate private static int internalHashCode`?) seem like a reasonable cleanup on the face of it. Assuming we can retain performance characteristics. One complication is that we'd also need to expose a `utf16HashCode` that takes a `byte[]` and interprets it as holding `char` values.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1655612832

From aph at openjdk.org  Fri Jul 28 12:38:56 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 28 Jul 2023 12:38:56 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v6]
In-Reply-To: <CRkpBSFzMIMI4km33WN9nLGSp7JuMM5s-2GdotfdeV8=.c6b252f1-74c5-4747-b528-26f787152fe2@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <CRkpBSFzMIMI4km33WN9nLGSp7JuMM5s-2GdotfdeV8=.c6b252f1-74c5-4747-b528-26f787152fe2@github.com>
Message-ID: <OpX_4s42FiOutGsH9buHA6jR0tuGHejkIhJar8qZmaI=.9676fdc6-0b71-44b9-a82e-96750c1525d9@github.com>

On Fri, 28 Jul 2023 03:59:26 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Preserve and restore register Z_R6
>   
>   Though Z_R6 is argument register it is a saved register
>   so preserve and restore Z_R6 register

src/hotspot/cpu/s390/upcallLinker_s390.cpp line 72:

> 70:     // Z_SP saved/restored by prologue/epilogue
> 71:     if (reg == Z_SP) continue;
> 72:     // though Z_R6 is argument register it is a saved register

Suggestion:
`    // although Z_R6 is used for parameter passing, it must be saved and restored by a called function.`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1277496026

From redestad at openjdk.org  Fri Jul 28 12:39:41 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 28 Jul 2023 12:39:41 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <ogq2xwuFL0hIb2tMw2w84PF8p7RYuuiaRCuRZlgL7L4=.b6baa56f-e685-4f83-af8a-b190a2221706@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
 <ogq2xwuFL0hIb2tMw2w84PF8p7RYuuiaRCuRZlgL7L4=.b6baa56f-e685-4f83-af8a-b190a2221706@github.com>
Message-ID: <W-zn8Rc6JLkSi8dwxir_slUMCLqhVnNUJdgQ6lNIb3g=.c0d13fe3-8de4-4713-9767-9cdd02c879dd@github.com>

On Fri, 28 Jul 2023 10:49:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Perhaps surprisingly, we don't need int[]; what JDK seems to use is these:
> 
> * byte[]
> * unsigned byte[]
> * Object[]

All `vectorizedHashCode` variants are exposed (and testable) via the public `java.util.Arrays.hashCode(byte/char/short/int[])` methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1655620421

From prappo at openjdk.org  Fri Jul 28 12:59:51 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 28 Jul 2023 12:59:51 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <W-zn8Rc6JLkSi8dwxir_slUMCLqhVnNUJdgQ6lNIb3g=.c0d13fe3-8de4-4713-9767-9cdd02c879dd@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
 <ogq2xwuFL0hIb2tMw2w84PF8p7RYuuiaRCuRZlgL7L4=.b6baa56f-e685-4f83-af8a-b190a2221706@github.com>
 <W-zn8Rc6JLkSi8dwxir_slUMCLqhVnNUJdgQ6lNIb3g=.c0d13fe3-8de4-4713-9767-9cdd02c879dd@github.com>
Message-ID: <Zy4NYQVrDePegz_yBYTHAl7ozdnlvrPyaoQ6JeETycc=.f06cc2a7-055d-4020-9a9f-ada69420138e@github.com>

On Fri, 28 Jul 2023 12:37:13 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > Perhaps surprisingly, we don't need int[]; what JDK seems to use is these:
> > 
> > * byte[]
> > * unsigned byte[]
> > * Object[]
> 
> All `vectorizedHashCode` variants are exposed (and testable) via the public `java.util.Arrays.hashCode(byte/char/short/int[])` methods.

There seems to be misunderstanding. Here's the intent of my earlier comment: it's only those three variants above that I found to be used in JDK where a subrange or, to a lesser extent, a different initial value is desired. This is ironic since this PR is titled as "Add ArraysSupport.hashCode(**int**[] a, fromIndex, length, initialValue)". I guess it's because I filed the PR before I gathered enough stats.

One lighter-weight alternative to providing more mid-layer methods would be to rename `basicType` constants to be more self-descriptive. Thoughts?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1655640886

From amitkumar at openjdk.org  Fri Jul 28 13:09:12 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 28 Jul 2023 13:09:12 GMT
Subject: RFR: 8313312: Add missing classpath exception copyright header
Message-ID: <9ZKXDEMzNF_XPzgzsXYskRSuM4pLj1zBVQUU8YONVqE=.e14017a2-cd82-4abd-8b72-d096a3fce69f@github.com>

Adds `classpath exception` in multiple files, affects copyright header only.

-------------

Commit messages:
 - adds classpath exception

Changes: https://git.openjdk.org/jdk/pull/15070/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15070&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313312
  Stats: 60 lines in 20 files changed: 40 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/15070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15070/head:pull/15070

PR: https://git.openjdk.org/jdk/pull/15070

From prappo at openjdk.org  Fri Jul 28 13:17:50 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 28 Jul 2023 13:17:50 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
Message-ID: <S9ESx4qVrwKzlrNfu2SGnaN-0pTBtxqRWFByGqWa0DI=.b97585d2-d317-44bf-81ee-91682b8f8bd9@github.com>

On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR adds an internal method to calculate hash code from the provided integer array, offset and length into that array, and the initial hash code value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's either ArraysSupport.vectorizedHashCode with an offset, length and initial value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling. Unfortunately, it's the only hash code method that operates on an array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, behaviour which was specified but untested.

Even with better named constants the Object type is missing. Something needs to be done about it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1655666546

From mcimadamore at openjdk.org  Fri Jul 28 13:42:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Jul 2023 13:42:53 GMT
Subject: RFR: 8313312: Add missing classpath exception copyright header
In-Reply-To: <9ZKXDEMzNF_XPzgzsXYskRSuM4pLj1zBVQUU8YONVqE=.e14017a2-cd82-4abd-8b72-d096a3fce69f@github.com>
References: <9ZKXDEMzNF_XPzgzsXYskRSuM4pLj1zBVQUU8YONVqE=.e14017a2-cd82-4abd-8b72-d096a3fce69f@github.com>
Message-ID: <D9xwTe1qp5_4-b16JgFldixDIhExdwLCBbrKbGWxFqk=.2497112c-f98e-4754-bd59-b28fcb8c89c9@github.com>

On Fri, 28 Jul 2023 13:02:20 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Adds `classpath exception` in multiple files, affects copyright header only.

Please leave the java.lang.foreign changes out of this. We already have another PR for those:
https://github.com/openjdk/jdk/pull/15042

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15070#issuecomment-1655699357

From serb at openjdk.org  Fri Jul 28 15:56:02 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 28 Jul 2023 15:56:02 GMT
Subject: [jdk21] Integrated: 8313260: JDK21: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java on linux-x86
In-Reply-To: <aAe2EfwCbhBufeuKFbNp1N9bwoUolT04vzI1ujZgIt0=.e3fdc7e0-feb2-480d-a0cd-52f8cfef1856@github.com>
References: <aAe2EfwCbhBufeuKFbNp1N9bwoUolT04vzI1ujZgIt0=.e3fdc7e0-feb2-480d-a0cd-52f8cfef1856@github.com>
Message-ID: <2GQ49U6cMhk_r6RGNKCVBNKbcMN17b4EnW1TqBLArr4=.5baeecb5-4b56-46fd-a61e-30904d849afb@github.com>

On Thu, 27 Jul 2023 18:21:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds the  java/lang/ScopedValue/StressStackOverflow.java to the problem list for linux-x86 where it intermittently fails on a GA, ex: https://github.com/openjdk/jdk21/pull/148
> 
> This is only for JDK 21, test passes on JDK 22.

This pull request has now been integrated.

Changeset: bb63b791
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/bb63b79112852af3020fe64bac1974d26272b442
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8313260: JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on linux-x86

Reviewed-by: clanger

-------------

PR: https://git.openjdk.org/jdk21/pull/149

From jlu at openjdk.org  Fri Jul 28 16:30:01 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 28 Jul 2023 16:30:01 GMT
Subject: Integrated: 8312416: Tests in Locale should have more descriptive
 names
In-Reply-To: <PrykfUm6DeNNoi2uQ9YR74Ae5Y0Fcn7S1-45ola7Qeo=.d158464f-ed6c-4cec-bcdd-2c998bc0934d@github.com>
References: <PrykfUm6DeNNoi2uQ9YR74Ae5Y0Fcn7S1-45ola7Qeo=.d158464f-ed6c-4cec-bcdd-2c998bc0934d@github.com>
Message-ID: <SvVGCvpozhKA3NBVo2W0CYMRSeAmneCopO8pnQ2Ba5I=.43a8c303-e3a9-413c-8bfa-004d40432383@github.com>

On Wed, 26 Jul 2023 07:11:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this change which renames tests for Locale from `bugNNNNNNN.java` to something more descriptive.
> 
> In addition to the name changes, accompanying copyright year, name usage within the test, and other minor changes were included. The test `bug4123285.java` was also removed, as it was never actually ran and java.applet.Applet is deprecated and marked for removal.

This pull request has now been integrated.

Changeset: a9a3463a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a9a3463afb33b9df4cbf64d1866255bff638824f
Stats:     265 lines in 16 files changed: 93 ins; 138 del; 34 mod

8312416: Tests in Locale should have more descriptive names

Reviewed-by: lancea, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/15032

From jlu at openjdk.org  Fri Jul 28 16:47:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 28 Jul 2023 16:47:43 GMT
Subject: RFR: 8313307: java/util/Formatter/Padding.java fails on some
 Locales
In-Reply-To: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
References: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
Message-ID: <FBzz30yUkDXmLzvheZkPF9EEW_kwWFyucP1ygAAOS3M=.44e4e387-f0d1-4c39-8df8-7ef171ac1aa6@github.com>

On Fri, 28 Jul 2023 08:49:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> $ CONF=macosx-aarch64-server-fastdebug make images test TEST=java/util/Formatter/Padding.java
> 
> ...
> STARTED Padding::padding '[216] -0000001.2, % 010.1f, -1.2'
> org.opentest4j.AssertionFailedError: expected: <-0000001.2> but was: <-0000001,2>
> 
> 
> Looks like a locale problem in test, so the simplest fix is to ask for a neutral Locale there.

LGTM

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15066#pullrequestreview-1552500764

From naoto at openjdk.org  Fri Jul 28 16:59:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 28 Jul 2023 16:59:41 GMT
Subject: RFR: 8313307: java/util/Formatter/Padding.java fails on some
 Locales
In-Reply-To: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
References: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
Message-ID: <z8Z6tshLWFUpyMQnXUuZuadiJOdDwStWuaEeUn5k0UA=.8cbca214-08a0-47b6-8ad7-0681f75bae39@github.com>

On Fri, 28 Jul 2023 08:49:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> $ CONF=macosx-aarch64-server-fastdebug make images test TEST=java/util/Formatter/Padding.java
> 
> ...
> STARTED Padding::padding '[216] -0000001.2, % 010.1f, -1.2'
> org.opentest4j.AssertionFailedError: expected: <-0000001.2> but was: <-0000001,2>
> 
> 
> Looks like a locale problem in test, so the simplest fix is to ask for a neutral Locale there.

test/jdk/java/util/Formatter/Padding.java line 312:

> 310:     @MethodSource
> 311:     void padding(String expected, String format, Object value) {
> 312:         assertEquals(expected, String.format(Locale.ROOT, format, value));

I suggest using `Locale.US` instead of `Locale.ROOT`. Although it works, `Locale.ROOT` is an invariant locale where theoretically you cannot assume the decimal point is a period. Using `Locale.US` assures that assumption, and also aligns with other similar test cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15066#discussion_r1277788433

From shade at openjdk.org  Fri Jul 28 17:13:54 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Jul 2023 17:13:54 GMT
Subject: RFR: 8313307: java/util/Formatter/Padding.java fails on some
 Locales [v2]
In-Reply-To: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
References: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
Message-ID: <n6-76f0BzHFEKRERy68N-jTy_zEoArwe6jeczkYCHhs=.89bb7415-fd8c-494d-8749-584e4eb19129@github.com>

> Fails like this:
> 
> 
> $ CONF=macosx-aarch64-server-fastdebug make images test TEST=java/util/Formatter/Padding.java
> 
> ...
> STARTED Padding::padding '[216] -0000001.2, % 010.1f, -1.2'
> org.opentest4j.AssertionFailedError: expected: <-0000001.2> but was: <-0000001,2>
> 
> 
> Looks like a locale problem in test, so the simplest fix is to ask for a neutral Locale there.

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Change to Locale.US

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15066/files
  - new: https://git.openjdk.org/jdk/pull/15066/files/97084428..eaca173c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15066&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15066&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15066/head:pull/15066

PR: https://git.openjdk.org/jdk/pull/15066

From shade at openjdk.org  Fri Jul 28 17:13:55 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Jul 2023 17:13:55 GMT
Subject: RFR: 8313307: java/util/Formatter/Padding.java fails on some
 Locales [v2]
In-Reply-To: <z8Z6tshLWFUpyMQnXUuZuadiJOdDwStWuaEeUn5k0UA=.8cbca214-08a0-47b6-8ad7-0681f75bae39@github.com>
References: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
 <z8Z6tshLWFUpyMQnXUuZuadiJOdDwStWuaEeUn5k0UA=.8cbca214-08a0-47b6-8ad7-0681f75bae39@github.com>
Message-ID: <oSqdWC9_f88kE4RcNfwyTHyk7Z4uYSbi32G0JocnJGA=.57960543-a960-438b-bab1-83f08c471c9e@github.com>

On Fri, 28 Jul 2023 16:53:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change to Locale.US
>
> test/jdk/java/util/Formatter/Padding.java line 312:
> 
>> 310:     @MethodSource
>> 311:     void padding(String expected, String format, Object value) {
>> 312:         assertEquals(expected, String.format(Locale.ROOT, format, value));
> 
> I suggest using `Locale.US` instead of `Locale.ROOT`. Although it works, `Locale.ROOT` is an invariant locale where theoretically you cannot assume the decimal point is a period. Using `Locale.US` assures that assumption, and also aligns with other similar test cases.

Sure, changed to `Locale.US` in new commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15066#discussion_r1277801468

From naoto at openjdk.org  Fri Jul 28 17:19:42 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 28 Jul 2023 17:19:42 GMT
Subject: RFR: 8313307: java/util/Formatter/Padding.java fails on some
 Locales [v2]
In-Reply-To: <n6-76f0BzHFEKRERy68N-jTy_zEoArwe6jeczkYCHhs=.89bb7415-fd8c-494d-8749-584e4eb19129@github.com>
References: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
 <n6-76f0BzHFEKRERy68N-jTy_zEoArwe6jeczkYCHhs=.89bb7415-fd8c-494d-8749-584e4eb19129@github.com>
Message-ID: <T1qDVaP6XmU0-CX4eJeFqK6EGEyqvoHMKBZzkq09qFY=.97ed1876-3e38-4b59-aeec-5a840e1cc274@github.com>

On Fri, 28 Jul 2023 17:13:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Fails like this:
>> 
>> 
>> $ CONF=macosx-aarch64-server-fastdebug make images test TEST=java/util/Formatter/Padding.java
>> 
>> ...
>> STARTED Padding::padding '[216] -0000001.2, % 010.1f, -1.2'
>> org.opentest4j.AssertionFailedError: expected: <-0000001.2> but was: <-0000001,2>
>> 
>> 
>> Looks like a locale problem in test, so the simplest fix is to ask for a neutral Locale there.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change to Locale.US

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15066#pullrequestreview-1552546716

From asotona at openjdk.org  Fri Jul 28 17:21:45 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 28 Jul 2023 17:21:45 GMT
Subject: RFR: 8312491: Update Classfile API snippets and examples [v6]
In-Reply-To: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
References: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
Message-ID: <JQ7oPHDLft2PtS3ux392bAjejVehcxi0ZQmrJxz_mFo=.9abc37b1-2008-4413-a219-7b1186a0fb4b@github.com>

> This pull request updates Classfile API snippets and examples and adds missing javadoc.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - fixing javadoc
 - fixing javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14968/files
  - new: https://git.openjdk.org/jdk/pull/14968/files/30d0507a..a2b4e858

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=04-05

  Stats: 1464 lines in 3 files changed: 1385 ins; 0 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/14968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14968/head:pull/14968

PR: https://git.openjdk.org/jdk/pull/14968

From asotona at openjdk.org  Fri Jul 28 17:21:46 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 28 Jul 2023 17:21:46 GMT
Subject: RFR: 8312491: Update Classfile API snippets and examples [v6]
In-Reply-To: <pfPJrvOo1qLD_ixLjMBHSNgLmAYOk_GmRLjdeQk8Nlg=.1f75b896-a16d-4f38-b464-1f1de25525a0@github.com>
References: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
 <Ttl1J3FLIh4BoYUbpVUUxkjRoU5isQFVMfIAhrK3MKI=.eecd68ae-4b04-465e-afc1-d2d33d39da83@github.com>
 <pfPJrvOo1qLD_ixLjMBHSNgLmAYOk_GmRLjdeQk8Nlg=.1f75b896-a16d-4f38-b464-1f1de25525a0@github.com>
Message-ID: <japOIwNHKmPyQJoGPELKWhwHHv0bjaJmUu3RvEkXg5o=.12dc26b3-fe76-42fb-b65e-b5a2644b3d6c@github.com>

On Thu, 27 Jul 2023 15:16:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 1239:
>> 
>>> 1237:         return ldc(BytecodeHelpers.constantEntry(constantPool(), value));
>>> 1238:     }
>>> 1239: 
>> 
>> Method needs specification
>
> Right, we need to add a lot of missing javadoc.

I did first round of filling missing javadoc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14968#discussion_r1277807478

From jlu at openjdk.org  Fri Jul 28 17:37:01 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 28 Jul 2023 17:37:01 GMT
Subject: Integrated: 8312411: MessageFormat.formatToCharacterIterator() can be
 improved
In-Reply-To: <SvBOR63sGUuLf0dWrmAV9vbyHNN2mf3wZIefKffPGl0=.05694f16-665d-407c-87b8-6b19041cf2d3@github.com>
References: <SvBOR63sGUuLf0dWrmAV9vbyHNN2mf3wZIefKffPGl0=.05694f16-665d-407c-87b8-6b19041cf2d3@github.com>
Message-ID: <SpjLu1vVOIPkbXXaSWkcgDmz_P6rvgPtxVfN71_NIjU=.79bdce13-87ab-4386-8b5a-601a69e8ff1a@github.com>

On Wed, 26 Jul 2023 07:39:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this change which makes `MessageFormat.formatToCharacterIterator` fail fast(er). The return statement is also modified to call  toArray() as `toArray(new T[0])` over `toArray(new T[size])`.

This pull request has now been integrated.

Changeset: 23755f90
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23755f90c9fb69b0ddad0cdfcdf8add309b1d845
Stats:     7 lines in 1 file changed: 1 ins; 5 del; 1 mod

8312411: MessageFormat.formatToCharacterIterator() can be improved

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/15035

From amitkumar at openjdk.org  Fri Jul 28 17:39:18 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 28 Jul 2023 17:39:18 GMT
Subject: RFR: 8313312: Add missing classpath exception copyright header
 [v2]
In-Reply-To: <9ZKXDEMzNF_XPzgzsXYskRSuM4pLj1zBVQUU8YONVqE=.e14017a2-cd82-4abd-8b72-d096a3fce69f@github.com>
References: <9ZKXDEMzNF_XPzgzsXYskRSuM4pLj1zBVQUU8YONVqE=.e14017a2-cd82-4abd-8b72-d096a3fce69f@github.com>
Message-ID: <cwVvcKK4X92FDntRJg9Iv3NuPvUAaybTDLrp6G1L6To=.0f1c62ab-b8cc-4df2-8157-4445fb1aa49c@github.com>

> Adds `classpath exception` in multiple files, affects copyright header only.

Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:

  revert java.lang.foreign changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15070/files
  - new: https://git.openjdk.org/jdk/pull/15070/files/d8d7cdf3..3958d9fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15070&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15070&range=00-01

  Stats: 12 lines in 4 files changed: 0 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15070/head:pull/15070

PR: https://git.openjdk.org/jdk/pull/15070

From amitkumar at openjdk.org  Fri Jul 28 17:45:52 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 28 Jul 2023 17:45:52 GMT
Subject: RFR: 8310643: Misformatted copyright messages in FFM
In-Reply-To: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>
References: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>
Message-ID: <Pih4eT303RY9NNNS340SQpoXkg0ST8rbJ-qx0k7bHpQ=.3124626a-79f3-4f9a-af15-11244aa790b4@github.com>

On Wed, 26 Jul 2023 15:43:12 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests updating some of the ill-formed copyright headers in the FFM API and the implementation and test thereof.
> 
> Some of the test files will have now the "classpath" exception. Is this correct?

Hi @minborg, 

Would you add below patch in this PR. This will add "classpath" exception copyright header for some files in java/lang/foreign dir. 

I have reverted the changes from my [PR](https://github.com/openjdk/jdk/pull/15070/commits/3958d9fe3a5fca3edebdf68ea7e082dd4768ce2f) as @mcimadamore  suggested. 

[java_lang_foreign_CP_exception.patch](https://github.com/openjdk/jdk/files/12196879/java_lang_foreign_CP_exception.patch)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15042#issuecomment-1656095047

From Alan.Bateman at oracle.com  Fri Jul 28 19:18:50 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 28 Jul 2023 20:18:50 +0100
Subject: CFV: New Core Libraries Group Member: Brian Burkhalter
In-Reply-To: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
References: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
Message-ID: <25ebfccb-ac12-34d0-e656-c6e1337a4a55@oracle.com>

Vote: yes

From Alan.Bateman at oracle.com  Fri Jul 28 19:19:02 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 28 Jul 2023 20:19:02 +0100
Subject: CFV: New Core Libraries Group Member: Brent Christian
In-Reply-To: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
References: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
Message-ID: <1937c852-fc6e-aa2f-604a-1636cec40399@oracle.com>

Vote: yes

From Alan.Bateman at oracle.com  Fri Jul 28 19:19:19 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 28 Jul 2023 20:19:19 +0100
Subject: CFV: New Core Libraries Group Member: Joe Wang
In-Reply-To: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
References: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
Message-ID: <cac9d92d-a4b1-1f73-4267-153f8d3e2430@oracle.com>

Vote: yes

From chegar999 at gmail.com  Fri Jul 28 19:32:21 2023
From: chegar999 at gmail.com (Chris Hegarty)
Date: Fri, 28 Jul 2023 20:32:21 +0100
Subject: CFV: New Core Libraries Group Member: Brian Burkhalter
In-Reply-To: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
References: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
Message-ID: <0a400f05-0c62-084b-06ca-6853554926fd@gmail.com>

Vote: Yes.

-Chris

On 27/07/2023 19:35, Roger Riggs wrote:
> |I hereby nominate |Brian Burkhalter|to Membership in the Core Libraries Group Brian has been working in 
> the Core Library team since 2012. Brian's many contributions to the 
> OpenJDK libraries include java.io subsystems, NIO channels, files, and 
> buffers. He applies his background in math and image processing to 
> OpenJDK development. ||Previously, he led JavaFX Media team. Co-designed and implemented 
> successor Java audio and video playback and recording API using 
> GStreamer, AV Foundation, and libav. Votes are due by August 11th, 
> 2023. Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list For 
> Lazy Consensus voting instructions, see [2]. Roger Riggs [1] 
> https://openjdk.org/census#core-libs [2] 
> https://openjdk.org/groups/#member-vote|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230728/4fe1eb6d/attachment.htm>

From chegar999 at gmail.com  Fri Jul 28 19:32:30 2023
From: chegar999 at gmail.com (Chris Hegarty)
Date: Fri, 28 Jul 2023 20:32:30 +0100
Subject: CFV: New Core Libraries Group Member: Brent Christian
In-Reply-To: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
References: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
Message-ID: <0c2dc760-ad55-2bc5-5e30-77f122071af8@gmail.com>

Vote: Yes.

-Chris

On 27/07/2023 19:36, Roger Riggs wrote:
> |I hereby nominate |Brent Christian|to Membership in the Core Libraries Group Brent has been working in 
> the Core Library team at Oracle since 2012. He has made contributions 
> to many areas of OpenJDK including java.lang strings, class loader, 
> NIO Jar, and many more. Most recently he has been working on steps to 
> deprecate and phase out finalization.|
> ||Previously he worked on OpenJDK AWT, Swing, and JavaFX before 
> joining the Core Libraries group.| Votes are due by August 11th, 2023. 
> Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list For 
> Lazy Consensus voting instructions, see [2]. Roger Riggs [1] 
> https://openjdk.org/census#core-libs [2] 
> https://openjdk.org/groups/#member-vote|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230728/95e16bf9/attachment.htm>

From chegar999 at gmail.com  Fri Jul 28 19:32:50 2023
From: chegar999 at gmail.com (Chris Hegarty)
Date: Fri, 28 Jul 2023 20:32:50 +0100
Subject: CFV: New Core Libraries Group Member: Joe Wang
In-Reply-To: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
References: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
Message-ID: <21f9c9be-bf85-38e8-c023-84090657fb48@gmail.com>

Vote: Yes.

-Chris

On 27/07/2023 19:36, Roger Riggs wrote:
> |I hereby nominate Joe Wang||to Membership in the Core Libraries Group Joe has been working in the 
> core library team since 2012. He has been maintaining and improving 
> the XML library APIs and implementations including ||DOM, SAX, StAX, Transform, Validation, XPath and Catalog. Recently he 
> has been updating and improving XML Security. Votes are due by August 
> 11th, 2023. Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list For 
> Lazy Consensus voting instructions, see [2]. Roger Riggs [1] 
> https://openjdk.org/census#core-libs [2] 
> https://openjdk.org/groups/#member-vote|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230728/ad306e1b/attachment-0001.htm>

From lance.andersen at oracle.com  Fri Jul 28 19:39:40 2023
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 28 Jul 2023 19:39:40 +0000
Subject: CFV: New Core Libraries Group Member: Brian Burkhalter
In-Reply-To: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
References: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
Message-ID: <77B2FA42-6085-49D2-88DC-F77008DD1D9C@oracle.com>

Vote: Yes.


On 27/07/2023 19:35, Roger Riggs wrote:

I hereby nominate Brian Burkhalter to Membership in the Core Libraries Group

Brian has been working in the Core Library team since 2012.
Brian's many contributions to the OpenJDK libraries include java.io<http://java.io> subsystems,
NIO channels, files, and buffers. He applies his background in math and image
processing to OpenJDK development.

Previously, he led JavaFX Media team. Co-designed and implemented successor
Java audio and video playback and recording API using GStreamer, AV Foundation,
and libav.

Votes are due by August 11th, 2023.

Only current Members of the Core Libraries Group [1] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs
[2] https://openjdk.org/groups/#member-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230728/f79fb541/attachment.htm>

From lance.andersen at oracle.com  Fri Jul 28 19:39:57 2023
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 28 Jul 2023 19:39:57 +0000
Subject: CFV: New Core Libraries Group Member: Brent Christian
In-Reply-To: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
References: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
Message-ID: <F3EDC231-C5FA-42E0-A107-C4E6CE59A78D@oracle.com>

Vote: Yes.

On 27/07/2023 19:36, Roger Riggs wrote:

I hereby nominate Brent Christian to Membership in the Core Libraries Group

Brent has been working in the Core Library team at Oracle since 2012.
He has made contributions to many areas of OpenJDK including java.lang strings,
class loader, NIO Jar, and many more.  Most recently he has been working on
steps to deprecate and phase out finalization.

Previously he worked on OpenJDK AWT, Swing, and JavaFX before joining
the Core Libraries group.


Votes are due by August 11th, 2023.

Only current Members of the Core Libraries Group [1] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs
[2] https://openjdk.org/groups/#member-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230728/b95f97ae/attachment.htm>

From lance.andersen at oracle.com  Fri Jul 28 19:40:12 2023
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 28 Jul 2023 19:40:12 +0000
Subject: CFV: New Core Libraries Group Member: Joe Wang
In-Reply-To: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
References: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
Message-ID: <6F414B9F-3987-4CBF-883B-021251ED2305@oracle.com>

Vote: Yes.


On 27/07/2023 19:36, Roger Riggs wrote:

I hereby nominate Joe Wang to Membership in the Core Libraries Group

Joe has been working in the core library team since 2012.
He has been maintaining and improving the XML library APIs and implementations
including DOM, SAX, StAX, Transform, Validation, XPath and Catalog.
Recently he has been updating and improving XML Security.

Votes are due by August 11th, 2023.

Only current Members of the Core Libraries Group [1] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs
[2] https://openjdk.org/groups/#member-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230728/7175cd6d/attachment-0001.htm>

From bpb at openjdk.org  Fri Jul 28 19:59:15 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 28 Jul 2023 19:59:15 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v3]
In-Reply-To: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
Message-ID: <c3ma_hgY3P7iCJwEVzVvrFKXBykVZnZQwnuKMva_LCY=.dd5cbce8-b761-4de8-a49e-ccf42874f22e@github.com>

> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  6478546: Move buffer clamping up to Java layer; correct read behavior to match legacy

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14981/files
  - new: https://git.openjdk.org/jdk/pull/14981/files/69941de4..92649751

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14981&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14981&range=01-02

  Stats: 102 lines in 4 files changed: 48 ins; 20 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/14981.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14981/head:pull/14981

PR: https://git.openjdk.org/jdk/pull/14981

From bpb at openjdk.org  Fri Jul 28 19:59:34 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 28 Jul 2023 19:59:34 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <8i_NF3xA4t8bZnYAJAHVoqNnZGipNqHyvWJJNzY2yC0=.99bd097d-30de-418a-85d0-f212b8b2e842@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <2Tev3UK-0UjhG8UZE0_bCj1wYf1eHKxGSRdYYZTmWN4=.e5979796-1956-4b46-b2a3-1da85ea862f7@github.com>
 <8i_NF3xA4t8bZnYAJAHVoqNnZGipNqHyvWJJNzY2yC0=.99bd097d-30de-418a-85d0-f212b8b2e842@github.com>
Message-ID: <QXMqNfAHfAHjgnz2uyydOKKo1J4ZUqH-w0yrPY136HI=.e64b31de-df9f-4fe5-9d2b-8f641f1f5555@github.com>

On Wed, 26 Jul 2023 09:29:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think this is close to what you want

Modified as suggested in 9264975. The limit is increased to 1.5 Mb where it was in native malloc clamping. This appears to prevent any throughput degradation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14981#issuecomment-1656245009

From joehw at openjdk.org  Fri Jul 28 20:26:37 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 28 Jul 2023 20:26:37 GMT
Subject: RFR: 8306632: Add a JDK Property for specifying DTD support
Message-ID: <XwN4WgnkT6xLC_KlP9HczT_skmiHqDu06hY_jKut-mQ=.d2f0dbe6-2a76-4640-a5c8-c2d3ef0a6803@github.com>

Add a JDK Impl specific property 'jdk.xml.dtd.support' for applications to specify how DTDs are handled. This property is uniformly supported across the JDK XML libraries. It complements, rather than replaces, the existing properties that are supportDTD for StAX and disallow-doctype-decl for DOM and SAX processors, which means the later will continue to work as they were and that if they are set, the new property will have no effect. Applications that use the existing properties continue to work as expected.

   This patch continues the path made previously with Xalan and XPath in which functions were moved into the jdk/xml classes. Similar changes are now made with the Xerces and XML classes, consolidating functions into the jdk/xml classes, reducing duplicate code for easier future maintenance.

Tests: new tests are added to cover the various processors.
       Existing tests pass. Only one was updated due to the change to the property impl.

-------------

Commit messages:
 - fix Whitespace errors
 - 8306632: Add a JDK Property for specifying DTD support

Changes: https://git.openjdk.org/jdk/pull/15075/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15075&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306632
  Stats: 3337 lines in 71 files changed: 2019 ins; 1135 del; 183 mod
  Patch: https://git.openjdk.org/jdk/pull/15075.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15075/head:pull/15075

PR: https://git.openjdk.org/jdk/pull/15075

From vlivanov at openjdk.org  Sat Jul 29 02:38:50 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Sat, 29 Jul 2023 02:38:50 GMT
Subject: RFR: 8313023: Return value corrupted when using CCS + isTrivial
 (mainline)
In-Reply-To: <OO6MXUJA8WN4KaZQ5s8f09My73TaVD8Fd4uqVTpRpdo=.ca97bc20-6eff-4855-8fde-cde634c71236@github.com>
References: <OO6MXUJA8WN4KaZQ5s8f09My73TaVD8Fd4uqVTpRpdo=.ca97bc20-6eff-4855-8fde-cde634c71236@github.com>
Message-ID: <bmqtK2gglszrl_-thBqJab2_Qw-LjRE3E6Ot56PwkW8=.a807eb43-90df-4800-8fca-580402b11109@github.com>

On Tue, 25 Jul 2023 19:17:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Port of: https://github.com/openjdk/panama-foreign/pull/848 from the panama-foreign repo.
> 
> Copying the PR body here for convenience:
> 
> Due to a bug in the downcall linker stub generation, we don't save the return value when capturing call state for trivial functions, and the return value gets corrupted.
> 
> We try not to save the return register around calls on the return path of a downcall stub, if it is not needed. Currently we don't save the return register when we're using a return buffer, since we write the return value to the return buffer before the calls on the return path, which means it is safe for those calls to overwrite the return register. But, the current logic also says we don't need to save the return register if the function is trivial (_needs_transition == false). The logic behind this was initially that, since we don't have any calls on the return path, we don't need to save the return register. But, after adding support for capturing call state, we now also have a call on the return path for trivial functions that capture call state, and around that call, we might need to save the return register.
> 
> The fix is to simply save the return register when capturing call state, regardless of whether the function is trivial or not. In the case of just a trivial function that doesn't capture call state, we still don't save the return register around the return path calls for the thread state transition (which is not needed), since we don't generate those thread state transitions in the first first place.
> 
> Testing: jdk-tier1, jdk-tier2, jdk-tier5.

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15025#pullrequestreview-1553162267

From dholmes at openjdk.org  Sat Jul 29 12:31:48 2023
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 29 Jul 2023 12:31:48 GMT
Subject: RFR: 8310643: Misformatted copyright messages in FFM
In-Reply-To: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>
References: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>
Message-ID: <CKKSbqKgvZ3lhPRtCqJ0iM-Ko5ZQ6Rbuh38tIO4Nbrw=.a3d2cb06-dece-4a0a-a380-68ad2ac2b8c6@github.com>

On Wed, 26 Jul 2023 15:43:12 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests updating some of the ill-formed copyright headers in the FFM API and the implementation and test thereof.
> 
> Some of the test files will have now the "classpath" exception. Is this correct?

src/java.base/share/classes/java/lang/foreign/GroupLayout.java line 25:

> 23:  * questions.
> 24:  */
> 25: 

Is there some style guideline that says there needs to be a blank line here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15042#discussion_r1278292345

From dholmes at openjdk.org  Sat Jul 29 12:35:50 2023
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 29 Jul 2023 12:35:50 GMT
Subject: RFR: 8313312: Add missing classpath exception copyright header
 [v2]
In-Reply-To: <cwVvcKK4X92FDntRJg9Iv3NuPvUAaybTDLrp6G1L6To=.0f1c62ab-b8cc-4df2-8157-4445fb1aa49c@github.com>
References: <9ZKXDEMzNF_XPzgzsXYskRSuM4pLj1zBVQUU8YONVqE=.e14017a2-cd82-4abd-8b72-d096a3fce69f@github.com>
 <cwVvcKK4X92FDntRJg9Iv3NuPvUAaybTDLrp6G1L6To=.0f1c62ab-b8cc-4df2-8157-4445fb1aa49c@github.com>
Message-ID: <Eq1iucoAVD0HgjvSt18ebLMnDONUoqjjQBAKiCwItB0=.5be6aa30-ffd5-426d-be74-1283a588764a@github.com>

On Fri, 28 Jul 2023 17:39:18 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Adds `classpath exception` in multiple files, affects copyright header only.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert java.lang.foreign changes

> Please leave the java.lang.foreign changes out of this. We already have another PR for those: #15042

@mcimadamore that PR does not seem to be  addressing this issue. E.g. I see no addition of CPE to src/java.base/share/classes/jdk/internal/foreign/abi/riscv64/RISCV64Architecture.java

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15070#issuecomment-1656720304

From alanb at openjdk.org  Sat Jul 29 13:11:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 29 Jul 2023 13:11:51 GMT
Subject: RFR: 8311989: Test java/lang/Thread/virtual/Reflection.java timed out
Message-ID: <d9lk2VG2kmsjDzSqc5AGPemSjpTF5uorW9NUNe9qCXo=.d607f40f-6e31-4b36-994c-21e7f26c7ad8@github.com>

This is a test only change to a test that exercises core reflection from virtual threads. One of the its tests (testNewInstance6) uses a custom scheduler in setup to check that calling a constructor reflectively, where the constructor parks, doesn't pin the underlying carrier. The test schedules an unpark from a virtual thread but the test is missing a call to Thread::join, thus creating a race between shutdown of the scheduler and the unpark. Two sightings of the test failing so far, both -Xcomp and ZGC.

While in the area, two usages of Thread.sleep in the test have been replaced with latches.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/15073/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15073&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311989
  Stats: 20 lines in 1 file changed: 15 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15073.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15073/head:pull/15073

PR: https://git.openjdk.org/jdk/pull/15073

From vtewari at openjdk.org  Sun Jul 30 04:58:03 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Sun, 30 Jul 2023 04:58:03 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v3]
In-Reply-To: <c3ma_hgY3P7iCJwEVzVvrFKXBykVZnZQwnuKMva_LCY=.dd5cbce8-b761-4de8-a49e-ccf42874f22e@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <c3ma_hgY3P7iCJwEVzVvrFKXBykVZnZQwnuKMva_LCY=.dd5cbce8-b761-4de8-a49e-ccf42874f22e@github.com>
Message-ID: <l89HrXyYOLLrJ1-774IBMvQG5zzYlJ9OxZ9J76qabCc=.e700afae-1e8f-4cf6-bf02-e2d4f34c1506@github.com>

On Fri, 28 Jul 2023 19:59:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6478546: Move buffer clamping up to Java layer; correct read behavior to match legacy

src/java.base/share/native/libjava/io_util.c line 171:

> 169:         if (buf == NULL) {
> 170:             JNU_ThrowOutOfMemoryError(env, NULL);
> 171:             return 0;

why we are returning '0' here ? I can see, it is consistence with 'readBytes'  in case of OOM error we are returning 0 and other exceptions we are returning -1. Can you please help me understand if there is any specific reason for returning 0 in case of OOM ?.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1278508600

From alanb at openjdk.org  Sun Jul 30 12:51:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 30 Jul 2023 12:51:03 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v3]
In-Reply-To: <l89HrXyYOLLrJ1-774IBMvQG5zzYlJ9OxZ9J76qabCc=.e700afae-1e8f-4cf6-bf02-e2d4f34c1506@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <c3ma_hgY3P7iCJwEVzVvrFKXBykVZnZQwnuKMva_LCY=.dd5cbce8-b761-4de8-a49e-ccf42874f22e@github.com>
 <l89HrXyYOLLrJ1-774IBMvQG5zzYlJ9OxZ9J76qabCc=.e700afae-1e8f-4cf6-bf02-e2d4f34c1506@github.com>
Message-ID: <xxK2tPVKoGsk-oXe7WzSzYYuSgVOXvqkVMiUGjTMCIU=.07c3ba46-6992-4891-b7bd-78dc3cb056ad@github.com>

On Sun, 30 Jul 2023 04:54:32 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6478546: Move buffer clamping up to Java layer; correct read behavior to match legacy
>
> src/java.base/share/native/libjava/io_util.c line 171:
> 
>> 169:         if (buf == NULL) {
>> 170:             JNU_ThrowOutOfMemoryError(env, NULL);
>> 171:             return 0;
> 
> why we are returning '0' here ? I can see, it is consistence with 'readBytes'  in case of OOM error we are returning 0 and other exceptions we are returning -1. Can you please help me understand if there is any specific reason for returning 0 in case of OOM ?.

This a JNI function returning with a pending exception so the return value doesn't matter.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1278562919

From alanb at openjdk.org  Sun Jul 30 13:11:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 30 Jul 2023 13:11:57 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v3]
In-Reply-To: <c3ma_hgY3P7iCJwEVzVvrFKXBykVZnZQwnuKMva_LCY=.dd5cbce8-b761-4de8-a49e-ccf42874f22e@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <c3ma_hgY3P7iCJwEVzVvrFKXBykVZnZQwnuKMva_LCY=.dd5cbce8-b761-4de8-a49e-ccf42874f22e@github.com>
Message-ID: <5k4VFVI74A2cbypxW01WHS1-jRPs0LCCmnT8sfQEomM=.1f19c199-0531-46f4-9b44-3ddccb053d69@github.com>

On Fri, 28 Jul 2023 19:59:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6478546: Move buffer clamping up to Java layer; correct read behavior to match legacy

src/java.base/share/classes/java/io/FileInputStream.java line 257:

> 255:         try {
> 256:             do {
> 257:                 int size = Math.min(remaining, 1572864);

1.5Mb seems high, I think we really need micro that do real file I/O to help tune this.

src/java.base/share/classes/java/io/FileOutputStream.java line 347:

> 345:                 pos += n;
> 346:                 remaining -= n;
> 347:             } while (remaining > 0);

Long standing behavior is that write is a no-open with len is 0, meaning you can do while here (no need to change it to do-while). Same thing in RAF.

src/java.base/share/native/libjava/io_util.c line 160:

> 158:     }
> 159: 
> 160:     if (outOfBounds(env, off, len, bytes)) {

I assume the IS_NULL and outOfBounds checking in both readBytes and writeBytes are redundant now.

src/java.base/share/native/libjava/io_util.c line 183:

> 181:         if (fd == -1) {
> 182:             JNU_ThrowIOException(env, "Stream Closed");
> 183:             nwritten = -1;

nwritten is initialized to -1.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1278565903
PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1278565565
PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1278563940
PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1278564255

From jwaters at openjdk.org  Mon Jul 31 05:06:51 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 31 Jul 2023 05:06:51 GMT
Subject: RFR: 8311085: Remove implementation detail writeTo from
 LocalVariable(Type) [v3]
In-Reply-To: <3n3a_zG41I1GVeW5RHAr2EASIq4cV_lrxPup1oNuRv8=.49f6ebe7-75d8-4424-9259-dbe8b96800b9@github.com>
References: <hhBayhCuF2xJo2qZ7OkMY26xdqYiDGaUQRjM2xqKjGs=.5ace6fd4-d423-4225-a34e-e62c0d5ca6a2@github.com>
 <7ubzbHS_BqvgHxklY3aRqbDUlntOcUNlRDALOKHXwcU=.bbdb193a-e9e3-4047-84c0-9659915e3b69@github.com>
 <3n3a_zG41I1GVeW5RHAr2EASIq4cV_lrxPup1oNuRv8=.49f6ebe7-75d8-4424-9259-dbe8b96800b9@github.com>
Message-ID: <B6beItW_JkydxjXvQUgdAXQM6kaGsI0yO6Vnkbk8c1w=.72b74f81-15f9-49c1-b8e5-9848b6282796@github.com>

On Sun, 2 Jul 2023 12:16:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix line ending, update corpus test
>
> Please hold off on sponsoring this; after another look, I find that LocalVariable and LocalVariableType can probably implement `WritableElement`.
> 
> Per our previous discussion, `WritableElement` should probably not be exposed; it is currently only exposed as a type parameter upper bound in `<T extends WritableElement<?>> void writeList(List<T> list);`
> 
> I think we might convert the `WritableElement` to an internal interface: is it possible to declare the method as `void writeTo(BufWriterImpl)`, and the public method is yet hidden from the API because `BufWriterImpl` is not in an exported package? For the `writeList`, I would turn it into `<T> void writeList(List<T> list, BiConsumer<T, BufWriter> writer)` or simply remove it.

@liach You can turn this back to draft or run the reviewers 2 command to reduce this risk of accidental sponsorship

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14705#issuecomment-1657600250

From scolebourne at openjdk.org  Mon Jul 31 07:13:43 2023
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Mon, 31 Jul 2023 07:13:43 GMT
Subject: RFR: 8313231: Redundant if statement in ZoneInfoFile
In-Reply-To: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
References: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
Message-ID: <w4MO1cUT1BGF6AwXNxGw6DfLkjPmRLF6MS2Z0CP8hbw=.f8943550-2c74-46dc-92e7-3e86a6f0c24c@github.com>

On Thu, 27 Jul 2023 06:46:46 GMT, John Jiang <jjiang at openjdk.org> wrote:

> if (i < savingsInstantTransitions.length) {
>     // javazic writes the last GMT offset into index 0!
>     if (i < savingsInstantTransitions.length) {
>         offsets[0] = standardOffsets[standardOffsets.length - 1] * 1000;
>         nOffsets = 1;
>     }
>     ...
> }
> 
> 
> The second if statement looks unnecessary.

Marked as reviewed by scolebourne (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15052#pullrequestreview-1554092886

From scolebourne at openjdk.org  Mon Jul 31 07:13:45 2023
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Mon, 31 Jul 2023 07:13:45 GMT
Subject: RFR: 8313231: Redundant if statement in ZoneInfoFile
In-Reply-To: <WkXEKK2noE080KzBMxfg-2xDGqUglB_zA267OpdC6gY=.fa7eeba9-2bb7-4f36-8c5e-20137a0ff9a1@github.com>
References: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
 <WkXEKK2noE080KzBMxfg-2xDGqUglB_zA267OpdC6gY=.fa7eeba9-2bb7-4f36-8c5e-20137a0ff9a1@github.com>
Message-ID: <7pmFTOthufJofV1gsoIeOVdc5FqkdZSl9DeSbsgHRa0=.e9eaef28-76b1-4f75-936d-b1aabeb88f25@github.com>

On Thu, 27 Jul 2023 11:01:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> if (i < savingsInstantTransitions.length) {
>>     // javazic writes the last GMT offset into index 0!
>>     if (i < savingsInstantTransitions.length) {
>>         offsets[0] = standardOffsets[standardOffsets.length - 1] * 1000;
>>         nOffsets = 1;
>>     }
>>     ...
>> }
>> 
>> 
>> The second if statement looks unnecessary.
>
> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 471:
> 
>> 469:             if (i < savingsInstantTransitions.length) {
>> 470:                 // javazic writes the last GMT offset into index 0!
>> 471:                 if (i < savingsInstantTransitions.length) {
> 
> Even my IDE flags it as always true. While it surely is redundant, I wonder if some other check was intended instead. @jodastephen?

I'm not sure this is my code - I certainly don't remember it. This PR causes no effective change but be slightly neater, so I guess I approve the PR

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15052#discussion_r1278874277

From jpai at openjdk.org  Mon Jul 31 07:23:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 31 Jul 2023 07:23:51 GMT
Subject: RFR: 8311989: Test java/lang/Thread/virtual/Reflection.java timed
 out
In-Reply-To: <d9lk2VG2kmsjDzSqc5AGPemSjpTF5uorW9NUNe9qCXo=.d607f40f-6e31-4b36-994c-21e7f26c7ad8@github.com>
References: <d9lk2VG2kmsjDzSqc5AGPemSjpTF5uorW9NUNe9qCXo=.d607f40f-6e31-4b36-994c-21e7f26c7ad8@github.com>
Message-ID: <4Bss41U8S-8CRewQM_KCI5b349Pm4nd6YQj4Ir4X734=.20f1beed-ac34-4fec-891a-809ba8f784c8@github.com>

On Fri, 28 Jul 2023 15:44:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to a test that exercises core reflection from virtual threads. One of the tests (testNewInstance6) uses a custom scheduler in setup to check that calling a constructor reflectively, where the constructor parks, doesn't pin the underlying carrier. The test schedules an unpark from a virtual thread but the test is missing a call to Thread::join, thus creating a race between shutdown of the scheduler and the unpark. Two sightings of the test failing so far, both -Xcomp and ZGC.
> 
> While in the area, two usages of Thread.sleep in the test have been replaced with latches.

The change looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15073#pullrequestreview-1554107159

From jjiang at openjdk.org  Mon Jul 31 07:48:44 2023
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 31 Jul 2023 07:48:44 GMT
Subject: RFR: 8313231: Redundant if statement in ZoneInfoFile
In-Reply-To: <w4MO1cUT1BGF6AwXNxGw6DfLkjPmRLF6MS2Z0CP8hbw=.f8943550-2c74-46dc-92e7-3e86a6f0c24c@github.com>
References: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
 <w4MO1cUT1BGF6AwXNxGw6DfLkjPmRLF6MS2Z0CP8hbw=.f8943550-2c74-46dc-92e7-3e86a6f0c24c@github.com>
Message-ID: <xM_hTPE2FiPCzI7F-xvVkDXBSNMjsHM-2uihF22lMbE=.13fb363f-63a2-4288-915d-33876b78f9aa@github.com>

On Mon, 31 Jul 2023 07:11:24 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> if (i < savingsInstantTransitions.length) {
>>     // javazic writes the last GMT offset into index 0!
>>     if (i < savingsInstantTransitions.length) {
>>         offsets[0] = standardOffsets[standardOffsets.length - 1] * 1000;
>>         nOffsets = 1;
>>     }
>>     ...
>> }
>> 
>> 
>> The second if statement looks unnecessary.
>
> Marked as reviewed by scolebourne (Author).

@jodastephen @DamonFool @pavelrappo 
Thanks for your reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15052#issuecomment-1657847007

From jjiang at openjdk.org  Mon Jul 31 07:53:55 2023
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 31 Jul 2023 07:53:55 GMT
Subject: Integrated: 8313231: Redundant if statement in ZoneInfoFile
In-Reply-To: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
References: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
Message-ID: <VypUq7JamGZQQyfsFDccrZ3JmDkPMtiy4z6zcX4WNlw=.56b49ee4-48b4-4116-8c30-222367d39770@github.com>

On Thu, 27 Jul 2023 06:46:46 GMT, John Jiang <jjiang at openjdk.org> wrote:

> if (i < savingsInstantTransitions.length) {
>     // javazic writes the last GMT offset into index 0!
>     if (i < savingsInstantTransitions.length) {
>         offsets[0] = standardOffsets[standardOffsets.length - 1] * 1000;
>         nOffsets = 1;
>     }
>     ...
> }
> 
> 
> The second if statement looks unnecessary.

This pull request has now been integrated.

Changeset: f8c2b7fe
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f8c2b7fee101d66107704b3ee464737c5ccdc13a
Stats:     4 lines in 1 file changed: 0 ins; 1 del; 3 mod

8313231: Redundant if statement in ZoneInfoFile

Reviewed-by: jiefu, scolebourne

-------------

PR: https://git.openjdk.org/jdk/pull/15052

From duke at openjdk.org  Mon Jul 31 08:04:25 2023
From: duke at openjdk.org (sid8606)
Date: Mon, 31 Jul 2023 08:04:25 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v7]
In-Reply-To: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
Message-ID: <PHjg21iCVdADrraZTD7W559jnt2sRBWRw1hLjgS28nQ=.555eb54c-7409-4312-af81-cb32c74d15ef@github.com>

> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).

sid8606 has updated the pull request incrementally with one additional commit since the last revision:

  Restructure comment sentence

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14801/files
  - new: https://git.openjdk.org/jdk/pull/14801/files/cc2292dd..12d1a397

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=05-06

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14801/head:pull/14801

PR: https://git.openjdk.org/jdk/pull/14801

From jvernee at openjdk.org  Mon Jul 31 08:05:00 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 31 Jul 2023 08:05:00 GMT
Subject: Integrated: 8313023: Return value corrupted when using CCS + isTrivial
 (mainline)
In-Reply-To: <OO6MXUJA8WN4KaZQ5s8f09My73TaVD8Fd4uqVTpRpdo=.ca97bc20-6eff-4855-8fde-cde634c71236@github.com>
References: <OO6MXUJA8WN4KaZQ5s8f09My73TaVD8Fd4uqVTpRpdo=.ca97bc20-6eff-4855-8fde-cde634c71236@github.com>
Message-ID: <o3u8abvibUoogt8VAOOzqlsONhimbFYVc8QSjemUD2s=.c0ad9752-c08b-4252-a0dc-5023fc990f14@github.com>

On Tue, 25 Jul 2023 19:17:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Port of: https://github.com/openjdk/panama-foreign/pull/848 from the panama-foreign repo.
> 
> Copying the PR body here for convenience:
> 
> Due to a bug in the downcall linker stub generation, we don't save the return value when capturing call state for trivial functions, and the return value gets corrupted.
> 
> We try not to save the return register around calls on the return path of a downcall stub, if it is not needed. Currently we don't save the return register when we're using a return buffer, since we write the return value to the return buffer before the calls on the return path, which means it is safe for those calls to overwrite the return register. But, the current logic also says we don't need to save the return register if the function is trivial (_needs_transition == false). The logic behind this was initially that, since we don't have any calls on the return path, we don't need to save the return register. But, after adding support for capturing call state, we now also have a call on the return path for trivial functions that capture call state, and around that call, we might need to save the return register.
> 
> The fix is to simply save the return register when capturing call state, regardless of whether the function is trivial or not. In the case of just a trivial function that doesn't capture call state, we still don't save the return register around the return path calls for the thread state transition (which is not needed), since we don't generate those thread state transitions in the first first place.
> 
> Testing: jdk-tier1, jdk-tier2, jdk-tier5.

This pull request has now been integrated.

Changeset: 6fca2898
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6fca28988794b52a6aa974bed1ed6f4f07e0994b
Stats:     39 lines in 5 files changed: 12 ins; 0 del; 27 mod

8313023: Return value corrupted when using CCS + isTrivial (mainline)

Reviewed-by: mcimadamore, vlivanov

-------------

PR: https://git.openjdk.org/jdk/pull/15025

From duke at openjdk.org  Mon Jul 31 08:04:30 2023
From: duke at openjdk.org (sid8606)
Date: Mon, 31 Jul 2023 08:04:30 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v6]
In-Reply-To: <OpX_4s42FiOutGsH9buHA6jR0tuGHejkIhJar8qZmaI=.9676fdc6-0b71-44b9-a82e-96750c1525d9@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <CRkpBSFzMIMI4km33WN9nLGSp7JuMM5s-2GdotfdeV8=.c6b252f1-74c5-4747-b528-26f787152fe2@github.com>
 <OpX_4s42FiOutGsH9buHA6jR0tuGHejkIhJar8qZmaI=.9676fdc6-0b71-44b9-a82e-96750c1525d9@github.com>
Message-ID: <XCxeWnPXJ4cvOI46OuHfKAgZ0xRldvhS7TIPKLiFzog=.361051e1-4b34-4218-8687-e8e3e54cfda9@github.com>

On Fri, 28 Jul 2023 12:36:13 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Preserve and restore register Z_R6
>>   
>>   Though Z_R6 is argument register it is a saved register
>>   so preserve and restore Z_R6 register
>
> src/hotspot/cpu/s390/upcallLinker_s390.cpp line 72:
> 
>> 70:     // Z_SP saved/restored by prologue/epilogue
>> 71:     if (reg == Z_SP) continue;
>> 72:     // though Z_R6 is argument register it is a saved register
> 
> Suggestion:
> `    // although Z_R6 is used for parameter passing, it must be saved and restored by a called function.`

Thanks for the review. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1278922263

From jvernee at openjdk.org  Mon Jul 31 08:12:01 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 31 Jul 2023 08:12:01 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v6]
In-Reply-To: <CRkpBSFzMIMI4km33WN9nLGSp7JuMM5s-2GdotfdeV8=.c6b252f1-74c5-4747-b528-26f787152fe2@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <CRkpBSFzMIMI4km33WN9nLGSp7JuMM5s-2GdotfdeV8=.c6b252f1-74c5-4747-b528-26f787152fe2@github.com>
Message-ID: <ZpwEwUH26fTry_21cRkKl0izTzB2YlUZ7u3PvaWeW4E=.f3c61d77-3c6b-4792-858d-fae6ac1358c8@github.com>

On Fri, 28 Jul 2023 03:59:26 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Preserve and restore register Z_R6
>   
>   Though Z_R6 is argument register it is a saved register
>   so preserve and restore Z_R6 register

src/hotspot/cpu/s390/upcallLinker_s390.cpp line 45:

> 43:     if (reg == Z_SP) continue;
> 44:     // though Z_R6 is argument register it is a saved register
> 45:     if (!abi.is_volatile_reg(reg) || reg == Z_R6) {

So, is the prior assumption that all argument registers are also volatile incorrect?

If so, I think it would be better to change `ABIDescriptor::is_volatile_reg` ([1]) to only look at the `_integer_additional_volatile_registers` list (maybe rename it too), and then list all the volatile regs in  LinuxS390CallArranger explicitly, excluding R6 ([2]). That way all the information about which regs are volatile is in one place (LinuxS390CallArranger).

[1]: https://github.com/openjdk/jdk/pull/14801/files#diff-7096e1975de20baa3219d616506f26ba2b4500bf5ad28c331e3d6049a32a461eR39-R42
[2]: https://github.com/openjdk/jdk/pull/14801/files#diff-09da9016992b04bab73b6cc6aad8ca719e86c90c398af4e000583c1f8220a99bR73

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1278932461

From jvernee at openjdk.org  Mon Jul 31 08:21:11 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 31 Jul 2023 08:21:11 GMT
Subject: [jdk21] RFR: 8313023: Return value corrupted when using CCS +
 isTrivial (mainline)
Message-ID: <dkqtEtTUgG8zHoU3EJYBpV09trLBjRen2fHiKfRcMas=.04ac1c72-1e83-44b7-8e75-b460acd6eb39@github.com>

Hi all,

This pull request contains a backport of commit [6fca2898](https://github.com/openjdk/jdk/commit/6fca28988794b52a6aa974bed1ed6f4f07e0994b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jorn Vernee on 31 Jul 2023 and was reviewed by Maurizio Cimadamore and Vladimir Ivanov.

Thanks!

-------------

Commit messages:
 - Backport 6fca28988794b52a6aa974bed1ed6f4f07e0994b

Changes: https://git.openjdk.org/jdk21/pull/150/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=150&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313023
  Stats: 39 lines in 5 files changed: 12 ins; 0 del; 27 mod
  Patch: https://git.openjdk.org/jdk21/pull/150.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/150/head:pull/150

PR: https://git.openjdk.org/jdk21/pull/150

From per-ake.minborg at oracle.com  Mon Jul 31 08:22:26 2023
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Mon, 31 Jul 2023 08:22:26 +0000
Subject: CFV: New Core Libraries Group Member: Joe Wang
In-Reply-To: <6F414B9F-3987-4CBF-883B-021251ED2305@oracle.com>
References: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
 <6F414B9F-3987-4CBF-883B-021251ED2305@oracle.com>
Message-ID: <DM6PR10MB4283FA138A786B130421947BDA05A@DM6PR10MB4283.namprd10.prod.outlook.com>

Vote: Yes.
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Lance Andersen <lance.andersen at oracle.com>
Sent: Friday, July 28, 2023 9:40 PM
To: Roger Riggs <roger.riggs at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: CFV: New Core Libraries Group Member: Joe Wang


Vote: Yes.


On 27/07/2023 19:36, Roger Riggs wrote:

I hereby nominate Joe Wang to Membership in the Core Libraries Group

Joe has been working in the core library team since 2012.
He has been maintaining and improving the XML library APIs and implementations
including DOM, SAX, StAX, Transform, Validation, XPath and Catalog.
Recently he has been updating and improving XML Security.

Votes are due by August 11th, 2023.

Only current Members of the Core Libraries Group [1] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs
[2] https://openjdk.org/groups/#member-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230731/711e1e4d/attachment.htm>

From shade at openjdk.org  Mon Jul 31 08:37:58 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 31 Jul 2023 08:37:58 GMT
Subject: RFR: 8313307: java/util/Formatter/Padding.java fails on some
 Locales [v2]
In-Reply-To: <n6-76f0BzHFEKRERy68N-jTy_zEoArwe6jeczkYCHhs=.89bb7415-fd8c-494d-8749-584e4eb19129@github.com>
References: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
 <n6-76f0BzHFEKRERy68N-jTy_zEoArwe6jeczkYCHhs=.89bb7415-fd8c-494d-8749-584e4eb19129@github.com>
Message-ID: <yBwYg7E4VaZsHTOb3-FviM2p1YEfJyfYuEs1SFeTpyE=.336380f3-332e-4a05-b9b7-0232a5659929@github.com>

On Fri, 28 Jul 2023 17:13:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Fails like this:
>> 
>> 
>> $ CONF=macosx-aarch64-server-fastdebug make images test TEST=java/util/Formatter/Padding.java
>> 
>> ...
>> STARTED Padding::padding '[216] -0000001.2, % 010.1f, -1.2'
>> org.opentest4j.AssertionFailedError: expected: <-0000001.2> but was: <-0000001,2>
>> 
>> 
>> Looks like a locale problem in test, so the simplest fix is to ask for a neutral Locale there.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change to Locale.US

Thank you all!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15066#issuecomment-1657917894

From shade at openjdk.org  Mon Jul 31 08:37:59 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 31 Jul 2023 08:37:59 GMT
Subject: Integrated: 8313307: java/util/Formatter/Padding.java fails on some
 Locales
In-Reply-To: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
References: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
Message-ID: <HYhRy-jeW34MAy0f80B7f0xFJx35lNF8NCBEJvptEPw=.e0745eb6-b919-4d0c-87dc-93c790f884e3@github.com>

On Fri, 28 Jul 2023 08:49:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> $ CONF=macosx-aarch64-server-fastdebug make images test TEST=java/util/Formatter/Padding.java
> 
> ...
> STARTED Padding::padding '[216] -0000001.2, % 010.1f, -1.2'
> org.opentest4j.AssertionFailedError: expected: <-0000001.2> but was: <-0000001,2>
> 
> 
> Looks like a locale problem in test, so the simplest fix is to ask for a neutral Locale there.

This pull request has now been integrated.

Changeset: 408987e1
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/408987e1ca9a42db8019b1bd7e52f85607975dde
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8313307: java/util/Formatter/Padding.java fails on some Locales

Reviewed-by: jlu, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/15066

From dholmes at openjdk.org  Mon Jul 31 08:39:02 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Jul 2023 08:39:02 GMT
Subject: [jdk21] RFR: 8300937: Update nroff pages in JDK 21 before RC
Message-ID: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>

Main changes are to use 21 instead of 21-ea. In addition the following files contain additional updates from the closed sources:

- src/java.base/share/man/java.1

 [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
 [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front

There are also some formatting differences related to:

 [JDK-8309670](https://bugs.openjdk.org/browse/JDK-8309670): java -help output for --module-path / -p is incomplete

Likely a different version of pandoc was used.

- src/java.base/share/man/keytool.1

 [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character

- src/jdk.compiler/share/man/javac.1

 [JDK-8308456](https://bugs.openjdk.org/browse/JDK-8308456): Update javac tool page for -proc:full

also some formatting differences.

- src/jdk.jartool/share/man/jarsigner.1

 [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)

- src/jdk.jcmd/share/man/jcmd.1

 [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion

- src/jdk.jdeps/share/man/jdeps.1

 [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option

- src/jdk.jfr/share/man/jfr.1

Formatting changes.

- src/jdk.jshell/share/man/jshell.1

 [JDK-8308988](https://bugs.openjdk.org/browse/JDK-8308988): Update JShell manpage to include TOOLING description

-------------

Commit messages:
 - 8300937: Update nroff pages in JDK 21 before RC

Changes: https://git.openjdk.org/jdk21/pull/151/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=151&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300937
  Stats: 163 lines in 28 files changed: 37 ins; 60 del; 66 mod
  Patch: https://git.openjdk.org/jdk21/pull/151.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/151/head:pull/151

PR: https://git.openjdk.org/jdk21/pull/151

From duke at openjdk.org  Mon Jul 31 09:54:53 2023
From: duke at openjdk.org (sid8606)
Date: Mon, 31 Jul 2023 09:54:53 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v6]
In-Reply-To: <ZpwEwUH26fTry_21cRkKl0izTzB2YlUZ7u3PvaWeW4E=.f3c61d77-3c6b-4792-858d-fae6ac1358c8@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <CRkpBSFzMIMI4km33WN9nLGSp7JuMM5s-2GdotfdeV8=.c6b252f1-74c5-4747-b528-26f787152fe2@github.com>
 <ZpwEwUH26fTry_21cRkKl0izTzB2YlUZ7u3PvaWeW4E=.f3c61d77-3c6b-4792-858d-fae6ac1358c8@github.com>
Message-ID: <HxZ5GsNyGPayJirTTRduaQWislw9ir-cgvYYQBTeyow=.01ce51fb-50d1-4589-81e0-51736367b397@github.com>

On Mon, 31 Jul 2023 08:08:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Preserve and restore register Z_R6
>>   
>>   Though Z_R6 is argument register it is a saved register
>>   so preserve and restore Z_R6 register
>
> src/hotspot/cpu/s390/upcallLinker_s390.cpp line 45:
> 
>> 43:     if (reg == Z_SP) continue;
>> 44:     // though Z_R6 is argument register it is a saved register
>> 45:     if (!abi.is_volatile_reg(reg) || reg == Z_R6) {
> 
> So, is the prior assumption that all argument registers are also volatile incorrect?
> 
> If so, I think it would be better to change `ABIDescriptor::is_volatile_reg` ([1]) to only look at the `_integer_additional_volatile_registers` list (maybe rename it too), and then list all the volatile regs in  LinuxS390CallArranger explicitly, excluding R6 ([2]). That way all the information about which regs are volatile is in one place (LinuxS390CallArranger).
> 
> [1]: https://github.com/openjdk/jdk/pull/14801/files#diff-7096e1975de20baa3219d616506f26ba2b4500bf5ad28c331e3d6049a32a461eR39-R42
> [2]: https://github.com/openjdk/jdk/pull/14801/files#diff-09da9016992b04bab73b6cc6aad8ca719e86c90c398af4e000583c1f8220a99bR73

Yes, s390x ABI says R6 is an argument register as we as non-volatile register.
It make sense, I'll make suggested changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1279064461

From jlaskey at openjdk.org  Mon Jul 31 12:21:02 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Jul 2023 12:21:02 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v9]
In-Reply-To: <F7-vbtAOHcDyu4wHp0n9Nh4PpcqPHHP8VWOk0bLJpMw=.bf1de997-f424-400b-ad6b-c8a9e017edd6@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <ixwf_fqc32YLSj9qlNkzlazRe5Zgf60Ufdg2c1yVKTM=.1d580c15-36a5-418d-9362-16eacb9135d7@github.com>
 <F7-vbtAOHcDyu4wHp0n9Nh4PpcqPHHP8VWOk0bLJpMw=.bf1de997-f424-400b-ad6b-c8a9e017edd6@github.com>
Message-ID: <JFefMMa5j1hs4baS7nad9COE9GMoVqDObG0QHH0pgcI=.b2021f1e-ec55-4325-a6e7-cca80cd50f1a@github.com>

On Wed, 19 Jul 2023 13:59:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Merge branch 'master' into 8310913
>>  - Requested changes.
>>    
>>    Added intern with UnaryOperator<T> interning function to prepare key before adding to set.
>>  - Update test to check for gc.
>>  - Update ReferencedKeyTest.java
>>  - Simple versions of create
>>  - Add flag for reference queue type
>>  - Merge branch 'master' into 8310913
>>  - Update to use VirtualThread friendly stale queue.
>>  - Remove warning tied to String Templates
>>  - unneeded SuppressWarning
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/028068a6...fbb78778
>
> src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 344:
> 
>> 342:      * interning values in a set.
>> 343:      *
>> 344:      * @implNote Requires a {@link ReferencedKeyMap} whose {@code V} type
> 
> The type safety is now ensured by the generic declaration on the static method. The `@implNote`s and `@throws ClassCastException`, including ones in other intern methods, are now redundant.

I think it still serves a warning to not use this form of the `intern` method during phase1. I will add a note that they should use an UnaryOperator instance instead of a lambda.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1279211620

From jlaskey at openjdk.org  Mon Jul 31 13:34:30 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Jul 2023 13:34:30 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v10]
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: <GaYMKEn3kerkgjjRebWCHq7d223FXiggEqDO4qynQEI=.9a92a070-0d89-43bc-baa6-46d423c5372a@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 with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' into 8310913
 - Update implNote for intern
 - Merge branch 'master' into 8310913
 - Requested changes.
   
   Added intern with UnaryOperator<T> interning function to prepare key before adding to set.
 - Update test to check for gc.
 - Update ReferencedKeyTest.java
 - Simple versions of create
 - Add flag for reference queue type
 - Merge branch 'master' into 8310913
 - Update to use VirtualThread friendly stale queue.
 - ... and 7 more: https://git.openjdk.org/jdk/compare/408987e1...af95e5ae

-------------

Changes: https://git.openjdk.org/jdk/pull/14684/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14684&range=09
  Stats: 1520 lines in 13 files changed: 887 ins; 625 del; 8 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 duke at openjdk.org  Mon Jul 31 14:04:23 2023
From: duke at openjdk.org (sid8606)
Date: Mon, 31 Jul 2023 14:04:23 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v8]
In-Reply-To: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
Message-ID: <-1Z9zN0Ljsm8JremgZrieIxTqr36QN2WrsBeDLelJpo=.4015c349-9a5a-45e6-9f71-76737e2154d7@github.com>

> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).

sid8606 has updated the pull request incrementally with one additional commit since the last revision:

  List all the volatile regs in LinuxS390CallArranger explicitly
  
  Signed-off-by: Sidraya <sidraya.jayagond at ibm.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14801/files
  - new: https://git.openjdk.org/jdk/pull/14801/files/12d1a397..fd2c6701

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=06-07

  Stats: 11 lines in 4 files changed: 0 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14801/head:pull/14801

PR: https://git.openjdk.org/jdk/pull/14801

From duke at openjdk.org  Mon Jul 31 14:12:00 2023
From: duke at openjdk.org (sid8606)
Date: Mon, 31 Jul 2023 14:12:00 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v6]
In-Reply-To: <HxZ5GsNyGPayJirTTRduaQWislw9ir-cgvYYQBTeyow=.01ce51fb-50d1-4589-81e0-51736367b397@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <CRkpBSFzMIMI4km33WN9nLGSp7JuMM5s-2GdotfdeV8=.c6b252f1-74c5-4747-b528-26f787152fe2@github.com>
 <ZpwEwUH26fTry_21cRkKl0izTzB2YlUZ7u3PvaWeW4E=.f3c61d77-3c6b-4792-858d-fae6ac1358c8@github.com>
 <HxZ5GsNyGPayJirTTRduaQWislw9ir-cgvYYQBTeyow=.01ce51fb-50d1-4589-81e0-51736367b397@github.com>
Message-ID: <YBW9z25e2jZbaSPsIwtTtAZlIyQ7M_GwtPrTp_ROIZ0=.ad5c4796-a28e-4601-b7d7-b89560240134@github.com>

On Mon, 31 Jul 2023 09:51:44 GMT, sid8606 <duke at openjdk.org> wrote:

>> src/hotspot/cpu/s390/upcallLinker_s390.cpp line 45:
>> 
>>> 43:     if (reg == Z_SP) continue;
>>> 44:     // though Z_R6 is argument register it is a saved register
>>> 45:     if (!abi.is_volatile_reg(reg) || reg == Z_R6) {
>> 
>> So, is the prior assumption that all argument registers are also volatile incorrect?
>> 
>> If so, I think it would be better to change `ABIDescriptor::is_volatile_reg` ([1]) to only look at the `_integer_additional_volatile_registers` list (maybe rename it too), and then list all the volatile regs in  LinuxS390CallArranger explicitly, excluding R6 ([2]). That way all the information about which regs are volatile is in one place (LinuxS390CallArranger).
>> 
>> [1]: https://github.com/openjdk/jdk/pull/14801/files#diff-7096e1975de20baa3219d616506f26ba2b4500bf5ad28c331e3d6049a32a461eR39-R42
>> [2]: https://github.com/openjdk/jdk/pull/14801/files#diff-09da9016992b04bab73b6cc6aad8ca719e86c90c398af4e000583c1f8220a99bR73
>
> Yes, s390x ABI says R6 is an argument register as we as non-volatile register.
> It make sense, I'll make suggested changes.

Made the changes in new commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1279354543

From amitkumar at openjdk.org  Mon Jul 31 14:18:09 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 31 Jul 2023 14:18:09 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v8]
In-Reply-To: <-1Z9zN0Ljsm8JremgZrieIxTqr36QN2WrsBeDLelJpo=.4015c349-9a5a-45e6-9f71-76737e2154d7@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <-1Z9zN0Ljsm8JremgZrieIxTqr36QN2WrsBeDLelJpo=.4015c349-9a5a-45e6-9f71-76737e2154d7@github.com>
Message-ID: <G_-CE66UQQT1EsI_gCH6T3Z0n2j5Z3G3xAKxGcUjzGQ=.546f6f36-8257-4c66-85a1-77df37fa4949@github.com>

On Mon, 31 Jul 2023 14:04:23 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   List all the volatile regs in LinuxS390CallArranger explicitly
>   
>   Signed-off-by: Sidraya <sidraya.jayagond at ibm.com>

Some nits :-)

-------------

Marked as reviewed by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14801#pullrequestreview-1527808341

From amitkumar at openjdk.org  Mon Jul 31 14:18:12 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 31 Jul 2023 14:18:12 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
Message-ID: <ePA2Co3SuIIkJZd1Ox5AvEr8bJIv8lOBEuV9CGiCQng=.977566d9-770a-4540-9cd5-4df752d63ac2@github.com>

On Sat, 8 Jul 2023 10:48:15 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address suggestions from Jorn Vernee

src/hotspot/cpu/s390/frame_s390.cpp line 228:

> 226: 
> 227: bool frame::upcall_stub_frame_is_first() const {
> 228:   assert(is_upcall_stub_frame(), "must be optimzed entry frame");

typo: s/optimzed/optimized

src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390CallArranger.java line 70:

> 68:     private static final ABIDescriptor CLinux = abiFor(
> 69:             new VMStorage[] { r2, r3, r4, r5, r6, }, // GP input
> 70:             new VMStorage[] { f0, f2, f4, f6 }, // FP intput

typo: s/intput/input

src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390CallArranger.java line 205:

> 203:     }
> 204: 
> 205:     // Compute recipe for transfering arguments / return values to C from Java.

typo: s/transfering/transferring

src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390CallArranger.java line 257:

> 255:     }
> 256: 
> 257:     // Compute recipe for transfering arguments / return values from C to Java.

typo: s/transfering/transferring

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1262149143
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1262152073
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1262153723
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1262154919

From dfuchs at openjdk.org  Mon Jul 31 14:24:57 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 31 Jul 2023 14:24:57 GMT
Subject: [jdk21] RFR: 8300937: Update nroff pages in JDK 21 before RC
In-Reply-To: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
References: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
Message-ID: <ZCnxqhxOMB5j9kYy7elrAETowcCKkK5EtGoxN0qhzjU=.7bc683d4-e058-4217-8977-ee839554aca4@github.com>

On Mon, 31 Jul 2023 08:33:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Main changes are to use 21 instead of 21-ea. In addition the following files contain additional updates from the closed sources:
> 
> - src/java.base/share/man/java.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
>  [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
> 
> There are also some formatting differences related to:
> 
>  [JDK-8309670](https://bugs.openjdk.org/browse/JDK-8309670): java -help output for --module-path / -p is incomplete
> 
> Likely a different version of pandoc was used.
> 
> - src/java.base/share/man/keytool.1
> 
>  [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> 
> - src/jdk.compiler/share/man/javac.1
> 
>  [JDK-8308456](https://bugs.openjdk.org/browse/JDK-8308456): Update javac tool page for -proc:full
> 
> also some formatting differences.
> 
> - src/jdk.jartool/share/man/jarsigner.1
> 
>  [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> 
> - src/jdk.jcmd/share/man/jcmd.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
> 
> - src/jdk.jdeps/share/man/jdeps.1
> 
>  [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> - src/jdk.jfr/share/man/jfr.1
> 
> Formatting changes.
> 
> - src/jdk.jshell/share/man/jshell.1
> 
>  [JDK-8308988](https://bugs.openjdk.org/browse/JDK-8308988): Update JShell manpage to include TOOLING description

Changes to jwebserver.1 look good to me.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/151#issuecomment-1658469731

From amitkumar at openjdk.org  Mon Jul 31 14:33:20 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 31 Jul 2023 14:33:20 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <ePA2Co3SuIIkJZd1Ox5AvEr8bJIv8lOBEuV9CGiCQng=.977566d9-770a-4540-9cd5-4df752d63ac2@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
 <ePA2Co3SuIIkJZd1Ox5AvEr8bJIv8lOBEuV9CGiCQng=.977566d9-770a-4540-9cd5-4df752d63ac2@github.com>
Message-ID: <UA7ZGFLTwJgbWQkZXrlWIjos5f9d9bcZt8-cqJlBpm8=.7da2a900-d87b-4ce5-b70f-6b88d7923ff4@github.com>

On Thu, 13 Jul 2023 07:41:11 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address suggestions from Jorn Vernee
>
> src/hotspot/cpu/s390/frame_s390.cpp line 228:
> 
>> 226: 
>> 227: bool frame::upcall_stub_frame_is_first() const {
>> 228:   assert(is_upcall_stub_frame(), "must be optimzed entry frame");
> 
> typo: s/optimzed/optimized

@sid8606 you left this one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1279382122

From duke at openjdk.org  Mon Jul 31 14:33:19 2023
From: duke at openjdk.org (sid8606)
Date: Mon, 31 Jul 2023 14:33:19 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v9]
In-Reply-To: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
Message-ID: <COlNVoJIX-BKMkCLnyVVeIMvGSXMw2J36PyHGu0BWBQ=.fa23cf11-878c-48c6-bccc-1c0781fa0574@github.com>

> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).

sid8606 has updated the pull request incrementally with one additional commit since the last revision:

  Fix typos
  
  Signed-off-by: Sidraya <sidraya.jayagond at ibm.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14801/files
  - new: https://git.openjdk.org/jdk/pull/14801/files/fd2c6701..b81d5bb7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=07-08

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14801/head:pull/14801

PR: https://git.openjdk.org/jdk/pull/14801

From duke at openjdk.org  Mon Jul 31 14:33:20 2023
From: duke at openjdk.org (sid8606)
Date: Mon, 31 Jul 2023 14:33:20 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <ePA2Co3SuIIkJZd1Ox5AvEr8bJIv8lOBEuV9CGiCQng=.977566d9-770a-4540-9cd5-4df752d63ac2@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
 <ePA2Co3SuIIkJZd1Ox5AvEr8bJIv8lOBEuV9CGiCQng=.977566d9-770a-4540-9cd5-4df752d63ac2@github.com>
Message-ID: <qe62sCjYtYECazfzkjgNZlnfj9yN1c7A2N8ATA_rgyE=.8b10ad22-70e5-461b-a138-9d5e0e58c792@github.com>

On Thu, 13 Jul 2023 07:46:00 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address suggestions from Jorn Vernee
>
> src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390CallArranger.java line 257:
> 
>> 255:     }
>> 256: 
>> 257:     // Compute recipe for transfering arguments / return values from C to Java.
> 
> typo: s/transfering/transferring

Fixed, Thanks @offamitkumar for pointing typos.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1279378873

From ysuenaga at openjdk.org  Mon Jul 31 15:09:09 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 31 Jul 2023 15:09:09 GMT
Subject: RFR: 8313406: nep_invoker_blob can be simplified more
Message-ID: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>

In FFM, native function would be called via `nep_invoker_blob`. If the function has two arguments, it would be following:


Decoding RuntimeStub - nep_invoker_blob 0x00007fcae394cd10
--------------------------------------------------------------------------------
  0x00007fcae394cd80: pushq %rbp
  0x00007fcae394cd81: movq %rsp, %rbp
  0x00007fcae394cd84: subq $0, %rsp
 ;; { argument shuffle
  0x00007fcae394cd88: movq %r8, %rax
  0x00007fcae394cd8b: movq %rsi, %r10
  0x00007fcae394cd8e: movq %rcx, %rsi
  0x00007fcae394cd91: movq %rdx, %rdi
 ;; } argument shuffle
  0x00007fcae394cd94: callq *%r10
  0x00007fcae394cd97: leave
  0x00007fcae394cd98: retq


`subq $0, %rsp` is for shadow space on stack, and `movq %r8, %rax` is number of args for variadic function. So they are not necessary in some case. They should be remove following if they are not needed:


Decoding RuntimeStub - nep_invoker_blob 0x00007fd8778e2810
--------------------------------------------------------------------------------
  0x00007fd8778e2880: pushq %rbp
  0x00007fd8778e2881: movq %rsp, %rbp
 ;; { argument shuffle
  0x00007fd8778e2884: movq %rsi, %r10
  0x00007fd8778e2887: movq %rcx, %rsi
  0x00007fd8778e288a: movq %rdx, %rdi
 ;; } argument shuffle
  0x00007fd8778e288d: callq *%r10
  0x00007fd8778e2890: leave
  0x00007fd8778e2891: retq


All java/foreign jtreg tests are passed.

We can see these stub code on [ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/examples/cpumodel) with `-XX:+UnlockDiagnosticVMOptions -XX:+PrintStubCode` and hsdis library. This testcase linked the code with `Linker.Option.isTrivial()`.

After this change, FFM performance on [another ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/benchmarks/funccall) was improved:

before:

Benchmark                           Mode  Cnt          Score          Error  Units
FuncCallComparison.invokeFFMRDTSC  thrpt    3  106664071.816 ? 14396524.718  ops/s
FuncCallComparison.rdtsc           thrpt    3  108024079.738 ? 13223921.011  ops/s


after:

Benchmark                           Mode  Cnt          Score          Error  Units
FuncCallComparison.invokeFFMRDTSC  thrpt    3  107622971.525 ? 12249767.134  ops/s
FuncCallComparison.rdtsc           thrpt    3  107695741.608 ? 23983281.346  ops/s


Environment:
* CPU: AMD Ryzen 3 3300X
* OS: Fedora 38 x86_64 (Kernel 6.3.8-200.fc38.x86_64)
* Hyper-V 4vCPU, 8GB mem

-------------

Commit messages:
 - 8313406: nep_invoker_blob can be simplified more

Changes: https://git.openjdk.org/jdk/pull/15089/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15089&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313406
  Stats: 41 lines in 3 files changed: 4 ins; 11 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/15089.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15089/head:pull/15089

PR: https://git.openjdk.org/jdk/pull/15089

From mchung at openjdk.org  Mon Jul 31 16:48:58 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 31 Jul 2023 16:48:58 GMT
Subject: [jdk21] RFR: 8300937: Update nroff pages in JDK 21 before RC
In-Reply-To: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
References: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
Message-ID: <Ka8_23z0VV93yF6loJ1RvpM37WznPRDQnonXsQVtUvc=.e6b134fc-7ada-4a2e-aeff-5dc02b8f956a@github.com>

On Mon, 31 Jul 2023 08:33:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Main changes are to use 21 instead of 21-ea. In addition the following files contain additional updates from the closed sources:
> 
> - src/java.base/share/man/java.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
>  [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
> 
> There are also some formatting differences related to:
> 
>  [JDK-8309670](https://bugs.openjdk.org/browse/JDK-8309670): java -help output for --module-path / -p is incomplete
> 
> Likely a different version of pandoc was used.
> 
> - src/java.base/share/man/keytool.1
> 
>  [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> 
> - src/jdk.compiler/share/man/javac.1
> 
>  [JDK-8308456](https://bugs.openjdk.org/browse/JDK-8308456): Update javac tool page for -proc:full
> 
> also some formatting differences.
> 
> - src/jdk.jartool/share/man/jarsigner.1
> 
>  [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> 
> - src/jdk.jcmd/share/man/jcmd.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
> 
> - src/jdk.jdeps/share/man/jdeps.1
> 
>  [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> - src/jdk.jfr/share/man/jfr.1
> 
> Formatting changes.
> 
> - src/jdk.jshell/share/man/jshell.1
> 
>  [JDK-8308988](https://bugs.openjdk.org/browse/JDK-8308988): Update JShell manpage to include TOOLING description

Changes in java and jdeps are good.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/151#pullrequestreview-1555334390

From mchung at openjdk.org  Mon Jul 31 16:52:46 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 31 Jul 2023 16:52:46 GMT
Subject: RFR: 8311989: Test java/lang/Thread/virtual/Reflection.java timed
 out
In-Reply-To: <d9lk2VG2kmsjDzSqc5AGPemSjpTF5uorW9NUNe9qCXo=.d607f40f-6e31-4b36-994c-21e7f26c7ad8@github.com>
References: <d9lk2VG2kmsjDzSqc5AGPemSjpTF5uorW9NUNe9qCXo=.d607f40f-6e31-4b36-994c-21e7f26c7ad8@github.com>
Message-ID: <1KLm1q_Ho_Kztv0LKU1hrT0ROmiYWEqimcNKOyDxBAg=.4da8dd49-b570-4d4c-8cf7-fb4168ffb125@github.com>

On Fri, 28 Jul 2023 15:44:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to a test that exercises core reflection from virtual threads. One of the tests (testNewInstance6) uses a custom scheduler in setup to check that calling a constructor reflectively, where the constructor parks, doesn't pin the underlying carrier. The test schedules an unpark from a virtual thread but the test is missing a call to Thread::join, thus creating a race between shutdown of the scheduler and the unpark. Two sightings of the test failing so far, both -Xcomp and ZGC.
> 
> While in the area, two usages of Thread.sleep in the test have been replaced with latches.

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15073#pullrequestreview-1555344119

From bpb at openjdk.org  Mon Jul 31 17:02:15 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 31 Jul 2023 17:02:15 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v4]
In-Reply-To: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
Message-ID: <MUpoHDGRKaAntNP0sxwe5aVOMIsxI9lx2rpueTydkRA=.35bd8851-78f5-4f77-872e-e0caaa86647d@github.com>

> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  6478546: do-while -> while-do in writeBytes; remove NULL and bounds checks in native

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14981/files
  - new: https://git.openjdk.org/jdk/pull/14981/files/92649751..cdb8455c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14981&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14981&range=02-03

  Stats: 39 lines in 3 files changed: 1 ins; 33 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14981.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14981/head:pull/14981

PR: https://git.openjdk.org/jdk/pull/14981

From iris at openjdk.org  Mon Jul 31 17:02:58 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 31 Jul 2023 17:02:58 GMT
Subject: [jdk21] RFR: 8300937: Update nroff pages in JDK 21 before RC
In-Reply-To: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
References: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
Message-ID: <IDTZVPoehnNAcfQAtY7KWm0s1jo7RMzhdttwdxoH6vI=.00094ef1-8a19-4884-b3f4-cd8ffb3e40e9@github.com>

On Mon, 31 Jul 2023 08:33:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Main changes are to use 21 instead of 21-ea. In addition the following files contain additional updates from the closed sources:
> 
> - src/java.base/share/man/java.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
>  [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
> 
> There are also some formatting differences related to:
> 
>  [JDK-8309670](https://bugs.openjdk.org/browse/JDK-8309670): java -help output for --module-path / -p is incomplete
> 
> Likely a different version of pandoc was used.
> 
> - src/java.base/share/man/keytool.1
> 
>  [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> 
> - src/jdk.compiler/share/man/javac.1
> 
>  [JDK-8308456](https://bugs.openjdk.org/browse/JDK-8308456): Update javac tool page for -proc:full
> 
> also some formatting differences.
> 
> - src/jdk.jartool/share/man/jarsigner.1
> 
>  [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> 
> - src/jdk.jcmd/share/man/jcmd.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
> 
> - src/jdk.jdeps/share/man/jdeps.1
> 
>  [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> - src/jdk.jfr/share/man/jfr.1
> 
> Formatting changes.
> 
> - src/jdk.jshell/share/man/jshell.1
> 
>  [JDK-8308988](https://bugs.openjdk.org/browse/JDK-8308988): Update JShell manpage to include TOOLING description

Looks good.

The flow changes are unfortunate, but a tool update has the potential to have far more wide-spread changes.  I'm happy that's all there was.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/151#pullrequestreview-1555365638

From rgiulietti at openjdk.org  Mon Jul 31 17:15:13 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 31 Jul 2023 17:15:13 GMT
Subject: RFR: 8312976: MatchResult produces StringIndexOutOfBoundsException
 for groups outside match [v2]
In-Reply-To: <x8ghNv-MsXGwtDhqgBCPbXQFGLTr3x0cWa4qUapadhY=.fa9e7f4f-744f-44aa-85c6-495a76eb2388@github.com>
References: <x8ghNv-MsXGwtDhqgBCPbXQFGLTr3x0cWa4qUapadhY=.fa9e7f4f-744f-44aa-85c6-495a76eb2388@github.com>
Message-ID: <NlYv4RrCKkapiS-ZQRPenQOHaefXMAcIlFUNuMOnXgk=.6346c137-57ac-43e2-b6fc-e0046ac1f846@github.com>

> Fixes a bug showing up after [JDK-8132995](https://bugs.openjdk.org/browse/JDK-8132995) when there are capturing groups outside the match.

Raffaello Giulietti has updated the pull request incrementally with two additional commits since the last revision:

 - Added a test with negatvie lookbehind.
 - Added test with a lookahead containing a back reference.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15053/files
  - new: https://git.openjdk.org/jdk/pull/15053/files/8c737329..2b164c87

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15053&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15053&range=00-01

  Stats: 75 lines in 1 file changed: 75 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15053.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15053/head:pull/15053

PR: https://git.openjdk.org/jdk/pull/15053

From rgiulietti at openjdk.org  Mon Jul 31 17:32:12 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 31 Jul 2023 17:32:12 GMT
Subject: RFR: 8312976: MatchResult produces StringIndexOutOfBoundsException
 for groups outside match [v3]
In-Reply-To: <x8ghNv-MsXGwtDhqgBCPbXQFGLTr3x0cWa4qUapadhY=.fa9e7f4f-744f-44aa-85c6-495a76eb2388@github.com>
References: <x8ghNv-MsXGwtDhqgBCPbXQFGLTr3x0cWa4qUapadhY=.fa9e7f4f-744f-44aa-85c6-495a76eb2388@github.com>
Message-ID: <F9kXHdajibdHpyYIFOcb1bTOfK4OIJ9vMBdsGSm5i_M=.bdede21c-3195-4c2c-aa3c-f1a674e37e96@github.com>

> Fixes a bug showing up after [JDK-8132995](https://bugs.openjdk.org/browse/JDK-8132995) when there are capturing groups outside the match.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Refactored recent tests as JUnit parametrized test.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15053/files
  - new: https://git.openjdk.org/jdk/pull/15053/files/2b164c87..49fb4f14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15053&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15053&range=01-02

  Stats: 81 lines in 1 file changed: 4 ins; 66 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/15053.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15053/head:pull/15053

PR: https://git.openjdk.org/jdk/pull/15053

From rriggs at openjdk.org  Mon Jul 31 18:15:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 31 Jul 2023 18:15:51 GMT
Subject: RFR: 8313312: Add missing classpath exception copyright header
 [v2]
In-Reply-To: <cwVvcKK4X92FDntRJg9Iv3NuPvUAaybTDLrp6G1L6To=.0f1c62ab-b8cc-4df2-8157-4445fb1aa49c@github.com>
References: <9ZKXDEMzNF_XPzgzsXYskRSuM4pLj1zBVQUU8YONVqE=.e14017a2-cd82-4abd-8b72-d096a3fce69f@github.com>
 <cwVvcKK4X92FDntRJg9Iv3NuPvUAaybTDLrp6G1L6To=.0f1c62ab-b8cc-4df2-8157-4445fb1aa49c@github.com>
Message-ID: <XEXOHZdjoQoCXitVeXIB06u99fCl-1eN7tNGdnpAHVc=.b185f379-564c-45bc-b58a-4eae8832cc23@github.com>

On Fri, 28 Jul 2023 17:39:18 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Adds `classpath exception` in multiple files, affects copyright header only.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert java.lang.foreign changes

Since we're past RPD2, this will need approval before this can be included.
(This is not just code review, but review from the Group and area leads)

Please re-read, JEP 3: https://openjdk.org/jeps/3#Bug-Deferral-Process
and on down the "Fix Request" process.

Please change the bug priority to P2; that is needed to be considered.

Add a comment as described headlined with "Fix Request" and the described rationale and information.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15070#issuecomment-1658909687

From rgiulietti at openjdk.org  Mon Jul 31 18:38:30 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 31 Jul 2023 18:38:30 GMT
Subject: RFR: 8312976: MatchResult produces StringIndexOutOfBoundsException
 for groups outside match [v4]
In-Reply-To: <x8ghNv-MsXGwtDhqgBCPbXQFGLTr3x0cWa4qUapadhY=.fa9e7f4f-744f-44aa-85c6-495a76eb2388@github.com>
References: <x8ghNv-MsXGwtDhqgBCPbXQFGLTr3x0cWa4qUapadhY=.fa9e7f4f-744f-44aa-85c6-495a76eb2388@github.com>
Message-ID: <dAlKckz0TgbCEaRYNsXhCMiAKpneG6SfYqQ3Zvfb1AQ=.ad6300a0-f3ca-4ac4-af6d-7b0e72e37b07@github.com>

> Fixes a bug showing up after [JDK-8132995](https://bugs.openjdk.org/browse/JDK-8132995) when there are capturing groups outside the match.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merged with mainline.
 - Merge branch 'master' into 8312976
 - Refactored recent tests as JUnit parametrized test.
 - Added a test with negatvie lookbehind.
 - Added test with a lookahead containing a back reference.
 - 8312976: MatchResult produces StringIndexOutOfBoundsException for groups outside match

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15053/files
  - new: https://git.openjdk.org/jdk/pull/15053/files/49fb4f14..f117745d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15053&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15053&range=02-03

  Stats: 41398 lines in 860 files changed: 23399 ins; 14058 del; 3941 mod
  Patch: https://git.openjdk.org/jdk/pull/15053.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15053/head:pull/15053

PR: https://git.openjdk.org/jdk/pull/15053

From egahlin at openjdk.org  Mon Jul 31 18:51:50 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 31 Jul 2023 18:51:50 GMT
Subject: [jdk21] RFR: 8300937: Update nroff pages in JDK 21 before RC
In-Reply-To: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
References: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
Message-ID: <9NqTSNFI28Ew52fVBR40-QdAioWNizm9lnuMHr8hVoo=.0f709ec1-8ec2-4e6e-a30c-f69f2026200b@github.com>

On Mon, 31 Jul 2023 08:33:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Main changes are to use 21 instead of 21-ea. In addition the following files contain additional updates from the closed sources:
> 
> - src/java.base/share/man/java.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
>  [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
> 
> There are also some formatting differences related to:
> 
>  [JDK-8309670](https://bugs.openjdk.org/browse/JDK-8309670): java -help output for --module-path / -p is incomplete
> 
> Likely a different version of pandoc was used.
> 
> - src/java.base/share/man/keytool.1
> 
>  [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> 
> - src/jdk.compiler/share/man/javac.1
> 
>  [JDK-8308456](https://bugs.openjdk.org/browse/JDK-8308456): Update javac tool page for -proc:full
> 
> also some formatting differences.
> 
> - src/jdk.jartool/share/man/jarsigner.1
> 
>  [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> 
> - src/jdk.jcmd/share/man/jcmd.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
> 
> - src/jdk.jdeps/share/man/jdeps.1
> 
>  [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> - src/jdk.jfr/share/man/jfr.1
> 
> Formatting changes.
> 
> - src/jdk.jshell/share/man/jshell.1
> 
>  [JDK-8308988](https://bugs.openjdk.org/browse/JDK-8308988): Update JShell manpage to include TOOLING description

Marked as reviewed by egahlin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/151#pullrequestreview-1555541442

From jlaskey at openjdk.org  Mon Jul 31 19:14:04 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Jul 2023 19:14:04 GMT
Subject: Integrated: 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: <l2lzCfmm_jU7c5hQvNaNHP2OQsVOuWF1ccwkbbWZrxU=.d4811b1c-cbd4-4369-b394-bdc3de2844ae@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.

This pull request has now been integrated.

Changeset: 6af0af59
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6af0af593446bc33dc94bbf7334c325c4ac0ac0f
Stats:     1520 lines in 13 files changed: 887 ins; 625 del; 8 mod

8310913: Move ReferencedKeyMap to jdk.internal so it may be shared

Reviewed-by: naoto, rriggs, mchung, liach

-------------

PR: https://git.openjdk.org/jdk/pull/14684

From iris.clark at oracle.com  Mon Jul 31 20:00:07 2023
From: iris.clark at oracle.com (Iris Clark)
Date: Mon, 31 Jul 2023 20:00:07 +0000
Subject: CFV: New Core Libraries Group Member: Brian Burkhalter
In-Reply-To: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
References: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
Message-ID: <SJ0PR10MB5440F0C59F775AA2BEBB781FFB05A@SJ0PR10MB5440.namprd10.prod.outlook.com>

Vote: yes

Thanks,
Iris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230731/f27d08a3/attachment.htm>

From rriggs at openjdk.org  Mon Jul 31 20:00:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 31 Jul 2023 20:00:06 GMT
Subject: [jdk21] RFR: 8310033: Clarify return value of Java Time compareTo
 methods
Message-ID: <ADJwWmHwN83osnGnw5-abEHQVIXAxAGpE1R2gBbCCbQ=.97f06961-5231-430c-a545-d75821ab2f19@github.com>

A doc-only change to improve javadoc in java.time.

-------------

Commit messages:
 - Backport 8650026ff16e5c5eff897f9fd39c0c35fd8b7367

Changes: https://git.openjdk.org/jdk21/pull/153/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=153&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310033
  Stats: 84 lines in 17 files changed: 49 ins; 0 del; 35 mod
  Patch: https://git.openjdk.org/jdk21/pull/153.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/153/head:pull/153

PR: https://git.openjdk.org/jdk21/pull/153

From iris.clark at oracle.com  Mon Jul 31 20:01:01 2023
From: iris.clark at oracle.com (Iris Clark)
Date: Mon, 31 Jul 2023 20:01:01 +0000
Subject: CFV: New Core Libraries Group Member: Brent Christian
In-Reply-To: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
References: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
Message-ID: <SJ0PR10MB5440659CB80DAB09B5E8E630FB05A@SJ0PR10MB5440.namprd10.prod.outlook.com>

Vote: yes

Thanks,
Iris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230731/e5dfed9c/attachment-0001.htm>

From iris.clark at oracle.com  Mon Jul 31 20:02:14 2023
From: iris.clark at oracle.com (Iris Clark)
Date: Mon, 31 Jul 2023 20:02:14 +0000
Subject: CFV: New Core Libraries Group Member: Joe Wang
In-Reply-To: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
References: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
Message-ID: <SJ0PR10MB5440D0522BC2353250B6D409FB05A@SJ0PR10MB5440.namprd10.prod.outlook.com>

Vote: yes

Thanks,
Iris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230731/1a51137b/attachment.htm>

From jvernee at openjdk.org  Mon Jul 31 20:20:52 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 31 Jul 2023 20:20:52 GMT
Subject: RFR: 8313406: nep_invoker_blob can be simplified more
In-Reply-To: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
References: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
Message-ID: <93nYmphakiPBp8Ic0LCAfmQSlXanw2Aif6QdPUCP3Hc=.f31f5dbb-4a12-4175-b5c6-78533193930a@github.com>

On Mon, 31 Jul 2023 12:22:00 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> In FFM, native function would be called via `nep_invoker_blob`. If the function has two arguments, it would be following:
> 
> 
> Decoding RuntimeStub - nep_invoker_blob 0x00007fcae394cd10
> --------------------------------------------------------------------------------
>   0x00007fcae394cd80: pushq %rbp
>   0x00007fcae394cd81: movq %rsp, %rbp
>   0x00007fcae394cd84: subq $0, %rsp
>  ;; { argument shuffle
>   0x00007fcae394cd88: movq %r8, %rax
>   0x00007fcae394cd8b: movq %rsi, %r10
>   0x00007fcae394cd8e: movq %rcx, %rsi
>   0x00007fcae394cd91: movq %rdx, %rdi
>  ;; } argument shuffle
>   0x00007fcae394cd94: callq *%r10
>   0x00007fcae394cd97: leave
>   0x00007fcae394cd98: retq
> 
> 
> `subq $0, %rsp` is for shadow space on stack, and `movq %r8, %rax` is number of args for variadic function. So they are not necessary in some case. They should be remove following if they are not needed:
> 
> 
> Decoding RuntimeStub - nep_invoker_blob 0x00007fd8778e2810
> --------------------------------------------------------------------------------
>   0x00007fd8778e2880: pushq %rbp
>   0x00007fd8778e2881: movq %rsp, %rbp
>  ;; { argument shuffle
>   0x00007fd8778e2884: movq %rsi, %r10
>   0x00007fd8778e2887: movq %rcx, %rsi
>   0x00007fd8778e288a: movq %rdx, %rdi
>  ;; } argument shuffle
>   0x00007fd8778e288d: callq *%r10
>   0x00007fd8778e2890: leave
>   0x00007fd8778e2891: retq
> 
> 
> All java/foreign jtreg tests are passed.
> 
> We can see these stub code on [ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/examples/cpumodel) with `-XX:+UnlockDiagnosticVMOptions -XX:+PrintStubCode` and hsdis library. This testcase linked the code with `Linker.Option.isTrivial()`.
> 
> After this change, FFM performance on [another ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/benchmarks/funccall) was improved:
> 
> before:
> 
> Benchmark                           Mode  Cnt          Score          Error  Units
> FuncCallComparison.invokeFFMRDTSC  thrpt    3  106664071.816 ? 14396524.718  ops/s
> FuncCallComparison.rdtsc           thrpt    3  108024079.738 ? 13223921.011  ops/s
> 
> 
> after:
> 
> Benchmark                           Mode  Cnt          Score          Error  Units
> FuncCallComparison.invokeFFMRDTSC  thrpt    3  107622971.525 ? 12249767.134  ops/s
> FuncCallComparison.rdtsc           thrpt    3  107695741.608 ? 23983281.346  ops/s
> 
> 
> Environment:
> * CPU: AMD Ryzen 3 3300X
> * OS: Fedora 38 x86_64 (Kernel 6.3.8-200.fc38.x86_64)
> * Hyper-V 4vCPU, 8GB mem

This looks good. I'm running tests in our CI.

> After this change, FFM performance on [another ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/benchmarks/funccall) was improved:

If you consider the 'error' in those benchmarks, only the first 2 digits of the throughput are significant, so I don't think we can claim that this improves performance base on these numbers alone.

However, I think the improvement in code quality is also a plus, just for making things easier to read/understand. I think these changes are non-invasive, and IIRC in the past we've always set RAX mostly since the code shape at that time didn't allow us to avoid it easily. So, I'm okay with this patch.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15089#pullrequestreview-1555707138

From naoto at openjdk.org  Mon Jul 31 20:40:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 31 Jul 2023 20:40:48 GMT
Subject: [jdk21] RFR: 8310033: Clarify return value of Java Time compareTo
 methods
In-Reply-To: <ADJwWmHwN83osnGnw5-abEHQVIXAxAGpE1R2gBbCCbQ=.97f06961-5231-430c-a545-d75821ab2f19@github.com>
References: <ADJwWmHwN83osnGnw5-abEHQVIXAxAGpE1R2gBbCCbQ=.97f06961-5231-430c-a545-d75821ab2f19@github.com>
Message-ID: <YNFjgL6cFfLUV_w3kiF1hXDIhGUW34t8Zl8aWHtAxOc=.8bf5d185-35fc-416b-9233-4b68da2bb8c4@github.com>

On Mon, 31 Jul 2023 19:48:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> A doc-only change to improve javadoc in java.time.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/153#pullrequestreview-1555741239

From alanb at openjdk.org  Mon Jul 31 20:48:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 31 Jul 2023 20:48:45 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v4]
In-Reply-To: <JNmxvM9LYO3qt1Eccce9fX3f2_9s7FzDEGNZHlaVQ88=.05986efe-f203-4b64-bb33-7f4db762773b@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
 <JNmxvM9LYO3qt1Eccce9fX3f2_9s7FzDEGNZHlaVQ88=.05986efe-f203-4b64-bb33-7f4db762773b@github.com>
Message-ID: <WPC9FJ4m70bcPPfRTaJRufAngzxlBnSRFmRh0xKY_BY=.ad3cdcc9-9950-4663-91e3-e5598ce2c691@github.com>

On Thu, 27 Jul 2023 19:09:00 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 
>> 
>> 
>>  // We have finished dumping the static archive. At this point, there may be pending VM
>>  // operations. We have changed some global states (such as vmClasses::_klasses) that
>>  // may cause these VM operations to fail. For safety, forget these operations and
>>  // exit the VM directly.
>>  void MetaspaceShared::exit_after_static_dump() {
>>    os::_exit(0);
>>  } 
>> 
>> 
>> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
>> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
>> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
>> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.
>> 
>> Verified with tier 1-9 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ioi comments

Updated launcher change looks fine.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14879#pullrequestreview-1555751362

From stuart.marks at oracle.com  Mon Jul 31 21:09:05 2023
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 31 Jul 2023 14:09:05 -0700
Subject: CFV: New Core Libraries Group Member: Brian Burkhalter
In-Reply-To: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
References: <37c50873-cfd5-fa7e-4533-299e91f6ca02@oracle.com>
Message-ID: <8321daa8-a9a0-8b57-63bd-3b4d32917d6b@oracle.com>

Vote: yes

On 7/27/23 11:35 AM, Roger Riggs wrote:
> |I hereby nominate |Brian Burkhalter|to Membership in the Core Libraries Group Brian has been working in the Core 
> Library team since 2012. Brian's many contributions to the OpenJDK libraries include 
> java.io subsystems, NIO channels, files, and buffers. He applies his background in 
> math and image processing to OpenJDK development. ||Previously, he led JavaFX Media team. Co-designed and implemented successor Java 
> audio and video playback and recording API using GStreamer, AV Foundation, and 
> libav. Votes are due by August 11th, 2023. Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. Votes must be 
> cast in the open by replying to this mailing list For Lazy Consensus voting 
> instructions, see [2]. Roger Riggs [1] https://openjdk.org/census#core-libs [2] 
> https://openjdk.org/groups/#member-vote|
> 

From stuart.marks at oracle.com  Mon Jul 31 21:09:31 2023
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 31 Jul 2023 14:09:31 -0700
Subject: CFV: New Core Libraries Group Member: Joe Wang
In-Reply-To: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
References: <6ba2bd5e-8699-57ba-8a5c-c44b07c792a8@oracle.com>
Message-ID: <0c2048cb-5084-f1c6-2860-343088dd9a92@oracle.com>

Vote: yes

On 7/27/23 11:36 AM, Roger Riggs wrote:
> |I hereby nominate Joe Wang||to Membership in the Core Libraries Group Joe has been working in the core library 
> team since 2012. He has been maintaining and improving the XML library APIs and 
> implementations including ||DOM, SAX, StAX, Transform, Validation, XPath and Catalog. Recently he has been 
> updating and improving XML Security. Votes are due by August 11th, 2023. Only 
> current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. Votes must be 
> cast in the open by replying to this mailing list For Lazy Consensus voting 
> instructions, see [2]. Roger Riggs [1] https://openjdk.org/census#core-libs [2] 
> https://openjdk.org/groups/#member-vote|
> 

From stuart.marks at oracle.com  Mon Jul 31 21:09:53 2023
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 31 Jul 2023 14:09:53 -0700
Subject: CFV: New Core Libraries Group Member: Brent Christian
In-Reply-To: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
References: <761a3fc1-aa64-af05-77be-dc96e54fbb47@oracle.com>
Message-ID: <58e27030-3a5c-b516-57fc-c5a80dc0e533@oracle.com>

Vote: yes

On 7/27/23 11:36 AM, Roger Riggs wrote:
> |I hereby nominate |Brent Christian|to Membership in the Core Libraries Group Brent has been working in the Core 
> Library team at Oracle since 2012. He has made contributions to many areas of 
> OpenJDK including java.lang strings, class loader, NIO Jar, and many more. Most 
> recently he has been working on steps to deprecate and phase out finalization.|
> ||Previously he worked on OpenJDK AWT, Swing, and JavaFX before joining the Core 
> Libraries group.| Votes are due by August 11th, 2023. Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. Votes must be 
> cast in the open by replying to this mailing list For Lazy Consensus voting 
> instructions, see [2]. Roger Riggs [1] https://openjdk.org/census#core-libs [2] 
> https://openjdk.org/groups/#member-vote|
> 

From dholmes at openjdk.org  Mon Jul 31 21:13:04 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Jul 2023 21:13:04 GMT
Subject: [jdk21] Integrated: 8300937: Update nroff pages in JDK 21 before RC
In-Reply-To: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
References: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
Message-ID: <CmpiBFKECHa2MW7JqbiBo7dLDr_HgLSwsIUwHl1DsRw=.a6c3df50-b0c2-492d-973f-83defe84514a@github.com>

On Mon, 31 Jul 2023 08:33:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Main changes are to use 21 instead of 21-ea. In addition the following files contain additional updates from the closed sources:
> 
> - src/java.base/share/man/java.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
>  [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
> 
> There are also some formatting differences related to:
> 
>  [JDK-8309670](https://bugs.openjdk.org/browse/JDK-8309670): java -help output for --module-path / -p is incomplete
> 
> Likely a different version of pandoc was used.
> 
> - src/java.base/share/man/keytool.1
> 
>  [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> 
> - src/jdk.compiler/share/man/javac.1
> 
>  [JDK-8308456](https://bugs.openjdk.org/browse/JDK-8308456): Update javac tool page for -proc:full
> 
> also some formatting differences.
> 
> - src/jdk.jartool/share/man/jarsigner.1
> 
>  [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> 
> - src/jdk.jcmd/share/man/jcmd.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
> 
> - src/jdk.jdeps/share/man/jdeps.1
> 
>  [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> - src/jdk.jfr/share/man/jfr.1
> 
> Formatting changes.
> 
> - src/jdk.jshell/share/man/jshell.1
> 
>  [JDK-8308988](https://bugs.openjdk.org/browse/JDK-8308988): Update JShell manpage to include TOOLING description

This pull request has now been integrated.

Changeset: 0439d584
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/0439d584221f4d92fd1f4097a331f83dcdb2c12c
Stats:     163 lines in 28 files changed: 37 ins; 60 del; 66 mod

8300937: Update nroff pages in JDK 21 before RC

Reviewed-by: mchung, iris, egahlin

-------------

PR: https://git.openjdk.org/jdk21/pull/151

From dholmes at openjdk.org  Mon Jul 31 21:13:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Jul 2023 21:13:03 GMT
Subject: [jdk21] RFR: 8300937: Update nroff pages in JDK 21 before RC
In-Reply-To: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
References: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
Message-ID: <Ksw1iyNt46vuKnXO6vAKBi1F1nBZQTCyYlahDuhFwPw=.c6de8a61-0add-4be7-b8ed-3f6e65f9a164@github.com>

On Mon, 31 Jul 2023 08:33:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Main changes are to use 21 instead of 21-ea. In addition the following files contain additional updates from the closed sources:
> 
> - src/java.base/share/man/java.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
>  [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
> 
> There are also some formatting differences related to:
> 
>  [JDK-8309670](https://bugs.openjdk.org/browse/JDK-8309670): java -help output for --module-path / -p is incomplete
> 
> Likely a different version of pandoc was used.
> 
> - src/java.base/share/man/keytool.1
> 
>  [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> 
> - src/jdk.compiler/share/man/javac.1
> 
>  [JDK-8308456](https://bugs.openjdk.org/browse/JDK-8308456): Update javac tool page for -proc:full
> 
> also some formatting differences.
> 
> - src/jdk.jartool/share/man/jarsigner.1
> 
>  [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> 
> - src/jdk.jcmd/share/man/jcmd.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
> 
> - src/jdk.jdeps/share/man/jdeps.1
> 
>  [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> - src/jdk.jfr/share/man/jfr.1
> 
> Formatting changes.
> 
> - src/jdk.jshell/share/man/jshell.1
> 
>  [JDK-8308988](https://bugs.openjdk.org/browse/JDK-8308988): Update JShell manpage to include TOOLING description

Thanks for the reviews everyone.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/151#issuecomment-1659164663

From jlu at openjdk.org  Mon Jul 31 21:20:59 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 31 Jul 2023 21:20:59 GMT
Subject: [jdk21] RFR: 8039165: [Doc] MessageFormat null locale generates
 NullPointerException
Message-ID: <JEUry7Jy_iEpNIjBbBKwX6M6K93nKGnSxPd0AiaJryk=.b394e6cf-9791-4279-931d-02507dbf9fa8@github.com>

Please review this change which contains a backport of commit [c6396dce](https://github.com/openjdk/jdk/commit/c6396dceb9a64578d5b335af27ad1d968190a1fa) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

This PR is a java.text doc/test-only change.

The commit being backported was authored by Justin Lu on 25 Jul 2023 and was reviewed by Naoto Sato.

Thanks!

-------------

Commit messages:
 - Backport c6396dceb9a64578d5b335af27ad1d968190a1fa

Changes: https://git.openjdk.org/jdk21/pull/154/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=154&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8039165
  Stats: 164 lines in 3 files changed: 97 ins; 64 del; 3 mod
  Patch: https://git.openjdk.org/jdk21/pull/154.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/154/head:pull/154

PR: https://git.openjdk.org/jdk21/pull/154

From naoto at openjdk.org  Mon Jul 31 21:29:56 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 31 Jul 2023 21:29:56 GMT
Subject: [jdk21] RFR: 8039165: [Doc] MessageFormat null locale generates
 NullPointerException
In-Reply-To: <JEUry7Jy_iEpNIjBbBKwX6M6K93nKGnSxPd0AiaJryk=.b394e6cf-9791-4279-931d-02507dbf9fa8@github.com>
References: <JEUry7Jy_iEpNIjBbBKwX6M6K93nKGnSxPd0AiaJryk=.b394e6cf-9791-4279-931d-02507dbf9fa8@github.com>
Message-ID: <rGO2QeiL9_IzjuSHcx8ojegiGNCJ5gAjNYPZTu24r0Q=.e3822510-3e48-4a98-aad1-ca60b53c623b@github.com>

On Mon, 31 Jul 2023 21:13:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this change which contains a backport of commit [c6396dce](https://github.com/openjdk/jdk/commit/c6396dceb9a64578d5b335af27ad1d968190a1fa) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This PR is a java.text doc/test-only change.
> 
> The commit being backported was authored by Justin Lu on 25 Jul 2023 and was reviewed by Naoto Sato.
> 
> Thanks!

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/154#pullrequestreview-1555801280