From iris at openjdk.org  Sat Apr  1 02:51:21 2023
From: iris at openjdk.org (Iris Clark)
Date: Sat, 1 Apr 2023 02:51:21 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v3]
In-Reply-To: <AzM9yIt0ic_LC_pI2Qi4oVMumARhGVjLVNoAM53uT28=.2d9a6869-38b8-421a-99c8-7e2155e8701b@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <AzM9yIt0ic_LC_pI2Qi4oVMumARhGVjLVNoAM53uT28=.2d9a6869-38b8-421a-99c8-7e2155e8701b@github.com>
Message-ID: <9xeOR9nFP1Pv9OxHLOkbzYTOjIkJxOZnB9M4zKAxJgU=.1d896a82-0139-434b-a6a3-ce4650914727@github.com>

On Fri, 31 Mar 2023 22:07:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert removing @see tags where the URL was not the same as the @spec URL

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1367798667

From qamai at openjdk.org  Sat Apr  1 07:44:25 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 1 Apr 2023 07:44:25 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v4]
In-Reply-To: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
Message-ID: <Hb8JZTxmiXR9lC0wUf7mPzDa3gcoTMQfsbqrZuu-UBk=.f8e1d2c5-86eb-4ce8-a57d-84be5d6733c4@github.com>

> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
> 
> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
> 
> Please take a look and have some reviews. Thank you very much.

Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - instruction asserts
 - Merge branch 'master' into sliceIntrinsics
 - add comments explaining anonymous classes
 - address reviews
 - sse2, increase warmup
 - aesthetic
 - optimise 64B
 - add jmh
 - vector slice intrinsics

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

Changes: https://git.openjdk.org/jdk/pull/12909/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12909&range=03
  Stats: 1603 lines in 58 files changed: 1277 ins; 257 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/12909.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12909/head:pull/12909

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

From chegar999 at gmail.com  Sat Apr  1 10:02:31 2023
From: chegar999 at gmail.com (Chris Hegarty)
Date: Sat, 1 Apr 2023 11:02:31 +0100
Subject: The non-deterministic iteration order of Immutable Collections
In-Reply-To: <39ceb9e6-3681-13f4-4fa3-b9e298203a70@oracle.com>
References: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
 <39ceb9e6-3681-13f4-4fa3-b9e298203a70@oracle.com>
Message-ID: <6dd0f90a-f4c3-df5a-e2b5-dcefc1d22ea6@gmail.com>

Hi Stuart,

First, thanks for you detailed reply.

On 25/03/2023 00:16, Stuart Marks wrote:
> ...
> 
> Yes, this has come up before, but it's been mostly theoretical. That is, 
> people worry about this when they hear of the idea of randomized 
> iteration order, but I've never heard any followup. This is in fact the 
> first time I've heard of an actual case where this is a real problem. So 
> thanks for bringing it up.

Here is a link to the GH issue has some more details, and links to 
further issues and PR's.

https://github.com/elastic/elasticsearch/issues/94946

> (And unfortunately, it's notoriously difficult to make code truly 
> iteration-order dependent. We've had our own history of problems with 
> this in the JDK. I'd be interested in hearing from you at some point 
> about the exact pathology of how this occurred.)
> 
> There's currently no debugging or experimental interface that will let 
> one print or set the random seed that's in use. The obvious approach of 
> using an agent to hack away at runtime doesn't work, because the 
> unmodifiable collections implementations are used very early in startup 
> and they're usually loaded before the agent runs. There are limitations 
> on what an agent can do when redefining an already-loaded class, for 
> example, removing the 'final' modifier from fields isn't supported. 
> (Well I suppose one can always use Unsafe.)

Yes, unfortunately that is one of the options that we're considering :-(

> Here's another approach that might work for you.
> 
> 1. Write a little program that extracts the class bytes of 
> ImmutableCollection.class from the runtime image, and use something like 
> ASM or ClassFile to make the class public and to make the REVERSE and 
> SALT32L fields public and non-final.
> 
> 2. Launch a VM using the --patch-module option to use this class instead 
> of the built-in one.
> 
> 3. Write an agent, or some debugging library that's called at the right 
> time, to use simple reflective access to get or set those fields as 
> desired.
> 
> This is a bit fiddly but it might be easier than rebuilding and 
> deploying a custom JDK.

Yes, certainly a bit fiddly, and maybe a little fragile - we currently 
support compiling on JDK 17, with a strong preference of running on the 
latest JDK ( currently JDK 20 ). It could be that we'd need to maintain 
a version of this for 17 through 20 ( and 21, as we test with EA builds 
of 21 ).

> Setting (formerly) final fields after the VM is initialized is often 
> somewhat risky. In this case these particular fields are used only 
> during iteration, and they don't actually change the layout of any data 
> structures. So setting them to some desired value should apply to all 
> subsequent iterations, even of existing data structures.
> 
> I'll think about better ways to do this in the product. The best 
> approach isn't obvious. The typical way of doing things like this using 
> system properties is tricky, as it depends on order of class 
> initialization at startup (and you know how fragile that is).

Yeah, the set of possible solutions is somewhat curtailed, but "the 
simpler the better"! ;-)  Something like a system property would be 
"good enough", if the initialization order could be enforced.

Thanks,
-Chris.


From darcy at openjdk.org  Sat Apr  1 17:41:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 1 Apr 2023 17:41:23 GMT
Subject: RFR: JDK-8304945: StringBuilder and StringBuffer should implement
 Appendable explicitly
Message-ID: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>

The StringBuilder and StringBuffer classes are Appendable by virtue of from subclasses their non-public superclass AbstractStringBuilder.

It is slightly clearer to declare StringBuilder and StringBuffer to directly implement Appendable, as they already directly implement the CharSequence interface also implemented by their superclass.

There are no other interfaces implemented by AbstractStringBuilder other than Appendable and CharSequence.

Please also review the CSR https://bugs.openjdk.org/browse/JDK-8305408

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

Commit messages:
 - JDK-8304945: StringBuilder and StringBuffer should implement Appendable explicitly

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

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

From darcy at openjdk.org  Sat Apr  1 18:15:16 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 1 Apr 2023 18:15:16 GMT
Subject: RFR: JDK-8303798: REDO - Remove fdlibm C sources
Message-ID: <VDk-pjTiTr7BFWxpbV22_MjjCRh7mEvxkBVbH0sARYM=.747e3f9d-626d-43c7-8da8-2f5c7c2c821d@github.com>

This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with JDK-8302801 was that it neglected (mea culpa) to include a Java implementation of IEEEremainder before the FDLIBM C implementation was deleted. Such an implementation has been successfully provided under JDK-8304028: Port fdlibm IEEEremainder to Java. After JDK-8304028, there are no native methods left in StrictMath.

This PR is the same as JDK-8302801 other than StrictMath.c already being removed under JDK-8304028.

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

Commit messages:
 - JDK-8303798: REDO - Remove fdlibm C sources

Changes: https://git.openjdk.org/jdk/pull/13279/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13279&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303798
  Stats: 6516 lines in 64 files changed: 20 ins; 6486 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13279.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13279/head:pull/13279

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

From jwaters at openjdk.org  Sun Apr  2 06:33:28 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 2 Apr 2023 06:33:28 GMT
Subject: RFR: 8305341: Alignment outside of HotSpot should be enforced by
 alignas instead of compiler specific attributes
In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
Message-ID: <8aU00n6Ts6blnBchhfbMycW_iAh1mX0Tv-breuukQto=.2c3d8810-c75f-427e-8fc3-436a89f63b79@github.com>

On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

I don't think I can touch the freetype code since I think it's an external library that was imported. HotSpot requires a special review for changes like this, so it's not done here, but instead at https://github.com/openjdk/jdk/pull/11431 (Which has dried up for a long time now, would be great if someone finally looked at that PR...)

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

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1493242732

From jwaters at openjdk.org  Sun Apr  2 06:37:19 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 2 Apr 2023 06:37:19 GMT
Subject: RFR: 8305341: Alignment outside of HotSpot should be enforced by
 alignas instead of compiler specific attributes
In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
Message-ID: <gBEfGwo_ZXOxhUUVjcE4Jld_AuDmZETuPvvuMakI81U=.dda832f7-3f92-40a6-9a4c-b42d6fc9f137@github.com>

On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

Just checked, the pragmas in the freetype code now seems to be pointless since there is no alignment specified in the code it's supposed to guard. Maybe upstream will fix this someday :/

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

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1493245182

From alanb at openjdk.org  Sun Apr  2 06:48:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 2 Apr 2023 06:48:26 GMT
Subject: RFR: JDK-8304945: StringBuilder and StringBuffer should implement
 Appendable explicitly
In-Reply-To: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
References: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
Message-ID: <jwwds1V7jHXE-sxIEQ9t95p3syrEnuJT2ok44v3wpMA=.504f0186-60b1-4e04-bb62-182623191d02@github.com>

On Sat, 1 Apr 2023 17:34:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The StringBuilder and StringBuffer classes are Appendable by virtue of from subclasses their non-public superclass AbstractStringBuilder.
> 
> It is slightly clearer to declare StringBuilder and StringBuffer to directly implement Appendable, as they already directly implement the CharSequence interface also implemented by their superclass.
> 
> There are no other interfaces implemented by AbstractStringBuilder other than Appendable and CharSequence.
> 
> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8305408

Right now, the javadoc for SB lists Appendable in the "All Implemented Interfaces" list. With this change it will be shown in the class declaration in the list of "implements" list. Make sense.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13278#pullrequestreview-1368029581

From duke at openjdk.org  Sun Apr  2 07:18:18 2023
From: duke at openjdk.org (M4ximumPizza)
Date: Sun, 2 Apr 2023 07:18:18 GMT
Subject: RFR: JDK-8304945: StringBuilder and StringBuffer should implement
 Appendable explicitly
In-Reply-To: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
References: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
Message-ID: <gRgYbTrhxPWyX0ij-RWtzJSczRk39cPzwBpNiybWWAo=.0c7c9655-25c9-4e68-a123-ebfbf3b47e4d@github.com>

On Sat, 1 Apr 2023 17:34:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The StringBuilder and StringBuffer classes are Appendable by virtue of from subclasses their non-public superclass AbstractStringBuilder.
> 
> It is slightly clearer to declare StringBuilder and StringBuffer to directly implement Appendable, as they already directly implement the CharSequence interface also implemented by their superclass.
> 
> There are no other interfaces implemented by AbstractStringBuilder other than Appendable and CharSequence.
> 
> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8305408

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

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

PR Review: https://git.openjdk.org/jdk/pull/13278#pullrequestreview-1368032789

From duke at openjdk.org  Sun Apr  2 07:20:23 2023
From: duke at openjdk.org (M4ximumPizza)
Date: Sun, 2 Apr 2023 07:20:23 GMT
Subject: RFR: 8305400: ISO 4217 Amendment 175 Update
In-Reply-To: <y9rYoYaCVHLiwhu8ICNuTAxpqWA7DO6dHBjtEVVLrAo=.8b660491-b48e-4092-9e3f-0cc1e90e0b31@github.com>
References: <y9rYoYaCVHLiwhu8ICNuTAxpqWA7DO6dHBjtEVVLrAo=.8b660491-b48e-4092-9e3f-0cc1e90e0b31@github.com>
Message-ID: <aRDlPuULrQkNmxr5fhL8rPfCms1JjIQ8Xd-6x7AraOw=.e7704361-3425-40b8-a798-1eea7ea20ad6@github.com>

On Fri, 31 Mar 2023 21:38:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review the ISO 4217 amendment 175 update.
> 
> There are no meaningful code changes, but the version number should be updated accordingly to be in sync.

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

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

PR Review: https://git.openjdk.org/jdk/pull/13275#pullrequestreview-1368032982

From alanb at openjdk.org  Sun Apr  2 07:27:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 2 Apr 2023 07:27:18 GMT
Subject: RFR: JDK-8303798: REDO - Remove fdlibm C sources
In-Reply-To: <VDk-pjTiTr7BFWxpbV22_MjjCRh7mEvxkBVbH0sARYM=.747e3f9d-626d-43c7-8da8-2f5c7c2c821d@github.com>
References: <VDk-pjTiTr7BFWxpbV22_MjjCRh7mEvxkBVbH0sARYM=.747e3f9d-626d-43c7-8da8-2f5c7c2c821d@github.com>
Message-ID: <RBDRS3PgFo8-kQ6kFz_0r-Tk27neFsJiy0hX9IjzQEw=.1ca43087-b1f6-4bdc-8554-749d8f2efcbe@github.com>

On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with JDK-8302801 was that it neglected (mea culpa) to include a Java implementation of IEEEremainder before the FDLIBM C implementation was deleted. Such an implementation has been successfully provided under JDK-8304028: Port fdlibm IEEEremainder to Java. After JDK-8304028, there are no native methods left in StrictMath.
> 
> This PR is the same as JDK-8302801 other than StrictMath.c already being removed under JDK-8304028.

I assume at least tier1-4 has been run, in which case this looks good (same as previous PR).

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13279#pullrequestreview-1368033821

From stsypanov at openjdk.org  Sun Apr  2 07:48:18 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 2 Apr 2023 07:48:18 GMT
Subject: RFR: JDK-8304945: StringBuilder and StringBuffer should implement
 Appendable explicitly
In-Reply-To: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
References: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
Message-ID: <a1W5DyShLxnj4ku7Y0GwCNRiKCGRYGNcyXt3O4JwU-A=.cb777d57-0e96-4388-bab6-09336e3eedbf@github.com>

On Sat, 1 Apr 2023 17:34:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The StringBuilder and StringBuffer classes are Appendable by virtue of from subclasses their non-public superclass AbstractStringBuilder.
> 
> It is slightly clearer to declare StringBuilder and StringBuffer to directly implement Appendable, as they already directly implement the CharSequence interface also implemented by their superclass.
> 
> There are no other interfaces implemented by AbstractStringBuilder other than Appendable and CharSequence.
> 
> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8305408

src/java.base/share/classes/java/lang/StringBuilder.java line 93:

> 91: public final class StringBuilder
> 92:     extends AbstractStringBuilder
> 93:     implements Appendable, java.io.Serializable, Comparable<StringBuilder>, CharSequence

Not an issue here, just wondering why do we have lots of places where we use `java.io.Serializable` instead of import statement?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13278#discussion_r1155259675

From lancea at openjdk.org  Sun Apr  2 14:13:33 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 2 Apr 2023 14:13:33 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]
In-Reply-To: <wdlK2a4TvgDZy13xJhJus7JEbD6oJ85jRnJmORsaq98=.7fcbc02f-1e9d-4cc2-98d0-7da3fcab9277@github.com>
References: <hRjv4lne53xefjivRXqIFnUozYDnbspHLloE8EqSDV0=.4cc72170-904d-4a43-a2aa-49d658f2de88@github.com>
 <EM2OKS8WyAMVqVxLJnccQ0dsVikng_mNsCKB-88m1KQ=.454a2b73-a955-42b5-8a36-023e025a2597@github.com>
 <DibMvsKMB9_nLOb5Vx1HprL3IpQ8CuwDd15f5DsB-LY=.0b3b37d4-127f-4411-94d2-88e41a66c63c@github.com>
 <wdlK2a4TvgDZy13xJhJus7JEbD6oJ85jRnJmORsaq98=.7fcbc02f-1e9d-4cc2-98d0-7da3fcab9277@github.com>
Message-ID: <His2dTDOJKhE4IMPmgpgzUvCPFr5CQSszERmKTzuR60=.e2ece17a-4d00-427e-a76d-63006a0d49c9@github.com>

On Fri, 31 Mar 2023 19:58:24 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 192:
>> 
>>> 190:     /*
>>> 191:      * Validate that a ZipException is thrown when the 'End of Central Directory'
>>> 192:      * (END) header has a CEN offset incoherent with the position calculated
>> 
>> Not sure _incoherent_ is the best term.
>> 
>>       perhaps something along the lines:
>> 
>> header  contains an invalid CEN Directory  starting offset.....
>
> I remember my struggles trying to write this one in the first place. The code says:
> 
> 
> long cenpos = end.endpos - end.cenlen;     // position of CEN table
> // Get position of first local file (LOC) header, taking into
> // account that there may be a stub prefixed to the zip file.
> locpos = cenpos - end.cenoff;
> if (locpos < 0) {
>         zerror("invalid END header (bad central directory offset)");
> }
> ``` 
> 
> so I ended up trying to express this equation in words, which is maybe not so successful. I don't see _incoherent_ as the main problem, if it was we could just use _inconsistent_.
> 
> Do you have a better concrete suggestion?

I would keep it simple and indicate that the offset of start of central directory field within the  End Header was given an invalid value

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1155318941

From duke at openjdk.org  Sun Apr  2 15:43:26 2023
From: duke at openjdk.org (ExE Boss)
Date: Sun, 2 Apr 2023 15:43:26 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v16]
In-Reply-To: <p9ijGq25fS1pue7aXoUfsKjc76t-oHcssoKtXRE7c_s=.a5e3a921-ed1d-4d39-aebc-6a7b590b5bdc@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <p9ijGq25fS1pue7aXoUfsKjc76t-oHcssoKtXRE7c_s=.a5e3a921-ed1d-4d39-aebc-6a7b590b5bdc@github.com>
Message-ID: <ZoVYnx2mKW_SE9Cl2YBSOTvId7rs0Sm3zQV-w4bz334=.dc1ec0a1-67c2-4ee1-8c15-0e17a8983c04@github.com>

On Thu, 30 Mar 2023 11:28:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

> 636:          *        .map(MemoryLayout::name)
> 637:          *        .filter(Optional::isPresent)
> 638:          *        .map(Optional::get)

[`Optional::stream()`] was?added specifically for?this:
Suggestion:

         *        .flatMap(Optional::stream)


[`Optional::stream()`]: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/Optional.html#stream()

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1155333484

From lancea at openjdk.org  Sun Apr  2 17:47:21 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 2 Apr 2023 17:47:21 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v6]
In-Reply-To: <CugzIulVBspVYrnt4jKnZHOpb204PPuUigImDuBrEYQ=.a7c2f6fd-6c44-400b-8643-07dd51b03aec@github.com>
References: <hRjv4lne53xefjivRXqIFnUozYDnbspHLloE8EqSDV0=.4cc72170-904d-4a43-a2aa-49d658f2de88@github.com>
 <CugzIulVBspVYrnt4jKnZHOpb204PPuUigImDuBrEYQ=.a7c2f6fd-6c44-400b-8643-07dd51b03aec@github.com>
Message-ID: <fQo-FDP7_6frCco4wfmEsGuoZm7ttVm_IL4EbxMhihA=.8436cba0-94e8-4354-a7ac-9dd0f5983418@github.com>

On Fri, 31 Mar 2023 19:59:10 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> CorruptedZipFiles could benefit from some spring cleaning and a conversion to junit:
>> 
>> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
>> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
>> - `checkZipExceptionImpl` is updated to take advantage of `assertThrows`
>> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed
>
> Eirik Bjorsnos has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Remove the "Validate that " comment prefix
>  - Spell immediately correctly
>  - a A -> a
>  - this -> the

Last Mach5 runs continue to be clean so you are good to integrate and then I can sponsor Monday

Thank you for your efforts on this clean up Eirik.

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12563#pullrequestreview-1368119311

From darcy at openjdk.org  Sun Apr  2 20:51:19 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 2 Apr 2023 20:51:19 GMT
Subject: RFR: JDK-8304945: StringBuilder and StringBuffer should implement
 Appendable explicitly
In-Reply-To: <jwwds1V7jHXE-sxIEQ9t95p3syrEnuJT2ok44v3wpMA=.504f0186-60b1-4e04-bb62-182623191d02@github.com>
References: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
 <jwwds1V7jHXE-sxIEQ9t95p3syrEnuJT2ok44v3wpMA=.504f0186-60b1-4e04-bb62-182623191d02@github.com>
Message-ID: <7l8JnIyX3rDbExkgcGAytNp4D0BXgo4RyTNefK6uT1c=.e7bc54cd-ed91-4c6b-82ba-3dd7068aaa0e@github.com>

On Sun, 2 Apr 2023 06:45:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Right now, the javadoc for SB lists Appendable in the "All Implemented Interfaces" list. With this change it will be shown in the class declaration in the list of "implements" list. Make sense.

Correct; after the change, the appearance of Appendable as one of the implemented interfaces of StringBuffer/StringBuilder has an evident explanation.

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

PR Comment: https://git.openjdk.org/jdk/pull/13278#issuecomment-1493436808

From darcy at openjdk.org  Sun Apr  2 20:53:28 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 2 Apr 2023 20:53:28 GMT
Subject: RFR: JDK-8303798: REDO - Remove fdlibm C sources
In-Reply-To: <RBDRS3PgFo8-kQ6kFz_0r-Tk27neFsJiy0hX9IjzQEw=.1ca43087-b1f6-4bdc-8554-749d8f2efcbe@github.com>
References: <VDk-pjTiTr7BFWxpbV22_MjjCRh7mEvxkBVbH0sARYM=.747e3f9d-626d-43c7-8da8-2f5c7c2c821d@github.com>
 <RBDRS3PgFo8-kQ6kFz_0r-Tk27neFsJiy0hX9IjzQEw=.1ca43087-b1f6-4bdc-8554-749d8f2efcbe@github.com>
Message-ID: <2Wk9KXrusm7rZrJ_f4J8hkUsFw6XmojEJn3U_J9SOzM=.d4e01c52-a73e-4b4c-a31a-042208b05ee8@github.com>

On Sun, 2 Apr 2023 07:24:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume at least tier1-4 has been run, in which case this looks good (same as previous PR).

Right; tier 1 - 4 job was successful other than an unrelated time-out. Previously, with the initial removal attempt there were many failures in tiers 2 and 3.

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

PR Comment: https://git.openjdk.org/jdk/pull/13279#issuecomment-1493437003

From duke at openjdk.org  Sun Apr  2 23:42:18 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sun, 2 Apr 2023 23:42:18 GMT
Subject: RFR: JDK-8304945: StringBuilder and StringBuffer should implement
 Appendable explicitly
In-Reply-To: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
References: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
Message-ID: <0rc8TP4dBlreDCv62jQyPJ83ccV7FIQcgMMKPxmI7r0=.0ea73555-5082-4b72-87da-b05e1866685a@github.com>

On Sat, 1 Apr 2023 17:34:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The StringBuilder and StringBuffer classes are Appendable by virtue of from subclasses their non-public superclass AbstractStringBuilder.
> 
> It is slightly clearer to declare StringBuilder and StringBuffer to directly implement Appendable, as they already directly implement the CharSequence interface also implemented by their superclass.
> 
> There are no other interfaces implemented by AbstractStringBuilder other than Appendable and CharSequence.
> 
> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8305408

src/java.base/share/classes/java/lang/StringBuffer.java line 112:

> 110:  * @since   1.0
> 111:  */
> 112:  public final class StringBuffer

Consider removing the leading space.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13278#discussion_r1155394123

From xgong at openjdk.org  Mon Apr  3 01:57:25 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 3 Apr 2023 01:57:25 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
Message-ID: <YjWuYxkOs-Fgyf-SzrRAdCmB4Uz18UUfZz9ghTSZSKo=.d8125bef-1cc0-429c-bd9b-cd29ee71b5d3@github.com>

On Fri, 31 Mar 2023 12:25:16 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small cosmetics

Looks good to me! Thanks!

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

Marked as reviewed by xgong (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13093#pullrequestreview-1368199580

From iris at openjdk.org  Mon Apr  3 06:38:18 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 3 Apr 2023 06:38:18 GMT
Subject: RFR: JDK-8303798: REDO - Remove fdlibm C sources
In-Reply-To: <VDk-pjTiTr7BFWxpbV22_MjjCRh7mEvxkBVbH0sARYM=.747e3f9d-626d-43c7-8da8-2f5c7c2c821d@github.com>
References: <VDk-pjTiTr7BFWxpbV22_MjjCRh7mEvxkBVbH0sARYM=.747e3f9d-626d-43c7-8da8-2f5c7c2c821d@github.com>
Message-ID: <TGtInwv-2J7FwmQKb_tPsYH8zXywQL3rg56CvaapoRk=.d95099e0-63a5-4015-90e0-269974f293a3@github.com>

On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with JDK-8302801 was that it neglected (mea culpa) to include a Java implementation of IEEEremainder before the FDLIBM C implementation was deleted. Such an implementation has been successfully provided under JDK-8304028: Port fdlibm IEEEremainder to Java. After JDK-8304028, there are no native methods left in StrictMath.
> 
> This PR is the same as JDK-8302801 other than StrictMath.c already being removed under JDK-8304028.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13279#pullrequestreview-1368368000

From jwaters at openjdk.org  Mon Apr  3 06:45:23 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 3 Apr 2023 06:45:23 GMT
Subject: RFR: JDK-8303798: REDO - Remove fdlibm C sources
In-Reply-To: <VDk-pjTiTr7BFWxpbV22_MjjCRh7mEvxkBVbH0sARYM=.747e3f9d-626d-43c7-8da8-2f5c7c2c821d@github.com>
References: <VDk-pjTiTr7BFWxpbV22_MjjCRh7mEvxkBVbH0sARYM=.747e3f9d-626d-43c7-8da8-2f5c7c2c821d@github.com>
Message-ID: <XtJgbTzgAjBAEGMGil5bdarZzGUATV93274hEeKCaN8=.4621d04c-90c8-4d2d-b34c-0e2fd8926921@github.com>

On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with JDK-8302801 was that it neglected (mea culpa) to include a Java implementation of IEEEremainder before the FDLIBM C implementation was deleted. Such an implementation has been successfully provided under JDK-8304028: Port fdlibm IEEEremainder to Java. After JDK-8304028, there are no native methods left in StrictMath.
> 
> This PR is the same as JDK-8302801 other than StrictMath.c already being removed under JDK-8304028.

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/13279#pullrequestreview-1368374542

From dholmes at openjdk.org  Mon Apr  3 07:27:14 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Apr 2023 07:27:14 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
Message-ID: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>

We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:

boolean alive() {
  return eetop != 0;
} 

I also updated a comment in relation to `eetop`.

Testing: tiers 1-3

Thanks

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

Commit messages:
 - update symbol file
 - 8305425: Thread.isAlive0 doesn't need to call into the VM

Changes: https://git.openjdk.org/jdk/pull/13287/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13287&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305425
  Stats: 19 lines in 5 files changed: 3 ins; 12 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13287.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13287/head:pull/13287

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

From alanb at openjdk.org  Mon Apr  3 07:55:20 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Apr 2023 07:55:20 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
In-Reply-To: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
Message-ID: <f8veI3E9mSCk6Adt4uvp7bLsc7ytYXFMfChE-yYAeJY=.f265a8a1-8973-4a4c-bc1c-1aee0987b8f2@github.com>

On Mon, 3 Apr 2023 07:17:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
> 
> boolean alive() {
>   return eetop != 0;
> } 
> 
> I also updated a comment in relation to `eetop`.
> 
> Testing: tiers 1-3
> 
> Thanks

src/java.base/share/classes/java/lang/Thread.java line 231:

> 229:     /* Reserved for exclusive use by the JVM. Cannot be moved to FieldHolder
> 230:        as it needs to be set by the VM before executing the constructor that
> 231:        will set FieldHolder.

"will set FieldHolder" is a bit confusing. It creates the FieldHolder and sets the field "holder" so I think the comment could be a bit clearer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1155601934

From pminborg at openjdk.org  Mon Apr  3 08:00:20 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 3 Apr 2023 08:00:20 GMT
Subject: RFR: JDK-8304945: StringBuilder and StringBuffer should implement
 Appendable explicitly
In-Reply-To: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
References: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
Message-ID: <9ALbTFVy0QaZYKhKuG4Os47w04N4CdJOI5el_rY-cSM=.26a90055-2f4d-4e17-ae16-f3e13f73df39@github.com>

On Sat, 1 Apr 2023 17:34:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The StringBuilder and StringBuffer classes are Appendable by virtue of from subclasses their non-public superclass AbstractStringBuilder.
> 
> It is slightly clearer to declare StringBuilder and StringBuffer to directly implement Appendable, as they already directly implement the CharSequence interface also implemented by their superclass.
> 
> There are no other interfaces implemented by AbstractStringBuilder other than Appendable and CharSequence.
> 
> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8305408

Are there more places where we "accidentally" expose interfaces via non-public (or even public) super classes?

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

PR Comment: https://git.openjdk.org/jdk/pull/13278#issuecomment-1493852792

From dholmes at openjdk.org  Mon Apr  3 09:36:39 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Apr 2023 09:36:39 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v2]
In-Reply-To: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
Message-ID: <Rvm7pyAc7BpF7m4H00gSdbHRsooRwD2msZ6_RETtPLU=.ca7096e0-2571-43df-9110-8f506b648abb@github.com>

> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
> 
> boolean alive() {
>   return eetop != 0;
> } 
> 
> I also updated a comment in relation to `eetop`.
> 
> Testing: tiers 1-3
> 
> Thanks

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

  Comment from AlanB

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13287/files
  - new: https://git.openjdk.org/jdk/pull/13287/files/5f5d05c2..fc1e1aba

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

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

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

From dholmes at openjdk.org  Mon Apr  3 09:36:41 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Apr 2023 09:36:41 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v2]
In-Reply-To: <f8veI3E9mSCk6Adt4uvp7bLsc7ytYXFMfChE-yYAeJY=.f265a8a1-8973-4a4c-bc1c-1aee0987b8f2@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <f8veI3E9mSCk6Adt4uvp7bLsc7ytYXFMfChE-yYAeJY=.f265a8a1-8973-4a4c-bc1c-1aee0987b8f2@github.com>
Message-ID: <fHNJ28uy5dIatiyn4qv-WUBuVZJYbXbuneXezr5Mf8k=.a362d687-1d74-456d-8924-b7441e13f5b5@github.com>

On Mon, 3 Apr 2023 07:53:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comment from AlanB
>
> src/java.base/share/classes/java/lang/Thread.java line 231:
> 
>> 229:     /* Reserved for exclusive use by the JVM. Cannot be moved to FieldHolder
>> 230:        as it needs to be set by the VM before executing the constructor that
>> 231:        will set FieldHolder.
> 
> "will set FieldHolder" is a bit confusing. It creates the FieldHolder and sets the field "holder" so I think the comment could be a bit clearer.

Thanks for looking at this @AlanBateman . I have updated the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1155715351

From alanb at openjdk.org  Mon Apr  3 10:25:31 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Apr 2023 10:25:31 GMT
Subject: RFR: JDK-8304945: StringBuilder and StringBuffer should implement
 Appendable explicitly
In-Reply-To: <9ALbTFVy0QaZYKhKuG4Os47w04N4CdJOI5el_rY-cSM=.26a90055-2f4d-4e17-ae16-f3e13f73df39@github.com>
References: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
 <9ALbTFVy0QaZYKhKuG4Os47w04N4CdJOI5el_rY-cSM=.26a90055-2f4d-4e17-ae16-f3e13f73df39@github.com>
Message-ID: <JFZq1B-vRNfhXgz6RHOWIfaYnzpluJZNNDv1MD5UE34=.a13e7c3c-b91a-4f6c-9382-39e57aed3bcc@github.com>

On Mon, 3 Apr 2023 07:57:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Are there more places where we "accidentally" expose interfaces via non-public (or even public) super classes?

Appendable was added as part of the scanning/formatting update in Java 5. It's intentional that SB implements Appendable but the intermediate/non-public superclass does complicate things. It makes it harder to reason about access control of public methods defined in the superclass, and problematic for javadoc. The funny thing is that the change that Joe has proposed here is what was discussed as a workaround in JDK-4983949 when it initially didn't show up in the javadoc. More discussion JDK-8224052 and JDK-8304060 for some of the challenges for javadoc.

Other examples are come up mind are
- j.u.concurrent.{Long,Double}{Adder,Accumulator} extend non-public Stripe64, Stripe64 extends Number
- j.t.chrono.XXXDate extends ChronoLocalDateImpl, ChronoLocalDateImpl implements several interfaces  

It's good question though, as it would be easy to "leak" an interface into the API.

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

PR Comment: https://git.openjdk.org/jdk/pull/13278#issuecomment-1494065784

From qamai at openjdk.org  Mon Apr  3 10:50:58 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 3 Apr 2023 10:50:58 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v2]
In-Reply-To: <Rvm7pyAc7BpF7m4H00gSdbHRsooRwD2msZ6_RETtPLU=.ca7096e0-2571-43df-9110-8f506b648abb@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <Rvm7pyAc7BpF7m4H00gSdbHRsooRwD2msZ6_RETtPLU=.ca7096e0-2571-43df-9110-8f506b648abb@github.com>
Message-ID: <IXARuOAY6V75ht99VLNC_RcprCTtpw4pqlq5PYdD9Dg=.65a411e4-22c9-4561-9bd8-a334de024fea@github.com>

On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
>> 
>> boolean alive() {
>>   return eetop != 0;
>> } 
>> 
>> I also updated a comment in relation to `eetop`.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment from AlanB

May I ask if we need some form of memory order here? Maybe an aquiring load is necessary?

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

PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1494094776

From duke at openjdk.org  Mon Apr  3 11:01:07 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 3 Apr 2023 11:01:07 GMT
Subject: RFR: JDK-8304945: StringBuilder and StringBuffer should implement
 Appendable explicitly
In-Reply-To: <JFZq1B-vRNfhXgz6RHOWIfaYnzpluJZNNDv1MD5UE34=.a13e7c3c-b91a-4f6c-9382-39e57aed3bcc@github.com>
References: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
 <9ALbTFVy0QaZYKhKuG4Os47w04N4CdJOI5el_rY-cSM=.26a90055-2f4d-4e17-ae16-f3e13f73df39@github.com>
 <JFZq1B-vRNfhXgz6RHOWIfaYnzpluJZNNDv1MD5UE34=.a13e7c3c-b91a-4f6c-9382-39e57aed3bcc@github.com>
Message-ID: <-04f9TPmUsdKgS6RPoQFKaskfezgt4p7CX5BKJqPofA=.fb6a66c8-6789-4275-b81b-eb10f2539a8a@github.com>

On Mon, 3 Apr 2023 10:23:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Are there more places where we "accidentally" expose interfaces via non-public (or even public) super classes?
> 
> Appendable was added as part of the scanning/formatting update in Java 5. It's intentional that SB implements Appendable but the intermediate/non-public superclass does complicate things. It makes it harder to reason about access control of public methods defined in the superclass, and problematic for javadoc. The funny thing is that the change that Joe has proposed here is what was discussed as a workaround in JDK-4983949 when it initially didn't show up in the javadoc. More discussion JDK-8224052 and JDK-8304060 for some of the challenges for javadoc.
> 
> Other examples are come up mind are
> 
> * j.u.concurrent.{Long,Double}{Adder,Accumulator} extend non-public Stripe64, Stripe64 extends Number
> * j.t.chrono.XXXDate extends ChronoLocalDateImpl, ChronoLocalDateImpl implements several interfaces
> 
> It's good question though, as it would be easy to "leak" an interface into the API.

`java.util.concurrent.atomic.Stripe64` does not declare to implement any interface, and its direct superclass `Number` is public and directly implements public interface `Serializable`. All subclasses of `java.time.chrono.ChronoLocalDateImpl` declare to implement a public interface `ChronoLocalDate` and the interface extends public interfaces `Temporal` and `TemporalAdjuster`. So we don't have to change these classes.

But in this issue, all public supertypes of `String{Builder,Buffer}` (`Serializable`, `Comparable`, `CharSequence` and `Object`) do not implement `Appendable`, so this change is necessary.

(BTW, I'm the submitter of this issue, so feel free to discuss further if you have any questions.)

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

PR Comment: https://git.openjdk.org/jdk/pull/13278#issuecomment-1494108985

From alanb at openjdk.org  Mon Apr  3 11:13:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Apr 2023 11:13:00 GMT
Subject: RFR: JDK-8304945: StringBuilder and StringBuffer should implement
 Appendable explicitly
In-Reply-To: <-04f9TPmUsdKgS6RPoQFKaskfezgt4p7CX5BKJqPofA=.fb6a66c8-6789-4275-b81b-eb10f2539a8a@github.com>
References: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
 <9ALbTFVy0QaZYKhKuG4Os47w04N4CdJOI5el_rY-cSM=.26a90055-2f4d-4e17-ae16-f3e13f73df39@github.com>
 <JFZq1B-vRNfhXgz6RHOWIfaYnzpluJZNNDv1MD5UE34=.a13e7c3c-b91a-4f6c-9382-39e57aed3bcc@github.com>
 <-04f9TPmUsdKgS6RPoQFKaskfezgt4p7CX5BKJqPofA=.fb6a66c8-6789-4275-b81b-eb10f2539a8a@github.com>
Message-ID: <b58GUWPLzY3vL4iEZlMmHHtVJ1sBsynh_hlU2xmp4_8=.36a73266-5a50-4fe1-9377-17599a4eb9d9@github.com>

On Mon, 3 Apr 2023 10:58:35 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>  So we don't have to change these classes.

They are just examples where the superclass is not-public.

> But in this issue, all public supertypes of `String{Builder,Buffer}` (`Serializable`, `Comparable`, `CharSequence` and `Object`) do not implement `Appendable`, so this change is necessary.

It's not strictly necessary but it does help the javadoc. It may also help code that walks the class hierarchy and looking at the accessibility of API elements in non-public supers.

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

PR Comment: https://git.openjdk.org/jdk/pull/13278#issuecomment-1494128409

From simon at dancingcloudservices.com  Mon Apr  3 11:27:45 2023
From: simon at dancingcloudservices.com (Simon Roberts)
Date: Mon, 3 Apr 2023 05:27:45 -0600
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v2]
In-Reply-To: <IXARuOAY6V75ht99VLNC_RcprCTtpw4pqlq5PYdD9Dg=.65a411e4-22c9-4561-9bd8-a334de024fea@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <Rvm7pyAc7BpF7m4H00gSdbHRsooRwD2msZ6_RETtPLU=.ca7096e0-2571-43df-9110-8f506b648abb@github.com>
 <IXARuOAY6V75ht99VLNC_RcprCTtpw4pqlq5PYdD9Dg=.65a411e4-22c9-4561-9bd8-a334de024fea@github.com>
Message-ID: <CADsQA7grFTSYWuKFJ5-f7M1oGsFbyeBYJCF_SiDNKsv92V6FKw@mail.gmail.com>

Agreed, I believe there should be an hb relationship with this, if the
target is not alive.

On Mon, Apr 3, 2023, 04:50 Quan Anh Mai <qamai at openjdk.org> wrote:

> On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes <dholmes at openjdk.org> wrote:
>
> >> We have the strange situation where calling `t.isAlive()` on a
> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
> `isAlive0()`) where the VM then examines the `eetop` field of `t` to
> extract its `JavaThread` pointer and compare it to null. We can simply read
> `eetop` directly in `Thread.alive()`:
> >>
> >> boolean alive() {
> >>   return eetop != 0;
> >> }
> >>
> >> I also updated a comment in relation to `eetop`.
> >>
> >> Testing: tiers 1-3
> >>
> >> Thanks
> >
> > David Holmes has updated the pull request incrementally with one
> additional commit since the last revision:
> >
> >   Comment from AlanB
>
> May I ask if we need some form of memory order here? Maybe an aquiring
> load is necessary?
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1494094776
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230403/da007773/attachment-0001.htm>

From shade at openjdk.org  Mon Apr  3 11:42:58 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 3 Apr 2023 11:42:58 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v2]
In-Reply-To: <Rvm7pyAc7BpF7m4H00gSdbHRsooRwD2msZ6_RETtPLU=.ca7096e0-2571-43df-9110-8f506b648abb@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <Rvm7pyAc7BpF7m4H00gSdbHRsooRwD2msZ6_RETtPLU=.ca7096e0-2571-43df-9110-8f506b648abb@github.com>
Message-ID: <5H50Wgs59idINOYfxPzUpnMAxCzXBn7H9rxSYDCUApI=.17ccba9a-629b-4ff8-a6e6-05b82d3d8fb9@github.com>

On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
>> 
>> boolean alive() {
>>   return eetop != 0;
>> } 
>> 
>> I also updated a comment in relation to `eetop`.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment from AlanB

This looks interesting. I think it is time to rename `eetop` to `javaThreadAddr` and comment that `javaThreadAddr != 0` means the thread has VM thread attached, and thus alive. Probably hide that fields from reflection too, like we do for some sensitive fields.

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

PR Review: https://git.openjdk.org/jdk/pull/13287#pullrequestreview-1368852869

From dholmes at openjdk.org  Mon Apr  3 12:34:59 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Apr 2023 12:34:59 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v2]
In-Reply-To: <IXARuOAY6V75ht99VLNC_RcprCTtpw4pqlq5PYdD9Dg=.65a411e4-22c9-4561-9bd8-a334de024fea@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <Rvm7pyAc7BpF7m4H00gSdbHRsooRwD2msZ6_RETtPLU=.ca7096e0-2571-43df-9110-8f506b648abb@github.com>
 <IXARuOAY6V75ht99VLNC_RcprCTtpw4pqlq5PYdD9Dg=.65a411e4-22c9-4561-9bd8-a334de024fea@github.com>
Message-ID: <FkWq56kYDdlaQU09wKnCcgGzajDxnAra_Y91392Jo9w=.ce51ebdf-b4b4-4c38-ab0c-d0e4762ca8ef@github.com>

On Mon, 3 Apr 2023 10:47:55 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> May I ask if we need some form of memory order here? Maybe an aquiring load is necessary?

What is it that you think needs ordering?

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

PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1494238641

From dholmes at openjdk.org  Mon Apr  3 12:35:01 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Apr 2023 12:35:01 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v2]
In-Reply-To: <5H50Wgs59idINOYfxPzUpnMAxCzXBn7H9rxSYDCUApI=.17ccba9a-629b-4ff8-a6e6-05b82d3d8fb9@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <Rvm7pyAc7BpF7m4H00gSdbHRsooRwD2msZ6_RETtPLU=.ca7096e0-2571-43df-9110-8f506b648abb@github.com>
 <5H50Wgs59idINOYfxPzUpnMAxCzXBn7H9rxSYDCUApI=.17ccba9a-629b-4ff8-a6e6-05b82d3d8fb9@github.com>
Message-ID: <01nnripfJun4F9CZ5MBhaUa_KsLB67FFOFHqRjRPWZQ=.4c7255a9-70d2-4bf5-967f-4f97de073fb3@github.com>

On Mon, 3 Apr 2023 11:39:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This looks interesting. I think it is time to rename eetop to javaThreadAddr ...

Feel free to file a RFE but not as part of this PR. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1494240185

From coleenp at openjdk.org  Mon Apr  3 12:59:04 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Apr 2023 12:59:04 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v2]
In-Reply-To: <Rvm7pyAc7BpF7m4H00gSdbHRsooRwD2msZ6_RETtPLU=.ca7096e0-2571-43df-9110-8f506b648abb@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <Rvm7pyAc7BpF7m4H00gSdbHRsooRwD2msZ6_RETtPLU=.ca7096e0-2571-43df-9110-8f506b648abb@github.com>
Message-ID: <xoIud8J2wplR5TbllFjyqDy8JfDiccn7vi9u_wXZ97U=.78523296-17fd-412b-a9b2-40d83dbaa4d0@github.com>

On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
>> 
>> boolean alive() {
>>   return eetop != 0;
>> } 
>> 
>> I also updated a comment in relation to `eetop`.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment from AlanB

This looks good.  Yes another RFE to rename eetop would be good but we shouldn't use our usual injected field mechanism to hide this from reflection because then we'd have to revert this and call into the JVM to fix it.  Also, we may want to also change the ensure.join() code in the VM to set eetop to zero directly to avoid one of the ObjectLockers in the vm.
We could add eetop (or its new name) to the excluded list in setAccessible().

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13287#pullrequestreview-1368976934

From david.holmes at oracle.com  Mon Apr  3 12:59:57 2023
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 3 Apr 2023 22:59:57 +1000
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v2]
In-Reply-To: <CADsQA7grFTSYWuKFJ5-f7M1oGsFbyeBYJCF_SiDNKsv92V6FKw@mail.gmail.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <Rvm7pyAc7BpF7m4H00gSdbHRsooRwD2msZ6_RETtPLU=.ca7096e0-2571-43df-9110-8f506b648abb@github.com>
 <IXARuOAY6V75ht99VLNC_RcprCTtpw4pqlq5PYdD9Dg=.65a411e4-22c9-4561-9bd8-a334de024fea@github.com>
 <CADsQA7grFTSYWuKFJ5-f7M1oGsFbyeBYJCF_SiDNKsv92V6FKw@mail.gmail.com>
Message-ID: <a7a426c1-c4fe-9dc1-662e-4a7a54e3dd02@oracle.com>

On 3/04/2023 9:27 pm, Simon Roberts wrote:
> Agreed, I believe there should be an hb relationship with this, if the 
> target is not alive.

You are both right - I did not recall the hb relationship between the 
last action of a thread and a call to isAlive that returns false. The 
existing code does not explicitly have it. In practice it was likely 
implicitly there due to the native call and VM thread state transitions 
but I'm not so sure.

Making eetop volatile would logically fix that, but the VM code that 
clears eetop would also need modifying to perform a volatile write.

Cheers,
David

> On Mon, Apr 3, 2023, 04:50 Quan Anh Mai <qamai at openjdk.org 
> <mailto:qamai at openjdk.org>> wrote:
> 
>     On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes <dholmes at openjdk.org
>     <mailto:dholmes at openjdk.org>> wrote:
> 
>      >> We have the strange situation where calling `t.isAlive()` on a
>     `java.lang.Thread` `t`, will call into the VM (via `alive()` then
>     `isAlive0()`) where the VM then examines the `eetop` field of `t` to
>     extract its `JavaThread` pointer and compare it to null. We can
>     simply read `eetop` directly in `Thread.alive()`:
>      >>
>      >> boolean alive() {
>      >>? ?return eetop != 0;
>      >> }
>      >>
>      >> I also updated a comment in relation to `eetop`.
>      >>
>      >> Testing: tiers 1-3
>      >>
>      >> Thanks
>      >
>      > David Holmes has updated the pull request incrementally with one
>     additional commit since the last revision:
>      >
>      >? ?Comment from AlanB
> 
>     May I ask if we need some form of memory order here? Maybe an
>     aquiring load is necessary?
> 
>     -------------
> 
>     PR Comment:
>     https://git.openjdk.org/jdk/pull/13287#issuecomment-1494094776
>     <https://git.openjdk.org/jdk/pull/13287#issuecomment-1494094776>
> 

From erikj at openjdk.org  Mon Apr  3 13:16:59 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 3 Apr 2023 13:16:59 GMT
Subject: RFR: JDK-8303798: REDO - Remove fdlibm C sources
In-Reply-To: <VDk-pjTiTr7BFWxpbV22_MjjCRh7mEvxkBVbH0sARYM=.747e3f9d-626d-43c7-8da8-2f5c7c2c821d@github.com>
References: <VDk-pjTiTr7BFWxpbV22_MjjCRh7mEvxkBVbH0sARYM=.747e3f9d-626d-43c7-8da8-2f5c7c2c821d@github.com>
Message-ID: <7oVTjm0lBVMaZK64Qb6pH0rgOCMYcGBxI0SfahlZh6A=.cd616078-d921-4294-9a4f-3ad7ff1924c2@github.com>

On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with JDK-8302801 was that it neglected (mea culpa) to include a Java implementation of IEEEremainder before the FDLIBM C implementation was deleted. Such an implementation has been successfully provided under JDK-8304028: Port fdlibm IEEEremainder to Java. After JDK-8304028, there are no native methods left in StrictMath.
> 
> This PR is the same as JDK-8302801 other than StrictMath.c already being removed under JDK-8304028.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13279#pullrequestreview-1369011040

From duke at openjdk.org  Mon Apr  3 13:41:48 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 3 Apr 2023 13:41:48 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v7]
In-Reply-To: <hRjv4lne53xefjivRXqIFnUozYDnbspHLloE8EqSDV0=.4cc72170-904d-4a43-a2aa-49d658f2de88@github.com>
References: <hRjv4lne53xefjivRXqIFnUozYDnbspHLloE8EqSDV0=.4cc72170-904d-4a43-a2aa-49d658f2de88@github.com>
Message-ID: <lbwOJZdFgaMNnJ_PPAOkj_kGQUmJUFOgtsRV9AN_kqs=.6d66b8e7-6dfd-4db3-98a2-f1a81de410cd@github.com>

> CorruptedZipFiles could benefit from some spring cleaning and a conversion to junit:
> 
> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
> - `checkZipExceptionImpl` is updated to take advantage of `assertThrows`
> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed

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

  Simplify the comment for excessiveCENOffset

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12563/files
  - new: https://git.openjdk.org/jdk/pull/12563/files/3b6d8577..ac4f2b42

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

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

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

From duke at openjdk.org  Mon Apr  3 13:41:52 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 3 Apr 2023 13:41:52 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v6]
In-Reply-To: <CugzIulVBspVYrnt4jKnZHOpb204PPuUigImDuBrEYQ=.a7c2f6fd-6c44-400b-8643-07dd51b03aec@github.com>
References: <hRjv4lne53xefjivRXqIFnUozYDnbspHLloE8EqSDV0=.4cc72170-904d-4a43-a2aa-49d658f2de88@github.com>
 <CugzIulVBspVYrnt4jKnZHOpb204PPuUigImDuBrEYQ=.a7c2f6fd-6c44-400b-8643-07dd51b03aec@github.com>
Message-ID: <nWoUcO_PIsAcXyPTPyg53e2MmRgCTHTTyqiCCm_6Xy0=.3b102db6-c379-4a8a-aadf-c86627c6954b@github.com>

On Fri, 31 Mar 2023 19:59:10 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> CorruptedZipFiles could benefit from some spring cleaning and a conversion to junit:
>> 
>> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
>> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
>> - `checkZipExceptionImpl` is updated to take advantage of `assertThrows`
>> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed
>
> Eirik Bjorsnos has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Remove the "Validate that " comment prefix
>  - Spell immediately correctly
>  - a A -> a
>  - this -> the

Updated the `excessiveCENOffset` comment to say just _A ZipException is thrown when the 'End of Central Directory'(END) header has a CEN offset with an invalid value_.

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

PR Comment: https://git.openjdk.org/jdk/pull/12563#issuecomment-1494337042

From shade at openjdk.org  Mon Apr  3 14:01:01 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 3 Apr 2023 14:01:01 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v2]
In-Reply-To: <01nnripfJun4F9CZ5MBhaUa_KsLB67FFOFHqRjRPWZQ=.4c7255a9-70d2-4bf5-967f-4f97de073fb3@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <Rvm7pyAc7BpF7m4H00gSdbHRsooRwD2msZ6_RETtPLU=.ca7096e0-2571-43df-9110-8f506b648abb@github.com>
 <5H50Wgs59idINOYfxPzUpnMAxCzXBn7H9rxSYDCUApI=.17ccba9a-629b-4ff8-a6e6-05b82d3d8fb9@github.com>
 <01nnripfJun4F9CZ5MBhaUa_KsLB67FFOFHqRjRPWZQ=.4c7255a9-70d2-4bf5-967f-4f97de073fb3@github.com>
Message-ID: <Ia8Pj1HOhPFQTknJECLBIhavjtRTMZZATrvacVX6Fk8=.c748d32a-a636-4a20-9679-4df4cf17890d@github.com>

On Mon, 3 Apr 2023 12:32:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > This looks interesting. I think it is time to rename eetop to javaThreadAddr ...
> 
> Feel free to file a RFE but not as part of this PR. :)

Well, when this thing is considered in isolation, it changes the clear `isAlive0()` call to rather obscure `eetop != 0` condition, with no documentation what that field actually is. At very least we should add the comment that the field carries the native thread pointer, and `!= 0` is actually checking for `null`.

But, someone (who should remain anonymous under the alias, say... rolls dice... Andrei?) pointed out that async-profiler looks up `eetop`, so the rename would break the profiler until the renamed field is handled there. So the rename at this point is a bit dicey: https://github.com/async-profiler/async-profiler/blob/39b0bdb5e446b1b88acdf37fd18a4560f5176a2e/src/vmStructs.cpp#L409

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

PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1494370793

From duke at openjdk.org  Mon Apr  3 14:45:12 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 3 Apr 2023 14:45:12 GMT
Subject: RFR: 8297605: improve DelayQueue removal method javadoc [v2]
In-Reply-To: <nzXs4JquqSnCFENe10ay8yg7ta6CoE09i73euZtcrng=.be9723c7-fa73-480e-aaf2-21a0e3aae60b@github.com>
References: <w6jsGlCtA8rY09gHTGFOsbaYBFLLRx3zv2YrVOCQv5o=.3513f580-3b42-4525-ad61-e6b561ede30d@github.com>
 <nzXs4JquqSnCFENe10ay8yg7ta6CoE09i73euZtcrng=.be9723c7-fa73-480e-aaf2-21a0e3aae60b@github.com>
Message-ID: <dGeH9L1qpB1KtOMhnARw2_oLQ5SPMFPCeLJHZOHjnmg=.75cf738e-4172-46df-a795-8dc0aa21bcff@github.com>

On Tue, 21 Mar 2023 17:51:26 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Inviting @DougLea and @viktorklang-ora to review.
>> 
>> As usual, I couldn't resist more fiddling.  
>> - Added missing tests for take, remove(), remove(Object).
>> - Improved DelayQueueTest's testing infrastructure
>> - added more test assertions
>> - linkified new javadoc definitions
>
> Martin Buchholz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix punctuation

Nice work @Martin-Buchholz! ?

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

PR Comment: https://git.openjdk.org/jdk/pull/12838#issuecomment-1494456047

From psandoz at openjdk.org  Mon Apr  3 15:02:07 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 3 Apr 2023 15:02:07 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
Message-ID: <yYs8BT5NPYXHWQZFgfuavw_a-2D_BLdBxTrKqYtXvPY=.e922781d-6eff-456b-8d76-8e14022c0aab@github.com>

On Fri, 31 Mar 2023 12:25:16 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small cosmetics

Tier 2/3 tests passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1494486846

From psandoz at openjdk.org  Mon Apr  3 15:20:21 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 3 Apr 2023 15:20:21 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
Message-ID: <dez4pisOp184_ewE6yWZu9sCTQwrYBz4cRkGeGZ--oI=.009b295a-049c-4574-aca2-13dac4cd6ecd@github.com>

On Fri, 31 Mar 2023 12:25:16 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small cosmetics

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13093#pullrequestreview-1369262809

From jlaskey at openjdk.org  Mon Apr  3 15:33:19 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 3 Apr 2023 15:33:19 GMT
Subject: Integrated: JDK-8302323 Add repeat methods to
 StringBuilder/StringBuffer
In-Reply-To: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
Message-ID: <WUmB1_H2E7ZY7SviVvIAqfmk9sjSh9f4wmTZenmJiFw=.72dcabe4-8c65-414d-96c5-96f5645ff563@github.com>

On Thu, 23 Feb 2023 13:13:43 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.

This pull request has now been integrated.

Changeset: 9b9b5a7a
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9b9b5a7a5c624f3512567f5d9b2e9eec231cabb3
Stats:     570 lines in 6 files changed: 566 ins; 0 del; 4 mod

8302323: Add repeat methods to StringBuilder/StringBuffer

Reviewed-by: tvaleev, redestad

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

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

From bpb at openjdk.org  Mon Apr  3 15:44:59 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 3 Apr 2023 15:44:59 GMT
Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing [v4]
In-Reply-To: <egxFmKc8oFy7aJVd6vnNWB_jcd2sP8-FC9Y0Dm6qUtw=.71d85ca0-aaad-44be-815d-aa8d0635a940@github.com>
References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
 <DTNziTj7KbkeG3LvpMREAi9WP9XRczQUdP_1-XTvp2c=.b9b78dec-3879-4626-9174-306e57ce83a4@github.com>
 <134wQrl9F4McK30DN1EvRTuqCx-WDMTgym1traoL8fI=.1247d3ff-0413-415a-9f3f-6a30b59f62d5@github.com>
 <Kia7JD1spnBOVIg-KuMO17m5UJClbL8R1SivnOyx8_0=.3950cd71-ce62-47ca-9ac6-0d16071567e3@github.com>
 <N2rOY286-pmyGS6g6R_EddIeBAj-cdStUNRMGwvh6tc=.06ec461d-2868-4de0-a0b0-a8e86709ba98@github.com>
 <2qnsd811w7eNF2SE9ZSkCtH0k87zSAMsi262xhyh8eQ=.b83e63dc-e3e7-4e69-858d-b4770abe59e5@github.com>
 <egxFmKc8oFy7aJVd6vnNWB_jcd2sP8-FC9Y0Dm6qUtw=.71d85ca0-aaad-44be-815d-aa8d0635a940@github.com>
Message-ID: <GA5QRIEnTaw_AVrVphHHISPA1fvWobSSiZYGtSoBB9Y=.7aa80863-611d-47ee-b776-e42718563dab@github.com>

On Tue, 28 Feb 2023 21:26:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Spawning `df` and `diskFree` processes have been replaced with native calls. For a reason as yet undetermined, the Windows function `GetDiskSpaceInformationW` fails to load on Windows Server 2016 so it is loaded dynamically and, if not found, a workaround is used.
>
> Testing in the CI against the latest commit 114857c1fbc6ea6ad0ee9ccce10cb886e8c62469 has passed more than 500 iterations on Windows with no failures.

This test has been run successfully hundreds of times on CI system nodes where it previously failed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12397#discussion_r1156138528

From bpb at openjdk.org  Mon Apr  3 15:45:06 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 3 Apr 2023 15:45:06 GMT
Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing [v3]
In-Reply-To: <bWLN-jk492CjkE5FQcrjHSeAswzrYEYTXlbhyA7MPsc=.17abd4b5-fbf0-4b9d-8158-7b2b2bab9a24@github.com>
References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
 <2d5h6HANV8vMQbQnVvsuiYiO_n1IG-2zQuz-facvwK0=.ca21cf4e-5f06-4893-a115-c9adb5310fff@github.com>
 <bWLN-jk492CjkE5FQcrjHSeAswzrYEYTXlbhyA7MPsc=.17abd4b5-fbf0-4b9d-8158-7b2b2bab9a24@github.com>
Message-ID: <-5eMDI6zpYdB_QgvsN8i6WEu9oFCXCtqUpzQvefKkLU=.025ce99f-fbe9-416f-a228-5fd67d1ad6da@github.com>

On Wed, 29 Mar 2023 16:10:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - 8298619: Change getSpace0() to return a boolean; print warning if total size is estimated instead of exact
>>  - Merge
>>  - 8298619: Load GetDiskSpaceInformationW dynamically
>>  - 8298619: Replace df and diskFree with native calls
>>  - 8298619: java/io/File/GetXSpace.java is failing
>
> test/jdk/java/io/File/GetXSpace.java line 278:
> 
>> 276:                 fail(s.name() + " free space (quota)", fs, ">", s.size());
>> 277:             } else {
>> 278:                 pass();
> 
> Can the inverted check and if/else clauses be swapped. It would read more naturally as:
> 
>  if (windows()) {
>     ...windows code...
>  } else {
>     ... non-windows code...
>  }

So changed in 9ae317e7b485d4ac56be25731165aafef694e9b5.

> test/jdk/java/io/File/libGetXSpace.c line 66:
> 
>> 64:     if (chars == NULL) {
>> 65:         JNU_ThrowByNameWithLastError(env, "java/lang/RuntimeException",
>> 66:                                      "GetStringChars");
> 
> Add a `return JNI_FALSE`; otherwise it falls through.

Fixed in 9ae317e7b485d4ac56be25731165aafef694e9b5.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12397#discussion_r1156137512
PR Review Comment: https://git.openjdk.org/jdk/pull/12397#discussion_r1156137241

From duke at openjdk.org  Mon Apr  3 16:15:16 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 3 Apr 2023 16:15:16 GMT
Subject: Integrated: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit
In-Reply-To: <hRjv4lne53xefjivRXqIFnUozYDnbspHLloE8EqSDV0=.4cc72170-904d-4a43-a2aa-49d658f2de88@github.com>
References: <hRjv4lne53xefjivRXqIFnUozYDnbspHLloE8EqSDV0=.4cc72170-904d-4a43-a2aa-49d658f2de88@github.com>
Message-ID: <MPT4oLbYfs3gwIukSt3STTBH-F5ngYO2atlsN_jUD0Y=.9755f6a0-1080-4aa3-ac29-e8d25192b5db@github.com>

On Tue, 14 Feb 2023 17:46:21 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> CorruptedZipFiles could benefit from some spring cleaning and a conversion to junit:
> 
> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
> - `checkZipExceptionImpl` is updated to take advantage of `assertThrows`
> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed

This pull request has now been integrated.

Changeset: 85e39744
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85e397447025484bde0fb8349d72075c14199be6
Stats:     392 lines in 1 file changed: 211 ins; 117 del; 64 mod

8304014: Convert test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit

Reviewed-by: lancea

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

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

From psandoz at openjdk.org  Mon Apr  3 16:39:01 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 3 Apr 2023 16:39:01 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v4]
In-Reply-To: <Hb8JZTxmiXR9lC0wUf7mPzDa3gcoTMQfsbqrZuu-UBk=.f8e1d2c5-86eb-4ce8-a57d-84be5d6733c4@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <Hb8JZTxmiXR9lC0wUf7mPzDa3gcoTMQfsbqrZuu-UBk=.f8e1d2c5-86eb-4ce8-a57d-84be5d6733c4@github.com>
Message-ID: <LoOoz2KdvmlNtfJy3Sv7m6EHZpCnVcaMdkFjZ0VFc-g=.a2e2fc2c-d421-4152-b410-7311219f634a@github.com>

On Sat, 1 Apr 2023 07:44:25 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
>> 
>> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
>> 
>> Please take a look and have some reviews. Thank you very much.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - instruction asserts
>  - Merge branch 'master' into sliceIntrinsics
>  - add comments explaining anonymous classes
>  - address reviews
>  - sse2, increase warmup
>  - aesthetic
>  - optimise 64B
>  - add jmh
>  - vector slice intrinsics

With the latest PR I am observing failures with debug builds for test compiler/vectorapi/TestVectorSlice.java on both AVX512 machines and aarch64 machines.

On AVX512 machines the test fails with JVM args `-XX:UseAVX=3` and `-XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting` and results in a test assertion failure e.g.,

Caused by: java.lang.RuntimeException: assertEquals: expected 70 to equal 0
	at jdk.test.lib.Asserts.fail(Asserts.java:594)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:189)
	at compiler.vectorapi.TestVectorSlice.lambda$testInts$2(TestVectorSlice.java:163)
	at compiler.vectorapi.TestVectorSlice.testInts(TestVectorSlice.java:181)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	... 7 more


CPU flags are:

fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant tsc arch perfmon rep good nopl xtopology cpuid tsc known freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4 1 sse4 2 x2apic movbe popcnt tsc deadline timer aes xsave avx f16c rdrand hypervisor lahf lm abm 3dnowprefetch cpuid fault invpcid single ssbd ibrs ibpb stibp ibrs enhanced tpr shadow vnmi flexpriority ept vpid ept ad fsgsbase tsc adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves nt good wbnoinvd arat avx512vbmi umip pku ospke avx512 vbmi2 gfni vaes vpclmulqdq avx512 vnni avx512 bitalg avx512 vpopcntdq la57 rdpid md clear arch capabilities


On aarch64 there is an IR rule failure.

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

PR Comment: https://git.openjdk.org/jdk/pull/12909#issuecomment-1494641261

From rriggs at openjdk.org  Mon Apr  3 16:53:04 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 3 Apr 2023 16:53:04 GMT
Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing [v4]
In-Reply-To: <zKxMjcsrJzFosMSbMXsc-Kw3-jMSTEXq509MhUgMd_o=.9a35eaab-327e-4321-901c-e01f15350ffb@github.com>
References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
 <zKxMjcsrJzFosMSbMXsc-Kw3-jMSTEXq509MhUgMd_o=.9a35eaab-327e-4321-901c-e01f15350ffb@github.com>
Message-ID: <lMl2jryCJ7mPv8dbeBmpEP0qT6yE0eN1AH6hExHQ5Mg=.2d90d873-6878-4ed5-9662-3c74edf73669@github.com>

On Wed, 29 Mar 2023 18:05:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify the `Space` instances used for size comparison to be created with total number of bytes derived from the Windows `diskFree` utility instead of Cygwin?s `df`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8305157: Clean up

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12397#pullrequestreview-1369424502

From naoto at openjdk.org  Mon Apr  3 16:56:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Apr 2023 16:56:12 GMT
Subject: RFR: 8304982: Emit warning for removal of `COMPAT` provider
Message-ID: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>

This is a precursor to the future removal of the `COMPAT` locale data provider. Before the actual removal of the provider, warn the users who explicitly specify `COMPAT` at the command line in order for their smooth migration to CLDR. A CSR has also been drafted.

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

Commit messages:
 - clean-up
 - Added @implNote. Check "JRE" as well. Clean-up
 - Spec change to LocaleServiceProvider
 - clean-up
 - added a test
 - 8304982: Emit warning for removal of `COMPAT` provider

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

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

From rriggs at openjdk.org  Mon Apr  3 17:10:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 3 Apr 2023 17:10:57 GMT
Subject: RFR: JDK-8304945: StringBuilder and StringBuffer should implement
 Appendable explicitly
In-Reply-To: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
References: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
Message-ID: <WYuGyXbCrrJfCb_VmMZxh09xumEQADCpB7x_GlntnuQ=.b4680328-5ba9-430c-b91b-fd76169ebe41@github.com>

On Sat, 1 Apr 2023 17:34:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The StringBuilder and StringBuffer classes are Appendable by virtue of from subclasses their non-public superclass AbstractStringBuilder.
> 
> It is slightly clearer to declare StringBuilder and StringBuffer to directly implement Appendable, as they already directly implement the CharSequence interface also implemented by their superclass.
> 
> There are no other interfaces implemented by AbstractStringBuilder other than Appendable and CharSequence.
> 
> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8305408

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13278#pullrequestreview-1369450009

From darcy at openjdk.org  Mon Apr  3 17:23:08 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Apr 2023 17:23:08 GMT
Subject: RFR: JDK-8304945: StringBuilder and StringBuffer should implement
 Appendable explicitly
In-Reply-To: <a1W5DyShLxnj4ku7Y0GwCNRiKCGRYGNcyXt3O4JwU-A=.cb777d57-0e96-4388-bab6-09336e3eedbf@github.com>
References: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
 <a1W5DyShLxnj4ku7Y0GwCNRiKCGRYGNcyXt3O4JwU-A=.cb777d57-0e96-4388-bab6-09336e3eedbf@github.com>
Message-ID: <KeJnKzgSUI7JXM7vWFww7MawVxasEwSCKuJqMOPPdGo=.3fc34e2e-b3e6-459d-913f-77e0db75b910@github.com>

On Sun, 2 Apr 2023 07:45:23 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> The StringBuilder and StringBuffer classes are Appendable by virtue of from subclasses their non-public superclass AbstractStringBuilder.
>> 
>> It is slightly clearer to declare StringBuilder and StringBuffer to directly implement Appendable, as they already directly implement the CharSequence interface also implemented by their superclass.
>> 
>> There are no other interfaces implemented by AbstractStringBuilder other than Appendable and CharSequence.
>> 
>> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8305408
>
> src/java.base/share/classes/java/lang/StringBuilder.java line 93:
> 
>> 91: public final class StringBuilder
>> 92:     extends AbstractStringBuilder
>> 93:     implements Appendable, java.io.Serializable, Comparable<StringBuilder>, CharSequence
> 
> Not an issue here, just wondering why do we have lots of places where we use `java.io.Serializable` instead of import statement?

The JDK codebase historically has not used tooling to enforce a uniform style on such matters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13278#discussion_r1156240099

From darcy at openjdk.org  Mon Apr  3 17:23:10 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Apr 2023 17:23:10 GMT
Subject: Integrated: JDK-8304945: StringBuilder and StringBuffer should
 implement Appendable explicitly
In-Reply-To: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
References: <cZ7Cy3ZkH3y2bs5j2FNb_N6R5Fiw9V6RD2Lr3goh-rA=.1b1df0db-c889-4e5e-8e50-15233f5765fc@github.com>
Message-ID: <HeyJY7OQRetVaKnwSnAmEFMtBfsSH5FDFKBbIlmi2E8=.7a34ecc9-2020-4763-8623-922029195741@github.com>

On Sat, 1 Apr 2023 17:34:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The StringBuilder and StringBuffer classes are Appendable by virtue of from subclasses their non-public superclass AbstractStringBuilder.
> 
> It is slightly clearer to declare StringBuilder and StringBuffer to directly implement Appendable, as they already directly implement the CharSequence interface also implemented by their superclass.
> 
> There are no other interfaces implemented by AbstractStringBuilder other than Appendable and CharSequence.
> 
> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8305408

This pull request has now been integrated.

Changeset: df819cfa
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df819cfa5a0330205fed89923df6dd5f7d5ffb45
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8304945: StringBuilder and StringBuffer should implement Appendable explicitly

Reviewed-by: alanb, rriggs

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

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

From alanb at openjdk.org  Mon Apr  3 17:28:58 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Apr 2023 17:28:58 GMT
Subject: RFR: 8304982: Emit warning for removal of `COMPAT` provider
In-Reply-To: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
Message-ID: <Mclqz7aiAy9PVJMWybbtAUnvfadP9uzJjc87ADcRKuU=.a8a61d3d-489c-467d-85ef-f6e7a403c018@github.com>

On Mon, 3 Apr 2023 16:47:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a precursor to the future removal of the `COMPAT` locale data provider. Before the actual removal of the provider, warn the users who explicitly specify `COMPAT` at the command line in order for their smooth migration to CLDR. A CSR has also been drafted.

src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 123:

> 121:  * {@link System#setProperty(String, String)} is discouraged and it may not affect
> 122:  * the order.
> 123:  * @implNote Java Runtime Environment provides the following four locale providers:

The change looks okay and I agree that this section should be changed to be an implNote. In several other areas, the wording is "The JDK Reference Implementation" rather than "Java Runtime Environment" in implNote text so we might have to adjust that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13302#discussion_r1156247831

From rgiulietti at openjdk.org  Mon Apr  3 17:54:13 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 3 Apr 2023 17:54:13 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to String
 and j.u.r.Pattern
Message-ID: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>

Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.

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

Commit messages:
 - 8305486: Add split() variants that keep the delimiters to String and j.u.r.Pattern

Changes: https://git.openjdk.org/jdk/pull/13305/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13305&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305486
  Stats: 384 lines in 3 files changed: 260 ins; 40 del; 84 mod
  Patch: https://git.openjdk.org/jdk/pull/13305.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13305/head:pull/13305

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

From rgiulietti at openjdk.org  Mon Apr  3 17:54:13 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 3 Apr 2023 17:54:13 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern
In-Reply-To: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
Message-ID: <G54EY6xmr8qc0lUXeQAFAaSKTP1CiFIw2O2-acsBBh0=.9973be11-1261-4560-8b74-48aed4475666@github.com>

On Mon, 3 Apr 2023 17:43:55 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.

Also see [here](https://mail.openjdk.org/pipermail/core-libs-dev/2023-March/103379.html) for some background discussion.

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

PR Comment: https://git.openjdk.org/jdk/pull/13305#issuecomment-1494734763

From naoto at openjdk.org  Mon Apr  3 18:11:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Apr 2023 18:11:03 GMT
Subject: RFR: 8304982: Emit warning for removal of `COMPAT` provider [v2]
In-Reply-To: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
Message-ID: <CTu8GEr7M96qN2VqCX0pcgkIgQnOLawY-9DvCTBqjjY=.00282dfc-2d97-40a3-b6ec-6efad774d573@github.com>

> This is a precursor to the future removal of the `COMPAT` locale data provider. Before the actual removal of the provider, warn the users who explicitly specify `COMPAT` at the command line in order for their smooth migration to CLDR. A CSR has also been drafted.

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

  Replaced "Java Runtime Environment" with "JDK Reference Implementation"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13302/files
  - new: https://git.openjdk.org/jdk/pull/13302/files/95a46b61..d613600f

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

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

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

From naoto at openjdk.org  Mon Apr  3 18:11:06 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Apr 2023 18:11:06 GMT
Subject: RFR: 8304982: Emit warning for removal of `COMPAT` provider [v2]
In-Reply-To: <Mclqz7aiAy9PVJMWybbtAUnvfadP9uzJjc87ADcRKuU=.a8a61d3d-489c-467d-85ef-f6e7a403c018@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
 <Mclqz7aiAy9PVJMWybbtAUnvfadP9uzJjc87ADcRKuU=.a8a61d3d-489c-467d-85ef-f6e7a403c018@github.com>
Message-ID: <iEV94nJGeRBF10hvO_jCgC0m89fSHCbys2DZG5-OMuQ=.14583332-4afa-42bb-9a0a-5e35a5b6ea2b@github.com>

On Mon, 3 Apr 2023 17:25:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replaced "Java Runtime Environment" with "JDK Reference Implementation"
>
> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 123:
> 
>> 121:  * {@link System#setProperty(String, String)} is discouraged and it may not affect
>> 122:  * the order.
>> 123:  * @implNote Java Runtime Environment provides the following four locale providers:
> 
> The change looks okay and I agree that this section should be changed to be an implNote. In several other areas, the wording is "The JDK Reference Implementation" rather than "Java Runtime Environment" in implNote text so we might have to adjust that.

Replaced the wording as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13302#discussion_r1156287411

From qamai at openjdk.org  Mon Apr  3 18:27:09 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 3 Apr 2023 18:27:09 GMT
Subject: RFR: 8305461: [vectorapi] Add VectorMask::xor
Message-ID: <3qsNbKA1cm_XZnUNTDApkZDGMBq6PXcXZBTvEdv9UC4=.5dc8fed0-684e-4cd1-a007-d5e0c3cd0a65@github.com>

Hi,

This patch adds `VectorMask.xor` to the public interface of `VectorMask`. This method has already been existed in each concrete mask classes. Also, this patch renames `VectorMask.eq` to `VectorMask::xorNot`, which is more consistent with other logical operations in the same interface.

Please kindly review.
Thanks a lot.

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

Commit messages:
 - rename xorNot back to eq
 - revert renaming eq
 - tests
 - remove dangling docs
 - add final
 - maskxor

Changes: https://git.openjdk.org/jdk/pull/13277/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13277&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305461
  Stats: 2732 lines in 64 files changed: 2411 ins; 281 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/13277.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13277/head:pull/13277

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

From jvernee at openjdk.org  Mon Apr  3 18:29:06 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 3 Apr 2023 18:29:06 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v5]
In-Reply-To: <Nqbg43z5eI4t0ggJF2Fs6WlOkWqRK6uL3CGUl8Ficm8=.0f7d7917-38c5-4727-8167-ef79ecf56686@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
 <Nqbg43z5eI4t0ggJF2Fs6WlOkWqRK6uL3CGUl8Ficm8=.0f7d7917-38c5-4727-8167-ef79ecf56686@github.com>
Message-ID: <AGH0w7uf0H8ZjrD4h1bRC8aY70ayWDyFoRvRyEXkCx4=.48d1d216-2b96-4a91-8523-d600682a5cc3@github.com>

On Thu, 30 Mar 2023 18:46:25 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
>> 
>> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=<dumpDir>` 
>> 
>> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
>> 
>> To dump lambda proxy classes, set this system property:
>>    -Djdk.internal.lambda.dumpProxyClasses=<dumpDir>
>> 
>> To dump LambdaForms and method handle implementation, set this system property:
>>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>>    
>> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   set -D<key> or -D<key>=true will enable dumping

Looks mostly good.

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 85:

> 83: 
> 84:     // Used to ensure that dumped class files for failed definitions have a unique class name
> 85:     private static final AtomicInteger counter = new AtomicInteger();

This counter could be removed now, it looks like.

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

> 2534:                             }
> 2535:                         } else {
> 2536:                             name += ".failed-" + dumper.incrementAndGetCounter();

I think it makes more sense to move the counter to `ClassDefiner`. It is not used by `ClassFileDumper` itself.

(make it `static` if it's possible to have multiple definer instances with the same class name)

src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 115:

> 113:         if (dumper.isEnabled() && !path.equals(dumper.dumpPath())) {
> 114:             throw new IllegalArgumentException("mismatched dump path for " + key);
> 115:         }

I don't see how this exception case could ever occur, given that `dumper.dumpPath` is directly coming from `dir`, and `validateDumpDir` doesn't return a modified path either.

Can this check be removed?

src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 145:

> 143:     public Path pathname(String internalName) {
> 144:         return dumpDir.resolve(encodeForFilename(internalName) + ".class");
> 145:     }

Could be `private` I think

src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 182:

> 180:                     if (!Files.exists(path)) {
> 181:                         try {
> 182:                             Files.createDirectory(path);

Maybe this could use `createDirectories` instead, in case the path is nested. `dumpClass` also uses that.

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

PR Review: https://git.openjdk.org/jdk/pull/13182#pullrequestreview-1369526948
PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1156289723
PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1156296104
PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1156281816
PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1156284973
PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1156280537

From mchung at openjdk.org  Mon Apr  3 19:25:05 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Apr 2023 19:25:05 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v5]
In-Reply-To: <AGH0w7uf0H8ZjrD4h1bRC8aY70ayWDyFoRvRyEXkCx4=.48d1d216-2b96-4a91-8523-d600682a5cc3@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
 <Nqbg43z5eI4t0ggJF2Fs6WlOkWqRK6uL3CGUl8Ficm8=.0f7d7917-38c5-4727-8167-ef79ecf56686@github.com>
 <AGH0w7uf0H8ZjrD4h1bRC8aY70ayWDyFoRvRyEXkCx4=.48d1d216-2b96-4a91-8523-d600682a5cc3@github.com>
Message-ID: <D5x0ovWRD97qrIAWH0ZwH0l2C0rJylk0Wf-45oHyatg=.96e943b0-334b-44bf-b0f0-484168e3ce79@github.com>

On Mon, 3 Apr 2023 18:07:52 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   set -D<key> or -D<key>=true will enable dumping
>
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 85:
> 
>> 83: 
>> 84:     // Used to ensure that dumped class files for failed definitions have a unique class name
>> 85:     private static final AtomicInteger counter = new AtomicInteger();
> 
> This counter could be removed now, it looks like.

thanks for catching it. will fix.

> src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 115:
> 
>> 113:         if (dumper.isEnabled() && !path.equals(dumper.dumpPath())) {
>> 114:             throw new IllegalArgumentException("mismatched dump path for " + key);
>> 115:         }
> 
> I don't see how this exception case could ever occur, given that `dumper.dumpPath` is directly coming from `dir`, and `validateDumpDir` doesn't return a modified path either.
> 
> Can this check be removed?

This is to check if two callers get the `ClassFileDumper` of the same key but different path.


  ClassFileDumper.getInstance("jdk.foo.dump", "DUMP_DIR");
  ClassFileDumper.getInstance("jdk.foo.dump", "DUMP_NEW_DIR");  <--- IAE

> src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 145:
> 
>> 143:     public Path pathname(String internalName) {
>> 144:         return dumpDir.resolve(encodeForFilename(internalName) + ".class");
>> 145:     }
> 
> Could be `private` I think

It's public in case the caller who invokes `ClassDefiner::defineClass` wants to print the path to which the classfile is written.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1156367767
PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1156366699
PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1156367573

From mchung at openjdk.org  Mon Apr  3 19:29:02 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Apr 2023 19:29:02 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v5]
In-Reply-To: <AGH0w7uf0H8ZjrD4h1bRC8aY70ayWDyFoRvRyEXkCx4=.48d1d216-2b96-4a91-8523-d600682a5cc3@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
 <Nqbg43z5eI4t0ggJF2Fs6WlOkWqRK6uL3CGUl8Ficm8=.0f7d7917-38c5-4727-8167-ef79ecf56686@github.com>
 <AGH0w7uf0H8ZjrD4h1bRC8aY70ayWDyFoRvRyEXkCx4=.48d1d216-2b96-4a91-8523-d600682a5cc3@github.com>
Message-ID: <6YVzrXiPHW6LqK7A6sNfC91khfHFzq8towGDF82RVEQ=.52704815-7269-4190-865b-2a4995002bfe@github.com>

On Mon, 3 Apr 2023 18:13:54 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   set -D<key> or -D<key>=true will enable dumping
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2536:
> 
>> 2534:                             }
>> 2535:                         } else {
>> 2536:                             name += ".failed-" + dumper.incrementAndGetCounter();
> 
> I think it makes more sense to move the counter to `ClassDefiner`. It is not used by `ClassFileDumper` itself.
> 
> (make it `static` if it's possible to have multiple definer instances with the same class name)

I see your point.   If it were a static counter for all dumpers,  multiple`.failed-xxx` dumped by a single dumper may not be in sequence if other dumpers have `.failed-xxx` class files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1156371958

From kvn at openjdk.org  Mon Apr  3 19:31:00 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 3 Apr 2023 19:31:00 GMT
Subject: RFR: JDK-8303798: REDO - Remove fdlibm C sources
In-Reply-To: <VDk-pjTiTr7BFWxpbV22_MjjCRh7mEvxkBVbH0sARYM=.747e3f9d-626d-43c7-8da8-2f5c7c2c821d@github.com>
References: <VDk-pjTiTr7BFWxpbV22_MjjCRh7mEvxkBVbH0sARYM=.747e3f9d-626d-43c7-8da8-2f5c7c2c821d@github.com>
Message-ID: <ls7wujBSGY0yM0Y0RsU_SnM35wmTyPxClFIqUBPAt5c=.49cea249-e9b3-460a-88e9-8ec330a64298@github.com>

On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with JDK-8302801 was that it neglected (mea culpa) to include a Java implementation of IEEEremainder before the FDLIBM C implementation was deleted. Such an implementation has been successfully provided under JDK-8304028: Port fdlibm IEEEremainder to Java. After JDK-8304028, there are no native methods left in StrictMath.
> 
> This PR is the same as JDK-8302801 other than StrictMath.c already being removed under JDK-8304028.

Seems fine to me.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13279#pullrequestreview-1369672551

From cjplummer at openjdk.org  Mon Apr  3 19:34:57 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 3 Apr 2023 19:34:57 GMT
Subject: RFR: 8305341: Alignment outside of HotSpot should be enforced by
 alignas instead of compiler specific attributes
In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
Message-ID: <PqgVwYn9G7DUgMlgyOJAqo65CPbiu5oUVnF-vzmfoVs=.c8db07f1-15d4-4af8-832f-256e6dca3ff4@github.com>

On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

> I don't think I can touch the freetype code since I think it's an external library that was imported. HotSpot requires a special review for changes like this, so it's not done here, but instead at #11431 (Which has dried up for a long time now, would be great if someone finally looked at that PR...)

Ok. What about the globalDefinitions_visCPP.hpp reference?

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

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1494864710

From jvernee at openjdk.org  Mon Apr  3 19:36:00 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 3 Apr 2023 19:36:00 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v5]
In-Reply-To: <D5x0ovWRD97qrIAWH0ZwH0l2C0rJylk0Wf-45oHyatg=.96e943b0-334b-44bf-b0f0-484168e3ce79@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
 <Nqbg43z5eI4t0ggJF2Fs6WlOkWqRK6uL3CGUl8Ficm8=.0f7d7917-38c5-4727-8167-ef79ecf56686@github.com>
 <AGH0w7uf0H8ZjrD4h1bRC8aY70ayWDyFoRvRyEXkCx4=.48d1d216-2b96-4a91-8523-d600682a5cc3@github.com>
 <D5x0ovWRD97qrIAWH0ZwH0l2C0rJylk0Wf-45oHyatg=.96e943b0-334b-44bf-b0f0-484168e3ce79@github.com>
Message-ID: <Ip2O_nL0GlvtVCci-uU7qPLolXiocP0C8HNTvqhhI2w=.0e456b1a-d6e4-4070-b2fa-1cbdf99c178d@github.com>

On Mon, 3 Apr 2023 19:21:00 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 115:
>> 
>>> 113:         if (dumper.isEnabled() && !path.equals(dumper.dumpPath())) {
>>> 114:             throw new IllegalArgumentException("mismatched dump path for " + key);
>>> 115:         }
>> 
>> I don't see how this exception case could ever occur, given that `dumper.dumpPath` is directly coming from `dir`, and `validateDumpDir` doesn't return a modified path either.
>> 
>> Can this check be removed?
>
> This is to check if two callers get the `ClassFileDumper` of the same key but different path.
> 
> 
>   ClassFileDumper.getInstance("jdk.foo.dump", "DUMP_DIR");
>   ClassFileDumper.getInstance("jdk.foo.dump", "DUMP_NEW_DIR");  <--- IAE

Ok, I see.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1156378106

From jvernee at openjdk.org  Mon Apr  3 19:44:04 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 3 Apr 2023 19:44:04 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v5]
In-Reply-To: <6YVzrXiPHW6LqK7A6sNfC91khfHFzq8towGDF82RVEQ=.52704815-7269-4190-865b-2a4995002bfe@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
 <Nqbg43z5eI4t0ggJF2Fs6WlOkWqRK6uL3CGUl8Ficm8=.0f7d7917-38c5-4727-8167-ef79ecf56686@github.com>
 <AGH0w7uf0H8ZjrD4h1bRC8aY70ayWDyFoRvRyEXkCx4=.48d1d216-2b96-4a91-8523-d600682a5cc3@github.com>
 <6YVzrXiPHW6LqK7A6sNfC91khfHFzq8towGDF82RVEQ=.52704815-7269-4190-865b-2a4995002bfe@github.com>
Message-ID: <m64QMWKYjfqd6dSdPpdDDGAbSjDI_Z5PGyd3f43pflo=.062cb1ef-379a-47ca-9fd0-9fb420a7a763@github.com>

On Mon, 3 Apr 2023 19:26:13 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2536:
>> 
>>> 2534:                             }
>>> 2535:                         } else {
>>> 2536:                             name += ".failed-" + dumper.incrementAndGetCounter();
>> 
>> I think it makes more sense to move the counter to `ClassDefiner`. It is not used by `ClassFileDumper` itself.
>> 
>> (make it `static` if it's possible to have multiple definer instances with the same class name)
>
> I see your point.   If it were a static counter for all dumpers,  multiple`.failed-xxx` dumped by a single dumper may not be in sequence if other dumpers have `.failed-xxx` class files.

If the counter has to be per dumper, maybe it makes sense to push the logic that derives the file name into ClassFileDumper too. e.g. have a `dumpClass(name, Class<?>, bytes)` and `dumpFailed(name, bytes)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1156387213

From duke at openjdk.org  Mon Apr  3 19:53:17 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 3 Apr 2023 19:53:17 GMT
Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing [v2]
In-Reply-To: <AjDnqfwvtOh_qfmB-9JifK1aS0X0Sw5tU79hL-UPGGE=.c2b74002-56a2-4fe8-879f-f11ce8e7b87a@github.com>
References: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
 <AjDnqfwvtOh_qfmB-9JifK1aS0X0Sw5tU79hL-UPGGE=.c2b74002-56a2-4fe8-879f-f11ce8e7b87a@github.com>
Message-ID: <lRNVBDX6XJuRDAlRHr4FrHv5XbDE6mFktwzhs1GyLjY=.3c2163de-47a2-41d6-803d-1c1ba9e5d5dd@github.com>

On Fri, 24 Feb 2023 16:08:57 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605
>> 
>> @DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter.
>
> Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   JDK-8297605 DelayQueue javadoc is confusing

Superseded by https://github.com/openjdk/jdk/pull/12838

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

PR Comment: https://git.openjdk.org/jdk/pull/12729#issuecomment-1494886096

From duke at openjdk.org  Mon Apr  3 19:53:17 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 3 Apr 2023 19:53:17 GMT
Subject: Withdrawn: JDK-8297605 DelayQueue javadoc is confusing
In-Reply-To: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
References: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
Message-ID: <44546xG2-n3GBZOA8Dnqit2LWee4ciES9XdSSrMGIfc=.2d4bccc1-fae4-4769-b8d4-62149b26d46c@github.com>

On Thu, 23 Feb 2023 15:36:48 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605
> 
> @DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter.

This pull request has been closed without being integrated.

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

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

From alanb at openjdk.org  Mon Apr  3 19:59:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Apr 2023 19:59:00 GMT
Subject: RFR: 8304982: Emit warning for removal of `COMPAT` provider [v2]
In-Reply-To: <CTu8GEr7M96qN2VqCX0pcgkIgQnOLawY-9DvCTBqjjY=.00282dfc-2d97-40a3-b6ec-6efad774d573@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
 <CTu8GEr7M96qN2VqCX0pcgkIgQnOLawY-9DvCTBqjjY=.00282dfc-2d97-40a3-b6ec-6efad774d573@github.com>
Message-ID: <KrPf7Cdx49LrETjy7N__lBWsXbmji93laRgUpErHGVQ=.3d70ebd7-35c1-4c54-8343-d59ee4df7d77@github.com>

On Mon, 3 Apr 2023 18:11:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a precursor to the future removal of the `COMPAT` locale data provider. Before the actual removal of the provider, warn the users who explicitly specify `COMPAT` at the command line in order for their smooth migration to CLDR. A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced "Java Runtime Environment" with "JDK Reference Implementation"

src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 120:

> 118:  * the locale sensitive services separated by a comma. As this property value is
> 119:  * read and cached only at the initialization of this class, users should specify the
> 120:  * property on the java launcher command line. Setting it at runtime with

I may have missed it but does LocalServiceProvider's description of "java.locale.providers" say what the value of the system property is? If providers don't have names then I'm wondering if this system property can be used to select control ordering if I deploy my own provider. If not, then it makes me wonder if the definition of this system property needs to move to the implNote section.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13302#discussion_r1156398749

From naoto at openjdk.org  Mon Apr  3 20:19:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Apr 2023 20:19:03 GMT
Subject: RFR: 8304982: Emit warning for removal of `COMPAT` provider [v2]
In-Reply-To: <KrPf7Cdx49LrETjy7N__lBWsXbmji93laRgUpErHGVQ=.3d70ebd7-35c1-4c54-8343-d59ee4df7d77@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
 <CTu8GEr7M96qN2VqCX0pcgkIgQnOLawY-9DvCTBqjjY=.00282dfc-2d97-40a3-b6ec-6efad774d573@github.com>
 <KrPf7Cdx49LrETjy7N__lBWsXbmji93laRgUpErHGVQ=.3d70ebd7-35c1-4c54-8343-d59ee4df7d77@github.com>
Message-ID: <DAPIvBszP49fQ1q_9v_onndEIpjFX2waXY_FA4-vups=.cd268216-7359-4071-aefd-543a1923cfdb@github.com>

On Mon, 3 Apr 2023 19:56:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replaced "Java Runtime Environment" with "JDK Reference Implementation"
>
> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 120:
> 
>> 118:  * the locale sensitive services separated by a comma. As this property value is
>> 119:  * read and cached only at the initialization of this class, users should specify the
>> 120:  * property on the java launcher command line. Setting it at runtime with
> 
> I may have missed it but does LocalServiceProvider's description of "java.locale.providers" say what the value of the system property is? If providers don't have names then I'm wondering if this system property can be used to select control ordering if I deploy my own provider. If not, then it makes me wonder if the definition of this system property needs to move to the implNote section.

Locale providers provided by users can all be loaded in the name of `SPI`, as they are the real implementation of `LocaleServiceProvider` class, so the order of the preference can be specified against JDK's `CLDR` provider. Does this answer your question?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13302#discussion_r1156415773

From mchung at openjdk.org  Mon Apr  3 20:24:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Apr 2023 20:24:56 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v6]
In-Reply-To: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
Message-ID: <cs28F4SMBCm6fRcgd5tntj76ADfq_DyyK-jH4Gr8M-w=.bfa787e7-5bb5-41ac-bcd9-bff2ba698550@github.com>

> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
> 
> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=<dumpDir>` 
> 
> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
> 
> To dump lambda proxy classes, set this system property:
>    -Djdk.internal.lambda.dumpProxyClasses=<dumpDir>
> 
> To dump LambdaForms and method handle implementation, set this system property:
>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>    
> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.

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

  comments from Jorn Vernee

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13182/files
  - new: https://git.openjdk.org/jdk/pull/13182/files/351574a8..2eeb7b04

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

  Stats: 75 lines in 3 files changed: 27 ins; 33 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13182.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13182/head:pull/13182

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

From mchung at openjdk.org  Mon Apr  3 20:25:00 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Apr 2023 20:25:00 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v5]
In-Reply-To: <m64QMWKYjfqd6dSdPpdDDGAbSjDI_Z5PGyd3f43pflo=.062cb1ef-379a-47ca-9fd0-9fb420a7a763@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
 <Nqbg43z5eI4t0ggJF2Fs6WlOkWqRK6uL3CGUl8Ficm8=.0f7d7917-38c5-4727-8167-ef79ecf56686@github.com>
 <AGH0w7uf0H8ZjrD4h1bRC8aY70ayWDyFoRvRyEXkCx4=.48d1d216-2b96-4a91-8523-d600682a5cc3@github.com>
 <6YVzrXiPHW6LqK7A6sNfC91khfHFzq8towGDF82RVEQ=.52704815-7269-4190-865b-2a4995002bfe@github.com>
 <m64QMWKYjfqd6dSdPpdDDGAbSjDI_Z5PGyd3f43pflo=.062cb1ef-379a-47ca-9fd0-9fb420a7a763@github.com>
Message-ID: <z8dj_wybff33lHLzg-6qMKxyTHTGzHnsWefQ3w7ch9s=.51f42f2b-30fd-4e90-8c2c-5de6ce25249a@github.com>

On Mon, 3 Apr 2023 19:41:28 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I see your point.   If it were a static counter for all dumpers,  multiple`.failed-xxx` dumped by a single dumper may not be in sequence if other dumpers have `.failed-xxx` class files.
>
> If the counter has to be per dumper, maybe it makes sense to push the logic that derives the file name into ClassFileDumper too. e.g. have a `dumpClass(name, Class<?>, bytes)` and `dumpFailed(name, bytes)`.

that's a good idea.  Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1156419811

From jvernee at openjdk.org  Mon Apr  3 20:40:00 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 3 Apr 2023 20:40:00 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v6]
In-Reply-To: <cs28F4SMBCm6fRcgd5tntj76ADfq_DyyK-jH4Gr8M-w=.bfa787e7-5bb5-41ac-bcd9-bff2ba698550@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
 <cs28F4SMBCm6fRcgd5tntj76ADfq_DyyK-jH4Gr8M-w=.bfa787e7-5bb5-41ac-bcd9-bff2ba698550@github.com>
Message-ID: <o6FX4zJdR0J8l33nkzgCY0v5PwHGLpGMm1qqt8mlnaY=.59c87892-f303-4483-a2cf-8c9556bcf3a2@github.com>

On Mon, 3 Apr 2023 20:24:56 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
>> 
>> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=<dumpDir>` 
>> 
>> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
>> 
>> To dump lambda proxy classes, set this system property:
>>    -Djdk.internal.lambda.dumpProxyClasses=<dumpDir>
>> 
>> To dump LambdaForms and method handle implementation, set this system property:
>>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>>    
>> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments from Jorn Vernee

Nice! Thanks.

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13182#pullrequestreview-1369768341

From forax at openjdk.org  Mon Apr  3 21:13:05 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 3 Apr 2023 21:13:05 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v6]
In-Reply-To: <cs28F4SMBCm6fRcgd5tntj76ADfq_DyyK-jH4Gr8M-w=.bfa787e7-5bb5-41ac-bcd9-bff2ba698550@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
 <cs28F4SMBCm6fRcgd5tntj76ADfq_DyyK-jH4Gr8M-w=.bfa787e7-5bb5-41ac-bcd9-bff2ba698550@github.com>
Message-ID: <M0RNE9ibe8V97BS8dZ1T_vNOVYrTcJz7Qio19VuN2iI=.2608edf5-bcc1-42b3-80e6-a863ad20bcda@github.com>

On Mon, 3 Apr 2023 20:24:56 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
>> 
>> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=<dumpDir>` 
>> 
>> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
>> 
>> To dump lambda proxy classes, set this system property:
>>    -Djdk.internal.lambda.dumpProxyClasses=<dumpDir>
>> 
>> To dump LambdaForms and method handle implementation, set this system property:
>>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>>    
>> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments from Jorn Vernee

src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 199:

> 197:                 @Override
> 198:                 public Path run() {
> 199:                     if (!Files.exists(path)) {

I do not think this is necessary, Files.createDirectories() already only create directories if they do not exist.
Moreover, someone can change the state of the files in between the two calls (Files.exists and Files.createDirectories) given that those two calls are not atomic from the filesystem POV.

src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 216:

> 214:     }
> 215: 
> 216:     private static HexFormat HEX = HexFormat.of().withUpperCase();

'final' ?

src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 226:

> 224:             // control characters
> 225:             if (c <= 31 || BAD_CHARS.contains(c)) {
> 226:                 sb.append("%");

sb.append('%')  // using a character instead of a String

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1156456578
PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1156456936
PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1156457481

From dholmes at openjdk.org  Mon Apr  3 21:33:46 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Apr 2023 21:33:46 GMT
Subject: RFR: JDK-8303798: REDO - Remove fdlibm C sources
In-Reply-To: <VDk-pjTiTr7BFWxpbV22_MjjCRh7mEvxkBVbH0sARYM=.747e3f9d-626d-43c7-8da8-2f5c7c2c821d@github.com>
References: <VDk-pjTiTr7BFWxpbV22_MjjCRh7mEvxkBVbH0sARYM=.747e3f9d-626d-43c7-8da8-2f5c7c2c821d@github.com>
Message-ID: <KsYNM_Ln5mgCYFJ3dUCmk1sb_KkhyueE0zraAYqNV0w=.0ffb3b8a-d84d-4dc2-a653-44ed6d855e70@github.com>

On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with JDK-8302801 was that it neglected (mea culpa) to include a Java implementation of IEEEremainder before the FDLIBM C implementation was deleted. Such an implementation has been successfully provided under JDK-8304028: Port fdlibm IEEEremainder to Java. After JDK-8304028, there are no native methods left in StrictMath.
> 
> This PR is the same as JDK-8302801 other than StrictMath.c already being removed under JDK-8304028.

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13279#pullrequestreview-1369828371

From mchung at openjdk.org  Mon Apr  3 22:09:29 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Apr 2023 22:09:29 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v7]
In-Reply-To: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
Message-ID: <aK83dHlaEHoi2IDqXCB5L_PzSRZpzXyOZ5eaRX_eG9s=.bd1fefa2-3fc2-4b8f-905b-d679ed4dcd8d@github.com>

> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
> 
> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=<dumpDir>` 
> 
> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
> 
> To dump lambda proxy classes, set this system property:
>    -Djdk.internal.lambda.dumpProxyClasses=<dumpDir>
> 
> To dump LambdaForms and method handle implementation, set this system property:
>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>    
> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.

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

  comments from Remi

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13182/files
  - new: https://git.openjdk.org/jdk/pull/13182/files/2eeb7b04..120bc2f1

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

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

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

From mchung at openjdk.org  Mon Apr  3 22:09:37 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Apr 2023 22:09:37 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v6]
In-Reply-To: <M0RNE9ibe8V97BS8dZ1T_vNOVYrTcJz7Qio19VuN2iI=.2608edf5-bcc1-42b3-80e6-a863ad20bcda@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
 <cs28F4SMBCm6fRcgd5tntj76ADfq_DyyK-jH4Gr8M-w=.bfa787e7-5bb5-41ac-bcd9-bff2ba698550@github.com>
 <M0RNE9ibe8V97BS8dZ1T_vNOVYrTcJz7Qio19VuN2iI=.2608edf5-bcc1-42b3-80e6-a863ad20bcda@github.com>
Message-ID: <qNn6pNBeq_yhHFupshqVmw6EQnLtxdymnVbDEujqGk8=.4fd57e72-65bd-47ca-9921-0ea3b3c035ab@github.com>

On Mon, 3 Apr 2023 21:05:07 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments from Jorn Vernee
>
> src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 199:
> 
>> 197:                 @Override
>> 198:                 public Path run() {
>> 199:                     if (!Files.exists(path)) {
> 
> I do not think this is necessary, Files.createDirectories() already only create directories if they do not exist.
> Moreover, someone can change the state of the files in between the two calls (Files.exists and Files.createDirectories) given that those two calls are not atomic from the filesystem POV.

that's right. updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1156495833

From mchung at openjdk.org  Mon Apr  3 22:32:44 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Apr 2023 22:32:44 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v8]
In-Reply-To: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
Message-ID: <pxr3PU4TR2TbPviyI-iMPQ6ZtoPmAOqK5T8fWC9S5CQ=.1d814810-9e8d-4ddd-b63d-6e8648028fcb@github.com>

> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
> 
> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=<dumpDir>` 
> 
> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
> 
> To dump lambda proxy classes, set this system property:
>    -Djdk.internal.lambda.dumpProxyClasses=<dumpDir>
> 
> To dump LambdaForms and method handle implementation, set this system property:
>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>    
> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.

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

  update test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13182/files
  - new: https://git.openjdk.org/jdk/pull/13182/files/120bc2f1..a6806208

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

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

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

From dholmes at openjdk.org  Mon Apr  3 22:41:44 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Apr 2023 22:41:44 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v3]
In-Reply-To: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
Message-ID: <QCUHuRgMUXENoZ9r6Xwrsoz9LUlI5g1L8jBFwuiv5jU=.31220531-a579-4d41-82e4-d3d454f59a0a@github.com>

> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
> 
> boolean alive() {
>   return eetop != 0;
> } 
> 
> I also updated a comment in relation to `eetop`.
> 
> Testing: tiers 1-3
> 
> Thanks

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

  Ensure HB relationship exists; additional explanatory comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13287/files
  - new: https://git.openjdk.org/jdk/pull/13287/files/fc1e1aba..e4bb5d66

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

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

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

From dholmes at openjdk.org  Mon Apr  3 22:41:45 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Apr 2023 22:41:45 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v2]
In-Reply-To: <Rvm7pyAc7BpF7m4H00gSdbHRsooRwD2msZ6_RETtPLU=.ca7096e0-2571-43df-9110-8f506b648abb@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <Rvm7pyAc7BpF7m4H00gSdbHRsooRwD2msZ6_RETtPLU=.ca7096e0-2571-43df-9110-8f506b648abb@github.com>
Message-ID: <QvG1pjPGk09SsPge25UnIxunE2pi5RthYxKWenTubFQ=.63babdfd-6a08-4253-ab97-56f7cb1f981d@github.com>

On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
>> 
>> boolean alive() {
>>   return eetop != 0;
>> } 
>> 
>> I also updated a comment in relation to `eetop`.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment from AlanB

Simpler fix for the HB issue is to make alive() synchronized.

Not sure how Virtual Threads are supposed to act here.

> At very least we should add the comment that the field carries the native thread pointer ...

I can do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1495076660

From naoto at openjdk.org  Mon Apr  3 23:05:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Apr 2023 23:05:26 GMT
Subject: RFR: 8305107: Emoji related binary properties in RegEx
Message-ID: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>

Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.

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

Commit messages:
 - 8305107: Emoji related binary properties in RegEx

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

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

From ysatowse at openjdk.org  Mon Apr  3 23:21:47 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Mon, 3 Apr 2023 23:21:47 GMT
Subject: RFR: 8305113: (tz) Update Timezone Data to 2023c
In-Reply-To: <g7ZoUMeB75XYwOMS9w6PnUxZGievJ_310fvgNer5LBo=.216c004f-a73f-49c8-8714-0582741fe2fd@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
 <g7ZoUMeB75XYwOMS9w6PnUxZGievJ_310fvgNer5LBo=.216c004f-a73f-49c8-8714-0582741fe2fd@github.com>
Message-ID: <0GIS0cB7XTY14P9SfaKlPz6LoTGxk-f6X9hpp02XBmk=.f9ee9de0-5a7d-4479-a4f0-8f7a00501a05@github.com>

On Fri, 31 Mar 2023 22:05:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Pleases review this PR. 
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.
>
> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 1996, 2033, Oracle and/or its affiliates. All rights reserved.
> 
> Wrong year.

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13255#discussion_r1156538844

From ysatowse at openjdk.org  Mon Apr  3 23:21:51 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Mon, 3 Apr 2023 23:21:51 GMT
Subject: RFR: 8305113: (tz) Update Timezone Data to 2023c
In-Reply-To: <1VwO7D4lktZKW64DaX6vLHnmPcA9NjjS38Keru9HuC8=.6d236924-f398-4067-9e85-2c739fdd766c@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
 <1VwO7D4lktZKW64DaX6vLHnmPcA9NjjS38Keru9HuC8=.6d236924-f398-4067-9e85-2c739fdd766c@github.com>
Message-ID: <lWWxOP6SzjE4LNGZMlqIgHQOF0afmhLqBnQIBauyyN0=.8190be32-83c0-453c-8617-795d877a7d29@github.com>

On Fri, 31 Mar 2023 16:44:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Pleases review this PR. 
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.
>
> src/java.base/share/data/tzdata/antarctica line 1:
> 
>> 1:  #
> 
> Extra space

Thanks!

> src/java.base/share/data/tzdata/northamerica line 1:
> 
>> 1: src/java.base/share/data/tzdata/northamerica #
> 
> ??? copy/paste error?

It's likely. Thanks for the catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13255#discussion_r1156538477
PR Review Comment: https://git.openjdk.org/jdk/pull/13255#discussion_r1156537246

From ysatowse at openjdk.org  Mon Apr  3 23:29:12 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Mon, 3 Apr 2023 23:29:12 GMT
Subject: RFR: 8305113: (tz) Update Timezone Data to 2023c
In-Reply-To: <g7ZoUMeB75XYwOMS9w6PnUxZGievJ_310fvgNer5LBo=.216c004f-a73f-49c8-8714-0582741fe2fd@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
 <g7ZoUMeB75XYwOMS9w6PnUxZGievJ_310fvgNer5LBo=.216c004f-a73f-49c8-8714-0582741fe2fd@github.com>
Message-ID: <rJbHEtOPTJ9joR8VatPhGQAv9GsaJLor9E-1jUESArA=.cd7577e0-21fc-4823-b412-2c8f379d2c54@github.com>

On Fri, 31 Mar 2023 22:06:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Pleases review this PR. 
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.
>
> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 742:
> 
>> 740: 
>> 741:         return new ZoneInfo(zoneId, rawOffset, dstSavings, checksum, transitions,
>> 742:                 offsets, params, willGMTOffsetChange);
> 
> do we need to change it here?

No need.  It was reformatted by IntelliJ editor.  The original code is better from perspective of the OpenJDK's standard code style.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13255#discussion_r1156543028

From ysatowse at openjdk.org  Mon Apr  3 23:34:05 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Mon, 3 Apr 2023 23:34:05 GMT
Subject: RFR: 8305113: (tz) Update Timezone Data to 2023c [v2]
In-Reply-To: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
Message-ID: <egXTJDiDBSUPeDPuKm5gHa-sPnsHIPUm1Vz5Hb_3S_U=.1fccc622-ce10-4daf-b9b0-32c195ac60ea@github.com>

> Pleases review this PR. 
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.

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

  fixing some typos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13255/files
  - new: https://git.openjdk.org/jdk/pull/13255/files/c754a33e..b29bb679

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

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

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

From ysatowse at openjdk.org  Mon Apr  3 23:40:05 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Mon, 3 Apr 2023 23:40:05 GMT
Subject: RFR: 8305113: (tz) Update Timezone Data to 2023c [v3]
In-Reply-To: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
Message-ID: <vTLYpNzwdiTkdNdsHyDC9iRA8GMLIov2-ASJi8ARaiY=.6797783d-5bd7-4093-910b-e4da9691817f@github.com>

> Pleases review this PR. 
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.

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

 - Revert formatted code in ZoneInfoFile.java
 - fixing typo again

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13255/files
  - new: https://git.openjdk.org/jdk/pull/13255/files/b29bb679..30c575e5

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

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

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

From darcy at openjdk.org  Tue Apr  4 00:00:15 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 4 Apr 2023 00:00:15 GMT
Subject: Integrated: JDK-8303798: REDO - Remove fdlibm C sources
In-Reply-To: <VDk-pjTiTr7BFWxpbV22_MjjCRh7mEvxkBVbH0sARYM=.747e3f9d-626d-43c7-8da8-2f5c7c2c821d@github.com>
References: <VDk-pjTiTr7BFWxpbV22_MjjCRh7mEvxkBVbH0sARYM=.747e3f9d-626d-43c7-8da8-2f5c7c2c821d@github.com>
Message-ID: <drkkUEoZdbyUe9ZHkKDNHAIJM5yZ0ln8NpSgdHRnZIA=.e24f0fad-e63b-48f9-8f48-8c96a44c9e58@github.com>

On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with JDK-8302801 was that it neglected (mea culpa) to include a Java implementation of IEEEremainder before the FDLIBM C implementation was deleted. Such an implementation has been successfully provided under JDK-8304028: Port fdlibm IEEEremainder to Java. After JDK-8304028, there are no native methods left in StrictMath.
> 
> This PR is the same as JDK-8302801 other than StrictMath.c already being removed under JDK-8304028.

This pull request has now been integrated.

Changeset: ccbb0e8d
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ccbb0e8d8927dff5a424717616468d05015cd002
Stats:     6516 lines in 64 files changed: 20 ins; 6486 del; 10 mod

8303798: REDO - Remove fdlibm C sources

Reviewed-by: alanb, iris, jwaters, erikj, kvn, dholmes

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

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

From jjg at openjdk.org  Tue Apr  4 00:13:20 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 4 Apr 2023 00:13:20 GMT
Subject: Integrated: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
In-Reply-To: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
Message-ID: <cU6-hY-ZFAn7XQ83SgGaTT-BsgqIhTus_Sj-XdFSzPE=.21e82408-ae57-4f06-9e51-cebd10d1efa5@github.com>

On Thu, 30 Mar 2023 17:24:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

This pull request has now been integrated.

Changeset: c6bd489c
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6bd489cc8d30fb6eec865b3dab1cf861e25c8d7
Stats:     270 lines in 60 files changed: 268 ins; 2 del; 0 mod

8305206: Add @spec tags in java.base/java.* (part 1)

Reviewed-by: alanb, naoto, darcy, lancea, dfuchs, iris, mchung

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

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

From qamai at openjdk.org  Tue Apr  4 00:59:21 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 4 Apr 2023 00:59:21 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
Message-ID: <BmyRfW4TbfVHEfQe_nkxQWzwsB35QLuK69_fw6FDJH4=.0032c600-b1f5-4c6c-ad54-1428c08fedb2@github.com>

On Fri, 31 Mar 2023 12:25:16 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small cosmetics

Thanks, may I integrate the changes now?

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

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1495191197

From psandoz at openjdk.org  Tue Apr  4 01:10:18 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 4 Apr 2023 01:10:18 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: <BmyRfW4TbfVHEfQe_nkxQWzwsB35QLuK69_fw6FDJH4=.0032c600-b1f5-4c6c-ad54-1428c08fedb2@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
 <BmyRfW4TbfVHEfQe_nkxQWzwsB35QLuK69_fw6FDJH4=.0032c600-b1f5-4c6c-ad54-1428c08fedb2@github.com>
Message-ID: <WsWtIiUL-CGRxmmXD6V0yOHVG1VtIfjrCxBBcQUUthQ=.5c744fd0-a360-4f1e-9496-b659326c0b6d@github.com>

On Tue, 4 Apr 2023 00:56:09 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Thanks, may I integrate the changes now?

You might need another HotSpot reviewer? @vnkozlov is that correct?

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

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1495198225

From iris at openjdk.org  Tue Apr  4 01:54:14 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 4 Apr 2023 01:54:14 GMT
Subject: RFR: 8305107: Emoji related binary properties in RegEx
In-Reply-To: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
Message-ID: <F61ux3s5-tBmXOa3RQ54mLcuG78LcElipew0-bgQ6Yk=.7865ae75-a5a6-46b5-a39e-e6cf660bbfde@github.com>

On Mon, 3 Apr 2023 22:58:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.

Associated CSR also Reviewed.

test/jdk/java/util/regex/RegExTest.java line 3827:

> 3825:                 POSIX_ASCII.isCntrl(cp)   != cntrl.reset(str).matches()  ||
> 3826:                 POSIX_Unicode.isCntrl(cp) != cntrlU.reset(str).matches() ||
> 3827:                 (CONTROL == type) != cntrlP.reset(str).matches() ||

I think this line may have lost the intended alignment of the "!=".

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13314#pullrequestreview-1370046964
PR Review Comment: https://git.openjdk.org/jdk/pull/13314#discussion_r1156628640

From xgong at openjdk.org  Tue Apr  4 02:40:12 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 4 Apr 2023 02:40:12 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v4]
In-Reply-To: <Hb8JZTxmiXR9lC0wUf7mPzDa3gcoTMQfsbqrZuu-UBk=.f8e1d2c5-86eb-4ce8-a57d-84be5d6733c4@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <Hb8JZTxmiXR9lC0wUf7mPzDa3gcoTMQfsbqrZuu-UBk=.f8e1d2c5-86eb-4ce8-a57d-84be5d6733c4@github.com>
Message-ID: <i5VqigHakGn3v5SOu8DD0hdwWwGD-Qt9ICxPobR8u3Q=.abc39fd5-92ee-4e69-b7cb-0717a654451d@github.com>

On Sat, 1 Apr 2023 07:44:25 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
>> 
>> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
>> 
>> Please take a look and have some reviews. Thank you very much.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - instruction asserts
>  - Merge branch 'master' into sliceIntrinsics
>  - add comments explaining anonymous classes
>  - address reviews
>  - sse2, increase warmup
>  - aesthetic
>  - optimise 64B
>  - add jmh
>  - vector slice intrinsics

src/hotspot/share/opto/vectorIntrinsics.cpp line 1935:

> 1933:     return false; // should be primitive type
> 1934:   }
> 1935:   BasicType elem_bt = elem_type->basic_type();

Code style: It's better to add a blank line between different blocks.

src/hotspot/share/opto/vectorIntrinsics.cpp line 1941:

> 1939:     if (C->print_intrinsics()) {
> 1940:       tty->print_cr("  ** not supported: arity=2 op=slice vlen=%d etype=%s ismask=notused",
> 1941:                     num_elem, type2name(elem_bt));

`ismask=notused` could be removed. We used `ismask` in other intrinsics to print whether it is a vector mask operation instead of vector class.

src/hotspot/share/opto/vectorIntrinsics.cpp line 1954:

> 1952:   if (v1 == NULL || v2 == NULL) {
> 1953:     return false; // operand unboxing failed
> 1954:   }

Suggest to reorder line-1950 and the if-statement in line-1952. And then we doesn't need too more spaces in the variable definition `Node* v1 = unbox_vector(xxx)`. Besides, could we rename variable `o` to `index` or `origin` ? I know you'v used `origin` at the begin, maybe we can rename it to `origin_type`. I see the similari name style in `inline_vector_frombits_coerced`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1156645453
PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1156646311
PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1156653402

From duke at openjdk.org  Tue Apr  4 03:07:24 2023
From: duke at openjdk.org (duke)
Date: Tue, 4 Apr 2023 03:07:24 GMT
Subject: Withdrawn: JDK-8301621: libzip should use pread instead of lseek+read
In-Reply-To: <pjSF1ED9D3FXjCFeqz2MRllCf0UT9suWaYa4O7kFeCM=.d16583a7-2c82-46c2-aaf1-2102c8978f2b@github.com>
References: <pjSF1ED9D3FXjCFeqz2MRllCf0UT9suWaYa4O7kFeCM=.d16583a7-2c82-46c2-aaf1-2102c8978f2b@github.com>
Message-ID: <GDPjBVFg2n2UrRhUow3TCMQ5KlksHb99DqyYNpyqsNc=.b3e18501-d025-4851-9c50-9560f4d9f236@github.com>

On Fri, 3 Feb 2023 19:49:44 GMT, Justin King <jcking at openjdk.org> wrote:

> Avoid using `lseek` + `read` in favor of `pread`. For Windows, we can do the same thing by using `OVERLAPPED`, as we are in synchronous mode we can use `Offset` and `OffsetHigh` to achieve the same thing.
> 
> Additionally I updated open to use `O_CLOEXEC` when available, as that really should be used.

This pull request has been closed without being integrated.

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

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

From jwaters at openjdk.org  Tue Apr  4 05:19:15 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 4 Apr 2023 05:19:15 GMT
Subject: RFR: 8305341: Alignment outside of HotSpot should be enforced by
 alignas instead of compiler specific attributes
In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
Message-ID: <JLSUGEppeJOjWysVOR-OD23yI7vcVId1lYrcgRXGu7Y=.d89b20ec-b6ab-4bc9-a732-abc0b50f9894@github.com>

On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

globalDefinitions_visCPP.hpp (and the corresponding globalDefinitions file for gcc based compilers) are both hotspot code, which require special review and are done in another Pull Request: https://github.com/openjdk/jdk/pull/11431

It would be great if Reviewers would take a look at that PR though...

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

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1495357119

From cjplummer at openjdk.org  Tue Apr  4 05:33:03 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 4 Apr 2023 05:33:03 GMT
Subject: RFR: 8305341: Alignment outside of HotSpot should be enforced by
 alignas instead of compiler specific attributes
In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
Message-ID: <yG0Qoi6EMyDS3cyN2whZGHaP_4gd23bk671ZGJHgIFo=.d7f7eafb-48ee-4499-b0db-942bf7f2f9e9@github.com>

On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

I'm not sure what you mean by hotspot requiring a special review, but serviceability code does require two reviewers just like hotspot does. Also, you don't need to split the PR because of that. If you get one person to review the jdk changes and 2 to review the hostpot/svc changes, then you are good to go.

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

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1495369012

From alanb at openjdk.org  Tue Apr  4 06:58:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Apr 2023 06:58:04 GMT
Subject: RFR: 8304982: Emit warning for removal of `COMPAT` provider [v2]
In-Reply-To: <DAPIvBszP49fQ1q_9v_onndEIpjFX2waXY_FA4-vups=.cd268216-7359-4071-aefd-543a1923cfdb@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
 <CTu8GEr7M96qN2VqCX0pcgkIgQnOLawY-9DvCTBqjjY=.00282dfc-2d97-40a3-b6ec-6efad774d573@github.com>
 <KrPf7Cdx49LrETjy7N__lBWsXbmji93laRgUpErHGVQ=.3d70ebd7-35c1-4c54-8343-d59ee4df7d77@github.com>
 <DAPIvBszP49fQ1q_9v_onndEIpjFX2waXY_FA4-vups=.cd268216-7359-4071-aefd-543a1923cfdb@github.com>
Message-ID: <pI6XSenNXSeDkGiioQ-1DCOEOpYBKxW47eF90uKTaHQ=.de3c3b1e-f1e2-48f6-9616-a22d8663adea@github.com>

On Mon, 3 Apr 2023 20:15:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Locale providers provided by users can all be loaded in the name of `SPI`, as they are the real implementation of `LocaleServiceProvider` class, so the order of the preference can be specified against JDK's `CLDR` provider. Does this answer your question?

There are two parts to this PR. One part is the deprecation of "COMPAT" with a warning if used, no issue there. The second part changes the text from "The JDK Reference Implementation .." to the end of the class description to be an implNote.  My concern is that is the system property "java.locale.providers" is introduced in the normative section but it doesn't say anything about values. It just says that it can be used to configure the user's preferred order. The possible names and everything about ordering is in the implNote section. To make this work is going to need some expansion of the text in the normative section to say that the value is a sequence of strings, separated by a comma. It will also need to say something about the names as they are implementation specific. Also what happens if I deploy two custom locale providers on the class path, which one is used as I don't think the system property covers that.

Maybe the right thing here is to drop "@implNote" (just the tag) from this PR so that the deprecation, warning, and the small adjustments to the class description are pushed out of the way. A follow-up PR could re-examine the class description and the description of the "java.locale.providers" property.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13302#discussion_r1156808106

From shade at openjdk.org  Tue Apr  4 09:26:10 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 4 Apr 2023 09:26:10 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v3]
In-Reply-To: <QCUHuRgMUXENoZ9r6Xwrsoz9LUlI5g1L8jBFwuiv5jU=.31220531-a579-4d41-82e4-d3d454f59a0a@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <QCUHuRgMUXENoZ9r6Xwrsoz9LUlI5g1L8jBFwuiv5jU=.31220531-a579-4d41-82e4-d3d454f59a0a@github.com>
Message-ID: <Ri_eufJ474fMNuOHikUcbRBgB2y-AHUsRjrtlEb_k38=.ed69b9f7-dc4d-4700-b8c9-fec0f8dded55@github.com>

On Mon, 3 Apr 2023 22:41:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
>> 
>> boolean alive() {
>>   return eetop != 0;
>> } 
>> 
>> I also updated a comment in relation to `eetop`.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure HB relationship exists; additional explanatory comments

src/java.base/share/classes/java/lang/Thread.java line 231:

> 229:     /* Reserved for exclusive use by the JVM. Cannot be moved to the FieldHolder
> 230:        as it needs to be set by the VM before executing the constructor that
> 231:        will create the FieldHolder. The historically named `eetop`holds the address

Suggestion:

       will create the FieldHolder. The historically named `eetop` holds the address

src/java.base/share/classes/java/lang/Thread.java line 1850:

> 1848:      * happens-before isAlive() returning false.
> 1849:      */
> 1850:     synchronized boolean alive() {

Ah. Yes, it needs to be synchronized on the same lock that VM uses, which is `this`.

But there is also a secondary issue fixed by this synchronization: without it, a simple `while (t.isAlive()) {}` loop would execute indefinitely, since `eetop` is going to be hoisted. This can be reproduced with the test below.

Consider adding it as `test/jdk/java/lang/Thread/IsAlive.java`:


/*
 * Copyright 2023, Amazon.com Inc. or its affiliates. All Rights Reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

/*
 * @test
 * @bug     8305425
 * @summary Check Thread.isAlive
 * @run main/othervm/timeout=10 IsAlive
 */

public class IsAlive {

    private static void spin() {
        try {
            while (!Thread.currentThread().isInterrupted()) {
                Thread.sleep(10);
            }
        } catch (InterruptedException ie) {
            // Do nothing, just exit
        }
    }

    static volatile boolean checkerReady;

    private static void check(Thread t) {
        while (!t.isAlive()) {
            // Burn hard, without any sleeps.
            // Check that we discover the thread is alive eventually.
        }

        checkerReady = true;

        while (t.isAlive()) {
            // Burn hard, without any sleeps.
            // Check that we discover the thread is not alive eventually.
        }
    }

    private static void assertAlive(Thread t) {
        if (!t.isAlive()) {
            throw new IllegalStateException("Thread " + t + " is not alive, but it should be");
        }
    }

    private static void assertNotAlive(Thread t) {
        if (t.isAlive()) {
            throw new IllegalStateException("Thread " + t + " is alive, but it should not be");
        }
    }

    public static void main(String args[]) throws Exception {
        Thread spinner = new Thread(IsAlive::spin);
        spinner.setName("Spinner");
        spinner.setDaemon(true);

        Thread checker = new Thread(() -> check(spinner));
        checker.setName("Checker");
        checker.setDaemon(true);

        assertNotAlive(spinner);
        assertNotAlive(checker);

        System.out.println("Starting spinner");
        spinner.start();
        assertAlive(spinner);

        System.out.println("Starting checker");
        checker.start();
        assertAlive(checker);

        System.out.println("Waiting for checker to catch up");
        while (!checkerReady) {
            Thread.sleep(100);
        }

        System.out.println("Interrupting and joining spinner");
        spinner.interrupt();
        spinner.join();
        assertNotAlive(spinner);

        System.out.println("Joining checker");
        checker.join();
        assertNotAlive(checker);

        System.out.println("Complete");
    }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1156901698
PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1156973465

From alanb at openjdk.org  Tue Apr  4 11:13:17 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Apr 2023 11:13:17 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v17]
In-Reply-To: <sMwYEg5s0F3O3g4ZHYrzemSltFgqvotVYNcfG1LNfJ8=.d4be632f-7d35-4111-98ca-d3c2a4d762ad@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <sMwYEg5s0F3O3g4ZHYrzemSltFgqvotVYNcfG1LNfJ8=.d4be632f-7d35-4111-98ca-d3c2a4d762ad@github.com>
Message-ID: <1ldWvL4BEm3OakDHZDeF3pgeXkvw8Wf8Zf9mvVqij1A=.1d75729f-926b-48e3-9502-42b086bb0901@github.com>

On Wed, 29 Mar 2023 01:40:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - cleanup test - rename method and update code comment as suggested by Alan
>  - Rename KNOWN_ENDIANNESS to PLATFORM_PROPERTIES

The jlink changes look okay and it improves the robustness when cross linking.

My preference would be to not change the CDSPluginTest.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/11943#pullrequestreview-1370740271

From alanb at openjdk.org  Tue Apr  4 11:13:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Apr 2023 11:13:18 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v16]
In-Reply-To: <ZzgFvwhr7OLv73zDXzHzlOxoPk5Cs04KZehq_MetjXE=.e72b958f-0333-4640-86bc-5dd85837c35a@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <jiN3_QFwCM43K42CHVop2o128cLMBkYCFXeVnJfljkM=.85b72b90-f1f3-4871-964f-84b5030ea82f@github.com>
 <_X148gAz795J-ExMjOAyvrykzc7a9vLdqg9pY2EaHKo=.40e38e68-013b-436e-bab0-933208fe4242@github.com>
 <ZzgFvwhr7OLv73zDXzHzlOxoPk5Cs04KZehq_MetjXE=.e72b958f-0333-4640-86bc-5dd85837c35a@github.com>
Message-ID: <Lc9n9aIcuWLCij2fdEk1Y6T8eUUuYORXdUdo-ZXizBM=.9a372f27-e696-4393-9643-4dbe5d90af5f@github.com>

On Wed, 29 Mar 2023 01:47:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/tools/jlink/plugins/CDSPluginTest.java line 97:
>> 
>>> 95:            // separate --module-path will force the JLink task to read the ModuleTarget from
>>> 96:            // the java.base module-info.class to identify the target platform for the image
>>> 97:            // being generated.
>> 
>> I'm a bit uncomfortable with change the test for the CDS plugin as part of this change but can live with it.
>
> Early on during this PR, we decided and implemented to read the `ModuleTarget` only if the java.base module's file path doesn't match that of the current platform's file path. If we remove that check and instead always read the ModuleTarget of java.base, in the JLinkTask, we won't need any changes to this test, since the JLinkTask will rightly find the correct target platform from the module-info.class. Furthermore, rest of the cross platform image generation would work fine too.
> 
> Do you think we should remove that file path check? I am guessing the reason why the file path checks were suggested was to reduce any chances of regression with these current changes?

My preference would be to drop this as it insane to run with -Dos.name=window set on Linux.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1157089625

From alanb at openjdk.org  Tue Apr  4 11:54:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Apr 2023 11:54:14 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v3]
In-Reply-To: <TeldqWpJMtC3H-RHFJvv0y7Ft3ke1Jt4i43KD9SrJgY=.9e260df1-986e-48ba-a78a-f37a25905fae@github.com>
References: <b2lIhVL1sHhnFTXvNSRBxxCd_b8KKUZz7mKWK1Zr6eY=.3d4fd0c8-a2b4-4510-bb6d-c68ad9de92bf@github.com>
 <Mx6DVvZla5YSXmLHoIjgObn8VuBKy-0iEfMsAHmJYNE=.4c7a893f-17ec-400b-bde7-70ec77983c4b@github.com>
 <I1BeB198LSEuC8Mkwx1zhT09Pfws5_i1nY7p7UhTk7s=.cf77a1c5-3bb3-4e4b-991b-c160031434c6@github.com>
 <TeldqWpJMtC3H-RHFJvv0y7Ft3ke1Jt4i43KD9SrJgY=.9e260df1-986e-48ba-a78a-f37a25905fae@github.com>
Message-ID: <aCjTHNCK8PuJgPM39GYLmXP1DOo3Eld5ZT-zbdpy7ng=.14763829-46cf-4940-b5f3-f3005eb7a197@github.com>

On Mon, 27 Mar 2023 15:24:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I skimmed through the latest version but there are still several issues.  Can you try the patch below instead? This will ensure that read, skip, reset, etc. check buf as before. It also ensures that read1 does the same threshold check as it has always done - your patch changes that in a subtle way and I think we have to be careful with behavior changes to this really old API.
>> 
>> To Eirik's comment about benchmarks. This change is about memory footprint and lazily creating the internal buffer. A good example is the BIS on stdin which has an 8k buffer that is only needed if something reads from System.in. There may be a few more like this. The other case is a large read where BIS will delegate to the wrapped stream when it doesn't have any bytes buffered. It would be useful to get some data on cases where it helps (the BIS wrapping BIS only works when the enclosing BIS has the same or larger buffer than the enclosed BIS).
>> 
>> 
>> --- a/src/java.base/share/classes/java/io/BufferedInputStream.java
>> +++ b/src/java.base/share/classes/java/io/BufferedInputStream.java
>> @@ -57,6 +57,8 @@ public class BufferedInputStream extends FilterInputStream {
>>  
>>      private static final int DEFAULT_BUFFER_SIZE = 8192;
>>  
>> +    private static final byte[] EMPTY = new byte[0];
>> +
>>      /**
>>       * As this class is used early during bootstrap, it's motivated to use
>>       * Unsafe.compareAndSetObject instead of AtomicReferenceFieldUpdater
>> @@ -70,6 +72,9 @@ public class BufferedInputStream extends FilterInputStream {
>>      // initialized to null when BufferedInputStream is sub-classed
>>      private final InternalLock lock;
>>  
>> +    // initial buffer size (DEFAULT_BUFFER_SIZE or size specified to constructor)
>> +    private final int initialSize;
>> +
>>      /**
>>       * The internal buffer array where the data is stored. When necessary,
>>       * it may be replaced by another array of
>> @@ -166,16 +171,42 @@ public class BufferedInputStream extends FilterInputStream {
>>      }
>>  
>>      /**
>> -     * Check to make sure that buffer has not been nulled out due to
>> -     * close; if not return it;
>> +     * Returns the internal buffer, optionally allocating it if empty.
>> +     * @param allocateIfEmpty true to allocate if empty
>> +     * @throws IOException if the stream is closed (buf is null)
>>       */
>> -    private byte[] getBufIfOpen() throws IOException {
>> +    private byte[] getBufIfOpen(boolean allocateIfEmpty) throws IOException {
>>          byte[] buffer = buf;
>> -        if (buffer == null)
>> +        if (allocateIfEmpty && buffer == EMPTY) {
>> +            buffer = new byte[initialSize];
>> +            if (!U.compareAndSetReference(this, BUF_OFFSET, EMPTY, buffer)) {
>> +                // re-read buf
>> +                buffer = buf;
>> +            }
>> +        }
>> +        if (buffer == null) {
>>              throw new IOException("Stream closed");
>> +        }
>>          return buffer;
>>      }
>>  
>> +    /**
>> +     * Returns the internal buffer, allocating it if empty.
>> +     * @throws IOException if the stream is closed (buf is null)
>> +     */
>> +    private byte[] getBufIfOpen() throws IOException {
>> +        return getBufIfOpen(true);
>> +    }
>> +
>> +    /**
>> +     * Throws IOException if the stream is closed (buf is null).
>> +     */
>> +    private void ensureOpen() throws IOException {
>> +        if (buf == null) {
>> +            throw new IOException("Stream closed");
>> +        }
>> +    }
>> +
>>      /**
>>       * Creates a {@code BufferedInputStream}
>>       * and saves its  argument, the input stream
>> @@ -205,13 +236,15 @@ public class BufferedInputStream extends FilterInputStream {
>>          if (size <= 0) {
>>              throw new IllegalArgumentException("Buffer size <= 0");
>>          }
>> -        buf = new byte[size];
>> -
>> -        // use monitors when BufferedInputStream is sub-classed
>> +        initialSize = size;
>>          if (getClass() == BufferedInputStream.class) {
>> +            // use internal lock and lazily create buffer when not subclassed
>>              lock = InternalLock.newLockOrNull();
>> +            buf = EMPTY;
>>          } else {
>> +            // use monitors and eagerly create buffer when subclassed
>>              lock = null;
>> +            buf = new byte[size];
>>          }
>>      }
>>  
>> @@ -307,7 +340,8 @@ public class BufferedInputStream extends FilterInputStream {
>>                 if there is no mark/reset activity, do not bother to copy the
>>                 bytes into the local buffer.  In this way buffered streams will
>>                 cascade harmlessly. */
>> -            if (len >= getBufIfOpen().length && markpos == -1) {
>> +            int size = Math.max(getBufIfOpen(false).length, initialSize);
>> +            if (len >= size && markpos == -1) {
>>                  return getInIfOpen().read(b, off, len);
>>              }
>>              fill();
>> @@ -374,7 +408,7 @@ public class BufferedInputStream extends FilterInputStream {
>>      }
>>  
>>      private int implRead(byte[] b, int off, int len) throws IOException {
>> -        getBufIfOpen(); // Check for closed stream
>> +        ensureOpen();
>>          if ((off | len | (off + len) | (b.length - (off + len))) < 0) {
>>              throw new IndexOutOfBoundsException();
>>          } else if (len == 0) {
>> @@ -421,7 +455,7 @@ public class BufferedInputStream extends FilterInputStream {
>>      }
>>  
>>      private long implSkip(long n) throws IOException {
>> -        getBufIfOpen(); // Check for closed stream
>> +        ensureOpen();
>>          if (n <= 0) {
>>              return 0;
>>          }
>> @@ -544,7 +578,7 @@ public class BufferedInputStream extends FilterInputStream {
>>      }
>>  
>>      private void implReset() throws IOException {
>> -        getBufIfOpen(); // Cause exception if closed
>> +        ensureOpen();
>>          if (markpos < 0)
>>              throw new IOException("Resetting to invalid mark");
>>          pos = markpos;
>
>> Can you try the patch below instead? This will ensure that read, skip, reset, etc. check buf as before.
> 
> I think that the implementation provided by @AlanBateman looks good.

The BIS changes in this PR looks okay. I can't be Reviewer for that part because I provided the current changes. @bplb tells me that he will review.

I don't have strong views on the benchmark. The main benefit of the lazy allocation is, in my view, for cases where a BIS is created and either not used, or the first usage is long after it is created.  We see this with System.in but it's possible that most BIS usages involve a read soon after the BIS is created. The other scenario is the subtle optimization to bypass the internal buffer. This only works in the benchmark because readAllBytes uses a 16k buffer.

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

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1495839430

From aturbanov at openjdk.org  Tue Apr  4 12:35:19 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 4 Apr 2023 12:35:19 GMT
Subject: RFR: 8305538: Avoid redundant HashMap.containsKey call in
 ModuleDescriptor.Builder
Message-ID: <cwKHk3sU2rRXKv4jNF2Biij7dPqlFQva3hBb8ZlVm-4=.18a6501d-db9d-44f4-9297-4e6dfa39c2e8@github.com>

`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.

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

Commit messages:
 - [PATCH] Avoid redundant HashMap.containsKey call in ModuleDescriptor

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

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

From aturbanov at openjdk.org  Tue Apr  4 12:40:05 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 4 Apr 2023 12:40:05 GMT
Subject: RFR: 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: <E07Ny-COtulL3RUVAUMdCvsZdsu2z6Qde6o9nmM0Qas=.bc7b12d6-c35a-4422-9de2-a36fd688fa53@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.

Seems we can update `java.lang.module.ModuleDescriptor.Builder#uses` too to directly call `add` instead of `contains`+`add`

https://github.com/openjdk/jdk/blob/5881b099f6c23c9e8329af20a18f476d659f0079/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java#L2015-L2018

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

PR Comment: https://git.openjdk.org/jdk/pull/13288#issuecomment-1495899800

From qamai at openjdk.org  Tue Apr  4 13:24:18 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 4 Apr 2023 13:24:18 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v5]
In-Reply-To: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
Message-ID: <fvpYPqmvn60WF8F7uDReTq2ZGUS-a-1LhKEEgD_lIxs=.892de878-23e8-4009-9d63-6577929a43b4@github.com>

> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
> 
> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
> 
> Please take a look and have some reviews. Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  add identity, fix flags

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12909/files
  - new: https://git.openjdk.org/jdk/pull/12909/files/bedb73bd..e68e215d

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

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

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

From rgiulietti at openjdk.org  Tue Apr  4 13:33:06 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 4 Apr 2023 13:33:06 GMT
Subject: RFR: 8305343: BigDecimal.fractionOnly() erroneously returns true for
 large scale value
Message-ID: <lu95OdgQj6d4EkFa3gxgVcE1knojEAX5piG5B8t4yjo=.02826750-5b48-4392-818b-f3264e98773c@github.com>

A fix for the issue and additional specific tests.

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

Commit messages:
 - 8305343: BigDecimal.fractionOnly() erroneously returns true for large scale value

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

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

From rriggs at openjdk.org  Tue Apr  4 13:36:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Apr 2023 13:36:19 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v16]
In-Reply-To: <Lc9n9aIcuWLCij2fdEk1Y6T8eUUuYORXdUdo-ZXizBM=.9a372f27-e696-4393-9643-4dbe5d90af5f@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <jiN3_QFwCM43K42CHVop2o128cLMBkYCFXeVnJfljkM=.85b72b90-f1f3-4871-964f-84b5030ea82f@github.com>
 <_X148gAz795J-ExMjOAyvrykzc7a9vLdqg9pY2EaHKo=.40e38e68-013b-436e-bab0-933208fe4242@github.com>
 <ZzgFvwhr7OLv73zDXzHzlOxoPk5Cs04KZehq_MetjXE=.e72b958f-0333-4640-86bc-5dd85837c35a@github.com>
 <Lc9n9aIcuWLCij2fdEk1Y6T8eUUuYORXdUdo-ZXizBM=.9a372f27-e696-4393-9643-4dbe5d90af5f@github.com>
Message-ID: <eTSuqtrCNvsGBVW9jOlC0SMcTX2c_0kTCK87Wbhve80=.3b893f55-4765-4be6-be54-b48f159ba05d@github.com>

On Tue, 4 Apr 2023 11:09:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Early on during this PR, we decided and implemented to read the `ModuleTarget` only if the java.base module's file path doesn't match that of the current platform's file path. If we remove that check and instead always read the ModuleTarget of java.base, in the JLinkTask, we won't need any changes to this test, since the JLinkTask will rightly find the correct target platform from the module-info.class. Furthermore, rest of the cross platform image generation would work fine too.
>> 
>> Do you think we should remove that file path check? I am guessing the reason why the file path checks were suggested was to reduce any chances of regression with these current changes?
>
> My preference would be to drop this as it insane to run with -Dos.name=window set on Linux.

I'm working on an update to jlink to use jdk.internal.misc.OperatingSystem instead of os.name (PR #12931), setting os.name on the command line will have no effect. (The test will be updated or removed).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1157265431

From qamai at openjdk.org  Tue Apr  4 13:46:12 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 4 Apr 2023 13:46:12 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v6]
In-Reply-To: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
Message-ID: <mvjXG43i2H0ULxXam6DzZR6SPrVjyth_x4Fu7CTjmE0=.04f5e64d-54bd-4556-bc46-212552526853@github.com>

> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
> 
> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
> 
> Please take a look and have some reviews. Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12909/files
  - new: https://git.openjdk.org/jdk/pull/12909/files/e68e215d..a17942f5

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

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

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

From aturbanov at openjdk.org  Tue Apr  4 13:48:06 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 4 Apr 2023 13:48:06 GMT
Subject: RFR: 8305107: Emoji related binary properties in RegEx
In-Reply-To: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
Message-ID: <y4OhV7jF8wscCbGEAVqH7fXG6cpRC-RaZRDm7DwI4-0=.65e27044-74fc-4971-bad9-e1b61eb72d64@github.com>

On Mon, 3 Apr 2023 22:58:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.

test/jdk/java/util/regex/RegExTest.java line 3774:

> 3772:         Matcher emojiPP = Pattern.compile("\\p{IsEmoji_Presentation}").matcher("");
> 3773:         Matcher emojiMP = Pattern.compile("\\p{IsEmoji_Modifier}").matcher("");
> 3774:         Matcher emojiMBP = Pattern.compile("\\p{IsEmoji_Modifier_Base}").matcher("");

Let's align to this assignment. Or remove alignments completely.

test/jdk/java/util/regex/RegExTest.java line 3851:

> 3849:                 POSIX_Unicode.isJoinControl(cp) != joinCrtl.reset(str).matches() ||
> 3850:                 // Emoji properties
> 3851:                 isEmoji(cp)     != emojiP.reset(str).matches() ||

Suggestion:

                isEmoji(cp) != emojiP.reset(str).matches() ||

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13314#discussion_r1157280360
PR Review Comment: https://git.openjdk.org/jdk/pull/13314#discussion_r1157280914

From asotona at openjdk.org  Tue Apr  4 13:57:07 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 4 Apr 2023 13:57:07 GMT
Subject: RFR: 8304937: BufferedFieldBuilder.Model missing
 writeTo(DirectClassBuilder)
In-Reply-To: <Dtm7oPGvT5GfxpBgOFDSRgtDsLsKLaaIL8Amip1bhuw=.e9aa02b1-9022-4d8a-82a1-8fa00ab2a407@github.com>
References: <Dtm7oPGvT5GfxpBgOFDSRgtDsLsKLaaIL8Amip1bhuw=.e9aa02b1-9022-4d8a-82a1-8fa00ab2a407@github.com>
Message-ID: <IWv63LTSfT-22FeX69zjP3u9Ek3bnFDXvefO-PiMbX4=.127f7f72-364b-42ad-9b6c-cc826a948592@github.com>

On Sun, 26 Mar 2023 20:35:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this simple patch to Classfile API that fixes a missing override that otherwise affects usage of chained class transforms. A test is included, that it fails on the missing method without this patch.
> 
> Please review a few other patches fixing bugs affecting normal usage of the Classfile API as well:
> #13167 #13021 #12996
> 
> I am trying to write a test for my in-progress patch to unify parameter mapping in core reflection in anticipation of #9862, however this bug prevents me from dropping method Signature and MethodParameters attributes with chained class transforms.

It looks good, thanks for catching and fixing it.

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

Marked as reviewed by asotona (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13187#pullrequestreview-1371053123

From alanb at openjdk.org  Tue Apr  4 14:00:17 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Apr 2023 14:00:17 GMT
Subject: RFR: 8305538: Avoid redundant HashMap.containsKey call in
 ModuleDescriptor.Builder
In-Reply-To: <E07Ny-COtulL3RUVAUMdCvsZdsu2z6Qde6o9nmM0Qas=.bc7b12d6-c35a-4422-9de2-a36fd688fa53@github.com>
References: <cwKHk3sU2rRXKv4jNF2Biij7dPqlFQva3hBb8ZlVm-4=.18a6501d-db9d-44f4-9297-4e6dfa39c2e8@github.com>
 <E07Ny-COtulL3RUVAUMdCvsZdsu2z6Qde6o9nmM0Qas=.bc7b12d6-c35a-4422-9de2-a36fd688fa53@github.com>
Message-ID: <oh7yFjQ5yHqs6a6nh5TfZoe7YAFEXnL9VDMaZQyfetQ=.27bc4ba7-0fcc-4033-8021-b91be71c8d06@github.com>

On Tue, 4 Apr 2023 12:37:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Seems we can update `java.lang.module.ModuleDescriptor.Builder#uses` too to directly call `add` instead of `contains`+`add`

If you are changing uses(String) then it should obey `strict`, meaning put this at the beginning of the method


if (strict) {
    requireServiceTypeName(service);
}

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

PR Comment: https://git.openjdk.org/jdk/pull/13288#issuecomment-1496022557

From qamai at openjdk.org  Tue Apr  4 14:57:18 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 4 Apr 2023 14:57:18 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v4]
In-Reply-To: <LoOoz2KdvmlNtfJy3Sv7m6EHZpCnVcaMdkFjZ0VFc-g=.a2e2fc2c-d421-4152-b410-7311219f634a@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <Hb8JZTxmiXR9lC0wUf7mPzDa3gcoTMQfsbqrZuu-UBk=.f8e1d2c5-86eb-4ce8-a57d-84be5d6733c4@github.com>
 <LoOoz2KdvmlNtfJy3Sv7m6EHZpCnVcaMdkFjZ0VFc-g=.a2e2fc2c-d421-4152-b410-7311219f634a@github.com>
Message-ID: <jlBV1NPgxhkBpM6R1wsPjFALJHy_BP1Gj1t84sWVDv8=.e430354a-123b-4b6b-986c-9402c68f7e13@github.com>

On Mon, 3 Apr 2023 16:36:08 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - instruction asserts
>>  - Merge branch 'master' into sliceIntrinsics
>>  - add comments explaining anonymous classes
>>  - address reviews
>>  - sse2, increase warmup
>>  - aesthetic
>>  - optimise 64B
>>  - add jmh
>>  - vector slice intrinsics
>
> With the latest PR I am observing failures with debug builds for test compiler/vectorapi/TestVectorSlice.java on both AVX512 machines and aarch64 machines.
> 
> On AVX512 machines the test fails with JVM args `-XX:UseAVX=3` and `-XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting` and results in a test assertion failure e.g.,
> 
> Caused by: java.lang.RuntimeException: assertEquals: expected 70 to equal 0
> 	at jdk.test.lib.Asserts.fail(Asserts.java:594)
> 	at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
> 	at jdk.test.lib.Asserts.assertEquals(Asserts.java:189)
> 	at compiler.vectorapi.TestVectorSlice.lambda$testInts$2(TestVectorSlice.java:163)
> 	at compiler.vectorapi.TestVectorSlice.testInts(TestVectorSlice.java:181)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	... 7 more
> 
> 
> CPU flags are:
> 
> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant tsc arch perfmon rep good nopl xtopology cpuid tsc known freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4 1 sse4 2 x2apic movbe popcnt tsc deadline timer aes xsave avx f16c rdrand hypervisor lahf lm abm 3dnowprefetch cpuid fault invpcid single ssbd ibrs ibpb stibp ibrs enhanced tpr shadow vnmi flexpriority ept vpid ept ad fsgsbase tsc adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves nt good wbnoinvd arat avx512vbmi umip pku ospke avx512 vbmi2 gfni vaes vpclmulqdq avx512 vnni avx512 bitalg avx512 vpopcntdq la57 rdpid md clear arch capabilities
> 
> 
> On aarch64 there is an IR rule failure.

@PaulSandoz I have fixed the error in AVX512 and added feature predicates to not do IR check on AArch64
@XiaohongGong Thanks for your reviews, I have addressed them

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

PR Comment: https://git.openjdk.org/jdk/pull/12909#issuecomment-1496115432

From jlaskey at openjdk.org  Tue Apr  4 15:16:19 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 4 Apr 2023 15:16:19 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v53]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <8IomKDUZEGYuWO0jwzX6b3C5oQH9aknVWeGtaRySXDs=.d229cb1f-3635-4992-838b-c521a8975062@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  RuntimeException is the only exception type that can is deduced from a lambda.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/67ffbccc..6274eb3f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=52
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=51-52

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

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

From forax at openjdk.org  Tue Apr  4 15:24:53 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 4 Apr 2023 15:24:53 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v53]
In-Reply-To: <8IomKDUZEGYuWO0jwzX6b3C5oQH9aknVWeGtaRySXDs=.d229cb1f-3635-4992-838b-c521a8975062@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <8IomKDUZEGYuWO0jwzX6b3C5oQH9aknVWeGtaRySXDs=.d229cb1f-3635-4992-838b-c521a8975062@github.com>
Message-ID: <FI5_yLnJFsWtW5ZSRNsl-wluIt9cEPBJPFr1QLCYCwY=.dacd6d62-dfd9-4b9f-959a-89317e95a40c@github.com>

On Tue, 4 Apr 2023 15:16:19 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   RuntimeException is the only exception type that can is deduced from a lambda.

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 70:

> 68:          * null.
> 69:          */
> 70:         int hashcode;

All the fields of the keys should be final, otherwise a publication problem can occur (the key is visible from another thread but its fields are not yet initialized)

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 100:

> 98:         try {
> 99:             return (List<Object>)valuesMH.invokeExact(this);
> 100:         } catch (Throwable ex) {

Errors likes OutOfMemoryError and runtime exception should be rethrown instead of being wrapped

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 109:

> 107:         try {
> 108:             return (String)interpolateMH.invokeExact(this);
> 109:         } catch (Throwable ex) {

see above

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1157415311
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1157417666
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1157417849

From forax at openjdk.org  Tue Apr  4 15:35:01 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 4 Apr 2023 15:35:01 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v53]
In-Reply-To: <8IomKDUZEGYuWO0jwzX6b3C5oQH9aknVWeGtaRySXDs=.d229cb1f-3635-4992-838b-c521a8975062@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <8IomKDUZEGYuWO0jwzX6b3C5oQH9aknVWeGtaRySXDs=.d229cb1f-3635-4992-838b-c521a8975062@github.com>
Message-ID: <6F3EPwqwVYV2OJhfvYrSaz7M0QIswDq2c0Besicj20U=.b3c8d68b-f41b-4110-b37d-b362148eb599@github.com>

On Tue, 4 Apr 2023 15:16:19 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   RuntimeException is the only exception type that can is deduced from a lambda.

src/java.base/share/classes/java/lang/StringTemplate.java line 577:

> 575:          */
> 576:         static <R> Processor<R, RuntimeException> of(Function<StringTemplate, R> process) {
> 577:             return process::apply;

The wildcards are missing :)

static <R> Processor<R, RuntimeException> of(Function<? super StringTemplate, ? extends R> process) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1157431904

From psandoz at openjdk.org  Tue Apr  4 15:47:07 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 4 Apr 2023 15:47:07 GMT
Subject: RFR: 8305461: [vectorapi] Add VectorMask::xor
In-Reply-To: <3qsNbKA1cm_XZnUNTDApkZDGMBq6PXcXZBTvEdv9UC4=.5dc8fed0-684e-4cd1-a007-d5e0c3cd0a65@github.com>
References: <3qsNbKA1cm_XZnUNTDApkZDGMBq6PXcXZBTvEdv9UC4=.5dc8fed0-684e-4cd1-a007-d5e0c3cd0a65@github.com>
Message-ID: <jwSNj78SkdTEkWtny9s7dV1VH1RA8qYV1ZD2tONFj0Q=.98bb0702-3d1b-4232-9f69-6f4bcd0d8e4d@github.com>

On Sat, 1 Apr 2023 15:40:14 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch adds `VectorMask.xor` to the public interface of `VectorMask`. This method has already been existed in each concrete mask classes.
> 
> Please kindly review.
> Thanks a lot.

Thank you for doing this. I am guessing it was always intended to be public but was not spotted in previous reviews.

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

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13277#pullrequestreview-1371284175

From jlaskey at openjdk.org  Tue Apr  4 15:52:41 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 4 Apr 2023 15:52:41 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v53]
In-Reply-To: <FI5_yLnJFsWtW5ZSRNsl-wluIt9cEPBJPFr1QLCYCwY=.dacd6d62-dfd9-4b9f-959a-89317e95a40c@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <8IomKDUZEGYuWO0jwzX6b3C5oQH9aknVWeGtaRySXDs=.d229cb1f-3635-4992-838b-c521a8975062@github.com>
 <FI5_yLnJFsWtW5ZSRNsl-wluIt9cEPBJPFr1QLCYCwY=.dacd6d62-dfd9-4b9f-959a-89317e95a40c@github.com>
Message-ID: <74cTZBH2HGtXITYb_G_6sdTPvqTs4V45Pg_8rpJv5AA=.7b50958d-fe2a-463a-bb1f-3759e9f82d6a@github.com>

On Tue, 4 Apr 2023 15:18:43 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   RuntimeException is the only exception type that can is deduced from a lambda.
>
> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 70:
> 
>> 68:          * null.
>> 69:          */
>> 70:         int hashcode;
> 
> All the fields of the keys should be final, otherwise a publication problem can occur (the key is visible from another thread but its fields are not yet initialized)

Changing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1157453484

From bpb at openjdk.org  Tue Apr  4 16:00:46 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 4 Apr 2023 16:00:46 GMT
Subject: Integrated: 8298619: java/io/File/GetXSpace.java is failing
In-Reply-To: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
Message-ID: <hD7B44iPwi6SJ3iK5Oq6dJTlqMM_ZWUukOGCCs8LueY=.d3afdc64-2ff6-4bd9-8669-0644a1c14ee6@github.com>

On Fri, 3 Feb 2023 02:02:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify the `Space` instances used for size comparison to be created with total number of bytes derived from the Windows `diskFree` utility instead of Cygwin?s `df`.

This pull request has now been integrated.

Changeset: 3ef834fc
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ef834fc6fc245accffc41da714358fc82f22657
Stats:     315 lines in 3 files changed: 211 ins; 60 del; 44 mod

8298619: java/io/File/GetXSpace.java is failing

Reviewed-by: rriggs

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

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

From jlaskey at openjdk.org  Tue Apr  4 16:01:42 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 4 Apr 2023 16:01:42 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v53]
In-Reply-To: <6F3EPwqwVYV2OJhfvYrSaz7M0QIswDq2c0Besicj20U=.b3c8d68b-f41b-4110-b37d-b362148eb599@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <8IomKDUZEGYuWO0jwzX6b3C5oQH9aknVWeGtaRySXDs=.d229cb1f-3635-4992-838b-c521a8975062@github.com>
 <6F3EPwqwVYV2OJhfvYrSaz7M0QIswDq2c0Besicj20U=.b3c8d68b-f41b-4110-b37d-b362148eb599@github.com>
Message-ID: <S-vNyonwJvpSSTOTpocL3sf60FrE0FWqFOMwbUA0FZU=.d7f1c249-7b58-4c66-b03b-38324ecdd28a@github.com>

On Tue, 4 Apr 2023 15:31:12 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   RuntimeException is the only exception type that can is deduced from a lambda.
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 577:
> 
>> 575:          */
>> 576:         static <R> Processor<R, RuntimeException> of(Function<StringTemplate, R> process) {
>> 577:             return process::apply;
> 
> The wildcards are missing :)
> 
> static <R> Processor<R, RuntimeException> of(Function<? super StringTemplate, ? extends R> process) {

Changing

> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 100:
> 
>> 98:         try {
>> 99:             return (List<Object>)valuesMH.invokeExact(this);
>> 100:         } catch (Throwable ex) {
> 
> Errors likes OutOfMemoryError and runtime exception should be rethrown instead of being wrapped

Changing

> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 109:
> 
>> 107:         try {
>> 108:             return (String)interpolateMH.invokeExact(this);
>> 109:         } catch (Throwable ex) {
> 
> see above

Changing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1157464394
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1157459830
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1157460255

From jlaskey at openjdk.org  Tue Apr  4 16:07:54 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 4 Apr 2023 16:07:54 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v54]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <BSADnCP_cZkZnwJDnznJ3T8PbB0IF6_xF_wuEJv7Pc0=.b8c1654a-6fe1-487e-9095-b4a5f2bcd22d@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Recommended changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/6274eb3f..4c6d70d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=53
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=52-53

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

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

From andrew at openjdk.org  Tue Apr  4 16:21:37 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 4 Apr 2023 16:21:37 GMT
Subject: RFR: 8305113: (tz) Update Timezone Data to 2023c [v3]
In-Reply-To: <vTLYpNzwdiTkdNdsHyDC9iRA8GMLIov2-ASJi8ARaiY=.6797783d-5bd7-4093-910b-e4da9691817f@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
 <vTLYpNzwdiTkdNdsHyDC9iRA8GMLIov2-ASJi8ARaiY=.6797783d-5bd7-4093-910b-e4da9691817f@github.com>
Message-ID: <1ATbpv7Q-diFv252WtjRSpLN1fbXHjMsMQQIta7junU=.d3edb88a-fe7b-4752-94fd-36eab10a974d@github.com>

On Mon, 3 Apr 2023 23:40:05 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> Pleases review this PR. 
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.
>
> Yoshiki Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert formatted code in ZoneInfoFile.java
>  - fixing typo again

Looks good to me. Interesting that `TimeZoneNames.java` already has the `MSK` change for the other timezone that was changed, `Europe/Volgograd`

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

Marked as reviewed by andrew (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13255#pullrequestreview-1371346092

From naoto at openjdk.org  Tue Apr  4 16:49:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 16:49:12 GMT
Subject: RFR: 8305113: (tz) Update Timezone Data to 2023c [v3]
In-Reply-To: <vTLYpNzwdiTkdNdsHyDC9iRA8GMLIov2-ASJi8ARaiY=.6797783d-5bd7-4093-910b-e4da9691817f@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
 <vTLYpNzwdiTkdNdsHyDC9iRA8GMLIov2-ASJi8ARaiY=.6797783d-5bd7-4093-910b-e4da9691817f@github.com>
Message-ID: <5hGSIiG3mi9eIPNFV2IMhnkdlGKqmKQMzElwVbZ1bTA=.4657e94f-8c03-4de0-a95b-8677c879965c@github.com>

On Mon, 3 Apr 2023 23:40:05 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> Pleases review this PR. 
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.
>
> Yoshiki Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert formatted code in ZoneInfoFile.java
>  - fixing typo again

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13255#pullrequestreview-1371389824

From bpb at openjdk.org  Tue Apr  4 17:06:18 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 4 Apr 2023 17:06:18 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v9]
In-Reply-To: <nFcbtXLuQHniBrOTa-1Iupa6-BuWo4f_ouLWCMKOv24=.01434cb5-1859-4c08-bdc0-307fab5e3d69@github.com>
References: <b2lIhVL1sHhnFTXvNSRBxxCd_b8KKUZz7mKWK1Zr6eY=.3d4fd0c8-a2b4-4510-bb6d-c68ad9de92bf@github.com>
 <nFcbtXLuQHniBrOTa-1Iupa6-BuWo4f_ouLWCMKOv24=.01434cb5-1859-4c08-bdc0-307fab5e3d69@github.com>
Message-ID: <btTGBk3xOrAqBiNLnNPyF-5rg9bH6rozEYVJ7U85yAA=.2d6630e5-7054-429b-bc82-5017f356ceec@github.com>

On Mon, 27 Mar 2023 16:18:22 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304745: Add comments for benchmark

Looks all right.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13150#pullrequestreview-1371418039

From darcy at openjdk.org  Tue Apr  4 17:07:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 4 Apr 2023 17:07:09 GMT
Subject: RFR: 8305343: BigDecimal.fractionOnly() erroneously returns true
 for large scale value
In-Reply-To: <lu95OdgQj6d4EkFa3gxgVcE1knojEAX5piG5B8t4yjo=.02826750-5b48-4392-818b-f3264e98773c@github.com>
References: <lu95OdgQj6d4EkFa3gxgVcE1knojEAX5piG5B8t4yjo=.02826750-5b48-4392-818b-f3264e98773c@github.com>
Message-ID: <NiB8NefTO6LIPHnW6i8to7qmL58gqmXDDbCqvTlUhoQ=.8e7c665e-bf62-4c9c-9ded-4a055790a94b@github.com>

On Tue, 4 Apr 2023 13:25:44 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> A fix for the issue and additional specific tests.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13326#pullrequestreview-1371418773

From bpb at openjdk.org  Tue Apr  4 17:07:19 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 4 Apr 2023 17:07:19 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v9]
In-Reply-To: <nFcbtXLuQHniBrOTa-1Iupa6-BuWo4f_ouLWCMKOv24=.01434cb5-1859-4c08-bdc0-307fab5e3d69@github.com>
References: <b2lIhVL1sHhnFTXvNSRBxxCd_b8KKUZz7mKWK1Zr6eY=.3d4fd0c8-a2b4-4510-bb6d-c68ad9de92bf@github.com>
 <nFcbtXLuQHniBrOTa-1Iupa6-BuWo4f_ouLWCMKOv24=.01434cb5-1859-4c08-bdc0-307fab5e3d69@github.com>
Message-ID: <btTGBk3xOrAqBiNLnNPyF-5rg9bH6rozEYVJ7U85yAA=.f2fddfbd-fa54-4d2d-a979-f18f3b0f83fd@github.com>

On Mon, 27 Mar 2023 16:18:22 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304745: Add comments for benchmark

Looks all right.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13150#pullrequestreview-1371418039

From naoto at openjdk.org  Tue Apr  4 17:10:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 17:10:09 GMT
Subject: RFR: 8305107: Emoji related binary properties in RegEx [v2]
In-Reply-To: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
Message-ID: <dXZYF3W2xBs1XKuQIyFSXSE6312C807ORXNmdXiwXOU=.d3cbcfcc-bc11-43a2-be83-15128d55b1a8@github.com>

> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.

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

  indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13314/files
  - new: https://git.openjdk.org/jdk/pull/13314/files/7a8a821c..41cfe460

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

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

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

From naoto at openjdk.org  Tue Apr  4 17:10:27 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 17:10:27 GMT
Subject: RFR: 8305107: Emoji related binary properties in RegEx
In-Reply-To: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
Message-ID: <XOPmRyPdwhuCh139oRJVCH9wu1sTDax-UjQfw-cY2tQ=.9390d89c-657b-4423-833b-480d71e5c85a@github.com>

On Mon, 3 Apr 2023 22:58:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.

Thanks, Iris, Andrey. Alignment corrected.

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

PR Comment: https://git.openjdk.org/jdk/pull/13314#issuecomment-1496318682

From liach at openjdk.org  Tue Apr  4 17:22:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Apr 2023 17:22:11 GMT
Subject: RFR: 8284871: Use covariant overrides for the
 resolveConstantDesc(Lookup) method in =?UTF-8?B?c3Vi4oCRaW50ZXJmYWNlcw==?= of
 java.lang.constant.ConstantDesc [v3]
In-Reply-To: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
References: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
Message-ID: <H7F0BJUl1P_mra_MSOPg_uVv_JdBxyS1ulS2_guX3yI=.3dc19464-9a2b-462c-8976-e13853d84c9e@github.com>

> Also remove redundant casts to avoid javac warnings.

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

 - Retain a general note in ConstantDesc
 - Merge branch 'master' into constdesc-override
 - Update tests to remove useless casts and update copyright year
 - Merge branch 'master' into constdesc-override
 - Move MethodTypeDesc api notes to MethodTypeDesc
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into constdesc-override
 - Remove redundant casts
 - Covariant override of resolveConstantDesc for Class/MethodType/MethodHandleDesc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12986/files
  - new: https://git.openjdk.org/jdk/pull/12986/files/5b26556d..23670070

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

  Stats: 12267 lines in 279 files changed: 4215 ins; 7423 del; 629 mod
  Patch: https://git.openjdk.org/jdk/pull/12986.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12986/head:pull/12986

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

From naoto at openjdk.org  Tue Apr  4 17:30:00 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 17:30:00 GMT
Subject: RFR: 8304982: Emit warning for removal of `COMPAT` provider [v3]
In-Reply-To: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
Message-ID: <uq37oZroZ0N3SASt0EQ9lAkYYb9TfZuxjzNIcTBT0n8=.028106b7-c850-4763-9461-51b86294fcd4@github.com>

> This is a precursor to the future removal of the `COMPAT` locale data provider. Before the actual removal of the provider, warn the users who explicitly specify `COMPAT` at the command line in order for their smooth migration to CLDR. A CSR has also been drafted.

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

  Removed @implNote for now

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13302/files
  - new: https://git.openjdk.org/jdk/pull/13302/files/d613600f..5eeb1ab0

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

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

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

From naoto at openjdk.org  Tue Apr  4 17:35:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 17:35:05 GMT
Subject: RFR: 8304982: Emit warning for removal of `COMPAT` provider [v2]
In-Reply-To: <pI6XSenNXSeDkGiioQ-1DCOEOpYBKxW47eF90uKTaHQ=.de3c3b1e-f1e2-48f6-9616-a22d8663adea@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
 <CTu8GEr7M96qN2VqCX0pcgkIgQnOLawY-9DvCTBqjjY=.00282dfc-2d97-40a3-b6ec-6efad774d573@github.com>
 <KrPf7Cdx49LrETjy7N__lBWsXbmji93laRgUpErHGVQ=.3d70ebd7-35c1-4c54-8343-d59ee4df7d77@github.com>
 <DAPIvBszP49fQ1q_9v_onndEIpjFX2waXY_FA4-vups=.cd268216-7359-4071-aefd-543a1923cfdb@github.com>
 <pI6XSenNXSeDkGiioQ-1DCOEOpYBKxW47eF90uKTaHQ=.de3c3b1e-f1e2-48f6-9616-a22d8663adea@github.com>
Message-ID: <AYWcQJ7odD8tJMqfNY8ucKVgDghy7TxCOFSSW978ooo=.a921e48e-98cd-46b0-8cc4-a365c6073c5f@github.com>

On Tue, 4 Apr 2023 06:54:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Locale providers provided by users can all be loaded in the name of `SPI`, as they are the real implementation of `LocaleServiceProvider` class, so the order of the preference can be specified against JDK's `CLDR` provider. Does this answer your question?
>
>> Locale providers provided by users can all be loaded in the name of `SPI`, as they are the real implementation of `LocaleServiceProvider` class, so the order of the preference can be specified against JDK's `CLDR` provider. Does this answer your question?
> 
> There are two parts to this PR. One part is the deprecation of "COMPAT" with a warning if used, no issue there. The second part changes the text from "The JDK Reference Implementation .." to the end of the class description to be an implNote.  My concern is that is the system property "java.locale.providers" is introduced in the normative section but it doesn't say anything about values. It just says that it can be used to configure the user's preferred order. The possible names and everything about ordering is in the implNote section. To make this work is going to need some expansion of the text in the normative section to say that the value is a sequence of strings, separated by a comma. It will also need to say something about the names as they are implementation specific. Also what happens if I deploy two custom locale providers on the class path, which one is used as I don't think the system property covers that.
> 
> Maybe the right thing here is to drop "@implNote" (just the tag) from this PR so that the deprecation, warning, and the small adjustments to the class description are pushed out of the way. A follow-up PR could re-examine the class description and the description of the "java.locale.providers" property.

Good point. Removed the @implNote tag for now and filed a separate issue to clarify the system property: https://bugs.openjdk.org/browse/JDK-8305595

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13302#discussion_r1157565170

From duke at openjdk.org  Tue Apr  4 17:39:05 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 4 Apr 2023 17:39:05 GMT
Subject: RFR: 8205129: Remove java.lang.Compiler
In-Reply-To: <k5oL-_x7ZlO48IYXqrBVQK_KhbPiLwrQSAXFgyWu8pk=.9834a282-838a-4893-b751-a8b318b68d37@github.com>
References: <k5oL-_x7ZlO48IYXqrBVQK_KhbPiLwrQSAXFgyWu8pk=.9834a282-838a-4893-b751-a8b318b68d37@github.com>
Message-ID: <mnHynp2_HnO-Vkt3-K2_40rL3OVVuLRSAI3xXdGR4F0=.b936b0a3-11eb-4d92-8fb9-1cc8ceaefc7b@github.com>

On Sun, 19 Mar 2023 09:01:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please help review this PR which suggests we remove the class `java.lang.Compiler`. The class seems non-functional for a decade, and was terminally deprecated in Java 9. Time has come to let it go.

The CSR for this PR has been approved for a while now. The PR is still looking for reviewers.

I know the change itself is not a very exciting one to review, it is after all just a file being deleted. But we still need a reviewer to approve it :-)

Or maybe all reviewers are gone on easter vacation?

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

PR Comment: https://git.openjdk.org/jdk/pull/13092#issuecomment-1496351036

From mchung at openjdk.org  Tue Apr  4 18:10:25 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 4 Apr 2023 18:10:25 GMT
Subject: Integrated: 8304846: Provide a shared utility to dump generated
 classes defined via Lookup API
In-Reply-To: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
Message-ID: <KTIQFbSD080BhsHxT4DsbW1N-szSMssFEyTliy0uTXQ=.648e9c76-16f5-4834-8f07-ad55abe4e388@github.com>

On Fri, 24 Mar 2023 20:41:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
> 
> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=<dumpDir>` 
> 
> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
> 
> To dump lambda proxy classes, set this system property:
>    -Djdk.internal.lambda.dumpProxyClasses=<dumpDir>
> 
> To dump LambdaForms and method handle implementation, set this system property:
>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>    
> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.

This pull request has now been integrated.

Changeset: dd594717
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dd59471798ad0118481939c59e58eca18e4365d1
Stats:     740 lines in 11 files changed: 347 ins; 300 del; 93 mod

8304846: Provide a shared utility to dump generated classes defined via Lookup API

Reviewed-by: jvernee

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

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

From rgiulietti at openjdk.org  Tue Apr  4 18:12:16 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 4 Apr 2023 18:12:16 GMT
Subject: Integrated: 8305343: BigDecimal.fractionOnly() erroneously returns
 true for large scale value
In-Reply-To: <lu95OdgQj6d4EkFa3gxgVcE1knojEAX5piG5B8t4yjo=.02826750-5b48-4392-818b-f3264e98773c@github.com>
References: <lu95OdgQj6d4EkFa3gxgVcE1knojEAX5piG5B8t4yjo=.02826750-5b48-4392-818b-f3264e98773c@github.com>
Message-ID: <KpJ8L15hEvVYnIVbNzBHKK-u0kjQNZIn9yty7vRHfj8=.15c3fff4-c2f0-4361-a26f-47966518c56b@github.com>

On Tue, 4 Apr 2023 13:25:44 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> A fix for the issue and additional specific tests.

This pull request has now been integrated.

Changeset: 7c650489
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7c650489d2ffd9ec7c8513427ff7c83ed30dcec2
Stats:     36 lines in 2 files changed: 31 ins; 0 del; 5 mod

8305343: BigDecimal.fractionOnly() erroneously returns true for large scale value

Reviewed-by: darcy

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

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

From alanb at openjdk.org  Tue Apr  4 18:22:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Apr 2023 18:22:08 GMT
Subject: RFR: 8304982: Emit warning for removal of `COMPAT` provider [v3]
In-Reply-To: <uq37oZroZ0N3SASt0EQ9lAkYYb9TfZuxjzNIcTBT0n8=.028106b7-c850-4763-9461-51b86294fcd4@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
 <uq37oZroZ0N3SASt0EQ9lAkYYb9TfZuxjzNIcTBT0n8=.028106b7-c850-4763-9461-51b86294fcd4@github.com>
Message-ID: <WOA5AnWNCgmUcj-rm6acPqrsg0blkDcN40VgXF3MBeE=.07166567-eefe-4fe3-9ef4-886c5d6e796b@github.com>

On Tue, 4 Apr 2023 17:30:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a precursor to the future removal of the `COMPAT` locale data provider. Before the actual removal of the provider, warn the users who explicitly specify `COMPAT` at the command line in order for their smooth migration to CLDR. A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed @implNote for now

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13302#pullrequestreview-1371538145

From alanb at openjdk.org  Tue Apr  4 18:22:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Apr 2023 18:22:10 GMT
Subject: RFR: 8304982: Emit warning for removal of `COMPAT` provider [v2]
In-Reply-To: <AYWcQJ7odD8tJMqfNY8ucKVgDghy7TxCOFSSW978ooo=.a921e48e-98cd-46b0-8cc4-a365c6073c5f@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
 <CTu8GEr7M96qN2VqCX0pcgkIgQnOLawY-9DvCTBqjjY=.00282dfc-2d97-40a3-b6ec-6efad774d573@github.com>
 <KrPf7Cdx49LrETjy7N__lBWsXbmji93laRgUpErHGVQ=.3d70ebd7-35c1-4c54-8343-d59ee4df7d77@github.com>
 <DAPIvBszP49fQ1q_9v_onndEIpjFX2waXY_FA4-vups=.cd268216-7359-4071-aefd-543a1923cfdb@github.com>
 <pI6XSenNXSeDkGiioQ-1DCOEOpYBKxW47eF90uKTaHQ=.de3c3b1e-f1e2-48f6-9616-a22d8663adea@github.com>
 <AYWcQJ7odD8tJMqfNY8ucKVgDghy7TxCOFSSW978ooo=.a921e48e-98cd-46b0-8cc4-a365c6073c5f@github.com>
Message-ID: <FNgksSyX3kBuP7Uk9fvRt2ORHWad8uNxE-9SUxp4Bn0=.f1c772eb-6644-43a5-8c89-fa8c866c37a3@github.com>

On Tue, 4 Apr 2023 17:32:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Good point. Removed the @implNote tag for now and filed a separate issue to clarify the system property: https://bugs.openjdk.org/browse/JDK-8305595

Okay, that works for me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13302#discussion_r1157610558

From alanb at openjdk.org  Tue Apr  4 18:23:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Apr 2023 18:23:10 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
Message-ID: <Gdwpun5rMVvm5SiUmgJ7ZIp3Kw6jUr3Ig90saDGXjKE=.56390924-d388-4daa-9ff9-c9d37d9f83fe@github.com>

On Thu, 30 Mar 2023 14:21:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>> 
>> Outstanding code work:
>> 
>> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
>> 
>> Outstanding work:
>> 
>> - CSR for the removal
>> - Release notes for the removal
>> - Coordination of the update of the Jar File Specification
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include a warning saying that 'The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18'

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13158#pullrequestreview-1371541522

From duke at openjdk.org  Tue Apr  4 18:26:32 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 4 Apr 2023 18:26:32 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
Message-ID: <o5oNiRz3KGL0IbapIeg20m5hTsg5AOADbz4v4OWjZTE=.08034e35-9a39-4af4-92bb-b57619b6bf2d@github.com>

On Thu, 30 Mar 2023 14:21:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>> 
>> Outstanding code work:
>> 
>> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
>> 
>> Outstanding work:
>> 
>> - CSR for the removal
>> - Release notes for the removal
>> - Coordination of the update of the Jar File Specification
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include a warning saying that 'The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18'

I have drafted CSR https://bugs.openjdk.org/browse/JDK-8305597, but I'm not sure what to put in the _Specification_ section.

What is the specification change in this PR? The removal of the system property?  The adding of the warning?

I'm not seeing any API change as is probably more usual in a CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1496409539

From alanb at openjdk.org  Tue Apr  4 18:30:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Apr 2023 18:30:08 GMT
Subject: RFR: 8205129: Remove java.lang.Compiler
In-Reply-To: <k5oL-_x7ZlO48IYXqrBVQK_KhbPiLwrQSAXFgyWu8pk=.9834a282-838a-4893-b751-a8b318b68d37@github.com>
References: <k5oL-_x7ZlO48IYXqrBVQK_KhbPiLwrQSAXFgyWu8pk=.9834a282-838a-4893-b751-a8b318b68d37@github.com>
Message-ID: <RIT4dt17CY1jLlaNbiKpnu4AgAYgoKxsjdz6nYQz5ms=.b10dc168-4c4e-4205-9f0f-882d576c8eae@github.com>

On Sun, 19 Mar 2023 09:01:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please help review this PR which suggests we remove the class `java.lang.Compiler`. The class seems non-functional for a decade, and was terminally deprecated in Java 9. Time has come to let it go.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13092#pullrequestreview-1371552031

From serb at openjdk.org  Tue Apr  4 18:31:10 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 4 Apr 2023 18:31:10 GMT
Subject: RFR: 8305113: (tz) Update Timezone Data to 2023c [v3]
In-Reply-To: <vTLYpNzwdiTkdNdsHyDC9iRA8GMLIov2-ASJi8ARaiY=.6797783d-5bd7-4093-910b-e4da9691817f@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
 <vTLYpNzwdiTkdNdsHyDC9iRA8GMLIov2-ASJi8ARaiY=.6797783d-5bd7-4093-910b-e4da9691817f@github.com>
Message-ID: <DTLIN9wvY3pjdZhq4I4wCjeOMro3QzaIH6MPhxAEMrc=.4d64e3e1-f78c-4073-82a4-54ac30f2abab@github.com>

On Mon, 3 Apr 2023 23:40:05 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> Pleases review this PR. 
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.
>
> Yoshiki Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert formatted code in ZoneInfoFile.java
>  - fixing typo again

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13255#pullrequestreview-1371553159

From duke at openjdk.org  Tue Apr  4 18:37:06 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 4 Apr 2023 18:37:06 GMT
Subject: RFR: 8205129: Remove java.lang.Compiler
In-Reply-To: <k5oL-_x7ZlO48IYXqrBVQK_KhbPiLwrQSAXFgyWu8pk=.9834a282-838a-4893-b751-a8b318b68d37@github.com>
References: <k5oL-_x7ZlO48IYXqrBVQK_KhbPiLwrQSAXFgyWu8pk=.9834a282-838a-4893-b751-a8b318b68d37@github.com>
Message-ID: <CbpdMRwsj2RxW_g9MvxCfqXCNgXjrz2NK90RxcAYKgQ=.2d162a73-8cd7-407b-8713-9d20ec9ace0a@github.com>

On Sun, 19 Mar 2023 09:01:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please help review this PR which suggests we remove the class `java.lang.Compiler`. The class seems non-functional for a decade, and was terminally deprecated in Java 9. Time has come to let it go.

Good riddance.

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

PR Comment: https://git.openjdk.org/jdk/pull/13092#issuecomment-1496423946

From alanb at openjdk.org  Tue Apr  4 18:40:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Apr 2023 18:40:10 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <o5oNiRz3KGL0IbapIeg20m5hTsg5AOADbz4v4OWjZTE=.08034e35-9a39-4af4-92bb-b57619b6bf2d@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <o5oNiRz3KGL0IbapIeg20m5hTsg5AOADbz4v4OWjZTE=.08034e35-9a39-4af4-92bb-b57619b6bf2d@github.com>
Message-ID: <uhG3aN9jIAmxDtQkGhtsjLGrmlz1FEk-INV3fMyQsUI=.36aa06d2-dc7c-4991-9c89-5d993d762b51@github.com>

On Tue, 4 Apr 2023 18:23:23 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> I have drafted CSR https://bugs.openjdk.org/browse/JDK-8305597, but I'm not sure what to put in the _Specification_ section.
> 
> What is the specification change in this PR? The removal of the system property? The adding of the warning?
> 
> I'm not seeing any API change as is probably more usual in a CSR.

I've edited it to add a Specification section with a summary of the changes to the JAR file spec. I also update the Solution section so that it provides a clearer summary of the changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1496428340

From lancea at openjdk.org  Tue Apr  4 18:44:09 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 4 Apr 2023 18:44:09 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
Message-ID: <bqQehzFMChYg_62qsxy4iEIEaYRIifH54GsE9cKcZDE=.4eb574d6-2fbd-4a62-879a-f2bf195348b4@github.com>

On Thu, 30 Mar 2023 14:21:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>> 
>> Outstanding code work:
>> 
>> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
>> 
>> Outstanding work:
>> 
>> - CSR for the removal
>> - Release notes for the removal
>> - Coordination of the update of the Jar File Specification
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include a warning saying that 'The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18'

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13158#pullrequestreview-1371573197

From lancea at openjdk.org  Tue Apr  4 18:44:09 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 4 Apr 2023 18:44:09 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <uhG3aN9jIAmxDtQkGhtsjLGrmlz1FEk-INV3fMyQsUI=.36aa06d2-dc7c-4991-9c89-5d993d762b51@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <o5oNiRz3KGL0IbapIeg20m5hTsg5AOADbz4v4OWjZTE=.08034e35-9a39-4af4-92bb-b57619b6bf2d@github.com>
 <uhG3aN9jIAmxDtQkGhtsjLGrmlz1FEk-INV3fMyQsUI=.36aa06d2-dc7c-4991-9c89-5d993d762b51@github.com>
Message-ID: <wyWIQkFXtsQNfrsiwREd8p_m7WY5o8V8iqsSQ-0NFEk=.bc25b747-8f1e-44e8-91d6-3b98fc9431f7@github.com>

On Tue, 4 Apr 2023 18:37:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I have drafted CSR https://bugs.openjdk.org/browse/JDK-8305597, but I'm not sure what to put in the _Specification_ section.
> > What is the specification change in this PR? The removal of the system property? The adding of the warning?
> > I'm not seeing any API change as is probably more usual in a CSR.
> 
> I've edited it to add a Specification section with a summary of the changes to the JAR file spec. I also update the Solution section so that it provides a clearer summary of the changes.

I also updated the CSR with the revised JAR File Spec.   I will look over the changes and add myself as a reviewer

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1496431151

From duke at openjdk.org  Tue Apr  4 18:44:10 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 4 Apr 2023 18:44:10 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <wyWIQkFXtsQNfrsiwREd8p_m7WY5o8V8iqsSQ-0NFEk=.bc25b747-8f1e-44e8-91d6-3b98fc9431f7@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <o5oNiRz3KGL0IbapIeg20m5hTsg5AOADbz4v4OWjZTE=.08034e35-9a39-4af4-92bb-b57619b6bf2d@github.com>
 <uhG3aN9jIAmxDtQkGhtsjLGrmlz1FEk-INV3fMyQsUI=.36aa06d2-dc7c-4991-9c89-5d993d762b51@github.com>
 <wyWIQkFXtsQNfrsiwREd8p_m7WY5o8V8iqsSQ-0NFEk=.bc25b747-8f1e-44e8-91d6-3b98fc9431f7@github.com>
Message-ID: <oFyQWvpvV4xyeR2-FMdEUd2e6gBm9ENX_d60DrXJE14=.ce8bb9c1-d80e-47b6-98ba-950fe1c159bf@github.com>

On Tue, 4 Apr 2023 18:39:54 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I've edited it to add a Specification section with a summary of the changes to the JAR file spec. I also update the Solution section so that it provides a clearer summary of the changes.

Thanks a lot Alan, as this CSR has deeper waters than what I've experienced before. Did you intend to remove the line break in the example warning output, collapsing it into one line?

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1496433027

From mchung at openjdk.org  Tue Apr  4 18:57:13 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 4 Apr 2023 18:57:13 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
Message-ID: <ja2RXqUfQfIE8BxHS4JtWakApCh2IS4-UoYrkXdk5AI=.900e0c4e-5838-4bd2-b596-15af5175e94b@github.com>

On Thu, 30 Mar 2023 14:21:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>> 
>> Outstanding code work:
>> 
>> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
>> 
>> Outstanding work:
>> 
>> - CSR for the removal
>> - Release notes for the removal
>> - Coordination of the update of the Jar File Specification
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include a warning saying that 'The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18'

LGTM

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13158#pullrequestreview-1371596288

From duke at openjdk.org  Tue Apr  4 19:03:16 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 4 Apr 2023 19:03:16 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
Message-ID: <nMjoazgMm0rBkvpvLF4xee7WqnsoZ-cbaeibb_zBF14=.4c962b19-3b1c-49de-8895-e558a26c2140@github.com>

On Thu, 30 Mar 2023 14:21:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>> 
>> Outstanding code work:
>> 
>> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
>> 
>> Outstanding work:
>> 
>> - CSR for the removal
>> - Release notes for the removal
>> - Coordination of the update of the Jar File Specification
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include a warning saying that 'The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18'

I added a draft release note https://bugs.openjdk.org/browse/JDK-8305603 as a sub-task of this PR's issue https://bugs.openjdk.org/browse/JDK-8303410

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1496455323

From mchung at openjdk.org  Tue Apr  4 19:15:20 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 4 Apr 2023 19:15:20 GMT
Subject: Integrated: 8305602: ProblemList
 java/lang/invoke/lambda/LogGeneratedClassesTest.java
Message-ID: <T1DfkoXKqIT9dcW6pxrIEMdFeYrPqLO-t6x1pcdVyE0=.95045b19-c1f4-41d6-b263-7328f9aa0da4@github.com>

This gives time to investigate JDK-8305600 and understand why the test didn't fail on my testing before the push.

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

Commit messages:
 - ProblemList java/lang/invoke/lambda/LogGeneratedClassesTest.java

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

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

From dcubed at openjdk.org  Tue Apr  4 19:15:21 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 4 Apr 2023 19:15:21 GMT
Subject: Integrated: 8305602: ProblemList
 java/lang/invoke/lambda/LogGeneratedClassesTest.java
In-Reply-To: <T1DfkoXKqIT9dcW6pxrIEMdFeYrPqLO-t6x1pcdVyE0=.95045b19-c1f4-41d6-b263-7328f9aa0da4@github.com>
References: <T1DfkoXKqIT9dcW6pxrIEMdFeYrPqLO-t6x1pcdVyE0=.95045b19-c1f4-41d6-b263-7328f9aa0da4@github.com>
Message-ID: <Q-JCnZRnkIPBoh8qU0LxCLK6x9HT3_FHMn_Mcrr8MLc=.d9ec2ed6-6cb1-43e4-b568-a255cf4eb1d0@github.com>

On Tue, 4 Apr 2023 18:58:12 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This gives time to investigate JDK-8305600 and understand why the test didn't fail on my testing before the push.

Thumbs up. This is a trivial fix.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13334#pullrequestreview-1371612964

From mchung at openjdk.org  Tue Apr  4 19:15:21 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 4 Apr 2023 19:15:21 GMT
Subject: Integrated: 8305602: ProblemList
 java/lang/invoke/lambda/LogGeneratedClassesTest.java
In-Reply-To: <T1DfkoXKqIT9dcW6pxrIEMdFeYrPqLO-t6x1pcdVyE0=.95045b19-c1f4-41d6-b263-7328f9aa0da4@github.com>
References: <T1DfkoXKqIT9dcW6pxrIEMdFeYrPqLO-t6x1pcdVyE0=.95045b19-c1f4-41d6-b263-7328f9aa0da4@github.com>
Message-ID: <mY1DhykMWar-cZjiMMgvFqz16p4VjX4FYLYOz6wtB3Q=.f80c5ca9-69cc-40d6-813b-f6797265be02@github.com>

On Tue, 4 Apr 2023 18:58:12 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This gives time to investigate JDK-8305600 and understand why the test didn't fail on my testing before the push.

This pull request has now been integrated.

Changeset: 3399fbf9
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3399fbf9fa22c37fc53ee54be52354dc532846ed
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8305602: ProblemList java/lang/invoke/lambda/LogGeneratedClassesTest.java

Reviewed-by: dcubed

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

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

From rriggs at openjdk.org  Tue Apr  4 19:31:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Apr 2023 19:31:02 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
Message-ID: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>

With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
This PR exports jdk.internal.util to:
 - java.prefs,
 - java.security.jgss,
 - java.smartcardio,
 - jdk.charsets,
 - jdk.net,
 - jdk.zipfs

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

Commit messages:
 - In jdk.prefs module, Replace os.name with OperatingSystem enum
 - Use OperatingSystem methods instead of system property os.name

Changes: https://git.openjdk.org/jdk/pull/13335/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13335&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304911
  Stats: 131 lines in 13 files changed: 24 ins; 54 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/13335.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13335/head:pull/13335

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

From rriggs at openjdk.org  Tue Apr  4 19:35:08 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Apr 2023 19:35:08 GMT
Subject: RFR: 8305107: Emoji related binary properties in RegEx [v2]
In-Reply-To: <dXZYF3W2xBs1XKuQIyFSXSE6312C807ORXNmdXiwXOU=.d3cbcfcc-bc11-43a2-be83-15128d55b1a8@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
 <dXZYF3W2xBs1XKuQIyFSXSE6312C807ORXNmdXiwXOU=.d3cbcfcc-bc11-43a2-be83-15128d55b1a8@github.com>
Message-ID: <azrc3PGKCGEGi6cken-j-5XEmIHZY5KQf2Qf2D8OC8s=.e710ddb7-26eb-4d39-8175-4b09ba9951d6@github.com>

On Tue, 4 Apr 2023 17:10:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation

Changes requested by rriggs (Reviewer).

test/jdk/java/util/regex/RegExTest.java line 64:

> 62: import java.util.stream.Stream;
> 63: 
> 64: import static java.lang.Character.*;

These static imports make the uses of the methods harder to recognize as from the Character class.

test/jdk/java/util/regex/RegExTest.java line 967:

> 965:         for (int i=0; i<1000; i++) {
> 966:             char c = (char)generator.nextInt();
> 967:             check("{javaLowerCase}", c, isLowerCase(c));

There are more readable with the explicit Character class reference; with them one has to hunt around for the named method. It also makes it explicit what is being tested.

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

PR Review: https://git.openjdk.org/jdk/pull/13314#pullrequestreview-1371648289
PR Review Comment: https://git.openjdk.org/jdk/pull/13314#discussion_r1157676720
PR Review Comment: https://git.openjdk.org/jdk/pull/13314#discussion_r1157677335

From naoto at openjdk.org  Tue Apr  4 20:15:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 20:15:52 GMT
Subject: RFR: 8305107: Emoji related binary properties in RegEx [v3]
In-Reply-To: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
Message-ID: <9_W23fwebJpTu-mWF0iLRqPZwZyGh127TQgZGtTg8aE=.1f203e4f-9f24-4216-a084-ea6277dfdc8e@github.com>

> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.

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

  Revert static import of Character.*

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13314/files
  - new: https://git.openjdk.org/jdk/pull/13314/files/41cfe460..5fd43d9e

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

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

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

From naoto at openjdk.org  Tue Apr  4 20:17:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 20:17:09 GMT
Subject: RFR: 8305107: Emoji related binary properties in RegEx [v2]
In-Reply-To: <azrc3PGKCGEGi6cken-j-5XEmIHZY5KQf2Qf2D8OC8s=.e710ddb7-26eb-4d39-8175-4b09ba9951d6@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
 <dXZYF3W2xBs1XKuQIyFSXSE6312C807ORXNmdXiwXOU=.d3cbcfcc-bc11-43a2-be83-15128d55b1a8@github.com>
 <azrc3PGKCGEGi6cken-j-5XEmIHZY5KQf2Qf2D8OC8s=.e710ddb7-26eb-4d39-8175-4b09ba9951d6@github.com>
Message-ID: <yu_gR26yn6qR8CLy6jyJMtWHq1G36mapgnyRJlwcxVg=.286224a7-149b-43bc-b038-9b9cd504084c@github.com>

On Tue, 4 Apr 2023 19:31:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   indentation
>
> test/jdk/java/util/regex/RegExTest.java line 967:
> 
>> 965:         for (int i=0; i<1000; i++) {
>> 966:             char c = (char)generator.nextInt();
>> 967:             check("{javaLowerCase}", c, isLowerCase(c));
> 
> There are more readable with the explicit Character class reference; with them one has to hunt around for the named method. It also makes it explicit what is being tested.

I thought it was apparent since this is testing the *Character* properties and reduces the complexity, but if you think so maybe not. Reverting static import as I don't have a strong opinion on it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13314#discussion_r1157717351

From naoto at openjdk.org  Tue Apr  4 20:46:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 20:46:08 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <PLVQO12D6OpNUM1D631lpeCa-XG2ppj8-yFutinjzo4=.8419be80-c474-4f80-b348-9248b49f12fc@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1371756979

From aturbanov at openjdk.org  Tue Apr  4 20:50:00 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 4 Apr 2023 20:50:00 GMT
Subject: RFR: 8305538: Avoid redundant HashMap.containsKey call in
 ModuleDescriptor.Builder [v2]
In-Reply-To: <cwKHk3sU2rRXKv4jNF2Biij7dPqlFQva3hBb8ZlVm-4=.18a6501d-db9d-44f4-9297-4e6dfa39c2e8@github.com>
References: <cwKHk3sU2rRXKv4jNF2Biij7dPqlFQva3hBb8ZlVm-4=.18a6501d-db9d-44f4-9297-4e6dfa39c2e8@github.com>
Message-ID: <YUsGhFl8t78O8CaDlAl_Ha8lNPEzaMxs9IcDPS76Txo=.43dd77f4-322e-4bda-b6fa-2377159a6e72@github.com>

> `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.

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

  8305538: Avoid redundant HashMap.containsKey call in ModuleDescriptor.Builder
  
  update java.lang.module.ModuleDescriptor.Builder.uses too

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13288/files
  - new: https://git.openjdk.org/jdk/pull/13288/files/06afe446..d6a6f365

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

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

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

From aturbanov at openjdk.org  Tue Apr  4 20:50:04 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 4 Apr 2023 20:50:04 GMT
Subject: RFR: 8305538: Avoid redundant HashMap.containsKey call in
 ModuleDescriptor.Builder
In-Reply-To: <oh7yFjQ5yHqs6a6nh5TfZoe7YAFEXnL9VDMaZQyfetQ=.27bc4ba7-0fcc-4033-8021-b91be71c8d06@github.com>
References: <cwKHk3sU2rRXKv4jNF2Biij7dPqlFQva3hBb8ZlVm-4=.18a6501d-db9d-44f4-9297-4e6dfa39c2e8@github.com>
 <E07Ny-COtulL3RUVAUMdCvsZdsu2z6Qde6o9nmM0Qas=.bc7b12d6-c35a-4422-9de2-a36fd688fa53@github.com>
 <oh7yFjQ5yHqs6a6nh5TfZoe7YAFEXnL9VDMaZQyfetQ=.27bc4ba7-0fcc-4033-8021-b91be71c8d06@github.com>
Message-ID: <9ICTUFZWdPM4NAeYnZlrrhgdDNGr-DCumibjZU0eIu4=.b5bf01f3-dfd3-40b4-988b-1c3df18c2d03@github.com>

On Tue, 4 Apr 2023 13:57:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If you are changing uses(String) then it should obey `strict`, meaning put this at the beginning of the method
> 
> ```
> if (strict) {
>     requireServiceTypeName(service);
> }
> ```

But now `requireServiceTypeName` is called unconditionally. Is it a bug?

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

PR Comment: https://git.openjdk.org/jdk/pull/13288#issuecomment-1496581270

From lancea at openjdk.org  Tue Apr  4 20:54:09 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 4 Apr 2023 20:54:09 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <jmYozHgCwkNFcK_M5EWxKGZ9iHABZ-RdMAOeDjBGNGk=.348c92c5-fb19-410f-9991-d7ab772ac914@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

The changes look good

Please add a Noreg-XXX label to the bug

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1371768336

From iris at openjdk.org  Tue Apr  4 21:00:10 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 4 Apr 2023 21:00:10 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <w--1bkwl6V1e7G7aGwcv4NlboudQn_noNPCyD03SAYM=.0c98f3d4-d4a1-43ca-b239-20d6658172a5@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1371776265

From jlu at openjdk.org  Tue Apr  4 21:05:24 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Apr 2023 21:05:24 GMT
Subject: Integrated: 8225641: Calendar.roll(int field) does not work correctly
 for WEEK_OF_YEAR
In-Reply-To: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
Message-ID: <EMy9c6RMyhfDZLAZr0MypZPMpSAleTzm7CD5AN4gPCo=.3d9e5130-ae91-4570-9640-85c36faf6c1d@github.com>

On Tue, 14 Mar 2023 22:16:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
> 
> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

This pull request has now been integrated.

Changeset: a324fa26
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a324fa2639d29f0c5b2928e7f15ec67e396c2648
Stats:     188 lines in 2 files changed: 186 ins; 0 del; 2 mod

8225641: Calendar.roll(int field) does not work correctly for WEEK_OF_YEAR

Reviewed-by: naoto

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

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

From jlu at openjdk.org  Tue Apr  4 21:06:18 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Apr 2023 21:06:18 GMT
Subject: Integrated: 8305400: ISO 4217 Amendment 175 Update
In-Reply-To: <y9rYoYaCVHLiwhu8ICNuTAxpqWA7DO6dHBjtEVVLrAo=.8b660491-b48e-4092-9e3f-0cc1e90e0b31@github.com>
References: <y9rYoYaCVHLiwhu8ICNuTAxpqWA7DO6dHBjtEVVLrAo=.8b660491-b48e-4092-9e3f-0cc1e90e0b31@github.com>
Message-ID: <o8zgneyOJIPMuLPncXmFHjmlNHorRWeJ08ZOxfxP4bE=.d649b9e0-5b51-41ae-ab2c-366227601378@github.com>

On Fri, 31 Mar 2023 21:38:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review the ISO 4217 amendment 175 update.
> 
> There are no meaningful code changes, but the version number should be updated accordingly to be in sync.

This pull request has now been integrated.

Changeset: 7cf24d1c
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7cf24d1c06142a3bab9cce5cd0ba34b8bbccf00f
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8305400: ISO 4217 Amendment 175 Update

Reviewed-by: naoto

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

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

From rriggs at openjdk.org  Tue Apr  4 21:10:07 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Apr 2023 21:10:07 GMT
Subject: RFR: 8305107: Emoji related binary properties in RegEx [v3]
In-Reply-To: <9_W23fwebJpTu-mWF0iLRqPZwZyGh127TQgZGtTg8aE=.1f203e4f-9f24-4216-a084-ea6277dfdc8e@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
 <9_W23fwebJpTu-mWF0iLRqPZwZyGh127TQgZGtTg8aE=.1f203e4f-9f24-4216-a084-ea6277dfdc8e@github.com>
Message-ID: <iBV9uRW4J5WamBUvy_DgeYxdElkFOGndcHnb47qxcpU=.1622f6b1-baad-4f8f-a3d3-1bd7b08e813d@github.com>

On Tue, 4 Apr 2023 20:15:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert static import of Character.*

LGTM; thanks for the updates

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13314#pullrequestreview-1371788528

From dholmes at openjdk.org  Tue Apr  4 22:28:10 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Apr 2023 22:28:10 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v3]
In-Reply-To: <Ri_eufJ474fMNuOHikUcbRBgB2y-AHUsRjrtlEb_k38=.ed69b9f7-dc4d-4700-b8c9-fec0f8dded55@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <QCUHuRgMUXENoZ9r6Xwrsoz9LUlI5g1L8jBFwuiv5jU=.31220531-a579-4d41-82e4-d3d454f59a0a@github.com>
 <Ri_eufJ474fMNuOHikUcbRBgB2y-AHUsRjrtlEb_k38=.ed69b9f7-dc4d-4700-b8c9-fec0f8dded55@github.com>
Message-ID: <sf-0By-JTaVS47-73zM3V1KNaD5zX1ibB3AJH9E2rYA=.ceab4973-6d33-469f-91b4-50d2ef308f9f@github.com>

On Tue, 4 Apr 2023 09:22:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Ensure HB relationship exists; additional explanatory comments
>
> src/java.base/share/classes/java/lang/Thread.java line 1850:
> 
>> 1848:      * happens-before isAlive() returning false.
>> 1849:      */
>> 1850:     synchronized boolean alive() {
> 
> Ah. Yes, it needs to be synchronized on the same lock that VM uses, which is `this`.
> 
> But there is also a secondary issue fixed by this synchronization: without it, a simple `while (t.isAlive()) {}` loop would execute indefinitely, since `eetop` is going to be hoisted. This can be reproduced with the test below.
> 
> Consider adding it as `test/jdk/java/lang/Thread/IsAlive.java`:
> 
> 
> /*
>  * Copyright 2023, Amazon.com Inc. or its affiliates. All Rights Reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU General Public License version 2 only, as
>  * published by the Free Software Foundation.
>  *
>  * This code is distributed in the hope that it will be useful, but WITHOUT
>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>  * version 2 for more details (a copy is included in the LICENSE file that
>  * accompanied this code).
>  *
>  * You should have received a copy of the GNU General Public License version
>  * 2 along with this work; if not, write to the Free Software Foundation,
>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>  *
>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>  * or visit www.oracle.com if you need additional information or have any
>  * questions.
>  */
> 
> /*
>  * @test
>  * @bug     8305425
>  * @summary Check Thread.isAlive
>  * @run main/othervm/timeout=10 IsAlive
>  */
> 
> public class IsAlive {
> 
>     private static void spin() {
>         try {
>             while (!Thread.currentThread().isInterrupted()) {
>                 Thread.sleep(10);
>             }
>         } catch (InterruptedException ie) {
>             // Do nothing, just exit
>         }
>     }
> 
>     static volatile boolean checkerReady;
> 
>     private static void check(Thread t) {
>         while (!t.isAlive()) {
>             // Burn hard, without any sleeps.
>             // Check that we discover the thread is alive eventually.
>         }
> 
>         checkerReady = true;
> 
>         while (t.isAlive()) {
>             // Burn hard, without any sleeps.
>             // Check that we discover the thread is not alive eventually.
>         }
>     }
> 
>     private static void assertAlive(Thread t) {
>         if (!t.isAlive()) {
>             throw new IllegalStateException("Thread " + t + " is not alive, but it should be");
>         }
>     }
> 
>     private static void assertNotAlive(Thread t) {
>         if (t.isAlive()) {
>             throw new IllegalStateException("Thread " + t + " is alive, but it should not be");
>         }
>     }
> 
>     public static void main(String args[]) throws Exception {
>         Thread spinner = new Thread(IsAlive::spin);
>         spinner.setName("Spinner");
>         spinner.setDaemon(true);
> 
>         Thread checker = new Thread(() -> check(spinner));
>         checker.setName("Checker");
>         checker.setDaemon(true);
> 
>         assertNotAlive(spinner);
>         assertNotAlive(checker);
> 
>         System.out.println("Starting spinner");
>         spinner.start();
>         assertAlive(spinner);
> 
>         System.out.println("Starting checker");
>         checker.start();
>         assertAlive(checker);
> 
>         System.out.println("Waiting for checker to catch up");
>         while (!checkerReady) {
>             Thread.sleep(100);
>         }
> 
>         System.out.println("Interrupting and joining spinner");
>         spinner.interrupt();
>         spinner.join();
>         assertNotAlive(spinner);
> 
>         System.out.println("Joining checker");
>         checker.join();
>         assertNotAlive(checker);
> 
>         System.out.println("Complete");
>     }
> }

Yes good catch @shipilev ! The fact the field was set by the VM dealt with a couple of issues that direct setting has to deal with explicitly. I will incorporate your new test. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1157826819

From joehw at openjdk.org  Tue Apr  4 22:32:39 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 4 Apr 2023 22:32:39 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v7]
In-Reply-To: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
Message-ID: <cAGYYyCkHAQnlDGI-arKzdZbxQy5V09PwRx5GOsQpMc=.8a5fb1d7-1fff-4c0b-977f-76609e18af75@github.com>

> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8303531
> 
> Tests: XML SQE and JCK tests passed.

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

  update javadoc as discussed in the review meeting; add a sample configuration file jaxp.properties; update impl and tests accordingly.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12985/files
  - new: https://git.openjdk.org/jdk/pull/12985/files/d62f58fd..f621b5d8

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

  Stats: 1346 lines in 34 files changed: 1191 ins; 67 del; 88 mod
  Patch: https://git.openjdk.org/jdk/pull/12985.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12985/head:pull/12985

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

From dholmes at openjdk.org  Tue Apr  4 22:50:00 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Apr 2023 22:50:00 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v4]
In-Reply-To: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
Message-ID: <dY8Eh4ftZ259U6cfZ2TVgbdNzxmDSxlkUiNQiH3mn7Q=.e5baaba2-2df5-4397-bbc7-de57d10e3ea3@github.com>

> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
> 
> boolean alive() {
>   return eetop != 0;
> } 
> 
> I also updated a comment in relation to `eetop`.
> 
> Testing: tiers 1-3
> 
> Thanks

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

  Fix copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13287/files
  - new: https://git.openjdk.org/jdk/pull/13287/files/e4bb5d66..a02431a9

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

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

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

From dholmes at openjdk.org  Tue Apr  4 23:05:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Apr 2023 23:05:07 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v4]
In-Reply-To: <dY8Eh4ftZ259U6cfZ2TVgbdNzxmDSxlkUiNQiH3mn7Q=.e5baaba2-2df5-4397-bbc7-de57d10e3ea3@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <dY8Eh4ftZ259U6cfZ2TVgbdNzxmDSxlkUiNQiH3mn7Q=.e5baaba2-2df5-4397-bbc7-de57d10e3ea3@github.com>
Message-ID: <blU7AIKbi7sUxDir9hYH_8e4TT8Y3gkazBOOJzGIePY=.f97f3445-92d6-4e04-8f7a-c593321a612a@github.com>

On Tue, 4 Apr 2023 22:50:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
>> 
>> boolean alive() {
>>   return eetop != 0;
>> } 
>> 
>> I also updated a comment in relation to `eetop`.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year

Actually I'm now thinking that introducing a synchronized method here could cause compatibility issues. While people shouldn't generally synchronize on Thread objects, if they do have threads locking themselves, whilst other threads check isAlive(), then we could introduce problems.

Making the `eetop` field volatile instead would address that, but it would mean that the VM also has to perform a volatile store (release_store) when setting `eetop` to 0 during thread termination.

Or may be I should just let sleeping dogs lie and leave this as-is?

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

PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1496704371

From psandoz at openjdk.org  Tue Apr  4 23:57:06 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 4 Apr 2023 23:57:06 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v6]
In-Reply-To: <mvjXG43i2H0ULxXam6DzZR6SPrVjyth_x4Fu7CTjmE0=.04f5e64d-54bd-4556-bc46-212552526853@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <mvjXG43i2H0ULxXam6DzZR6SPrVjyth_x4Fu7CTjmE0=.04f5e64d-54bd-4556-bc46-212552526853@github.com>
Message-ID: <ZpW8BKYTCA7h52SQYD_DgTHLiRLkyxroHQbAbYr37LM=.87075dd6-3d05-4574-a713-33708211db9c@github.com>

On Tue, 4 Apr 2023 13:46:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
>> 
>> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
>> 
>> Please take a look and have some reviews. Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   style

Tier 1-3 tests now pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/12909#issuecomment-1496737872

From dholmes at openjdk.org  Wed Apr  5 00:28:56 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Apr 2023 00:28:56 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v5]
In-Reply-To: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
Message-ID: <tQOj8CExWNo2C2wi5gq9D_VNmmfpLq5qAwmGxDKMKg0=.fe9935d6-59dc-4bcd-a3b6-08f8dc48fa45@github.com>

> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
> 
> boolean alive() {
>   return eetop != 0;
> } 
> 
> I also updated a comment in relation to `eetop`.
> 
> Testing: tiers 1-3
> 
> Thanks

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

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13287/files
  - new: https://git.openjdk.org/jdk/pull/13287/files/a02431a9..10022a06

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

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

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

From ysatowse at openjdk.org  Wed Apr  5 01:22:30 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Wed, 5 Apr 2023 01:22:30 GMT
Subject: Integrated: 8305113: (tz) Update Timezone Data to 2023c
In-Reply-To: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
Message-ID: <CSfCOwf-MVivq29WBb4gTvs6K17Czwq3G-l_uTz0eEs=.fd155a3b-28a3-4872-8180-dbad58ff4d46@github.com>

On Fri, 31 Mar 2023 00:02:02 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Pleases review this PR. 
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.

This pull request has now been integrated.

Changeset: ed9592c6
Author:    Yoshiki Sato <ysatowse at openjdk.org>
Committer: Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed9592c6e81f82e2bf6508ce45ba15aad8232181
Stats:     330 lines in 18 files changed: 188 ins; 25 del; 117 mod

8305113: (tz) Update Timezone Data to 2023c

Reviewed-by: naoto, andrew, serb

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

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

From dholmes at openjdk.org  Wed Apr  5 02:30:15 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Apr 2023 02:30:15 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v6]
In-Reply-To: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
Message-ID: <akKez57fnfshR7bdob_wHSmeDnRhsD8pDDKptpTE90s=.6b90034e-768b-4e4c-b512-f60763aec4b4@github.com>

> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
> 
> boolean alive() {
>   return eetop != 0;
> } 
> 
> I also updated a comment in relation to `eetop`.
> 
> Testing: tiers 1-3
> 
> Thanks

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

 - Switch from using synchronized to using a volatile eetop field
 - Added Shipilev's test (with a small addition)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13287/files
  - new: https://git.openjdk.org/jdk/pull/13287/files/10022a06..d284547c

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

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

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

From liangchenblue at gmail.com  Wed Apr  5 03:15:17 2023
From: liangchenblue at gmail.com (-)
Date: Tue, 4 Apr 2023 22:15:17 -0500
Subject: About MethodTypeDesc having more than 255 slots
Message-ID: <CABe8uE0R5O=Xx=EVXJO-iu-o1=MVtpej+dvN8Gq_HG+YnNCnVA@mail.gmail.com>

Hi Vincente,
In https://bugs.openjdk.org/browse/JDK-8223803 you argued that it can
be used to represent descriptor with more than 255 slots and that it
can be used to indify a varargs with more than 255 parameters.

However, this has brought some trouble to the classfile-oriented
usages of MethodTypeDesc: it's somewhat complicated for regular
MethodTypeDesc users to check if the desc is always invalid (must
count the slots manually), and this has an effect to encoding the
downstream MethodHandleDesc in the Classfile API. Most parts of the VM
have assumed there's at most 255 arguments: max stacks, max locals,
and number of arguments to bootstrap methods, so it doesn't help
indify existing bytecode. It also makes
ConstantDesc::resolveConstantDesc unreliable, as all other constant
descriptors exclusively describe constants that are valid.

My proposal is to revive https://bugs.openjdk.org/browse/JDK-8223919
and to enforce the 255-slot limit of MethodTypeDesc on creation (which
shouldn't add a large overhead as we already iterate over the
parameters to check for void).

For your proposed usage of MethodTypeDesc with more than 255 slots, I
recommend resorting to other source-oriented representations of such
general varargs or indify, such as string concatenation, given such a
representation is impossible in the JVM. An 1000-argument method type
descriptor cannot represent how the arguments are going to be grouped
together when it's encoded into bytecode, such as which argument
should go to which argument of the chained call tree. Making
MethodTypeDesc represent such in-source structures provides little
value at the cost of uncertainties of invalid descriptors to bytecode
and constant oriented users.

Thank you for your time. Feel free to offer alternative solutions to
my troubles with bytecode/classfile-oriented usage or point out
problems in my mail. I will be more than glad to hear from you and
respond to your questions.

Chen Liang

From duke at openjdk.org  Wed Apr  5 04:05:08 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 5 Apr 2023 04:05:08 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v6]
In-Reply-To: <akKez57fnfshR7bdob_wHSmeDnRhsD8pDDKptpTE90s=.6b90034e-768b-4e4c-b512-f60763aec4b4@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <akKez57fnfshR7bdob_wHSmeDnRhsD8pDDKptpTE90s=.6b90034e-768b-4e4c-b512-f60763aec4b4@github.com>
Message-ID: <DioJuftMaV3gF2gJ1dbaUsuL5mzcwU93bzzA4Spo6tA=.c97faa36-f060-42ba-9ecc-1acd483a2ee3@github.com>

On Wed, 5 Apr 2023 02:30:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
>> 
>> boolean alive() {
>>   return eetop != 0;
>> } 
>> 
>> I also updated a comment in relation to `eetop`.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Switch from using synchronized to using a volatile eetop field
>  - Added Shipilev's test (with a small addition)

src/java.base/share/classes/java/lang/Thread.java line 1846:

> 1844:     /**
> 1845:      * Returns true if this thread is alive.
> 1846:      * This method is non-final so it can be overridden.

Suggestion:

     * This method is non-final so it can be overridden by VirtualThread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1157995444

From duke at openjdk.org  Wed Apr  5 04:12:18 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 5 Apr 2023 04:12:18 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v6]
In-Reply-To: <akKez57fnfshR7bdob_wHSmeDnRhsD8pDDKptpTE90s=.6b90034e-768b-4e4c-b512-f60763aec4b4@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <akKez57fnfshR7bdob_wHSmeDnRhsD8pDDKptpTE90s=.6b90034e-768b-4e4c-b512-f60763aec4b4@github.com>
Message-ID: <kLZKUWtKDjFTVDDVTM4y2emeWYMTc7BHuGQRocEnOrw=.f13e2f3c-3f28-40db-8700-1cca88af6daa@github.com>

On Wed, 5 Apr 2023 02:30:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
>> 
>> boolean alive() {
>>   return eetop != 0;
>> } 
>> 
>> I also updated a comment in relation to `eetop`.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Switch from using synchronized to using a volatile eetop field
>  - Added Shipilev's test (with a small addition)

src/hotspot/share/runtime/javaThread.cpp line 743:

> 741:   // Clear the native thread instance - this makes isAlive return false and allows the join()
> 742:   // to complete once we've done the notify_all below. Needs a release() to obey Java Memory Model
> 743:   // requirements.

This?might be?more readable:
Suggestion:

  // to complete once we've done the notify_all below.
  // Needs a release() to obey Java Memory Model requirements.

src/java.base/share/classes/java/lang/Thread.java line 235:

> 233:        and reset to zero when the thread terminates. A non-zero value indicates this thread
> 234:        isAlive().
> 235:     */

Maybe JavaDocify this?
Suggestion:

    /**
     * Reserved for exclusive use by the JVM. Cannot be moved to the FieldHolder
     * as it needs to be set by the VM before executing the constructor that
     * will create the FieldHolder. The historically named {@code eetop} holds
     * the address of the underlying VM JavaThread, and is set to non-zero when
     * the thread is started, and reset to zero when the thread terminates.
     * A non-zero value indicates this thread {@link #isAlive()}.
     */

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1157996691
PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1157998171

From duke at openjdk.org  Wed Apr  5 04:15:08 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 5 Apr 2023 04:15:08 GMT
Subject: RFR: 8284871: Use covariant overrides for the
 resolveConstantDesc(Lookup) method in =?UTF-8?B?c3Vi4oCRaW50ZXJmYWNlcw==?= of
 java.lang.constant.ConstantDesc [v3]
In-Reply-To: <H7F0BJUl1P_mra_MSOPg_uVv_JdBxyS1ulS2_guX3yI=.3dc19464-9a2b-462c-8976-e13853d84c9e@github.com>
References: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
 <H7F0BJUl1P_mra_MSOPg_uVv_JdBxyS1ulS2_guX3yI=.3dc19464-9a2b-462c-8976-e13853d84c9e@github.com>
Message-ID: <KMgUTSY8-Wu87Jb7cOw1zlNrK_cX0wZFqz_bumKpg8Y=.f7035126-113b-4faf-8926-b8dad6ce7fd1@github.com>

On Tue, 4 Apr 2023 17:22:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also remove redundant casts to avoid javac warnings.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Retain a general note in ConstantDesc
>  - Merge branch 'master' into constdesc-override
>  - Update tests to remove useless casts and update copyright year
>  - Merge branch 'master' into constdesc-override
>  - Move MethodTypeDesc api notes to MethodTypeDesc
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into constdesc-override
>  - Remove redundant casts
>  - Covariant override of resolveConstantDesc for Class/MethodType/MethodHandleDesc

This?should probably also?remove the?now unnecessary?casts from?the?benchmark that?was?added in?[GH?13252]: https://github.com/openjdk/jdk/blob/ed9592c6e81f82e2bf6508ce45ba15aad8232181/test/micro/org/openjdk/bench/java/lang/constant/ReferenceClassDescResolve.java#L57-L70

[GH?13252]: https://github.com/openjdk/jdk/pull/13252

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

PR Comment: https://git.openjdk.org/jdk/pull/12986#issuecomment-1496893219

From dholmes at openjdk.org  Wed Apr  5 04:41:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Apr 2023 04:41:07 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v6]
In-Reply-To: <akKez57fnfshR7bdob_wHSmeDnRhsD8pDDKptpTE90s=.6b90034e-768b-4e4c-b512-f60763aec4b4@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <akKez57fnfshR7bdob_wHSmeDnRhsD8pDDKptpTE90s=.6b90034e-768b-4e4c-b512-f60763aec4b4@github.com>
Message-ID: <RiHRWAAmMKpKPARTwAHEWphfw8Cy82wz2Vmu4xNCVBY=.7751b216-1be3-4439-9d35-edd8fdc45699@github.com>

On Wed, 5 Apr 2023 02:30:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
>> 
>> boolean alive() {
>>   return eetop != 0;
>> } 
>> 
>> I also updated a comment in relation to `eetop`.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Switch from using synchronized to using a volatile eetop field
>  - Added Shipilev's test (with a small addition)

Thanks for looking at this @Exe-Boss

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

PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1496907094

From dholmes at openjdk.org  Wed Apr  5 04:41:12 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Apr 2023 04:41:12 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v6]
In-Reply-To: <kLZKUWtKDjFTVDDVTM4y2emeWYMTc7BHuGQRocEnOrw=.f13e2f3c-3f28-40db-8700-1cca88af6daa@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <akKez57fnfshR7bdob_wHSmeDnRhsD8pDDKptpTE90s=.6b90034e-768b-4e4c-b512-f60763aec4b4@github.com>
 <kLZKUWtKDjFTVDDVTM4y2emeWYMTc7BHuGQRocEnOrw=.f13e2f3c-3f28-40db-8700-1cca88af6daa@github.com>
Message-ID: <YywTNp7DBB0Q24FsEBURdRQ76efk-_huOfBW3-aenSk=.d4f369f8-4f3f-4277-b61b-d07bf1384f9f@github.com>

On Wed, 5 Apr 2023 04:04:11 GMT, ExE Boss <duke at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Switch from using synchronized to using a volatile eetop field
>>  - Added Shipilev's test (with a small addition)
>
> src/hotspot/share/runtime/javaThread.cpp line 743:
> 
>> 741:   // Clear the native thread instance - this makes isAlive return false and allows the join()
>> 742:   // to complete once we've done the notify_all below. Needs a release() to obey Java Memory Model
>> 743:   // requirements.
> 
> This?might be?more readable:
> Suggestion:
> 
>   // to complete once we've done the notify_all below.
>   // Needs a release() to obey Java Memory Model requirements.

Multi-line comments are typically written in normal paragraph style.

> src/java.base/share/classes/java/lang/Thread.java line 235:
> 
>> 233:        and reset to zero when the thread terminates. A non-zero value indicates this thread
>> 234:        isAlive().
>> 235:     */
> 
> Maybe JavaDocify this?
> Suggestion:
> 
>     /**
>      * Reserved for exclusive use by the JVM. Cannot be moved to the FieldHolder
>      * as it needs to be set by the VM before executing the constructor that
>      * will create the FieldHolder. The historically named {@code eetop} holds
>      * the address of the underlying VM JavaThread, and is set to non-zero when
>      * the thread is started, and reset to zero when the thread terminates.
>      * A non-zero value indicates this thread {@link #isAlive()}.
>      */

Being a private field it won't appear in any javadoc that anyone is ever likely to read. Only developers will see this (or need to see it) when they read the source code.

> src/java.base/share/classes/java/lang/Thread.java line 1846:
> 
>> 1844:     /**
>> 1845:      * Returns true if this thread is alive.
>> 1846:      * This method is non-final so it can be overridden.
> 
> Suggestion:
> 
>      * This method is non-final so it can be overridden by VirtualThread.

:) I actually made that change in an earlier commit but decided to revert it because I assumed (@AlanBateman can confirm or refute) that it was left unspecific in case classes other than VirtualThread needed to override it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1158010812
PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1158011258
PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1158010458

From liach at openjdk.org  Wed Apr  5 04:50:04 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Apr 2023 04:50:04 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v4]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <6hZzlgJtzWUJJupq0J2gRfeEvxD-wXkpsa2XcYvA0qM=.145bc6af-99b5-421a-940c-5198291764c8@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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
> 
> [^1]: single abstract method

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

 - Use a dumper for interface instances, other cleanup
 - Merge branch 'master' into explore/mhp-iface
 - Merge branch 'master' into explore/mhp-iface
 - Remove unused JavaLangReflectReflectAccess.invokeDefault
 - rethrow error
 - Benchmark compareing to lamda metafactory, various minor updates
 - Cache the spinned class, loading is still slow
 - Wrapper instance type is already available
 - mark records as private
 - Merge branch 'master' into explore/mhp-iface
 - ... and 3 more: https://git.openjdk.org/jdk/compare/7a470bdc...0eec507d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/fade6200..0eec507d

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

  Stats: 23624 lines in 577 files changed: 10873 ins; 10354 del; 2397 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 jlu at openjdk.org  Wed Apr  5 05:08:03 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 5 Apr 2023 05:08:03 GMT
Subject: RFR: 6241286: (cal) API: Calendar.DAY_OF_WEEK definition is wrong
Message-ID: <Fe3PdyvyvFi_GNbxowh7Ps4ZhCLcqO2MEmiLD3bddyg=.8e8e6669-6549-49fe-93db-a837427c3515@github.com>

This PR updates the Calendar.DAY_OF_WEEK documentation to make it clear that the field accepts _any_ value if the calendar is lenient and then normalizes it. Only if the calendar is non-lenient, will the field accept only one of SUNDAY ... SATURDAY.

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

Commit messages:
 - Redudant wording
 - Adjust doc

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

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

From duke at openjdk.org  Wed Apr  5 05:11:08 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 5 Apr 2023 05:11:08 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <aQYAwMrrJcqk4ATxMUuvnQswH8AxHgye4L34iE3UTG4=.5c1f5324-846f-4833-8828-16b3c6067a46@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java line 105:

> 103:                                 case WINDOWS -> // Full path needed, DLL is in jre/bin
> 104:                                         new String[]{StaticProperty.javaHome()
> 105:                                                 + "\\bin\\sspi_bridge.dll"};

Suggestion:

                                        new String[]{ StaticProperty.javaHome()
                                                + "\\bin\\sspi_bridge.dll" };

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158027900

From liach at openjdk.org  Wed Apr  5 05:14:07 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Apr 2023 05:14:07 GMT
Subject: RFR: 8284871: Use covariant overrides for the
 resolveConstantDesc(Lookup) method in =?UTF-8?B?c3Vi4oCRaW50ZXJmYWNlcw==?= of
 java.lang.constant.ConstantDesc [v4]
In-Reply-To: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
References: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
Message-ID: <DY2phRiG3uDRbfToXvZfSjzy_jyBg1wUE4BSYQQAJNQ=.8774ae82-7d81-40d4-8666-c273bb9cbec8@github.com>

> Also remove redundant casts to avoid javac warnings.

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

  Redundant casts in benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12986/files
  - new: https://git.openjdk.org/jdk/pull/12986/files/23670070..7ff2d4a4

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

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

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

From jpai at openjdk.org  Wed Apr  5 05:45:17 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Apr 2023 05:45:17 GMT
Subject: RFR: 8305107: Emoji related binary properties in RegEx [v3]
In-Reply-To: <9_W23fwebJpTu-mWF0iLRqPZwZyGh127TQgZGtTg8aE=.1f203e4f-9f24-4216-a084-ea6277dfdc8e@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
 <9_W23fwebJpTu-mWF0iLRqPZwZyGh127TQgZGtTg8aE=.1f203e4f-9f24-4216-a084-ea6277dfdc8e@github.com>
Message-ID: <H0Y8hgnWufqWjUkrIQ6ck7CvuRlq2nb-DMmcWsnV1AI=.bade62c4-95f9-47f7-b119-0ebf5c699bce@github.com>

On Tue, 4 Apr 2023 20:15:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert static import of Character.*

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13314#pullrequestreview-1372187317

From jpai at openjdk.org  Wed Apr  5 05:56:11 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Apr 2023 05:56:11 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
Message-ID: <bhwfEvvgT8rIUjF9EvPW6Ok3rVxijYadSJ8MaPE6tPE=.0d01c912-7f87-4d9a-98ac-ef7f155cec9b@github.com>

On Thu, 30 Mar 2023 14:21:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>> 
>> Outstanding code work:
>> 
>> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
>> 
>> Outstanding work:
>> 
>> - CSR for the removal
>> - Release notes for the removal
>> - Coordination of the update of the Jar File Specification
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include a warning saying that 'The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18'

Hello Eirik, the changes look good to me. The new test that was planned for testing `JarFile` and `JarInputStream` when dealing with a jar containing a `META-INF/INDEX.LIST`, is that something that you want to be done as a separate PR/task? It's fine with me if you want that to be done separately.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13158#pullrequestreview-1372196049

From alanb at openjdk.org  Wed Apr  5 06:15:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Apr 2023 06:15:09 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <oFyQWvpvV4xyeR2-FMdEUd2e6gBm9ENX_d60DrXJE14=.ce8bb9c1-d80e-47b6-98ba-950fe1c159bf@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <o5oNiRz3KGL0IbapIeg20m5hTsg5AOADbz4v4OWjZTE=.08034e35-9a39-4af4-92bb-b57619b6bf2d@github.com>
 <uhG3aN9jIAmxDtQkGhtsjLGrmlz1FEk-INV3fMyQsUI=.36aa06d2-dc7c-4991-9c89-5d993d762b51@github.com>
 <wyWIQkFXtsQNfrsiwREd8p_m7WY5o8V8iqsSQ-0NFEk=.bc25b747-8f1e-44e8-91d6-3b98fc9431f7@github.com>
 <oFyQWvpvV4xyeR2-FMdEUd2e6gBm9ENX_d60DrXJE14=.ce8bb9c1-d80e-47b6-98ba-950fe1c159bf@github.com>
Message-ID: <91azLVsPgSYLoqX_EK98jo4GsWmOsCJjza85IWcuADc=.1a99ec85-6e54-4ae4-babe-eb6a00648613@github.com>

On Tue, 4 Apr 2023 18:41:31 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Thanks a lot Alan, as this CSR has deeper waters than what I've experienced before. Did you intend to remove the line break in the example warning output, collapsing it into one line?

I used the inline code formatting (3 backquotes) to make the output clear, but maybe it looks differently for you or maybe your comment was while I was editing? When you are ready, press "Finalize" and that will put in the CSR queue to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1496970170

From duke at openjdk.org  Wed Apr  5 06:22:11 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 5 Apr 2023 06:22:11 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <91azLVsPgSYLoqX_EK98jo4GsWmOsCJjza85IWcuADc=.1a99ec85-6e54-4ae4-babe-eb6a00648613@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <o5oNiRz3KGL0IbapIeg20m5hTsg5AOADbz4v4OWjZTE=.08034e35-9a39-4af4-92bb-b57619b6bf2d@github.com>
 <uhG3aN9jIAmxDtQkGhtsjLGrmlz1FEk-INV3fMyQsUI=.36aa06d2-dc7c-4991-9c89-5d993d762b51@github.com>
 <wyWIQkFXtsQNfrsiwREd8p_m7WY5o8V8iqsSQ-0NFEk=.bc25b747-8f1e-44e8-91d6-3b98fc9431f7@github.com>
 <oFyQWvpvV4xyeR2-FMdEUd2e6gBm9ENX_d60DrXJE14=.ce8bb9c1-d80e-47b6-98ba-950fe1c159bf@github.com>
 <91azLVsPgSYLoqX_EK98jo4GsWmOsCJjza85IWcuADc=.1a99ec85-6e54-4ae4-babe-eb6a00648613@github.com>
Message-ID: <KdAVX73Iq-4-DtzRq-DkyTJmlG3KDeCA5rYMtYkjRpc=.d49565d9-7947-47c3-bc30-d918d19133de@github.com>

On Wed, 5 Apr 2023 06:12:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I used the inline code formatting (3 backquotes) to make the output clear, but maybe it looks differently for you or maybe your comment was while I was editing? 

It looks good now, so my comment was probably made during your edits.

> When you are ready, press "Finalize" and that will put in the CSR queue to review.

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1496975708

From alanb at openjdk.org  Wed Apr  5 06:56:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Apr 2023 06:56:13 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v6]
In-Reply-To: <YywTNp7DBB0Q24FsEBURdRQ76efk-_huOfBW3-aenSk=.d4f369f8-4f3f-4277-b61b-d07bf1384f9f@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <akKez57fnfshR7bdob_wHSmeDnRhsD8pDDKptpTE90s=.6b90034e-768b-4e4c-b512-f60763aec4b4@github.com>
 <kLZKUWtKDjFTVDDVTM4y2emeWYMTc7BHuGQRocEnOrw=.f13e2f3c-3f28-40db-8700-1cca88af6daa@github.com>
 <YywTNp7DBB0Q24FsEBURdRQ76efk-_huOfBW3-aenSk=.d4f369f8-4f3f-4277-b61b-d07bf1384f9f@github.com>
Message-ID: <6C3f6soy1El0-9gC4AnnJ4_NXyxsMQsfYcZe-ol3UYA=.96d92daf-c7e6-49ac-ab18-d556acea19b8@github.com>

On Wed, 5 Apr 2023 04:35:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Thread.java line 1846:
>> 
>>> 1844:     /**
>>> 1845:      * Returns true if this thread is alive.
>>> 1846:      * This method is non-final so it can be overridden.
>> 
>> Suggestion:
>> 
>>      * This method is non-final so it can be overridden by VirtualThread.
>
> :) I actually made that change in an earlier commit but decided to revert it because I assumed (@AlanBateman can confirm or refute) that it was left unspecific in case classes other than VirtualThread needed to override it.

isAlive is final so it delegates to an overridable method to allow for other implementations. Right now, it's just VirtualThread but the alt implementation might have to override it too. I think the comment can be left as it is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1158093009

From alanb at openjdk.org  Wed Apr  5 07:00:07 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Apr 2023 07:00:07 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v6]
In-Reply-To: <YywTNp7DBB0Q24FsEBURdRQ76efk-_huOfBW3-aenSk=.d4f369f8-4f3f-4277-b61b-d07bf1384f9f@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <akKez57fnfshR7bdob_wHSmeDnRhsD8pDDKptpTE90s=.6b90034e-768b-4e4c-b512-f60763aec4b4@github.com>
 <kLZKUWtKDjFTVDDVTM4y2emeWYMTc7BHuGQRocEnOrw=.f13e2f3c-3f28-40db-8700-1cca88af6daa@github.com>
 <YywTNp7DBB0Q24FsEBURdRQ76efk-_huOfBW3-aenSk=.d4f369f8-4f3f-4277-b61b-d07bf1384f9f@github.com>
Message-ID: <OUoDm9l4L6x8LYe2M88EieQzffH3uGNe2-Jyb9EBMnY=.cf1b8256-c48d-4335-99bf-cce615f357a1@github.com>

On Wed, 5 Apr 2023 04:37:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Thread.java line 235:
>> 
>>> 233:        and reset to zero when the thread terminates. A non-zero value indicates this thread
>>> 234:        isAlive().
>>> 235:     */
>> 
>> Maybe JavaDocify this?
>> Suggestion:
>> 
>>     /**
>>      * Reserved for exclusive use by the JVM. Cannot be moved to the FieldHolder
>>      * as it needs to be set by the VM before executing the constructor that
>>      * will create the FieldHolder. The historically named {@code eetop} holds
>>      * the address of the underlying VM JavaThread, and is set to non-zero when
>>      * the thread is started, and reset to zero when the thread terminates.
>>      * A non-zero value indicates this thread {@link #isAlive()}.
>>      */
>
> Being a private field it won't appear in any javadoc that anyone is ever likely to read. Only developers will see this (or need to see it) when they read the source code.

It's just a bit inconsistent with the other comments, no big deal.  I'd probably put an asterisk at the bringing of each time so it's consistent with the other /*..*/ comments on fields in this class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1158096207

From jpai at openjdk.org  Wed Apr  5 07:01:17 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Apr 2023 07:01:17 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v9]
In-Reply-To: <nFcbtXLuQHniBrOTa-1Iupa6-BuWo4f_ouLWCMKOv24=.01434cb5-1859-4c08-bdc0-307fab5e3d69@github.com>
References: <b2lIhVL1sHhnFTXvNSRBxxCd_b8KKUZz7mKWK1Zr6eY=.3d4fd0c8-a2b4-4510-bb6d-c68ad9de92bf@github.com>
 <nFcbtXLuQHniBrOTa-1Iupa6-BuWo4f_ouLWCMKOv24=.01434cb5-1859-4c08-bdc0-307fab5e3d69@github.com>
Message-ID: <dkBL6eP9AlPRAIXiTWf77dClbG1qJs_Ftn9CmtqMpq8=.9112cddb-1c31-430e-9a9f-36235894941d@github.com>

On Mon, 27 Mar 2023 16:18:22 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304745: Add comments for benchmark

Marked as reviewed by jpai (Reviewer).

src/java.base/share/classes/java/io/BufferedInputStream.java line 181:

> 179:         byte[] buffer = buf;
> 180:         if (allocateIfEmpty && buffer == EMPTY) {
> 181:             buffer = new byte[initialSize];

It took me a few rounds of reading this code to realize that this array allocation will only be done once even when multiple threads are involved, because when `buffer == EMPTY` (i.e. `BufferedInputStream` is not subclassed), then the call to `getBufIfOpen(...)` always happens after acquiring the `lock`. So, only one thread will ever enter this block. Looks good to me.

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

PR Review: https://git.openjdk.org/jdk/pull/13150#pullrequestreview-1372264626
PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1158097110

From duke at openjdk.org  Wed Apr  5 07:08:11 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 5 Apr 2023 07:08:11 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <bhwfEvvgT8rIUjF9EvPW6Ok3rVxijYadSJ8MaPE6tPE=.0d01c912-7f87-4d9a-98ac-ef7f155cec9b@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <bhwfEvvgT8rIUjF9EvPW6Ok3rVxijYadSJ8MaPE6tPE=.0d01c912-7f87-4d9a-98ac-ef7f155cec9b@github.com>
Message-ID: <NGmHVOi3lHnU_rT5YpeoV-fpTN6QMhsGVXSmNvU6cHQ=.67c55b1f-349a-4626-902e-9069ff7c60bc@github.com>

On Wed, 5 Apr 2023 05:53:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The new test that was planned for testing `JarFile` and `JarInputStream` when dealing with a jar containing a `META-INF/INDEX.LIST`, is that something that you want to be done as a separate PR/task? It's fine with me if you want that to be done separately.

@jaikiran 

I was looking into creating such a test yesterday. For `JarInputStream`, I was able to write a tests which expects a certain order of entries. This could made broken by disabling the `META-INF/INDEX.LIST` check in `JarInputStream.getNextEntry`.

With `JarVerifier`, I'm struggling to create a scenario which excercises the `META-INF/INDEX.LIST` check. It seems to me this code is simply unreachable, even after moving the `META-INF/INDEX.LIST` file first in the JAR.

If the code is properly unreachable, then maybe we should consider removing it?

In any case, since I feel the current test is somewhat dubious, I checked it into another branch here:

https://github.com/eirbjo/jdk/blob/remove-jar-index-test/test/jdk/java/util/jar/JarFile/JarIndexLegacyJars.java

This is perhaps better than having no tests. I'm not feeling sure about this, please let me know what you think. Perhaps @AlanBateman also has an opinion on this?

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1497017466

From alanb at openjdk.org  Wed Apr  5 07:12:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Apr 2023 07:12:13 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v9]
In-Reply-To: <nFcbtXLuQHniBrOTa-1Iupa6-BuWo4f_ouLWCMKOv24=.01434cb5-1859-4c08-bdc0-307fab5e3d69@github.com>
References: <b2lIhVL1sHhnFTXvNSRBxxCd_b8KKUZz7mKWK1Zr6eY=.3d4fd0c8-a2b4-4510-bb6d-c68ad9de92bf@github.com>
 <nFcbtXLuQHniBrOTa-1Iupa6-BuWo4f_ouLWCMKOv24=.01434cb5-1859-4c08-bdc0-307fab5e3d69@github.com>
Message-ID: <Wk7S_ogheoFOpmayDF94vwiGGQezF4g9cenbxUttqNs=.71f72ab0-40c6-4874-b70e-764ec87cd1fb@github.com>

On Mon, 27 Mar 2023 16:18:22 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304745: Add comments for benchmark

So I think the main thing now is to decide whether the benchmark should be included or not.

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

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1497021299

From dholmes at openjdk.org  Wed Apr  5 07:23:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Apr 2023 07:23:03 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v7]
In-Reply-To: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
Message-ID: <jTxe3uvd2ovkmOTPKa43cQDHL8aa-PSTrHkf-mStV4A=.4bf40b36-ef35-4b59-a306-8155d18d021a@github.com>

> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
> 
> boolean alive() {
>   return eetop != 0;
> } 
> 
> I also updated a comment in relation to `eetop`.
> 
> Testing: tiers 1-3
> 
> Thanks

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

  Reformat comment block

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13287/files
  - new: https://git.openjdk.org/jdk/pull/13287/files/d284547c..8e662cdf

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

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

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

From dholmes at openjdk.org  Wed Apr  5 07:23:04 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Apr 2023 07:23:04 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v6]
In-Reply-To: <OUoDm9l4L6x8LYe2M88EieQzffH3uGNe2-Jyb9EBMnY=.cf1b8256-c48d-4335-99bf-cce615f357a1@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <akKez57fnfshR7bdob_wHSmeDnRhsD8pDDKptpTE90s=.6b90034e-768b-4e4c-b512-f60763aec4b4@github.com>
 <kLZKUWtKDjFTVDDVTM4y2emeWYMTc7BHuGQRocEnOrw=.f13e2f3c-3f28-40db-8700-1cca88af6daa@github.com>
 <YywTNp7DBB0Q24FsEBURdRQ76efk-_huOfBW3-aenSk=.d4f369f8-4f3f-4277-b61b-d07bf1384f9f@github.com>
 <OUoDm9l4L6x8LYe2M88EieQzffH3uGNe2-Jyb9EBMnY=.cf1b8256-c48d-4335-99bf-cce615f357a1@github.com>
Message-ID: <llh2lXWX-Vv4e36IA3xaOZaxUW4Qk5M_ssF49jtysSs=.4664adf7-76e2-4a6a-9455-4542c541ad94@github.com>

On Wed, 5 Apr 2023 06:56:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Being a private field it won't appear in any javadoc that anyone is ever likely to read. Only developers will see this (or need to see it) when they read the source code.
>
> It's just a bit inconsistent with the other comments, no big deal.  I'd probably put an asterisk at the bringing of each time so it's consistent with the other /*..*/ comments on fields in this class.

Added the asterisks. Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1158115339

From shade at openjdk.org  Wed Apr  5 08:23:19 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Apr 2023 08:23:19 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v7]
In-Reply-To: <jTxe3uvd2ovkmOTPKa43cQDHL8aa-PSTrHkf-mStV4A=.4bf40b36-ef35-4b59-a306-8155d18d021a@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <jTxe3uvd2ovkmOTPKa43cQDHL8aa-PSTrHkf-mStV4A=.4bf40b36-ef35-4b59-a306-8155d18d021a@github.com>
Message-ID: <jLV5_NuZwnjm__Qw5O31LhiAjKU7D6bfotMCDkxQdJw=.a589e2a4-188f-43e7-acca-18e0a76315a9@github.com>

On Wed, 5 Apr 2023 07:23:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
>> 
>> boolean alive() {
>>   return eetop != 0;
>> } 
>> 
>> I also updated a comment in relation to `eetop`.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat comment block

I am good with this version. Consider the following amendments, if you have any other fixes for this PR in the pipeline. Ignore if not, no need to spend more time testing this.

test/jdk/java/lang/Thread/IsAlive.java line 38:

> 36:         try {
> 37:             while (!Thread.currentThread().isInterrupted()) {
> 38:                 Thread.sleep(10);

Suggestion:

                Thread.sleep(100);

test/jdk/java/lang/Thread/IsAlive.java line 62:

> 60: 
> 61:         if (!spinnerDone) {
> 62:             throw new RuntimeException("last write of terminated thread wasn't seen!");

Suggestion:

            throw new RuntimeException("Last write of terminated thread was not seen!");

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13287#pullrequestreview-1372395326
PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1158184386
PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1158184236

From dholmes at openjdk.org  Wed Apr  5 08:37:26 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Apr 2023 08:37:26 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v8]
In-Reply-To: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
Message-ID: <SnfypS1G5cpjvXzaNQXzbxCNOzurav7nZJeUVTKTBX4=.ceaaf102-ba13-4fcd-925f-6a5f498b20a2@github.com>

> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
> 
> boolean alive() {
>   return eetop != 0;
> } 
> 
> I also updated a comment in relation to `eetop`.
> 
> Testing: tiers 1-3
> 
> Thanks

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

  Test tweaks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13287/files
  - new: https://git.openjdk.org/jdk/pull/13287/files/8e662cdf..dbb9a91a

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

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

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

From dholmes at openjdk.org  Wed Apr  5 08:37:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Apr 2023 08:37:28 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v2]
In-Reply-To: <Ia8Pj1HOhPFQTknJECLBIhavjtRTMZZATrvacVX6Fk8=.c748d32a-a636-4a20-9679-4df4cf17890d@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <Rvm7pyAc7BpF7m4H00gSdbHRsooRwD2msZ6_RETtPLU=.ca7096e0-2571-43df-9110-8f506b648abb@github.com>
 <5H50Wgs59idINOYfxPzUpnMAxCzXBn7H9rxSYDCUApI=.17ccba9a-629b-4ff8-a6e6-05b82d3d8fb9@github.com>
 <01nnripfJun4F9CZ5MBhaUa_KsLB67FFOFHqRjRPWZQ=.4c7255a9-70d2-4bf5-967f-4f97de073fb3@github.com>
 <Ia8Pj1HOhPFQTknJECLBIhavjtRTMZZATrvacVX6Fk8=.c748d32a-a636-4a20-9679-4df4cf17890d@github.com>
Message-ID: <O7PtYy52JJVAYByJSZEAX71Xl2gIPZYQ2sYvvqnuuFc=.6133fcef-b26a-4dd3-8c00-20f43dfbb30a@github.com>

On Mon, 3 Apr 2023 13:57:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> This looks interesting. I think it is time to rename eetop to javaThreadAddr ...
>> 
>> Feel free to file a RFE but not as part of this PR. :)
>
>> > This looks interesting. I think it is time to rename eetop to javaThreadAddr ...
>> 
>> Feel free to file a RFE but not as part of this PR. :)
> 
> Well, when this thing is considered in isolation, it changes the clear `isAlive0()` call to rather obscure `eetop != 0` condition, with no documentation what that field actually is. At very least we should add the comment that the field carries the native thread pointer, and `!= 0` is actually checking for `null`.
> 
> But, someone (who should remain anonymous under the alias, say... rolls dice... Andrei?) pointed out that async-profiler looks up `eetop`, so the rename would break the profiler until the renamed field is handled there. So the rename at this point is a bit dicey: https://github.com/async-profiler/async-profiler/blob/39b0bdb5e446b1b88acdf37fd18a4560f5176a2e/src/vmStructs.cpp#L409

Thanks for the review @shipilev !

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

PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1497115716

From dholmes at openjdk.org  Wed Apr  5 08:37:31 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Apr 2023 08:37:31 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v7]
In-Reply-To: <jLV5_NuZwnjm__Qw5O31LhiAjKU7D6bfotMCDkxQdJw=.a589e2a4-188f-43e7-acca-18e0a76315a9@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <jTxe3uvd2ovkmOTPKa43cQDHL8aa-PSTrHkf-mStV4A=.4bf40b36-ef35-4b59-a306-8155d18d021a@github.com>
 <jLV5_NuZwnjm__Qw5O31LhiAjKU7D6bfotMCDkxQdJw=.a589e2a4-188f-43e7-acca-18e0a76315a9@github.com>
Message-ID: <saSq4wCa6OEgd_-R8vVeKSCl4d7JlVW_3bBoBuHfiLk=.a89bd0fc-7c50-495d-84fa-7dc9624c69b2@github.com>

On Wed, 5 Apr 2023 08:19:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reformat comment block
>
> test/jdk/java/lang/Thread/IsAlive.java line 38:
> 
>> 36:         try {
>> 37:             while (!Thread.currentThread().isInterrupted()) {
>> 38:                 Thread.sleep(10);
> 
> Suggestion:
> 
>                 Thread.sleep(100);

Done

> test/jdk/java/lang/Thread/IsAlive.java line 62:
> 
>> 60: 
>> 61:         if (!spinnerDone) {
>> 62:             throw new RuntimeException("last write of terminated thread wasn't seen!");
> 
> Suggestion:
> 
>             throw new RuntimeException("Last write of terminated thread was not seen!");

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1158200731
PR Review Comment: https://git.openjdk.org/jdk/pull/13287#discussion_r1158199923

From alanb at openjdk.org  Wed Apr  5 08:42:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Apr 2023 08:42:16 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java line 406:

> 404:                 case MACOS -> newInstance("jdk.net.MacOSXSocketOptions");
> 405:                 case WINDOWS -> newInstance("jdk.net.WindowsSocketOptions");
> 406:                 default -> new PlatformSocketOptions();

For another issue, but I assume this could be refactored to not need PlatformSocketOptions, in which case the mapping of OS name to implementation class would go away.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2882:

> 2880:                     elenNTFS = 36;           // total 36 bytes
> 2881:                 } else {                     // Extended Timestamp otherwise
> 2882:                     elenEXTT = 9;            // only mtime in cen

It might be better to drop ZipFileSystem from this patch and instead create a bug to re-examine this code. I would have expected it use NFTS when the timestamp is beyond the range of an extended timestamp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158209156
PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158206710

From alanb at openjdk.org  Wed Apr  5 08:51:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Apr 2023 08:51:18 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v8]
In-Reply-To: <SnfypS1G5cpjvXzaNQXzbxCNOzurav7nZJeUVTKTBX4=.ceaaf102-ba13-4fcd-925f-6a5f498b20a2@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <SnfypS1G5cpjvXzaNQXzbxCNOzurav7nZJeUVTKTBX4=.ceaaf102-ba13-4fcd-925f-6a5f498b20a2@github.com>
Message-ID: <7xiFw07DnVBoaQ3vuDPOI_I1Dhy3Gsu2PsBFRvguAZY=.1b663448-ae4c-4f4a-aec6-639e8cc1e8c6@github.com>

On Wed, 5 Apr 2023 08:37:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
>> 
>> boolean alive() {
>>   return eetop != 0;
>> } 
>> 
>> I also updated a comment in relation to `eetop`.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test tweaks

Yes, I suspect having isAlive be synchronized would have had side-effects and maybe deadlock in some cases. Volatile-read on the libs side + OrderAccess::release in the VM at termination time looks okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13287#pullrequestreview-1372446213

From duke at openjdk.org  Wed Apr  5 09:28:21 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 5 Apr 2023 09:28:21 GMT
Subject: RFR: JDK-8170945: Collectors$Partition should override more Map
 methods
Message-ID: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>

Adds overrides for common Map operations to avoid having to allocate the entrySet for Collectors$Partition maps.

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

Commit messages:
 - Overriding containsKey and containsValue of Collectors
 - JDK-8170945: override more Map-methods on Collectors

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

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

From jwaters at openjdk.org  Wed Apr  5 09:39:19 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 5 Apr 2023 09:39:19 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v2]
In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
Message-ID: <AARIkAf0Mo2WIiPfhdiMYxeCWFhAE8BlprS805U_mdY=.34d1b36e-1db7-4deb-8046-22265b418a45@github.com>

> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

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

 - gcc offset_of
 - Remove Visual C++ alignment
 - Remove gcc alignment
 - globalDefinitions.hpp
 - Merge branch 'openjdk:master' into patch-6
 - <stdalign.h>
 - GSSLibStub.c
 - ArrayReferenceImpl.c
 - Alignment outside of HotSpot should be enforced by alignas instead of compiler specific attributes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13258/files
  - new: https://git.openjdk.org/jdk/pull/13258/files/7e5e6449..7dc7f7d8

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

  Stats: 16524 lines in 394 files changed: 7231 ins; 8051 del; 1242 mod
  Patch: https://git.openjdk.org/jdk/pull/13258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13258/head:pull/13258

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

From jwaters at openjdk.org  Wed Apr  5 09:39:22 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 5 Apr 2023 09:39:22 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes
In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
Message-ID: <648nGU6epXFxCy9rfbKldQsb_LN7wqrjkzQMN9n3z98=.4d090b19-8f13-4740-a595-17b0564d3a54@github.com>

On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

Hmm, right I'll link that issue into this one as well then

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

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1497188210

From lancea at openjdk.org  Wed Apr  5 10:28:20 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 5 Apr 2023 10:28:20 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <NGmHVOi3lHnU_rT5YpeoV-fpTN6QMhsGVXSmNvU6cHQ=.67c55b1f-349a-4626-902e-9069ff7c60bc@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <bhwfEvvgT8rIUjF9EvPW6Ok3rVxijYadSJ8MaPE6tPE=.0d01c912-7f87-4d9a-98ac-ef7f155cec9b@github.com>
 <NGmHVOi3lHnU_rT5YpeoV-fpTN6QMhsGVXSmNvU6cHQ=.67c55b1f-349a-4626-902e-9069ff7c60bc@github.com>
Message-ID: <amSmQvZ0xqhJvib4GKRW6bvPHLkrFS1jAJ-VICULtA0=.5d1063fa-78da-459b-adec-7d602a239a5e@github.com>

On Wed, 5 Apr 2023 07:05:11 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> > The new test that was planned for testing `JarFile` and `JarInputStream` when dealing with a jar containing a `META-INF/INDEX.LIST`, is that something that you want to be done as a separate PR/task? It's fine with me if you want that to be done separately.
> 
> @jaikiran
> 
> I was looking into creating such a test yesterday. For `JarInputStream`, I was able to write a tests which expects a certain order of entries. This could made broken by disabling the `META-INF/INDEX.LIST` check in `JarInputStream.getNextEntry`.
> 
> With `JarVerifier`, I'm struggling to create a scenario which excercises the `META-INF/INDEX.LIST` check. It seems to me this code is simply unreachable, even after moving the `META-INF/INDEX.LIST` file first in the JAR.
> 
> If the code is properly unreachable, then maybe we should consider removing it?
> 
> In any case, since I feel the current test is somewhat dubious, I checked it into another branch here:
> 
> https://github.com/eirbjo/jdk/blob/remove-jar-index-test/test/jdk/java/util/jar/JarFile/JarIndexLegacyJars.java
> 
> This is perhaps better than having no tests. I'm not feeling sure about this, please let me know what you think. Perhaps @AlanBateman also has an opinion on this?

I am not convinced we need a test but to your point Jai, Eirik, lets handle this as a separate PR/Issue and work through what we are hoping to achieve/validate

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1497259301

From alanb at openjdk.org  Wed Apr  5 10:38:20 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Apr 2023 10:38:20 GMT
Subject: RFR: JDK-8170945: Collectors$Partition should override more Map
 methods
In-Reply-To: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
References: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
Message-ID: <YJEDxTwWTtqJ6tAO1xvHsyPFRbjJLpOZ_wyQuPPW38w=.4302ca3f-dd95-448e-9d0e-1464dfb7b8ac@github.com>

On Wed, 5 Apr 2023 09:19:57 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Adds overrides for common Map operations to avoid having to allocate the entrySet for Collectors$Partition maps.

src/java.base/share/classes/java/util/stream/Collectors.java line 1988:

> 1986:         public T get(Object key) {
> 1987:             if (key instanceof Boolean b) {
> 1988:                 return b.booleanValue() ? forTrue : forFalse;

Usages of partitioningBy are likely to be followed by get(TRUE) and get(FALSE) to get the sets in each partition, so this looks good, avoids needing the entrySet and and iterator.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13347#discussion_r1158336071

From mbaesken at openjdk.org  Wed Apr  5 10:54:15 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Apr 2023 10:54:15 GMT
Subject: RFR: JDK-8305646: compile error on Alpine with gcc12 after 8298619 in
 libGetXSpace.c
Message-ID: <Zf_gfZj3Ih8j32OGcMMMIy7fDFu8PiV06MZhsXdyhec=.b99c6a82-b74c-4514-bc90-a56022219346@github.com>

On Alpine Linux, using gcc12, we run now into this compile warning as error :
In file included from /openjdk/linuxmuslx86_64/jdk/test/jdk/java/io/File/libGetXSpace.c:31:
/usr/include/sys/errno.h:1:2: error: #warning redirecting incorrect #include <sys/errno.h> to <errno.h> [-Werror=cpp]
    1 | #warning redirecting incorrect #include <sys/errno.h> to <errno.h>
      | ^~~~~~~
cc1: all warnings being treated as errors

We probably better just include <errno.h> like it is done at almost all other places in the codebase.

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

Commit messages:
 - JDK-8305646

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

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

From alanb at openjdk.org  Wed Apr  5 10:58:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Apr 2023 10:58:06 GMT
Subject: RFR: JDK-8305646: compile error on Alpine with gcc12 after 8298619
 in libGetXSpace.c
In-Reply-To: <Zf_gfZj3Ih8j32OGcMMMIy7fDFu8PiV06MZhsXdyhec=.b99c6a82-b74c-4514-bc90-a56022219346@github.com>
References: <Zf_gfZj3Ih8j32OGcMMMIy7fDFu8PiV06MZhsXdyhec=.b99c6a82-b74c-4514-bc90-a56022219346@github.com>
Message-ID: <j14dzLVFLoaZFqjuXSUBdARH8PO89s4auskI065kXzE=.4c66ef89-835f-449a-8433-02910b09a43f@github.com>

On Wed, 5 Apr 2023 10:47:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Alpine Linux, using gcc12, we run now into this compile warning as error :
> In file included from /openjdk/linuxmuslx86_64/jdk/test/jdk/java/io/File/libGetXSpace.c:31:
> /usr/include/sys/errno.h:1:2: error: #warning redirecting incorrect #include <sys/errno.h> to <errno.h> [-Werror=cpp]
>     1 | #warning redirecting incorrect #include <sys/errno.h> to <errno.h>
>       | ^~~~~~~
> cc1: all warnings being treated as errors
> 
> We probably better just include <errno.h> like it is done at almost all other places in the codebase.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13349#pullrequestreview-1372658193

From duke at openjdk.org  Wed Apr  5 11:09:18 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 5 Apr 2023 11:09:18 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <amSmQvZ0xqhJvib4GKRW6bvPHLkrFS1jAJ-VICULtA0=.5d1063fa-78da-459b-adec-7d602a239a5e@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <bhwfEvvgT8rIUjF9EvPW6Ok3rVxijYadSJ8MaPE6tPE=.0d01c912-7f87-4d9a-98ac-ef7f155cec9b@github.com>
 <NGmHVOi3lHnU_rT5YpeoV-fpTN6QMhsGVXSmNvU6cHQ=.67c55b1f-349a-4626-902e-9069ff7c60bc@github.com>
 <amSmQvZ0xqhJvib4GKRW6bvPHLkrFS1jAJ-VICULtA0=.5d1063fa-78da-459b-adec-7d602a239a5e@github.com>
Message-ID: <qpuVT0Ad52mJlpqnttoqUyehD78j7XBAq2FgcNMh8KY=.4d231f3d-cabf-43db-9d69-994424fe1292@github.com>

On Wed, 5 Apr 2023 10:25:01 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I am not convinced we need a test but to your point Jai, Eirik, lets handle this as a separate PR/Issue and work through what we are hoping to achieve/validate

Good. Let's agree to handle testing of dusty 'index jars' separately from this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1497307096

From shade at openjdk.org  Wed Apr  5 11:10:15 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Apr 2023 11:10:15 GMT
Subject: RFR: JDK-8305646: compile error on Alpine with gcc12 after 8298619
 in libGetXSpace.c
In-Reply-To: <Zf_gfZj3Ih8j32OGcMMMIy7fDFu8PiV06MZhsXdyhec=.b99c6a82-b74c-4514-bc90-a56022219346@github.com>
References: <Zf_gfZj3Ih8j32OGcMMMIy7fDFu8PiV06MZhsXdyhec=.b99c6a82-b74c-4514-bc90-a56022219346@github.com>
Message-ID: <qSMm1hUXEJsyrfOZC9Kcid0HVD6eW2mZF0BAhY7B0o8=.089d4fcd-fb3e-4815-b26c-76744b47b3e5@github.com>

On Wed, 5 Apr 2023 10:47:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Alpine Linux, using gcc12, we run now into this compile warning as error :
> In file included from /openjdk/linuxmuslx86_64/jdk/test/jdk/java/io/File/libGetXSpace.c:31:
> /usr/include/sys/errno.h:1:2: error: #warning redirecting incorrect #include <sys/errno.h> to <errno.h> [-Werror=cpp]
>     1 | #warning redirecting incorrect #include <sys/errno.h> to <errno.h>
>       | ^~~~~~~
> cc1: all warnings being treated as errors
> 
> We probably better just include <errno.h> like it is done at almost all other places in the codebase.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13349#pullrequestreview-1372674972

From mbaesken at openjdk.org  Wed Apr  5 11:27:12 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Apr 2023 11:27:12 GMT
Subject: RFR: JDK-8305646: compile error on Alpine with gcc12 after 8298619
 in libGetXSpace.c
In-Reply-To: <Zf_gfZj3Ih8j32OGcMMMIy7fDFu8PiV06MZhsXdyhec=.b99c6a82-b74c-4514-bc90-a56022219346@github.com>
References: <Zf_gfZj3Ih8j32OGcMMMIy7fDFu8PiV06MZhsXdyhec=.b99c6a82-b74c-4514-bc90-a56022219346@github.com>
Message-ID: <2P9HR5E88zecgI1-28VU-LPTfpFX3HUGtWvZesw4G1I=.aec70413-e1bd-4e12-bf3e-6ed079cee01c@github.com>

On Wed, 5 Apr 2023 10:47:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Alpine Linux, using gcc12, we run now into this compile warning as error :
> In file included from /openjdk/linuxmuslx86_64/jdk/test/jdk/java/io/File/libGetXSpace.c:31:
> /usr/include/sys/errno.h:1:2: error: #warning redirecting incorrect #include <sys/errno.h> to <errno.h> [-Werror=cpp]
>     1 | #warning redirecting incorrect #include <sys/errno.h> to <errno.h>
>       | ^~~~~~~
> cc1: all warnings being treated as errors
> 
> We probably better just include <errno.h> like it is done at almost all other places in the codebase.

Hi Alan and Aleksey, thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/13349#issuecomment-1497326575

From dholmes at openjdk.org  Wed Apr  5 12:38:10 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Apr 2023 12:38:10 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v8]
In-Reply-To: <7xiFw07DnVBoaQ3vuDPOI_I1Dhy3Gsu2PsBFRvguAZY=.1b663448-ae4c-4f4a-aec6-639e8cc1e8c6@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
 <SnfypS1G5cpjvXzaNQXzbxCNOzurav7nZJeUVTKTBX4=.ceaaf102-ba13-4fcd-925f-6a5f498b20a2@github.com>
 <7xiFw07DnVBoaQ3vuDPOI_I1Dhy3Gsu2PsBFRvguAZY=.1b663448-ae4c-4f4a-aec6-639e8cc1e8c6@github.com>
Message-ID: <PTitSzPiOToqL-DMPdPQ_HlwLbgppON-tU9hlLNCPc8=.2c4824ee-d851-45df-b3b4-bc0d10c7f90d@github.com>

On Wed, 5 Apr 2023 08:48:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test tweaks
>
> Yes, I suspect having isAlive be synchronized would have had side-effects and maybe deadlock in some cases. Volatile-read on the libs side + OrderAccess::release in the VM at termination time looks okay.

Thanks for the review @AlanBateman !

Any further comments from anyone else?

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

PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1497414936

From tvaleev at openjdk.org  Wed Apr  5 12:41:17 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 5 Apr 2023 12:41:17 GMT
Subject: RFR: JDK-8170945: Collectors$Partition should override more Map
 methods
In-Reply-To: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
References: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
Message-ID: <3K3xtGYQRQW3zEVZY5g13lotl0sL0pdyMUXnKrnRJ04=.5c5ccc6b-1b6d-4033-9c78-81fb3deb2e81@github.com>

On Wed, 5 Apr 2023 09:19:57 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Adds overrides for common Map operations to avoid having to allocate the entrySet for Collectors$Partition maps.

Interesting improvement!

How about `forEach` and `values`? These look quite easy to implement.


    @Override
    public void forEach(BiConsumer<? super Boolean, ? super T> action) {
      Objects.requireNonNull(action);
      action.accept(Boolean.FALSE, forFalse);
      action.accept(Boolean.TRUE, forTrue);
    }

    @Override
    public Collection<T> values() {
      return List.of(forFalse, forTrue);
    }


Theoretically, it would be possible to simplify `entrySet()` and `keySet()` as well:

    @Override
    public Set<Entry<Boolean, T>> entrySet() {
      return Set.of(new SimpleImmutableEntry<>(false, forFalse),
              new SimpleImmutableEntry<>(true, forTrue));
    }

    @Override
    public Set<Boolean> keySet() {
      return Set.of(false, true);
    }


However, this won't guarantee the order of false and true. On one hand, this order was never guaranteed. On the other hand, it might be nice to have. However, soon we may have a facility to explicitly state that the order is preserved, namely, SequencedMap (PR #7387). If we really want to guarantee the order, probably it would be better to implement SequencedMap here (when PR #7387 will be merged)? Though this may require adding more methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/13347#issuecomment-1497418841

From tvaleev at openjdk.org  Wed Apr  5 12:55:13 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 5 Apr 2023 12:55:13 GMT
Subject: RFR: JDK-8170945: Collectors$Partition should override more Map
 methods
In-Reply-To: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
References: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
Message-ID: <DA9tvsYd9Ed46EADNk4AAiQI-s7I9RFd6DEkBEgEAzw=.fcccbf55-53dc-437c-9f8c-d0e3861d7b33@github.com>

On Wed, 5 Apr 2023 09:19:57 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Adds overrides for common Map operations to avoid having to allocate the entrySet for Collectors$Partition maps.

Another thing I noticed is that `keySet()` of this map is a constant. If we want to preserve the order, we can use something like this:


    @Override
    public Set<Boolean> keySet() {
      return KeySet.INSTANCE;
    }

    private static class KeySet extends AbstractSet<Boolean> {
      private static final KeySet INSTANCE = new KeySet();
      
      public Iterator<Boolean> iterator() {
        return List.of(false, true).iterator();
      }

      public int size() {
        return 2;
      }

      @Override
      public int hashCode() {
        // Boolean.hashCode(true) + Boolean.hashCode(false)
        return 1237 + 1231;
      }

      @Override
      public boolean equals(Object o) {
        return o instanceof Set<?> s &&
                s.size() == 2 &&
                s.contains(false) && s.contains(true);
      }

      public boolean isEmpty() {
        return false;
      }

      public boolean contains(Object k) {
        return k instanceof Boolean;
      }

      @Override
      public void forEach(Consumer<? super Boolean> action) {
        Objects.requireNonNull(action);
        action.accept(false);
        action.accept(true);
      }

      @Override
      public String toString() {
        return "[false, true]";
      }
    }


Overengineering, probably? On the other hand, it might be useful to expose this set somewhere, like `Collections.booleans()`? This would allow using `for(boolean b: Collections.booleans()) {...}`. In our codebase, I see quite many loops like `for (boolean b : new boolean[]{false, true})`. Declaring it as a `SequencedSet` would be even more useful, as one may control the order via `Collections.booleans().reversed()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/13347#issuecomment-1497432746

From aturbanov at openjdk.org  Wed Apr  5 12:55:14 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 5 Apr 2023 12:55:14 GMT
Subject: RFR: JDK-8170945: Collectors$Partition should override more Map
 methods
In-Reply-To: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
References: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
Message-ID: <pCqu2BewIxK43QXJxrBWOygNle0ZajFM-XpXx--fl2o=.23884727-d98a-4322-b610-787f66685896@github.com>

On Wed, 5 Apr 2023 09:19:57 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Adds overrides for common Map operations to avoid having to allocate the entrySet for Collectors$Partition maps.

src/java.base/share/classes/java/util/stream/Collectors.java line 1988:

> 1986:         public T get(Object key) {
> 1987:             if (key instanceof Boolean b) {
> 1988:                 return b.booleanValue() ? forTrue : forFalse;

Can we drop `.booleanValue()` ?
Suggestion:

                return b ? forTrue : forFalse;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13347#discussion_r1158478074

From duke at openjdk.org  Wed Apr  5 13:22:15 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 5 Apr 2023 13:22:15 GMT
Subject: RFR: JDK-8170945: Collectors$Partition should override more Map
 methods
In-Reply-To: <pCqu2BewIxK43QXJxrBWOygNle0ZajFM-XpXx--fl2o=.23884727-d98a-4322-b610-787f66685896@github.com>
References: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
 <pCqu2BewIxK43QXJxrBWOygNle0ZajFM-XpXx--fl2o=.23884727-d98a-4322-b610-787f66685896@github.com>
Message-ID: <E0-nt7HWDXJgF200ux6yOcNJMupmyGhbVE3-h1gr8vw=.b1fb4e01-7177-42e1-9f69-cff2a9658462@github.com>

On Wed, 5 Apr 2023 12:52:11 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Adds overrides for common Map operations to avoid having to allocate the entrySet for Collectors$Partition maps.
>
> src/java.base/share/classes/java/util/stream/Collectors.java line 1988:
> 
>> 1986:         public T get(Object key) {
>> 1987:             if (key instanceof Boolean b) {
>> 1988:                 return b.booleanValue() ? forTrue : forFalse;
> 
> Can we drop `.booleanValue()` ?
> Suggestion:
> 
>                 return b ? forTrue : forFalse;

@turbanoff Definitely possible, I added it because it visually distinguishes that it is a boxed value, but perhaps relying on autoboxing in this case is just fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13347#discussion_r1158509411

From duke at openjdk.org  Wed Apr  5 13:28:13 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 5 Apr 2023 13:28:13 GMT
Subject: RFR: JDK-8170945: Collectors$Partition should override more Map
 methods
In-Reply-To: <DA9tvsYd9Ed46EADNk4AAiQI-s7I9RFd6DEkBEgEAzw=.fcccbf55-53dc-437c-9f8c-d0e3861d7b33@github.com>
References: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
 <DA9tvsYd9Ed46EADNk4AAiQI-s7I9RFd6DEkBEgEAzw=.fcccbf55-53dc-437c-9f8c-d0e3861d7b33@github.com>
Message-ID: <xJM84Cg86-iXJxSK3XYE3irqyVC_4NSJ18JZKZViFrU=.4560bc30-af02-459c-84b9-107932601c34@github.com>

On Wed, 5 Apr 2023 12:49:31 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Adds overrides for common Map operations to avoid having to allocate the entrySet for Collectors$Partition maps.
>
> Another thing I noticed is that `keySet()` of this map is a constant. If we want to preserve the order, we can use something like this:
> 
> 
>     @Override
>     public Set<Boolean> keySet() {
>       return KeySet.INSTANCE;
>     }
> 
>     private static class KeySet extends AbstractSet<Boolean> {
>       private static final KeySet INSTANCE = new KeySet();
>       
>       public Iterator<Boolean> iterator() {
>         return List.of(false, true).iterator();
>       }
> 
>       public int size() {
>         return 2;
>       }
> 
>       @Override
>       public int hashCode() {
>         // Boolean.hashCode(true) + Boolean.hashCode(false)
>         return 1237 + 1231;
>       }
> 
>       @Override
>       public boolean equals(Object o) {
>         return o instanceof Set<?> s &&
>                 s.size() == 2 &&
>                 s.contains(false) && s.contains(true);
>       }
> 
>       public boolean isEmpty() {
>         return false;
>       }
> 
>       public boolean contains(Object k) {
>         return k instanceof Boolean;
>       }
> 
>       @Override
>       public void forEach(Consumer<? super Boolean> action) {
>         Objects.requireNonNull(action);
>         action.accept(false);
>         action.accept(true);
>       }
> 
>       @Override
>       public String toString() {
>         return "[false, true]";
>       }
>     }
> 
> 
> Overengineering, probably? On the other hand, it might be useful to expose this set somewhere, like `Collections.booleans()`? This would allow using `for(boolean b: Collections.booleans()) {...}`. In our codebase, I see quite many loops like `for (boolean b : new boolean[]{false, true})`. Declaring it as a `SequencedSet` would be even more useful, as one may control the order via `Collections.booleans().reversed()`.

@amaembo I think ideally the entire Partition class could be replaced in favor of some `OrderedMap.of(Boolean.TRUE, forTrue, Boolean.FALSE, forFalse)` version. I'll let @stuart-marks chime in if there's other options on the table here. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/13347#issuecomment-1497483295

From mbaesken at openjdk.org  Wed Apr  5 13:30:25 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Apr 2023 13:30:25 GMT
Subject: Integrated: JDK-8305646: compile error on Alpine with gcc12 after
 8298619 in libGetXSpace.c
In-Reply-To: <Zf_gfZj3Ih8j32OGcMMMIy7fDFu8PiV06MZhsXdyhec=.b99c6a82-b74c-4514-bc90-a56022219346@github.com>
References: <Zf_gfZj3Ih8j32OGcMMMIy7fDFu8PiV06MZhsXdyhec=.b99c6a82-b74c-4514-bc90-a56022219346@github.com>
Message-ID: <FGL0pFToZcVS-8zA8Sc905WaweBPWInLVFJE_AXvIr4=.a8f38833-dc02-446a-b0c0-11d064818f26@github.com>

On Wed, 5 Apr 2023 10:47:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Alpine Linux, using gcc12, we run now into this compile warning as error :
> In file included from /openjdk/linuxmuslx86_64/jdk/test/jdk/java/io/File/libGetXSpace.c:31:
> /usr/include/sys/errno.h:1:2: error: #warning redirecting incorrect #include <sys/errno.h> to <errno.h> [-Werror=cpp]
>     1 | #warning redirecting incorrect #include <sys/errno.h> to <errno.h>
>       | ^~~~~~~
> cc1: all warnings being treated as errors
> 
> We probably better just include <errno.h> like it is done at almost all other places in the codebase.

This pull request has now been integrated.

Changeset: a3137c75
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3137c750f37d8fb03fd93f12e699df790adb327
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8305646: compile error on Alpine with gcc12 after 8298619 in libGetXSpace.c

Reviewed-by: alanb, shade

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

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

From pminborg at openjdk.org  Wed Apr  5 14:07:47 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 5 Apr 2023 14:07:47 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v17]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <9PKnuMc3_0dEdBMHR6hectXHSSYnUVCC5i0jdemzVjA=.998f626e-e2d9-4b03-9ccb-1b93c1082b27@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

  Update JEP number and name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/928ad35e..3a4d9f66

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

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

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

From rriggs at openjdk.org  Wed Apr  5 14:11:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 14:11:18 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
Message-ID: <F8Jr6kezM5OXPwzssO4GuD_FFHdkruuTw955hwPJ9Kc=.fb2ede42-7b0d-4221-9c87-bfa0df005123@github.com>

On Wed, 5 Apr 2023 08:39:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java line 406:
> 
>> 404:                 case MACOS -> newInstance("jdk.net.MacOSXSocketOptions");
>> 405:                 case WINDOWS -> newInstance("jdk.net.WindowsSocketOptions");
>> 406:                 default -> new PlatformSocketOptions();
> 
> For another issue, but I assume this could be refactored to not need PlatformSocketOptions, in which case the mapping of OS name to implementation class would go away.

Created an issue to track the possible refactoring, will keep this change until then.
https://bugs.openjdk.org/browse/JDK-8305661

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158574021

From pminborg at openjdk.org  Wed Apr  5 14:20:46 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 5 Apr 2023 14:20:46 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v18]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <_PWutk51h6HTKm9BEzpkSLUxUXjDmg3YHQM-ojIQkZI=.ed9ed673-e70e-4f45-9496-e16408796427@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

  Improve code snipet

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/3a4d9f66..183d3511

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

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

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

From rriggs at openjdk.org  Wed Apr  5 14:22:29 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 14:22:29 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
Message-ID: <GKbr8qOEym791fnbOadgQhjW8wVFdWzXFj7iLXFgxv0=.3b848e97-7d14-4f51-969c-f54d3fc31aac@github.com>

On Wed, 5 Apr 2023 08:37:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2882:
> 
>> 2880:                     elenNTFS = 36;           // total 36 bytes
>> 2881:                 } else {                     // Extended Timestamp otherwise
>> 2882:                     elenEXTT = 9;            // only mtime in cen
> 
> It might be better to drop ZipFileSystem from this patch and instead create a bug to re-examine this code. I would have expected it use NFTS when the timestamp is beyond the range of an extended timestamp. It shouldn't be looking at the current OS name.

Created [JDK-8305662](https://bugs.openjdk.org/browse/JDK-8305662) to track refactoring.
Will revert.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158587949

From rriggs at openjdk.org  Wed Apr  5 14:32:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 14:32:03 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v2]
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <di3Ff8SfMiCj2gtD3VVcz3f1QHTEShmlProg9qzQza4=.0b3d8874-c6dc-4809-951a-429120f064fc@github.com>

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

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

  Revert chanes to ZipFileSystem to defer refactoring.
  Reformatted expression to match switch expression formatting.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13335/files
  - new: https://git.openjdk.org/jdk/pull/13335/files/72cff1ed..aadf5bbd

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

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

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

From alanb at openjdk.org  Wed Apr  5 14:36:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Apr 2023 14:36:16 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v2]
In-Reply-To: <GKbr8qOEym791fnbOadgQhjW8wVFdWzXFj7iLXFgxv0=.3b848e97-7d14-4f51-969c-f54d3fc31aac@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
 <GKbr8qOEym791fnbOadgQhjW8wVFdWzXFj7iLXFgxv0=.3b848e97-7d14-4f51-969c-f54d3fc31aac@github.com>
Message-ID: <hoTsG4Le90HdJbdN-yAOFAYCjwwLn4avbyJBS6VViR8=.7e769d74-a829-4621-8229-8722dc7c50df@github.com>

On Wed, 5 Apr 2023 14:18:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Created [JDK-8305662](https://bugs.openjdk.org/browse/JDK-8305662) to track refactoring.
> Will revert.

Thanks, you can revert the qualified export in module-info and the additional grant in default.policy too.

The interesting thing about this PR is that each change begs the question on whether the code should be refactored, that would take time of course.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158609098

From duke at openjdk.org  Wed Apr  5 14:45:15 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 5 Apr 2023 14:45:15 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v2]
In-Reply-To: <di3Ff8SfMiCj2gtD3VVcz3f1QHTEShmlProg9qzQza4=.0b3d8874-c6dc-4809-951a-429120f064fc@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <di3Ff8SfMiCj2gtD3VVcz3f1QHTEShmlProg9qzQza4=.0b3d8874-c6dc-4809-951a-429120f064fc@github.com>
Message-ID: <Osp9DN7X8Ep5PtaZ0V8E7kf3vDZRpxHnrsKmj4NAjPg=.e2fadf20-cd2e-4596-a78d-73e75af04eab@github.com>

On Wed, 5 Apr 2023 14:32:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert chanes to ZipFileSystem to defer refactoring.
>   Reformatted expression to match switch expression formatting.

src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java line 103:

> 101:                                         "/usr/lib/sasl2/libgssapiv2.2.so",
> 102:                                 };
> 103:                                 case WINDOWS -> new String[]{ // Full path needed, DLL is in jre/bin

Suggestion:

                                case WINDOWS -> new String[]{
                                        // Full path needed, DLL is in jre/bin

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158620967

From pminborg at openjdk.org  Wed Apr  5 14:48:29 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 5 Apr 2023 14:48:29 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v19]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <V3G4ulbWUhYRz7zcF1Z71FRpmrgWc-M0Tk-BtT6RP7I=.d1adf747-525f-4415-9a7c-93494463c2b0@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:

 - Merge master
 - Improve code snipet
 - Update JEP number and name
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Cleanup finality
 - Merge pull request #1 from JornVernee/Fix_ULE
   
   Fix ULE when intializing LibFallback
 - fix ULE when intializing LibFallback
 - Remove unused method and declare class final
 - Fix copyrigth year issues
 - ... and 23 more: https://git.openjdk.org/jdk/compare/2e59d21e...0ee65ac1

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

Changes: https://git.openjdk.org/jdk/pull/13079/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=18
  Stats: 13133 lines in 268 files changed: 5016 ins; 6013 del; 2104 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

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

From duke at openjdk.org  Wed Apr  5 14:56:14 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 5 Apr 2023 14:56:14 GMT
Subject: RFR: JDK-8272119: Typo in JDK documentation (a -> an)
Message-ID: <40YBi9KTn2VI8x7eNQ5mCY5ftJoy8tD1a_irk8CGOvk=.f0e57a2f-a3e7-41a8-bb38-5a0b3bc18266@github.com>

a -> an

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

Commit messages:
 - Fixing a small typo in Collectors.summingInt

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

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

From dfuchs at openjdk.org  Wed Apr  5 15:07:05 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Apr 2023 15:07:05 GMT
Subject: RFR: JDK-8272119: Typo in JDK documentation (a -> an)
In-Reply-To: <40YBi9KTn2VI8x7eNQ5mCY5ftJoy8tD1a_irk8CGOvk=.f0e57a2f-a3e7-41a8-bb38-5a0b3bc18266@github.com>
References: <40YBi9KTn2VI8x7eNQ5mCY5ftJoy8tD1a_irk8CGOvk=.f0e57a2f-a3e7-41a8-bb38-5a0b3bc18266@github.com>
Message-ID: <oUYY-U2Y__K1f3kJFmiwxMbxvtuOi6zy1AfC5JasD1Y=.e6704899-7c75-4efe-b28c-254595bf69ce@github.com>

On Wed, 5 Apr 2023 14:48:52 GMT, Viktor Klang <duke at openjdk.org> wrote:

> a -> an

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13353#pullrequestreview-1373128734

From rriggs at openjdk.org  Wed Apr  5 15:48:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 15:48:02 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v3]
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

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

  Backout unneeded changes to module-info and default.policy.
  Fixup formatting.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13335/files
  - new: https://git.openjdk.org/jdk/pull/13335/files/aadf5bbd..5546b824

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

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

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

From rriggs at openjdk.org  Wed Apr  5 16:06:25 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 16:06:25 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
Message-ID: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>

Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
The enumeration values are defined to match those used in the build.
The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
Note that `amd64` and `x86_64` in the build are represented by `X64`.
The values of the system property `os.arch` is unchanged.

The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

Commit messages:
 - 8304915: Create jdk.internal.util.Architecture enum and apply

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

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

From naoto at openjdk.org  Wed Apr  5 16:07:49 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 5 Apr 2023 16:07:49 GMT
Subject: Integrated: 8305107: Emoji related binary properties in RegEx
In-Reply-To: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
Message-ID: <QpPuWK1bPRiJjP1X4hE3j32MZm-kaHcUvW9--CdwY14=.e3b1268c-b3c9-44a0-a504-a5dbfc30be56@github.com>

On Mon, 3 Apr 2023 22:58:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.

This pull request has now been integrated.

Changeset: ee302335
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee3023359caed3be4fe4cd829f04ede99d17ae86
Stats:     55 lines in 3 files changed: 49 ins; 3 del; 3 mod

8305107: Emoji related binary properties in RegEx

Reviewed-by: iris, rriggs, jpai

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

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

From naoto at openjdk.org  Wed Apr  5 16:09:39 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 5 Apr 2023 16:09:39 GMT
Subject: Integrated: 8304982: Emit warning for removal of `COMPAT` provider
In-Reply-To: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
Message-ID: <oxEnaA7Trmwprk_xcnZ-x6rUt5U2hGwqkC7i_ngIK_s=.2290197f-d762-4f55-ad91-a9cce7861ad1@github.com>

On Mon, 3 Apr 2023 16:47:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a precursor to the future removal of the `COMPAT` locale data provider. Before the actual removal of the provider, warn the users who explicitly specify `COMPAT` at the command line in order for their smooth migration to CLDR. A CSR has also been drafted.

This pull request has now been integrated.

Changeset: 44f33ad1
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/44f33ad1a9617fc23864c9ba5f063b3fc2f1e18c
Stats:     92 lines in 4 files changed: 83 ins; 1 del; 8 mod

8304982: Emit warning for removal of `COMPAT` provider

Reviewed-by: alanb

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

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

From duke at openjdk.org  Wed Apr  5 16:26:15 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 5 Apr 2023 16:26:15 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <t3MnPRyEwHwsVMPhYfAjaSQ4LYfELEj_zXHGu5KurWM=.fd0179d1-e84b-4af1-82b2-bcf89ed1355f@github.com>

On Wed, 5 Apr 2023 15:58:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

src/java.base/share/classes/jdk/internal/util/Architecture.java line 77:

> 75:      * {@return {@code true} if the current architecture is IA64}
> 76:      */
> 77:     public static boolean isIA64() {

Why is the name case correct only for IA-64, while `AArch64`, `RISC-V 64` and other architectures only have the first letter capitalized?

I think names like `isRiscv64`, `isPpc64le`, and `isAarch64` are quite ugly, and there is no precedent yet.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158748071

From iris at openjdk.org  Wed Apr  5 16:27:21 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 5 Apr 2023 16:27:21 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v3]
In-Reply-To: <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
Message-ID: <yNqK4eZqzxXtzGKEYf4MbbAaVHOB0Y785UAn1LuTvcs=.525903c3-871b-48b0-ab80-36917b999098@github.com>

On Wed, 5 Apr 2023 15:48:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backout unneeded changes to module-info and default.policy.
>   Fixup formatting.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1373282111

From mchung at openjdk.org  Wed Apr  5 16:28:06 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 5 Apr 2023 16:28:06 GMT
Subject: RFR: JDK-8272119: Typo in JDK documentation (a -> an)
In-Reply-To: <40YBi9KTn2VI8x7eNQ5mCY5ftJoy8tD1a_irk8CGOvk=.f0e57a2f-a3e7-41a8-bb38-5a0b3bc18266@github.com>
References: <40YBi9KTn2VI8x7eNQ5mCY5ftJoy8tD1a_irk8CGOvk=.f0e57a2f-a3e7-41a8-bb38-5a0b3bc18266@github.com>
Message-ID: <7dwQsULUpRFJePG6pZb2poNvD7F9ku5SIyFTI6vJh7E=.d09c9343-f595-42f6-9f67-2d1ae2e28368@github.com>

On Wed, 5 Apr 2023 14:48:52 GMT, Viktor Klang <duke at openjdk.org> wrote:

> a -> an

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13353#pullrequestreview-1373282807

From jvernee at openjdk.org  Wed Apr  5 16:33:24 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 5 Apr 2023 16:33:24 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v4]
In-Reply-To: <6hZzlgJtzWUJJupq0J2gRfeEvxD-wXkpsa2XcYvA0qM=.145bc6af-99b5-421a-940c-5198291764c8@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <6hZzlgJtzWUJJupq0J2gRfeEvxD-wXkpsa2XcYvA0qM=.145bc6af-99b5-421a-940c-5198291764c8@github.com>
Message-ID: <Y3D7vbAYx3qZJXYND4qNh4wDVRg84BUDOd_uZrQB_0A=.a7da1a97-b216-408f-ad6a-4da56fb2f77c@github.com>

On Wed, 5 Apr 2023 04:50:04 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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Use a dumper for interface instances, other cleanup
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - Remove unused JavaLangReflectReflectAccess.invokeDefault
>  - rethrow error
>  - Benchmark compareing to lamda metafactory, various minor updates
>  - Cache the spinned class, loading is still slow
>  - Wrapper instance type is already available
>  - mark records as private
>  - Merge branch 'master' into explore/mhp-iface
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/389698f9...0eec507d

I think the approach taken by this patch is good.

I agree with your analysis about access checking. The access checks are preformed when creating the target method handle, and if the target is a `@CallerSensitive` method, the caller will be the lookup class. So, it seems like it's not possible to e.g. turn a MethodHandle pointing at MethodHandles::lookup into an interface instance to get access to a Lookup created in the target interface's module.

I also think the approach of creating a new class per method handle is good. This is currently the only way to guarantee peak performance as far as I'm aware. If only a single class is desired, this can be achieved by using a lambda expression that captures the target method handle. Though, that also requires knowing the target type statically.

I think this change needs a CSR as well to document the change in behavior. If an application currently calls asInterfaceInstance many times for the same interface, the amount of classes generated will increase (potentially a lot).

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

> 185:             throw newIllegalArgumentException("a sealed interface", intfc.getName());
> 186:         if (intfc.isHidden())
> 187:             throw newIllegalArgumentException("a hidden interface", intfc.getName());

This extra check should be reflected in the javadoc as well. (there's already a note about the interface needing to be public and not sealed).

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

> 198: 
> 199:         // Interface-specific setup
> 200:         var info = INTERFACE_INFOS.get(intfc); // throws IllegalArgumentException

I find the use of `var` confusing here, since the type doesn't appear locally and is not well known either.
Suggestion:

        InterfaceInfo info = INTERFACE_INFOS.get(intfc); // throws IllegalArgumentException

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

> 211:                     .defineClassAsLookup(true, List.of(mhs));
> 212:             proxy = lookup.findConstructor(lookup.lookupClass(), methodType(void.class))
> 213:                     .asType(methodType(Object.class)).invokeExact();

This can use `invoke` instead of an explicit `asType` and `invokeExact`. It is more or less the same.
Suggestion:

            proxy = lookup.findConstructor(lookup.lookupClass(), methodType(void.class)).invoke();

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

> 223:     private record LocalMethodInfo(MethodTypeDesc desc, List<ClassDesc> thrown) {}
> 224: 
> 225:     private record InterfaceInfo(@Stable MethodType[] types, Lookup lookup, @Stable byte[] template) {}

Use of `@Stable` here is not needed. We don't constant fold through `InterfaceInfo` instances.
Suggestion:

    private record InterfaceInfo(MethodType[] types, Lookup lookup, byte[] template) {}

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

> 254:             }
> 255: 
> 256:             var template = createTemplate(desc(intfc), methods.get(0).getName(), infos);

I think using an explicit type would be preferable here as well
Suggestion:

            byte[] template = createTemplate(desc(intfc), methods.get(0).getName(), infos);

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

> 291: 
> 292:     // Spin an implementation class for an interface. A new class should be defined for each handle.
> 293:     // constructor parameter: Array[target, mh1, mh2, ...]

This comment seems outdated. The constructor doesn't have parameters atm

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

> 292:     // Spin an implementation class for an interface. A new class should be defined for each handle.
> 293:     // constructor parameter: Array[target, mh1, mh2, ...]
> 294:     private static byte[] createTemplate(ClassDesc ifaceDesc, String name, List<LocalMethodInfo> methods) {

'name' is quite ambiguous here, I suggest `name` -> `methodName`

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

> 307: 
> 308:             // actual implementations
> 309:             int i = 1;

Can you give `i` a more descriptive name here? Also, can you add a comment that says why it starts at `1` (e.g. `// +1 skip original target mh`).

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

> 319:                                         bcb.loadInstruction(kind, slot);
> 320:                                         slot += kind.slotSize();
> 321:                                     }

You could also use `CodeBuilder::parameterSlot` instead of computing the slot manually.

test/jdk/java/lang/invoke/MethodHandleProxies/BasicTest.java line 123:

> 121:         assertEquals(Objects.toIdentityString(p1), p1.toString());
> 122:         assertEquals(Objects.toIdentityString(p2), p2.toString());
> 123:     }

tbh I don't really see the point of this test since we don't override hashCode/equals/toString?

test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesAsIFInstance.java line 82:

> 80: 
> 81:     @Benchmark
> 82:     public Doable lambdaCreate() throws Throwable {

I know this is pre-existing, but I don't think having both call and create benchmarks in the same class is that useful. Since the time that is taken by each is very different.

I suggest splitting these benchmarks into 2 files instead: one for the call benchmarks, and the other for create, and create + call benchmarks (and then change the output time units for the latter).

I think the call benchmark could be fleshed out a bit more as well. It would be interesting to see these cases:
1. direct call to `doWork` (this would be the baseline)
2. call through non-constant method handle
3. call through non-constant interface instance created with lambda (existing `lambdaCall`)
4. call through non-constant interface instance created with MHP::asInterfaceInstance (existing `testCall`)
5. call through constant (`static final`) method handle
6. call through constant (`static final`) interface instance created with lambda
7. call through constant (`static final`) interface instance created with MHP::asInterfaceInstance

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

PR Review: https://git.openjdk.org/jdk/pull/13197#pullrequestreview-1372885252
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1158688369
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1158515268
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1158513973
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1158516812
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1158529119
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1158551214
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1158548324
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1158557239
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1158555913
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1158585395
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1158668111

From iris at openjdk.org  Wed Apr  5 16:34:06 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 5 Apr 2023 16:34:06 GMT
Subject: RFR: JDK-8272119: Typo in JDK documentation (a -> an)
In-Reply-To: <40YBi9KTn2VI8x7eNQ5mCY5ftJoy8tD1a_irk8CGOvk=.f0e57a2f-a3e7-41a8-bb38-5a0b3bc18266@github.com>
References: <40YBi9KTn2VI8x7eNQ5mCY5ftJoy8tD1a_irk8CGOvk=.f0e57a2f-a3e7-41a8-bb38-5a0b3bc18266@github.com>
Message-ID: <9S8BcGD7F_ROh4JMqz5vsYG2IYTU4KXPvzmN-dX1AAw=.69182632-5462-42d7-a6c6-e8b4c83fdeeb@github.com>

On Wed, 5 Apr 2023 14:48:52 GMT, Viktor Klang <duke at openjdk.org> wrote:

> a -> an

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13353#pullrequestreview-1373292633

From erikj at openjdk.org  Wed Apr  5 16:40:06 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 5 Apr 2023 16:40:06 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <ayNmGsyResKyCueqD6aTS5L0uh70jHoyOkiB5GLRmcM=.fcc4dc7e-cc0f-4056-a16e-c08d47603bcb@github.com>

On Wed, 5 Apr 2023 15:58:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

Looks good from a build point of view.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1373301135

From rriggs at openjdk.org  Wed Apr  5 17:18:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 17:18:15 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
In-Reply-To: <t3MnPRyEwHwsVMPhYfAjaSQ4LYfELEj_zXHGu5KurWM=.fd0179d1-e84b-4af1-82b2-bcf89ed1355f@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <t3MnPRyEwHwsVMPhYfAjaSQ4LYfELEj_zXHGu5KurWM=.fd0179d1-e84b-4af1-82b2-bcf89ed1355f@github.com>
Message-ID: <9Nk_HYxa54gfYKJSJbxMZ-HRVyzjeGK7U9kf98E9DIE=.73c87a07-e254-44b8-882d-8c46fab92d15@github.com>

On Wed, 5 Apr 2023 16:23:08 GMT, Glavo <duke at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 77:
> 
>> 75:      * {@return {@code true} if the current architecture is IA64}
>> 76:      */
>> 77:     public static boolean isIA64() {
> 
> Why is the name case correct only for IA-64, while `AArch64`, `RISC-V 64` and other architectures only have the first letter capitalized?
> 
> I think names like `isRiscv64`, `isPpc64le`, and `isAarch64` are quite ugly, and there is no precedent yet.

Yes, the capitalization names should be disciplined. In the enum, there are all uppercase, following the style of manifest constants and enums. In the build they are always lower case. Camel case is usually used for method names.
Using all upper case would make them consistent with the Enum names.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158801096

From duke at openjdk.org  Wed Apr  5 17:41:04 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 5 Apr 2023 17:41:04 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
In-Reply-To: <9Nk_HYxa54gfYKJSJbxMZ-HRVyzjeGK7U9kf98E9DIE=.73c87a07-e254-44b8-882d-8c46fab92d15@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <t3MnPRyEwHwsVMPhYfAjaSQ4LYfELEj_zXHGu5KurWM=.fd0179d1-e84b-4af1-82b2-bcf89ed1355f@github.com>
 <9Nk_HYxa54gfYKJSJbxMZ-HRVyzjeGK7U9kf98E9DIE=.73c87a07-e254-44b8-882d-8c46fab92d15@github.com>
Message-ID: <cOIMF34EcOAPchse1nXXFwDxxu9RGREACA050iTI-PE=.e1126679-6315-4837-9880-ee576bf7c29c@github.com>

On Wed, 5 Apr 2023 17:15:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Yes, the capitalization names should be disciplined. In the enum, there are all uppercase, following the style of manifest constants and enums. In the build they are always lower case. Camel case is usually used for method names. Using all upper case would make them consistent with the Enum names.

What I mean is, should we rename these methods? Because they are really ugly.

https://github.com/openjdk/jdk/blob/0c61382dc50fdc66d3e2b9a9975ac31d91890a5e/src/java.base/share/classes/jdk/internal/util/Architecture.java#L91

https://github.com/openjdk/jdk/blob/0c61382dc50fdc66d3e2b9a9975ac31d91890a5e/src/java.base/share/classes/jdk/internal/util/Architecture.java#L105

https://github.com/openjdk/jdk/blob/0c61382dc50fdc66d3e2b9a9975ac31d91890a5e/src/java.base/share/classes/jdk/internal/util/Architecture.java#L112

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158823225

From jkuhn at openjdk.org  Wed Apr  5 18:05:17 2023
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Wed, 5 Apr 2023 18:05:17 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: <tj562sC1hOPdzmo76ZkzZLJ__offyU-bl_aif14sb-U=.d5718dc9-c8dc-4776-a536-73f7d402fc9d@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <Mx7AH0tqNK0e10MkIi9BZm7hVuL5qXvhdtY8i0BiPE4=.f3329822-11a8-498d-9fac-fc1df82090f0@github.com>
 <6N1wKps-M239ceVuAojyvUIc-HjAEhcMLhxB6-jlkwI=.fc4f560f-9e98-4688-98a2-187e4f3f8758@github.com>
 <tj562sC1hOPdzmo76ZkzZLJ__offyU-bl_aif14sb-U=.d5718dc9-c8dc-4776-a536-73f7d402fc9d@github.com>
Message-ID: <PGfnSI2IP7zQ1B6p0c5uSaTvt7Tlk6PTFPAzA77HeVY=.af8c60d6-3110-48cc-bb46-285d00f6c790@github.com>

On Tue, 28 Mar 2023 14:34:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> The interface access may be problematic: A non-exported interface Class object can be obtained via Reflection inspection on exported types, such as java packages and jdk.internal packages.
> 
>     * In that case, it might not be of best interest to create an interface, but I don't think the current asInterfaceInstance API rejects such creations either.

See the Javadoc: https://github.com/openjdk/jdk/pull/13197/files#diff-6de80127c851b1b0ba6b2ab0a739ffae803187028a721d4a28cd47fb17b1bbcdL64-L65

As this API was added in Java 7, `public` access was easy. W.R.T. modules, no changes have been made to this API.  
The (previously) underlying `java.lang.reflect.Proxy` does not even require that.

@liach  Can you please test calling `MethodHandleProxies.wrapperInstanceTarget(MethodHandleProxies.asInterfaceInstance(Runnable.class, MethodHandles.zero(void.class)))` **with an installed `SecurityManager`**?
Also with an interface in an untrusted protection domain, for example:


public interface Test {
    void run();
    public static void main(String[] args) {
        System.out.println(MethodHandleProxies.wrapperInstanceTarget(MethodHandleProxies.asInterfaceInstance(Test.class, MethodHandles.zero(void.class))));
    }
}

also with a `SecurityManager` (`-Djava.security.manager` as VM argument).

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

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

From liach at openjdk.org  Wed Apr  5 18:33:19 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Apr 2023 18:33:19 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v4]
In-Reply-To: <Y3D7vbAYx3qZJXYND4qNh4wDVRg84BUDOd_uZrQB_0A=.a7da1a97-b216-408f-ad6a-4da56fb2f77c@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <6hZzlgJtzWUJJupq0J2gRfeEvxD-wXkpsa2XcYvA0qM=.145bc6af-99b5-421a-940c-5198291764c8@github.com>
 <Y3D7vbAYx3qZJXYND4qNh4wDVRg84BUDOd_uZrQB_0A=.a7da1a97-b216-408f-ad6a-4da56fb2f77c@github.com>
Message-ID: <g8d5NM8Vuikb-Kqra77FzWykqzCXomboIioaUhHXe_E=.76700423-c03c-4259-a390-a2c67abdd52f@github.com>

On Wed, 5 Apr 2023 13:22:30 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
>> 
>>  - Use a dumper for interface instances, other cleanup
>>  - Merge branch 'master' into explore/mhp-iface
>>  - Merge branch 'master' into explore/mhp-iface
>>  - Remove unused JavaLangReflectReflectAccess.invokeDefault
>>  - rethrow error
>>  - Benchmark compareing to lamda metafactory, various minor updates
>>  - Cache the spinned class, loading is still slow
>>  - Wrapper instance type is already available
>>  - mark records as private
>>  - Merge branch 'master' into explore/mhp-iface
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/118045b8...0eec507d
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 213:
> 
>> 211:                     .defineClassAsLookup(true, List.of(mhs));
>> 212:             proxy = lookup.findConstructor(lookup.lookupClass(), methodType(void.class))
>> 213:                     .asType(methodType(Object.class)).invokeExact();
> 
> This can use `invoke` instead of an explicit `asType` and `invokeExact`. It is more or less the same.
> Suggestion:
> 
>             proxy = lookup.findConstructor(lookup.lookupClass(), methodType(void.class)).invoke();

Fyi the original code was an emulation of how LambdaMetafactory initializes no-arg lambda instances.

> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 225:
> 
>> 223:     private record LocalMethodInfo(MethodTypeDesc desc, List<ClassDesc> thrown) {}
>> 224: 
>> 225:     private record InterfaceInfo(@Stable MethodType[] types, Lookup lookup, @Stable byte[] template) {}
> 
> Use of `@Stable` here is not needed. We don't constant fold through `InterfaceInfo` instances.
> Suggestion:
> 
>     private record InterfaceInfo(MethodType[] types, Lookup lookup, byte[] template) {}

Hmm, I thought records are constant-folded. https://github.com/openjdk/jdk/blob/44f33ad1a9617fc23864c9ba5f063b3fc2f1e18c/src/hotspot/share/ci/ciField.cpp#L240 Per https://github.com/openjdk/jdk/pull/9143#discussion_r912239501, array cloning sees 10% less time per operation with the annotation.

I will try with and without these annotations and report the creation benchmark results to see if they are worth it.

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

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

From jvernee at openjdk.org  Wed Apr  5 18:43:15 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 5 Apr 2023 18:43:15 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v4]
In-Reply-To: <g8d5NM8Vuikb-Kqra77FzWykqzCXomboIioaUhHXe_E=.76700423-c03c-4259-a390-a2c67abdd52f@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <6hZzlgJtzWUJJupq0J2gRfeEvxD-wXkpsa2XcYvA0qM=.145bc6af-99b5-421a-940c-5198291764c8@github.com>
 <Y3D7vbAYx3qZJXYND4qNh4wDVRg84BUDOd_uZrQB_0A=.a7da1a97-b216-408f-ad6a-4da56fb2f77c@github.com>
 <g8d5NM8Vuikb-Kqra77FzWykqzCXomboIioaUhHXe_E=.76700423-c03c-4259-a390-a2c67abdd52f@github.com>
Message-ID: <j0Ej2wA9-M8Ke3vNhtAqtFSR9Hk2xVgjHxARy4jYUnc=.0bcacbac-3708-4f31-aa04-e754914808f5@github.com>

On Wed, 5 Apr 2023 18:28:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 225:
>> 
>>> 223:     private record LocalMethodInfo(MethodTypeDesc desc, List<ClassDesc> thrown) {}
>>> 224: 
>>> 225:     private record InterfaceInfo(@Stable MethodType[] types, Lookup lookup, @Stable byte[] template) {}
>> 
>> Use of `@Stable` here is not needed. We don't constant fold through `InterfaceInfo` instances.
>> Suggestion:
>> 
>>     private record InterfaceInfo(MethodType[] types, Lookup lookup, byte[] template) {}
>
> Hmm, I thought records are constant-folded. https://github.com/openjdk/jdk/blob/44f33ad1a9617fc23864c9ba5f063b3fc2f1e18c/src/hotspot/share/ci/ciField.cpp#L240 Per https://github.com/openjdk/jdk/pull/9143#discussion_r912239501, array cloning sees 10% less time per operation with the annotation.
> 
> I will try with and without these annotations and report the creation benchmark results to see if they are worth it.

The `InterfaceInfo` instance would have to be constant as well in order for loads of the fields & array elements to be constant folded (the same applies to records in general). However, the instances come from a call from `ClassValue::get` so they are not constant. (See also: https://bugs.openjdk.org/browse/JDK-8238260)

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

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

From liach at openjdk.org  Wed Apr  5 18:51:16 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Apr 2023 18:51:16 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: <PGfnSI2IP7zQ1B6p0c5uSaTvt7Tlk6PTFPAzA77HeVY=.af8c60d6-3110-48cc-bb46-285d00f6c790@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <Mx7AH0tqNK0e10MkIi9BZm7hVuL5qXvhdtY8i0BiPE4=.f3329822-11a8-498d-9fac-fc1df82090f0@github.com>
 <6N1wKps-M239ceVuAojyvUIc-HjAEhcMLhxB6-jlkwI=.fc4f560f-9e98-4688-98a2-187e4f3f8758@github.com>
 <tj562sC1hOPdzmo76ZkzZLJ__offyU-bl_aif14sb-U=.d5718dc9-c8dc-4776-a536-73f7d402fc9d@github.com>
 <PGfnSI2IP7zQ1B6p0c5uSaTvt7Tlk6PTFPAzA77HeVY=.af8c60d6-3110-48cc-bb46-285d00f6c790@github.com>
Message-ID: <UNBYDCYIpdSQq-k3iZugOtgX9ziLN-GU-JsBnlfJ81I=.4a841705-9faa-48c2-b475-608d356abc16@github.com>

On Wed, 5 Apr 2023 17:59:24 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

>>> I think it should be possible to spin the class bytes once, stick the result in a ClassValue cache, but then use the bytes to define multiple classes with different class data (MethodHandles).
>> 
>> Great point, I was dumbfounded there.
>> 
>>> Let suppose you have an interface like:
>>> 
>>> ```
>>> interface StringConsumer extends Consumer<String> {}
>>> ```
>>> 
>>> The implementation needs to override both accept(Object) and accept(String).
>> 
>> It already does, and there are multiple test cases covering that: [mine](https://github.com/openjdk/jdk/pull/13197/files#diff-9753e5dae7b27070a1fe0d6c12eb65db605ee479d0e93d214ce710a8bbfc4922R176) and another in [MethodHandlesGeneralTest](https://github.com/openjdk/jdk/blob/927e674c12aa7965c63059b8f650d8f60156cefc/test/jdk/java/lang/invoke/MethodHandlesGeneralTest.java#L1785)
>> 
>>> Also, it would be nice if you could include the benchmarks you used in the patch as well.
>> 
>> They are from the JDK itself: https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesSuppl.java https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesAsIFInstance.java
>> 
>> Due to make issues (it passed `/` for module exports as `` on my windows somehow), I ran the test by copying them to a separate Gradle project with Gradle JMH plugin.
>> 
>>> I've worked on something similar before: https://bugs.openjdk.org/browse/JDK-8257605 The idea then was to add a new API in MethodHandles but since then I've been thinking that enhancing the performance of MethodHandleProxies might be better. The only issue I saw with that is that the current API doesn't accept a MethodHandles.Lookup object which would be needed to define an interface instance if the interface is in a non-exported package. Your solution just creates the lookup directly. Typically we have to be careful with injecting classes into other packages/modules since it can lead to access escalation, but maybe in this case it is fine. I don't think there's a way that this could be used to escalate access, though it seems strange that anyone could now define a class in a non-exported package/some other module.
>> 
>> About access:
>> 1. The method handle itself is already access-checked upon creation. 
>> 2. The interface access may be problematic: A non-exported interface Class object can be obtained via Reflection inspection on exported types, such as java packages and jdk.internal packages. 
>>    - In that case, it might not be of best interest to create an interface, but I don't think the current asInterfaceInstance API rejects such creations either.
>> 3. The class definition under the interface and its classloader IMO is safe, as the class will not refer to any type the interface itself does not refer to; the annotation is not involved in class loading either.
>> 
>>> We've also recently discussed LambdaMetafactory https://github.com/openjdk/jdk/pull/12493 which will produce classes strongly tied to the class loader. If we can bring MethodHandleProxies up to the same performance level as the classes produced by LambdaMetaFactory, it could serve as an alternative and people could move away from using the LambdaMetafactory runtime API (which is not really meant to be used directly). WRT that, I think the fact that the implementation proposed by this patch defines classes that are not strongly tied to the defining loader is a good thing.
>> 
>> Sounds good; it's not hard to make a benchmark that compares asInterfaceInstance and metafactory side-by-side either. The non-strong feature was intended indeed when one class is defined for each class + methodhandle combination. I agree `asInterfaceInstance` would be extremely useful to users, like a plugin loader converting json-based static method references into SAM implementations, which definitely should not become defined as a part of the plugin loader; or an event bus firing events.
>
>> The interface access may be problematic: A non-exported interface Class object can be obtained via Reflection inspection on exported types, such as java packages and jdk.internal packages.
>> 
>>     * In that case, it might not be of best interest to create an interface, but I don't think the current asInterfaceInstance API rejects such creations either.
> 
> See the Javadoc: https://github.com/openjdk/jdk/pull/13197/files#diff-6de80127c851b1b0ba6b2ab0a739ffae803187028a721d4a28cd47fb17b1bbcdL64-L65
> 
> As this API was added in Java 7, `public` access was easy. W.R.T. modules, no changes have been made to this API.  
> The (previously) underlying `java.lang.reflect.Proxy` does not even require that.
> 
> @liach  Can you please test calling `MethodHandleProxies.wrapperInstanceTarget(MethodHandleProxies.asInterfaceInstance(Runnable.class, MethodHandles.zero(void.class)))` **with an installed `SecurityManager`**?
> Also with an interface in an untrusted protection domain, for example:
> 
> 
> public interface Test {
>     void run();
>     public static void main(String[] args) {
>         System.out.println(MethodHandleProxies.wrapperInstanceTarget(MethodHandleProxies.asInterfaceInstance(Test.class, MethodHandles.zero(void.class))));
>     }
> }
> 
> also with a `SecurityManager` (`-Djava.security.manager` as VM argument).

@DasBrain: Good point, I will do it through a jtreg test, someting like `@run junit/othervm/secure=java.lang.SecurityManager TestClassName` in the jtreg tag section

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

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

From rriggs at openjdk.org  Wed Apr  5 18:53:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 18:53:12 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v2]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <9lnZlVpDi3KGYMVOhH2747WWOXbQjR5wqge69MvhMVs=.6b59dacd-19d0-4c5b-9869-11e31db3219a@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Rename isXXX method to be uppercase architecture names matching the enum.
  Refactor the is64Bit method to be a static method for the current runtime.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/0c61382d..bef30f96

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

  Stats: 72 lines in 5 files changed: 35 ins; 13 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

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

From duke at openjdk.org  Wed Apr  5 18:55:19 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 5 Apr 2023 18:55:19 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v2]
In-Reply-To: <9lnZlVpDi3KGYMVOhH2747WWOXbQjR5wqge69MvhMVs=.6b59dacd-19d0-4c5b-9869-11e31db3219a@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <9lnZlVpDi3KGYMVOhH2747WWOXbQjR5wqge69MvhMVs=.6b59dacd-19d0-4c5b-9869-11e31db3219a@github.com>
Message-ID: <qN_H6ys21NPr-SV_uL2LNiA5RHizrE0sLvoq8or-Py4=.f33b71d1-f48b-413f-82cd-86a951d07d3f@github.com>

On Wed, 5 Apr 2023 18:53:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename isXXX method to be uppercase architecture names matching the enum.
>   Refactor the is64Bit method to be a static method for the current runtime.

src/java.base/share/classes/jdk/internal/util/Architecture.java line 85:

> 83:      */
> 84:     @ForceInline
> 85:     public static boolean isRISCV() {

I think it should be named `isRISCV64` because RISC-V also has a 32-bit variant, so the name `isRISCV` may cause confusion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158897476

From rriggs at openjdk.org  Wed Apr  5 19:05:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 19:05:03 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v3]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <bUOhtX5Ni80FR0ljiFP_l76p_1Jh82sBTRmlv3B1j1E=.0c2b8db4-76cf-405d-8ecc-a7e3e2a09c67@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Correct name of isRISCV64 method.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/bef30f96..3349b46d

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

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

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

From rriggs at openjdk.org  Wed Apr  5 19:20:08 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 19:20:08 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Correct spelling of isAARCH64 in WIndows AttachProviderImpl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/3349b46d..8916dcae

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

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

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

From duke at openjdk.org  Wed Apr  5 20:35:17 2023
From: duke at openjdk.org (Bernd)
Date: Wed, 5 Apr 2023 20:35:17 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
Message-ID: <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>

On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl

src/java.base/share/classes/jdk/internal/foreign/CABI.java line 48:

> 46:         // might be running in a 32-bit VM on a 64-bit platform.
> 47:         // addressSize will be correctly 32
> 48:         if (Architecture.isX64() && ADDRESS_SIZE == 64) {

Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime

src/java.base/share/classes/jdk/internal/util/Architecture.java line 77:

> 75:      */
> 76:     @ForceInline
> 77:     public static boolean isARM() {

It should define what?s the difference to aarch64 for example will aarch64 also be arm, but arm32 wont? (Or remove)

test/jdk/jdk/internal/util/ArchTest.java line 58:

> 56:     @Test
> 57:     public void nameVsCurrent() {
> 58:         String osArch = System.getProperty("os.arch").toLowerCase(Locale.ROOT);

Is it planned to determine os.arch with the same enum in the future (keeping the legacy names)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158982643
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158988981
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158993835

From rriggs at openjdk.org  Wed Apr  5 20:43:27 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 20:43:27 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
Message-ID: <nLwwrSP70xk9K8LB8A12aWZYjI6XVDCa51x7DR9OoVk=.baed90d9-9f56-479c-8af5-8d1c7749f889@github.com>

On Wed, 5 Apr 2023 20:25:43 GMT, Bernd <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/foreign/CABI.java line 48:
> 
>> 46:         // might be running in a 32-bit VM on a 64-bit platform.
>> 47:         // addressSize will be correctly 32
>> 48:         if (Architecture.isX64() && ADDRESS_SIZE == 64) {
> 
> Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime

There should be no difference; I was hesitant to drop the ADDRESS_SIZE check without knowing more about the foreign api dependencies.  ADDRESS_SIZE is computed (I think) from `UNSAFE.ADDRESS_SIZE * 8`.
But I can't think of how it can be different than the CPU_BITS that are defined when the JDK is built.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159001239

From rriggs at openjdk.org  Wed Apr  5 20:52:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 20:52:15 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
Message-ID: <Y-C9ir5RmytyeZPaxBlFdMIk7QkKdXsO2yLDNK-515o=.b60f5eae-2707-41a2-9e13-93c42500bcf6@github.com>

On Wed, 5 Apr 2023 20:31:43 GMT, Bernd <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> test/jdk/jdk/internal/util/ArchTest.java line 58:
> 
>> 56:     @Test
>> 57:     public void nameVsCurrent() {
>> 58:         String osArch = System.getProperty("os.arch").toLowerCase(Locale.ROOT);
> 
> Is it planned to determine os.arch with the same enum in the future (keeping the legacy names)?

That's a different set of twisty build and native source files, I'll create an issue to re-visit that.
It may not change too much, the native code needs to initialize `os.arch` very early.
[JDK-8305676](https://bugs.openjdk.org/browse/JDK-8305676)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159009755

From duke at openjdk.org  Wed Apr  5 21:21:07 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 5 Apr 2023 21:21:07 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <nLwwrSP70xk9K8LB8A12aWZYjI6XVDCa51x7DR9OoVk=.baed90d9-9f56-479c-8af5-8d1c7749f889@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
 <nLwwrSP70xk9K8LB8A12aWZYjI6XVDCa51x7DR9OoVk=.baed90d9-9f56-479c-8af5-8d1c7749f889@github.com>
Message-ID: <1HKkKI-yuCGm_7ojnOgq0VCK-uJyAnsnXp4KYsrXW0M=.fbe8d18f-e9a6-4032-b9d3-6de15297f8d1@github.com>

On Wed, 5 Apr 2023 20:40:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/CABI.java line 48:
>> 
>>> 46:         // might be running in a 32-bit VM on a 64-bit platform.
>>> 47:         // addressSize will be correctly 32
>>> 48:         if (Architecture.isX64() && ADDRESS_SIZE == 64) {
>> 
>> Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime
>
> There should be no difference; I was hesitant to drop the ADDRESS_SIZE check without knowing more about the foreign api dependencies.  ADDRESS_SIZE is computed (I think) from `UNSAFE.ADDRESS_SIZE * 8`.
> But I can't think of how it can be different than the CPU_BITS that are defined when the JDK is built.

> Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime

Theoretically, the two can be unrelated. Linux x32 ABI is a typical example of using 32-bit addresses on the x86-64 architecture.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159032441

From dcubed at openjdk.org  Wed Apr  5 21:29:20 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 5 Apr 2023 21:29:20 GMT
Subject: Integrated: 8305678: ProblemList serviceability/sa/ClhsdbInspect.java
 on windows-x64 in Xcomp
Message-ID: <K2KonNWkIE9AOO0JRVyvjlRyVqQ4qpPKqGU80uwCh90=.e378c1e2-9648-4225-87bd-5cda880ce088@github.com>

Trivial fixes to ProblemList a couple of tests:
[JDK-8305678](https://bugs.openjdk.org/browse/JDK-8305678) ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
[JDK-8305679](https://bugs.openjdk.org/browse/JDK-8305679) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC

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

Commit messages:
 - 8305679: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC
 - 8305678: ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp

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

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

From mikael at openjdk.org  Wed Apr  5 21:29:20 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 5 Apr 2023 21:29:20 GMT
Subject: Integrated: 8305678: ProblemList
 serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
In-Reply-To: <K2KonNWkIE9AOO0JRVyvjlRyVqQ4qpPKqGU80uwCh90=.e378c1e2-9648-4225-87bd-5cda880ce088@github.com>
References: <K2KonNWkIE9AOO0JRVyvjlRyVqQ4qpPKqGU80uwCh90=.e378c1e2-9648-4225-87bd-5cda880ce088@github.com>
Message-ID: <FztW3oqLyzZMMsKMPZfTpaC744xRqdvUgv6OqDADSC0=.e43203ba-5683-45c2-9948-12779d418c3c@github.com>

On Wed, 5 Apr 2023 21:12:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList a couple of tests:
> [JDK-8305678](https://bugs.openjdk.org/browse/JDK-8305678) ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
> [JDK-8305679](https://bugs.openjdk.org/browse/JDK-8305679) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC

Marked as reviewed by mikael (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13365#pullrequestreview-1373708430

From dcubed at openjdk.org  Wed Apr  5 21:29:21 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 5 Apr 2023 21:29:21 GMT
Subject: Integrated: 8305678: ProblemList
 serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
In-Reply-To: <FztW3oqLyzZMMsKMPZfTpaC744xRqdvUgv6OqDADSC0=.e43203ba-5683-45c2-9948-12779d418c3c@github.com>
References: <K2KonNWkIE9AOO0JRVyvjlRyVqQ4qpPKqGU80uwCh90=.e378c1e2-9648-4225-87bd-5cda880ce088@github.com>
 <FztW3oqLyzZMMsKMPZfTpaC744xRqdvUgv6OqDADSC0=.e43203ba-5683-45c2-9948-12779d418c3c@github.com>
Message-ID: <ilwkLHU3To0UHC-9zuH_FiJUXkN4ApaUYN92hqUHZt0=.a4c22c1f-7bcb-4c75-b613-c5371d05c5ec@github.com>

On Wed, 5 Apr 2023 21:18:28 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Trivial fixes to ProblemList a couple of tests:
>> [JDK-8305678](https://bugs.openjdk.org/browse/JDK-8305678) ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
>> [JDK-8305679](https://bugs.openjdk.org/browse/JDK-8305679) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC
>
> Marked as reviewed by mikael (Reviewer).

@vidmik - Thanks for the fast review!

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

PR Comment: https://git.openjdk.org/jdk/pull/13365#issuecomment-1498180191

From dcubed at openjdk.org  Wed Apr  5 21:29:22 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 5 Apr 2023 21:29:22 GMT
Subject: Integrated: 8305678: ProblemList serviceability/sa/ClhsdbInspect.java
 on windows-x64 in Xcomp
In-Reply-To: <K2KonNWkIE9AOO0JRVyvjlRyVqQ4qpPKqGU80uwCh90=.e378c1e2-9648-4225-87bd-5cda880ce088@github.com>
References: <K2KonNWkIE9AOO0JRVyvjlRyVqQ4qpPKqGU80uwCh90=.e378c1e2-9648-4225-87bd-5cda880ce088@github.com>
Message-ID: <fNP8w6E0DR5Buf_w72VxtxGMWnhYi7m1Fz0sRYoZjxc=.4bb8daee-1099-4de0-933b-a4f2c198e3da@github.com>

On Wed, 5 Apr 2023 21:12:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList a couple of tests:
> [JDK-8305678](https://bugs.openjdk.org/browse/JDK-8305678) ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
> [JDK-8305679](https://bugs.openjdk.org/browse/JDK-8305679) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC

This pull request has now been integrated.

Changeset: b5d204c3
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5d204c3a4274c2e4604390eba436d42b5f5e9c9
Stats:     3 lines in 2 files changed: 2 ins; 0 del; 1 mod

8305678: ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
8305679: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC

Reviewed-by: mikael

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

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

From duke at openjdk.org  Wed Apr  5 21:40:16 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 5 Apr 2023 21:40:16 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
Message-ID: <sT3Awtma89tTplYplOqA3gP6chUCMu12WMcjB2BPyuw=.515492b6-3cad-4006-a053-fcca6f1d5b31@github.com>

On Wed, 5 Apr 2023 20:28:17 GMT, Bernd <duke at openjdk.org> wrote:

> It should define what?s the difference to aarch64 for example will aarch64 also be arm, but arm32 wont? (Or remove)

I think x86 and ARM are a bit confusing in this regard, as they can refer to 32-bit architectures in a narrow sense and 32-bit or 64 bit architectures in a broad sense.

For clarity, we can use more specific names: `x86-32`/`i686` and `arm32`/`aarch32`. But these names don't seem to be that commonly used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159047360

From dholmes at openjdk.org  Wed Apr  5 21:48:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Apr 2023 21:48:03 GMT
Subject: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM
 [v9]
In-Reply-To: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
Message-ID: <_ddegqzpdA5RyFhDsIQEYDXcVZRi1F-4JUwoZ-g2tPc=.1bd8c0b3-f51f-4474-a256-be2ded3d76a3@github.com>

> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
> 
> boolean alive() {
>   return eetop != 0;
> } 
> 
> I also updated a comment in relation to `eetop`.
> 
> Testing: tiers 1-3
> 
> Thanks

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

  Update comment to clarify the constraint is for JNI attaching threads.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13287/files
  - new: https://git.openjdk.org/jdk/pull/13287/files/dbb9a91a..3148401a

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

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

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

From dholmes at openjdk.org  Wed Apr  5 21:58:27 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Apr 2023 21:58:27 GMT
Subject: Integrated: 8305425: Thread.isAlive0 doesn't need to call into the VM
In-Reply-To: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
References: <eqV6rzUpjOdFvodgImo6VuGK6C2bUot4ZEzd0EUkBeM=.f7439de6-9cfa-4084-b6f9-cc60b8b26788@github.com>
Message-ID: <VWwcfOt2yLzEnoB4aFx2DnrdfD2dzgcBTOusN0hW7Rs=.66cbf076-514f-4512-8c2c-aebd40c9eaee@github.com>

On Mon, 3 Apr 2023 07:17:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
> 
> boolean alive() {
>   return eetop != 0;
> } 
> 
> I also updated a comment in relation to `eetop`.
> 
> Testing: tiers 1-3
> 
> Thanks

This pull request has now been integrated.

Changeset: 35cb303a
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/35cb303a2c0c8b32de257c02e012a1928a6b4594
Stats:     142 lines in 7 files changed: 123 ins; 12 del; 7 mod

8305425: Thread.isAlive0 doesn't need to call into the VM

Co-authored-by: Aleksey Shipilev <shade at openjdk.org>
Reviewed-by: shade, coleenp, alanb

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

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

From jvernee at openjdk.org  Wed Apr  5 23:42:13 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 5 Apr 2023 23:42:13 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
Message-ID: <CcdC-dn_yOzKYNQ5L2jhMZwRe_x5q59mxo6RpTIDs-E=.e1c302d4-3c5e-4892-9a52-e2f7efe2d246@github.com>

On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl

test/jdk/java/foreign/TestUnsupportedLinker.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @ignore architecture can not be overridden by setting os.arch - delete test

FWIW, we introduce a property in CABI to override it directly in the JEP patch: https://github.com/openjdk/jdk/pull/13079/files#diff-1e9526318ae485495af012cbf0450693d77fd8241be62afe422a75304de5aed1R28

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159130445

From jvernee at openjdk.org  Wed Apr  5 23:50:05 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 5 Apr 2023 23:50:05 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <1HKkKI-yuCGm_7ojnOgq0VCK-uJyAnsnXp4KYsrXW0M=.fbe8d18f-e9a6-4032-b9d3-6de15297f8d1@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
 <nLwwrSP70xk9K8LB8A12aWZYjI6XVDCa51x7DR9OoVk=.baed90d9-9f56-479c-8af5-8d1c7749f889@github.com>
 <1HKkKI-yuCGm_7ojnOgq0VCK-uJyAnsnXp4KYsrXW0M=.fbe8d18f-e9a6-4032-b9d3-6de15297f8d1@github.com>
Message-ID: <No3cTS4RYljpCXCUS6hzxAnnvZpYgpco5JNBkU7Vpgw=.4dddf75c-5703-4955-b126-73ea99004a82@github.com>

On Wed, 5 Apr 2023 21:18:43 GMT, Glavo <duke at openjdk.org> wrote:

>> There should be no difference; I was hesitant to drop the ADDRESS_SIZE check without knowing more about the foreign api dependencies.  ADDRESS_SIZE is computed (I think) from `UNSAFE.ADDRESS_SIZE * 8`.
>> But I can't think of how it can be different than the CPU_BITS that are defined when the JDK is built.
>
>> Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime
> 
> Theoretically, the two can be unrelated. Linux x32 ABI is a typical example of using 32-bit addresses on the x86-64 architecture.

Right, it is still possible to run a 32-bit VM build on a 64-bit platform. `os.arch` is the runtime platform in this case, but the VM variant can still be 32 bits.

Since `Architecture.isX64` seems to be the target arch of the VM, I'm think that when running a 32-bit VM on a amd64 would result in `isX64` being `false`? (In that case, only the `isX64` check should be enough)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159142830

From duke at openjdk.org  Thu Apr  6 00:57:19 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Thu, 6 Apr 2023 00:57:19 GMT
Subject: RFR: JDK-8269843: typo in LinkedHashMap::removeEldestEntry spec
Message-ID: <X4I_XNugeQN-QoxhtSqiRPrRbVuTffrf-o4y6mj5RJ0=.46b495f3-c1bd-414e-8a3a-531c62321c75@github.com>

Fix a typo in the specification of `java.util.LinkedHashMap.removeEldestEntry(Map.Entry)`.

> This is the entry that will be removed **it** this method returns `true`.

will become:

> This is the entry that will be removed **if** this method returns `true`.

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

Commit messages:
 - Fix typo in LinkedHashMap.java

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

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

From xgong at openjdk.org  Thu Apr  6 01:51:17 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 6 Apr 2023 01:51:17 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v6]
In-Reply-To: <mvjXG43i2H0ULxXam6DzZR6SPrVjyth_x4Fu7CTjmE0=.04f5e64d-54bd-4556-bc46-212552526853@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <mvjXG43i2H0ULxXam6DzZR6SPrVjyth_x4Fu7CTjmE0=.04f5e64d-54bd-4556-bc46-212552526853@github.com>
Message-ID: <hzuMOVojyS3HN_2Zw6GAW2pabc9ad1hBDqUbuCdOs1U=.835c02fd-dfc5-44eb-af87-b1c6b45fe41b@github.com>

On Tue, 4 Apr 2023 13:46:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
>> 
>> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
>> 
>> Please take a look and have some reviews. Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   style

test/hotspot/jtreg/compiler/vectorapi/TestVectorSlice.java line 466:

> 464:     @IR(counts = {IRNode.VECTOR_SLICE, "17"})
> 465:     static void testB128(byte[][] dst, byte[] src1, byte[] src2) {
> 466:         var species = ByteVector.SPECIES_128;

Suggest to define the species as a "`private static final`" field of this test class. It may make the intrinsification fail if the species is not a constant to the compiler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1159206009

From xgong at openjdk.org  Thu Apr  6 01:56:16 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 6 Apr 2023 01:56:16 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v5]
In-Reply-To: <fvpYPqmvn60WF8F7uDReTq2ZGUS-a-1LhKEEgD_lIxs=.892de878-23e8-4009-9d63-6577929a43b4@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <fvpYPqmvn60WF8F7uDReTq2ZGUS-a-1LhKEEgD_lIxs=.892de878-23e8-4009-9d63-6577929a43b4@github.com>
Message-ID: <XUHCLaLrR2dkOK3UpyxRNZ5gdNdJ-QEBTZK6NC6IYmM=.595c3343-2bc1-444a-99de-265d3a9c41f0@github.com>

On Tue, 4 Apr 2023 13:24:18 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
>> 
>> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
>> 
>> Please take a look and have some reviews. Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add identity, fix flags

test/hotspot/jtreg/compiler/vectorapi/TestVectorSlice.java line 327:

> 325: 
> 326:     @Test
> 327:     @IR(counts = {IRNode.VECTOR_SLICE, "7"}, applyIfCPUFeature = {"sse2", "true"})

How about separating the special cases (i.e. origin is `0/VLENGTH`), and using the `FailOn` check instead on them? Tests are more accurate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1159208577

From martin at openjdk.org  Thu Apr  6 02:29:08 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 6 Apr 2023 02:29:08 GMT
Subject: RFR: JDK-8269843: typo in LinkedHashMap::removeEldestEntry spec
In-Reply-To: <X4I_XNugeQN-QoxhtSqiRPrRbVuTffrf-o4y6mj5RJ0=.46b495f3-c1bd-414e-8a3a-531c62321c75@github.com>
References: <X4I_XNugeQN-QoxhtSqiRPrRbVuTffrf-o4y6mj5RJ0=.46b495f3-c1bd-414e-8a3a-531c62321c75@github.com>
Message-ID: <iTZuby8yll1moFuqrgcK50ESPKLugTzVMkG_jvQDxzU=.58ac3a35-c6d4-4f80-8193-bb0d73f85155@github.com>

On Thu, 6 Apr 2023 00:49:33 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> Fix a typo in the specification of `java.util.LinkedHashMap.removeEldestEntry(Map.Entry)`.
> 
>> This is the entry that will be removed **it** this method returns `true`.
> 
> will become:
> 
>> This is the entry that will be removed **if** this method returns `true`.

Marked as reviewed by martin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13367#pullrequestreview-1373966866

From liach at openjdk.org  Thu Apr  6 02:31:24 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Apr 2023 02:31:24 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v5]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <dcOzsKh1JGknBfdDPsKW13P2XWE5lISxYemPxixtG9Y=.fc1c9bec-06e9-4566-b168-413e0d846f9a@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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
> 
> [^1]: single abstract method

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

  Address review comments
  
  Make sure it runs with SecurityManager
  Split the benchmarks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/0eec507d..1bbd503d

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

  Stats: 565 lines in 9 files changed: 345 ins; 179 del; 41 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  Thu Apr  6 03:27:18 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 6 Apr 2023 03:27:18 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
Message-ID: <LoWlJFwsXXbDwr7WfOPP49CDMOnE3aU7vD7VILWDQkE=.07eb72c5-7bcc-4d9a-9518-14ce48dd2d63@github.com>

On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl

Per?@Glavo?s [comment][GH?13357#r1159047360]:

[GH?13357#r1159047360]: https://github.com/openjdk/jdk/pull/13357#discussion_r1159047360

src/java.base/share/classes/jdk/internal/util/Architecture.java line 37:

> 35: public enum Architecture {
> 36:     X64(),        // Represents AMD64 and X86_64
> 37:     X86(),

Suggestion:

    X86_64(),        // Represents AMD64 and X86_64
    X86_32(),

src/java.base/share/classes/jdk/internal/util/Architecture.java line 39:

> 37:     X86(),
> 38:     IA64(),
> 39:     ARM(),

Suggestion:

    ARM32(),

src/java.base/share/classes/jdk/internal/util/Architecture.java line 53:

> 51:      */
> 52:     @ForceInline
> 53:     public static boolean isX64() {

Suggestion:

    public static boolean isX86_64() {

src/java.base/share/classes/jdk/internal/util/Architecture.java line 61:

> 59:      */
> 60:     @ForceInline
> 61:     public static boolean isX86() {

Suggestion:

    public static boolean isX86_32() {

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

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1373996601
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159242846
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159242963
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159245067
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159245163

From duke at openjdk.org  Thu Apr  6 03:27:21 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 6 Apr 2023 03:27:21 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <sT3Awtma89tTplYplOqA3gP6chUCMu12WMcjB2BPyuw=.515492b6-3cad-4006-a053-fcca6f1d5b31@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
 <sT3Awtma89tTplYplOqA3gP6chUCMu12WMcjB2BPyuw=.515492b6-3cad-4006-a053-fcca6f1d5b31@github.com>
Message-ID: <7EnGBAROZJ-eiWhNUPPVUL2oPQDWGF_7Dd7sPT_ihNs=.c3317c6f-0986-4ba8-8bb2-62cd2b2ba390@github.com>

On Wed, 5 Apr 2023 21:36:57 GMT, Glavo <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/Architecture.java line 77:
>> 
>>> 75:      */
>>> 76:     @ForceInline
>>> 77:     public static boolean isARM() {
>> 
>> It should define what?s the difference to aarch64 for example will aarch64 also be arm, but arm32 wont? (Or remove)
>
>> It should define what?s the difference to aarch64 for example will aarch64 also be arm, but arm32 wont? (Or remove)
> 
> I think x86 and ARM are a bit confusing in this regard, as they can refer to 32-bit architectures in a narrow sense and 32-bit or 64 bit architectures in a broad sense.
> 
> For clarity, we can use more specific names: `x86-32`/`i686` and `arm32`/`aarch32`. But these names don't seem to be that commonly used.

Suggestion:

    public static boolean isARM32() {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159243677

From liach at openjdk.org  Thu Apr  6 03:44:07 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Apr 2023 03:44:07 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v6]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
> 
> [^1]: single abstract method

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

  Whitespace, cleanup, rename benchmarks to be informative

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/1bbd503d..3e5e6143

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

  Stats: 126 lines in 4 files changed: 40 ins; 19 del; 67 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 qamai at openjdk.org  Thu Apr  6 03:46:15 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 6 Apr 2023 03:46:15 GMT
Subject: RFR: 8305461: [vectorapi] Add VectorMask::xor
In-Reply-To: <jwSNj78SkdTEkWtny9s7dV1VH1RA8qYV1ZD2tONFj0Q=.98bb0702-3d1b-4232-9f69-6f4bcd0d8e4d@github.com>
References: <3qsNbKA1cm_XZnUNTDApkZDGMBq6PXcXZBTvEdv9UC4=.5dc8fed0-684e-4cd1-a007-d5e0c3cd0a65@github.com>
 <jwSNj78SkdTEkWtny9s7dV1VH1RA8qYV1ZD2tONFj0Q=.98bb0702-3d1b-4232-9f69-6f4bcd0d8e4d@github.com>
Message-ID: <d0xuQnDOKYZBo7uu9P8XWouqJl0wujz0wiVX8qkMRlI=.3a9a8874-9929-4ec2-b0ad-7d303261fa0c@github.com>

On Tue, 4 Apr 2023 15:44:41 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Hi,
>> 
>> This patch adds `VectorMask.xor` to the public interface of `VectorMask`. This method has already been existed in each concrete mask classes.
>> 
>> Please kindly review.
>> Thanks a lot.
>
> Thank you for doing this. I am guessing it was always intended to be public but was not spotted in previous reviews.

@PaulSandoz Thanks for your timely review, do I need a second review for this patch?

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

PR Comment: https://git.openjdk.org/jdk/pull/13277#issuecomment-1498449149

From liach at openjdk.org  Thu Apr  6 04:53:16 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Apr 2023 04:53:16 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v4]
In-Reply-To: <Y3D7vbAYx3qZJXYND4qNh4wDVRg84BUDOd_uZrQB_0A=.a7da1a97-b216-408f-ad6a-4da56fb2f77c@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <6hZzlgJtzWUJJupq0J2gRfeEvxD-wXkpsa2XcYvA0qM=.145bc6af-99b5-421a-940c-5198291764c8@github.com>
 <Y3D7vbAYx3qZJXYND4qNh4wDVRg84BUDOd_uZrQB_0A=.a7da1a97-b216-408f-ad6a-4da56fb2f77c@github.com>
Message-ID: <GnkIBV0m-7RAi0FNmcxGIpSWfqjYrfXt0TPzzhAWQQU=.f0720687-22bb-4346-aa9e-01d0d97af3bc@github.com>

On Wed, 5 Apr 2023 16:30:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I think this change needs a CSR as well to document the change in behavior. If an application currently calls asInterfaceInstance many times for the same interface, the amount of classes generated will increase (potentially a lot).

Created CSR at https://bugs.openjdk.org/browse/JDK-8305691, for both the specification of rejection of hidden interfaces and the new behavior of creating many weak classes.

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

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

From duke at openjdk.org  Thu Apr  6 06:38:23 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Thu, 6 Apr 2023 06:38:23 GMT
Subject: Integrated: JDK-8269843: typo in LinkedHashMap::removeEldestEntry spec
In-Reply-To: <X4I_XNugeQN-QoxhtSqiRPrRbVuTffrf-o4y6mj5RJ0=.46b495f3-c1bd-414e-8a3a-531c62321c75@github.com>
References: <X4I_XNugeQN-QoxhtSqiRPrRbVuTffrf-o4y6mj5RJ0=.46b495f3-c1bd-414e-8a3a-531c62321c75@github.com>
Message-ID: <D7YXFDQtVstGjS880PD47li215g89_1MhfoGvyhUIxg=.4d5d7e3a-cc1b-4c1a-b80a-51bcd0e446cc@github.com>

On Thu, 6 Apr 2023 00:49:33 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> Fix a typo in the specification of `java.util.LinkedHashMap.removeEldestEntry(Map.Entry)`.
> 
>> This is the entry that will be removed **it** this method returns `true`.
> 
> will become:
> 
>> This is the entry that will be removed **if** this method returns `true`.

This pull request has now been integrated.

Changeset: b5ea140d
Author:    Tingjun Yuan <yuantj1999 at outlook.com>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5ea140dff0ba0b1ce22063e2b4af10a3b2086f3
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8269843: typo in LinkedHashMap::removeEldestEntry spec

Reviewed-by: martin

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

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

From alanb at openjdk.org  Thu Apr  6 07:35:20 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Apr 2023 07:35:20 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
Message-ID: <AvcNFdCM6eGAM-NA9yDxTZzE_h5xywb7qZV-ZhohHNc=.0ec40d45-ac53-460e-8df9-d2795add811f@github.com>

On Thu, 30 Mar 2023 14:21:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include a warning saying that 'The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18'

One additional thing we could do is update the usage output for -i/--generate-index to say that the option is deprecated. Looking at `jdeps -help` output to see this for the deprecated -P/--profile option.

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1498617201

From pminborg at openjdk.org  Thu Apr  6 07:39:17 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 6 Apr 2023 07:39:17 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
Message-ID: <DI1Ik8MSwOL9Iol8Z-7wwkTeVIihP6b4WIfXgKjQ5IQ=.1dc38421-ada7-4837-849d-05d617827316@github.com>

On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl

src/java.base/share/classes/jdk/internal/util/Architecture.java line 114:

> 112: 
> 113:     /**
> 114:      * {@return return the current architecture}

Suggestion :

{@return the current architecture}.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159396971

From pminborg at openjdk.org  Thu Apr  6 07:45:16 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 6 Apr 2023 07:45:16 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
Message-ID: <yFfP_oPn6GzKwA6avyNt3STIz49hjD1Gv5YSb2A-CgU=.52dd7fca-5f64-4665-8a06-e0272aa82c7d@github.com>

On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl

src/java.base/share/classes/jdk/internal/util/Architecture.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2023, Oracle and/or its affiliates. All rights reserved.

Why 2018?

src/java.base/share/classes/jdk/internal/util/Architecture.java line 85:

> 83:      */
> 84:     @ForceInline
> 85:     public static boolean isRISCV64() {

Are all the "isers" necessary to provide constant code folding or is the samt thing achievable via expressions like `(Architecture.current() == Architecture.X)` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159404227
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159402728

From duke at openjdk.org  Thu Apr  6 08:02:19 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 6 Apr 2023 08:02:19 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <DI1Ik8MSwOL9Iol8Z-7wwkTeVIihP6b4WIfXgKjQ5IQ=.1dc38421-ada7-4837-849d-05d617827316@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <DI1Ik8MSwOL9Iol8Z-7wwkTeVIihP6b4WIfXgKjQ5IQ=.1dc38421-ada7-4837-849d-05d617827316@github.com>
Message-ID: <X3waE5jxXJlMlgiSW1tQXtYyxNGeUz8pfYN6JFv9gco=.d846bec5-8362-41fa-999d-7ad28a486831@github.com>

On Thu, 6 Apr 2023 07:36:36 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 114:
> 
>> 112: 
>> 113:     /**
>> 114:      * {@return return the current architecture}
> 
> Suggestion :
> 
> {@return the current architecture}.

Suggestion:

     * {@return the current architecture}.


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

@minborg
You?need to?use:

Suggestion:

     * {@return the current architecture}.



For?**GitHub** to?recognise?it as?a?suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159422715

From duke at openjdk.org  Thu Apr  6 08:08:20 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 6 Apr 2023 08:08:20 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
Message-ID: <RLXITzKGMBGDGi0WLRNF4I4ztakWC96rvnmZHQxFzBY=.1381d600-b541-4daa-996e-3ca6f4e257f6@github.com>

On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl

src/java.base/share/classes/jdk/internal/util/Architecture.java line 26:

> 24: 
> 25: import jdk.internal.vm.annotation.ForceInline;
> 26: 

Suggestion:

import jdk.internal.vm.annotation.ForceInline;
import jdk.internal.vm.annotation.Stable;

src/java.base/share/classes/jdk/internal/util/Architecture.java line 47:

> 45: 
> 46:     // Cache a copy of the array for lightweight indexing
> 47:     private static final Architecture[] archValues = Architecture.values();

This?needs to?be?annotated with?`@jdk.internal.vm.annotation.Stable` for?`Architecture.current()` to?be?constant?foldable:
Suggestion:

    private static final @Stable Architecture[] archValues = Architecture.values();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159426832
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159424057

From duke at openjdk.org  Thu Apr  6 08:08:23 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 6 Apr 2023 08:08:23 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <yFfP_oPn6GzKwA6avyNt3STIz49hjD1Gv5YSb2A-CgU=.52dd7fca-5f64-4665-8a06-e0272aa82c7d@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <yFfP_oPn6GzKwA6avyNt3STIz49hjD1Gv5YSb2A-CgU=.52dd7fca-5f64-4665-8a06-e0272aa82c7d@github.com>
Message-ID: <la0VOIRB7qmN9Y0_mUCl9-8oloBAW9ZW4vZ0ddAHgqo=.d9490bcb-a45d-4cac-a09c-683ee1c80f75@github.com>

On Thu, 6 Apr 2023 07:40:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 85:
> 
>> 83:      */
>> 84:     @ForceInline
>> 85:     public static boolean isRISCV64() {
> 
> Are all the "isers" necessary to provide constant code folding or is the samt thing achievable via expressions like `(Architecture.current() == Architecture.X)` ?

`Architecture.current()`?requires the?`Architecture.archValues` array to?be?annotated with?`@jdk.internal.vm.annotation.Stable` for?it?to?be?constant?foldable by?the?JIT.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159428913

From duke at openjdk.org  Thu Apr  6 08:16:19 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 6 Apr 2023 08:16:19 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <No3cTS4RYljpCXCUS6hzxAnnvZpYgpco5JNBkU7Vpgw=.4dddf75c-5703-4955-b126-73ea99004a82@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
 <nLwwrSP70xk9K8LB8A12aWZYjI6XVDCa51x7DR9OoVk=.baed90d9-9f56-479c-8af5-8d1c7749f889@github.com>
 <1HKkKI-yuCGm_7ojnOgq0VCK-uJyAnsnXp4KYsrXW0M=.fbe8d18f-e9a6-4032-b9d3-6de15297f8d1@github.com>
 <No3cTS4RYljpCXCUS6hzxAnnvZpYgpco5JNBkU7Vpgw=.4dddf75c-5703-4955-b126-73ea99004a82@github.com>
Message-ID: <7w-PPxtMpjBDyYgYeIuNwR_Ntbd-6T2Ja_umzjWFRLA=.548725ca-0692-4e1f-82a7-5e6689317cae@github.com>

On Wed, 5 Apr 2023 23:46:33 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Right, it is still possible to run a 32-bit VM build on a 64-bit platform. `os.arch` can be `amd64`, the runtime platform, in this case, but the VM variant can still be 32 bits.

`os.arch` is always the target architecture for JVM, even using 32-bit JVM on 64-bit system, its value remains x86.

But as mentioned above, the size of the address can be independent of these. 

Linux x32 ABI is an ABI for the x86-64 architecture, which uses unique features of 64-bit architectures such as 64-bit registers, but it uses 32-bit addresses.

Although OpenJDK does not support such a platform, technically speaking, it is still necessary to distinguish between architecture bits and address bits.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159438411

From alanb at openjdk.org  Thu Apr  6 09:05:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Apr 2023 09:05:18 GMT
Subject: RFR: 8305538: Avoid redundant HashMap.containsKey call in
 ModuleDescriptor.Builder
In-Reply-To: <9ICTUFZWdPM4NAeYnZlrrhgdDNGr-DCumibjZU0eIu4=.b5bf01f3-dfd3-40b4-988b-1c3df18c2d03@github.com>
References: <cwKHk3sU2rRXKv4jNF2Biij7dPqlFQva3hBb8ZlVm-4=.18a6501d-db9d-44f4-9297-4e6dfa39c2e8@github.com>
 <E07Ny-COtulL3RUVAUMdCvsZdsu2z6Qde6o9nmM0Qas=.bc7b12d6-c35a-4422-9de2-a36fd688fa53@github.com>
 <oh7yFjQ5yHqs6a6nh5TfZoe7YAFEXnL9VDMaZQyfetQ=.27bc4ba7-0fcc-4033-8021-b91be71c8d06@github.com>
 <9ICTUFZWdPM4NAeYnZlrrhgdDNGr-DCumibjZU0eIu4=.b5bf01f3-dfd3-40b4-988b-1c3df18c2d03@github.com>
Message-ID: <Koq_jwjZuRF_xV1rEM97f_Gfir4fS0Q4UrU6aTPZx30=.4239a881-f6cf-4d5e-a437-ca4b9b320a1c@github.com>

On Tue, 4 Apr 2023 20:43:13 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> But now `requireServiceTypeName` is called unconditionally.

requireServiceTypeName(service) should only be called when using the API. The non-strict route is when parsing a module-info on the module path, the checks that the names are legal should not be done for that case.

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

PR Comment: https://git.openjdk.org/jdk/pull/13288#issuecomment-1498724800

From aturbanov at openjdk.org  Thu Apr  6 09:13:13 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 6 Apr 2023 09:13:13 GMT
Subject: RFR: 8305696: Avoid redundant LinkedHashMap.containsKey call
 ZipFileSystem.makeParentDirs
Message-ID: <L1C6gVVln23VejqKo9Qab54sNHc8tLuQoyVL3Y9uc9o=.9f0f0cdb-2e9c-42e6-801b-d1aa64dc8bc5@github.com>

`LinkedHashMap<IndexNode, IndexNode>` `ZipFileSystem.inodes` contains only non-null values. It means instead of separate `containsKey`+`get` calls, we can use single `LinkedHashMap.get` call and then compare result with `null`.
Result code is a bit simpler and faster.

Testing: Linux x64 `java/nio`, `jdk/nio`

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

Commit messages:
 - [PATCH] Avoid redundant LinkedHashMap.containsKey call ZipFileSystem.makeParentDirs

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

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

From jpai at openjdk.org  Thu Apr  6 09:26:20 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Apr 2023 09:26:20 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v9]
In-Reply-To: <Wk7S_ogheoFOpmayDF94vwiGGQezF4g9cenbxUttqNs=.71f72ab0-40c6-4874-b70e-764ec87cd1fb@github.com>
References: <b2lIhVL1sHhnFTXvNSRBxxCd_b8KKUZz7mKWK1Zr6eY=.3d4fd0c8-a2b4-4510-bb6d-c68ad9de92bf@github.com>
 <nFcbtXLuQHniBrOTa-1Iupa6-BuWo4f_ouLWCMKOv24=.01434cb5-1859-4c08-bdc0-307fab5e3d69@github.com>
 <Wk7S_ogheoFOpmayDF94vwiGGQezF4g9cenbxUttqNs=.71f72ab0-40c6-4874-b70e-764ec87cd1fb@github.com>
Message-ID: <rqgyQUcjDVDJBP5B9jH23dvO3dH_5mVdhSREVu8Ac_4=.4f2a73f4-1174-48ef-a5eb-b50a0a210a57@github.com>

On Wed, 5 Apr 2023 07:08:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> So I think the main thing now is to decide whether the benchmark should be included or not.

In my review I hadn't paid attention to the benchmark class. I now applied this patch locally and reviewed the benchmark code and even ran it locally, with and without changes.

Like Alan notes, the change that has been done in `BufferedInputStream` code, in this PR, now delays the allocation of the internal byte[]. Unlike previously where it used to be allocated when the `BufferedInputStream` was instantiated. For this change, I think a benchmark isn't necessary - what would it test, how quickly a `new BufferedInputStream` returns as compared to previous code? Or how slow a `read()` operation (which could potentially end up allocating the internal byte[]) would now run as compared to the previous code? To me, looking at the change it's clear that delaying the byte[] creation to the point where it's really needed does add value and I don't think a benchmark which checks the duration of a read() operation, would be able to capture this accurately.

So, I think it's OK if we drop the benchmark from this PR, if @stsypanov agrees. If however we do go ahead with including this benchmark, then I think the benchmark class file will need a change in its package declaration. It should be:


package org.openjdk.bench.java.io;

to match where it resides (just like other benchmark classes in this directory).

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

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1498753613

From stsypanov at openjdk.org  Thu Apr  6 09:59:25 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 6 Apr 2023 09:59:25 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v9]
In-Reply-To: <rqgyQUcjDVDJBP5B9jH23dvO3dH_5mVdhSREVu8Ac_4=.4f2a73f4-1174-48ef-a5eb-b50a0a210a57@github.com>
References: <b2lIhVL1sHhnFTXvNSRBxxCd_b8KKUZz7mKWK1Zr6eY=.3d4fd0c8-a2b4-4510-bb6d-c68ad9de92bf@github.com>
 <nFcbtXLuQHniBrOTa-1Iupa6-BuWo4f_ouLWCMKOv24=.01434cb5-1859-4c08-bdc0-307fab5e3d69@github.com>
 <Wk7S_ogheoFOpmayDF94vwiGGQezF4g9cenbxUttqNs=.71f72ab0-40c6-4874-b70e-764ec87cd1fb@github.com>
 <rqgyQUcjDVDJBP5B9jH23dvO3dH_5mVdhSREVu8Ac_4=.4f2a73f4-1174-48ef-a5eb-b50a0a210a57@github.com>
Message-ID: <9blhI8gEfRu0rjv9rtxgY55_0CYL-XXd636fqho2FNE=.b0c4a6aa-5ebf-43ee-8151-53574e894a1d@github.com>

On Thu, 6 Apr 2023 09:23:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>  For this change, I think a benchmark isn't necessary - what would it test, how quickly a new BufferedInputStream returns as compared to previous code?

@jaikiran first of all it demonstrates reducing allocation for plain/cascaded readAllBytes() operation. If the question was only about buffer allocation delay the change would be pointless to me.

> So, I think it's OK if we drop the benchmark from this PR, if @stsypanov agrees

I agree. There'd be hardly more changes into buffer allocation, so we needn't meaure it. And if this patch is for some reason reverted then we needn't it either.

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

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1498794845

From stsypanov at openjdk.org  Thu Apr  6 10:07:31 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 6 Apr 2023 10:07:31 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v10]
In-Reply-To: <b2lIhVL1sHhnFTXvNSRBxxCd_b8KKUZz7mKWK1Zr6eY=.3d4fd0c8-a2b4-4510-bb6d-c68ad9de92bf@github.com>
References: <b2lIhVL1sHhnFTXvNSRBxxCd_b8KKUZz7mKWK1Zr6eY=.3d4fd0c8-a2b4-4510-bb6d-c68ad9de92bf@github.com>
Message-ID: <v7kass_oAduy96QyULTQbtddJvWOcPOXWYdacm6qh-M=.4558aa31-037c-45a7-99d5-aa61f0e6e171@github.com>

> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.

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

  8304745: Drop benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13150/files
  - new: https://git.openjdk.org/jdk/pull/13150/files/439460bc..34ccd883

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

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

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

From jpai at openjdk.org  Thu Apr  6 10:08:06 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Apr 2023 10:08:06 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v10]
In-Reply-To: <v7kass_oAduy96QyULTQbtddJvWOcPOXWYdacm6qh-M=.4558aa31-037c-45a7-99d5-aa61f0e6e171@github.com>
References: <b2lIhVL1sHhnFTXvNSRBxxCd_b8KKUZz7mKWK1Zr6eY=.3d4fd0c8-a2b4-4510-bb6d-c68ad9de92bf@github.com>
 <v7kass_oAduy96QyULTQbtddJvWOcPOXWYdacm6qh-M=.4558aa31-037c-45a7-99d5-aa61f0e6e171@github.com>
Message-ID: <un0nZ6KSEgBu35ITn1Bsbhmvoxrv2mz0usx9FO02Ez8=.a2f3a493-4ac1-4a75-bb14-63b91161b359@github.com>

On Thu, 6 Apr 2023 10:07:31 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304745: Drop benchmark

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13150#pullrequestreview-1374513020

From jpai at openjdk.org  Thu Apr  6 10:08:08 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Apr 2023 10:08:08 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v9]
In-Reply-To: <9blhI8gEfRu0rjv9rtxgY55_0CYL-XXd636fqho2FNE=.b0c4a6aa-5ebf-43ee-8151-53574e894a1d@github.com>
References: <b2lIhVL1sHhnFTXvNSRBxxCd_b8KKUZz7mKWK1Zr6eY=.3d4fd0c8-a2b4-4510-bb6d-c68ad9de92bf@github.com>
 <nFcbtXLuQHniBrOTa-1Iupa6-BuWo4f_ouLWCMKOv24=.01434cb5-1859-4c08-bdc0-307fab5e3d69@github.com>
 <Wk7S_ogheoFOpmayDF94vwiGGQezF4g9cenbxUttqNs=.71f72ab0-40c6-4874-b70e-764ec87cd1fb@github.com>
 <rqgyQUcjDVDJBP5B9jH23dvO3dH_5mVdhSREVu8Ac_4=.4f2a73f4-1174-48ef-a5eb-b50a0a210a57@github.com>
 <9blhI8gEfRu0rjv9rtxgY55_0CYL-XXd636fqho2FNE=.b0c4a6aa-5ebf-43ee-8151-53574e894a1d@github.com>
Message-ID: <3UJPVcGKQispvNc3D5xNpOWP5-8g_aSKh4CTpaVl9TA=.309ca7c8-7921-443a-8c61-8c92f3063420@github.com>

On Thu, 6 Apr 2023 09:55:57 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>>> So I think the main thing now is to decide whether the benchmark should be included or not.
>> 
>> In my review I hadn't paid attention to the benchmark class. I now applied this patch locally and reviewed the benchmark code and even ran it locally, with and without changes.
>> 
>> Like Alan notes, the change that has been done in `BufferedInputStream` code, in this PR, now delays the allocation of the internal byte[]. Unlike previously where it used to be allocated when the `BufferedInputStream` was instantiated. For this change, I think a benchmark isn't necessary - what would it test, how quickly a `new BufferedInputStream` returns as compared to previous code? Or how slow a `read()` operation (which could potentially end up allocating the internal byte[]) would now run as compared to the previous code? To me, looking at the change it's clear that delaying the byte[] creation to the point where it's really needed does add value and I don't think a benchmark which checks the duration of a read() operation, would be able to capture this accurately.
>> 
>> So, I think it's OK if we drop the benchmark from this PR, if @stsypanov agrees. If however we do go ahead with including this benchmark, then I think the benchmark class file will need a change in its package declaration. It should be:
>> 
>> 
>> package org.openjdk.bench.java.io;
>> 
>> to match where it resides (just like other benchmark classes in this directory).
>
>>  For this change, I think a benchmark isn't necessary - what would it test, how quickly a new BufferedInputStream returns as compared to previous code?
> 
> @jaikiran first of all it demonstrates reducing allocation for plain/cascaded readAllBytes() operation. If the question was only about buffer allocation delay the change would be pointless to me.
> 
>> So, I think it's OK if we drop the benchmark from this PR, if @stsypanov agrees
> 
> I agree. There'd be hardly more changes into buffer allocation, so we needn't meaure it. And if this patch is for some reason reverted then we needn't it either.

Thank you for the update, @stsypanov. This looks good to me. I had run this against our internal CI yesterday and the test runs completed fine. I'll go ahead and sponsor this shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1498807545

From pminborg at openjdk.org  Thu Apr  6 10:54:18 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 6 Apr 2023 10:54:18 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v20]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <zxEBDsj3-07V4u3Exryupcrs_9mcT14cJ96TOIxWXc8=.07d9f518-7e1f-4ad7-89e0-84b0bf52ed2e@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

 - 8305369: Issues in zero-length memory segment javadoc section
 - 8305087: MemoryLayout API checks should be more eager

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/0ee65ac1..c1999447

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

  Stats: 340 lines in 21 files changed: 98 ins; 184 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

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

From stsypanov at openjdk.org  Thu Apr  6 11:20:31 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 6 Apr 2023 11:20:31 GMT
Subject: Integrated: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream
In-Reply-To: <b2lIhVL1sHhnFTXvNSRBxxCd_b8KKUZz7mKWK1Zr6eY=.3d4fd0c8-a2b4-4510-bb6d-c68ad9de92bf@github.com>
References: <b2lIhVL1sHhnFTXvNSRBxxCd_b8KKUZz7mKWK1Zr6eY=.3d4fd0c8-a2b4-4510-bb6d-c68ad9de92bf@github.com>
Message-ID: <PMaFW2dJ-bxbsiuMQt0CunVuN91ob2UCtGhe1UAb6bc=.d71b44a0-b05e-4a0c-80de-9643f8af5254@github.com>

On Wed, 22 Mar 2023 20:34:08 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.

This pull request has now been integrated.

Changeset: e52a2aee
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e52a2aeeacaeb26c801b6e31f8e67e61b1ea2de3
Stats:     47 lines in 1 file changed: 36 ins; 2 del; 9 mod

8304745: Lazily initialize byte[] in java.io.BufferedInputStream

Reviewed-by: liach, bpb, jpai

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

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

From jvernee at openjdk.org  Thu Apr  6 12:32:16 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Apr 2023 12:32:16 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <7w-PPxtMpjBDyYgYeIuNwR_Ntbd-6T2Ja_umzjWFRLA=.548725ca-0692-4e1f-82a7-5e6689317cae@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
 <nLwwrSP70xk9K8LB8A12aWZYjI6XVDCa51x7DR9OoVk=.baed90d9-9f56-479c-8af5-8d1c7749f889@github.com>
 <1HKkKI-yuCGm_7ojnOgq0VCK-uJyAnsnXp4KYsrXW0M=.fbe8d18f-e9a6-4032-b9d3-6de15297f8d1@github.com>
 <No3cTS4RYljpCXCUS6hzxAnnvZpYgpco5JNBkU7Vpgw=.4dddf75c-5703-4955-b126-73ea99004a82@github.com>
 <7w-PPxtMpjBDyYgYeIuNwR_Ntbd-6T2Ja_umzjWFRLA=.548725ca-0692-4e1f-82a7-5e6689317cae@github.com>
Message-ID: <RIoft18UIqYlHjwybyOYApGv8h94sp2V0_yJRBNp5uE=.793455d2-0e07-4e22-b3e3-89dd651029c0@github.com>

On Thu, 6 Apr 2023 08:11:45 GMT, Glavo <duke at openjdk.org> wrote:

> os.arch is always the target architecture for JVM, even using 32-bit JVM on 64-bit system, its value remains x86.

Okay, I could have sworn we had to add the `ADDRESS_SIZE` check because of this issue where a 32-bit VM running on x64 would erroneously select the x64 ABIs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159734833

From rriggs at openjdk.org  Thu Apr  6 13:34:13 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 13:34:13 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <LoWlJFwsXXbDwr7WfOPP49CDMOnE3aU7vD7VILWDQkE=.07eb72c5-7bcc-4d9a-9518-14ce48dd2d63@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <LoWlJFwsXXbDwr7WfOPP49CDMOnE3aU7vD7VILWDQkE=.07eb72c5-7bcc-4d9a-9518-14ce48dd2d63@github.com>
Message-ID: <sepxAFSgYMetWe8oTnqeZHFSUZVZM_CO99-QFmj8lYI=.7f2c4ce3-86a3-4937-9322-acd6fa5549a5@github.com>

On Thu, 6 Apr 2023 03:17:37 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 37:
> 
>> 35: public enum Architecture {
>> 36:     X64(),        // Represents AMD64 and X86_64
>> 37:     X86(),
> 
> Suggestion:
> 
>     X86_64(),        // Represents AMD64 and X86_64
>     X86_32(),

The underscores are too ugly and X86 and X64 are well accepted names for those architectures.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159804212

From rriggs at openjdk.org  Thu Apr  6 13:34:16 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 13:34:16 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <CcdC-dn_yOzKYNQ5L2jhMZwRe_x5q59mxo6RpTIDs-E=.e1c302d4-3c5e-4892-9a52-e2f7efe2d246@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <CcdC-dn_yOzKYNQ5L2jhMZwRe_x5q59mxo6RpTIDs-E=.e1c302d4-3c5e-4892-9a52-e2f7efe2d246@github.com>
Message-ID: <WOwDnuubxA88fWJ5Xn0u_B6xS1G6pjAbHYSC9l8WDb4=.d1b0a0f0-a0b9-44ae-8072-29faf84f7358@github.com>

On Wed, 5 Apr 2023 23:39:00 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> test/jdk/java/foreign/TestUnsupportedLinker.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @ignore architecture can not be overridden by setting os.arch - delete test
> 
> FWIW, we introduce a property in CABI to override it directly in the JEP patch: https://github.com/openjdk/jdk/pull/13079/files#diff-1e9526318ae485495af012cbf0450693d77fd8241be62afe422a75304de5aed1R28

I'll drop the changes to foreign to avoid conflicts with PR #13079.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159801845

From rriggs at openjdk.org  Thu Apr  6 13:41:21 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 13:41:21 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <yFfP_oPn6GzKwA6avyNt3STIz49hjD1Gv5YSb2A-CgU=.52dd7fca-5f64-4665-8a06-e0272aa82c7d@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <yFfP_oPn6GzKwA6avyNt3STIz49hjD1Gv5YSb2A-CgU=.52dd7fca-5f64-4665-8a06-e0272aa82c7d@github.com>
Message-ID: <iS3fMy_lLdnJ4ouROyFQ9hyBk0YIg16idCaWq7pWQoY=.a57c5f92-8a89-4cfd-b3d9-7365810b45f4@github.com>

On Thu, 6 Apr 2023 07:41:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Why 2018?

Copy/paste error.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159813009

From jpai at openjdk.org  Thu Apr  6 13:41:24 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Apr 2023 13:41:24 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
Message-ID: <MiQD6AQa57VKQSBc-OsOiFLEEmMga3F0UdxOQp5SUgU=.0281f55f-5e7c-4e9c-a8a3-30f886a826b3@github.com>

On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl

src/java.base/share/classes/jdk/internal/util/Architecture.java line 42:

> 40:     AARCH64(),
> 41:     RISCV64(),
> 42:     S390X(),

Hello Roger, in a recent unrelated discussion, @RealLucy noted here https://github.com/openjdk/jdk/pull/13228#issuecomment-1488650865 that `s390x` denotes the arch and operating system combination and `s390` on the other hand represents the architecture. So should this enum value instead be `S390`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159810942

From rriggs at openjdk.org  Thu Apr  6 13:41:26 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 13:41:26 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <la0VOIRB7qmN9Y0_mUCl9-8oloBAW9ZW4vZ0ddAHgqo=.d9490bcb-a45d-4cac-a09c-683ee1c80f75@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <yFfP_oPn6GzKwA6avyNt3STIz49hjD1Gv5YSb2A-CgU=.52dd7fca-5f64-4665-8a06-e0272aa82c7d@github.com>
 <la0VOIRB7qmN9Y0_mUCl9-8oloBAW9ZW4vZ0ddAHgqo=.d9490bcb-a45d-4cac-a09c-683ee1c80f75@github.com>
Message-ID: <GsIzbdOe1YK90czP28gCz7GNhSrkh5cxw6yuU87M2qw=.b22c61be-3446-4355-9ec7-0f148f331b9c@github.com>

On Thu, 6 Apr 2023 08:05:14 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/Architecture.java line 85:
>> 
>>> 83:      */
>>> 84:     @ForceInline
>>> 85:     public static boolean isRISCV64() {
>> 
>> Are all the "isers" necessary to provide constant code folding or is the samt thing achievable via expressions like `(Architecture.current() == Architecture.X)` ?
>
> `Architecture.current()`?requires the?`Architecture.archValues` array to?be?annotated with?`@jdk.internal.vm.annotation.Stable` for?it?to?be?constant?foldable by?the?JIT.

The `isXXX` is lighterweight and easier to read.  
With current compiler technology, it can result in dead code elimination.
The HotSpot compiler reduces `(Architecture.current() == Architecture.X)` at runtime.  
Project Leyden may enable dead code based on evaluating more complex expressions as above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159811629

From rriggs at openjdk.org  Thu Apr  6 14:11:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 14:11:19 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <LoWlJFwsXXbDwr7WfOPP49CDMOnE3aU7vD7VILWDQkE=.07eb72c5-7bcc-4d9a-9518-14ce48dd2d63@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <LoWlJFwsXXbDwr7WfOPP49CDMOnE3aU7vD7VILWDQkE=.07eb72c5-7bcc-4d9a-9518-14ce48dd2d63@github.com>
Message-ID: <icOZtPetzIY9nTxlxASs1i4P-fprSHWpsSEubEcUYvE=.44380123-6097-4609-8dc6-74b3a9be386f@github.com>

On Thu, 6 Apr 2023 03:17:57 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 39:
> 
>> 37:     X86(),
>> 38:     IA64(),
>> 39:     ARM(),
> 
> Suggestion:
> 
>     ARM32(),

I'm inclined to drop the enum value and isArm method because they are legacy and are not being used in OpenJDK sources.  This could also apply to IA64. 
They can be added if needed and otherwise are just unused bulk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159852394

From psandoz at openjdk.org  Thu Apr  6 15:12:16 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 6 Apr 2023 15:12:16 GMT
Subject: RFR: 8305461: [vectorapi] Add VectorMask::xor
In-Reply-To: <jwSNj78SkdTEkWtny9s7dV1VH1RA8qYV1ZD2tONFj0Q=.98bb0702-3d1b-4232-9f69-6f4bcd0d8e4d@github.com>
References: <3qsNbKA1cm_XZnUNTDApkZDGMBq6PXcXZBTvEdv9UC4=.5dc8fed0-684e-4cd1-a007-d5e0c3cd0a65@github.com>
 <jwSNj78SkdTEkWtny9s7dV1VH1RA8qYV1ZD2tONFj0Q=.98bb0702-3d1b-4232-9f69-6f4bcd0d8e4d@github.com>
Message-ID: <uYAErTu7Evr4bUH-64o81FN9nTlObLW0xbWC6SQlFiI=.29c00d76-5a24-4138-a2ea-77c27007f894@github.com>

On Tue, 4 Apr 2023 15:44:41 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Hi,
>> 
>> This patch adds `VectorMask.xor` to the public interface of `VectorMask`. This method has already been existed in each concrete mask classes.
>> 
>> Please kindly review.
>> Thanks a lot.
>
> Thank you for doing this. I am guessing it was always intended to be public but was not spotted in previous reviews.

> @PaulSandoz Thanks for your timely review, do I need a second review for this patch?

No need for another reviewer.

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

PR Comment: https://git.openjdk.org/jdk/pull/13277#issuecomment-1499228548

From duke at openjdk.org  Thu Apr  6 15:31:14 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 6 Apr 2023 15:31:14 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <RLXITzKGMBGDGi0WLRNF4I4ztakWC96rvnmZHQxFzBY=.1381d600-b541-4daa-996e-3ca6f4e257f6@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <RLXITzKGMBGDGi0WLRNF4I4ztakWC96rvnmZHQxFzBY=.1381d600-b541-4daa-996e-3ca6f4e257f6@github.com>
Message-ID: <TVg8nM0cVwBPeGov7T6m-gl1Bhb9U598OYJKB6UfiyI=.801efaf7-8fd7-4d40-9b34-50e124e75a67@github.com>

On Thu, 6 Apr 2023 08:00:43 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 47:
> 
>> 45: 
>> 46:     // Cache a copy of the array for lightweight indexing
>> 47:     private static final Architecture[] archValues = Architecture.values();
> 
> This?needs to?be?annotated with?`@jdk.internal.vm.annotation.Stable` for?`Architecture.current()` to?be?constant?foldable:
> Suggestion:
> 
>     private static final @Stable Architecture[] archValues = Architecture.values();

Even if it's `static` *and* `final`? I thought `@Stable` exists to "...process non-null stable fields (final or otherwise) in a similar manner to static final fields with respect to promoting the field's value to a constant", implying that `static final` fields already have this property.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159957027

From qamai at openjdk.org  Thu Apr  6 15:36:24 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 6 Apr 2023 15:36:24 GMT
Subject: Integrated: 8305461: [vectorapi] Add VectorMask::xor
In-Reply-To: <3qsNbKA1cm_XZnUNTDApkZDGMBq6PXcXZBTvEdv9UC4=.5dc8fed0-684e-4cd1-a007-d5e0c3cd0a65@github.com>
References: <3qsNbKA1cm_XZnUNTDApkZDGMBq6PXcXZBTvEdv9UC4=.5dc8fed0-684e-4cd1-a007-d5e0c3cd0a65@github.com>
Message-ID: <WlqZzO2YsXxc15dwX1QAnXsNWdIJlI8eMpjSFa98C1o=.8c6af4ad-07de-4226-945f-91adf3b9bab8@github.com>

On Sat, 1 Apr 2023 15:40:14 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch adds `VectorMask.xor` to the public interface of `VectorMask`. This method has already been existed in each concrete mask classes.
> 
> Please kindly review.
> Thanks a lot.

This pull request has now been integrated.

Changeset: 536ad9df
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/536ad9df1abc2b905e8e679a08503afd6490805b
Stats:     2732 lines in 64 files changed: 2411 ins; 281 del; 40 mod

8305461: [vectorapi] Add VectorMask::xor

Reviewed-by: psandoz

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

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

From alanb at openjdk.org  Thu Apr  6 15:49:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Apr 2023 15:49:27 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
Message-ID: <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>

> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
> 
> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
> 
> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
> 
> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
> - ThreadPerTaskExecutor is changed to use FutureTask.
> 
> Testing: tier1-6.

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

 - Test/comments updates
 - Merge
 - Expand tests for jdk.ThreadSleep event
 - Review feedback
 - Merge
 - Fix ThreadSleepEvent again
 - Test updates
 - ThreadSleepEvent refactoring
 - Merge
 - Merge
 - ... and 1 more: https://git.openjdk.org/jdk/compare/6e04878d...a5bb3fd9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13203/files
  - new: https://git.openjdk.org/jdk/pull/13203/files/722d5afa..a5bb3fd9

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

  Stats: 21808 lines in 499 files changed: 11410 ins; 8547 del; 1851 mod
  Patch: https://git.openjdk.org/jdk/pull/13203.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13203/head:pull/13203

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

From alanb at openjdk.org  Thu Apr  6 15:50:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Apr 2023 15:50:06 GMT
Subject: RFR: 8305696: (zipfs) Avoid redundant LinkedHashMap.containsKey
 call ZipFileSystem.makeParentDirs
In-Reply-To: <L1C6gVVln23VejqKo9Qab54sNHc8tLuQoyVL3Y9uc9o=.9f0f0cdb-2e9c-42e6-801b-d1aa64dc8bc5@github.com>
References: <L1C6gVVln23VejqKo9Qab54sNHc8tLuQoyVL3Y9uc9o=.9f0f0cdb-2e9c-42e6-801b-d1aa64dc8bc5@github.com>
Message-ID: <3-aPfnucSFEEByALSr8Xv64VzIKcqfMte2ApNhm-3pY=.83a85005-b99c-4e21-b8d9-8d9e9829d06f@github.com>

On Mon, 3 Apr 2023 17:16:26 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `LinkedHashMap<IndexNode, IndexNode>` `ZipFileSystem.inodes` contains only non-null values. It means instead of separate `containsKey`+`get` calls, we can use single `LinkedHashMap.get` call and then compare result with `null`.
> Result code is a bit simpler and faster.
> 
> Testing: Linux x64 `java/nio`, `jdk/nio`

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13304#pullrequestreview-1375149465

From duke at openjdk.org  Thu Apr  6 15:53:25 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 6 Apr 2023 15:53:25 GMT
Subject: Integrated: JDK-8272119: Typo in JDK documentation (a -> an)
In-Reply-To: <40YBi9KTn2VI8x7eNQ5mCY5ftJoy8tD1a_irk8CGOvk=.f0e57a2f-a3e7-41a8-bb38-5a0b3bc18266@github.com>
References: <40YBi9KTn2VI8x7eNQ5mCY5ftJoy8tD1a_irk8CGOvk=.f0e57a2f-a3e7-41a8-bb38-5a0b3bc18266@github.com>
Message-ID: <kligs8nJx-ZEkKOxWXoBKBINXBF5Zrb1dJ4BiYnXTvw=.29b3cc76-83ec-4afb-8d17-510b4d4261fe@github.com>

On Wed, 5 Apr 2023 14:48:52 GMT, Viktor Klang <duke at openjdk.org> wrote:

> a -> an

This pull request has now been integrated.

Changeset: 08fbb7bb
Author:    Viktor Klang <viktor.klang at oracle.com>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08fbb7bb5edebbc22e0a84710894be47bd4fe332
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8272119: Typo in JDK documentation (a -> an)

Reviewed-by: dfuchs, mchung, iris

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

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

From jkuhn at openjdk.org  Thu Apr  6 16:00:20 2023
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Thu, 6 Apr 2023 16:00:20 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v6]
In-Reply-To: <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@github.com>
Message-ID: <2VczS9PzQByyD9ZeOoL5-w_YQ0LCHbFUtBas24NGdKE=.62539127-8dba-43b0-9cb7-a2744d7ba374@github.com>

On Thu, 6 Apr 2023 03:44:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace, cleanup, rename benchmarks to be informative

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

> 282:                     return type.getDeclaredAnnotation(WrapperInstance.class);
> 283:                 }
> 284:             }) : type.getDeclaredAnnotation(WrapperInstance.class);

This may introduce a security vulnerability:


@AnnotationTest.ClassHolder(sun.misc.Unsafe.class)
public class AnnotationTest {
    
    @Target(ElementType.TYPE)
    @Retention(RetentionPolicy.RUNTIME)
    @interface ClassHolder {
        Class<?> value();
    }
    public static void main(String[] args) throws PrivilegedActionException {
        MethodHandleProxies.isWrapperInstance(new AnnotationTest());
        System.out.println(AnnotationTest.class.getDeclaredAnnotation(ClassHolder.class).value());
    }
}


Don't parse annotations in a privileged context.

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

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

From jvernee at openjdk.org  Thu Apr  6 16:18:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Apr 2023 16:18:21 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v6]
In-Reply-To: <2VczS9PzQByyD9ZeOoL5-w_YQ0LCHbFUtBas24NGdKE=.62539127-8dba-43b0-9cb7-a2744d7ba374@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@github.com>
 <2VczS9PzQByyD9ZeOoL5-w_YQ0LCHbFUtBas24NGdKE=.62539127-8dba-43b0-9cb7-a2744d7ba374@github.com>
Message-ID: <9V7Lxo_MVbv4DNWm1hipUQsFZD4Qx_g1WF8uYggn69A=.a685dc78-1c1c-4357-b7d1-c15e85f1dfaf@github.com>

On Thu, 6 Apr 2023 15:57:33 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Whitespace, cleanup, rename benchmarks to be informative
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 284:
> 
>> 282:                     return type.getDeclaredAnnotation(WrapperInstance.class);
>> 283:                 }
>> 284:             }) : type.getDeclaredAnnotation(WrapperInstance.class);
> 
> This may introduce a security vulnerability:
> 
> 
> @AnnotationTest.ClassHolder(sun.misc.Unsafe.class)
> public class AnnotationTest {
>     
>     @Target(ElementType.TYPE)
>     @Retention(RetentionPolicy.RUNTIME)
>     @interface ClassHolder {
>         Class<?> value();
>     }
>     public static void main(String[] args) throws PrivilegedActionException {
>         MethodHandleProxies.isWrapperInstance(new AnnotationTest());
>         System.out.println(AnnotationTest.class.getDeclaredAnnotation(ClassHolder.class).value());
>     }
> }
> 
> 
> Don't parse annotations in a privileged context.

I'm not sure how the example shows that this is a security vulnerability? It still works fine without the call to `isWrapperInstance` (even if you switch to using jdk.internal.misc.Unsafe.class, although that also requires `--add-exports` when compiling)

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

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

From jkuhn at openjdk.org  Thu Apr  6 16:18:21 2023
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Thu, 6 Apr 2023 16:18:21 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v6]
In-Reply-To: <9V7Lxo_MVbv4DNWm1hipUQsFZD4Qx_g1WF8uYggn69A=.a685dc78-1c1c-4357-b7d1-c15e85f1dfaf@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@github.com>
 <2VczS9PzQByyD9ZeOoL5-w_YQ0LCHbFUtBas24NGdKE=.62539127-8dba-43b0-9cb7-a2744d7ba374@github.com>
 <9V7Lxo_MVbv4DNWm1hipUQsFZD4Qx_g1WF8uYggn69A=.a685dc78-1c1c-4357-b7d1-c15e85f1dfaf@github.com>
Message-ID: <BXC_zNN0NIDsUpdjCWntEeOD04gwDdJKzY5XaiOMafU=.50d2eabb-19ec-42fb-99e1-4ab7133c62d8@github.com>

On Thu, 6 Apr 2023 16:13:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 284:
>> 
>>> 282:                     return type.getDeclaredAnnotation(WrapperInstance.class);
>>> 283:                 }
>>> 284:             }) : type.getDeclaredAnnotation(WrapperInstance.class);
>> 
>> This may introduce a security vulnerability:
>> 
>> 
>> @AnnotationTest.ClassHolder(sun.misc.Unsafe.class)
>> public class AnnotationTest {
>>     
>>     @Target(ElementType.TYPE)
>>     @Retention(RetentionPolicy.RUNTIME)
>>     @interface ClassHolder {
>>         Class<?> value();
>>     }
>>     public static void main(String[] args) throws PrivilegedActionException {
>>         MethodHandleProxies.isWrapperInstance(new AnnotationTest());
>>         System.out.println(AnnotationTest.class.getDeclaredAnnotation(ClassHolder.class).value());
>>     }
>> }
>> 
>> 
>> Don't parse annotations in a privileged context.
>
> I'm not sure how the example shows that this is a security vulnerability? It still works fine without the call to `isWrapperInstance` (even if you switch to using jdk.internal.misc.Unsafe.class, although that also requires `--add-exports` when compiling)

Sorry, you are supposed to run it with an installed `SecurityManager` of course.  
With an installed `SecurityManager` you should not be able to access classes in `sun.misc`.

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

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

From liach at openjdk.org  Thu Apr  6 16:27:18 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Apr 2023 16:27:18 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v6]
In-Reply-To: <BXC_zNN0NIDsUpdjCWntEeOD04gwDdJKzY5XaiOMafU=.50d2eabb-19ec-42fb-99e1-4ab7133c62d8@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@github.com>
 <2VczS9PzQByyD9ZeOoL5-w_YQ0LCHbFUtBas24NGdKE=.62539127-8dba-43b0-9cb7-a2744d7ba374@github.com>
 <9V7Lxo_MVbv4DNWm1hipUQsFZD4Qx_g1WF8uYggn69A=.a685dc78-1c1c-4357-b7d1-c15e85f1dfaf@github.com>
 <BXC_zNN0NIDsUpdjCWntEeOD04gwDdJKzY5XaiOMafU=.50d2eabb-19ec-42fb-99e1-4ab7133c62d8@github.com>
Message-ID: <6YKY9npr2Dp9PO5bXb5OWvjJhRY-87LaVWelaIHP7BY=.c38048cd-50d8-4c76-9ecc-4d9bc1ae4b85@github.com>

On Thu, 6 Apr 2023 16:15:16 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

>> I'm not sure how the example shows that this is a security vulnerability? It still works fine without the call to `isWrapperInstance` (even if you switch to using jdk.internal.misc.Unsafe.class, although that also requires `--add-exports` when compiling)
>
> Sorry, you are supposed to run it with an installed `SecurityManager` of course.  
> With an installed `SecurityManager` you should not be able to access classes in `sun.misc`.

Guess I will just nuke the annotation and check for its implemented clause instead.

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

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

From rriggs at openjdk.org  Thu Apr  6 16:29:09 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 16:29:09 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <TVg8nM0cVwBPeGov7T6m-gl1Bhb9U598OYJKB6UfiyI=.801efaf7-8fd7-4d40-9b34-50e124e75a67@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <RLXITzKGMBGDGi0WLRNF4I4ztakWC96rvnmZHQxFzBY=.1381d600-b541-4daa-996e-3ca6f4e257f6@github.com>
 <TVg8nM0cVwBPeGov7T6m-gl1Bhb9U598OYJKB6UfiyI=.801efaf7-8fd7-4d40-9b34-50e124e75a67@github.com>
Message-ID: <vbNizO04e07ExQof6jN2gwc5nX-ZHKqOyTnEV9z8AXQ=.6740715b-a821-4890-9627-a13372d1ac67@github.com>

On Thu, 6 Apr 2023 15:27:49 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/Architecture.java line 47:
>> 
>>> 45: 
>>> 46:     // Cache a copy of the array for lightweight indexing
>>> 47:     private static final Architecture[] archValues = Architecture.values();
>> 
>> This?needs to?be?annotated with?`@jdk.internal.vm.annotation.Stable` for?`Architecture.current()` to?be?constant?foldable:
>> Suggestion:
>> 
>>     private static final @Stable Architecture[] archValues = Architecture.values();
>
> Even if it's `static` *and* `final`? I thought `@Stable` exists to "...process non-null stable fields (final or otherwise) in a similar manner to static final fields with respect to promoting the field's value to a constant", implying that `static final` fields already have this property.

The use here is not particularly performance sensitive. So it doesn't provide much value.
In this case, it allows each array element to be considered stable.

>From the @Stable javadoc:

 * Fields which are declared {@code final} may also be annotated as stable.
 * Since final fields already behave as stable values, such an annotation
 * conveys no additional information regarding change of the field's value, but
 * still conveys information regarding change of additional components values if
 * the type of the field is an array type (as described above).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160018375

From jvernee at openjdk.org  Thu Apr  6 17:01:15 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Apr 2023 17:01:15 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v6]
In-Reply-To: <6YKY9npr2Dp9PO5bXb5OWvjJhRY-87LaVWelaIHP7BY=.c38048cd-50d8-4c76-9ecc-4d9bc1ae4b85@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@github.com>
 <2VczS9PzQByyD9ZeOoL5-w_YQ0LCHbFUtBas24NGdKE=.62539127-8dba-43b0-9cb7-a2744d7ba374@github.com>
 <9V7Lxo_MVbv4DNWm1hipUQsFZD4Qx_g1WF8uYggn69A=.a685dc78-1c1c-4357-b7d1-c15e85f1dfaf@github.com>
 <BXC_zNN0NIDsUpdjCWntEeOD04gwDdJKzY5XaiOMafU=.50d2eabb-19ec-42fb-99e1-4ab7133c62d8@github.com>
 <6YKY9npr2Dp9PO5bXb5OWvjJhRY-87LaVWelaIHP7BY=.c38048cd-50d8-4c76-9ecc-4d9bc1ae4b85@github.com>
Message-ID: <ztUZF5ThyhCdD_NvaGNbgc6XQKpxGqa_lFasi1FtamA=.646964c6-084d-4a00-9d6a-0c10d30ee426@github.com>

On Thu, 6 Apr 2023 16:24:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Sorry, you are supposed to run it with an installed `SecurityManager` of course.  
>> With an installed `SecurityManager` you should not be able to access classes in `sun.misc`.
>
> Guess I will just nuke the annotation and check for its implemented clause instead.

I don't think that's good enough. If an instance implements an interface that just happens to also have an entry in the INTERFACE_INFOS cache, then e.g. `MethodHandleProxies::wrapperInstanceTarget` could be used to retrieve the class data of a class that wasn't generated using MethodHandleProxies.

I think some explicit marker is needed for class generated by MethodHandleProxies.

Switching back to the `WrapperInstance` interface, and then defining the class using `IMPL_LOOKUP`, as opposed to defining the class in a dynamic module, could be an option (since we determined that the wrapper instance can not be used to escalate privilege. I'm just not sure if that will work for target interfaces in non-exported packages. Proxy seems to be able to do that too though.

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

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

From jkuhn at openjdk.org  Thu Apr  6 17:07:07 2023
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Thu, 6 Apr 2023 17:07:07 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v6]
In-Reply-To: <ztUZF5ThyhCdD_NvaGNbgc6XQKpxGqa_lFasi1FtamA=.646964c6-084d-4a00-9d6a-0c10d30ee426@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@github.com>
 <2VczS9PzQByyD9ZeOoL5-w_YQ0LCHbFUtBas24NGdKE=.62539127-8dba-43b0-9cb7-a2744d7ba374@github.com>
 <9V7Lxo_MVbv4DNWm1hipUQsFZD4Qx_g1WF8uYggn69A=.a685dc78-1c1c-4357-b7d1-c15e85f1dfaf@github.com>
 <BXC_zNN0NIDsUpdjCWntEeOD04gwDdJKzY5XaiOMafU=.50d2eabb-19ec-42fb-99e1-4ab7133c62d8@github.com>
 <6YKY9npr2Dp9PO5bXb5OWvjJhRY-87LaVWelaIHP7BY=.c38048cd-50d8-4c76-9ecc-4d9bc1ae4b85@github.com>
 <ztUZF5ThyhCdD_NvaGNbgc6XQKpxGqa_lFasi1FtamA=.646964c6-084d-4a00-9d6a-0c10d30ee426@github.com>
Message-ID: <oN8A3EPYZ8WDHW2YQDhKfa-eJvEmI0SOJMMh2sGIB_E=.f7bdb760-a72f-4c9e-92e4-d8ad6632dd50@github.com>

On Thu, 6 Apr 2023 16:58:43 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Guess I will just nuke the annotation and check for its implemented clause instead.
>
> I don't think that's good enough. If an instance implements an interface that just happens to also have an entry in the INTERFACE_INFOS cache, then e.g. `MethodHandleProxies::wrapperInstanceTarget` could be used to retrieve the class data of a class that wasn't generated using MethodHandleProxies.
> 
> I think some explicit marker is needed for class generated by MethodHandleProxies.
> 
> Switching back to the `WrapperInstance` interface, and then defining the class using `IMPL_LOOKUP`, as opposed to defining the class in a dynamic module, could be an option (since we determined that the wrapper instance can not be used to escalate privilege. I'm just not sure if that will work for target interfaces in non-exported packages. Proxy seems to be able to do that too though.

An other possibility to to add some key into the ClassData that can't be imitated - such as the `InterfaceInfo` itself.  
An `instanceof` check on the ClassData at a fixed position could then determine if is a MHP.

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

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

From rriggs at openjdk.org  Thu Apr  6 17:17:35 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 17:17:35 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v5]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <RNCT_0qrYIiGhIqeW400LQizY12I8E3KUfh7miWaPCs=.97b3db84-d3f1-4d8f-bb16-b4230e4da670@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Revert changes to Foreign API to avoid class with another PR
  Rename S390X to S390, representing just the s390 architecture
  Removed ARM and IA64 enum values; they are unused; they can be added later if needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/8916dcae..105ce605

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

  Stats: 58 lines in 5 files changed: 5 ins; 32 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

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

From liach at openjdk.org  Thu Apr  6 17:18:22 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Apr 2023 17:18:22 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v7]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <0taty5KKs0mKI7Fh6Gt11ySMUTl940RvQxqTkDv-sxM=.056b2f7e-c326-4a2d-b8dd-86c72bde50bc@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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
> 
> [^1]: single abstract method

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

 - Nuke WrapperInstance
 - Merge branch 'master' into explore/mhp-iface
 - Whitespace, cleanup, rename benchmarks to be informative
 - Address review comments
   
   Make sure it runs with SecurityManager
   Split the benchmarks
 - Use a dumper for interface instances, other cleanup
 - Merge branch 'master' into explore/mhp-iface
 - Merge branch 'master' into explore/mhp-iface
 - Remove unused JavaLangReflectReflectAccess.invokeDefault
 - rethrow error
 - Benchmark compareing to lamda metafactory, various minor updates
 - ... and 7 more: https://git.openjdk.org/jdk/compare/9b04b70e...3fe36fd6

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/3e5e6143..3fe36fd6

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

  Stats: 8051 lines in 169 files changed: 7176 ins; 465 del; 410 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 jvernee at openjdk.org  Thu Apr  6 17:24:23 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Apr 2023 17:24:23 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v7]
In-Reply-To: <0taty5KKs0mKI7Fh6Gt11ySMUTl940RvQxqTkDv-sxM=.056b2f7e-c326-4a2d-b8dd-86c72bde50bc@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <0taty5KKs0mKI7Fh6Gt11ySMUTl940RvQxqTkDv-sxM=.056b2f7e-c326-4a2d-b8dd-86c72bde50bc@github.com>
Message-ID: <Dop9qJMLUxgu5ifULoESEw9jyMiYZ327PKMmDkFKF8o=.e48f6efb-472c-4de4-945d-67f9df896dad@github.com>

On Thu, 6 Apr 2023 17:18:22 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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Nuke WrapperInstance
>  - Merge branch 'master' into explore/mhp-iface
>  - Whitespace, cleanup, rename benchmarks to be informative
>  - Address review comments
>    
>    Make sure it runs with SecurityManager
>    Split the benchmarks
>  - Use a dumper for interface instances, other cleanup
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - Remove unused JavaLangReflectReflectAccess.invokeDefault
>  - rethrow error
>  - Benchmark compareing to lamda metafactory, various minor updates
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/ee339c8e...3fe36fd6

test/jdk/java/lang/invoke/MethodHandleProxies/BasicTest.java line 31:

> 29:  *          java.base/jdk.internal.classfile.constantpool
> 30:  * @summary Basic sanity tests for MethodHandleProxies
> 31:  * @run junit/othervm -ea -esa -Djdk.invoke.MethodHandleProxies.dumpInterfaceInstances BasicTest

AFAIK jtreg already adds `-ea` and `-esa` so it shouldn't be needed here

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

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

From jvernee at openjdk.org  Thu Apr  6 17:24:28 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Apr 2023 17:24:28 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v6]
In-Reply-To: <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@github.com>
Message-ID: <Swz5eBbc2tMlcL40MflnzQwBu4k56I1iDE3Hc-M42r0=.7a749b37-39c1-4e57-9cbb-24ee4c1cb0a0@github.com>

On Thu, 6 Apr 2023 03:44:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace, cleanup, rename benchmarks to be informative

test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesAsIFInstanceCall.java line 131:

> 129:         interfaceInstance = MethodHandleProxies.asInterfaceInstance(Doable.class, target);
> 130:         lambda = (Doable) LambdaMetafactory.metafactory(LOOKUP, "doWork", MT_Doable, MT_int_int, target, MT_int_int).getTarget().invokeExact();
> 131:     }

The setup here can just re-use the constant* fields. The important part is that the benchmark methods load the value from a non-constant field (i.e. not static final).
Suggestion:

    @Setup
    public void setup() throws Throwable {
        target = constantTarget;
        doable = constantDoable;
        handle = constantHandle;
        interfaceInstance = constantInterfaceInstance;
        lambda = constantLambda;
    }

test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesAsIFInstanceCall.java line 176:

> 174:     public void constantLambda() {
> 175:         i = constantLambda.doWork(i);
> 176:     }

I think setting the result into an instance field like this can work, but it's imo better to let JMH handle it. So, these methods should just return the value instead of writing it to the `i` field.

test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesAsIFInstanceCreate.java line 86:

> 84:         i = doable.doWork(i);
> 85:         return doable;
> 86:     }

In this case, instead of writing to `i`, the benchmark method can accept a `Blackhole` argument and use that to consume the value.
Suggestion:

    public Doable createCallLambda(Blackhole bh) throws Throwable {
        Doable doable = (Doable) LambdaMetafactory.metafactory(LOOKUP, "doWork", MT_Doable, MT_int_int, target, MT_int_int).getTarget().invokeExact();
        bh.consume(doable.doWork(i));
        return doable;
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1160054577
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1160056394
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1160059392

From jvernee at openjdk.org  Thu Apr  6 17:30:18 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Apr 2023 17:30:18 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v6]
In-Reply-To: <oN8A3EPYZ8WDHW2YQDhKfa-eJvEmI0SOJMMh2sGIB_E=.f7bdb760-a72f-4c9e-92e4-d8ad6632dd50@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@github.com>
 <2VczS9PzQByyD9ZeOoL5-w_YQ0LCHbFUtBas24NGdKE=.62539127-8dba-43b0-9cb7-a2744d7ba374@github.com>
 <9V7Lxo_MVbv4DNWm1hipUQsFZD4Qx_g1WF8uYggn69A=.a685dc78-1c1c-4357-b7d1-c15e85f1dfaf@github.com>
 <BXC_zNN0NIDsUpdjCWntEeOD04gwDdJKzY5XaiOMafU=.50d2eabb-19ec-42fb-99e1-4ab7133c62d8@github.com>
 <6YKY9npr2Dp9PO5bXb5OWvjJhRY-87LaVWelaIHP7BY=.c38048cd-50d8-4c76-9ecc-4d9bc1ae4b85@github.com>
 <ztUZF5ThyhCdD_NvaGNbgc6XQKpxGqa_lFasi1FtamA=.646964c6-084d-4a00-9d6a-0c10d30ee426@github.com>
 <oN8A3EPYZ8WDHW2YQDhKfa-eJvEmI0SOJMMh2sGIB_E=.f7bdb760-a72f-4c9e-92e4-d8ad6632dd50@github.com>
Message-ID: <EX6f8EoOhL5Ja7odE4Sk9B7PgUNnawbUQa43g1fqTBk=.10166737-d2a9-40aa-b61d-b6f06997ed51@github.com>

On Thu, 6 Apr 2023 17:04:02 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

>> I don't think that's good enough. If an instance implements an interface that just happens to also have an entry in the INTERFACE_INFOS cache, then e.g. `MethodHandleProxies::wrapperInstanceTarget` could be used to retrieve the class data of a class that wasn't generated using MethodHandleProxies.
>> 
>> I think some explicit marker is needed for class generated by MethodHandleProxies.
>> 
>> Switching back to the `WrapperInstance` interface, and then defining the class using `IMPL_LOOKUP`, as opposed to defining the class in a dynamic module, could be an option (since we determined that the wrapper instance can not be used to escalate privilege. I'm just not sure if that will work for target interfaces in non-exported packages. Proxy seems to be able to do that too though.
>
> An other possibility to to add some key into the ClassData that can't be imitated - such as the `InterfaceInfo` itself.  
> An `instanceof` check on the ClassData at a fixed position could then determine if is a MHP.

It looks like Proxy forcibly adds reads and exports edges from the module of the target interface to the module that defines the proxy: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/reflect/Proxy.java#L855-L868 I think we can do the same here

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

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

From jvernee at openjdk.org  Thu Apr  6 17:44:23 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Apr 2023 17:44:23 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v7]
In-Reply-To: <0taty5KKs0mKI7Fh6Gt11ySMUTl940RvQxqTkDv-sxM=.056b2f7e-c326-4a2d-b8dd-86c72bde50bc@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <0taty5KKs0mKI7Fh6Gt11ySMUTl940RvQxqTkDv-sxM=.056b2f7e-c326-4a2d-b8dd-86c72bde50bc@github.com>
Message-ID: <rdKh62sJED_kdgF1Wsl73oc8DqQBd28Zq8sMyoPIR_8=.fcb5f0b4-ad36-4aab-98d0-eceb7ababc6f@github.com>

On Thu, 6 Apr 2023 17:18:22 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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Nuke WrapperInstance
>  - Merge branch 'master' into explore/mhp-iface
>  - Whitespace, cleanup, rename benchmarks to be informative
>  - Address review comments
>    
>    Make sure it runs with SecurityManager
>    Split the benchmarks
>  - Use a dumper for interface instances, other cleanup
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - Remove unused JavaLangReflectReflectAccess.invokeDefault
>  - rethrow error
>  - Benchmark compareing to lamda metafactory, various minor updates
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/56e7c01e...3fe36fd6

> Updated per your comments and refined the benchmark as well.

Thanks! the new benchmarks look much better already. I've left a couple of inline comments as well.

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

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

From mchung at openjdk.org  Thu Apr  6 17:54:18 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 6 Apr 2023 17:54:18 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: <PGfnSI2IP7zQ1B6p0c5uSaTvt7Tlk6PTFPAzA77HeVY=.af8c60d6-3110-48cc-bb46-285d00f6c790@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <Mx7AH0tqNK0e10MkIi9BZm7hVuL5qXvhdtY8i0BiPE4=.f3329822-11a8-498d-9fac-fc1df82090f0@github.com>
 <6N1wKps-M239ceVuAojyvUIc-HjAEhcMLhxB6-jlkwI=.fc4f560f-9e98-4688-98a2-187e4f3f8758@github.com>
 <tj562sC1hOPdzmo76ZkzZLJ__offyU-bl_aif14sb-U=.d5718dc9-c8dc-4776-a536-73f7d402fc9d@github.com>
 <PGfnSI2IP7zQ1B6p0c5uSaTvt7Tlk6PTFPAzA77HeVY=.af8c60d6-3110-48cc-bb46-285d00f6c790@github.com>
Message-ID: <GnM5Sjf9eU2iN0uGez2fBxnhWxoiqKo4I59AJyyI_Qk=.39292947-803b-48d9-9be8-d3f0183b8515@github.com>

On Wed, 5 Apr 2023 17:59:24 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

>>> I think it should be possible to spin the class bytes once, stick the result in a ClassValue cache, but then use the bytes to define multiple classes with different class data (MethodHandles).
>> 
>> Great point, I was dumbfounded there.
>> 
>>> Let suppose you have an interface like:
>>> 
>>> ```
>>> interface StringConsumer extends Consumer<String> {}
>>> ```
>>> 
>>> The implementation needs to override both accept(Object) and accept(String).
>> 
>> It already does, and there are multiple test cases covering that: [mine](https://github.com/openjdk/jdk/pull/13197/files#diff-9753e5dae7b27070a1fe0d6c12eb65db605ee479d0e93d214ce710a8bbfc4922R176) and another in [MethodHandlesGeneralTest](https://github.com/openjdk/jdk/blob/927e674c12aa7965c63059b8f650d8f60156cefc/test/jdk/java/lang/invoke/MethodHandlesGeneralTest.java#L1785)
>> 
>>> Also, it would be nice if you could include the benchmarks you used in the patch as well.
>> 
>> They are from the JDK itself: https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesSuppl.java https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesAsIFInstance.java
>> 
>> Due to make issues (it passed `/` for module exports as `` on my windows somehow), I ran the test by copying them to a separate Gradle project with Gradle JMH plugin.
>> 
>>> I've worked on something similar before: https://bugs.openjdk.org/browse/JDK-8257605 The idea then was to add a new API in MethodHandles but since then I've been thinking that enhancing the performance of MethodHandleProxies might be better. The only issue I saw with that is that the current API doesn't accept a MethodHandles.Lookup object which would be needed to define an interface instance if the interface is in a non-exported package. Your solution just creates the lookup directly. Typically we have to be careful with injecting classes into other packages/modules since it can lead to access escalation, but maybe in this case it is fine. I don't think there's a way that this could be used to escalate access, though it seems strange that anyone could now define a class in a non-exported package/some other module.
>> 
>> About access:
>> 1. The method handle itself is already access-checked upon creation. 
>> 2. The interface access may be problematic: A non-exported interface Class object can be obtained via Reflection inspection on exported types, such as java packages and jdk.internal packages. 
>>    - In that case, it might not be of best interest to create an interface, but I don't think the current asInterfaceInstance API rejects such creations either.
>> 3. The class definition under the interface and its classloader IMO is safe, as the class will not refer to any type the interface itself does not refer to; the annotation is not involved in class loading either.
>> 
>>> We've also recently discussed LambdaMetafactory https://github.com/openjdk/jdk/pull/12493 which will produce classes strongly tied to the class loader. If we can bring MethodHandleProxies up to the same performance level as the classes produced by LambdaMetaFactory, it could serve as an alternative and people could move away from using the LambdaMetafactory runtime API (which is not really meant to be used directly). WRT that, I think the fact that the implementation proposed by this patch defines classes that are not strongly tied to the defining loader is a good thing.
>> 
>> Sounds good; it's not hard to make a benchmark that compares asInterfaceInstance and metafactory side-by-side either. The non-strong feature was intended indeed when one class is defined for each class + methodhandle combination. I agree `asInterfaceInstance` would be extremely useful to users, like a plugin loader converting json-based static method references into SAM implementations, which definitely should not become defined as a part of the plugin loader; or an event bus firing events.
>
>> The interface access may be problematic: A non-exported interface Class object can be obtained via Reflection inspection on exported types, such as java packages and jdk.internal packages.
>> 
>>     * In that case, it might not be of best interest to create an interface, but I don't think the current asInterfaceInstance API rejects such creations either.
> 
> See the Javadoc: https://github.com/openjdk/jdk/pull/13197/files#diff-6de80127c851b1b0ba6b2ab0a739ffae803187028a721d4a28cd47fb17b1bbcdL64-L65
> 
> As this API was added in Java 7, `public` access was easy. W.R.T. modules, no changes have been made to this API.  
> The (previously) underlying `java.lang.reflect.Proxy` does not even require that.
> 
> @liach  Can you please test calling `MethodHandleProxies.wrapperInstanceTarget(MethodHandleProxies.asInterfaceInstance(Runnable.class, MethodHandles.zero(void.class)))` **with an installed `SecurityManager`**?
> Also with an interface in an untrusted protection domain, for example:
> 
> 
> public interface Test {
>     void run();
>     public static void main(String[] args) {
>         System.out.println(MethodHandleProxies.wrapperInstanceTarget(MethodHandleProxies.asInterfaceInstance(Test.class, MethodHandles.zero(void.class))));
>     }
> }
> 
> also with a `SecurityManager` (`-Djava.security.manager` as VM argument).

> @DasBrain Thanks for the recommendation to test with SecurityManager, added a test and found two places that needs to do privileged indeed.

What operations require the security permission check?   I suspect some doPrivileged may be missing in the ClassFile API implementation.

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

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

From liach at openjdk.org  Thu Apr  6 17:54:20 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Apr 2023 17:54:20 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v6]
In-Reply-To: <EX6f8EoOhL5Ja7odE4Sk9B7PgUNnawbUQa43g1fqTBk=.10166737-d2a9-40aa-b61d-b6f06997ed51@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@github.com>
 <2VczS9PzQByyD9ZeOoL5-w_YQ0LCHbFUtBas24NGdKE=.62539127-8dba-43b0-9cb7-a2744d7ba374@github.com>
 <9V7Lxo_MVbv4DNWm1hipUQsFZD4Qx_g1WF8uYggn69A=.a685dc78-1c1c-4357-b7d1-c15e85f1dfaf@github.com>
 <BXC_zNN0NIDsUpdjCWntEeOD04gwDdJKzY5XaiOMafU=.50d2eabb-19ec-42fb-99e1-4ab7133c62d8@github.com>
 <6YKY9npr2Dp9PO5bXb5OWvjJhRY-87LaVWelaIHP7BY=.c38048cd-50d8-4c76-9ecc-4d9bc1ae4b85@github.com>
 <ztUZF5ThyhCdD_NvaGNbgc6XQKpxGqa_lFasi1FtamA=.646964c6-084d-4a00-9d6a-0c10d30ee426@github.com>
 <oN8A3EPYZ8WDHW2YQDhKfa-eJvEmI0SOJMMh2sGIB_E=.f7bdb760-a72f-4c9e-92e4-d8ad6632dd50@github.com>
 <EX6f8EoOhL5Ja7odE4Sk9B7PgUNnawbUQa43g1fqTBk=.10166737-d2a9-40aa-b61d-b6f06997ed51@github.com>
Message-ID: <AjXnD01FmlYsgDkUIq5rzx6QoM_DRgGdGRz1WN16UHg=.b35cec7b-67c3-42a5-88f6-af9d055676fb@github.com>

On Thu, 6 Apr 2023 17:27:14 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> An other possibility to to add some key into the ClassData that can't be imitated - such as the `InterfaceInfo` itself.  
>> An `instanceof` check on the ClassData at a fixed position could then determine if is a MHP.
>
> It looks like Proxy forcibly adds reads and exports edges from the module of the target interface to the module that defines the proxy: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/reflect/Proxy.java#L855-L868 I think we can do the same here

I would support the putting InterfaceInfo in class data approach. With IMPL_LOOKUP, we currently define the hidden class in the same module as the interface. It's currently hard to define a hidden class without an anchor host class for a new module.

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

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

From mchung at openjdk.org  Thu Apr  6 17:59:15 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 6 Apr 2023 17:59:15 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v4]
In-Reply-To: <Y3D7vbAYx3qZJXYND4qNh4wDVRg84BUDOd_uZrQB_0A=.a7da1a97-b216-408f-ad6a-4da56fb2f77c@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <6hZzlgJtzWUJJupq0J2gRfeEvxD-wXkpsa2XcYvA0qM=.145bc6af-99b5-421a-940c-5198291764c8@github.com>
 <Y3D7vbAYx3qZJXYND4qNh4wDVRg84BUDOd_uZrQB_0A=.a7da1a97-b216-408f-ad6a-4da56fb2f77c@github.com>
Message-ID: <ASIxJa9wfdr8YvxQLZaD9sVuB_oR2GkWccMlHuzuj74=.c2479e31-0309-4f30-ab0b-a4e37906b36b@github.com>

On Wed, 5 Apr 2023 13:22:30 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
>> 
>>  - Use a dumper for interface instances, other cleanup
>>  - Merge branch 'master' into explore/mhp-iface
>>  - Merge branch 'master' into explore/mhp-iface
>>  - Remove unused JavaLangReflectReflectAccess.invokeDefault
>>  - rethrow error
>>  - Benchmark compareing to lamda metafactory, various minor updates
>>  - Cache the spinned class, loading is still slow
>>  - Wrapper instance type is already available
>>  - mark records as private
>>  - Merge branch 'master' into explore/mhp-iface
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/3fd633cd...0eec507d
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 213:
> 
>> 211:                     .defineClassAsLookup(true, List.of(mhs));
>> 212:             proxy = lookup.findConstructor(lookup.lookupClass(), methodType(void.class))
>> 213:                     .asType(methodType(Object.class)).invokeExact();
> 
> This can use `invoke` instead of an explicit `asType` and `invokeExact`. It is more or less the same.
> Suggestion:
> 
>             proxy = lookup.findConstructor(lookup.lookupClass(), methodType(void.class)).invoke();

@JornVernee Is there any performance difference with `invokeExact` vs `invoke`?   I have the impression there is.

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

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

From duke at openjdk.org  Thu Apr  6 18:07:29 2023
From: duke at openjdk.org (Chris Hennick)
Date: Thu, 6 Apr 2023 18:07:29 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v19]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <wmegzqOmGYmmSpapSq1N2yIsBWcKTXCYDFpUQLwDYrs=.8a7ed0df-4849-4656-a52f-8f99a4963516@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 17 commits:

 - 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
 - Add parameter to enable/disable fixed PRNG seed
 - Rewrite Javadoc
 - Simplify Javadoc description
 - ... and 7 more: https://git.openjdk.org/jdk/compare/08fbb7bb...2470c00a

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

Changes: https://git.openjdk.org/jdk/pull/8131/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=18
  Stats: 144 lines in 4 files changed: 129 ins; 1 del; 14 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 liach at openjdk.org  Thu Apr  6 18:12:19 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Apr 2023 18:12:19 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: <PGfnSI2IP7zQ1B6p0c5uSaTvt7Tlk6PTFPAzA77HeVY=.af8c60d6-3110-48cc-bb46-285d00f6c790@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <Mx7AH0tqNK0e10MkIi9BZm7hVuL5qXvhdtY8i0BiPE4=.f3329822-11a8-498d-9fac-fc1df82090f0@github.com>
 <6N1wKps-M239ceVuAojyvUIc-HjAEhcMLhxB6-jlkwI=.fc4f560f-9e98-4688-98a2-187e4f3f8758@github.com>
 <tj562sC1hOPdzmo76ZkzZLJ__offyU-bl_aif14sb-U=.d5718dc9-c8dc-4776-a536-73f7d402fc9d@github.com>
 <PGfnSI2IP7zQ1B6p0c5uSaTvt7Tlk6PTFPAzA77HeVY=.af8c60d6-3110-48cc-bb46-285d00f6c790@github.com>
Message-ID: <PnDi7l7gLXLUQwf0V_pyF-tFLajRwtPoXks4lyvYP9o=.e1c7fea3-d1a8-43e3-8bc5-82ea807f98aa@github.com>

On Wed, 5 Apr 2023 17:59:24 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

>>> I think it should be possible to spin the class bytes once, stick the result in a ClassValue cache, but then use the bytes to define multiple classes with different class data (MethodHandles).
>> 
>> Great point, I was dumbfounded there.
>> 
>>> Let suppose you have an interface like:
>>> 
>>> ```
>>> interface StringConsumer extends Consumer<String> {}
>>> ```
>>> 
>>> The implementation needs to override both accept(Object) and accept(String).
>> 
>> It already does, and there are multiple test cases covering that: [mine](https://github.com/openjdk/jdk/pull/13197/files#diff-9753e5dae7b27070a1fe0d6c12eb65db605ee479d0e93d214ce710a8bbfc4922R176) and another in [MethodHandlesGeneralTest](https://github.com/openjdk/jdk/blob/927e674c12aa7965c63059b8f650d8f60156cefc/test/jdk/java/lang/invoke/MethodHandlesGeneralTest.java#L1785)
>> 
>>> Also, it would be nice if you could include the benchmarks you used in the patch as well.
>> 
>> They are from the JDK itself: https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesSuppl.java https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesAsIFInstance.java
>> 
>> Due to make issues (it passed `/` for module exports as `` on my windows somehow), I ran the test by copying them to a separate Gradle project with Gradle JMH plugin.
>> 
>>> I've worked on something similar before: https://bugs.openjdk.org/browse/JDK-8257605 The idea then was to add a new API in MethodHandles but since then I've been thinking that enhancing the performance of MethodHandleProxies might be better. The only issue I saw with that is that the current API doesn't accept a MethodHandles.Lookup object which would be needed to define an interface instance if the interface is in a non-exported package. Your solution just creates the lookup directly. Typically we have to be careful with injecting classes into other packages/modules since it can lead to access escalation, but maybe in this case it is fine. I don't think there's a way that this could be used to escalate access, though it seems strange that anyone could now define a class in a non-exported package/some other module.
>> 
>> About access:
>> 1. The method handle itself is already access-checked upon creation. 
>> 2. The interface access may be problematic: A non-exported interface Class object can be obtained via Reflection inspection on exported types, such as java packages and jdk.internal packages. 
>>    - In that case, it might not be of best interest to create an interface, but I don't think the current asInterfaceInstance API rejects such creations either.
>> 3. The class definition under the interface and its classloader IMO is safe, as the class will not refer to any type the interface itself does not refer to; the annotation is not involved in class loading either.
>> 
>>> We've also recently discussed LambdaMetafactory https://github.com/openjdk/jdk/pull/12493 which will produce classes strongly tied to the class loader. If we can bring MethodHandleProxies up to the same performance level as the classes produced by LambdaMetaFactory, it could serve as an alternative and people could move away from using the LambdaMetafactory runtime API (which is not really meant to be used directly). WRT that, I think the fact that the implementation proposed by this patch defines classes that are not strongly tied to the defining loader is a good thing.
>> 
>> Sounds good; it's not hard to make a benchmark that compares asInterfaceInstance and metafactory side-by-side either. The non-strong feature was intended indeed when one class is defined for each class + methodhandle combination. I agree `asInterfaceInstance` would be extremely useful to users, like a plugin loader converting json-based static method references into SAM implementations, which definitely should not become defined as a part of the plugin loader; or an event bus firing events.
>
>> The interface access may be problematic: A non-exported interface Class object can be obtained via Reflection inspection on exported types, such as java packages and jdk.internal packages.
>> 
>>     * In that case, it might not be of best interest to create an interface, but I don't think the current asInterfaceInstance API rejects such creations either.
> 
> See the Javadoc: https://github.com/openjdk/jdk/pull/13197/files#diff-6de80127c851b1b0ba6b2ab0a739ffae803187028a721d4a28cd47fb17b1bbcdL64-L65
> 
> As this API was added in Java 7, `public` access was easy. W.R.T. modules, no changes have been made to this API.  
> The (previously) underlying `java.lang.reflect.Proxy` does not even require that.
> 
> @liach  Can you please test calling `MethodHandleProxies.wrapperInstanceTarget(MethodHandleProxies.asInterfaceInstance(Runnable.class, MethodHandles.zero(void.class)))` **with an installed `SecurityManager`**?
> Also with an interface in an untrusted protection domain, for example:
> 
> 
> public interface Test {
>     void run();
>     public static void main(String[] args) {
>         System.out.println(MethodHandleProxies.wrapperInstanceTarget(MethodHandleProxies.asInterfaceInstance(Test.class, MethodHandles.zero(void.class))));
>     }
> }
> 
> also with a `SecurityManager` (`-Djava.security.manager` as VM argument).

> > @DasBrain Thanks for the recommendation to test with SecurityManager, added a test and found two places that needs to do privileged indeed.
> 
> What operations require the security permission check? I suspect some doPrivileged may be missing in the ClassFile API implementation.

It appears the default class hierarchy resolver cannot be used to generates stack maps with only the FilePermission required by JTReg granted.

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

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

From liach at openjdk.org  Thu Apr  6 18:12:21 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Apr 2023 18:12:21 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: <GnM5Sjf9eU2iN0uGez2fBxnhWxoiqKo4I59AJyyI_Qk=.39292947-803b-48d9-9be8-d3f0183b8515@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <Mx7AH0tqNK0e10MkIi9BZm7hVuL5qXvhdtY8i0BiPE4=.f3329822-11a8-498d-9fac-fc1df82090f0@github.com>
 <6N1wKps-M239ceVuAojyvUIc-HjAEhcMLhxB6-jlkwI=.fc4f560f-9e98-4688-98a2-187e4f3f8758@github.com>
 <tj562sC1hOPdzmo76ZkzZLJ__offyU-bl_aif14sb-U=.d5718dc9-c8dc-4776-a536-73f7d402fc9d@github.com>
 <PGfnSI2IP7zQ1B6p0c5uSaTvt7Tlk6PTFPAzA77HeVY=.af8c60d6-3110-48cc-bb46-285d00f6c790@github.com>
 <GnM5Sjf9eU2iN0uGez2fBxnhWxoiqKo4I59AJyyI_Qk=.39292947-803b-48d9-9be8-d3f0183b8515@github.com>
Message-ID: <rIdV-mFb6rAIiwC5kADLbOuYOyYssvM9nVYB5Lcllac=.80372f54-b0fa-40bb-a7a8-16c8c3129c7f@github.com>

On Thu, 6 Apr 2023 17:51:27 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> The interface access may be problematic: A non-exported interface Class object can be obtained via Reflection inspection on exported types, such as java packages and jdk.internal packages.
>>> 
>>>     * In that case, it might not be of best interest to create an interface, but I don't think the current asInterfaceInstance API rejects such creations either.
>> 
>> See the Javadoc: https://github.com/openjdk/jdk/pull/13197/files#diff-6de80127c851b1b0ba6b2ab0a739ffae803187028a721d4a28cd47fb17b1bbcdL64-L65
>> 
>> As this API was added in Java 7, `public` access was easy. W.R.T. modules, no changes have been made to this API.  
>> The (previously) underlying `java.lang.reflect.Proxy` does not even require that.
>> 
>> @liach  Can you please test calling `MethodHandleProxies.wrapperInstanceTarget(MethodHandleProxies.asInterfaceInstance(Runnable.class, MethodHandles.zero(void.class)))` **with an installed `SecurityManager`**?
>> Also with an interface in an untrusted protection domain, for example:
>> 
>> 
>> public interface Test {
>>     void run();
>>     public static void main(String[] args) {
>>         System.out.println(MethodHandleProxies.wrapperInstanceTarget(MethodHandleProxies.asInterfaceInstance(Test.class, MethodHandles.zero(void.class))));
>>     }
>> }
>> 
>> also with a `SecurityManager` (`-Djava.security.manager` as VM argument).
>
>> @DasBrain Thanks for the recommendation to test with SecurityManager, added a test and found two places that needs to do privileged indeed.
> 
> What operations require the security permission check?   I suspect some doPrivileged may be missing in the ClassFile API implementation.

Also, @mlchung Mandy, where would jtreg place the dumped class files with the new class file dumper? I didn't find it within test-support directory.

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

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

From mchung at openjdk.org  Thu Apr  6 18:12:25 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 6 Apr 2023 18:12:25 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v7]
In-Reply-To: <0taty5KKs0mKI7Fh6Gt11ySMUTl940RvQxqTkDv-sxM=.056b2f7e-c326-4a2d-b8dd-86c72bde50bc@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <0taty5KKs0mKI7Fh6Gt11ySMUTl940RvQxqTkDv-sxM=.056b2f7e-c326-4a2d-b8dd-86c72bde50bc@github.com>
Message-ID: <oN1aXF2fd7e53cXJTY2nWW-AsZtHSqn0YhvRuYx3tqo=.e610f687-b010-4b0c-91dc-94a5fe6f89fa@github.com>

On Thu, 6 Apr 2023 17:18:22 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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Nuke WrapperInstance
>  - Merge branch 'master' into explore/mhp-iface
>  - Whitespace, cleanup, rename benchmarks to be informative
>  - Address review comments
>    
>    Make sure it runs with SecurityManager
>    Split the benchmarks
>  - Use a dumper for interface instances, other cleanup
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - Remove unused JavaLangReflectReflectAccess.invokeDefault
>  - rethrow error
>  - Benchmark compareing to lamda metafactory, various minor updates
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/d7a90082...3fe36fd6

If you run the test with the system property on, it's dumped in the scratch directory.   Do you run with jtreg command?

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

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

From liach at openjdk.org  Thu Apr  6 18:12:28 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Apr 2023 18:12:28 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v6]
In-Reply-To: <Swz5eBbc2tMlcL40MflnzQwBu4k56I1iDE3Hc-M42r0=.7a749b37-39c1-4e57-9cbb-24ee4c1cb0a0@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@github.com>
 <Swz5eBbc2tMlcL40MflnzQwBu4k56I1iDE3Hc-M42r0=.7a749b37-39c1-4e57-9cbb-24ee4c1cb0a0@github.com>
Message-ID: <s2TMEhiNrSYth0nxwhJMDun_zb1V-IixnBZexhnSQ5o=.11d80f7b-f30f-4507-b168-ee190a1fc03f@github.com>

On Thu, 6 Apr 2023 17:08:33 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Whitespace, cleanup, rename benchmarks to be informative
>
> test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesAsIFInstanceCall.java line 176:
> 
>> 174:     public void constantLambda() {
>> 175:         i = constantLambda.doWork(i);
>> 176:     }
> 
> I think setting the result into an instance field like this can work, but it's imo better to let JMH handle it. So, these methods should just return the value instead of writing it to the `i` field.

I think the point here is to make sure work is done by ensuring the VM cannot figure out the input value to doWork, isn't it? To make that more clear, I decide to initialize i to a random value from identity hash code instead.

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

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

From jvernee at openjdk.org  Thu Apr  6 18:12:28 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Apr 2023 18:12:28 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v6]
In-Reply-To: <s2TMEhiNrSYth0nxwhJMDun_zb1V-IixnBZexhnSQ5o=.11d80f7b-f30f-4507-b168-ee190a1fc03f@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@github.com>
 <Swz5eBbc2tMlcL40MflnzQwBu4k56I1iDE3Hc-M42r0=.7a749b37-39c1-4e57-9cbb-24ee4c1cb0a0@github.com>
 <s2TMEhiNrSYth0nxwhJMDun_zb1V-IixnBZexhnSQ5o=.11d80f7b-f30f-4507-b168-ee190a1fc03f@github.com>
Message-ID: <4hiCptOAeAEDzW42E7J5Cim7s_1UfXiQA2HFiwk3aRE=.090244d2-19ba-4c0c-a660-5dfab6883386@github.com>

On Thu, 6 Apr 2023 18:03:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesAsIFInstanceCall.java line 176:
>> 
>>> 174:     public void constantLambda() {
>>> 175:         i = constantLambda.doWork(i);
>>> 176:     }
>> 
>> I think setting the result into an instance field like this can work, but it's imo better to let JMH handle it. So, these methods should just return the value instead of writing it to the `i` field.
>
> I think the point here is to make sure work is done by ensuring the VM cannot figure out the input value to doWork, isn't it? To make that more clear, I decide to initialize i to a random value from identity hash code instead.

That too. But I'm talking about the value that is assigned to the field after calling `doWork`. That value should be 'consumed' as well. IMO it's better to do that the conventional way, by returning the value (or using a Blackhole). i.e. let JMH handle it. (IIRC writing the value to a field like this has some issue with it as well)

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

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

From mchung at openjdk.org  Thu Apr  6 18:17:11 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 6 Apr 2023 18:17:11 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: <PnDi7l7gLXLUQwf0V_pyF-tFLajRwtPoXks4lyvYP9o=.e1c7fea3-d1a8-43e3-8bc5-82ea807f98aa@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <Mx7AH0tqNK0e10MkIi9BZm7hVuL5qXvhdtY8i0BiPE4=.f3329822-11a8-498d-9fac-fc1df82090f0@github.com>
 <6N1wKps-M239ceVuAojyvUIc-HjAEhcMLhxB6-jlkwI=.fc4f560f-9e98-4688-98a2-187e4f3f8758@github.com>
 <tj562sC1hOPdzmo76ZkzZLJ__offyU-bl_aif14sb-U=.d5718dc9-c8dc-4776-a536-73f7d402fc9d@github.com>
 <PGfnSI2IP7zQ1B6p0c5uSaTvt7Tlk6PTFPAzA77HeVY=.af8c60d6-3110-48cc-bb46-285d00f6c790@github.com>
 <PnDi7l7gLXLUQwf0V_pyF-tFLajRwtPoXks4lyvYP9o=.e1c7fea3-d1a8-43e3-8bc5-82ea807f98aa@github.com>
Message-ID: <Zdb6wAFkeZYfbj-mFc9q-d4IIhK5taczlPd4Af76Kms=.0ec0cff5-444f-4710-8be2-202cfec85302@github.com>

On Thu, 6 Apr 2023 18:04:49 GMT, Chen Liang <liach at openjdk.org> wrote:

> It appears the default class hierarchy resolver cannot be used to generates stack maps with only the FilePermission required by JTReg granted.

what permission does it need?

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

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

From liach at openjdk.org  Thu Apr  6 18:33:29 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Apr 2023 18:33:29 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v8]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <mMStVRzaAZtfXG5a5gfo-4DZCMysHuYXr81MZDRuTGs=.bda91a0e-956c-4dba-b21f-b62190dd3db2@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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
> 
> [^1]: single abstract method

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

  pass interface info via condy,
  drop explicit ea flags
  initialize benchmark work variable randomly
  benchmarks just need 1 fork

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/3fe36fd6..ab3ad41a

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

  Stats: 57 lines in 6 files changed: 6 ins; 28 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/13197.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13197/head:pull/13197

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

From liach at openjdk.org  Thu Apr  6 18:33:30 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Apr 2023 18:33:30 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v7]
In-Reply-To: <oN1aXF2fd7e53cXJTY2nWW-AsZtHSqn0YhvRuYx3tqo=.e610f687-b010-4b0c-91dc-94a5fe6f89fa@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <0taty5KKs0mKI7Fh6Gt11ySMUTl940RvQxqTkDv-sxM=.056b2f7e-c326-4a2d-b8dd-86c72bde50bc@github.com>
 <oN1aXF2fd7e53cXJTY2nWW-AsZtHSqn0YhvRuYx3tqo=.e610f687-b010-4b0c-91dc-94a5fe6f89fa@github.com>
Message-ID: <7JyzZAo5id42t1kuEOum-WLqeJBT96oL5ns6705yUI0=.36bb8780-0244-4ab5-a751-8188ce16f0e6@github.com>

On Thu, 6 Apr 2023 18:09:33 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> If you run the test with the system property on, it's dumped in the scratch directory. Do you run with jtreg command?

I ran with `make test TEST="test/jdk/java/lang/invoke/MethodHandleProxies"`. The scratch's subdirectories (corresponding to processors) are all empty.



> > It appears the default class hierarchy resolver cannot be used to generates stack maps with only the FilePermission required by JTReg granted.
> 
> what permission does it need?

It didn't explicitly fail with a security exception; the test fails with such a stacktrace:

java.lang.IllegalArgumentException: Could not resolve class RuntimeException
        at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:59)
        at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:69)
        at java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1360)
        at java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeFrom(StackMapGenerator.java:1328)
        at java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.merge(StackMapGenerator.java:1191)
        at java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.checkAssignableTo(StackMapGenerator.java:1141)
        at java.base/jdk.internal.classfile.impl.StackMapGenerator.checkJumpTarget(StackMapGenerator.java:263)
        at java.base/jdk.internal.classfile.impl.StackMapGenerator.processExceptionHandlerTargets(StackMapGenerator.java:659)
        at java.base/jdk.internal.classfile.impl.StackMapGenerator.processBlock(StackMapGenerator.java:645)
        at java.base/jdk.internal.classfile.impl.StackMapGenerator.processMethod(StackMapGenerator.java:420)
        at java.base/jdk.internal.classfile.impl.StackMapGenerator.generate(StackMapGenerator.java:293)
        at java.base/jdk.internal.classfile.impl.StackMapGenerator.<init>(StackMapGenerator.java:232)
        at java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.writeBody(DirectCodeBuilder.java:333)
        at java.base/jdk.internal.classfile.impl.UnboundAttribute$AdHocAttribute.writeTo(UnboundAttribute.java:914)
        at java.base/jdk.internal.classfile.impl.AttributeHolder.writeTo(AttributeHolder.java:56)
        at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.writeTo(DirectMethodBuilder.java:136)
        at java.base/jdk.internal.classfile.impl.BufWriterImpl.writeList(BufWriterImpl.java:194)
        at java.base/jdk.internal.classfile.impl.DirectClassBuilder.build(DirectClassBuilder.java:176)
        at java.base/jdk.internal.classfile.Classfile.build(Classfile.java:218)
        at java.base/jdk.internal.classfile.Classfile.build(Classfile.java:200)
        at java.base/jdk.internal.classfile.Classfile.build(Classfile.java:186)
        at java.base/java.lang.invoke.MethodHandleProxies.createTemplate(MethodHandleProxies.java:297)
        at java.base/java.lang.invoke.MethodHandleProxies$1.computeValue(MethodHandleProxies.java:260)
        at java.base/java.lang.invoke.MethodHandleProxies$1.computeValue(MethodHandleProxies.java:229)
        at java.base/java.lang.ClassValue.getFromHashMap(ClassValue.java:229)
        at java.base/java.lang.ClassValue.getFromBackup(ClassValue.java:211)
        at java.base/java.lang.ClassValue.get(ClassValue.java:117)
        at java.base/java.lang.invoke.MethodHandleProxies.asInterfaceInstance(MethodHandleProxies.java:195)
        at WithSecurityManagerTest.main(WithSecurityManagerTest.java:38)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:578)
        at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
        at java.base/java.lang.Thread.run(Thread.java:1630)

Think it relates to the behavior of `ClassLoader.getSystemResourceAsStream`.

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

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

From alanb at openjdk.org  Thu Apr  6 18:47:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Apr 2023 18:47:21 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v5]
In-Reply-To: <RNCT_0qrYIiGhIqeW400LQizY12I8E3KUfh7miWaPCs=.97b3db84-d3f1-4d8f-bb16-b4230e4da670@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <RNCT_0qrYIiGhIqeW400LQizY12I8E3KUfh7miWaPCs=.97b3db84-d3f1-4d8f-bb16-b4230e4da670@github.com>
Message-ID: <pXO1Amr7Pdib4u5KY4MJ_u7k72PpfbXy8-mKbjD7erw=.d2e7b6c5-8e98-47c1-af92-dca2b4fb7d83@github.com>

On Thu, 6 Apr 2023 17:17:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to Foreign API to avoid class with another PR
>   Rename S390X to S390, representing just the s390 architecture
>   Removed ARM and IA64 enum values; they are unused; they can be added later if needed

src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java line 51:

> 49:             !Architecture.isAARCH64()) {
> 50:             throw new RuntimeException(
> 51:                 "This provider is not supported on this processor architecture: " + Architecture.current());

Could this constructor be changed to be a no-op? The check for Windows 9 and Windows Me dates back to JDK 6 and is no longer needed. The os.arch check also dates from JDK 6 when the  attach provider didn't work on IA64 The only Windows builds now are windows-x86, windows-x64, windows-aarch64 so I assume this check can go away.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160140379

From rriggs at openjdk.org  Thu Apr  6 19:06:16 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 19:06:16 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v6]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <rg324NqOtoFCh3AhKz2rWKjq45ShY5Kk17RdHGGtiZU=.df9e078c-052c-4485-9e19-3d6734ebc873@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Remove obsolete conditions in Windows AttachProviderImpl.
  All platforms and architectures that can be built support attach.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/105ce605..ab084c27

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

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

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

From forax at openjdk.org  Thu Apr  6 19:06:14 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 6 Apr 2023 19:06:14 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v8]
In-Reply-To: <mMStVRzaAZtfXG5a5gfo-4DZCMysHuYXr81MZDRuTGs=.bda91a0e-956c-4dba-b21f-b62190dd3db2@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <mMStVRzaAZtfXG5a5gfo-4DZCMysHuYXr81MZDRuTGs=.bda91a0e-956c-4dba-b21f-b62190dd3db2@github.com>
Message-ID: <2ENhOI1fg1a24ypghjkvGc_W3qORab_K-p8lv1cRKMA=.c16e1c96-56c6-4f70-9276-322cbb9e044f@github.com>

On Thu, 6 Apr 2023 18:33:29 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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pass interface info via condy,
>   drop explicit ea flags
>   initialize benchmark work variable randomly
>   benchmarks just need 1 fork

It's the Classfile API that is not able to generate stack map information.
The class should be "java/lang/RuntimeException" not "RuntimeException" (apart if the class name is truncated/simplified).

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

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

From rriggs at openjdk.org  Thu Apr  6 19:06:20 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 19:06:20 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v5]
In-Reply-To: <pXO1Amr7Pdib4u5KY4MJ_u7k72PpfbXy8-mKbjD7erw=.d2e7b6c5-8e98-47c1-af92-dca2b4fb7d83@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <RNCT_0qrYIiGhIqeW400LQizY12I8E3KUfh7miWaPCs=.97b3db84-d3f1-4d8f-bb16-b4230e4da670@github.com>
 <pXO1Amr7Pdib4u5KY4MJ_u7k72PpfbXy8-mKbjD7erw=.d2e7b6c5-8e98-47c1-af92-dca2b4fb7d83@github.com>
Message-ID: <4mLFbdHUYtZRYFFi_s9YffxJOeVcMjU_TsIgVn7hUbM=.34d74c76-68dd-4ad3-ae8d-4906756aa438@github.com>

On Thu, 6 Apr 2023 18:44:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes to Foreign API to avoid class with another PR
>>   Rename S390X to S390, representing just the s390 architecture
>>   Removed ARM and IA64 enum values; they are unused; they can be added later if needed
>
> src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java line 51:
> 
>> 49:             !Architecture.isAARCH64()) {
>> 50:             throw new RuntimeException(
>> 51:                 "This provider is not supported on this processor architecture: " + Architecture.current());
> 
> Could this constructor be changed to be a no-op? The check for Windows 9 and Windows Me dates back to JDK 6 and is no longer needed. The os.arch check also dates from JDK 6 when the  attach provider didn't work on IA64 The only Windows builds now are windows-x86, windows-x64, windows-aarch64 so I assume this check can go away.

Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160154277

From alanb at openjdk.org  Thu Apr  6 19:15:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Apr 2023 19:15:18 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v5]
In-Reply-To: <4mLFbdHUYtZRYFFi_s9YffxJOeVcMjU_TsIgVn7hUbM=.34d74c76-68dd-4ad3-ae8d-4906756aa438@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <RNCT_0qrYIiGhIqeW400LQizY12I8E3KUfh7miWaPCs=.97b3db84-d3f1-4d8f-bb16-b4230e4da670@github.com>
 <pXO1Amr7Pdib4u5KY4MJ_u7k72PpfbXy8-mKbjD7erw=.d2e7b6c5-8e98-47c1-af92-dca2b4fb7d83@github.com>
 <4mLFbdHUYtZRYFFi_s9YffxJOeVcMjU_TsIgVn7hUbM=.34d74c76-68dd-4ad3-ae8d-4906756aa438@github.com>
Message-ID: <y48cQRq1AcsvBI3l28dcA4KbXtayFp-vQONNKNONu2Q=.d525a706-aaad-4a30-9676-2065e816df91@github.com>

On Thu, 6 Apr 2023 19:01:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Removed.

Good, that makes it simpler and it means the qualified export can be removed too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160162760

From rriggs at openjdk.org  Thu Apr  6 19:25:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 19:25:19 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Remove unneeded qualified export from java.base to jdk.attach

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/ab084c27..52ca4a70

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

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

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

From mchung at openjdk.org  Thu Apr  6 19:26:15 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 6 Apr 2023 19:26:15 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v8]
In-Reply-To: <mMStVRzaAZtfXG5a5gfo-4DZCMysHuYXr81MZDRuTGs=.bda91a0e-956c-4dba-b21f-b62190dd3db2@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <mMStVRzaAZtfXG5a5gfo-4DZCMysHuYXr81MZDRuTGs=.bda91a0e-956c-4dba-b21f-b62190dd3db2@github.com>
Message-ID: <gaLNCImAF5D9p_3dg-oKd-fmwOuPfzCG5XZR5nrHIJk=.4248ea55-87c9-4479-bf56-95b8e0587962@github.com>

On Thu, 6 Apr 2023 18:33:29 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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pass interface info via condy,
>   drop explicit ea flags
>   initialize benchmark work variable randomly
>   benchmarks just need 1 fork

This is good work.    This needs some careful study on the security aspect.  I see the proxy class is in the same module of the interface, is non-public, and it has a no-arg non-public constructor. 

Defining the proxy class in the same module would grant this class reflective access to any class in this module.  This seems a concern if the target method handle should not have access to the class in that module.

W.r.t. the no-arg constructor,  I would consider another level of defense to make the constructor to take `Lookup` of itself and throw an IAE if the lookup class is not itself or it does not have `ORIGINAL` access.

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

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

From alanb at openjdk.org  Thu Apr  6 19:31:17 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Apr 2023 19:31:17 GMT
Subject: RFR: 8303923: ZipOutStream::putEntry should include an apiNote to
 indicate that the STORED compression method should be used when
 writing directory entries [v3]
In-Reply-To: <fpQplW3xmjNOyr6EEDqQVu3cSsTBxbh2dNnn44XAoLo=.9333a0cb-a7ba-4d08-ae15-4984b872e7fb@github.com>
References: <MxdaGLimDdbjNWSyo6yfkpt0KjEn1WTulCzSPmhWtyQ=.96687fb2-6334-4240-ae83-fc3d6cfe613a@github.com>
 <fpQplW3xmjNOyr6EEDqQVu3cSsTBxbh2dNnn44XAoLo=.9333a0cb-a7ba-4d08-ae15-4984b872e7fb@github.com>
Message-ID: <-Bx8sLknaK1GkPeGxxI5LVSMMTHO2CxsPgXYb1pQgQw=.5a9233d3-f954-4f3d-97a9-50465d8a89c0@github.com>

On Sun, 19 Mar 2023 14:50:41 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> ZipOutputStream currently writes directory entries using the DEFLATED compression method. This does not strictly comply with the APPNOTE.TXT specification and is also about 10x slower than using the STORED compression method.
>> 
>> Because of these concerns, `ZipOutputStream.putNextEntry` should be updated with an `@apiNote` recommending
>> the use of the STORED compression method for directory entries.
>> 
>> Suggested CSR in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove speculation that using DEFLATED for directory entries is not in strict compliance with APPNOTE.txt

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/12899#pullrequestreview-1375448942

From jkuhn at openjdk.org  Thu Apr  6 19:37:19 2023
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Thu, 6 Apr 2023 19:37:19 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v8]
In-Reply-To: <gaLNCImAF5D9p_3dg-oKd-fmwOuPfzCG5XZR5nrHIJk=.4248ea55-87c9-4479-bf56-95b8e0587962@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <mMStVRzaAZtfXG5a5gfo-4DZCMysHuYXr81MZDRuTGs=.bda91a0e-956c-4dba-b21f-b62190dd3db2@github.com>
 <gaLNCImAF5D9p_3dg-oKd-fmwOuPfzCG5XZR5nrHIJk=.4248ea55-87c9-4479-bf56-95b8e0587962@github.com>
Message-ID: <AxIHVvKaa0GEKnEEap7XdeOrbx108pfazC3yu_uUGEU=.64918012-1a0e-4a7c-9028-5dfc5d485df5@github.com>

On Thu, 6 Apr 2023 19:22:56 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This seems a concern if the target method handle should not have access to the class in that module.

MethodHandle access is checked when the MethodHandle is created.  
For `@CallerSensitive` methods, the MethodHandle is additionally bound to the lookup class.  
Also see [`java.lang.invoke.ConstantBootstraps.invoke`](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/ConstantBootstraps.html#invoke%28java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.Class,java.lang.invoke.MethodHandle,java.lang.Object...%29). If calling an arbitrary MethodHandle from a module could be a problem, then that is an easier target.

> W.r.t. the no-arg constructor, I would consider another level of defense to make the constructor to take Lookup of itself and throw an IAE if the lookup class is not itself or it does not have ORIGINAL access.

Without that defense you can create a new instance (if you have a reference to the hidden class) that does exactly the same thing as the original instance.  
Other than `getClass` on the original object, `StackWalker` comes to mind as a way to obtain the class reference.

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

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

From mchung at openjdk.org  Thu Apr  6 19:41:20 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 6 Apr 2023 19:41:20 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v8]
In-Reply-To: <mMStVRzaAZtfXG5a5gfo-4DZCMysHuYXr81MZDRuTGs=.bda91a0e-956c-4dba-b21f-b62190dd3db2@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <mMStVRzaAZtfXG5a5gfo-4DZCMysHuYXr81MZDRuTGs=.bda91a0e-956c-4dba-b21f-b62190dd3db2@github.com>
Message-ID: <iMtmXC9L8ev0sLKw7UOgguSOzEQCDdDPUIaXXdbr5Gc=.dc6ee88d-43fd-4a7e-b96f-eed74927affc@github.com>

On Thu, 6 Apr 2023 18:33:29 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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pass interface info via condy,
>   drop explicit ea flags
>   initialize benchmark work variable randomly
>   benchmarks just need 1 fork

Note that the current implementation uses the thread's context class loader or system class loader if the interface is defined by null loader.   This PR changes it to use the defining class loader of the  interface.

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

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

From duke at openjdk.org  Thu Apr  6 19:58:21 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 6 Apr 2023 19:58:21 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
Message-ID: <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>

On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded qualified export from java.base to jdk.attach

src/java.base/share/classes/jdk/internal/util/Architecture.java line 100:

> 98:      */
> 99:     public static Architecture current() {
> 100:         return archValues[OperatingSystemProps.CURRENT_ARCH_ORDINAL];

I think the `Architecture ` is different from the `OperatingSystem`. There are ports of [other architectures](https://github.com/openjdk/jdk/blob/1d517afbd4547171ad6fb6a3356351c2554c8279/make/autoconf/platform.m4#L33-L188) (Including `MIPS64el`, `LoongArch64`, `SPARC v9`, etc) in the upstream.

Will hard coding architectures destroy these ports? Should a "OTHER" or "UNKNOWN" entry be added  to the enum to represent other architectures that are not of concern?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160193842

From jvernee at openjdk.org  Thu Apr  6 20:07:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Apr 2023 20:07:21 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v7]
In-Reply-To: <7JyzZAo5id42t1kuEOum-WLqeJBT96oL5ns6705yUI0=.36bb8780-0244-4ab5-a751-8188ce16f0e6@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <0taty5KKs0mKI7Fh6Gt11ySMUTl940RvQxqTkDv-sxM=.056b2f7e-c326-4a2d-b8dd-86c72bde50bc@github.com>
 <oN1aXF2fd7e53cXJTY2nWW-AsZtHSqn0YhvRuYx3tqo=.e610f687-b010-4b0c-91dc-94a5fe6f89fa@github.com>
 <7JyzZAo5id42t1kuEOum-WLqeJBT96oL5ns6705yUI0=.36bb8780-0244-4ab5-a751-8188ce16f0e6@github.com>
Message-ID: <CRmke7OFdsT0l5zkw9FpQWaWtTRNM8nKqcbi28mBOUI=.4d2c6517-c062-4059-8df0-90642a549ce3@github.com>

On Thu, 6 Apr 2023 18:27:33 GMT, Chen Liang <liach at openjdk.org> wrote:

> I ran with make test TEST="test/jdk/java/lang/invoke/MethodHandleProxies". The scratch's subdirectories (corresponding to processors) are all empty.

The contents of the scratch directory is only saved if the test fails. Maybe it's not that useful to always run the test with class dumping enabled. If the test ever fails, it could also be re-run with dumping enabled.

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

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

From rriggs at openjdk.org  Thu Apr  6 20:27:22 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 20:27:22 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>
Message-ID: <VnW1VBWQ9sLchqOACSMh0gUQG1cvQDJaSW3g_MPHnqo=.47697356-aabb-4d33-b4bf-df12bd3b15b3@github.com>

On Thu, 6 Apr 2023 19:55:07 GMT, Glavo <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unneeded qualified export from java.base to jdk.attach
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 100:
> 
>> 98:      */
>> 99:     public static Architecture current() {
>> 100:         return archValues[OperatingSystemProps.CURRENT_ARCH_ORDINAL];
> 
> I think the `Architecture ` is different from the `OperatingSystem`. There are ports of [other architectures](https://github.com/openjdk/jdk/blob/1d517afbd4547171ad6fb6a3356351c2554c8279/make/autoconf/platform.m4#L33-L188) (Including `MIPS64el`, `LoongArch64`, `SPARC v9`, etc) in the upstream.
> 
> Will hard coding architectures destroy these ports? Should a "OTHER" or "UNKNOWN" entry be added  to the enum to represent other architectures that are not of concern?

There is no benefit to preemptively defining a full set of architectures; we only need those that are used in the OpenJDK runtime selection of options or parameters.
The other and unknown cases can be handled in code using switch as `default` or for `if (xx) {} else {...}` in the else clause.
Ports not supported the OpenJDK can add enum values and the corresponding static `isXXX()` methods if needed.

The template file used in the implementation could be renamed to be more agnostic to OS or arch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160226259

From stuefe at openjdk.org  Thu Apr  6 20:31:21 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 6 Apr 2023 20:31:21 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
Message-ID: <z8EuL6vvnVdCVsR68uEbPMFxyCabYlTLxrgh-xRzEj0=.619c4a4b-1bb0-44d5-88cf-50b801c4049d@github.com>

On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded qualified export from java.base to jdk.attach

What about PPC (big endian)? Used on AIX? 

On Arm, it may be useful to know whether we built for thumb mode (We recently had this problem in tests).

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1499585079

From duke at openjdk.org  Thu Apr  6 20:32:19 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 6 Apr 2023 20:32:19 GMT
Subject: RFR: 8303923: ZipOutStream::putEntry should include an apiNote to
 indicate that the STORED compression method should be used when
 writing directory entries [v3]
In-Reply-To: <fpQplW3xmjNOyr6EEDqQVu3cSsTBxbh2dNnn44XAoLo=.9333a0cb-a7ba-4d08-ae15-4984b872e7fb@github.com>
References: <MxdaGLimDdbjNWSyo6yfkpt0KjEn1WTulCzSPmhWtyQ=.96687fb2-6334-4240-ae83-fc3d6cfe613a@github.com>
 <fpQplW3xmjNOyr6EEDqQVu3cSsTBxbh2dNnn44XAoLo=.9333a0cb-a7ba-4d08-ae15-4984b872e7fb@github.com>
Message-ID: <zTqdR1tf3ONETxAjdAZ2iYGRfKIt9LiinFZqTXtJ44M=.82339b76-f8b0-4201-8627-f16f03499920@github.com>

On Sun, 19 Mar 2023 14:50:41 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> ZipOutputStream currently writes directory entries using the DEFLATED compression method. This does not strictly comply with the APPNOTE.TXT specification and is also about 10x slower than using the STORED compression method.
>> 
>> Because of these concerns, `ZipOutputStream.putNextEntry` should be updated with an `@apiNote` recommending
>> the use of the STORED compression method for directory entries.
>> 
>> Suggested CSR in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove speculation that using DEFLATED for directory entries is not in strict compliance with APPNOTE.txt

I moved the CSR for this PR into the Proposed state. The CSR is now looking for reviewers.

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

PR Comment: https://git.openjdk.org/jdk/pull/12899#issuecomment-1499585675

From stuefe at openjdk.org  Thu Apr  6 20:42:18 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 6 Apr 2023 20:42:18 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
Message-ID: <MKuFpznU5E4HZbE1eLsTk9EGJvH5AvrBpDDrVVvMQz0=.9d894a93-b4bf-4e84-9178-6cf2b08e0049@github.com>

On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded qualified export from java.base to jdk.attach

Another question, how does this work with Zero?

I know e.g. Debian maintains a broad range of Zero JVMs on different target CPUs. Things like ia64 and parisc. What is the os.arch value on those, and how will this work with the limited set of enums we replace it with?

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1499594972

From rriggs at openjdk.org  Thu Apr  6 20:42:20 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 20:42:20 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <z8EuL6vvnVdCVsR68uEbPMFxyCabYlTLxrgh-xRzEj0=.619c4a4b-1bb0-44d5-88cf-50b801c4049d@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <z8EuL6vvnVdCVsR68uEbPMFxyCabYlTLxrgh-xRzEj0=.619c4a4b-1bb0-44d5-88cf-50b801c4049d@github.com>
Message-ID: <nc_w6DjozGQhwsm1-vZr-xgc0tV1HPheuWyA0QAo0CA=.f4b271b0-b08e-47a1-8353-12fe26707d8a@github.com>

On Thu, 6 Apr 2023 20:28:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> What about PPC (big endian)? Used on AIX?

I'm not aware of any code (in OpenJDK) related to big/little endian that is derived from `os.arch`.

> 
> On Arm, it may be useful to know whether we built for thumb mode (We recently had this problem in tests).

For tests, there is the test library `jdk.test.lib.Platform` class with its own set of predicates.

For the moment, the idea is to do the minimum to replace OpenJDK internal uses of `os.arch`.

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1499597036

From duke at openjdk.org  Thu Apr  6 20:45:21 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 6 Apr 2023 20:45:21 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <VnW1VBWQ9sLchqOACSMh0gUQG1cvQDJaSW3g_MPHnqo=.47697356-aabb-4d33-b4bf-df12bd3b15b3@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>
 <VnW1VBWQ9sLchqOACSMh0gUQG1cvQDJaSW3g_MPHnqo=.47697356-aabb-4d33-b4bf-df12bd3b15b3@github.com>
Message-ID: <IWrvXb5j8yccPrUMpMHD63ddaA_7zKQBtkcRlnA--VU=.39f6fc2d-2614-4b2c-9f53-b7c7567648e2@github.com>

On Thu, 6 Apr 2023 20:24:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/Architecture.java line 100:
>> 
>>> 98:      */
>>> 99:     public static Architecture current() {
>>> 100:         return archValues[OperatingSystemProps.CURRENT_ARCH_ORDINAL];
>> 
>> I think the `Architecture ` is different from the `OperatingSystem`. There are ports of [other architectures](https://github.com/openjdk/jdk/blob/1d517afbd4547171ad6fb6a3356351c2554c8279/make/autoconf/platform.m4#L33-L188) (Including `MIPS64el`, `LoongArch64`, `SPARC v9`, etc) in the upstream.
>> 
>> Will hard coding architectures destroy these ports? Should a "OTHER" or "UNKNOWN" entry be added  to the enum to represent other architectures that are not of concern?
>
> There is no benefit to preemptively defining a full set of architectures; we only need those that are used in the OpenJDK runtime selection of options or parameters.
> The other and unknown cases can be handled in code using switch as `default` or for `if (xx) {} else {...}` in the else clause.
> Ports not supported the OpenJDK can add enum values and the corresponding static `isXXX()` methods if needed.
> 
> The template file used in the implementation could be renamed to be more agnostic to OS or arch.

I understand that there is no need to define enum entries for all architectures now, but the `current` method seems to cause crashes on other platforms. 

Even worse, `OperatingSystemProps` seems to be unable to compile on other architectures at all:

https://github.com/openjdk/jdk/blob/52ca4a70fc3de9e285964f9545ea8cd54e2d9924/src/java.base/share/classes/jdk/internal/util/OperatingSystemProps.java.template#L40

Does `Architecture` really need to be implemented as an enum? The value of this enum has never been used in this PR except for testing. I think perhaps just providing the isXXX methods is enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160242246

From liach at openjdk.org  Thu Apr  6 20:47:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Apr 2023 20:47:10 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v9]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <-TIa9k1sR_2QUcm_ebyVk54FuDJS4OxaxPuoOGOYmyE=.372021a2-ff5c-4726-a040-598cff334dae@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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
> 
> [^1]: single abstract method

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

  Require an original lookup in constructor arguments to prevent unintended instantiation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/ab3ad41a..2401dc94

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

  Stats: 63 lines in 3 files changed: 56 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13197.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13197/head:pull/13197

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

From liach at openjdk.org  Thu Apr  6 20:51:23 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Apr 2023 20:51:23 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v9]
In-Reply-To: <-TIa9k1sR_2QUcm_ebyVk54FuDJS4OxaxPuoOGOYmyE=.372021a2-ff5c-4726-a040-598cff334dae@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <-TIa9k1sR_2QUcm_ebyVk54FuDJS4OxaxPuoOGOYmyE=.372021a2-ff5c-4726-a040-598cff334dae@github.com>
Message-ID: <1-FVClq0cCFU_BTg1EE5ppKZUp4vGRMPUI9sgnJVRr8=.e7876da5-9dcc-45b7-8bf1-7c7478caa851@github.com>

On Thu, 6 Apr 2023 20:47:10 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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Require an original lookup in constructor arguments to prevent unintended instantiation

I will keep that flag in tests, as otherwise the existence of this dumping feature may not be immediately obvious to investigators.

I have implemented defense against a full privilege lookup creating instances of the wrapper with a test case.

For the changed loader, my rationale was that all classes involved in the spinning of the wrapper should be already visible to the interface's loader, and should be safe as the target method handle itself doesn't have any knowledge of the wrapper class; does it affect weak hidden class behavior to any extent?

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

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

From rriggs at openjdk.org  Thu Apr  6 20:53:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 20:53:18 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <MKuFpznU5E4HZbE1eLsTk9EGJvH5AvrBpDDrVVvMQz0=.9d894a93-b4bf-4e84-9178-6cf2b08e0049@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <MKuFpznU5E4HZbE1eLsTk9EGJvH5AvrBpDDrVVvMQz0=.9d894a93-b4bf-4e84-9178-6cf2b08e0049@github.com>
Message-ID: <uvmDQLXP0-JK7qjEGK80qRpwYD8G0b0MtEJBY6KEsKY=.31e25922-0f8e-4693-af7c-3d40dea07753@github.com>

On Thu, 6 Apr 2023 20:38:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Another question, how does this work with Zero?

Zero is orthogonal to architecture; the interpreter is compiled for a specific target architecture.

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1499606550

From rriggs at openjdk.org  Thu Apr  6 20:59:22 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 20:59:22 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <IWrvXb5j8yccPrUMpMHD63ddaA_7zKQBtkcRlnA--VU=.39f6fc2d-2614-4b2c-9f53-b7c7567648e2@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>
 <VnW1VBWQ9sLchqOACSMh0gUQG1cvQDJaSW3g_MPHnqo=.47697356-aabb-4d33-b4bf-df12bd3b15b3@github.com>
 <IWrvXb5j8yccPrUMpMHD63ddaA_7zKQBtkcRlnA--VU=.39f6fc2d-2614-4b2c-9f53-b7c7567648e2@github.com>
Message-ID: <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com>

On Thu, 6 Apr 2023 20:42:26 GMT, Glavo <duke at openjdk.org> wrote:

>> There is no benefit to preemptively defining a full set of architectures; we only need those that are used in the OpenJDK runtime selection of options or parameters.
>> The other and unknown cases can be handled in code using switch as `default` or for `if (xx) {} else {...}` in the else clause.
>> Ports not supported the OpenJDK can add enum values and the corresponding static `isXXX()` methods if needed.
>> 
>> The template file used in the implementation could be renamed to be more agnostic to OS or arch.
>
> I understand that there is no need to define enum entries for all architectures now, but the `current` method seems to cause crashes on other platforms. 
> 
> Even worse, `OperatingSystemProps` seems to be unable to compile on other architectures at all:
> 
> https://github.com/openjdk/jdk/blob/52ca4a70fc3de9e285964f9545ea8cd54e2d9924/src/java.base/share/classes/jdk/internal/util/OperatingSystemProps.java.template#L40
> 
> Does `Architecture` really need to be implemented as an enum? The value of this enum has never been used in this PR except for testing. I think perhaps just providing the isXXX methods is enough.

The point of Architecture is reflect the architecture as supported by the build and the runtime mutually and to reflect dependencies on the target hardware. 

What did you use as the example that would not compile on the other architecture?
Did you make the other changes to the build that would be needed for a new architecture?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160252604

From mchung at openjdk.org  Thu Apr  6 21:17:21 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 6 Apr 2023 21:17:21 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v9]
In-Reply-To: <-TIa9k1sR_2QUcm_ebyVk54FuDJS4OxaxPuoOGOYmyE=.372021a2-ff5c-4726-a040-598cff334dae@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <-TIa9k1sR_2QUcm_ebyVk54FuDJS4OxaxPuoOGOYmyE=.372021a2-ff5c-4726-a040-598cff334dae@github.com>
Message-ID: <c65OZGHuriJuhXohjEbdG5m8v4Uc1WqmrG4w90DP0xs=.38d7dc96-dd39-4594-b762-27872323bfb5@github.com>

On Thu, 6 Apr 2023 20:47:10 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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Require an original lookup in constructor arguments to prevent unintended instantiation

This needs a security assessment.   My first reaction should not use null loader to define the proxy class as there is a reason why it didn't use it in the first place (I have to dig up the history).

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

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

From jvernee at openjdk.org  Thu Apr  6 21:17:23 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Apr 2023 21:17:23 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v4]
In-Reply-To: <ASIxJa9wfdr8YvxQLZaD9sVuB_oR2GkWccMlHuzuj74=.c2479e31-0309-4f30-ab0b-a4e37906b36b@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <6hZzlgJtzWUJJupq0J2gRfeEvxD-wXkpsa2XcYvA0qM=.145bc6af-99b5-421a-940c-5198291764c8@github.com>
 <Y3D7vbAYx3qZJXYND4qNh4wDVRg84BUDOd_uZrQB_0A=.a7da1a97-b216-408f-ad6a-4da56fb2f77c@github.com>
 <ASIxJa9wfdr8YvxQLZaD9sVuB_oR2GkWccMlHuzuj74=.c2479e31-0309-4f30-ab0b-a4e37906b36b@github.com>
Message-ID: <_rGOoWBRA98FDLEMzV6jf5qqSzydgzyABj43pxNN5KA=.3ae023ab-3d9f-4634-8df5-55ef8596c0e9@github.com>

On Thu, 6 Apr 2023 17:56:23 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 213:
>> 
>>> 211:                     .defineClassAsLookup(true, List.of(mhs));
>>> 212:             proxy = lookup.findConstructor(lookup.lookupClass(), methodType(void.class))
>>> 213:                     .asType(methodType(Object.class)).invokeExact();
>> 
>> This can use `invoke` instead of an explicit `asType` and `invokeExact`. It is more or less the same.
>> Suggestion:
>> 
>>             proxy = lookup.findConstructor(lookup.lookupClass(), methodType(void.class)).invoke();
>
> @JornVernee Is there any performance difference with `invokeExact` vs `invoke`?   I have the impression there is.

It only matters when we get to C2 compilation for a constant method handle instance being called, which is not the case here. `invoke` is just a nice shorthand for doing an inexact call.

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

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

From duke at openjdk.org  Thu Apr  6 21:20:20 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 6 Apr 2023 21:20:20 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>
 <VnW1VBWQ9sLchqOACSMh0gUQG1cvQDJaSW3g_MPHnqo=.47697356-aabb-4d33-b4bf-df12bd3b15b3@github.com>
 <IWrvXb5j8yccPrUMpMHD63ddaA_7zKQBtkcRlnA--VU=.39f6fc2d-2614-4b2c-9f53-b7c7567648e2@github.com>
 <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com>
Message-ID: <3jNPX5xpKbZQ0Cz05qJHuDLRpx5SmhzOxIHCeERnDWg=.90260d1e-6d77-430c-b0dc-a83df36b1272@github.com>

On Thu, 6 Apr 2023 20:56:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> What did you use as the example that would not compile on the other architecture? 

https://github.com/openjdk/jdk/blob/52ca4a70fc3de9e285964f9545ea8cd54e2d9924/src/java.base/share/classes/jdk/internal/util/OperatingSystemProps.java.template#L40

I don't understand how the above code can be compiled on architectures such as LongArch64, MIPS64el, or ARM32 without modifying the source file.

> Did you make the other changes to the build that would be needed for a new architecture?

I'm not talking about the new architecture, I'm talking about the architecture that OpenJDK already supports. 

According to my understanding, the above code breaks the support of all architectures not listed in `Architecture`. But has `Architecture` really listed all the supported architectures in the OpenJDK mainline?

For example, I want to compile OpenJDK for 32-bit ARM.  I think in this PR, I cannot compile without modifying the source code because `TARGET_ARCH_arm` does not exist. But before this PR, I was able to compile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160266038

From rriggs at openjdk.org  Thu Apr  6 21:59:17 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 21:59:17 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern
In-Reply-To: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
Message-ID: <jz0_QYI2hm_HhVa09VDSt5CwssjqZN3wU_bealmsGQY=.cda1e9f1-aead-4fae-b2f8-d319328fc832@github.com>

On Mon, 3 Apr 2023 17:43:55 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.

src/java.base/share/classes/java/lang/String.java line 3129:

> 3127:      * <a href="../util/regex/Pattern.html#sum">regular expression</a>.
> 3128:      *
> 3129:      * <p> This method works as if by invoking the three-argument {@link

The descriptions should be mostly self contained, repeating/duplicating the test as necessary so it easier to read. In this case, there is no reason to change the existing method javadoc except perhaps to note the relationship to the new method. It will be obvious that the spec and behavior are not changing.

src/java.base/share/classes/java/lang/String.java line 3155:

> 3153:     /**
> 3154:      * Splits this string around matches of the given
> 3155:      * <a href="../util/regex/Pattern.html#sum">regular expression</a>.

When this sentence appears in the summary table of the class javadoc, it would be useful if there were a few words that set it apart from the adjacent split methods.

src/java.base/share/classes/java/lang/String.java line 3157:

> 3155:      * <a href="../util/regex/Pattern.html#sum">regular expression</a>.
> 3156:      *
> 3157:      * <p> When {@code withDelimiter} is {@code false},

I'd look for an brief but intuitive description of the difference between the two cases before diving into the details.
It might even be better to not expose the implementation with the true/false argument but have a separate `splitWithDelimiters` (name tbd) method that can avoid having to describe both cases.

I understand this something like:
   Splits this string around matches of the given regular expression and returns both the strings and the matching delimiters.

src/java.base/share/classes/java/lang/String.java line 3365:

> 3363:      * href="../util/regex/Pattern.html#sum">regular expression</a>.
> 3364:      *
> 3365:      * <p> This method works as if by invoking the three-argument {@link

Same here, keep the original javadoc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1160271658
PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1160275907
PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1160286341
PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1160272599

From duke at openjdk.org  Thu Apr  6 22:43:46 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 6 Apr 2023 22:43:46 GMT
Subject: RFR: 8291023: FileOutputStream.close() re-entrantly invokes itself
 after getChannel().force()
Message-ID: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>

IO stream classes like `FileOutputStream` can have assocated NIO channels.

When `close()` is invoked on one of these classes, it in turn invokes `close()` on the associated channel (if any). But when the associated channel's `close()` method is invoked, it in turn invokes `close()` on the associated stream (if any).

As a result, these IO stream `close()` methods invoke themselves reentrantly when there is an associated channel.

This is not a problem for these classes because they are written to handle this (i.e., they are idempotent), but it can be surprising (or worse, just silently bug-inducing) for subclasses that override `close()`.

There are two possible ways to address this:
1. Modify the code to detect and avoid the (unnecessary) reentrant invocations
2. Add a `@implNote` to the Javadoc so subclass implementers are made aware

This patch takes the second, more conservative approach.

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

Commit messages:
 - Add @implNote's regarding close() invoking itself reentrantly.

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

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

From prr at openjdk.org  Thu Apr  6 22:47:58 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 6 Apr 2023 22:47:58 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
Message-ID: <3iWq-g0ji56gRdTxUVtO64dy60rPmtQsQ_64HWoCMlY=.300723e5-d788-42f4-9d40-bb768390fc0b@github.com>

On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded qualified export from java.base to jdk.attach

src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java line 169:

> 167:         // Load the appropriate DLLs
> 168:         boolean is32on64 = false;
> 169:         if (Architecture.isX86()) {

This would be another coupling of java.desktop into java.base internals and I don't think it worth it.
Particularly because this check is obsolete !
It is a remnant of when accessbridge was an unbundled download so provided both 32 and 64 bit.
We don't even have  the file it is looking for in the build - even if someone did a 32 bit build.
Instead of making this change a bug should be filed to remove this code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160314934

From naoto at openjdk.org  Thu Apr  6 23:15:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Apr 2023 23:15:45 GMT
Subject: RFR: 6241286: (cal) API: Calendar.DAY_OF_WEEK definition is wrong
In-Reply-To: <Fe3PdyvyvFi_GNbxowh7Ps4ZhCLcqO2MEmiLD3bddyg=.8e8e6669-6549-49fe-93db-a837427c3515@github.com>
References: <Fe3PdyvyvFi_GNbxowh7Ps4ZhCLcqO2MEmiLD3bddyg=.8e8e6669-6549-49fe-93db-a837427c3515@github.com>
Message-ID: <ocyiBNq0sAqYa6y-6h0FqRElo4lRNuWS3YzN1HfOts0=.8671988d-fafd-468b-b509-e9b6e8da1d98@github.com>

On Mon, 3 Apr 2023 21:56:33 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR updates the Calendar.DAY_OF_WEEK documentation to make it clear that the field accepts _any_ value if the calendar is lenient and then normalizes it. Only if the calendar is non-lenient, will the field accept only one of SUNDAY ... SATURDAY.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13311#pullrequestreview-1375674071

From mchung at openjdk.org  Thu Apr  6 23:47:48 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 6 Apr 2023 23:47:48 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v9]
In-Reply-To: <-TIa9k1sR_2QUcm_ebyVk54FuDJS4OxaxPuoOGOYmyE=.372021a2-ff5c-4726-a040-598cff334dae@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <-TIa9k1sR_2QUcm_ebyVk54FuDJS4OxaxPuoOGOYmyE=.372021a2-ff5c-4726-a040-598cff334dae@github.com>
Message-ID: <pZUyVPlM9DRaJfUPCepjucKJDxjsurkznsZuX_qcOns=.f095c2c0-554e-4995-8c4d-a5a9223d3480@github.com>

On Thu, 6 Apr 2023 20:47:10 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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Require an original lookup in constructor arguments to prevent unintended instantiation

This PR is in open state but it seems to be under development.  Is it in a state asking for review or asking for discussion?    I started looking into it closely today but only realized now that the use of `WrapperInstance` was changed again.

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

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

From liach at openjdk.org  Fri Apr  7 00:14:49 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Apr 2023 00:14:49 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v8]
In-Reply-To: <AxIHVvKaa0GEKnEEap7XdeOrbx108pfazC3yu_uUGEU=.64918012-1a0e-4a7c-9028-5dfc5d485df5@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <mMStVRzaAZtfXG5a5gfo-4DZCMysHuYXr81MZDRuTGs=.bda91a0e-956c-4dba-b21f-b62190dd3db2@github.com>
 <gaLNCImAF5D9p_3dg-oKd-fmwOuPfzCG5XZR5nrHIJk=.4248ea55-87c9-4479-bf56-95b8e0587962@github.com>
 <AxIHVvKaa0GEKnEEap7XdeOrbx108pfazC3yu_uUGEU=.64918012-1a0e-4a7c-9028-5dfc5d485df5@github.com>
Message-ID: <CPOnK9Q4YpWAqQ0QAEclpqEH1AZYtQijNZvkxZBBV98=.d41cc6e4-1a29-46d3-bf55-b218a93fc461@github.com>

On Thu, 6 Apr 2023 19:33:51 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

>> This is good work.    This needs some careful study on the security aspect.  I see the proxy class is in the same module of the interface, is non-public, and it has a no-arg non-public constructor. 
>> 
>> Defining the proxy class in the same module would grant this class reflective access to any class in this module.  This seems a concern if the target method handle should not have access to the class in that module.
>> 
>> W.r.t. the no-arg constructor,  I would consider another level of defense to make the constructor to take `Lookup` of itself and throw an IAE if the lookup class is not itself or it does not have `ORIGINAL` access.
>
>> This seems a concern if the target method handle should not have access to the class in that module.
> 
> MethodHandle access is checked when the MethodHandle is created.  
> For `@CallerSensitive` methods, the MethodHandle is additionally bound to the lookup class.  
> Also see [`java.lang.invoke.ConstantBootstraps.invoke`](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/ConstantBootstraps.html#invoke%28java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.Class,java.lang.invoke.MethodHandle,java.lang.Object...%29). If calling an arbitrary MethodHandle from a module could be a problem, then that is an easier target.
> 
>> W.r.t. the no-arg constructor, I would consider another level of defense to make the constructor to take Lookup of itself and throw an IAE if the lookup class is not itself or it does not have ORIGINAL access.
> 
> Without that defense you can create a new instance (if you have a reference to the hidden class) that does exactly the same thing as the original instance.  
> Other than `getClass` on the original object, `StackWalker` comes to mind as a way to obtain the class reference.

This patch is ready for review. WrapperInstance change was to address the annotation security concerns raised by @DasBrain. If there's more security implications with null classloader, I will swiftly update this patch as well.

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

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

From prr at openjdk.org  Fri Apr  7 02:12:53 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 02:12:53 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v3]
In-Reply-To: <B5qkdYWLgOcqZ-_IdFBZTehhhHA6IhwfnE9OecMrxGU=.d1e536f4-fba5-43db-b6a1-e8974b641815@github.com>
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 <B5qkdYWLgOcqZ-_IdFBZTehhhHA6IhwfnE9OecMrxGU=.d1e536f4-fba5-43db-b6a1-e8974b641815@github.com>
Message-ID: <48dealGmfwU6m9dKdOEs-aiiVt5fconzd880Qu94Y8A=.e2e0f829-dde5-4109-a177-facbd3305237@github.com>

On Fri, 31 Mar 2023 05:57:01 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicit conversion to jboolean

The single java.desktop change looks OK, so when anyone approves the rest that's implicitly approved.

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

PR Review: https://git.openjdk.org/jdk/pull/13139#pullrequestreview-1375751794

From fyang at openjdk.org  Fri Apr  7 02:39:56 2023
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 7 Apr 2023 02:39:56 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <hw0KAH255Qgpaf9TWe72S7DBFDPLju7BjAZo6Cnh7q0=.e4ce764d-37db-40c4-83bf-96705c0c80a1@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
 <hw0KAH255Qgpaf9TWe72S7DBFDPLju7BjAZo6Cnh7q0=.e4ce764d-37db-40c4-83bf-96705c0c80a1@github.com>
Message-ID: <UqgP5We9AZlrauRA3WGmu-_X9NXcHVMWlji7lgy_C-s=.dfc70627-db2b-4e4d-b2d8-4071c61bcde9@github.com>

On Tue, 21 Mar 2023 13:35:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> A review of all the copyright years shall be made in this PR.

> Hi @minborg, looks like some changes were missed on riscv port. I've added these changes and submitted tests on linux-riscv. `jdk_foreign` still passed with release & fatdebug build. Could you please add these extra changes for riscv? Thanks. Here is the patch: [foreign_riscv_port_patch.txt](https://github.com/openjdk/jdk/files/11037700/foreign_riscv_port_patch.txt)

@feilongjiang : Hello, the riscv-specific changes looks good to me. Thanks for the update.

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

PR Comment: https://git.openjdk.org/jdk/pull/13079#issuecomment-1499868465

From joehw at openjdk.org  Fri Apr  7 03:58:39 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 7 Apr 2023 03:58:39 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v8]
In-Reply-To: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
Message-ID: <kYQ4PnqjllVzqAjiiwC9Y4RFege0V55a72wdrP5b5HU=.6581eb6b-5590-4802-bc14-ace5a531625a@github.com>

> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8303531
> 
> Tests: XML SQE and JCK tests passed.

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

  Update based on the review meeting on 4/5. Added (duplicated) definitions in jaxp.properties; Rewrote Property Precedence with samples; Other updates.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12985/files
  - new: https://git.openjdk.org/jdk/pull/12985/files/f621b5d8..98a312cd

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

  Stats: 378 lines in 5 files changed: 216 ins; 33 del; 129 mod
  Patch: https://git.openjdk.org/jdk/pull/12985.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12985/head:pull/12985

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

From jpai at openjdk.org  Fri Apr  7 05:59:46 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 05:59:46 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v3]
In-Reply-To: <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
Message-ID: <P8j4Sb_G26s5EnX3hMY-OkBfW7izQLv1uflhTkdV6sM=.1688b147-9689-4eb1-aebb-9cc0a83b1cd8@github.com>

On Wed, 5 Apr 2023 15:48:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backout unneeded changes to module-info and default.policy.
>   Fixup formatting.

Looks ok to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1375851004

From stuefe at openjdk.org  Fri Apr  7 06:05:49 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Apr 2023 06:05:49 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <3jNPX5xpKbZQ0Cz05qJHuDLRpx5SmhzOxIHCeERnDWg=.90260d1e-6d77-430c-b0dc-a83df36b1272@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>
 <VnW1VBWQ9sLchqOACSMh0gUQG1cvQDJaSW3g_MPHnqo=.47697356-aabb-4d33-b4bf-df12bd3b15b3@github.com>
 <IWrvXb5j8yccPrUMpMHD63ddaA_7zKQBtkcRlnA--VU=.39f6fc2d-2614-4b2c-9f53-b7c7567648e2@github.com>
 <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com>
 <3jNPX5xpKbZQ0Cz05qJHuDLRpx5SmhzOxIHCeERnDWg=.90260d1e-6d77-430c-b0dc-a83df36b1272@github.com>
Message-ID: <7ams55QLQB0VUnTJfQBNoFlrgkZUBKTYsBL-NGVAxJY=.55a97708-fa04-4705-bf4d-60bf27d0a872@github.com>

On Thu, 6 Apr 2023 21:17:25 GMT, Glavo <duke at openjdk.org> wrote:

>> The point of Architecture is reflect the architecture as supported by the build and the runtime mutually and to reflect dependencies on the target hardware. 
>> 
>> What did you use as the example that would not compile on the other architecture?
>> Did you make the other changes to the build that would be needed for a new architecture?
>
>> What did you use as the example that would not compile on the other architecture? 
> 
> https://github.com/openjdk/jdk/blob/52ca4a70fc3de9e285964f9545ea8cd54e2d9924/src/java.base/share/classes/jdk/internal/util/OperatingSystemProps.java.template#L40
> 
> I don't understand how the above code can be compiled on architectures such as LongArch64, MIPS64el, or ARM32 without modifying the source file.
> 
>> Did you make the other changes to the build that would be needed for a new architecture?
> 
> I'm not talking about the new architecture, I'm talking about the architecture that OpenJDK already supports. 
> 
> According to my understanding, the above code breaks the support of all architectures not listed in `Architecture`. But has `Architecture` really listed all the supported architectures in the OpenJDK mainline?
> 
> For example, I want to compile OpenJDK for 32-bit ARM.  I think in this PR, I cannot compile without modifying the source code because `TARGET_ARCH_arm` does not exist. But before this PR, I was able to compile.

@Glavo Arm32 builds, though, see GHAs (crossbuilding test). As for the others, as long as the ports have not been integrated into mainline, I expect port maintainers will adapt the enum downstream. They do this anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160459041

From jpai at openjdk.org  Fri Apr  7 06:29:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 06:29:51 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
Message-ID: <QPi2XPcvt6OsxYrkPCYOhWMnP7aaVHBxcyugT4Ihn4M=.a268843f-2ac5-4c09-be43-c96b666d1fc3@github.com>

On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> 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 11 additional commits since the last revision:
> 
>  - Test/comments updates
>  - Merge
>  - Expand tests for jdk.ThreadSleep event
>  - Review feedback
>  - Merge
>  - Fix ThreadSleepEvent again
>  - Test updates
>  - ThreadSleepEvent refactoring
>  - Merge
>  - Merge
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/7adf8162...a5bb3fd9

src/java.base/share/classes/java/lang/ThreadLocal.java line 825:

> 823:                 // switch to carrier thread to avoid recursive use of thread-locals
> 824:                 vthread.executeOnCarrierThread(() -> {
> 825:                     System.out.println(vthread);

Hello Alan, as far as I have seen, much of a our debug logs/stacktrace in the JDK uses `System.err` to write them out. For example, `Thread.dumpStack()`, then even `java.security.debug` logging and many such places. Is it intentional that this tracing here uses `System.out` instead?

src/java.base/share/classes/java/lang/ThreadLocal.java line 832:

> 830:                 });
> 831:             } catch (Exception e) {
> 832:                 throw new InternalError(e);

Should inability to log/trace `ThreadLocal` creation or `set` lead to those operations failing? Or would it be OK, if we just ignored this exception that happened when tracing/logging?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160468749
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160469548

From stuefe at openjdk.org  Fri Apr  7 06:35:49 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Apr 2023 06:35:49 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <nc_w6DjozGQhwsm1-vZr-xgc0tV1HPheuWyA0QAo0CA=.f4b271b0-b08e-47a1-8353-12fe26707d8a@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <z8EuL6vvnVdCVsR68uEbPMFxyCabYlTLxrgh-xRzEj0=.619c4a4b-1bb0-44d5-88cf-50b801c4049d@github.com>
 <nc_w6DjozGQhwsm1-vZr-xgc0tV1HPheuWyA0QAo0CA=.f4b271b0-b08e-47a1-8353-12fe26707d8a@github.com>
Message-ID: <yyHezPsdOG8L8tnGGSIR1NfKkmLGvG2fnlGt1TbdWZ4=.0f7ad875-d8c5-4d31-9da4-4fe70eaacdda@github.com>

On Thu, 6 Apr 2023 20:39:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> > What about PPC (big endian)? Used on AIX?
> 
> I'm not aware of any code (in OpenJDK) related to big/little endian that is derived from `os.arch`.
> 
> > On Arm, it may be useful to know whether we built for thumb mode (We recently had this problem in tests).
> 
> For tests, there is the test library `jdk.test.lib.Platform` class with its own set of predicates.
> 
> For the moment, the idea is to do the minimum to replace OpenJDK internal uses of `os.arch`.

What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We also have PPC big-endian, it is used by AIX (and you can also run Linux with PPC big-endian). Why omit that?

os.arch for AIX is "ppc64". It is even used in our codebase, see https://github.com/openjdk/jdk/blob/c67bbcea92919fea9b6f7bbcde8ba4488289d174/test/hotspot/jtreg/runtime/ElfDecoder/TestElfDirectRead.java#L51

> > Another question, how does this work with Zero?
> 
> Zero is orthogonal to architecture; the interpreter is compiled for a specific target architecture.

Sorry, I was not clear. Zero is the vehicle to get the OpenJDK to build and run on hardware we don't directly support. It is not only used in bootstrapping but finds surprisingly broad use, e.g., for Debian wich itself supports a wide range of platforms and tries to provide java on all of them. 

For these JDKs, IIUC, os.arch would have the value of the target architecture ("PA-RISC", "mips", "alpha" etc). These platforms would be at a disadvantage now, as @Glavo pointed out: since OPENJDK_TARGET_CPU is fed from uname: https://github.com/openjdk/jdk/blob/c67bbcea92919fea9b6f7bbcde8ba4488289d174/make/RunTestsPrebuilt.gmk#L182, they will have a name that expands to an enum that is not compilable. So all of these platforms will get build errors.

I understand your intention to keep this patch simple, and that you want to limit the enum value. I also like enums. I wonder whether it would be possible to have an enum value "other" and map unknown architectures to that.

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1499986742

From alanb at openjdk.org  Fri Apr  7 06:38:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 06:38:48 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <QPi2XPcvt6OsxYrkPCYOhWMnP7aaVHBxcyugT4Ihn4M=.a268843f-2ac5-4c09-be43-c96b666d1fc3@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
 <QPi2XPcvt6OsxYrkPCYOhWMnP7aaVHBxcyugT4Ihn4M=.a268843f-2ac5-4c09-be43-c96b666d1fc3@github.com>
Message-ID: <VMj7jPofpC00sYegYPb6u2GnvYFw_lWhhg9I2ZBWhzs=.b9bc7749-0a2a-465d-a403-f908764d81af@github.com>

On Fri, 7 Apr 2023 06:26:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Or would it be OK, if we just ignored this exception that happened when tracing/logging?

If, for example, something has changed System.out to be a throwing PrintStream, and this diagnostic option is enabled, then it may fail here. As it's just a diagnostic option then I don't think it's a bit issue. Also this code will change with a future PR that will integrate this will filtering.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160473898

From jpai at openjdk.org  Fri Apr  7 06:45:52 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 06:45:52 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
Message-ID: <rIR_HSP_XsfklIih7VKTPrh5NpmdRXsC70POr-5Y_GY=.9081d045-7302-4652-94de-03291719ddd4@github.com>

On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> 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 11 additional commits since the last revision:
> 
>  - Test/comments updates
>  - Merge
>  - Expand tests for jdk.ThreadSleep event
>  - Review feedback
>  - Merge
>  - Fix ThreadSleepEvent again
>  - Test updates
>  - ThreadSleepEvent refactoring
>  - Merge
>  - Merge
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/430702c5...a5bb3fd9

src/java.base/share/classes/java/lang/ThreadLocal.java line 823:

> 821:                          .collect(Collectors.toList()));
> 822: 
> 823:                 // switch to carrier thread to avoid recursive use of thread-locals

The lambda here uses `System.out` to format and print and there's a loop which converts each collect `StackFrame` to a printable `StackTraceElement`. I had a brief look at the internals of the classes involved, but couldn't spot any code that instantiates or calls `set()` on any `ThreadLocal`s. Is there any specific code here which would trigger recursive thread-local usage or is it more a precaution to prevent any such potential usage.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160476293

From alanb at openjdk.org  Fri Apr  7 06:45:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 06:45:55 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <QPi2XPcvt6OsxYrkPCYOhWMnP7aaVHBxcyugT4Ihn4M=.a268843f-2ac5-4c09-be43-c96b666d1fc3@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
 <QPi2XPcvt6OsxYrkPCYOhWMnP7aaVHBxcyugT4Ihn4M=.a268843f-2ac5-4c09-be43-c96b666d1fc3@github.com>
Message-ID: <MoIGOZKMqI6NlmTVXTiMH13I9ygvy_0aC7bvkKsKH5w=.71913ad9-989a-4904-90ac-240065102f82@github.com>

On Fri, 7 Apr 2023 06:24:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Alan, as far as I have seen, much of a our debug logs/stacktrace in the JDK uses `System.err` to write them out. For example, `Thread.dumpStack()`, then even `java.security.debug` logging and many such places. Is it intentional that this tracing here uses `System.out` instead?

The tracing/diagnostic options print to stdout so I just kept it consistent. As I mentioned in another comment, there is further work on filtering that will require re-visiting this and maybe we can look at having broader consistency then, just not this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160476763

From jpai at openjdk.org  Fri Apr  7 06:49:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 06:49:51 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
Message-ID: <XPM7ME7-99gcqWDDAG8sIwgHVeUmCl3a-RtatpKf2aM=.db83990d-e283-4564-bcb7-24fd84e59e5f@github.com>

On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> 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 11 additional commits since the last revision:
> 
>  - Test/comments updates
>  - Merge
>  - Expand tests for jdk.ThreadSleep event
>  - Review feedback
>  - Merge
>  - Fix ThreadSleepEvent again
>  - Test updates
>  - ThreadSleepEvent refactoring
>  - Merge
>  - Merge
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/a6347823...a5bb3fd9

src/java.base/share/classes/java/lang/ThreadLocal.java line 805:

> 803:     /**
> 804:      * Reads the value of the jdk.traceVirtualThreadLocals property to determine if
> 805:      * a stack trace should be printed when a virtual threads sets a thread local.

Trivial typo - "virtual threads sets ...." should have been "virtual thread sets ...."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160478015

From alanb at openjdk.org  Fri Apr  7 06:49:54 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 06:49:54 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <rIR_HSP_XsfklIih7VKTPrh5NpmdRXsC70POr-5Y_GY=.9081d045-7302-4652-94de-03291719ddd4@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
 <rIR_HSP_XsfklIih7VKTPrh5NpmdRXsC70POr-5Y_GY=.9081d045-7302-4652-94de-03291719ddd4@github.com>
Message-ID: <SVJbmVy9DYNffFJGhQBr3EpMFMwMq3E6ri2WFitnViQ=.1ea17d37-2e7e-4953-aa96-b946748dcc32@github.com>

On Fri, 7 Apr 2023 06:41:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The lambda here uses `System.out` to format and print and there's a loop which converts each collect `StackFrame` to a printable `StackTraceElement`. I had a brief look at the internals of the classes involved, but couldn't spot any code that instantiates or calls `set()` on any `ThreadLocal`s. Is there any specific code here which would trigger recursive thread-local usage or is it more a precaution to prevent any such potential usage.

Formatting is locale specific and amounts to running arbitrary code, so this cod has to defend against recursive calls.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160478956

From duke at openjdk.org  Fri Apr  7 06:54:45 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 7 Apr 2023 06:54:45 GMT
Subject: RFR: 8205129: Remove java.lang.Compiler
In-Reply-To: <k5oL-_x7ZlO48IYXqrBVQK_KhbPiLwrQSAXFgyWu8pk=.9834a282-838a-4893-b751-a8b318b68d37@github.com>
References: <k5oL-_x7ZlO48IYXqrBVQK_KhbPiLwrQSAXFgyWu8pk=.9834a282-838a-4893-b751-a8b318b68d37@github.com>
Message-ID: <kDbStzVZm9y54LqvmY7FhRjZP8AZZxMt2MzjgkGDsFo=.4365c127-0297-4d89-856d-652fee9aa421@github.com>

On Sun, 19 Mar 2023 09:01:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please help review this PR which suggests we remove the class `java.lang.Compiler`. The class seems non-functional for a decade, and was terminally deprecated in Java 9. Time has come to let it go.

This PR is daydreaming about  a sponsor walking by.

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

PR Comment: https://git.openjdk.org/jdk/pull/13092#issuecomment-1499997803

From jpai at openjdk.org  Fri Apr  7 06:59:53 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 06:59:53 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
Message-ID: <g4YIGP-iVVSL-eTXLzsIChj1LmIR2j1lfnBPlv23Xa4=.b6fb0131-e8ef-4bbf-b48b-2f10861a45e0@github.com>

On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> 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 11 additional commits since the last revision:
> 
>  - Test/comments updates
>  - Merge
>  - Expand tests for jdk.ThreadSleep event
>  - Review feedback
>  - Merge
>  - Fix ThreadSleepEvent again
>  - Test updates
>  - ThreadSleepEvent refactoring
>  - Merge
>  - Merge
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c776b73f...a5bb3fd9

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 72:

> 70:         RECORD_PATTERNS,
> 71:         // not used
> 72:         VIRTUAL_THREADS,

The javadoc `Preview` page lists the preview features (and the JEPs) that are part of a release. For example, for JDK 20 the page is here https://docs.oracle.com/en/java/javase/20/docs/api/preview-list.html. 

In a JDK image that's built out of this PR, does the missing `@JEP` annotation on this enum value cause issues in javadoc image generation or presentation on that page?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160484235

From jpai at openjdk.org  Fri Apr  7 07:11:55 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 07:11:55 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
Message-ID: <D-FuKNjVPY_lzkN-s93N4Wvd1rNzRgqkM-HG9DP0u9s=.c8c04b5c-e09a-4c53-8c10-4a280a7cbe7d@github.com>

On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> 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 11 additional commits since the last revision:
> 
>  - Test/comments updates
>  - Merge
>  - Expand tests for jdk.ThreadSleep event
>  - Review feedback
>  - Merge
>  - Fix ThreadSleepEvent again
>  - Test updates
>  - ThreadSleepEvent refactoring
>  - Merge
>  - Merge
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/24494df1...a5bb3fd9

test/jdk/com/sun/jdi/SuspendAfterDeath.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

This should have been `2022, 2023,`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160490224

From alanb at openjdk.org  Fri Apr  7 07:11:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 07:11:50 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <g4YIGP-iVVSL-eTXLzsIChj1LmIR2j1lfnBPlv23Xa4=.b6fb0131-e8ef-4bbf-b48b-2f10861a45e0@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
 <g4YIGP-iVVSL-eTXLzsIChj1LmIR2j1lfnBPlv23Xa4=.b6fb0131-e8ef-4bbf-b48b-2f10861a45e0@github.com>
Message-ID: <XybSoCyu6cdVMCTUJ8VQ7QTS5kyD984Vy1h0y7X8iNs=.29358db7-8beb-4499-8487-089c6555cb76@github.com>

On Fri, 7 Apr 2023 06:56:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> In a JDK image that's built out of this PR, does the missing `@JEP` annotation on this enum value cause issues in javadoc image generation or presentation on that page?

This has been looked at a few times and we didn't find any issues. Ideally the constant would be removed but we are forced to leave it for now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160490631

From jpai at openjdk.org  Fri Apr  7 07:28:52 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 07:28:52 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
Message-ID: <vIxvHzI1nS7XasIA9Mj3KoKydm1MkFmp1WTl7YBwxwA=.48ae6914-8444-4d98-85e5-07429a60bb25@github.com>

On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> 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 11 additional commits since the last revision:
> 
>  - Test/comments updates
>  - Merge
>  - Expand tests for jdk.ThreadSleep event
>  - Review feedback
>  - Merge
>  - Fix ThreadSleepEvent again
>  - Test updates
>  - ThreadSleepEvent refactoring
>  - Merge
>  - Merge
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/a85d6cbe...a5bb3fd9

test/jdk/java/lang/Thread/java.base/jdk/internal/event/ThreadSleepEvent.java line 29:

> 27:  * ThreadSleepEvent to optionally throw OOME at create, begin or commit time.
> 28:  */
> 29: public class ThreadSleepEvent {

Should this extend `jdk.internal.event.Event` and then have each of the methods have a `@Override` on them? Or would that cause some issue when this is used in a jtreg test in the `@compile` directive?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160500794

From alanb at openjdk.org  Fri Apr  7 07:29:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 07:29:46 GMT
Subject: RFR: 8291023: FileOutputStream.close() re-entrantly invokes itself
 after getChannel().force()
In-Reply-To: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
References: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
Message-ID: <fs4ZHBtHiNRGZO0X7tIRyFrUC9aUPb0hstw1JEA1_bs=.b9875f1b-00a3-4ff9-886c-3c7d24161a7e@github.com>

On Thu, 6 Apr 2023 22:36:33 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> IO stream classes like `FileOutputStream` can have assocated NIO channels.
> 
> When `close()` is invoked on one of these classes, it in turn invokes `close()` on the associated channel (if any). But when the associated channel's `close()` method is invoked, it in turn invokes `close()` on the associated stream (if any).
> 
> As a result, these IO stream `close()` methods invoke themselves reentrantly when there is an associated channel.
> 
> This is not a problem for these classes because they are written to handle this (i.e., they are idempotent), but it can be surprising (or worse, just silently bug-inducing) for subclasses that override `close()`.
> 
> There are two possible ways to address this:
> 1. Modify the code to detect and avoid the (unnecessary) reentrant invocations
> 2. Add a `@implNote` to the Javadoc so subclass implementers are made aware
> 
> This patch takes the second, more conservative approach.

Closing a FIS/FOS/RAF with an associated file channel is specified to close the channel. FileChannel's class description is missing a sentence to say that closing a file channel obtained from a FIS/FOS/RAF will close the stream, something like:


--- a/src/java.base/share/classes/java/nio/channels/FileChannel.java
+++ b/src/java.base/share/classes/java/nio/channels/FileChannel.java
@@ -122,7 +122,8 @@ import jdk.internal.javac.PreviewFeature;
  * the originating object, and vice versa. Changing the file's length via the
  * file channel will change the length seen via the originating object, and vice
  * versa.  Changing the file's content by writing bytes will change the content
- * seen by the originating object, and vice versa.
+ * seen by the originating object, and vice versa.  Closing the channel will
+ * close the originating object.


No objection to adding a note to FIS/FOS/RAF for cases where these classes are extended and close is overridden but I think it should be an API note. As regards JBS issues, the title on JDK-8291023 is misleading as it's nothing to do with FileChannel.close, maybe a new issue should be created for the the API note or else JDK-8291023 it renamed to reflective the re-purpose.

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

PR Comment: https://git.openjdk.org/jdk/pull/13379#issuecomment-1500021465

From duke at openjdk.org  Fri Apr  7 07:34:54 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 7 Apr 2023 07:34:54 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <HjBAtHd8xcylCVfDPjKgabKcPG2LIy4egD5iUMLz5rg=.ae4edf98-987c-483a-8f6b-f8c0c0f594a0@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <VSummI7PkJWPb8R-Ee_GQ5e69_mXIvFaeRPf1lVkGac=.011bc0a0-de39-4bdc-bd96-3e02b301a825@github.com>
 <HjBAtHd8xcylCVfDPjKgabKcPG2LIy4egD5iUMLz5rg=.ae4edf98-987c-483a-8f6b-f8c0c0f594a0@github.com>
Message-ID: <OqZpzPPYklrHL-1VJLy0DpIzbPTGEl2mWwZPjKHXMyU=.9ff6a9be-e020-4ddb-b7c4-208a6bee8bf1@github.com>

On Tue, 28 Mar 2023 10:00:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 297:
>> 
>>> 295:         MethodType mtype = mh.type();
>>> 296:         int[] perms = new int[mtype.parameterCount()];
>>> 297:         MethodType swappedType = MethodType.methodType(mtype.returnType());
>> 
>> Instead?of `MethodType::appendParameterTypes(?)` (which?performs an?expensive?lookup of?a?new?cached `MethodType` value per?call), this?method should?instead use?a?`Class<?>[]` for?the?arguments, which?avoids that?overhead inside?a?loop:
>> 
>> 	public static MethodHandle swapArguments(MethodHandle mh, int firstArg, int secondArg) {
>> 		MethodType mtype = mh.type();
>> 		int[] perms = new int[mtype.parameterCount()];
>> 		Class<?>[] ptypes = new Class<?>[perms.length];
>> 		for (int i = 0 ; i < perms.length ; i++) {
>> 			int dst = i;
>> 			if (i == firstArg) dst = secondArg;
>> 			else if (i == secondArg) dst = firstArg;
>> 			perms[i] = dst;
>> 			ptypes[i] = mtype.parameterType(dst);
>> 		}
>> 		// This should use `JavaLangInvokeAccess` to invoke the internal
>> 		// `MethodType.methodType(Class<?> rtype, Class<?>[] ptypes, boolean trusted)`
>> 		// method with a `trusted` value of `true`:
>> 		MethodType swappedType = MethodType.methodType(mtype.returnType(), ptypes);
>> 		return permuteArguments(mh, swappedType, perms);
>> 	}
>
> Thanks for this enhancement proposal. I hope you do not mind me asking if you could file a separate issue about this where you describe the above? We can then merge that proposal independent of this PR.

I?don?t (yet)?have a?**JBS**?account, so?it?s?painful to?file?issues because the?**Java Bug?Report** website[^1] doesn?t support neither **Markdown** nor?**Jira**?formatting (and?also the?`JI?*` to?`JDK?*` issue?transfer waiting?time).

[^1]: https://bugreport.java.com/bugreport/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1160504428

From jpai at openjdk.org  Fri Apr  7 07:41:52 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 07:41:52 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
Message-ID: <5qIKJpxmQtkzyHNAtMdEPV9NHYUGMXinsHk6gTOk8WM=.4ffa9d7e-ae4f-4ab3-acbd-4c2e59642659@github.com>

On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> 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 11 additional commits since the last revision:
> 
>  - Test/comments updates
>  - Merge
>  - Expand tests for jdk.ThreadSleep event
>  - Review feedback
>  - Merge
>  - Fix ThreadSleepEvent again
>  - Test updates
>  - ThreadSleepEvent refactoring
>  - Merge
>  - Merge
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c2ee11c7...a5bb3fd9

test/jdk/java/lang/Thread/virtual/TraceVirtualThreadLocals.java line 52:

> 50:             name.get();
> 51:         });
> 52:         assertContains(output, "java.lang.ThreadLocal.get");

Should it also assert the presence of `ThreadLocal.setInitialValue` in the stacktrace?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160508153

From alanb at openjdk.org  Fri Apr  7 07:45:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 07:45:55 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <yyHezPsdOG8L8tnGGSIR1NfKkmLGvG2fnlGt1TbdWZ4=.0f7ad875-d8c5-4d31-9da4-4fe70eaacdda@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <z8EuL6vvnVdCVsR68uEbPMFxyCabYlTLxrgh-xRzEj0=.619c4a4b-1bb0-44d5-88cf-50b801c4049d@github.com>
 <nc_w6DjozGQhwsm1-vZr-xgc0tV1HPheuWyA0QAo0CA=.f4b271b0-b08e-47a1-8353-12fe26707d8a@github.com>
 <yyHezPsdOG8L8tnGGSIR1NfKkmLGvG2fnlGt1TbdWZ4=.0f7ad875-d8c5-4d31-9da4-4fe70eaacdda@github.com>
Message-ID: <RSr_REqgL5AEiDIRHJmvhlDoHBV5XclUTFwt9ALIOUc=.b9986985-0d6f-4daa-ab65-69acb188a52f@github.com>

On Fri, 7 Apr 2023 06:33:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We also have PPC big-endian, it is used by AIX (and you can also run Linux with PPC big-endian). Why omit that?
> 
> os.arch for AIX is "ppc64".

So I think you are saying that there are aix-ppc64 and linux-ppc64le builds so this enum needs to have values for both ppc64 and ppc64le.

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1500032422

From duke at openjdk.org  Fri Apr  7 07:47:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 7 Apr 2023 07:47:49 GMT
Subject: RFR: 8302819: Remove JAR Index [v6]
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.

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

  Add a note in the --help for --generate-index that this option is deprecated and may be removed in a future release.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13158/files
  - new: https://git.openjdk.org/jdk/pull/13158/files/79b19e94..d04df25e

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

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

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

From duke at openjdk.org  Fri Apr  7 07:47:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 7 Apr 2023 07:47:49 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <AvcNFdCM6eGAM-NA9yDxTZzE_h5xywb7qZV-ZhohHNc=.0ec40d45-ac53-460e-8df9-d2795add811f@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <AvcNFdCM6eGAM-NA9yDxTZzE_h5xywb7qZV-ZhohHNc=.0ec40d45-ac53-460e-8df9-d2795add811f@github.com>
Message-ID: <U68JoyaXxhEailTKQBaI0OCmPVg7nTS8e5pbn1jlGpI=.3321a055-a8a1-4a22-b6d4-1322c7892998@github.com>

On Thu, 6 Apr 2023 07:32:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> One additional thing we could do is update the usage output for -i/--generate-index to say that the option is deprecated. Looking at `jdeps -help` output to see this for the deprecated -P/--profile option.

Implemented as suggested. The --help output now looks like:


  -i, --generate-index=FILE  Generate index information for the specified jar
                             archives. This option is deprecated and may be 
                             removed in a future release.

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1500032739

From jpai at openjdk.org  Fri Apr  7 07:49:58 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 07:49:58 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <vIxvHzI1nS7XasIA9Mj3KoKydm1MkFmp1WTl7YBwxwA=.48ae6914-8444-4d98-85e5-07429a60bb25@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
 <vIxvHzI1nS7XasIA9Mj3KoKydm1MkFmp1WTl7YBwxwA=.48ae6914-8444-4d98-85e5-07429a60bb25@github.com>
Message-ID: <iMZV-gvZHa2JTNWCMFCdHdLWZf7k99sM4uG4A7KjUec=.cbb02abe-750b-463c-b73b-2e1a45410dc1@github.com>

On Fri, 7 Apr 2023 07:25:59 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 11 additional commits since the last revision:
>> 
>>  - Test/comments updates
>>  - Merge
>>  - Expand tests for jdk.ThreadSleep event
>>  - Review feedback
>>  - Merge
>>  - Fix ThreadSleepEvent again
>>  - Test updates
>>  - ThreadSleepEvent refactoring
>>  - Merge
>>  - Merge
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/97c49893...a5bb3fd9
>
> test/jdk/java/lang/Thread/java.base/jdk/internal/event/ThreadSleepEvent.java line 29:
> 
>> 27:  * ThreadSleepEvent to optionally throw OOME at create, begin or commit time.
>> 28:  */
>> 29: public class ThreadSleepEvent {
> 
> Should this extend `jdk.internal.event.Event` and then have each of the methods have a `@Override` on them? Or would that cause some issue when this is used in a jtreg test in the `@compile` directive?

Same comment for the newly introduced `test/jdk/java/lang/Thread/virtual/java.base/jdk/internal/event/VirtualThreadPinnedEvent.java`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160511761

From jpai at openjdk.org  Fri Apr  7 07:50:00 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 07:50:00 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
Message-ID: <JtdwfR2old3BhGiFvZfJWl9XM33h9yXkw4shVkUoYhI=.e53b0447-7315-4999-95f6-9ccc03a23380@github.com>

On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> 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 11 additional commits since the last revision:
> 
>  - Test/comments updates
>  - Merge
>  - Expand tests for jdk.ThreadSleep event
>  - Review feedback
>  - Merge
>  - Fix ThreadSleepEvent again
>  - Test updates
>  - ThreadSleepEvent refactoring
>  - Merge
>  - Merge
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/97c49893...a5bb3fd9

test/jdk/java/lang/Thread/virtual/YieldQueuing.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

Should have been `2022, 2023,`

test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

Same as some other files with copyright year updates, should have been `2022, 2023,`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160510856
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160513282

From duke at openjdk.org  Fri Apr  7 07:52:53 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 7 Apr 2023 07:52:53 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <OqZpzPPYklrHL-1VJLy0DpIzbPTGEl2mWwZPjKHXMyU=.9ff6a9be-e020-4ddb-b7c4-208a6bee8bf1@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <VSummI7PkJWPb8R-Ee_GQ5e69_mXIvFaeRPf1lVkGac=.011bc0a0-de39-4bdc-bd96-3e02b301a825@github.com>
 <HjBAtHd8xcylCVfDPjKgabKcPG2LIy4egD5iUMLz5rg=.ae4edf98-987c-483a-8f6b-f8c0c0f594a0@github.com>
 <OqZpzPPYklrHL-1VJLy0DpIzbPTGEl2mWwZPjKHXMyU=.9ff6a9be-e020-4ddb-b7c4-208a6bee8bf1@github.com>
Message-ID: <K-DrLBEZWuqbfxe6WhtS36HWIUmtsgHlDn3NBoJl27g=.4a8a61f4-29b6-487e-94f7-e9f382be1fe3@github.com>

On Fri, 7 Apr 2023 07:32:02 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Thanks for this enhancement proposal. I hope you do not mind me asking if you could file a separate issue about this where you describe the above? We can then merge that proposal independent of this PR.
>
> I?don?t (yet)?have a?**JBS**?account, so?it?s?painful to?file?issues because the?**Java Bug?Report** website[^1] doesn?t support neither **Markdown** nor?**Jira**?formatting (and?also the?`JI?*` to?`JDK?*` issue?transfer waiting?time).
> 
> [^1]: https://bugreport.java.com/bugreport/

Filed?as: [JI?9075066](https://bugs.openjdk.org/browse/JI-9075066 "[JI?9075066] Optimise `jdk.internal.foreign.abi.SharedUtils::swapArguments(?)`")

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1160514139

From aturbanov at openjdk.org  Fri Apr  7 08:09:46 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 7 Apr 2023 08:09:46 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v3]
In-Reply-To: <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
Message-ID: <MoRaAV2bfkpmtql8WLLyCK7oZuW7oIWJDzLSgmBAEvU=.e90d7846-8e32-4dba-a63e-1d9a2d69fc7e@github.com>

On Wed, 5 Apr 2023 15:48:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backout unneeded changes to module-info and default.policy.
>   Fixup formatting.

src/java.prefs/share/classes/java/util/prefs/Preferences.java line 299:

> 297:         String platformFactory = switch (OperatingSystem.current()) {
> 298:             case WINDOWS -> "java.util.prefs.WindowsPreferencesFactory";
> 299:             case MACOS ->  "java.util.prefs.MacOSXPreferencesFactory";

Suggestion:

            case MACOS -> "java.util.prefs.MacOSXPreferencesFactory";

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1160525650

From alanb at openjdk.org  Fri Apr  7 08:39:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 08:39:50 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <iMZV-gvZHa2JTNWCMFCdHdLWZf7k99sM4uG4A7KjUec=.cbb02abe-750b-463c-b73b-2e1a45410dc1@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
 <vIxvHzI1nS7XasIA9Mj3KoKydm1MkFmp1WTl7YBwxwA=.48ae6914-8444-4d98-85e5-07429a60bb25@github.com>
 <iMZV-gvZHa2JTNWCMFCdHdLWZf7k99sM4uG4A7KjUec=.cbb02abe-750b-463c-b73b-2e1a45410dc1@github.com>
Message-ID: <S8bu5rbpVpclkmueMYncJ6HM4Q10GouAPy-VOugYXF4=.f9ae5d3b-c236-49ea-9a22-f1bbdb20e679@github.com>

On Fri, 7 Apr 2023 07:44:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/lang/Thread/java.base/jdk/internal/event/ThreadSleepEvent.java line 29:
>> 
>>> 27:  * ThreadSleepEvent to optionally throw OOME at create, begin or commit time.
>>> 28:  */
>>> 29: public class ThreadSleepEvent {
>> 
>> Should this extend `jdk.internal.event.Event` and then have each of the methods have a `@Override` on them? Or would that cause some issue when this is used in a jtreg test in the `@compile` directive?
>
> Same comment for the newly introduced `test/jdk/java/lang/Thread/virtual/java.base/jdk/internal/event/VirtualThreadPinnedEvent.java`

> Should this extend `jdk.internal.event.Event` and then have each of the methods have a `@Override` on them? Or would that cause some issue when this is used in a jtreg test in the `@compile` directive?

Okay, we can do that do as it might be cleaner for something changing these tests in the future and help to find issues quickly in the event that the internal infrastructure for JFR events in java.base changes in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160543904

From alanb at openjdk.org  Fri Apr  7 08:39:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 08:39:56 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <JtdwfR2old3BhGiFvZfJWl9XM33h9yXkw4shVkUoYhI=.e53b0447-7315-4999-95f6-9ccc03a23380@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
 <JtdwfR2old3BhGiFvZfJWl9XM33h9yXkw4shVkUoYhI=.e53b0447-7315-4999-95f6-9ccc03a23380@github.com>
Message-ID: <_8akvgHjBo-ri1FBYwKY9ZvnCl1wgJplmI7ws6Q4giU=.05eb7df4-06dd-402a-91a6-37cdbb8bb04e@github.com>

On Fri, 7 Apr 2023 07:43:02 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 11 additional commits since the last revision:
>> 
>>  - Test/comments updates
>>  - Merge
>>  - Expand tests for jdk.ThreadSleep event
>>  - Review feedback
>>  - Merge
>>  - Fix ThreadSleepEvent again
>>  - Test updates
>>  - ThreadSleepEvent refactoring
>>  - Merge
>>  - Merge
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/9db93ce4...a5bb3fd9
>
> test/jdk/java/lang/Thread/virtual/YieldQueuing.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Should have been `2022, 2023,`

Yes, it should. There are 200+ tests updated, the majority of which were updated with `sed` rather than manual edits, got it wrong for 5 tests it seems. I'll fix those, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160542385

From alanb at openjdk.org  Fri Apr  7 08:42:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 08:42:43 GMT
Subject: RFR: 8303919: Instant.ofEpochMilli says it can throw an exception
 that it can't
In-Reply-To: <KZTI-vNW52nDDiFr1qtbUBxKGGr6To04RWa7PMpcIjU=.38d302c5-15d6-446e-97d0-6f87f7ff0f77@github.com>
References: <KZTI-vNW52nDDiFr1qtbUBxKGGr6To04RWa7PMpcIjU=.38d302c5-15d6-446e-97d0-6f87f7ff0f77@github.com>
Message-ID: <y14BGbU2gdCPj9Pqj3HL33vdD1842iBPXyfHrHoeyUQ=.1f258b75-669b-4597-b4eb-8adb13148de4@github.com>

On Thu, 9 Mar 2023 19:49:29 GMT, Eamonn McManus <emcmanus at openjdk.org> wrote:

> Instant.ofEpochMilli says this:
> 
> 
> @throws DateTimeException if the instant exceeds the maximum or minimum instant
> 
> 
> But that can't happen. Even given `Long.MIN_VALUE` or `Long.MAX_VALUE` it does not throw. That's already implicitly tested in [`TestInstant`](https://github.com/openjdk/jdk/blob/a9dba565688a29bef8626488c47519008dcadbe8/test/jdk/java/time/test/java/time/TestInstant.java#L84), which calls it with both those values.

I see this PR is timing out but I think the spec should be changed as "throws DateTimeException if ..." is testable and there are no inputs where this exception is thrown.

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

PR Comment: https://git.openjdk.org/jdk/pull/12958#issuecomment-1500076391

From alanb at openjdk.org  Fri Apr  7 08:46:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 08:46:52 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v6]
In-Reply-To: <5qIKJpxmQtkzyHNAtMdEPV9NHYUGMXinsHk6gTOk8WM=.4ffa9d7e-ae4f-4ab3-acbd-4c2e59642659@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <kjOo0A0TyZDOq4cWWAWoUET79yQkqd9DHYjnWyvu4Vs=.5173f873-e3f9-4feb-afa9-a0cad68e114d@github.com>
 <5qIKJpxmQtkzyHNAtMdEPV9NHYUGMXinsHk6gTOk8WM=.4ffa9d7e-ae4f-4ab3-acbd-4c2e59642659@github.com>
Message-ID: <iSMgwiCuvSdRSA4svHmPQNRMBZPaeP0QdoK0sNC86ME=.ca215490-a37e-472e-934d-9fbb06e9b71c@github.com>

On Fri, 7 Apr 2023 07:38:31 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 11 additional commits since the last revision:
>> 
>>  - Test/comments updates
>>  - Merge
>>  - Expand tests for jdk.ThreadSleep event
>>  - Review feedback
>>  - Merge
>>  - Fix ThreadSleepEvent again
>>  - Test updates
>>  - ThreadSleepEvent refactoring
>>  - Merge
>>  - Merge
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/49869acd...a5bb3fd9
>
> test/jdk/java/lang/Thread/virtual/TraceVirtualThreadLocals.java line 52:
> 
>> 50:             name.get();
>> 51:         });
>> 52:         assertContains(output, "java.lang.ThreadLocal.get");
> 
> Should it also assert the presence of `ThreadLocal.setInitialValue` in the stacktrace?

It's the `get` method that triggers the initial value to be generated so this is why the test checks that method. But I think you have a point it would be clearer if the the test were to match on something that has "initialValue" in the string. It means using the name of an internal method but it might be okay here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160548887

From duke at openjdk.org  Fri Apr  7 08:58:58 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 7 Apr 2023 08:58:58 GMT
Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting
 in the latin1 fast-path test [v2]
In-Reply-To: <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com>
Message-ID: <x-bCJ3nQNK3_HAfPx7YPN_Wh0PLOT2Gu56l4tgX1_Ks=.0ba11267-787e-4ff3-9def-73af07e2fc55@github.com>

On Wed, 15 Mar 2023 14:31:03 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points.
>> 
>> The latin1 test is currently implemented as `ch >>> 8 == 0`.  We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for Latin1 code points):
>> 
>> This method is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods.
>> 
>> Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00):
>> 
>> Baseline:
>> 
>> 
>> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigit           48  avgt   15  0.870 ? 0.011  ns/op
>> Characters.isDigit         1632  avgt   15  2.168 ? 0.017  ns/op
>> 
>> PR:
>> 
>> 
>> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigit           48  avgt   15  0.654 ? 0.007  ns/op
>> Characters.isDigit         1632  avgt   15  2.032 ? 0.019  ns/op
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update StringLatin1.canEncode to sync with same test in CharacterData.of

I'm withdrawing this PR since its merits seem suspect.

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

PR Comment: https://git.openjdk.org/jdk/pull/13040#issuecomment-1500087677

From duke at openjdk.org  Fri Apr  7 08:59:00 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 7 Apr 2023 08:59:00 GMT
Subject: Withdrawn: 8304245: Speed up CharacterData.of by avoiding bit shifting
 in the latin1 fast-path test
In-Reply-To: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
Message-ID: <OILXrp8R1NJN7jsogPgyH5uw8triGaIB0vL0qJU0WfY=.e2d5522d-5ae0-414a-9f40-9f5b89c20b07@github.com>

On Wed, 15 Mar 2023 11:26:21 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points.
> 
> The latin1 test is currently implemented as `ch >>> 8 == 0`.  We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for Latin1 code points):
> 
> This method is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods.
> 
> Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00):
> 
> Baseline:
> 
> 
> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigit           48  avgt   15  0.870 ? 0.011  ns/op
> Characters.isDigit         1632  avgt   15  2.168 ? 0.017  ns/op
> 
> PR:
> 
> 
> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigit           48  avgt   15  0.654 ? 0.007  ns/op
> Characters.isDigit         1632  avgt   15  2.032 ? 0.019  ns/op

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Fri Apr  7 09:10:49 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 7 Apr 2023 09:10:49 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
Message-ID: <UNx5kajHm8bXnl8XGs3I5xKHGodIVD6yQJ-DxoHcgdw=.2592f28c-a962-41c3-a9ae-2e359a64d516@github.com>

On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded qualified export from java.base to jdk.attach

src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java line 38:

> 36: 
> 37: import jdk.internal.util.Architecture;
> 38: 

Not?removed in?[commit?`ab084c2` or?`52ca4a7`](https://github.com/openjdk/jdk/pull/13357/files/105ce60528f7ef84e31ac3db64e6eb63860b4a70..52ca4a70fc3de9e285964f9545ea8cd54e2d9924):
Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160563815

From jpai at openjdk.org  Fri Apr  7 09:18:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 09:18:45 GMT
Subject: RFR: 8305696: (zipfs) Avoid redundant LinkedHashMap.containsKey
 call ZipFileSystem.makeParentDirs
In-Reply-To: <L1C6gVVln23VejqKo9Qab54sNHc8tLuQoyVL3Y9uc9o=.9f0f0cdb-2e9c-42e6-801b-d1aa64dc8bc5@github.com>
References: <L1C6gVVln23VejqKo9Qab54sNHc8tLuQoyVL3Y9uc9o=.9f0f0cdb-2e9c-42e6-801b-d1aa64dc8bc5@github.com>
Message-ID: <4jw7OifTl7Pq70Ohv4afNgGzAAGY2kHHMAdbqwdh8Es=.bc895cb3-27b8-4bba-ad50-5a4b532980a5@github.com>

On Mon, 3 Apr 2023 17:16:26 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `LinkedHashMap<IndexNode, IndexNode>` `ZipFileSystem.inodes` contains only non-null values. It means instead of separate `containsKey`+`get` calls, we can use single `LinkedHashMap.get` call and then compare result with `null`.
> Result code is a bit simpler and faster.
> 
> Testing: Linux x64 `java/nio`, `jdk/nio`

Looks ok to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13304#pullrequestreview-1376013170

From jpai at openjdk.org  Fri Apr  7 09:20:44 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 09:20:44 GMT
Subject: RFR: 8205129: Remove java.lang.Compiler
In-Reply-To: <k5oL-_x7ZlO48IYXqrBVQK_KhbPiLwrQSAXFgyWu8pk=.9834a282-838a-4893-b751-a8b318b68d37@github.com>
References: <k5oL-_x7ZlO48IYXqrBVQK_KhbPiLwrQSAXFgyWu8pk=.9834a282-838a-4893-b751-a8b318b68d37@github.com>
Message-ID: <w6HPp1ilkUo7r_vK4XA1Ye6GpC3D253cBNupjfrtH8o=.e0a02423-251c-4d38-b357-208a4b03e3d3@github.com>

On Sun, 19 Mar 2023 09:01:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please help review this PR which suggests we remove the class `java.lang.Compiler`. The class seems non-functional for a decade, and was terminally deprecated in Java 9. Time has come to let it go.

Hello Eirik, I'll run this against our CI just to be sure and if things go fine, will sponsor this.

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

PR Comment: https://git.openjdk.org/jdk/pull/13092#issuecomment-1500107402

From stuefe at openjdk.org  Fri Apr  7 09:30:48 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Apr 2023 09:30:48 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <RSr_REqgL5AEiDIRHJmvhlDoHBV5XclUTFwt9ALIOUc=.b9986985-0d6f-4daa-ab65-69acb188a52f@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <z8EuL6vvnVdCVsR68uEbPMFxyCabYlTLxrgh-xRzEj0=.619c4a4b-1bb0-44d5-88cf-50b801c4049d@github.com>
 <nc_w6DjozGQhwsm1-vZr-xgc0tV1HPheuWyA0QAo0CA=.f4b271b0-b08e-47a1-8353-12fe26707d8a@github.com>
 <yyHezPsdOG8L8tnGGSIR1NfKkmLGvG2fnlGt1TbdWZ4=.0f7ad875-d8c5-4d31-9da4-4fe70eaacdda@github.com>
 <RSr_REqgL5AEiDIRHJmvhlDoHBV5XclUTFwt9ALIOUc=.b9986985-0d6f-4daa-ab65-69acb188a52f@github.com>
Message-ID: <xPongRDOBHRh5URyYf3cFcGGh2gMdwvCPbsnCdVuQ3Y=.23496da3-d68d-409e-bea1-53a1ec7f66b0@github.com>

On Fri, 7 Apr 2023 07:42:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We also have PPC big-endian, it is used by AIX (and you can also run Linux with PPC big-endian). Why omit that?
> > os.arch for AIX is "ppc64".
> 
> So I think you are saying that there are aix-ppc64 and linux-ppc64le builds so this enum needs to have values for both ppc64 and ppc64le.

Yes, precisely.

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1500115177

From duke at openjdk.org  Fri Apr  7 10:01:30 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 7 Apr 2023 10:01:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v54]
In-Reply-To: <BSADnCP_cZkZnwJDnznJ3T8PbB0IF6_xF_wuEJv7Pc0=.b8c1654a-6fe1-487e-9095-b4a5f2bcd22d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <BSADnCP_cZkZnwJDnznJ3T8PbB0IF6_xF_wuEJv7Pc0=.b8c1654a-6fe1-487e-9095-b4a5f2bcd22d@github.com>
Message-ID: <AhfxQ0KFneqkzcwmZyT_BrIP7EPK8mq3TDxAOa_a0yI=.3daa6dc8-2844-4fe4-a2ea-a40e9ee38eaf@github.com>

On Tue, 4 Apr 2023 16:07:54 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Recommended changes

These?should rethrow all?`Error`s:

src/java.base/share/classes/java/lang/StringConcatHelper.java line 364:

> 362:         try {
> 363:             return value.prepend(indexCoder, buf);
> 364:         } catch (Throwable ex) {

This?should rethrow?errors (such?as?`OutOfMemoryError`):
Suggestion:

        } catch (Error err) {
            throw err;
        } catch (Throwable ex) {

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 100:

> 98:         try {
> 99:             return (List<Object>)valuesMH.invokeExact(this);
> 100:         } catch (RuntimeException | OutOfMemoryError ex) {

Suggestion:

        } catch (RuntimeException | Error ex) {

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 111:

> 109:         try {
> 110:             return (String) interpolateMH.invokeExact(this);
> 111:         } catch (RuntimeException | OutOfMemoryError ex) {

Suggestion:

        } catch (RuntimeException | Error ex) {

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

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1376048871
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1160580952
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1160595676
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1160595790

From duke at openjdk.org  Fri Apr  7 10:01:30 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 7 Apr 2023 10:01:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v3]
In-Reply-To: <QTuXZCQBCHnfr-n7W3F7K3vEr88fCuQVsvRcikoTbOM=.020347ed-48ee-4beb-97e6-60ab0f5f4da9@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
 <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>
 <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com>
 <jFftqftzDSSQqAYaG6f944PpB4L11OJWh0TkJjYk-nM=.692bccb6-304f-4173-8538-5644e36dff2f@github.com>
 <QTuXZCQBCHnfr-n7W3F7K3vEr88fCuQVsvRcikoTbOM=.020347ed-48ee-4beb-97e6-60ab0f5f4da9@github.com>
Message-ID: <NTKibLWXQzrCIBY8wvYUh_dNOj2OSUyqrkQYUd7Zk-A=.bc1d54f2-a304-4364-aba0-64228e90d64c@github.com>

On Tue, 1 Nov 2022 00:02:46 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> Anyway, i think you are right, this can be public
>
> If this is a public int field, it will be inlined to class file byte code at compile time, which may not be what you want if this value needs to change in the future. If this needs to be exposed, should it be as a public method?

It?can?also be?initialised in?a?static?initialiser, which?will make?it no?longer?inlined at?use?sites:
Suggestion:

    public static final int MAX_INDY_CONCAT_ARG_SLOTS;
    static { MAX_INDY_CONCAT_ARG_SLOTS = 200; }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1160586124

From duke at openjdk.org  Fri Apr  7 10:06:09 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 7 Apr 2023 10:06:09 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <xPongRDOBHRh5URyYf3cFcGGh2gMdwvCPbsnCdVuQ3Y=.23496da3-d68d-409e-bea1-53a1ec7f66b0@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <z8EuL6vvnVdCVsR68uEbPMFxyCabYlTLxrgh-xRzEj0=.619c4a4b-1bb0-44d5-88cf-50b801c4049d@github.com>
 <nc_w6DjozGQhwsm1-vZr-xgc0tV1HPheuWyA0QAo0CA=.f4b271b0-b08e-47a1-8353-12fe26707d8a@github.com>
 <yyHezPsdOG8L8tnGGSIR1NfKkmLGvG2fnlGt1TbdWZ4=.0f7ad875-d8c5-4d31-9da4-4fe70eaacdda@github.com>
 <RSr_REqgL5AEiDIRHJmvhlDoHBV5XclUTFwt9ALIOUc=.b9986985-0d6f-4daa-ab65-69acb188a52f@github.com>
 <xPongRDOBHRh5URyYf3cFcGGh2gMdwvCPbsnCdVuQ3Y=.23496da3-d68d-409e-bea1-53a1ec7f66b0@github.com>
Message-ID: <HqhOSr8ECbP9BRzm52aeWixWz4gCk7GZYLJt-oyGWEU=.396c01dd-f83c-4f91-92eb-afcb6b159325@github.com>

On Fri, 7 Apr 2023 09:28:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We also have PPC big-endian, it is used by AIX (and you can also run Linux with PPC big-endian). Why omit that?
> > > os.arch for AIX is "ppc64".
> > 
> > 
> > So I think you are saying that there are aix-ppc64 and linux-ppc64le builds so this enum needs to have values for both ppc64 and ppc64le.
> 
> Yes, precisely.

In?that?case, they?should probably be?called `PPC64BE` and?`PPC64LE`?to?disambiguate between?them.

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1500140904

From lancea at openjdk.org  Fri Apr  7 10:20:43 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 7 Apr 2023 10:20:43 GMT
Subject: RFR: 8305696: (zipfs) Avoid redundant LinkedHashMap.containsKey
 call ZipFileSystem.makeParentDirs
In-Reply-To: <L1C6gVVln23VejqKo9Qab54sNHc8tLuQoyVL3Y9uc9o=.9f0f0cdb-2e9c-42e6-801b-d1aa64dc8bc5@github.com>
References: <L1C6gVVln23VejqKo9Qab54sNHc8tLuQoyVL3Y9uc9o=.9f0f0cdb-2e9c-42e6-801b-d1aa64dc8bc5@github.com>
Message-ID: <Nt74hQwkNEt8U99wMv4KxyR4FyhrxZts4_HhW5AgPbg=.27c8c828-581e-416a-8d99-7349003fb98d@github.com>

On Mon, 3 Apr 2023 17:16:26 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `LinkedHashMap<IndexNode, IndexNode>` `ZipFileSystem.inodes` contains only non-null values. It means instead of separate `containsKey`+`get` calls, we can use single `LinkedHashMap.get` call and then compare result with `null`.
> Result code is a bit simpler and faster.
> 
> Testing: Linux x64 `java/nio`, `jdk/nio`

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13304#pullrequestreview-1376064521

From stuefe at openjdk.org  Fri Apr  7 10:26:50 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Apr 2023 10:26:50 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
Message-ID: <j7jhRBvTbbRGN7Adkc8kY-5ZTRTAUGgG5hOLldVrh4Y=.d9ca1ba2-0dd1-4280-a321-46fb2cf65288@github.com>

On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded qualified export from java.base to jdk.attach

src/java.base/share/classes/jdk/internal/util/Architecture.java line 41:

> 39:     AARCH64(),
> 40:     RISCV64(),
> 41:     S390(),

Why getting rid of the X in s390x? There has not been an s390 linux kernel in almost ten years.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160610072

From jpai at openjdk.org  Fri Apr  7 10:55:49 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 10:55:49 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <j7jhRBvTbbRGN7Adkc8kY-5ZTRTAUGgG5hOLldVrh4Y=.d9ca1ba2-0dd1-4280-a321-46fb2cf65288@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <j7jhRBvTbbRGN7Adkc8kY-5ZTRTAUGgG5hOLldVrh4Y=.d9ca1ba2-0dd1-4280-a321-46fb2cf65288@github.com>
Message-ID: <1rnezvB6dF2qCWucljVIY9AO_mGGDCwZfah9pntJFmU=.391a8c44-602e-49d0-a8b7-379d174712ce@github.com>

On Fri, 7 Apr 2023 10:24:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unneeded qualified export from java.base to jdk.attach
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 41:
> 
>> 39:     AARCH64(),
>> 40:     RISCV64(),
>> 41:     S390(),
> 
> Why getting rid of the X in s390x? There has not been an s390 linux kernel in almost ten years.

Hello Thomas, that change was based on the review comment here https://github.com/openjdk/jdk/pull/13357#discussion_r1159810942

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160623813

From stuefe at openjdk.org  Fri Apr  7 11:24:50 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Apr 2023 11:24:50 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <1rnezvB6dF2qCWucljVIY9AO_mGGDCwZfah9pntJFmU=.391a8c44-602e-49d0-a8b7-379d174712ce@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <j7jhRBvTbbRGN7Adkc8kY-5ZTRTAUGgG5hOLldVrh4Y=.d9ca1ba2-0dd1-4280-a321-46fb2cf65288@github.com>
 <1rnezvB6dF2qCWucljVIY9AO_mGGDCwZfah9pntJFmU=.391a8c44-602e-49d0-a8b7-379d174712ce@github.com>
Message-ID: <tsc6LlSdPu19saBv3IHUJsjaw-XTxrO3Syvemm4ZasY=.583024c6-5298-4fab-a359-8fdba0905fdc@github.com>

On Fri, 7 Apr 2023 10:52:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/Architecture.java line 41:
>> 
>>> 39:     AARCH64(),
>>> 40:     RISCV64(),
>>> 41:     S390(),
>> 
>> Why getting rid of the X in s390x? There has not been an s390 linux kernel in almost ten years.
>
> Hello Thomas, that change was based on the review comment here https://github.com/openjdk/jdk/pull/13357#discussion_r1159810942

Okay, Lutz is the expert here. Sorry for the noise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160637280

From duke at openjdk.org  Fri Apr  7 11:38:53 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 7 Apr 2023 11:38:53 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v9]
In-Reply-To: <-TIa9k1sR_2QUcm_ebyVk54FuDJS4OxaxPuoOGOYmyE=.372021a2-ff5c-4726-a040-598cff334dae@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <-TIa9k1sR_2QUcm_ebyVk54FuDJS4OxaxPuoOGOYmyE=.372021a2-ff5c-4726-a040-598cff334dae@github.com>
Message-ID: <gAYxM04D64Fly-PQufru4lvWK-7MrIHIA6kN8upCKHg=.42b39da4-8624-4f90-a293-ed117a141451@github.com>

On Thu, 6 Apr 2023 20:47:10 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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with a check to the class data. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Require an original lookup in constructor arguments to prevent unintended instantiation

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

> 315:                 cob.aload(1);
> 316:                 cob.invokevirtual(CD_MethodHandles_Lookup, "lookupClass", MTD_Class);
> 317:                 cob.constantInstruction(proxyDesc);

This?probably can?t?use?`LDC` of?`CONSTANT_Class`, as?that can?t?refer to?hidden?classes:
Suggestion:

                cob.aload(0);
                cob.invokevirtual(CD_Object, "getClass", MTD_Class);


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

Having?a?helper constant?bootstrap of?the?following?form would?allow to?obtain the?current?class using?a?dynamic?constant:

public static final Class<?> lookupClass(
	final MethodHandles.Lookup lookup,
	final String name,
	@SuppressWarnings("rawtypes") // needed to allow `Class.class`
	final Class<? extends Class> type
) {
	requireNonNull(lookup);
	requireNonNull(type);
	if (type != Class.class) {
		throw new IllegalArgumentException();
	}
	return lookup.lookupClass();
}

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

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

From jkuhn at openjdk.org  Fri Apr  7 11:44:49 2023
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Fri, 7 Apr 2023 11:44:49 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v9]
In-Reply-To: <gAYxM04D64Fly-PQufru4lvWK-7MrIHIA6kN8upCKHg=.42b39da4-8624-4f90-a293-ed117a141451@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <-TIa9k1sR_2QUcm_ebyVk54FuDJS4OxaxPuoOGOYmyE=.372021a2-ff5c-4726-a040-598cff334dae@github.com>
 <gAYxM04D64Fly-PQufru4lvWK-7MrIHIA6kN8upCKHg=.42b39da4-8624-4f90-a293-ed117a141451@github.com>
Message-ID: <b47by8Y4-_d2PNleCNlWsI2uumvB_m3-veDSYRtykUE=.ba510b70-45e1-4bc1-ade2-cf84de6a8f21@github.com>

On Fri, 7 Apr 2023 11:20:12 GMT, ExE Boss <duke at openjdk.org> wrote:

> that can?t refer to hidden classes

No, that is exactly the **one and only thing** that can refer to the hidden class:

> * On any attempt to resolve the entry in the run-time constant pool indicated by `this_class`, the symbolic reference is considered to be resolved to `C` and resolution always succeeds immediately.

[(Souce)](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass%28byte%5B%5D,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...%29)

As the passed class refers to `this_class`, that use is fine.

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

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

From alanb at openjdk.org  Fri Apr  7 11:54:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 11:54:00 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v7]
In-Reply-To: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
Message-ID: <-mPFKr9vh4NoXyvJfYAlS0UmtkuxdKdk0UZpm6lcif0=.adcf09ea-f301-4c82-93d0-f6cfcc7a8b51@github.com>

> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
> 
> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
> 
> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
> 
> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
> - ThreadPerTaskExecutor is changed to use FutureTask.
> 
> Testing: tier1-6.

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

 - Merge
 - Test updates to address review comments
 - Test/comments updates
 - Merge
 - Expand tests for jdk.ThreadSleep event
 - Review feedback
 - Merge
 - Fix ThreadSleepEvent again
 - Test updates
 - ThreadSleepEvent refactoring
 - ... and 3 more: https://git.openjdk.org/jdk/compare/a19243ec...cd680f66

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13203/files
  - new: https://git.openjdk.org/jdk/pull/13203/files/a5bb3fd9..cd680f66

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

  Stats: 3163 lines in 90 files changed: 2642 ins; 442 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/13203.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13203/head:pull/13203

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

From lucy at openjdk.org  Fri Apr  7 12:08:49 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 7 Apr 2023 12:08:49 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <tsc6LlSdPu19saBv3IHUJsjaw-XTxrO3Syvemm4ZasY=.583024c6-5298-4fab-a359-8fdba0905fdc@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <j7jhRBvTbbRGN7Adkc8kY-5ZTRTAUGgG5hOLldVrh4Y=.d9ca1ba2-0dd1-4280-a321-46fb2cf65288@github.com>
 <1rnezvB6dF2qCWucljVIY9AO_mGGDCwZfah9pntJFmU=.391a8c44-602e-49d0-a8b7-379d174712ce@github.com>
 <tsc6LlSdPu19saBv3IHUJsjaw-XTxrO3Syvemm4ZasY=.583024c6-5298-4fab-a359-8fdba0905fdc@github.com>
Message-ID: <Xvuj-FNTekaixILX1yWW729EsDfmTv_KN4iNp08-eWA=.742dfc08-383b-4afe-af0c-87098d7e177c@github.com>

On Fri, 7 Apr 2023 11:21:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hello Thomas, that change was based on the review comment here https://github.com/openjdk/jdk/pull/13357#discussion_r1159810942
>
> Okay, Lutz is the expert here. Sorry for the noise.

Just to let my voice be heard directly after being cited several times: s390 is used to designate the CPU architecture. The arch-specific files are stored in src/hotspot/cpu/s390 for that reason. Back in the days when SAP contributed the s390 port, there was a discussion which architecture name to use. SAP had used zArch_64 which more closely reflects what the port really is (a 64-bit only port to IBM's z/Architecture). It was a majority decision to use s390 for some historic reasons (I don't remember exactly anymore).

s390x is (almost) always used in conjunction with a Linux OS port. In that respect, linuxs390x is a tautology. OpenJDK does not use this tautology, see src/hotspot/os_cpu/linux_s390 for example.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160657249

From jpai at openjdk.org  Fri Apr  7 12:44:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 12:44:51 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v7]
In-Reply-To: <-mPFKr9vh4NoXyvJfYAlS0UmtkuxdKdk0UZpm6lcif0=.adcf09ea-f301-4c82-93d0-f6cfcc7a8b51@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <-mPFKr9vh4NoXyvJfYAlS0UmtkuxdKdk0UZpm6lcif0=.adcf09ea-f301-4c82-93d0-f6cfcc7a8b51@github.com>
Message-ID: <2mMJCOu4-A2LKcNdNqVHXGy_yg8Yncc67BysDb7sedc=.5852ccfc-c175-46c3-9bc0-a9058320215f@github.com>

On Fri, 7 Apr 2023 11:54:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> 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 13 additional commits since the last revision:
> 
>  - Merge
>  - Test updates to address review comments
>  - Test/comments updates
>  - Merge
>  - Expand tests for jdk.ThreadSleep event
>  - Review feedback
>  - Merge
>  - Fix ThreadSleepEvent again
>  - Test updates
>  - ThreadSleepEvent refactoring
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/af05156d...cd680f66

Thank you for the updates Alan, they look fine to me. 

I've gone through the java side changes in this PR and the tests (except for hotspot tests) and they all look fine to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13203#pullrequestreview-1376162404

From duke at openjdk.org  Fri Apr  7 12:56:51 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 7 Apr 2023 12:56:51 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v9]
In-Reply-To: <b47by8Y4-_d2PNleCNlWsI2uumvB_m3-veDSYRtykUE=.ba510b70-45e1-4bc1-ade2-cf84de6a8f21@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <-TIa9k1sR_2QUcm_ebyVk54FuDJS4OxaxPuoOGOYmyE=.372021a2-ff5c-4726-a040-598cff334dae@github.com>
 <gAYxM04D64Fly-PQufru4lvWK-7MrIHIA6kN8upCKHg=.42b39da4-8624-4f90-a293-ed117a141451@github.com>
 <b47by8Y4-_d2PNleCNlWsI2uumvB_m3-veDSYRtykUE=.ba510b70-45e1-4bc1-ade2-cf84de6a8f21@github.com>
Message-ID: <Xh8dkdi891BiwKvd0TrA7YbGlPh2f0lsbMCW4c5I2BY=.3dd410ba-4690-4e00-80d9-8734269fcf9f@github.com>

On Fri, 7 Apr 2023 11:41:52 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 317:
>> 
>>> 315:                 cob.aload(1);
>>> 316:                 cob.invokevirtual(CD_MethodHandles_Lookup, "lookupClass", MTD_Class);
>>> 317:                 cob.constantInstruction(proxyDesc);
>> 
>> This?probably can?t?use?`LDC` of?`CONSTANT_Class`, as?that can?t?refer to?hidden?classes:
>> Suggestion:
>> 
>>                 cob.aload(0);
>>                 cob.invokevirtual(CD_Object, "getClass", MTD_Class);
>> 
>> 
>> --------------------------------------------------------------------------------
>> 
>> Having?a?helper constant?bootstrap of?the?following?form would?allow to?obtain the?current?class using?a?dynamic?constant:
>> 
>> public static final Class<?> lookupClass(
>> 	final MethodHandles.Lookup lookup,
>> 	final String name,
>> 	@SuppressWarnings("rawtypes") // needed to allow `Class.class`
>> 	final Class<? extends Class> type
>> ) {
>> 	requireNonNull(lookup);
>> 	requireNonNull(type);
>> 	if (type != Class.class) {
>> 		throw new IllegalArgumentException();
>> 	}
>> 	return lookup.lookupClass();
>> }
>
>> that can?t refer to hidden classes
> 
> No, that is exactly the **one and only thing** that can refer to the hidden class:
> 
>> * On any attempt to resolve the entry in the run-time constant pool indicated by `this_class`, the symbolic reference is considered to be resolved to `C` and resolution always succeeds immediately.
> 
> [(Souce)](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass%28byte%5B%5D,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...%29)
> 
> As the passed class refers to `this_class`, that use is fine.

The?**JVM**?spec doesn?t?mention?that anywhere?though.

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

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

From liach at openjdk.org  Fri Apr  7 13:19:50 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Apr 2023 13:19:50 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v9]
In-Reply-To: <Xh8dkdi891BiwKvd0TrA7YbGlPh2f0lsbMCW4c5I2BY=.3dd410ba-4690-4e00-80d9-8734269fcf9f@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <-TIa9k1sR_2QUcm_ebyVk54FuDJS4OxaxPuoOGOYmyE=.372021a2-ff5c-4726-a040-598cff334dae@github.com>
 <gAYxM04D64Fly-PQufru4lvWK-7MrIHIA6kN8upCKHg=.42b39da4-8624-4f90-a293-ed117a141451@github.com>
 <b47by8Y4-_d2PNleCNlWsI2uumvB_m3-veDSYRtykUE=.ba510b70-45e1-4bc1-ade2-cf84de6a8f21@github.com>
 <Xh8dkdi891BiwKvd0TrA7YbGlPh2f0lsbMCW4c5I2BY=.3dd410ba-4690-4e00-80d9-8734269fcf9f@github.com>
Message-ID: <yxU-U7S7wHT-QdIb5nE_cO95_wYFVvsMFN_oGKrbVf0=.793c1081-a3e9-44d8-8d04-34d5731ee1a8@github.com>

On Fri, 7 Apr 2023 12:54:01 GMT, ExE Boss <duke at openjdk.org> wrote:

> The?**JVM**?spec doesn?t?mention?that anywhere?though.

I don't think JVMS mentions hidden classes at all. You have to refer to the specification of Lookup.defineHiddenClass, as hidden classes were originated from VM anonymous classes added back in Java 7 with j.l.invoke package (JSR 292) as an implementation artifact

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

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

From rgiulietti at openjdk.org  Fri Apr  7 14:11:36 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 7 Apr 2023 14:11:36 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v2]
In-Reply-To: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
Message-ID: <dg6qtk5ave9VNr7E0Jf7nHBB9OgkJdJq-A_17OsP094=.1113df8d-50f7-4baa-a8e8-8aef1ee61ac0@github.com>

> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.

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

  8305486: Add split() variants that keep the delimiters to String and j.u.r.Pattern
  Restored original JavaDoc to existing methods.
  Replaced proposed parametrized split(*, boolean) methods with suggested splitWithDelimiters(*) variants.
  Adjusted tests accordingly.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13305/files
  - new: https://git.openjdk.org/jdk/pull/13305/files/e7b7c659..597ee0ce

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

  Stats: 360 lines in 3 files changed: 192 ins; 79 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/13305.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13305/head:pull/13305

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

From rgiulietti at openjdk.org  Fri Apr  7 14:12:41 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 7 Apr 2023 14:12:41 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern
In-Reply-To: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
Message-ID: <7lEIsG3_pynI5zfhZ6oPd6cGhSg0JGc-YqbyIJelMp8=.39ac8899-9dd2-4f42-bb2e-9e9cbdd4fe5d@github.com>

On Mon, 3 Apr 2023 17:43:55 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.

@RogerRiggs All concerns should have been addressed in the last commit, I hope.

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

PR Comment: https://git.openjdk.org/jdk/pull/13305#issuecomment-1500325392

From duke at openjdk.org  Fri Apr  7 14:16:32 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 7 Apr 2023 14:16:32 GMT
Subject: RFR: 8291023: FileOutputStream.close() re-entrantly invokes itself
 via FileChannel.close() [v2]
In-Reply-To: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
References: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
Message-ID: <FrQ1lwdHlpwzS3cDkvuQGxxvvC7wPowaSHyNGvf0A-Y=.aa703b7e-5b09-4e7e-88d4-d84073c410f7@github.com>

> IO stream classes like `FileOutputStream` can have assocated NIO channels.
> 
> When `close()` is invoked on one of these classes, it in turn invokes `close()` on the associated channel (if any). But when the associated channel's `close()` method is invoked, it in turn invokes `close()` on the associated stream (if any).
> 
> As a result, these IO stream `close()` methods invoke themselves reentrantly when there is an associated channel.
> 
> This is not a problem for these classes because they are written to handle this (i.e., they are idempotent), but it can be surprising (or worse, just silently bug-inducing) for subclasses that override `close()`.
> 
> There are two possible ways to address this:
> 1. Modify the code to detect and avoid the (unnecessary) reentrant invocations
> 2. Add a `@implNote` to the Javadoc so subclass implementers are made aware
> 
> This patch takes the second, more conservative approach.

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Apply Javadoc improvements suggested in review.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13379/files
  - new: https://git.openjdk.org/jdk/pull/13379/files/d3409a57..9978b52e

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

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

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

From duke at openjdk.org  Fri Apr  7 14:16:34 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 7 Apr 2023 14:16:34 GMT
Subject: RFR: 8291023: FileOutputStream.close() re-entrantly invokes itself
 via FileChannel.close()
In-Reply-To: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
References: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
Message-ID: <7BvuwzY0e1z7qBZy7u_ERurpT3Evf7pr1PxoLkEgXy4=.785ec2dc-de6a-4bfe-b07d-8add9b93e461@github.com>

On Thu, 6 Apr 2023 22:36:33 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> IO stream classes like `FileOutputStream` can have assocated NIO channels.
> 
> When `close()` is invoked on one of these classes, it in turn invokes `close()` on the associated channel (if any). But when the associated channel's `close()` method is invoked, it in turn invokes `close()` on the associated stream (if any).
> 
> As a result, these IO stream `close()` methods invoke themselves reentrantly when there is an associated channel.
> 
> This is not a problem for these classes because they are written to handle this (i.e., they are idempotent), but it can be surprising (or worse, just silently bug-inducing) for subclasses that override `close()`.
> 
> There are two possible ways to address this:
> 1. Modify the code to detect and avoid the (unnecessary) reentrant invocations
> 2. Add a `@implNote` to the Javadoc so subclass implementers are made aware
> 
> This patch takes the second, more conservative approach.

Good suggestions - thanks. Implemented in 9978b52ed73.

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

PR Comment: https://git.openjdk.org/jdk/pull/13379#issuecomment-1500326488

From jbhateja at openjdk.org  Fri Apr  7 14:22:56 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 7 Apr 2023 14:22:56 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
Message-ID: <o-4GAbPsOv3lW_IFRcx5Ii_rPgIJ7pTH1axmmtd7oaA=.c2c248b1-bd0c-43ff-ba25-fb90be3d98a3@github.com>

On Fri, 31 Mar 2023 12:25:16 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small cosmetics

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractShuffle.java line 96:

> 94:         }
> 95:         Vector<?> shufvec = this.toBitsVector();
> 96:         VectorMask<?> vecmask = shufvec.compare(VectorOperators.LT, 0);

This may impact the intrinsification over AVX1 targets for floating point shuffles. Since bits vector is an integral vector and AVX1 does support 32 byte floats but not 32 byte integral vectors.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 226:

> 224: 
> 225:         AbstractSpecies<?> species = vspecies().asIntegral();
> 226:         Vector iota = species.iota();

we can do an early exist by returning species..iota() if start = 0 and step = 1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1160650526
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1160672743

From jbhateja at openjdk.org  Fri Apr  7 14:22:57 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 7 Apr 2023 14:22:57 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: <o-4GAbPsOv3lW_IFRcx5Ii_rPgIJ7pTH1axmmtd7oaA=.c2c248b1-bd0c-43ff-ba25-fb90be3d98a3@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
 <o-4GAbPsOv3lW_IFRcx5Ii_rPgIJ7pTH1axmmtd7oaA=.c2c248b1-bd0c-43ff-ba25-fb90be3d98a3@github.com>
Message-ID: <fmI--ihud_n-PgIsWGOcty7kScPkSO1rZltNx4ZB2xA=.82c99f84-ede6-4531-9aa8-cd5212121b40@github.com>

On Fri, 7 Apr 2023 12:36:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   small cosmetics
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 226:
> 
>> 224: 
>> 225:         AbstractSpecies<?> species = vspecies().asIntegral();
>> 226:         Vector iota = species.iota();
> 
> we can do an early exist by returning species..iota() if start = 0 and step = 1

Power of two step count may be replaced by logical right shifts. But special handling may impact generic path
, currently c2 inline expander handles these special cases.

Alternatively we can keep this implementation at its and enhance vector idealizations to handle identity scenarios, multiply by 1, addition by 0, shift replacement for power of two multiply, since their scalar counterparts do handle these cases and SLP generated code gets a benefit of that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1160706670

From rriggs at openjdk.org  Fri Apr  7 14:24:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Apr 2023 14:24:37 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v4]
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <Usevw300y_mQRvFgSwqQlXsxI8LHs0hb38Xk6PuTx1g=.64512eff-175f-4da7-a1e2-34afd8936b3c@github.com>

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

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

  Remove errant space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13335/files
  - new: https://git.openjdk.org/jdk/pull/13335/files/5546b824..b9267942

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

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

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

From liach at openjdk.org  Fri Apr  7 14:35:41 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Apr 2023 14:35:41 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v10]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <OfxL6Odm5c304zI2CefUBX4tR_zO3x2QEl8Vi13l2S8=.2e1ed129-1523-4081-88cb-0781e65f1cdf@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 implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with a check to the class data. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> [^1]: single abstract method

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

  Fix test that depend on WrapperInstance

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/2401dc94..0bfda844

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

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 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  Fri Apr  7 14:43:50 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Apr 2023 14:43:50 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <3iWq-g0ji56gRdTxUVtO64dy60rPmtQsQ_64HWoCMlY=.300723e5-d788-42f4-9d40-bb768390fc0b@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <3iWq-g0ji56gRdTxUVtO64dy60rPmtQsQ_64HWoCMlY=.300723e5-d788-42f4-9d40-bb768390fc0b@github.com>
Message-ID: <ZPU30OWEffB1RmzJKMcO52XNC4f7L-DZtzvd2I1mFk4=.3aff1b1c-1131-4364-89fe-a8081adb1f0a@github.com>

On Thu, 6 Apr 2023 22:44:52 GMT, Phil Race <prr at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unneeded qualified export from java.base to jdk.attach
>
> src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java line 169:
> 
>> 167:         // Load the appropriate DLLs
>> 168:         boolean is32on64 = false;
>> 169:         if (Architecture.isX86()) {
> 
> This would be another coupling of java.desktop into java.base internals and I don't think it worth it.
> Particularly because this check is obsolete !
> It is a remnant of when accessbridge was an unbundled download so provided both 32 and 64 bit.
> We don't even have  the file it is looking for in the build - even if someone did a 32 bit build.
> Instead of making this change a bug should be filed to remove this code.

Reverting; filed [8305745](https://bugs.openjdk.org/browse/JDK-8305745)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160748988

From emcmanus at openjdk.org  Fri Apr  7 15:32:43 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Fri, 7 Apr 2023 15:32:43 GMT
Subject: RFR: 8303919: Instant.ofEpochMilli says it can throw an exception
 that it can't
In-Reply-To: <KZTI-vNW52nDDiFr1qtbUBxKGGr6To04RWa7PMpcIjU=.38d302c5-15d6-446e-97d0-6f87f7ff0f77@github.com>
References: <KZTI-vNW52nDDiFr1qtbUBxKGGr6To04RWa7PMpcIjU=.38d302c5-15d6-446e-97d0-6f87f7ff0f77@github.com>
Message-ID: <FYBLru1RjX-c5ppAwnq6yF6Qt9IV0gc9Li4BuCsHZzc=.6b073e71-064e-4946-bc75-7bc1f5768ed3@github.com>

On Thu, 9 Mar 2023 19:49:29 GMT, Eamonn McManus <emcmanus at openjdk.org> wrote:

> Instant.ofEpochMilli says this:
> 
> 
> @throws DateTimeException if the instant exceeds the maximum or minimum instant
> 
> 
> But that can't happen. Even given `Long.MIN_VALUE` or `Long.MAX_VALUE` it does not throw. That's already implicitly tested in [`TestInstant`](https://github.com/openjdk/jdk/blob/a9dba565688a29bef8626488c47519008dcadbe8/test/jdk/java/time/test/java/time/TestInstant.java#L84), which calls it with both those values.

What do I need to do to help the CSR [JDK-8303926](https://bugs.openjdk.org/browse/JDK-8303926) progress?

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

PR Comment: https://git.openjdk.org/jdk/pull/12958#issuecomment-1500390622

From rriggs at openjdk.org  Fri Apr  7 15:38:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Apr 2023 15:38:44 GMT
Subject: RFR: 8303919: Instant.ofEpochMilli says it can throw an exception
 that it can't
In-Reply-To: <KZTI-vNW52nDDiFr1qtbUBxKGGr6To04RWa7PMpcIjU=.38d302c5-15d6-446e-97d0-6f87f7ff0f77@github.com>
References: <KZTI-vNW52nDDiFr1qtbUBxKGGr6To04RWa7PMpcIjU=.38d302c5-15d6-446e-97d0-6f87f7ff0f77@github.com>
Message-ID: <HbIfyamGL8qHeJltbrH58kiv0KXhnz3qFKps4YoVs-c=.427c2103-3b1b-4cdc-84f1-1833a13aa7ad@github.com>

On Thu, 9 Mar 2023 19:49:29 GMT, Eamonn McManus <emcmanus at openjdk.org> wrote:

> Instant.ofEpochMilli says this:
> 
> 
> @throws DateTimeException if the instant exceeds the maximum or minimum instant
> 
> 
> But that can't happen. Even given `Long.MIN_VALUE` or `Long.MAX_VALUE` it does not throw. That's already implicitly tested in [`TestInstant`](https://github.com/openjdk/jdk/blob/a9dba565688a29bef8626488c47519008dcadbe8/test/jdk/java/time/test/java/time/TestInstant.java#L84), which calls it with both those values.

It slipped too far down in my list.  
I Reviewed the CSR; you can mark it finalized.

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

PR Comment: https://git.openjdk.org/jdk/pull/12958#issuecomment-1500395509

From bpb at openjdk.org  Fri Apr  7 15:55:44 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 7 Apr 2023 15:55:44 GMT
Subject: RFR: 8291023: FileOutputStream.close() re-entrantly invokes itself
 via FileChannel.close() [v2]
In-Reply-To: <FrQ1lwdHlpwzS3cDkvuQGxxvvC7wPowaSHyNGvf0A-Y=.aa703b7e-5b09-4e7e-88d4-d84073c410f7@github.com>
References: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
 <FrQ1lwdHlpwzS3cDkvuQGxxvvC7wPowaSHyNGvf0A-Y=.aa703b7e-5b09-4e7e-88d4-d84073c410f7@github.com>
Message-ID: <YuyDmXB7S3e1NBBLzatf8DG0BmiNaTE9MDIqHCYXOlU=.8e205734-b1e7-49b1-9362-29870e4b12df@github.com>

On Fri, 7 Apr 2023 14:16:32 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> IO stream classes like `FileOutputStream` can have assocated NIO channels.
>> 
>> When `close()` is invoked on one of these classes, it in turn invokes `close()` on the associated channel (if any). But when the associated channel's `close()` method is invoked, it in turn invokes `close()` on the associated stream (if any).
>> 
>> As a result, these IO stream `close()` methods invoke themselves reentrantly when there is an associated channel.
>> 
>> This is not a problem for these classes because they are written to handle this (i.e., they are idempotent), but it can be surprising (or worse, just silently bug-inducing) for subclasses that override `close()`.
>> 
>> There are two possible ways to address this:
>> 1. Modify the code to detect and avoid the (unnecessary) reentrant invocations
>> 2. Add a `@implNote` to the Javadoc so subclass implementers are made aware
>> 
>> This patch takes the second, more conservative approach.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply Javadoc improvements suggested in review.

Perhaps the issue summary / PR title should be more like this?

Clarify reentrant behavior of the close method of FileInputStream, FileOutputStream, and RandomAccessFile

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

PR Comment: https://git.openjdk.org/jdk/pull/13379#issuecomment-1500409211

From alanb at openjdk.org  Fri Apr  7 16:13:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 16:13:41 GMT
Subject: RFR: 8291023: FileOutputStream.close() re-entrantly invokes itself
 via FileChannel.close() [v2]
In-Reply-To: <YuyDmXB7S3e1NBBLzatf8DG0BmiNaTE9MDIqHCYXOlU=.8e205734-b1e7-49b1-9362-29870e4b12df@github.com>
References: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
 <FrQ1lwdHlpwzS3cDkvuQGxxvvC7wPowaSHyNGvf0A-Y=.aa703b7e-5b09-4e7e-88d4-d84073c410f7@github.com>
 <YuyDmXB7S3e1NBBLzatf8DG0BmiNaTE9MDIqHCYXOlU=.8e205734-b1e7-49b1-9362-29870e4b12df@github.com>
Message-ID: <gxwn8NN9hOo2lBiyIPLJrxlLy5rq5j6wZT-CgsgcH7g=.f15771bb-2be9-4b44-8f4e-b913135bcbc0@github.com>

On Fri, 7 Apr 2023 15:53:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Perhaps the issue summary / PR title should be more like this?
> 
> ```
> Clarify reentrant behavior of the close method of FileInputStream, FileOutputStream, and RandomAccessFile
> ```

or better still, create a new issue in JBS as it is confusing to re-purpose JDK-8291023.

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

PR Comment: https://git.openjdk.org/jdk/pull/13379#issuecomment-1500424046

From duke at openjdk.org  Fri Apr  7 16:13:43 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 7 Apr 2023 16:13:43 GMT
Subject: RFR: 8291023: FileOutputStream.close() re-entrantly invokes itself
 via FileChannel.close() [v2]
In-Reply-To: <gxwn8NN9hOo2lBiyIPLJrxlLy5rq5j6wZT-CgsgcH7g=.f15771bb-2be9-4b44-8f4e-b913135bcbc0@github.com>
References: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
 <FrQ1lwdHlpwzS3cDkvuQGxxvvC7wPowaSHyNGvf0A-Y=.aa703b7e-5b09-4e7e-88d4-d84073c410f7@github.com>
 <YuyDmXB7S3e1NBBLzatf8DG0BmiNaTE9MDIqHCYXOlU=.8e205734-b1e7-49b1-9362-29870e4b12df@github.com>
 <gxwn8NN9hOo2lBiyIPLJrxlLy5rq5j6wZT-CgsgcH7g=.f15771bb-2be9-4b44-8f4e-b913135bcbc0@github.com>
Message-ID: <I6UsLKuoqWgHt6_rT3jhzomoj-IuIgh_bwBXlg1C1g4=.6497c19b-1cf8-469f-b0b7-7056ff706f06@github.com>

On Fri, 7 Apr 2023 16:09:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Perhaps the issue summary / PR title should be more like this?

I'm not so sure. What you suggest describes this fix for this bug, but it doesn't really describe the bug itself - instead, the bug argues that the reentrant behavior is wrong (though it does admit better documentation would help somewhat).

I'm not sure what the official policy is here on bug summaries vs. PR's, etc.

> or better still, create a new issue in JBS as it is confusing to re-purpose JDK-8291023.

OK, good compromise. I'll do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/13379#issuecomment-1500424529
PR Comment: https://git.openjdk.org/jdk/pull/13379#issuecomment-1500425283

From alanb at openjdk.org  Fri Apr  7 16:32:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 16:32:48 GMT
Subject: RFR: 8302819: Remove JAR Index [v6]
In-Reply-To: <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
Message-ID: <7c4SBE39xUiS01y6-GM-uH3F-tL_H975S1bgEwWsrLs=.9c69b6cc-bcdd-44ee-81e5-f88ad9f7dcde@github.com>

On Fri, 7 Apr 2023 07:47:49 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a note in the --help for --generate-index that this option is deprecated and may be removed in a future release.

I've updated the CSR to align it with the proposed solution. Please review again and if you happy, press "Finalize".

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1500441305

From duke at openjdk.org  Fri Apr  7 16:36:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 7 Apr 2023 16:36:49 GMT
Subject: RFR: 8302819: Remove JAR Index [v6]
In-Reply-To: <7c4SBE39xUiS01y6-GM-uH3F-tL_H975S1bgEwWsrLs=.9c69b6cc-bcdd-44ee-81e5-f88ad9f7dcde@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
 <7c4SBE39xUiS01y6-GM-uH3F-tL_H975S1bgEwWsrLs=.9c69b6cc-bcdd-44ee-81e5-f88ad9f7dcde@github.com>
Message-ID: <nmKbFFghmOj8RodCnv6wMTvUzaTBf0uSs1PVv-7J1lg=.2ea66677-3cfe-4ad9-9c31-9e3110e1f10e@github.com>

On Fri, 7 Apr 2023 16:29:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I've updated the CSR to align it with the proposed solution. Please review again and if you happy, press "Finalize".

Thanks, Alan, this looks good to me. I have pressed "Finalize".

The CSR makes promises about the Release Note. Do you think the current Release Note delivers on this promise?

https://bugs.openjdk.org/browse/JDK-8305603

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1500444352

From emcmanus at openjdk.org  Fri Apr  7 16:55:44 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Fri, 7 Apr 2023 16:55:44 GMT
Subject: RFR: 8303919: Instant.ofEpochMilli says it can throw an exception
 that it can't
In-Reply-To: <KZTI-vNW52nDDiFr1qtbUBxKGGr6To04RWa7PMpcIjU=.38d302c5-15d6-446e-97d0-6f87f7ff0f77@github.com>
References: <KZTI-vNW52nDDiFr1qtbUBxKGGr6To04RWa7PMpcIjU=.38d302c5-15d6-446e-97d0-6f87f7ff0f77@github.com>
Message-ID: <xe8tVcx6guJhNyFzfht9XwoTLn4B4qmFdlSaPPw1skQ=.dc7b5a9c-6a25-4b5c-8f6f-d3e4247033d5@github.com>

On Thu, 9 Mar 2023 19:49:29 GMT, Eamonn McManus <emcmanus at openjdk.org> wrote:

> Instant.ofEpochMilli says this:
> 
> 
> @throws DateTimeException if the instant exceeds the maximum or minimum instant
> 
> 
> But that can't happen. Even given `Long.MIN_VALUE` or `Long.MAX_VALUE` it does not throw. That's already implicitly tested in [`TestInstant`](https://github.com/openjdk/jdk/blob/a9dba565688a29bef8626488c47519008dcadbe8/test/jdk/java/time/test/java/time/TestInstant.java#L84), which calls it with both those values.

Done. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/12958#issuecomment-1500458471

From qamai at openjdk.org  Fri Apr  7 17:13:50 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 7 Apr 2023 17:13:50 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v7]
In-Reply-To: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
Message-ID: <PAuphp5Wv4xJIe8z3jCYNCHdPqP7yhbk4WX7SRnsst0=.58751569-e28b-4a68-9d49-5bebe56d7881@github.com>

> Hi,
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> 
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {external_word}
>     vpackusdw %xmm0,%xmm0,%xmm0
>     vpackuswb %xmm0,%xmm0,%xmm0
>     vpmovsxbd %xmm0,%xmm3
>     vpcmpgtd %xmm3,%xmm1,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fc2acb4e0d8
>     vpmovzxbd %xmm0,%xmm0
>     vpermd %ymm2,%ymm0,%ymm0
>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>     vmovdqu %xmm0,0x10(%r10)
> 
>     After:
>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>     vmovdqu 0x10(%r10),%xmm2
>     vpxor  %xmm0,%xmm0,%xmm0
>     vpcmpgtd %xmm2,%xmm0,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fa818b27cb1
>     vpermd %ymm1,%ymm2,%ymm0
>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>     vmovdqu %xmm0,0x10(%r10)
>     
> Please take a look and leave reviews. Thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  special case iotaShuffle

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13093/files
  - new: https://git.openjdk.org/jdk/pull/13093/files/97c8fabf..079a6b5f

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

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

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

From qamai at openjdk.org  Fri Apr  7 17:14:14 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 7 Apr 2023 17:14:14 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: <fmI--ihud_n-PgIsWGOcty7kScPkSO1rZltNx4ZB2xA=.82c99f84-ede6-4531-9aa8-cd5212121b40@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
 <o-4GAbPsOv3lW_IFRcx5Ii_rPgIJ7pTH1axmmtd7oaA=.c2c248b1-bd0c-43ff-ba25-fb90be3d98a3@github.com>
 <fmI--ihud_n-PgIsWGOcty7kScPkSO1rZltNx4ZB2xA=.82c99f84-ede6-4531-9aa8-cd5212121b40@github.com>
Message-ID: <buzCSAY9Gr87vBrf6IAEfpVejL33HGEvh0myKAsus6k=.237019ac-ff46-422c-8f37-ed7ceef8b4dc@github.com>

On Fri, 7 Apr 2023 13:36:22 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 226:
>> 
>>> 224: 
>>> 225:         AbstractSpecies<?> species = vspecies().asIntegral();
>>> 226:         Vector iota = species.iota();
>> 
>> we can do an early exist by returning species..iota() if start = 0 and step = 1
>
> Power of two step count may be replaced by logical right shifts. But special handling may impact generic path
> , currently c2 inline expander handles these special cases.
> 
> Alternatively we can keep this implementation at its and enhance vector idealizations to handle identity scenarios, multiply by 1, addition by 0, shift replacement for power of two multiply, since their scalar counterparts do handle these cases and SLP generated code gets a benefit of that.

Thanks a lot for your review, I think that transforming a multiplication by a power of 2 into a shift can be done by the C2 compiler. I have added the special case for `start = 0 && step == 1` since it may be more common and can be optimised away when the arguments are constants.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1160841447

From jlu at openjdk.org  Fri Apr  7 17:27:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 7 Apr 2023 17:27:40 GMT
Subject: RFR: 6218123: (cal) API: Spec for GregorianCalendar constructors and
 Calendar getInstance is inconsistent.
Message-ID: <Y6sYxUG7fkJL1Lsu4JNIzzbLtwU8BPcm59_QsiURv4o=.1e74a01f-5950-45cc-acec-0217e7fb9094@github.com>

The GregorianCalendar constructors and Calendar.getInstance() methods that take TimeZone or Locale throw a NullPointerException if any values are null. 

This PR updates the javadoc to make this apparent.

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

Commit messages:
 - Adjust wording
 - Document exceptions

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

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

From alanb at openjdk.org  Fri Apr  7 17:59:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 17:59:46 GMT
Subject: RFR: 8305748: Clarify reentrant behavior of close() in
 FileInputStream, FileOutputStream, and RandomAccessFile [v2]
In-Reply-To: <FrQ1lwdHlpwzS3cDkvuQGxxvvC7wPowaSHyNGvf0A-Y=.aa703b7e-5b09-4e7e-88d4-d84073c410f7@github.com>
References: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
 <FrQ1lwdHlpwzS3cDkvuQGxxvvC7wPowaSHyNGvf0A-Y=.aa703b7e-5b09-4e7e-88d4-d84073c410f7@github.com>
Message-ID: <fxBykJLGjvCCzMFZ4IAwCKQDUxJvpedXGAFOhQmcqkM=.7b55f68e-0240-4c0a-bcc8-ba3c061f642a@github.com>

On Fri, 7 Apr 2023 14:16:32 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> IO stream classes like `FileOutputStream` can have assocated NIO channels.
>> 
>> When `close()` is invoked on one of these classes, it in turn invokes `close()` on the associated channel (if any). But when the associated channel's `close()` method is invoked, it in turn invokes `close()` on the associated stream (if any).
>> 
>> As a result, these IO stream `close()` methods invoke themselves reentrantly when there is an associated channel.
>> 
>> This is not a problem for these classes because they are written to handle this (i.e., they are idempotent), but it can be surprising (or worse, just silently bug-inducing) for subclasses that override `close()`.
>> 
>> There are two possible ways to address this:
>> 1. Modify the code to detect and avoid the (unnecessary) reentrant invocations
>> 2. Add a `@implNote` to the Javadoc so subclass implementers are made aware
>> 
>> This patch takes the second, more conservative approach.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply Javadoc improvements suggested in review.

src/java.base/share/classes/java/io/FileInputStream.java line 503:

> 501:      *
> 502:      * @apiNote
> 503:      * When this stream has an associated channel, this method may invoke

I don't think a method can have more than one apiNote so the existing note will run into this text. Replacing @apiNote with a paragraph tag will help.

As regards the wording, then here's a suggestion that relies on the specification and avoids giving the impression that the close method directly calls itself recursively:

"If this stream has an associated channel then this method will close the channel, which in turn will close this stream. Subclasses that override this method should be prepared to handle possible reentrant invocation."

src/java.base/share/classes/java/io/RandomAccessFile.java line 701:

> 699:      *
> 700:      * @apiNote
> 701:      * When this file has an associated channel, this method may invoke

"this file" should be "this stream"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13379#discussion_r1160864473
PR Review Comment: https://git.openjdk.org/jdk/pull/13379#discussion_r1160864654

From jvernee at openjdk.org  Fri Apr  7 18:03:51 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Apr 2023 18:03:51 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v6]
In-Reply-To: <AjXnD01FmlYsgDkUIq5rzx6QoM_DRgGdGRz1WN16UHg=.b35cec7b-67c3-42a5-88f6-af9d055676fb@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@github.com>
 <2VczS9PzQByyD9ZeOoL5-w_YQ0LCHbFUtBas24NGdKE=.62539127-8dba-43b0-9cb7-a2744d7ba374@github.com>
 <9V7Lxo_MVbv4DNWm1hipUQsFZD4Qx_g1WF8uYggn69A=.a685dc78-1c1c-4357-b7d1-c15e85f1dfaf@github.com>
 <BXC_zNN0NIDsUpdjCWntEeOD04gwDdJKzY5XaiOMafU=.50d2eabb-19ec-42fb-99e1-4ab7133c62d8@github.com>
 <6YKY9npr2Dp9PO5bXb5OWvjJhRY-87LaVWelaIHP7BY=.c38048cd-50d8-4c76-9ecc-4d9bc1ae4b85@github.com>
 <ztUZF5ThyhCdD_NvaGNbgc6XQKpxGqa_lFasi1FtamA=.646964c6-084d-4a00-9d6a-0c10d30ee426@github.com>
 <oN8A3EPYZ8WDHW2YQDhKfa-eJvEmI0SOJMMh2sGIB_E=.f7bdb760-a72f-4c9e-92e4-d8ad6632dd50@github.com>
 <EX6f8EoOhL5Ja7odE4Sk9B7PgUNnawbUQa43g1fqTBk=.10166737-d2a9-40aa-b61d-b6f06997ed51@github.com>
 <AjXnD01FmlYsgDkUIq5rzx6QoM_DRgGdGRz1WN16UHg=.b35cec7b-67c3-42a5-88f6-af9d055676fb@github.com>
Message-ID: <YAxuEL_TWkDzqWFLSnmltRwe7u-GtaqMCMREILuXfnY=.09ae369a-418b-48c7-a805-cfe43e729df4@github.com>

On Thu, 6 Apr 2023 17:50:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> It looks like Proxy forcibly adds reads and exports edges from the module of the target interface to the module that defines the proxy: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/reflect/Proxy.java#L855-L868 I think we can do the same here
>
> I would support the putting InterfaceInfo in class data approach. With IMPL_LOOKUP, we currently define the hidden class in the same module as the interface. It's currently hard to define a hidden class without an anchor host class for a new module.

This seems like a reasonable solution.

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

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

From qamai at openjdk.org  Fri Apr  7 18:06:53 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 7 Apr 2023 18:06:53 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: <o-4GAbPsOv3lW_IFRcx5Ii_rPgIJ7pTH1axmmtd7oaA=.c2c248b1-bd0c-43ff-ba25-fb90be3d98a3@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
 <o-4GAbPsOv3lW_IFRcx5Ii_rPgIJ7pTH1axmmtd7oaA=.c2c248b1-bd0c-43ff-ba25-fb90be3d98a3@github.com>
Message-ID: <ItNcjfH6t0u6JCJxo9rJM9YDp8I3k4TvnZpdIykXHfs=.0c00585d-5737-4447-b6e6-240804fbc3a1@github.com>

On Fri, 7 Apr 2023 11:51:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   small cosmetics
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractShuffle.java line 96:
> 
>> 94:         }
>> 95:         Vector<?> shufvec = this.toBitsVector();
>> 96:         VectorMask<?> vecmask = shufvec.compare(VectorOperators.LT, 0);
> 
> This may impact the intrinsification over AVX1 targets for floating point shuffles. Since bits vector is an integral vector and AVX1 does support 32 byte floats but not 32 byte integral vectors.

Yes I think it is a drawback of this approach, however currently we do not support shuffling for 256-bit vectors on AVX1 machines either, and AVX1 seems to be a special case in this regard. This species of float and double may also be less common in the usage of Vector API since it is larger than SPECIES_PREFERRED.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1160868954

From duke at openjdk.org  Fri Apr  7 18:24:42 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 7 Apr 2023 18:24:42 GMT
Subject: RFR: 8305748: Clarify reentrant behavior of close() in
 FileInputStream, FileOutputStream, and RandomAccessFile [v3]
In-Reply-To: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
References: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
Message-ID: <RraYLzBv8h4DYRPcJWc32nsXMUq-icAEem6XvzIBP-A=.0708429e-61af-4e3e-ae1e-3b96a70f38d0@github.com>

> IO stream classes like `FileOutputStream` can have assocated NIO channels.
> 
> When `close()` is invoked on one of these classes, it in turn invokes `close()` on the associated channel (if any). But when the associated channel's `close()` method is invoked, it in turn invokes `close()` on the associated stream (if any).
> 
> As a result, these IO stream `close()` methods invoke themselves reentrantly when there is an associated channel.
> 
> This is not a problem for these classes because they are written to handle this (i.e., they are idempotent), but it can be surprising (or worse, just silently bug-inducing) for subclasses that override `close()`.
> 
> There are two possible ways to address this:
> 1. Modify the code to detect and avoid the (unnecessary) reentrant invocations
> 2. Add a `@implNote` to the Javadoc so subclass implementers are made aware
> 
> This patch takes the second, more conservative approach.

Archie L. Cobbs 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/13379/files
  - new: https://git.openjdk.org/jdk/pull/13379/files/9978b52e..90a13078

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

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

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

From naoto at openjdk.org  Fri Apr  7 20:27:43 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 7 Apr 2023 20:27:43 GMT
Subject: RFR: 6218123: (cal) API: Spec for GregorianCalendar constructors
 and Calendar getInstance is inconsistent.
In-Reply-To: <Y6sYxUG7fkJL1Lsu4JNIzzbLtwU8BPcm59_QsiURv4o=.1e74a01f-5950-45cc-acec-0217e7fb9094@github.com>
References: <Y6sYxUG7fkJL1Lsu4JNIzzbLtwU8BPcm59_QsiURv4o=.1e74a01f-5950-45cc-acec-0217e7fb9094@github.com>
Message-ID: <r49Q2F95HGDOkjKZ50v0XLfqDCa-Q8SdapEpI_cNHoU=.285627dc-c353-426d-a742-216673732aad@github.com>

On Mon, 3 Apr 2023 21:56:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> The GregorianCalendar constructors and Calendar.getInstance() methods that take TimeZone or Locale throw a NullPointerException if any values are null. 
> 
> This PR updates the javadoc to make this apparent.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13310#pullrequestreview-1376554740

From bchristi at openjdk.org  Fri Apr  7 21:08:57 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 7 Apr 2023 21:08:57 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: <l_n7isQdstCqGlD3plQuPFPgznC9ZgnCrqrva7mqJiQ=.0da1e55e-99a2-41d4-b4df-1dbf0443e407@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

[Presses Snooze]

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

PR Comment: https://git.openjdk.org/jdk/pull/8311#issuecomment-1500647493

From rriggs at openjdk.org  Fri Apr  7 21:13:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Apr 2023 21:13:03 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v8]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <kkme-6_p1Ux-3R8qks4vMCfF32WaCxcCBfyeHmOgsUA=.a33c4e16-1f0f-40cb-8e83-1cf318d89f60@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

Roger Riggs has updated the pull request incrementally with three additional commits since the last revision:

 - Rename OperatingSystemProps to PlatformProps.
   Refactor OperatingSystem initialization to use strings instead of integers.
 - Revised mapping mechanism of build target architecture names to enum values.
   Unrecognized values from the build are mapped to enum value "OTHER".
   Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
   Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
 - Revert changes to jdk.accessibility AccessBridge

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/52ca4a70..53c20c77

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

  Stats: 237 lines in 10 files changed: 123 ins; 81 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

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

From rriggs at openjdk.org  Fri Apr  7 21:20:53 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Apr 2023 21:20:53 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <7ams55QLQB0VUnTJfQBNoFlrgkZUBKTYsBL-NGVAxJY=.55a97708-fa04-4705-bf4d-60bf27d0a872@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>
 <VnW1VBWQ9sLchqOACSMh0gUQG1cvQDJaSW3g_MPHnqo=.47697356-aabb-4d33-b4bf-df12bd3b15b3@github.com>
 <IWrvXb5j8yccPrUMpMHD63ddaA_7zKQBtkcRlnA--VU=.39f6fc2d-2614-4b2c-9f53-b7c7567648e2@github.com>
 <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com>
 <3jNPX5xpKbZQ0Cz05qJHuDLRpx5SmhzOxIHCeERnDWg=.90260d1e-6d77-430c-b0dc-a83df36b1272@github.com>
 <7ams55QLQB0VUnTJfQBNoFlrgkZUBKTYsBL-NGVAxJY=.55a97708-fa04-4705-bf4d-60bf27d0a872@github.com>
Message-ID: <GwC_Fo0whJG-qqwuFPBso_v6GMGaH5LNGPnWGhmJzpE=.68e2a3b1-0ea6-40e9-b3ec-d4f6b3ba0680@github.com>

On Fri, 7 Apr 2023 06:03:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> What did you use as the example that would not compile on the other architecture? 
>> 
>> https://github.com/openjdk/jdk/blob/52ca4a70fc3de9e285964f9545ea8cd54e2d9924/src/java.base/share/classes/jdk/internal/util/OperatingSystemProps.java.template#L40
>> 
>> I don't understand how the above code can be compiled on architectures such as LongArch64, MIPS64el, or ARM32 without modifying the source file.
>> 
>>> Did you make the other changes to the build that would be needed for a new architecture?
>> 
>> I'm not talking about the new architecture, I'm talking about the architecture that OpenJDK already supports. 
>> 
>> According to my understanding, the above code breaks the support of all architectures not listed in `Architecture`. But has `Architecture` really listed all the supported architectures in the OpenJDK mainline?
>> 
>> For example, I want to compile OpenJDK for 32-bit ARM.  I think in this PR, I cannot compile without modifying the source code because `TARGET_ARCH_arm` does not exist. But before this PR, I was able to compile.
>
> @Glavo Arm32 builds, though, see GHAs (crossbuilding test). As for the others, as long as the ports have not been integrated into mainline, I expect port maintainers will adapt the enum downstream. They do this anyway.
> 
> Edit: I now understand your point better and agree in parts, see my reply below.

Refactored the way that build time architecture values are mapped to the Architecture enum.
It now uses strings and does not require predefined names in the template file.
Explicitly maps some build time arch values to the corresponding (but not identical Arch enum); for example x86_64 to X64.
Added a method to expose the endian-ness of the build; this allows it to be separated from the architecture.
So for example "ppc64le" maps to PPC64 and the endian-ness is little.
Added an "OTHER" to the enum values so that unrecognized architecture values from the build can be mapped to that enum.
Renamed the template file so it can more naturally cover the os, architecture, endianness, and 64bit'ness of the implementation.
Reworked OperatingSystem to use the same string based interface between the build and the enum.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160968389

From rriggs at openjdk.org  Fri Apr  7 21:20:50 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Apr 2023 21:20:50 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v8]
In-Reply-To: <kkme-6_p1Ux-3R8qks4vMCfF32WaCxcCBfyeHmOgsUA=.a33c4e16-1f0f-40cb-8e83-1cf318d89f60@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <kkme-6_p1Ux-3R8qks4vMCfF32WaCxcCBfyeHmOgsUA=.a33c4e16-1f0f-40cb-8e83-1cf318d89f60@github.com>
Message-ID: <Q13R8FT1RLjbMV8OLLPzuQn9NF2U2ZuuQdMtR48J7-0=.6b9136e6-e9cf-421b-a228-a7b5d59c8701@github.com>

On Fri, 7 Apr 2023 21:13:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Rename OperatingSystemProps to PlatformProps.
>    Refactor OperatingSystem initialization to use strings instead of integers.
>  - Revised mapping mechanism of build target architecture names to enum values.
>    Unrecognized values from the build are mapped to enum value "OTHER".
>    Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
>    Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
>  - Revert changes to jdk.accessibility AccessBridge

Take a fresh look and comment.  Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1500655738

From rriggs at openjdk.org  Fri Apr  7 21:20:52 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Apr 2023 21:20:52 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <Xvuj-FNTekaixILX1yWW729EsDfmTv_KN4iNp08-eWA=.742dfc08-383b-4afe-af0c-87098d7e177c@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <j7jhRBvTbbRGN7Adkc8kY-5ZTRTAUGgG5hOLldVrh4Y=.d9ca1ba2-0dd1-4280-a321-46fb2cf65288@github.com>
 <1rnezvB6dF2qCWucljVIY9AO_mGGDCwZfah9pntJFmU=.391a8c44-602e-49d0-a8b7-379d174712ce@github.com>
 <tsc6LlSdPu19saBv3IHUJsjaw-XTxrO3Syvemm4ZasY=.583024c6-5298-4fab-a359-8fdba0905fdc@github.com>
 <Xvuj-FNTekaixILX1yWW729EsDfmTv_KN4iNp08-eWA=.742dfc08-383b-4afe-af0c-87098d7e177c@github.com>
Message-ID: <OPkepccrTIX4Mw1pwC5nci9e07caIiJDLTRxpDic18o=.85e77a43-2d49-4157-9645-580548295daa@github.com>

On Fri, 7 Apr 2023 12:05:28 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> Okay, Lutz is the expert here. Sorry for the noise.
>
> Just to let my voice be heard directly after being cited several times: s390 is used to designate the CPU architecture. The arch-specific files are stored in src/hotspot/cpu/s390 for that reason. Back in the days when SAP contributed the s390 port, there was a discussion which architecture name to use. SAP had used zArch_64 which more closely reflects what the port really is (a 64-bit only port to IBM's z/Architecture). It was a majority decision to use s390 for some historic reasons (I don't remember exactly anymore).
> 
> s390x is (almost) always used in conjunction with a Linux OS port. In that respect, linuxs390x is a tautology. OpenJDK does not use this tautology, see src/hotspot/os_cpu/linux_s390 for example.

Thanks for the authoritative answer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160968894

From jpai at openjdk.org  Sat Apr  8 05:44:36 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 8 Apr 2023 05:44:36 GMT
Subject: RFR: 6441827: Documentation mentions nonexistent
 NullReferenceException
Message-ID: <GKByR6YZY_uN0HohFB29uMe7vzInhnhz2378VICHyAM=.ccf97aa4-f781-4895-a895-68c7d3ec2dfa@github.com>

Can I please get a review of this doc only change which fixes a trivial typo in the documentation of `ObjectOutputStream.replaceObject()` method, as noted in https://bugs.openjdk.org/browse/JDK-6441827?

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

Commit messages:
 - 6441827: Documentation mentions nonexistent NullReferenceException

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

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

From iris at openjdk.org  Sat Apr  8 05:53:50 2023
From: iris at openjdk.org (Iris Clark)
Date: Sat, 8 Apr 2023 05:53:50 GMT
Subject: RFR: 6441827: Documentation mentions nonexistent
 NullReferenceException
In-Reply-To: <GKByR6YZY_uN0HohFB29uMe7vzInhnhz2378VICHyAM=.ccf97aa4-f781-4895-a895-68c7d3ec2dfa@github.com>
References: <GKByR6YZY_uN0HohFB29uMe7vzInhnhz2378VICHyAM=.ccf97aa4-f781-4895-a895-68c7d3ec2dfa@github.com>
Message-ID: <1ltDLTSlcgWNa1Zf4Y2taMoyghpPpWlpDkBqwln62Os=.d17070ba-9c78-4e99-9bd2-40df236ab9dc@github.com>

On Sat, 8 Apr 2023 05:37:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc only change which fixes a trivial typo in the documentation of `ObjectOutputStream.replaceObject()` method, as noted in https://bugs.openjdk.org/browse/JDK-6441827?

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13399#pullrequestreview-1376722568

From stuefe at openjdk.org  Sat Apr  8 07:10:55 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 8 Apr 2023 07:10:55 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <GwC_Fo0whJG-qqwuFPBso_v6GMGaH5LNGPnWGhmJzpE=.68e2a3b1-0ea6-40e9-b3ec-d4f6b3ba0680@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>
 <VnW1VBWQ9sLchqOACSMh0gUQG1cvQDJaSW3g_MPHnqo=.47697356-aabb-4d33-b4bf-df12bd3b15b3@github.com>
 <IWrvXb5j8yccPrUMpMHD63ddaA_7zKQBtkcRlnA--VU=.39f6fc2d-2614-4b2c-9f53-b7c7567648e2@github.com>
 <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com>
 <3jNPX5xpKbZQ0Cz05qJHuDLRpx5SmhzOxIHCeERnDWg=.90260d1e-6d77-430c-b0dc-a83df36b1272@github.com>
 <7ams55QLQB0VUnTJfQBNoFlrgkZUBKTYsBL-NGVAxJY=.55a97708-fa04-4705-bf4d-60bf27d0a872@github.com>
 <GwC_Fo0whJG-qqwuFPBso_v6GMGaH5LNGPnWGhmJzpE=.68e2a3b1-0ea6-40e9-b3ec-d4f6b3ba0680@github.com>
Message-ID: <yGbFDaAum7pDn4MwLcBi0iWruPAfF3L9ixTaz4_le3E=.80c8a999-3f52-40c0-95dc-6b4336b890c0@github.com>

On Fri, 7 Apr 2023 21:15:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactored the way that build time architecture values are mapped to the Architecture enum. 

Thank you for this, Roger.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1161075537

From duke at openjdk.org  Sat Apr  8 08:26:49 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 8 Apr 2023 08:26:49 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v8]
In-Reply-To: <kkme-6_p1Ux-3R8qks4vMCfF32WaCxcCBfyeHmOgsUA=.a33c4e16-1f0f-40cb-8e83-1cf318d89f60@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <kkme-6_p1Ux-3R8qks4vMCfF32WaCxcCBfyeHmOgsUA=.a33c4e16-1f0f-40cb-8e83-1cf318d89f60@github.com>
Message-ID: <bp-SLJyZUFte1k0P3N5Xkf2YZmA_MDGuJlfbSHwOdYA=.3b2a68c6-e27c-47d9-811a-21c8ebb7036f@github.com>

On Fri, 7 Apr 2023 21:13:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Rename OperatingSystemProps to PlatformProps.
>    Refactor OperatingSystem initialization to use strings instead of integers.
>  - Revised mapping mechanism of build target architecture names to enum values.
>    Unrecognized values from the build are mapped to enum value "OTHER".
>    Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
>    Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
>  - Revert changes to jdk.accessibility AccessBridge

src/java.base/share/classes/jdk/internal/util/Architecture.java line 47:

> 45:     // Cache a copy of the array for lightweight indexing
> 46:     private static final @Stable Architecture[] archValues = Architecture.values();
> 47: 

This?now appears to?be?unused:
Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1161082612

From duke at openjdk.org  Sat Apr  8 08:27:42 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 8 Apr 2023 08:27:42 GMT
Subject: RFR: 6441827: Documentation mentions nonexistent
 NullReferenceException
In-Reply-To: <GKByR6YZY_uN0HohFB29uMe7vzInhnhz2378VICHyAM=.ccf97aa4-f781-4895-a895-68c7d3ec2dfa@github.com>
References: <GKByR6YZY_uN0HohFB29uMe7vzInhnhz2378VICHyAM=.ccf97aa4-f781-4895-a895-68c7d3ec2dfa@github.com>
Message-ID: <-vyORrcz_Qhsr9r5kxQEEKba3qwltIZoVOZprHYN4Ow=.73dab5ac-a5fd-483e-a8bd-6215e6f23a97@github.com>

On Sat, 8 Apr 2023 05:37:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc only change which fixes a trivial typo in the documentation of `ObjectOutputStream.replaceObject()` method, as noted in https://bugs.openjdk.org/browse/JDK-6441827?

src/java.base/share/classes/java/io/ObjectOutputStream.java line 588:

> 586:      *
> 587:      * <p>Null can be returned as the object to be substituted, but may cause
> 588:      * {@code NullPointerException} in classes that contain references to the

Maybe?use `{@link??}` instead of?`{@code??}`?
Suggestion:

     * {@link NullPointerException} in classes that contain references to the

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13399#discussion_r1161082846

From lancea at openjdk.org  Sat Apr  8 10:40:46 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 8 Apr 2023 10:40:46 GMT
Subject: RFR: 8305758: Update the man page to indicate -i/--generate-file is
 deprecated
Message-ID: <rKQ1y-A4MHFzqmvT2_RM9yGgUWMJ-DK1CMuFWHyIqts=.6c84fd7e-6a78-46e7-9182-656945374691@github.com>

Hi all,

Please review this MR which updates the jar man page to to indicate that  --generate-index/-I are deprecated and may be removed in a future release

Support for JAR Index is being removed via JDK-8302819.

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

Commit messages:
 - Update the man page to indicate -i/--generate-file is deprecated

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

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

From duke at openjdk.org  Sat Apr  8 11:56:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 8 Apr 2023 11:56:49 GMT
Subject: RFR: 8305758: Update the man page to indicate -i/--generate-file
 is deprecated
In-Reply-To: <rKQ1y-A4MHFzqmvT2_RM9yGgUWMJ-DK1CMuFWHyIqts=.6c84fd7e-6a78-46e7-9182-656945374691@github.com>
References: <rKQ1y-A4MHFzqmvT2_RM9yGgUWMJ-DK1CMuFWHyIqts=.6c84fd7e-6a78-46e7-9182-656945374691@github.com>
Message-ID: <KAyHQPsYjJPBHZdhpAztrfgTf93ZJJ2DWGXaeDufWJI=.30340978-d193-4cfe-9834-201c3af6070a@github.com>

On Sat, 8 Apr 2023 10:33:48 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this MR which updates the jar man page to to indicate that  --generate-index/-I are deprecated and may be removed in a future release
> 
> Support for JAR Index is being removed via JDK-8302819.

The JBS issue name should be updated to use a lowercase `-i` and this PR's title should be updated to match the JBS title.

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

PR Comment: https://git.openjdk.org/jdk/pull/13400#issuecomment-1500875207

From duke at openjdk.org  Sat Apr  8 12:04:42 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 8 Apr 2023 12:04:42 GMT
Subject: RFR: 8305758: Update the man page to indicate -i/--generate-file
 is deprecated
In-Reply-To: <rKQ1y-A4MHFzqmvT2_RM9yGgUWMJ-DK1CMuFWHyIqts=.6c84fd7e-6a78-46e7-9182-656945374691@github.com>
References: <rKQ1y-A4MHFzqmvT2_RM9yGgUWMJ-DK1CMuFWHyIqts=.6c84fd7e-6a78-46e7-9182-656945374691@github.com>
Message-ID: <548jGvmygucriKe6kz3dVwCUjd0OVjsTZ5E4EF71oFQ=.efedecfb-5744-445f-80d0-d2e0acc0a4fa@github.com>

On Sat, 8 Apr 2023 10:33:48 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this MR which updates the jar man page to to indicate that  --generate-index/-I are deprecated and may be removed in a future release
> 
> Support for JAR Index is being removed via JDK-8302819.

Is the `compiler` label appropriate for this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/13400#issuecomment-1500876783

From jpai at openjdk.org  Sat Apr  8 13:00:40 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 8 Apr 2023 13:00:40 GMT
Subject: RFR: 6441827: Documentation mentions nonexistent
 NullReferenceException [v2]
In-Reply-To: <GKByR6YZY_uN0HohFB29uMe7vzInhnhz2378VICHyAM=.ccf97aa4-f781-4895-a895-68c7d3ec2dfa@github.com>
References: <GKByR6YZY_uN0HohFB29uMe7vzInhnhz2378VICHyAM=.ccf97aa4-f781-4895-a895-68c7d3ec2dfa@github.com>
Message-ID: <wcrFyAruTfWylDZ6O2ERA6_KX8A3fYrLVrq7x_c1CSk=.b2744623-1b41-4960-b2ed-c87e8145d0b0@github.com>

> Can I please get a review of this doc only change which fixes a trivial typo in the documentation of `ObjectOutputStream.replaceObject()` method, as noted in https://bugs.openjdk.org/browse/JDK-6441827?

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

  @link instead of @code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13399/files
  - new: https://git.openjdk.org/jdk/pull/13399/files/97ed04fd..1bde61f2

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

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

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

From jpai at openjdk.org  Sat Apr  8 13:00:42 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 8 Apr 2023 13:00:42 GMT
Subject: RFR: 6441827: Documentation mentions nonexistent
 NullReferenceException [v2]
In-Reply-To: <-vyORrcz_Qhsr9r5kxQEEKba3qwltIZoVOZprHYN4Ow=.73dab5ac-a5fd-483e-a8bd-6215e6f23a97@github.com>
References: <GKByR6YZY_uN0HohFB29uMe7vzInhnhz2378VICHyAM=.ccf97aa4-f781-4895-a895-68c7d3ec2dfa@github.com>
 <-vyORrcz_Qhsr9r5kxQEEKba3qwltIZoVOZprHYN4Ow=.73dab5ac-a5fd-483e-a8bd-6215e6f23a97@github.com>
Message-ID: <1zJUzYN3SZXtNvZTzc9NgdyG_8VK6oU-nNEpdDLlYPU=.f07ce5c4-0849-4d17-81ce-273301e30678@github.com>

On Sat, 8 Apr 2023 08:24:54 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @link instead of @code
>
> src/java.base/share/classes/java/io/ObjectOutputStream.java line 588:
> 
>> 586:      *
>> 587:      * <p>Null can be returned as the object to be substituted, but may cause
>> 588:      * {@code NullPointerException} in classes that contain references to the
> 
> Maybe?use `{@link??}` instead of?`{@code??}`?
> Suggestion:
> 
>      * {@link NullPointerException} in classes that contain references to the

In this case I don't have a specific preference. I've updated the PR to use `@link` instead of `@code`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13399#discussion_r1161109315

From jwaters at openjdk.org  Sat Apr  8 13:24:37 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 8 Apr 2023 13:24:37 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v3]
In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
Message-ID: <a8EKWPPER8vptO3T4DOmt1KwB03s4vc2gkkXOBKEohk=.f898dbf4-dbf0-452e-8d25-3975423bfee5@github.com>

> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

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

  Semicolon

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13258/files
  - new: https://git.openjdk.org/jdk/pull/13258/files/7dc7f7d8..07f5c702

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

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

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

From jwaters at openjdk.org  Sat Apr  8 13:26:36 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 8 Apr 2023 13:26:36 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v4]
In-Reply-To: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
Message-ID: <V1mOqqIoiev_kAYV0lyDKLJ2NaxTA-EzY_DiJkI8hig=.1eeea2af-a281-499e-88bb-2beff4262bc2@github.com>

> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched

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

  Legacy Boolean to jboolean conversion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13139/files
  - new: https://git.openjdk.org/jdk/pull/13139/files/362cf3ed..dad94b31

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

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

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

From jwaters at openjdk.org  Sat Apr  8 13:26:38 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 8 Apr 2023 13:26:38 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v3]
In-Reply-To: <B5qkdYWLgOcqZ-_IdFBZTehhhHA6IhwfnE9OecMrxGU=.d1e536f4-fba5-43db-b6a1-e8974b641815@github.com>
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 <B5qkdYWLgOcqZ-_IdFBZTehhhHA6IhwfnE9OecMrxGU=.d1e536f4-fba5-43db-b6a1-e8974b641815@github.com>
Message-ID: <Xaw00mULXX4soVsjOmi12olib0t6Qt997WbQOAp3zes=.e084264d-b74d-4ed4-b685-24d45b74d46f@github.com>

On Fri, 31 Mar 2023 05:57:01 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicit conversion to jboolean

Alright, thanks Phil

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

PR Comment: https://git.openjdk.org/jdk/pull/13139#issuecomment-1500890807

From lancea at openjdk.org  Sat Apr  8 14:01:45 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 8 Apr 2023 14:01:45 GMT
Subject: RFR: 8305758: Update the JAR tool man page to indicate
 -i/--generate-file is deprecated
In-Reply-To: <KAyHQPsYjJPBHZdhpAztrfgTf93ZJJ2DWGXaeDufWJI=.30340978-d193-4cfe-9834-201c3af6070a@github.com>
References: <rKQ1y-A4MHFzqmvT2_RM9yGgUWMJ-DK1CMuFWHyIqts=.6c84fd7e-6a78-46e7-9182-656945374691@github.com>
 <KAyHQPsYjJPBHZdhpAztrfgTf93ZJJ2DWGXaeDufWJI=.30340978-d193-4cfe-9834-201c3af6070a@github.com>
Message-ID: <d8_kn3ZS-BVHMCo1b9nyuWz64YgZhLMQVGgwDu65TBQ=.af4f37e9-2b18-4a81-afd2-c06c008fa7e3@github.com>

On Sat, 8 Apr 2023 11:53:50 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The JBS issue name should be updated to use a lowercase `-i` and this PR's title should be updated to match the JBS title.

Lack of coffee and doing this before 7am this morning  is my only excuse

> Is the `compiler` label appropriate for this PR?

This was done by the bots,  not sure why but not really an issue

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

PR Comment: https://git.openjdk.org/jdk/pull/13400#issuecomment-1500897626
PR Comment: https://git.openjdk.org/jdk/pull/13400#issuecomment-1500897794

From jlaskey at openjdk.org  Sat Apr  8 14:42:35 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Sat, 8 Apr 2023 14:42:35 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v55]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <RV84nzy4c88wTwf2PhV2A4uYS0HMiK1_jwYo-YvZMMA=.4dd46868-c5b8-4a02-ac45-80151c4381f1@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Clean up Error handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/4c6d70d1..62eadb84

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=54
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=53-54

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

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

From jlaskey at openjdk.org  Sat Apr  8 14:42:39 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Sat, 8 Apr 2023 14:42:39 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v54]
In-Reply-To: <AhfxQ0KFneqkzcwmZyT_BrIP7EPK8mq3TDxAOa_a0yI=.3daa6dc8-2844-4fe4-a2ea-a40e9ee38eaf@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <BSADnCP_cZkZnwJDnznJ3T8PbB0IF6_xF_wuEJv7Pc0=.b8c1654a-6fe1-487e-9095-b4a5f2bcd22d@github.com>
 <AhfxQ0KFneqkzcwmZyT_BrIP7EPK8mq3TDxAOa_a0yI=.3daa6dc8-2844-4fe4-a2ea-a40e9ee38eaf@github.com>
Message-ID: <IhW7W0jh8z0Qs5RZwP0W4nUgyiXJbKGGtG6VwVJ6_Vw=.61492a73-946c-49d3-9dc8-7bbf4425b835@github.com>

On Fri, 7 Apr 2023 09:32:59 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Recommended changes
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 364:
> 
>> 362:         try {
>> 363:             return value.prepend(indexCoder, buf);
>> 364:         } catch (Throwable ex) {
> 
> This?should rethrow?errors (such?as?`OutOfMemoryError`):
> Suggestion:
> 
>         } catch (Error err) {
>             throw err;
>         } catch (Throwable ex) {

Changing

> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 100:
> 
>> 98:         try {
>> 99:             return (List<Object>)valuesMH.invokeExact(this);
>> 100:         } catch (RuntimeException | OutOfMemoryError ex) {
> 
> Suggestion:
> 
>         } catch (RuntimeException | Error ex) {

Changing

> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 111:
> 
>> 109:         try {
>> 110:             return (String) interpolateMH.invokeExact(this);
>> 111:         } catch (RuntimeException | OutOfMemoryError ex) {
> 
> Suggestion:
> 
>         } catch (RuntimeException | Error ex) {

Changing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1161119626
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1161119647
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1161119669

From duke at openjdk.org  Sat Apr  8 15:22:44 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 8 Apr 2023 15:22:44 GMT
Subject: RFR: 8305748: Clarify reentrant behavior of close() in
 FileInputStream, FileOutputStream, and RandomAccessFile [v2]
In-Reply-To: <fxBykJLGjvCCzMFZ4IAwCKQDUxJvpedXGAFOhQmcqkM=.7b55f68e-0240-4c0a-bcc8-ba3c061f642a@github.com>
References: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
 <FrQ1lwdHlpwzS3cDkvuQGxxvvC7wPowaSHyNGvf0A-Y=.aa703b7e-5b09-4e7e-88d4-d84073c410f7@github.com>
 <fxBykJLGjvCCzMFZ4IAwCKQDUxJvpedXGAFOhQmcqkM=.7b55f68e-0240-4c0a-bcc8-ba3c061f642a@github.com>
Message-ID: <to_wRbzCCGeQRdaykunReDLw5yRTvwQr8xsFlHYTjyI=.827abf9f-e26f-4e10-8399-ab095fcdf84b@github.com>

On Fri, 7 Apr 2023 17:56:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply Javadoc improvements suggested in review.
>
> src/java.base/share/classes/java/io/FileInputStream.java line 503:
> 
>> 501:      *
>> 502:      * @apiNote
>> 503:      * When this stream has an associated channel, this method may invoke
> 
> I don't think a method can have more than one apiNote so the existing note will run into this text. Replacing @apiNote with a paragraph tag will help.
> 
> As regards the wording, then here's a suggestion that relies on the specification and avoids giving the impression that the close method directly calls itself recursively:
> 
> "If this stream has an associated channel then this method will close the channel, which in turn will close this stream. Subclasses that override this method should be prepared to handle possible reentrant invocation."

Thanks - fixed in 90a130783.

> src/java.base/share/classes/java/io/RandomAccessFile.java line 701:
> 
>> 699:      *
>> 700:      * @apiNote
>> 701:      * When this file has an associated channel, this method may invoke
> 
> "this file" should be "this stream"

Thanks - fixed in 90a130783.

@AlanBateman, would you mind reviewing the CSR also? Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13379#discussion_r1161124154
PR Review Comment: https://git.openjdk.org/jdk/pull/13379#discussion_r1161124215

From bmarwell at apache.org  Sat Apr  8 15:36:35 2023
From: bmarwell at apache.org (Benjamin Marwell)
Date: Sat, 8 Apr 2023 17:36:35 +0200
Subject: RFE: SequenceInputStream - Consider new issue for PR #11718
Message-ID: <CAKZnr+xnAfrCkuGjyMDnPfLWG8BNXtT03Yi7HfVDdgY3k3-iTw@mail.gmail.com>

Dear Core-Devs,

There was a PR created for an enhancement of SequenceInputStream [1]
by Romain Manni-Buceau.

Description by Romain:

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

As the both of us do not have access to the OpenJDK bug tracker,
kindly open an issue for this PR if you agree with this
enhancement/PR.

[1]: https://github.com/openjdk/jdk/pull/11718

From jlaskey at openjdk.org  Sat Apr  8 15:51:36 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Sat, 8 Apr 2023 15:51:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v56]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/62eadb84..6016deb8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=55
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=54-55

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

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

From alanb at openjdk.org  Sat Apr  8 15:55:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 8 Apr 2023 15:55:43 GMT
Subject: RFR: 8305758: Update the JAR tool man page to indicate
 -i/--generate-file is deprecated
In-Reply-To: <rKQ1y-A4MHFzqmvT2_RM9yGgUWMJ-DK1CMuFWHyIqts=.6c84fd7e-6a78-46e7-9182-656945374691@github.com>
References: <rKQ1y-A4MHFzqmvT2_RM9yGgUWMJ-DK1CMuFWHyIqts=.6c84fd7e-6a78-46e7-9182-656945374691@github.com>
Message-ID: <uD12n_ddf2Wyz7J6LCLkGJbGQjxLxbKUsfrnkgSkQ3s=.cfe99fdb-906a-43e8-8c60-4c343ddaea2c@github.com>

On Sat, 8 Apr 2023 10:33:48 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this MR which updates the jar man page to to indicate that  --generate-index/-I are deprecated and may be removed in a future release
> 
> Support for JAR Index is being removed via JDK-8302819.

src/jdk.jartool/share/man/jar.1 line 38:

> 36: . ftr VBI CBI
> 37: .\}
> 38: .TH "JAR" "1" "2023" "JDK 21-internal" "JDK Commands"

I assume you didn't mean to edit this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13400#discussion_r1161127540

From rriggs at openjdk.org  Sat Apr  8 18:00:53 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 8 Apr 2023 18:00:53 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Remove unused static and import of Stabile

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/53c20c77..f3646dc9

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

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

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

From iris at openjdk.org  Sat Apr  8 19:43:43 2023
From: iris at openjdk.org (Iris Clark)
Date: Sat, 8 Apr 2023 19:43:43 GMT
Subject: RFR: 6441827: Documentation mentions nonexistent
 NullReferenceException [v2]
In-Reply-To: <wcrFyAruTfWylDZ6O2ERA6_KX8A3fYrLVrq7x_c1CSk=.b2744623-1b41-4960-b2ed-c87e8145d0b0@github.com>
References: <GKByR6YZY_uN0HohFB29uMe7vzInhnhz2378VICHyAM=.ccf97aa4-f781-4895-a895-68c7d3ec2dfa@github.com>
 <wcrFyAruTfWylDZ6O2ERA6_KX8A3fYrLVrq7x_c1CSk=.b2744623-1b41-4960-b2ed-c87e8145d0b0@github.com>
Message-ID: <29mhxI_-vulPvUxKMP_Lyu5Rvt4UwNRG4TKB4-jtNPo=.83a60df9-8973-48b8-8162-60095115720f@github.com>

On Sat, 8 Apr 2023 13:00:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc only change which fixes a trivial typo in the documentation of `ObjectOutputStream.replaceObject()` method, as noted in https://bugs.openjdk.org/browse/JDK-6441827?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @link instead of @code

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13399#pullrequestreview-1376799637

From duke at openjdk.org  Sat Apr  8 21:41:51 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sat, 8 Apr 2023 21:41:51 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection
Message-ID: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>

In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.

I don't know whether this change requires a CSR request.

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

Commit messages:
 - Optimize String.join(CharSequence,Iterable)

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

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

From jlaskey at openjdk.org  Sat Apr  8 22:12:41 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Sat, 8 Apr 2023 22:12:41 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection
In-Reply-To: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
Message-ID: <N-XIQmrA7d8LVS4WxzZOBBK3-uoJx1oQVvAkqnPMKG0=.de0daff5-6b5d-4e93-b2dc-cf064566074f@github.com>

On Fri, 7 Apr 2023 08:27:18 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
> 
> I don't know whether this change requires a CSR request.

It would be good to show the performance improvement via a few jmh runs.

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

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1500986773

From liach at openjdk.org  Sat Apr  8 23:20:47 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 8 Apr 2023 23:20:47 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection
In-Reply-To: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
Message-ID: <p4fyVneBLmpagZKZBR0-LNrrn9SYUaqz7HCg_lqjBZM=.d71e6823-ce55-4424-b512-7235763517b2@github.com>

On Fri, 7 Apr 2023 08:27:18 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
> 
> I don't know whether this change requires a CSR request.

Have you considered the performance impact on concurrent collections, that their size() computation is non-constant, and the array still may need resizing later (which you've kept, good)

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

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1500995565

From duke at openjdk.org  Sat Apr  8 23:31:40 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sat, 8 Apr 2023 23:31:40 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection
In-Reply-To: <p4fyVneBLmpagZKZBR0-LNrrn9SYUaqz7HCg_lqjBZM=.d71e6823-ce55-4424-b512-7235763517b2@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <p4fyVneBLmpagZKZBR0-LNrrn9SYUaqz7HCg_lqjBZM=.d71e6823-ce55-4424-b512-7235763517b2@github.com>
Message-ID: <I-JoKkS1PKoRi4Bf5tgm3DndL_oPQ4cB_kvJZ1yW7-M=.d1858059-b17a-496a-bfe2-a5da7a206839@github.com>

On Sat, 8 Apr 2023 23:18:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
>> 
>> I don't know whether this change requires a CSR request.
>
> Have you considered the performance impact on concurrent collections, that their size() computation is non-constant, and the array still may need resizing later (which you've kept, good)

@liach Thanks for reminding that. Some collections such as `java.util.concurrent.ConcurrentLinkedDeque` require O(n) time to compute the `size`. I will benchmark it as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1500996891

From jpai at openjdk.org  Sun Apr  9 01:34:06 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 9 Apr 2023 01:34:06 GMT
Subject: RFR: 6441827: Documentation mentions nonexistent
 NullReferenceException [v2]
In-Reply-To: <wcrFyAruTfWylDZ6O2ERA6_KX8A3fYrLVrq7x_c1CSk=.b2744623-1b41-4960-b2ed-c87e8145d0b0@github.com>
References: <GKByR6YZY_uN0HohFB29uMe7vzInhnhz2378VICHyAM=.ccf97aa4-f781-4895-a895-68c7d3ec2dfa@github.com>
 <wcrFyAruTfWylDZ6O2ERA6_KX8A3fYrLVrq7x_c1CSk=.b2744623-1b41-4960-b2ed-c87e8145d0b0@github.com>
Message-ID: <JUy6XZuwkdrtPnnwvT7w9Ip8xxmccT9JX0yboNTQUGk=.0700de72-5dc6-45a0-a8f7-ffb006a53f70@github.com>

On Sat, 8 Apr 2023 13:00:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc only change which fixes a trivial typo in the documentation of `ObjectOutputStream.replaceObject()` method, as noted in https://bugs.openjdk.org/browse/JDK-6441827?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @link instead of @code

Thank you Iris for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/13399#issuecomment-1501014790

From jpai at openjdk.org  Sun Apr  9 01:34:07 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 9 Apr 2023 01:34:07 GMT
Subject: Integrated: 6441827: Documentation mentions nonexistent
 NullReferenceException
In-Reply-To: <GKByR6YZY_uN0HohFB29uMe7vzInhnhz2378VICHyAM=.ccf97aa4-f781-4895-a895-68c7d3ec2dfa@github.com>
References: <GKByR6YZY_uN0HohFB29uMe7vzInhnhz2378VICHyAM=.ccf97aa4-f781-4895-a895-68c7d3ec2dfa@github.com>
Message-ID: <h7ihWfVyPVn5-IhyQGOOc5vUk2Ak0trvrJI3FCLC6VU=.9920c261-20a2-4e4f-8a93-49087060fff4@github.com>

On Sat, 8 Apr 2023 05:37:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc only change which fixes a trivial typo in the documentation of `ObjectOutputStream.replaceObject()` method, as noted in https://bugs.openjdk.org/browse/JDK-6441827?

This pull request has now been integrated.

Changeset: ec9d816a
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec9d816abf29efe1eb6af46c394fafa7f75e3d7b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

6441827: Documentation mentions nonexistent NullReferenceException

Reviewed-by: iris

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

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

From duke at openjdk.org  Sun Apr  9 02:14:50 2023
From: duke at openjdk.org (jmehrens)
Date: Sun, 9 Apr 2023 02:14:50 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection
In-Reply-To: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
Message-ID: <q7jlCo1zq4IBBVoicuXZkHPjGT86ez4o6QyWdDVc7NY=.dd661c42-ebaa-415c-b345-698baba0cc88@github.com>

On Fri, 7 Apr 2023 08:27:18 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
> 
> I don't know whether this change requires a CSR request.

What about using Iterable::spliterator instead of Iterable::iterator (enhanced for loop)?  Spliterator would allow you to call Spliterator::estimateSize and then to default to 8 if less than 8, cast and use if less than or equal to ArraysSupport.SOFT_MAX_ARRAY_LENGTH, or throw OutOfMemoryError if greater than Integer.MAX_VALUE.  The array growth code would have to use ArraysSupport.newLength to deal with huge sizes.

I'm not sure if bootstrapping issues will prevent you from using lambdas expressions to traverse the Spliterator.  If lambdas expressions are forbidden then this approach will introduce some code smell by having to use inner classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501020813

From duke at openjdk.org  Sun Apr  9 02:28:37 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sun, 9 Apr 2023 02:28:37 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
Message-ID: <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>

> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
> 
> I don't know whether this change requires a CSR request.

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

  Add benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13383/files
  - new: https://git.openjdk.org/jdk/pull/13383/files/3d4787ed..50e670c7

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

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

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

From duke at openjdk.org  Sun Apr  9 02:28:38 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sun, 9 Apr 2023 02:28:38 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection
In-Reply-To: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
Message-ID: <4N3rKwTvcUf7CHK9Jki29LETDrZaIdP0hl7FECSr3Yk=.bc37e139-c935-46e0-afc6-7bf169493e17@github.com>

On Fri, 7 Apr 2023 08:27:18 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
> 
> I don't know whether this change requires a CSR request.

I've just added the benchmark code, and here is the result tested on my computer.

Before change:


Benchmark                                           Mode  Cnt          Score          Error  Units
StringJoinWithIterable.joinWithArrayList            avgt   30  146820983.745 ?  6654877.812  ns/op
StringJoinWithIterable.joinWithIterable             avgt   30  145236859.688 ?  5683967.478  ns/op
StringJoinWithIterable.joinWithLinkedBlockingDeque  avgt   30  250139433.967 ? 14381158.389  ns/op
StringJoinWithIterable.joinWithLinkedHashSet        avgt   30  167718287.313 ?  7394905.875  ns/op
StringJoinWithIterable.joinWithLinkedTransferQueue  avgt   30  153245459.832 ?  7972716.070  ns/op


After change:


Benchmark                                           Mode  Cnt          Score          Error  Units
StringJoinWithIterable.joinWithArrayList            avgt   30  138343729.406 ?  5959140.498  ns/op
StringJoinWithIterable.joinWithIterable             avgt   30  149566458.195 ?  9755905.704  ns/op
StringJoinWithIterable.joinWithLinkedBlockingDeque  avgt   30  247384811.927 ? 14647765.134  ns/op
StringJoinWithIterable.joinWithLinkedHashSet        avgt   30  153244492.767 ?  4589884.301  ns/op
StringJoinWithIterable.joinWithLinkedTransferQueue  avgt   30  157162685.594 ?  4330658.539  ns/op



It seems that the improvement is not notable :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501022549

From liach at openjdk.org  Sun Apr  9 02:35:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 9 Apr 2023 02:35:42 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
Message-ID: <lG8VuoiQCo5TxTzX1baulfzsdqqGMsZMtX3cGQHCIIU=.345aa822-ff47-410d-ab58-1a7e916ac073@github.com>

On Sun, 9 Apr 2023 02:28:37 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
>> 
>> I don't know whether this change requires a CSR request.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark

This appears to be a 4% improvement for non-concurrent structures like ArrayList or LinkedHashSet, if we ignore the baseline difference (for Iterable). This is anticipated as the growth of array size is exponential, so the total allocation is effectively O(N log(N)). Can you try with smaller quantities, like single-digit or double digits length, which may be more frequent in application?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501023576

From duke at openjdk.org  Sun Apr  9 02:40:43 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sun, 9 Apr 2023 02:40:43 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection
In-Reply-To: <q7jlCo1zq4IBBVoicuXZkHPjGT86ez4o6QyWdDVc7NY=.dd661c42-ebaa-415c-b345-698baba0cc88@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <q7jlCo1zq4IBBVoicuXZkHPjGT86ez4o6QyWdDVc7NY=.dd661c42-ebaa-415c-b345-698baba0cc88@github.com>
Message-ID: <RjzBDt3fuiL9oKotiPdctmyZ06xftWypJr4Hx0E49gI=.59429abf-9f6c-48d8-b1a3-6ca3b14f6ec1@github.com>

On Sun, 9 Apr 2023 02:11:44 GMT, jmehrens <duke at openjdk.org> wrote:

>> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
>> 
>> I don't know whether this change requires a CSR request.
>
> What about using Iterable::spliterator instead of Iterable::iterator (enhanced for loop)?  Spliterator would allow you to call Spliterator::estimateSize and then to default to 8 if less than 8, cast and use if less than or equal to ArraysSupport.SOFT_MAX_ARRAY_LENGTH, or throw OutOfMemoryError if greater than Integer.MAX_VALUE.  The array growth code would have to use ArraysSupport.newLength to deal with huge sizes.
> 
> I'm not sure if bootstrapping issues will prevent you from using lambdas expressions to traverse the Spliterator.  If lambdas expressions are forbidden then this approach will introduce some code smell by having to use inner classes.

Maybe I should consider @jmehrens 's suggestion to check the return value of `elements.spliterator().estimateSize()`. It will return `Long.MAX_VALUE` if the size is expensive to compute (e.g. `ConcurrentLinkedDeque`). This also works if `elements` is not a `Collection`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501023984

From duke at openjdk.org  Sun Apr  9 02:40:45 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sun, 9 Apr 2023 02:40:45 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <lG8VuoiQCo5TxTzX1baulfzsdqqGMsZMtX3cGQHCIIU=.345aa822-ff47-410d-ab58-1a7e916ac073@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
 <lG8VuoiQCo5TxTzX1baulfzsdqqGMsZMtX3cGQHCIIU=.345aa822-ff47-410d-ab58-1a7e916ac073@github.com>
Message-ID: <m19mkLyirsWHcsG4MZ4mVsw76KjQsJlY-Frk69e1q0E=.90e37483-9d4c-437f-88a2-ee0e26a9d68d@github.com>

On Sun, 9 Apr 2023 02:33:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add benchmark
>
> This appears to be a 4% improvement for non-concurrent structures like ArrayList or LinkedHashSet, if we ignore the baseline difference (for Iterable). This is anticipated as the growth of array size is exponential, so the total allocation is effectively O(N log(N)). Can you try with smaller quantities, like single-digit or double digits length, which may be more frequent in application?

@liach Working on that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501024117

From duke at openjdk.org  Sun Apr  9 08:44:42 2023
From: duke at openjdk.org (ExE Boss)
Date: Sun, 9 Apr 2023 08:44:42 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
Message-ID: <VkRbUAKNwlGSBuBqsEKLm8JKlZ2QOxiPE2XZTgGJlK0=.4e834497-b8d9-4772-827b-e9a1a23588a2@github.com>

On Sun, 9 Apr 2023 02:28:37 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
>> 
>> I don't know whether this change requires a CSR request.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark

You?can?also use?[`Spliterators.iterator(Spliterator)`] to?convert the?[`Spliterator`] into?an?[`Iterator`] after?the?size?computation without?needing to?change the?loop.

[`Spliterators.iterator(Spliterator)`]: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/Spliterators.html#iterator%28java.util.Spliterator%29
[`Spliterator`]: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/Spliterator.html
[`Iterator`]: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/Iterator.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501077218

From duke at openjdk.org  Sun Apr  9 09:54:50 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sun, 9 Apr 2023 09:54:50 GMT
Subject: RFR: 8302819: Remove JAR Index [v6]
In-Reply-To: <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
Message-ID: <YZVAX8X1dCPJREA_khYRvrv5TFWwoVcBD212xChegow=.6cb9dc6f-2cf4-4a17-b226-0621e9f3de36@github.com>

On Fri, 7 Apr 2023 07:47:49 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a note in the --help for --generate-index that this option is deprecated and may be removed in a future release.

It seems the stars are getting aligned for this PR to be integrated.

None of the current approvals apply to the latest commit d04df25ea2dd505f2224bff446865a0974a8f37a, it would be good to have that `jar --help` update approved as well.

Are there any other concerns left before we can integrate?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1501089831

From aturbanov at openjdk.org  Sun Apr  9 11:25:04 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 9 Apr 2023 11:25:04 GMT
Subject: RFR: 8305696: (zipfs) Avoid redundant LinkedHashMap.containsKey
 call ZipFileSystem.makeParentDirs
In-Reply-To: <L1C6gVVln23VejqKo9Qab54sNHc8tLuQoyVL3Y9uc9o=.9f0f0cdb-2e9c-42e6-801b-d1aa64dc8bc5@github.com>
References: <L1C6gVVln23VejqKo9Qab54sNHc8tLuQoyVL3Y9uc9o=.9f0f0cdb-2e9c-42e6-801b-d1aa64dc8bc5@github.com>
Message-ID: <TK6wIcTnbedcuKYDjnV_FCGPP21gHuwTomEX5vsKRNs=.72abcfa4-acdd-4d63-8590-6c8c15eccc15@github.com>

On Mon, 3 Apr 2023 17:16:26 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `LinkedHashMap<IndexNode, IndexNode>` `ZipFileSystem.inodes` contains only non-null values. It means instead of separate `containsKey`+`get` calls, we can use single `LinkedHashMap.get` call and then compare result with `null`.
> Result code is a bit simpler and faster.
> 
> Testing: Linux x64 `java/nio`, `jdk/nio`

Thank you for review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13304#issuecomment-1501105487

From aturbanov at openjdk.org  Sun Apr  9 11:25:04 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 9 Apr 2023 11:25:04 GMT
Subject: Integrated: 8305696: (zipfs) Avoid redundant LinkedHashMap.containsKey
 call ZipFileSystem.makeParentDirs
In-Reply-To: <L1C6gVVln23VejqKo9Qab54sNHc8tLuQoyVL3Y9uc9o=.9f0f0cdb-2e9c-42e6-801b-d1aa64dc8bc5@github.com>
References: <L1C6gVVln23VejqKo9Qab54sNHc8tLuQoyVL3Y9uc9o=.9f0f0cdb-2e9c-42e6-801b-d1aa64dc8bc5@github.com>
Message-ID: <kIp_BfBNIZGRcDb7V6P-vYipIJTz7an_J5eL7OAucx0=.bae4c523-85ae-4438-ab68-404918323107@github.com>

On Mon, 3 Apr 2023 17:16:26 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `LinkedHashMap<IndexNode, IndexNode>` `ZipFileSystem.inodes` contains only non-null values. It means instead of separate `containsKey`+`get` calls, we can use single `LinkedHashMap.get` call and then compare result with `null`.
> Result code is a bit simpler and faster.
> 
> Testing: Linux x64 `java/nio`, `jdk/nio`

This pull request has now been integrated.

Changeset: 50d73352
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/50d73352068f588cf6db29acb56e21b0412ab768
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8305696: (zipfs) Avoid redundant LinkedHashMap.containsKey call ZipFileSystem.makeParentDirs

Reviewed-by: alanb, jpai, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/13304

From some-java-user-99206970363698485155 at vodafonemail.de  Sun Apr  9 14:57:52 2023
From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de)
Date: Sun, 09 Apr 2023 16:57:52 +0200
Subject: Add String & Character ASCII case conversion methods
Message-ID: <5c703745f0ba484c9d66b9666a1218a7@vodafonemail.de>

Hello,
could you please add String & Character ASCII case conversion methods, that is, methods which only perform case conversion on ASCII characters in the input and leave any other characters unchanged. The conversion should not depend on the default locale. For example:
- String:
  - toAsciiLowerCase
  - toAsciiUpperCase
  - equalsAsciiIgnoreCase (or a better name)
  - compareToAsciiIgnoreCase (or a better name)
- Character:
  - toAsciiLowerCase
  - toAsciiUpperCase

This would give the following advantages:
- Increased performance (+ not be vulnerable to denial of service attacks)
- Reduced number of bugs in applications


Please read on for a detailed explanation.

I assume for historic reasons (Applets) the current case conversion methods use the Unicode conversion rules, and even worse String.toLowerCase() and String.toUpperCase() use the default locale. While this might back then have been a reasonable choice because Applets ran locally in the browser and localization was a nice to have feature (or even a requirement), nowadays Java is largely used for back-end systems and case conversion is pretty often done for technical strings and not display text anymore. In this context applications mostly process ASCII strings.
However, because Java does not offer any specific case conversion methods for these cases, users still use the standard String & Character methods. This causes the following problems [1]:

- String.toLowerCase() & String.toUpperCase() using default locale
  What this means is that depending on the OS locale your application might behave differently or fail [2]. For the scale of this, simply look in the OpenJDK database: https://bugs.openjdk.org/issues/?jql=text ~ "turkish locale"
  At this point you probably have to add a disclaimer to any Java program that running it on systems with Turkish (and possibly others) as locale is not supported, because either your own code or the libraries you are using might be calling toLowerCase() or toUpperCase() [3].

- Bad performance for Unicode aware case conversions
  Compared to simply performing ASCII case conversion, applying Unicode case conversion has worse performance. In some cases it can even have extremely bad performance (JDK-8292573). This could have security implications.

- Bugs due to case conversion changing string length
  Unicode case conversion for certain strings can change the length, either increasing or decreasing the size of the string (or when combining both, shifting position of characters in the string while keeping the length the same). If an application assumes that the length of the string remains the same and uses data derived from the original string (e.g. character indices or length) on the converted string this can lead to exceptions or potentially even security issues.

- Unicode characters mapping to ASCII chars
  When performing case conversion on certain non-ASCII Unicode characters, the results are ASCII characters. For example `Character.toLowerCase('\u212A') == 'k'`. This could have security implications.

- Update to Unicode data changing application behavior
  Unicode evolves over time, and the JDK regularly updates the Unicode data it is using. Even if an application is not affected by the issues mentioned above, it could become affected by them when the Unicode data is updated in a newer JDK version.

My main point here is that (I assume) in many cases Java applications don't need Unicode case conversion, let alone Unicode case conversion using the default locale. If Java offered ASCII-only case conversion methods, then hopefully users would (where applicable) switch to these methods over time and avoid all the issues mentioned above. And even if they accidentally use the ASCII-only methods for display text, the result might be a minor inconvenience for users seeing the display text, compared to in the other cases application bugs and security vulnerabilities.

Related information about other programming languages:
- Rust: Has dedicated methods for ASCII case conversion, e.g. https://doc.rust-lang.org/std/string/struct.String.html#method.to_ascii_lowercase
- Kotlin: Functions which implicitly use the default locale were deprecated, see https://youtrack.jetbrains.com/issue/KT-43023

Risks:
- ASCII case conversion could lead to undesired results in some cases, see the example for the word "caf?" on https://doc.rust-lang.org/std/ascii/trait.AsciiExt.html (though that specific example is about a display string, for which these ASCII-only methods are not intended)
- When applications start to mix ASCII-only and the existing Unicode conversion methods this could lead to bugs and security issues as well; though it might also indicate a flaw in the application if it performs case conversion on the same value in different places

I hope you consider this suggestion. Feedback is appreciated!

Kind regards

----

[1] I am not saying though that Java is the only affected language, it definitely affects others as well. But that should not prevent improving the Java API.
[2] Tool for detecting usage of such methods: https://github.com/policeman-tools/forbidden-apis
[3] Maybe it would also be worth discussing deprecating String.toLowerCase() and String.toUpperCase() because they seem to do more harm than good.



From zjx001202 at gmail.com  Sun Apr  9 16:46:15 2023
From: zjx001202 at gmail.com (Glavo)
Date: Mon, 10 Apr 2023 00:46:15 +0800
Subject: Add String & Character ASCII case conversion methods
In-Reply-To: <5c703745f0ba484c9d66b9666a1218a7@vodafonemail.de>
References: <5c703745f0ba484c9d66b9666a1218a7@vodafonemail.de>
Message-ID: <CAJL5A3=N+Mwv0uAa2w=rF2XW2SLVpZeUv_nPrZ=vK1Ek9yF3vA@mail.gmail.com>

Hi,

We discussed this issue on this mailing list[1] earlier this year.

I investigated the usage of these two methods and found that all use cases
within
JDK are suspicious, resulting in many imperceptible bugs.

I hope to create a PR for this issue, deprecate these two methods, and
create
alternative methods for them. But I don't have the experience of making
such
changes, maybe I need some guidance or have more experienced people do
these things.

Glavo

[1]
https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html

On Sun, Apr 9, 2023 at 10:58?PM <
some-java-user-99206970363698485155 at vodafonemail.de> wrote:

> Hello,
> could you please add String & Character ASCII case conversion methods,
> that is, methods which only perform case conversion on ASCII characters in
> the input and leave any other characters unchanged. The conversion should
> not depend on the default locale. For example:
> - String:
>   - toAsciiLowerCase
>   - toAsciiUpperCase
>   - equalsAsciiIgnoreCase (or a better name)
>   - compareToAsciiIgnoreCase (or a better name)
> - Character:
>   - toAsciiLowerCase
>   - toAsciiUpperCase
>
> This would give the following advantages:
> - Increased performance (+ not be vulnerable to denial of service attacks)
> - Reduced number of bugs in applications
>
>
> Please read on for a detailed explanation.
>
> I assume for historic reasons (Applets) the current case conversion
> methods use the Unicode conversion rules, and even worse
> String.toLowerCase() and String.toUpperCase() use the default locale. While
> this might back then have been a reasonable choice because Applets ran
> locally in the browser and localization was a nice to have feature (or even
> a requirement), nowadays Java is largely used for back-end systems and case
> conversion is pretty often done for technical strings and not display text
> anymore. In this context applications mostly process ASCII strings.
> However, because Java does not offer any specific case conversion methods
> for these cases, users still use the standard String & Character methods.
> This causes the following problems [1]:
>
> - String.toLowerCase() & String.toUpperCase() using default locale
>   What this means is that depending on the OS locale your application
> might behave differently or fail [2]. For the scale of this, simply look in
> the OpenJDK database: https://bugs.openjdk.org/issues/?jql=text ~
> "turkish locale"
>   At this point you probably have to add a disclaimer to any Java program
> that running it on systems with Turkish (and possibly others) as locale is
> not supported, because either your own code or the libraries you are using
> might be calling toLowerCase() or toUpperCase() [3].
>
> - Bad performance for Unicode aware case conversions
>   Compared to simply performing ASCII case conversion, applying Unicode
> case conversion has worse performance. In some cases it can even have
> extremely bad performance (JDK-8292573). This could have security
> implications.
>
> - Bugs due to case conversion changing string length
>   Unicode case conversion for certain strings can change the length,
> either increasing or decreasing the size of the string (or when combining
> both, shifting position of characters in the string while keeping the
> length the same). If an application assumes that the length of the string
> remains the same and uses data derived from the original string (e.g.
> character indices or length) on the converted string this can lead to
> exceptions or potentially even security issues.
>
> - Unicode characters mapping to ASCII chars
>   When performing case conversion on certain non-ASCII Unicode characters,
> the results are ASCII characters. For example
> `Character.toLowerCase('\u212A') == 'k'`. This could have security
> implications.
>
> - Update to Unicode data changing application behavior
>   Unicode evolves over time, and the JDK regularly updates the Unicode
> data it is using. Even if an application is not affected by the issues
> mentioned above, it could become affected by them when the Unicode data is
> updated in a newer JDK version.
>
> My main point here is that (I assume) in many cases Java applications
> don't need Unicode case conversion, let alone Unicode case conversion using
> the default locale. If Java offered ASCII-only case conversion methods,
> then hopefully users would (where applicable) switch to these methods over
> time and avoid all the issues mentioned above. And even if they
> accidentally use the ASCII-only methods for display text, the result might
> be a minor inconvenience for users seeing the display text, compared to in
> the other cases application bugs and security vulnerabilities.
>
> Related information about other programming languages:
> - Rust: Has dedicated methods for ASCII case conversion, e.g.
> https://doc.rust-lang.org/std/string/struct.String.html#method.to_ascii_lowercase
> - Kotlin: Functions which implicitly use the default locale were
> deprecated, see https://youtrack.jetbrains.com/issue/KT-43023
>
> Risks:
> - ASCII case conversion could lead to undesired results in some cases, see
> the example for the word "caf?" on
> https://doc.rust-lang.org/std/ascii/trait.AsciiExt.html (though that
> specific example is about a display string, for which these ASCII-only
> methods are not intended)
> - When applications start to mix ASCII-only and the existing Unicode
> conversion methods this could lead to bugs and security issues as well;
> though it might also indicate a flaw in the application if it performs case
> conversion on the same value in different places
>
> I hope you consider this suggestion. Feedback is appreciated!
>
> Kind regards
>
> ----
>
> [1] I am not saying though that Java is the only affected language, it
> definitely affects others as well. But that should not prevent improving
> the Java API.
> [2] Tool for detecting usage of such methods:
> https://github.com/policeman-tools/forbidden-apis
> [3] Maybe it would also be worth discussing deprecating
> String.toLowerCase() and String.toUpperCase() because they seem to do more
> harm than good.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230410/d7ae3e6c/attachment-0001.htm>

From aturbanov at openjdk.org  Sun Apr  9 20:11:11 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 9 Apr 2023 20:11:11 GMT
Subject: RFR: 8305785: Avoid redundant HashMap.containsKey call in
 java.util.regex
Message-ID: <_WLYJq0pH0MAmUOuVtCJsRIYvmjtwi_cwW3_Wy341Ks=.17067b05-2a67-49f8-b167-6b2404165ae5@github.com>

`Pattern.namedGroups` and `Matcher.namedGroups` contains only non-null values. It means instead of separate `containsKey`+`get` calls, we can use single `HashMap.get` call and then compare result with null.
Result code is a bit simpler and faster.

-------------

Commit messages:
 - 8305785: Avoid redundant HashMap.containsKey call in java.util.regex
 - [PATCH] Avoid redundant HashMap.containsKey call in java.util.regex{Matcher, Pattern}

Changes: https://git.openjdk.org/jdk/pull/13303/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13303&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305785
  Stats: 10 lines in 2 files changed: 3 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13303/head:pull/13303

PR: https://git.openjdk.org/jdk/pull/13303

From liach at openjdk.org  Mon Apr 10 03:06:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Apr 2023 03:06:42 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <m19mkLyirsWHcsG4MZ4mVsw76KjQsJlY-Frk69e1q0E=.90e37483-9d4c-437f-88a2-ee0e26a9d68d@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
 <lG8VuoiQCo5TxTzX1baulfzsdqqGMsZMtX3cGQHCIIU=.345aa822-ff47-410d-ab58-1a7e916ac073@github.com>
 <m19mkLyirsWHcsG4MZ4mVsw76KjQsJlY-Frk69e1q0E=.90e37483-9d4c-437f-88a2-ee0e26a9d68d@github.com>
Message-ID: <eO5axAaRZ2hFG6Xm0aftP1DrnXsOle99ezw_XT2lWDU=.55292de3-bc37-464a-a62b-a1c8fd493a50@github.com>

On Sun, 9 Apr 2023 02:37:45 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> This appears to be a 4% improvement for non-concurrent structures like ArrayList or LinkedHashSet, if we ignore the baseline difference (for Iterable). This is anticipated as the growth of array size is exponential, so the total allocation is effectively O(N log(N)). Can you try with smaller quantities, like single-digit or double digits length, which may be more frequent in application?
>
> @liach Working on that.

@yuantj Alternatively, you can probably try working on the `toArray` result of a collection than to allocate a new String array. This might be more efficient for some implementations like ArrayList as well, in addition to benefiting concurrent collections.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501331722

From duke at openjdk.org  Mon Apr 10 03:12:46 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 10 Apr 2023 03:12:46 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <m19mkLyirsWHcsG4MZ4mVsw76KjQsJlY-Frk69e1q0E=.90e37483-9d4c-437f-88a2-ee0e26a9d68d@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
 <lG8VuoiQCo5TxTzX1baulfzsdqqGMsZMtX3cGQHCIIU=.345aa822-ff47-410d-ab58-1a7e916ac073@github.com>
 <m19mkLyirsWHcsG4MZ4mVsw76KjQsJlY-Frk69e1q0E=.90e37483-9d4c-437f-88a2-ee0e26a9d68d@github.com>
Message-ID: <VCLOMC1JH_nXlQ-sly6bp5cegROXt7sup1bZG80P_5w=.f08b26c4-8af9-41f8-a39b-5f33a0cd0c38@github.com>

On Sun, 9 Apr 2023 02:37:45 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> This appears to be a 4% improvement for non-concurrent structures like ArrayList or LinkedHashSet, if we ignore the baseline difference (for Iterable). This is anticipated as the growth of array size is exponential, so the total allocation is effectively O(N log(N)). Can you try with smaller quantities, like single-digit or double digits length, which may be more frequent in application?
>
> @liach Working on that.

> @yuantj Alternatively, you can probably try working on the `toArray` result of a collection than to allocate a new String array. This might be more efficient for some implementations like ArrayList as well, in addition to benefiting concurrent collections.

The method accepts collections of nullable CharSequences, which may not be Strings. So `c.toArray(new String[0])` doesn't work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501335944

From duke at openjdk.org  Mon Apr 10 03:18:48 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 10 Apr 2023 03:18:48 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <eO5axAaRZ2hFG6Xm0aftP1DrnXsOle99ezw_XT2lWDU=.55292de3-bc37-464a-a62b-a1c8fd493a50@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
 <lG8VuoiQCo5TxTzX1baulfzsdqqGMsZMtX3cGQHCIIU=.345aa822-ff47-410d-ab58-1a7e916ac073@github.com>
 <m19mkLyirsWHcsG4MZ4mVsw76KjQsJlY-Frk69e1q0E=.90e37483-9d4c-437f-88a2-ee0e26a9d68d@github.com>
 <eO5axAaRZ2hFG6Xm0aftP1DrnXsOle99ezw_XT2lWDU=.55292de3-bc37-464a-a62b-a1c8fd493a50@github.com>
Message-ID: <Ex5koKnYJv-CiOEFX5iRVaVTNLSysxCJ_UD8HLmtaMU=.729dd6d6-d325-4fef-8a60-0cd079619937@github.com>

On Mon, 10 Apr 2023 03:04:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @liach Working on that.
>
> @yuantj Alternatively, you can probably try working on the `toArray` result of a collection than to allocate a new String array. This might be more efficient for some implementations like ArrayList as well, in addition to benefiting concurrent collections.

@liach  Did you mean this?


public static String join(CharSequence delimiter,
            Iterable<? extends CharSequence> elements) {
    if (elements instanceof Collection<?> c) {
        try {
            return String.join(delimiter, c.toArray(new CharSequence[0]));
        } catch (ArrayStoreException e) {
            throw new ClassCastException(e.getMessage());
        }
    } else {
        // old implementations for non-collection iterables.
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501340839

From duke at openjdk.org  Mon Apr 10 03:25:44 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 10 Apr 2023 03:25:44 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
Message-ID: <uVGEv6-1o8uyKIvJ3LypPMYGDD0JOPxJ7X2EWZvieso=.012aa9a2-e9a9-4afb-91e9-a6c6d3769bd6@github.com>

On Sun, 9 Apr 2023 02:28:37 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
>> 
>> I don't know whether this change requires a CSR request.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark

What about setting the initial length to this?


String[] elems;
long initLen = elements.spliterator().estimateSize();
if (initLen < 8L || initLen > Integer.MAX_VALUE - 8L) {
    // This usually means the size of the Iterable cannot be computed easily.
    elems = new String[8];
} else {
    elems = new String[(int)initLen];
}


This doesn't require that `elements` is an instance of `Collection`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501344632

From liach at openjdk.org  Mon Apr 10 03:39:49 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Apr 2023 03:39:49 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
Message-ID: <60_PSLEk9SWr5pKMfsR5oJYIeMq5Xli8if1jxw4tyRA=.728db73a-fd8b-458d-bc35-8accf591c442@github.com>

On Sun, 9 Apr 2023 02:28:37 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
>> 
>> I don't know whether this change requires a CSR request.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark

Nah. I mean like:

    public static String join(CharSequence delimiter,
            Iterable<? extends CharSequence> elements) {
        Objects.requireNonNull(delimiter);
        Objects.requireNonNull(elements);
        var delim = delimiter.toString();
        Object[] elems;
        final int size;
        if (elements instanceof Collection<?> c) {
            elems = c.toArray();
            size = elems.length;
            for (int i = 0; i < size; i++) {
                elems[i] = String.valueOf(elems[i]);
            }
        } else {
            elems = new String[elements instanceof Collection<?> c ? c.size() : 8]; // or whatever spliterator you decide to use
            size = 0;
            for (CharSequence cs: elements) {
                if (size >= elems.length) {
                    elems = Arrays.copyOf(elems, elems.length << 1);
                }
                elems[size++] = String.valueOf(cs);
            }
        }
        return join("", "", delim, elems, size);
    }
// ...
static String join(String prefix, String suffix, String delimiter, Object[] elements, int size) { // change array type to Object[], cast on access elements

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501351704

From duke at openjdk.org  Mon Apr 10 04:11:45 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 10 Apr 2023 04:11:45 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <60_PSLEk9SWr5pKMfsR5oJYIeMq5Xli8if1jxw4tyRA=.728db73a-fd8b-458d-bc35-8accf591c442@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
 <60_PSLEk9SWr5pKMfsR5oJYIeMq5Xli8if1jxw4tyRA=.728db73a-fd8b-458d-bc35-8accf591c442@github.com>
Message-ID: <Rkd-n2htG3OemZxvf-XEliw2cWnEIQy6nS0MykGawSc=.9344ae31-5581-41b4-9475-1d64ccfe7122@github.com>

On Mon, 10 Apr 2023 03:36:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add benchmark
>
> Nah. I mean like:
> 
>     public static String join(CharSequence delimiter,
>             Iterable<? extends CharSequence> elements) {
>         Objects.requireNonNull(delimiter);
>         Objects.requireNonNull(elements);
>         var delim = delimiter.toString();
>         Object[] elems;
>         final int size;
>         if (elements instanceof Collection<?> c) {
>             elems = c.toArray();
>             size = elems.length;
>             for (int i = 0; i < size; i++) {
>                 elems[i] = String.valueOf(elems[i]);
>             }
>         } else {
>             elems = new String[elements instanceof Collection<?> c ? c.size() : 8]; // or whatever spliterator you decide to use
>             size = 0;
>             for (CharSequence cs: elements) {
>                 if (size >= elems.length) {
>                     elems = Arrays.copyOf(elems, elems.length << 1);
>                 }
>                 elems[size++] = String.valueOf(cs);
>             }
>         }
>         return join("", "", delim, elems, size);
>     }
> // ...
> static String join(String prefix, String suffix, String delimiter, Object[] elements, int size) { // change array type to Object[], cast on access elements

@liach I don't think it's safe because `c.toArray()` can return an array that may be modified by others. In fact, although the specification of `Collection.toArray()` indicates that the returned array is free to be modified, nobody actually trusts this contract. They only trust `ArrayList` which is most widely-used.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501368747

From liach at openjdk.org  Mon Apr 10 04:31:44 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Apr 2023 04:31:44 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <60_PSLEk9SWr5pKMfsR5oJYIeMq5Xli8if1jxw4tyRA=.728db73a-fd8b-458d-bc35-8accf591c442@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
 <60_PSLEk9SWr5pKMfsR5oJYIeMq5Xli8if1jxw4tyRA=.728db73a-fd8b-458d-bc35-8accf591c442@github.com>
Message-ID: <CEZIB2UbSuFdcR8GtC4doXDQF6BoRMyuEdJ7Ry3j5xk=.b355e4ef-73bd-43cc-8bcd-688f1fd7676b@github.com>

On Mon, 10 Apr 2023 03:36:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add benchmark
>
> Nah. I mean like:
> 
>     public static String join(CharSequence delimiter,
>             Iterable<? extends CharSequence> elements) {
>         Objects.requireNonNull(delimiter);
>         Objects.requireNonNull(elements);
>         var delim = delimiter.toString();
>         Object[] elems;
>         final int size;
>         if (elements instanceof Collection<?> c) {
>             elems = c.toArray();
>             size = elems.length;
>             for (int i = 0; i < size; i++) {
>                 elems[i] = String.valueOf(elems[i]);
>             }
>         } else {
>             elems = new String[elements instanceof Collection<?> c ? c.size() : 8]; // or whatever spliterator you decide to use
>             size = 0;
>             for (CharSequence cs: elements) {
>                 if (size >= elems.length) {
>                     elems = Arrays.copyOf(elems, elems.length << 1);
>                 }
>                 elems[size++] = String.valueOf(cs);
>             }
>         }
>         return join("", "", delim, elems, size);
>     }
> // ...
> static String join(String prefix, String suffix, String delimiter, Object[] elements, int size) { // change array type to Object[], cast on access elements

> @liach I don't think it's safe because `c.toArray()` can return an array that may be modified by others. In fact, although the specification of `Collection.toArray()` indicates that the returned array is free to be modified, nobody actually trusts this contract. They only trust `ArrayList` which is most widely-used.

It's safe. We don't keep the array in another object, and it's discarded after we finish the join. The most risky scenario is that the array is shared to another thread that can execute in parallel with the malicious Collection, which can swap out the String elements in the array we've obtained with irrelevant items.

Then you might go for https://github.com/openjdk/jdk/pull/13383#issuecomment-1501340839 but it involves one extra array copy.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501378416

From duke at openjdk.org  Mon Apr 10 04:45:41 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 10 Apr 2023 04:45:41 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <CEZIB2UbSuFdcR8GtC4doXDQF6BoRMyuEdJ7Ry3j5xk=.b355e4ef-73bd-43cc-8bcd-688f1fd7676b@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
 <60_PSLEk9SWr5pKMfsR5oJYIeMq5Xli8if1jxw4tyRA=.728db73a-fd8b-458d-bc35-8accf591c442@github.com>
 <CEZIB2UbSuFdcR8GtC4doXDQF6BoRMyuEdJ7Ry3j5xk=.b355e4ef-73bd-43cc-8bcd-688f1fd7676b@github.com>
Message-ID: <DwJWd2844o1Li6ZFO_QVfUXsoL_l1V9Z_VEH_N_Ya-U=.e832cf2d-babb-429d-be08-bfb0f73a8658@github.com>

On Mon, 10 Apr 2023 04:28:34 GMT, Chen Liang <liach at openjdk.org> wrote:

> nobody actually trusts this contract

I guess not every place should not trust this contract.

Where should we distrust contracts and use defensive programming? For example, the constructor of `ArrayList` that accepts `Collection` should not trust the `toArray` method of unknown collections. Because if the implementation of toArray is incorrect, trusting its return value will cause errors may occur in other subsequent places, rather than during the call to the constructor.

But this dangerous situation does not occur with the join method, as it does not leak the results of `toArray` to other places. If the implementation of `toArray` is incorrect, then the `join` method is not correct for it. This phenomenon is reasonable and acceptable, as long as the error does not occur outside of the join method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501384516

From duke at openjdk.org  Mon Apr 10 04:53:51 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 10 Apr 2023 04:53:51 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <CEZIB2UbSuFdcR8GtC4doXDQF6BoRMyuEdJ7Ry3j5xk=.b355e4ef-73bd-43cc-8bcd-688f1fd7676b@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
 <60_PSLEk9SWr5pKMfsR5oJYIeMq5Xli8if1jxw4tyRA=.728db73a-fd8b-458d-bc35-8accf591c442@github.com>
 <CEZIB2UbSuFdcR8GtC4doXDQF6BoRMyuEdJ7Ry3j5xk=.b355e4ef-73bd-43cc-8bcd-688f1fd7676b@github.com>
Message-ID: <mHXBKP7qcDJoNlnVMLj_Cm9SwycLmJX9jhSmdLnpaJw=.b81d824e-326d-4e49-925a-60292e4298ca@github.com>

On Mon, 10 Apr 2023 04:28:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Nah. I mean like:
>> 
>>     public static String join(CharSequence delimiter,
>>             Iterable<? extends CharSequence> elements) {
>>         Objects.requireNonNull(delimiter);
>>         Objects.requireNonNull(elements);
>>         var delim = delimiter.toString();
>>         Object[] elems;
>>         final int size;
>>         if (elements instanceof Collection<?> c) {
>>             elems = c.toArray();
>>             size = elems.length;
>>             for (int i = 0; i < size; i++) {
>>                 elems[i] = String.valueOf(elems[i]);
>>             }
>>         } else {
>>             elems = new String[elements instanceof Collection<?> c ? c.size() : 8]; // or whatever spliterator you decide to use
>>             size = 0;
>>             for (CharSequence cs: elements) {
>>                 if (size >= elems.length) {
>>                     elems = Arrays.copyOf(elems, elems.length << 1);
>>                 }
>>                 elems[size++] = String.valueOf(cs);
>>             }
>>         }
>>         return join("", "", delim, elems, size);
>>     }
>> // ...
>> static String join(String prefix, String suffix, String delimiter, Object[] elements, int size) { // change array type to Object[], cast on access elements
>
>> @liach I don't think it's safe because `c.toArray()` can return an array that may be modified by others. In fact, although the specification of `Collection.toArray()` indicates that the returned array is free to be modified, nobody actually trusts this contract. They only trust `ArrayList` which is most widely-used.
> 
> It's safe. We don't keep the array in another object, and it's discarded after we finish the join. The most risky scenario is that the array is shared to another thread that can execute in parallel with the malicious Collection, which can swap out the String elements in the array we've obtained with irrelevant items.
> 
> Then you might go for https://github.com/openjdk/jdk/pull/13383#issuecomment-1501340839 but it involves one extra array copy.

But @liach 's sample modifies the returned array directly. It cause problems with this situation:


class BadList implements List<Object> {
    private Object[] array;

    public Object get(int i) {
        return array[i];
    }

    public Object[] toArray() {
        return array;  // no clone
    }

    // ...
}


Modifying the array will accidentally modify the collection implemented as above. That's why we should not trust that the array is *safe to be modified*.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501387583

From duke at openjdk.org  Mon Apr 10 04:59:43 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 10 Apr 2023 04:59:43 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
Message-ID: <OElH9uMVG6tctet0MPtq7HsqhJt6VIPnfQTjvhnZnZY=.66ccdc21-9d13-4a82-98d0-805acc567ece@github.com>

On Sun, 9 Apr 2023 02:28:37 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
>> 
>> I don't know whether this change requires a CSR request.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark

If you really don't trust a collection, then we can't do anything.

Can copying the results of `toArray` ensure accuracy and security? It has too many possible problems. Maybe the size of the array is wrong, maybe it forgot to copy the contents of the collection and all it returns is an array full of nulls.

To put it one step further, is its iterator necessarily correct? Perhaps its iterator implementation is also incorrect:


class BadList implements List<Object> {
    private Object[] array;

    // ...

    public Iterator<Object> iterator(){
        return new Iterator<Object>() {
            int i = 0;

            public boolean hasNext() {
                return true;
            }

            public Object next() {
                array[i++] = null;
                return new Object(); // crazy implementation
            }
        };
    }
}


But who cares? Since its implementation is incorrect, it is normal for it to suffer for itself. We only need to prevent errors from being leaked to other places, rather than defending against all errors.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501390568

From liach at openjdk.org  Mon Apr 10 05:11:45 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Apr 2023 05:11:45 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
Message-ID: <4kFaWdiKNETHPd-_y22R-pw9tnllInxGKOTlK56nOwU=.c3dfdf53-5584-40db-b656-0f271e66c199@github.com>

On Sun, 9 Apr 2023 02:28:37 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
>> 
>> I don't know whether this change requires a CSR request.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark

I recommended toArray for concurrent collections usually optimize that better than size. The goal is to defend against malicious actors that produce broken objects (like method parameters with void type), and tossing a problem back to the actor is a good enough solution. All these broken toArray will immediately backfire to the caller or execute normally without side effects, so I think toArray is safe.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501400056

From duke at openjdk.org  Mon Apr 10 05:16:53 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 10 Apr 2023 05:16:53 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <OElH9uMVG6tctet0MPtq7HsqhJt6VIPnfQTjvhnZnZY=.66ccdc21-9d13-4a82-98d0-805acc567ece@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
 <OElH9uMVG6tctet0MPtq7HsqhJt6VIPnfQTjvhnZnZY=.66ccdc21-9d13-4a82-98d0-805acc567ece@github.com>
Message-ID: <BZU9giDi5MFjLIRNpUojs6o1j-iGryTOORduciNSL6g=.786117dd-12b7-4462-a006-ecac6f69d7d3@github.com>

On Mon, 10 Apr 2023 04:57:09 GMT, Glavo <duke at openjdk.org> wrote:

>> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add benchmark
>
> If you really don't trust a collection, then we can't do anything.
> 
> Can copying the results of `toArray` ensure accuracy and security? It has too many possible problems. Maybe the size of the array is wrong, maybe it forgot to copy the contents of the collection and all it returns is an array full of nulls.
> 
> To put it one step further, is its iterator necessarily correct? Perhaps its iterator implementation is also incorrect:
> 
> 
> class BadList implements List<Object> {
>     private Object[] array;
> 
>     // ...
> 
>     public Iterator<Object> iterator() {
>         // crazy implementation
>         return new Iterator<Object>() {
>             int i = 0;
> 
>             public boolean hasNext() {
>                 return Math.random() < 0.5;
>             }
> 
>             public Object next() {
>                 if (Math.random() < 0.25) {
>                     array[i++] = null;
>                     return new Object();
>                 } else {
>                     return array[i++];
>                 }                 
>             }
>         };
>     }
> }
> 
> 
> But who cares? Since its implementation is incorrect, it is normal for it to suffer for itself. We only need to prevent errors from being leaked to other places, rather than defending against all errors.

@Glavo Then why doesn't `ArrayList` trust `toArray()`? If all implementations behave correctly, then it should return an `Object[]` independent of the original collection, so `ArrayList` should trust it. Those who doesn't implement `toArray()` correctly should use these methods at their own risk, shouldn't they?

This PR modifies a class that is used by nearly every JVM code, so safety is more important than performance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501402954

From duke at openjdk.org  Mon Apr 10 05:16:53 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 10 Apr 2023 05:16:53 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <BZU9giDi5MFjLIRNpUojs6o1j-iGryTOORduciNSL6g=.786117dd-12b7-4462-a006-ecac6f69d7d3@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
 <OElH9uMVG6tctet0MPtq7HsqhJt6VIPnfQTjvhnZnZY=.66ccdc21-9d13-4a82-98d0-805acc567ece@github.com>
 <BZU9giDi5MFjLIRNpUojs6o1j-iGryTOORduciNSL6g=.786117dd-12b7-4462-a006-ecac6f69d7d3@github.com>
Message-ID: <VFbclUCUoOjGkDZVRl5EruOK2tR0iRkDQw01xE5a2R8=.c0497f87-ec58-48b4-aa50-b6349a6a16f2@github.com>

On Mon, 10 Apr 2023 05:12:07 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> If you really don't trust a collection, then we can't do anything.
>> 
>> Can copying the results of `toArray` ensure accuracy and security? It has too many possible problems. Maybe the size of the array is wrong, maybe it forgot to copy the contents of the collection and all it returns is an array full of nulls.
>> 
>> To put it one step further, is its iterator necessarily correct? Perhaps its iterator implementation is also incorrect:
>> 
>> 
>> class BadList implements List<Object> {
>>     private Object[] array;
>> 
>>     // ...
>> 
>>     public Iterator<Object> iterator() {
>>         // crazy implementation
>>         return new Iterator<Object>() {
>>             int i = 0;
>> 
>>             public boolean hasNext() {
>>                 return Math.random() < 0.5;
>>             }
>> 
>>             public Object next() {
>>                 if (Math.random() < 0.25) {
>>                     array[i++] = null;
>>                     return new Object();
>>                 } else {
>>                     return array[i++];
>>                 }                 
>>             }
>>         };
>>     }
>> }
>> 
>> 
>> But who cares? Since its implementation is incorrect, it is normal for it to suffer for itself. We only need to prevent errors from being leaked to other places, rather than defending against all errors.
>
> @Glavo Then why doesn't `ArrayList` trust `toArray()`? If all implementations behave correctly, then it should return an `Object[]` independent of the original collection, so `ArrayList` should trust it. Those who doesn't implement `toArray()` correctly should use these methods at their own risk, shouldn't they?
> 
> This PR modifies a class that is used by nearly every JVM code, so safety is more important than performance.

@yuantj As I mentioned earlier, we need to prevent errors from leaking to other places, rather than defending against all errors.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501404519

From duke at openjdk.org  Mon Apr 10 05:23:50 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 10 Apr 2023 05:23:50 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <VFbclUCUoOjGkDZVRl5EruOK2tR0iRkDQw01xE5a2R8=.c0497f87-ec58-48b4-aa50-b6349a6a16f2@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
 <OElH9uMVG6tctet0MPtq7HsqhJt6VIPnfQTjvhnZnZY=.66ccdc21-9d13-4a82-98d0-805acc567ece@github.com>
 <BZU9giDi5MFjLIRNpUojs6o1j-iGryTOORduciNSL6g=.786117dd-12b7-4462-a006-ecac6f69d7d3@github.com>
 <VFbclUCUoOjGkDZVRl5EruOK2tR0iRkDQw01xE5a2R8=.c0497f87-ec58-48b4-aa50-b6349a6a16f2@github.com>
Message-ID: <dc5P1YYYPVxNHYZseSXyz4sINHPcj2YTQT4HtqzTpCs=.552425e8-23d3-4c85-b169-e6968e63a015@github.com>

On Mon, 10 Apr 2023 05:14:16 GMT, Glavo <duke at openjdk.org> wrote:

>> @Glavo Then why doesn't `ArrayList` trust `toArray()`? If all implementations behave correctly, then it should return an `Object[]` independent of the original collection, so `ArrayList` should trust it. Those who doesn't implement `toArray()` correctly should use these methods at their own risk, shouldn't they?
>> 
>> This PR modifies a class that is used by nearly every JVM code, so safety is more important than performance.
>
> @yuantj As I mentioned earlier, we need to prevent errors from leaking to other places, rather than defending against all errors.

> @Glavo Then why doesn't `ArrayList` trust `toArray()`? If all implementations behave correctly, then it should return an `Object[]` independent of the original collection, so `ArrayList` should trust it. Those who doesn't implement `toArray()` correctly should use these methods at their own risk, shouldn't they?

I already explained the reason in detail in my earliest reply.

> This PR modifies a class that is used by nearly every JVM code, so safety is more important than performance.

Even without using `toArray`, security cannot be guaranteed. Just like the `BadList` in my previous example, if you cannot trust this collection, then we cannot do anything because its iterator may also be unsafe.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501408139

From duke at openjdk.org  Mon Apr 10 05:23:52 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 10 Apr 2023 05:23:52 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
Message-ID: <vRgv2oMEh_0OEwKqbqlGRsbIRu7eVvuGsdum7fQK6KM=.ad2a3470-dfa5-47bc-b778-edc1b8eba5c3@github.com>

On Sun, 9 Apr 2023 02:28:37 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
>> 
>> I don't know whether this change requires a CSR request.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark

Furthermore, I did not and will not defend against all possible errors.

One possible solution is change the package-private `join` method to accept an `Iterable` rather an `Object[]`, and change `String.join(CharSequence, CharSequence...)` to wrap the array with `Arrays.asList(E...)`, then we don't have to create any copies.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501408398

From liach at openjdk.org  Mon Apr 10 05:23:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Apr 2023 05:23:53 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <dc5P1YYYPVxNHYZseSXyz4sINHPcj2YTQT4HtqzTpCs=.552425e8-23d3-4c85-b169-e6968e63a015@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
 <OElH9uMVG6tctet0MPtq7HsqhJt6VIPnfQTjvhnZnZY=.66ccdc21-9d13-4a82-98d0-805acc567ece@github.com>
 <BZU9giDi5MFjLIRNpUojs6o1j-iGryTOORduciNSL6g=.786117dd-12b7-4462-a006-ecac6f69d7d3@github.com>
 <VFbclUCUoOjGkDZVRl5EruOK2tR0iRkDQw01xE5a2R8=.c0497f87-ec58-48b4-aa50-b6349a6a16f2@github.com>
 <dc5P1YYYPVxNHYZseSXyz4sINHPcj2YTQT4HtqzTpCs=.552425e8-23d3-4c85-b169-e6968e63a015@github.com>
Message-ID: <BzGurc_a_jIL0AJgFZrPSbh3OkUsQB_vSV0jA7noOMU=.9b72a850-800b-49e2-8c30-4c1179e594b0@github.com>

On Mon, 10 Apr 2023 05:19:05 GMT, Glavo <duke at openjdk.org> wrote:

>> @yuantj As I mentioned earlier, we need to prevent errors from leaking to other places, rather than defending against all errors.
>
>> @Glavo Then why doesn't `ArrayList` trust `toArray()`? If all implementations behave correctly, then it should return an `Object[]` independent of the original collection, so `ArrayList` should trust it. Those who doesn't implement `toArray()` correctly should use these methods at their own risk, shouldn't they?
> 
> I already explained the reason in detail in my earliest reply.
> 
>> This PR modifies a class that is used by nearly every JVM code, so safety is more important than performance.
> 
> Even without using `toArray`, security cannot be guaranteed. Just like the `BadList` in my previous example, if you cannot trust this collection, then we cannot do anything because its iterator may also be unsafe.

> @Glavo Then why doesn't `ArrayList` trust `toArray()`? If all implementations behave correctly, then it should return an `Object[]` independent of the original collection, so `ArrayList` should trust it. Those who doesn't implement `toArray()` correctly should use these methods at their own risk, shouldn't they?
> 
> This PR modifies a class that is used by nearly every JVM code, so safety is more important than performance.

@yuantj Because ArrayList stores that array. It doesn't want its state to mutate without calling collection mutator methods. Same goes for MethodType.methodTye. However, in our case, we are just using it momentarily and not storing the array from collection, so it's safe not to copy the array, like in MethodType.insertParameterTypes. If you really lacks trust, you can just convert to stream and call toArray, which always return a trusted array.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501408955

From duke at openjdk.org  Mon Apr 10 05:28:45 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 10 Apr 2023 05:28:45 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
Message-ID: <pmg4tLEq-SIFaygeRJRXmdkao4h233HXYIUylMu4vvE=.4b9ff1b6-a94b-42fe-9c91-ba4dd3fd5b53@github.com>

On Sun, 9 Apr 2023 02:28:37 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
>> 
>> I don't know whether this change requires a CSR request.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark

Just as below:

public static String join(CharSequence delim, CharSequence... elems) {
    return join("", "", delim, Arrays.asList(elems);
}

public static String join(CharSequence delim, Iterable<? extends CharSequence> elems) {
    return join("", "", delim, elems);
}

static String join(String prefix, String suffix, String delimiter, Iterable<? extends CharSequence> elems) {
    // main implementation
}

// used by JavaLangAccess
static String join(String prefix, String suffix, String delim, String[] elements, int size) {
    return join(prefix, suffix, delim, Arrays.asList(elements).subList(0, size));
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501411745

From liach at openjdk.org  Mon Apr 10 05:31:44 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Apr 2023 05:31:44 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
Message-ID: <-miQQU36p-JIgVipmpj0jzzVu960MX8vccLX_Y-qq9o=.43fb5945-d4d1-4dc1-9b7e-ac1e4de6f3f1@github.com>

On Sun, 9 Apr 2023 02:28:37 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
>> 
>> I don't know whether this change requires a CSR request.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark

Converting array to iterable almost guarantees performance degradation, with the extra iterator allocation. Often even forEach is better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501413441

From duke at openjdk.org  Mon Apr 10 05:46:23 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 10 Apr 2023 05:46:23 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v3]
In-Reply-To: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
Message-ID: <RtgJpCzuZjU92WPYpxNfz8KsyPm4ZGMoOp7-Ua4qlFU=.277f86a2-b3d8-40d1-a15f-48083ded05dd@github.com>

> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
> 
> I don't know whether this change requires a CSR request.

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  use spliterator().estimateSize()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13383/files
  - new: https://git.openjdk.org/jdk/pull/13383/files/50e670c7..4fe345ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13383&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13383&range=01-02

  Stats: 9 lines in 1 file changed: 7 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13383.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13383/head:pull/13383

PR: https://git.openjdk.org/jdk/pull/13383

From duke at openjdk.org  Mon Apr 10 05:46:23 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 10 Apr 2023 05:46:23 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v2]
In-Reply-To: <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <O5hkShErQ0qQFzA64CpszctP5ufPG_zF9Np-HkBtT7M=.b8b78ea3-966e-4edb-a621-0833f65d23e5@github.com>
Message-ID: <esuvSVbWb6tPL-CdrbYa70vm4qhMvHOBuRvIgfK8EUw=.707a021f-00fc-44c1-a828-49f49cca578a@github.com>

On Sun, 9 Apr 2023 02:28:37 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
>> 
>> I don't know whether this change requires a CSR request.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark

In conclusion, I just don't want to make this change much complicated. So I decide to use `spliterator().estimateSize()` and later benchmark it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13383#issuecomment-1501420066

From jpai at openjdk.org  Mon Apr 10 08:32:46 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Apr 2023 08:32:46 GMT
Subject: RFR: 8205129: Remove java.lang.Compiler
In-Reply-To: <k5oL-_x7ZlO48IYXqrBVQK_KhbPiLwrQSAXFgyWu8pk=.9834a282-838a-4893-b751-a8b318b68d37@github.com>
References: <k5oL-_x7ZlO48IYXqrBVQK_KhbPiLwrQSAXFgyWu8pk=.9834a282-838a-4893-b751-a8b318b68d37@github.com>
Message-ID: <kzplfDgH8i1pZwFTQOulDpLc_Z3OLxeA3i-V-POCJzI=.700da3d5-f324-493c-a211-013f6c7d4c36@github.com>

On Sun, 19 Mar 2023 09:01:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please help review this PR which suggests we remove the class `java.lang.Compiler`. The class seems non-functional for a decade, and was terminally deprecated in Java 9. Time has come to let it go.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13092#pullrequestreview-1377245088

From duke at openjdk.org  Mon Apr 10 08:35:56 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 10 Apr 2023 08:35:56 GMT
Subject: Integrated: 8205129: Remove java.lang.Compiler
In-Reply-To: <k5oL-_x7ZlO48IYXqrBVQK_KhbPiLwrQSAXFgyWu8pk=.9834a282-838a-4893-b751-a8b318b68d37@github.com>
References: <k5oL-_x7ZlO48IYXqrBVQK_KhbPiLwrQSAXFgyWu8pk=.9834a282-838a-4893-b751-a8b318b68d37@github.com>
Message-ID: <zuMMcph2hvtjARF0jD09yYxOZBH0u0hCFxxTzEgZiz0=.2f1730ce-05c5-4d7d-92e8-098fe58556fb@github.com>

On Sun, 19 Mar 2023 09:01:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please help review this PR which suggests we remove the class `java.lang.Compiler`. The class seems non-functional for a decade, and was terminally deprecated in Java 9. Time has come to let it go.

This pull request has now been integrated.

Changeset: a8e3a2dd
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a8e3a2dd2f8025986501f59f085afeffa6559e6b
Stats:     105 lines in 1 file changed: 0 ins; 105 del; 0 mod

8205129: Remove java.lang.Compiler

Reviewed-by: alanb, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/13092

From alanb at openjdk.org  Mon Apr 10 10:11:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Apr 2023 10:11:47 GMT
Subject: RFR: 8305748: Clarify reentrant behavior of close() in
 FileInputStream, FileOutputStream, and RandomAccessFile [v3]
In-Reply-To: <RraYLzBv8h4DYRPcJWc32nsXMUq-icAEem6XvzIBP-A=.0708429e-61af-4e3e-ae1e-3b96a70f38d0@github.com>
References: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
 <RraYLzBv8h4DYRPcJWc32nsXMUq-icAEem6XvzIBP-A=.0708429e-61af-4e3e-ae1e-3b96a70f38d0@github.com>
Message-ID: <9fAghAmdCVNHiDs8duAQeZnXMBkD_VMS46bKsmphZoA=.e221f823-bf08-4de1-a4d5-0b2b33ff5ef6@github.com>

On Fri, 7 Apr 2023 18:24:42 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> IO stream classes like `FileOutputStream` can have assocated NIO channels.
>> 
>> When `close()` is invoked on one of these classes, it in turn invokes `close()` on the associated channel (if any). But when the associated channel's `close()` method is invoked, it in turn invokes `close()` on the associated stream (if any).
>> 
>> As a result, these IO stream `close()` methods invoke themselves reentrantly when there is an associated channel.
>> 
>> This is not a problem for these classes because they are written to handle this (i.e., they are idempotent), but it can be surprising (or worse, just silently bug-inducing) for subclasses that override `close()`.
>> 
>> There are two possible ways to address this:
>> 1. Modify the code to detect and avoid the (unnecessary) reentrant invocations
>> 2. Add a `@implNote` to the Javadoc so subclass implementers are made aware
>> 
>> This patch takes the second, more conservative approach.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13379#pullrequestreview-1377345855

From lancea at openjdk.org  Mon Apr 10 10:11:53 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 10 Apr 2023 10:11:53 GMT
Subject: RFR: 8302819: Remove JAR Index [v6]
In-Reply-To: <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
Message-ID: <Czu-mBUM7EfgSs7RXn9mc0HbbTNOgdHhwp36NM7xwIw=.ef63b4eb-1a25-4e04-b16d-10c62540fe11@github.com>

On Fri, 7 Apr 2023 07:47:49 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a note in the --help for --generate-index that this option is deprecated and may be removed in a future release.

> It seems the stars are getting aligned for this PR to be integrated.
> 
> None of the current approvals apply to the latest commit [d04df25](https://github.com/openjdk/jdk/commit/d04df25ea2dd505f2224bff446865a0974a8f37a), it would be good to have that `jar --help` update approved as well.
> 
> Are there any other concerns left before we can integrate?

I think we are good to go.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1501639744

From lancea at openjdk.org  Mon Apr 10 10:13:52 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 10 Apr 2023 10:13:52 GMT
Subject: RFR: 8305758: Update the JAR tool man page to indicate
 -i/--generate-file is deprecated [v2]
In-Reply-To: <rKQ1y-A4MHFzqmvT2_RM9yGgUWMJ-DK1CMuFWHyIqts=.6c84fd7e-6a78-46e7-9182-656945374691@github.com>
References: <rKQ1y-A4MHFzqmvT2_RM9yGgUWMJ-DK1CMuFWHyIqts=.6c84fd7e-6a78-46e7-9182-656945374691@github.com>
Message-ID: <pCxWDcY2KNT0UYOlW7IYMnDS12ikNsSBTGoBvo_9Npg=.bb763d55-df81-4031-bf7d-b29fb387ac6d@github.com>

> Hi all,
> 
> Please review this MR which updates the jar man page to to indicate that  --generate-index/-I are deprecated and may be removed in a future release
> 
> Support for JAR Index is being removed via JDK-8302819.

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Update version

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13400/files
  - new: https://git.openjdk.org/jdk/pull/13400/files/5fe1e8e1..d93ec834

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13400&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13400&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13400.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13400/head:pull/13400

PR: https://git.openjdk.org/jdk/pull/13400

From alanb at openjdk.org  Mon Apr 10 10:13:54 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Apr 2023 10:13:54 GMT
Subject: RFR: 8305758: Update the JAR tool man page to indicate
 -i/--generate-file is deprecated [v2]
In-Reply-To: <pCxWDcY2KNT0UYOlW7IYMnDS12ikNsSBTGoBvo_9Npg=.bb763d55-df81-4031-bf7d-b29fb387ac6d@github.com>
References: <rKQ1y-A4MHFzqmvT2_RM9yGgUWMJ-DK1CMuFWHyIqts=.6c84fd7e-6a78-46e7-9182-656945374691@github.com>
 <pCxWDcY2KNT0UYOlW7IYMnDS12ikNsSBTGoBvo_9Npg=.bb763d55-df81-4031-bf7d-b29fb387ac6d@github.com>
Message-ID: <wdrmBuUeNJ0LlcNdJkr7EkQFnul5EeJnj5oh09hHDBM=.84f1b2c7-e2f7-4b67-9907-83facbc4bfbb@github.com>

On Mon, 10 Apr 2023 10:09:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this MR which updates the jar man page to to indicate that  --generate-index/-I are deprecated and may be removed in a future release
>> 
>> Support for JAR Index is being removed via JDK-8302819.
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update version

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13400#pullrequestreview-1377344849

From lancea at openjdk.org  Mon Apr 10 10:13:55 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 10 Apr 2023 10:13:55 GMT
Subject: RFR: 8305758: Update the JAR tool man page to indicate
 -i/--generate-file is deprecated [v2]
In-Reply-To: <uD12n_ddf2Wyz7J6LCLkGJbGQjxLxbKUsfrnkgSkQ3s=.cfe99fdb-906a-43e8-8c60-4c343ddaea2c@github.com>
References: <rKQ1y-A4MHFzqmvT2_RM9yGgUWMJ-DK1CMuFWHyIqts=.6c84fd7e-6a78-46e7-9182-656945374691@github.com>
 <uD12n_ddf2Wyz7J6LCLkGJbGQjxLxbKUsfrnkgSkQ3s=.cfe99fdb-906a-43e8-8c60-4c343ddaea2c@github.com>
Message-ID: <1FjJ11yLh44wd5iptO81LRgC7KqB0NjL9jT6SxKn_UM=.3a2a95ba-e8e7-41c2-9846-e893b57a5805@github.com>

On Sat, 8 Apr 2023 15:53:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume you didn't mean to edit this.

Updated, thank you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13400#discussion_r1161603585

From lancea at openjdk.org  Mon Apr 10 10:15:51 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 10 Apr 2023 10:15:51 GMT
Subject: RFR: 8302819: Remove JAR Index [v6]
In-Reply-To: <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
Message-ID: <bshbqRBVTcIUuYkCQCg3pcMXu4CzCjq6kEymbMDaj8o=.82964e6e-0d88-4455-93a2-3fc986514b50@github.com>

On Fri, 7 Apr 2023 07:47:49 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a note in the --help for --generate-index that this option is deprecated and may be removed in a future release.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13158#pullrequestreview-1377350274

From duke at openjdk.org  Mon Apr 10 10:45:48 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 10 Apr 2023 10:45:48 GMT
Subject: RFR: 8302819: Remove JAR Index [v6]
In-Reply-To: <Czu-mBUM7EfgSs7RXn9mc0HbbTNOgdHhwp36NM7xwIw=.ef63b4eb-1a25-4e04-b16d-10c62540fe11@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
 <Czu-mBUM7EfgSs7RXn9mc0HbbTNOgdHhwp36NM7xwIw=.ef63b4eb-1a25-4e04-b16d-10c62540fe11@github.com>
Message-ID: <zfOVzfE3t5S_KjbOBT8uJzYdxO3j_ZBwNib5mbfeCYY=.eebc4d0c-725c-48a2-8eae-8dbd294731d1@github.com>

On Mon, 10 Apr 2023 10:09:04 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I think we are good to go.

Thanks, the PR is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1501666039

From duke at openjdk.org  Mon Apr 10 11:27:02 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 10 Apr 2023 11:27:02 GMT
Subject: Integrated: 8302819: Remove JAR Index
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: <SE0GbU2IGKwdxzIV1_xwGBovTJTvZmWjU7jetXCcJCY=.77b913b2-685f-47fa-8651-8210c91291aa@github.com>

On Thu, 23 Mar 2023 12:05:50 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.

This pull request has now been integrated.

Changeset: 0d45a524
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0d45a524b3d29fd57a4d468d7b5af0f588db7409
Stats:     1826 lines in 25 files changed: 231 ins; 1580 del; 15 mod

8302819: Remove JAR Index

Reviewed-by: mchung, alanb, lancea, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/13158

From jpai at openjdk.org  Mon Apr 10 12:01:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Apr 2023 12:01:45 GMT
Subject: RFR: 8305758: Update the JAR tool man page to indicate
 -i/--generate-file is deprecated [v2]
In-Reply-To: <pCxWDcY2KNT0UYOlW7IYMnDS12ikNsSBTGoBvo_9Npg=.bb763d55-df81-4031-bf7d-b29fb387ac6d@github.com>
References: <rKQ1y-A4MHFzqmvT2_RM9yGgUWMJ-DK1CMuFWHyIqts=.6c84fd7e-6a78-46e7-9182-656945374691@github.com>
 <pCxWDcY2KNT0UYOlW7IYMnDS12ikNsSBTGoBvo_9Npg=.bb763d55-df81-4031-bf7d-b29fb387ac6d@github.com>
Message-ID: <DWUNf1joT19DyJaFdj6WWO-6gaMZSR4xRHSOWEGUnS0=.f7606caa-5ee9-4f76-bf25-e5ebbcbf67f4@github.com>

On Mon, 10 Apr 2023 10:13:52 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this MR which updates the jar man page to to indicate that  --generate-index/-I are deprecated and may be removed in a future release
>> 
>> Support for JAR Index is being removed via JDK-8302819.
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update version

This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13400#pullrequestreview-1377445230

From duke at openjdk.org  Mon Apr 10 13:20:49 2023
From: duke at openjdk.org (jmehrens)
Date: Mon, 10 Apr 2023 13:20:49 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v3]
In-Reply-To: <RtgJpCzuZjU92WPYpxNfz8KsyPm4ZGMoOp7-Ua4qlFU=.277f86a2-b3d8-40d1-a15f-48083ded05dd@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <RtgJpCzuZjU92WPYpxNfz8KsyPm4ZGMoOp7-Ua4qlFU=.277f86a2-b3d8-40d1-a15f-48083ded05dd@github.com>
Message-ID: <LUk2Ieylad6F_XsBE_B03FB2ZVoVE5GB06C3f_l1Vmw=.190f1a30-7b54-44ff-ad94-b3102327aeff@github.com>

On Mon, 10 Apr 2023 05:46:23 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
>> 
>> I don't know whether this change requires a CSR request.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use spliterator().estimateSize()

src/java.base/share/classes/java/lang/String.java line 3466:

> 3464:         }
> 3465:         int size = 0;
> 3466:         for (CharSequence cs: elements) {

I would think you have to locally store the result of `elements.spliterator()` and then use Spliterators::iterator to adapt it back to an iterator.  This should correctly handle [early-binding](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Spliterator.html#binding) spliterators.

I think in the loop the code should use ArraysSupport.newLength.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13383#discussion_r1161712521

From stsypanov at openjdk.org  Mon Apr 10 14:01:53 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 10 Apr 2023 14:01:53 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v3]
In-Reply-To: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
Message-ID: <5e1c0aIHmpueO2gPCS4suJh3Jo0RVhWpSkUnMmnM2uw=.7592dbee-3c4e-4ba7-8c7c-9184fa3ddcbe@github.com>

> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
> 
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>   .appendLiteral("Date:")
>   .padNext(20, ' ')
>   .append(DateTimeFormatter.ISO_DATE)
>   .toFormatter();
> String text = dtf.format(LocalDateTime.now());

Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' into dtfb
 - 8300818: Add benchmark
 - 8300818: Add benchmark
 - Revert irrelevant change
 - Merge branch 'master' into dtfb
 - Improve padding of DateTimeFormatter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12131/files
  - new: https://git.openjdk.org/jdk/pull/12131/files/322ae9b4..b40de5a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12131&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12131&range=01-02

  Stats: 497235 lines in 5533 files changed: 277601 ins; 160858 del; 58776 mod
  Patch: https://git.openjdk.org/jdk/pull/12131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12131/head:pull/12131

PR: https://git.openjdk.org/jdk/pull/12131

From lancea at openjdk.org  Mon Apr 10 14:14:54 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 10 Apr 2023 14:14:54 GMT
Subject: Integrated: 8305758: Update the JAR tool man page to indicate
 -i/--generate-file is deprecated
In-Reply-To: <rKQ1y-A4MHFzqmvT2_RM9yGgUWMJ-DK1CMuFWHyIqts=.6c84fd7e-6a78-46e7-9182-656945374691@github.com>
References: <rKQ1y-A4MHFzqmvT2_RM9yGgUWMJ-DK1CMuFWHyIqts=.6c84fd7e-6a78-46e7-9182-656945374691@github.com>
Message-ID: <g5rk4AN9Ljs2BNX_aP_l1nHoR1tB-KY_4K14faYO_g0=.e30e13d4-a3eb-4edf-8ed1-e87bca302291@github.com>

On Sat, 8 Apr 2023 10:33:48 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this MR which updates the jar man page to to indicate that  --generate-index/-I are deprecated and may be removed in a future release
> 
> Support for JAR Index is being removed via JDK-8302819.

This pull request has now been integrated.

Changeset: 76975da5
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/76975da59e85c1520e97384f7ab707787e41a019
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8305758: Update the JAR tool man page to indicate -i/--generate-file is deprecated

Reviewed-by: alanb, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/13400

From jbhateja at openjdk.org  Mon Apr 10 15:14:51 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 10 Apr 2023 15:14:51 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: <buzCSAY9Gr87vBrf6IAEfpVejL33HGEvh0myKAsus6k=.237019ac-ff46-422c-8f37-ed7ceef8b4dc@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
 <o-4GAbPsOv3lW_IFRcx5Ii_rPgIJ7pTH1axmmtd7oaA=.c2c248b1-bd0c-43ff-ba25-fb90be3d98a3@github.com>
 <fmI--ihud_n-PgIsWGOcty7kScPkSO1rZltNx4ZB2xA=.82c99f84-ede6-4531-9aa8-cd5212121b40@github.com>
 <buzCSAY9Gr87vBrf6IAEfpVejL33HGEvh0myKAsus6k=.237019ac-ff46-422c-8f37-ed7ceef8b4dc@github.com>
Message-ID: <JlC26Wq01TsmgcabNz-1BzpyIyTUzKig2cGetS0D4Ds=.d2d387a4-1b9e-414d-9c3b-81ae9a92f29a@github.com>

On Fri, 7 Apr 2023 17:12:08 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Power of two step count may be replaced by logical right shifts. But special handling may impact generic path
>> , currently c2 inline expander handles these special cases.
>> 
>> Alternatively we can keep this implementation at its and enhance vector idealizations to handle identity scenarios, multiply by 1, addition by 0, shift replacement for power of two multiply, since their scalar counterparts do handle these cases and SLP generated code gets a benefit of that.
>
> Thanks a lot for your review, I think that transforming a multiplication by a power of 2 into a shift can be done by the C2 compiler. I have added the special case for `start = 0 && step == 1` since it may be more common and can be optimised away when the arguments are constants.

For x86 byte vector multiplication is done at granularity of short lanes, this case shows regression with power of two multiplications which are strength reduced to shifts currently. please file a follow up bug report for this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1161806381

From rriggs at openjdk.org  Mon Apr 10 15:24:49 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 10 Apr 2023 15:24:49 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v2]
In-Reply-To: <dg6qtk5ave9VNr7E0Jf7nHBB9OgkJdJq-A_17OsP094=.1113df8d-50f7-4baa-a8e8-8aef1ee61ac0@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <dg6qtk5ave9VNr7E0Jf7nHBB9OgkJdJq-A_17OsP094=.1113df8d-50f7-4baa-a8e8-8aef1ee61ac0@github.com>
Message-ID: <OQI29CEXN1M-5u_8Y7SLcxMC-SEO3OwOoeL-gunFNlE=.2b59085c-72ba-4a11-852f-57528a390819@github.com>

On Fri, 7 Apr 2023 14:11:36 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8305486: Add split() variants that keep the delimiters to String and j.u.r.Pattern
>   Restored original JavaDoc to existing methods.
>   Replaced proposed parametrized split(*, boolean) methods with suggested splitWithDelimiters(*) variants.
>   Adjusted tests accordingly.

src/java.base/share/classes/java/lang/String.java line 3237:

> 3235:      * the array are in the order in which they occur in this string.  If the
> 3236:      * expression does not match any part of the input then the resulting array
> 3237:      * has just one element, namely this string.

This paragraph duplicates part of the next paragraph.

src/java.base/share/classes/java/lang/String.java line 3253:

> 3251:      * string then an empty leading substring is included at the beginning
> 3252:      * of the resulting array. A zero-width match at the beginning however
> 3253:      * never produces such empty leading substring.

Is there any case in which it is ambiguous whether the first element is a string or delimiter?
I'm not sure what patterns could be zero-width.  But perhaps, a regex such as "^|\s", where one of the patterns could be zero-width and the other is non-zero width?
That could make the API hard to use.

src/java.base/share/classes/java/lang/String.java line 3302:

> 3300:      * <tr><!-- o -->
> 3301:      *     <th scope="row" style="font-weight:normal; text-align:right; padding-right:1em">0</th>
> 3302:      *     <td>{@code { "b", "o", "", "o", ":::and::f", "o", "", "o" }}</td></tr>

These cases might be a bit easier to understand if the regex matched characters that looked more like delimiters, perhaps just ":".

src/java.base/share/classes/java/lang/String.java line 3324:

> 3322:      *         the result threshold, as described above
> 3323:      *
> 3324:      * @return  the array of strings computed by splitting this string

Add a mention to the delimiters in the result.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1161745116
PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1161756041
PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1161773124
PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1161790058

From rriggs at openjdk.org  Mon Apr 10 15:53:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 10 Apr 2023 15:53:54 GMT
Subject: Integrated: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <cYBk3ZVUnDppbIZGj79ENgNctV4SjMCgrAXF1Jf_Sd8=.150e8aac-3658-4a6e-876c-9c3147847104@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

This pull request has now been integrated.

Changeset: ba90dc77
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba90dc77958c399e4e1fc3c4999dd76680480c7b
Stats:     120 lines in 12 files changed: 20 ins; 50 del; 50 mod

8304911: Use OperatingSystem enum in some modules

Reviewed-by: naoto, lancea, iris, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/13335

From bpb at openjdk.org  Mon Apr 10 16:09:48 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 10 Apr 2023 16:09:48 GMT
Subject: RFR: 8305748: Clarify reentrant behavior of close() in
 FileInputStream, FileOutputStream, and RandomAccessFile [v3]
In-Reply-To: <RraYLzBv8h4DYRPcJWc32nsXMUq-icAEem6XvzIBP-A=.0708429e-61af-4e3e-ae1e-3b96a70f38d0@github.com>
References: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
 <RraYLzBv8h4DYRPcJWc32nsXMUq-icAEem6XvzIBP-A=.0708429e-61af-4e3e-ae1e-3b96a70f38d0@github.com>
Message-ID: <s-lQyhwULKRo_qVf8okAVfy2doXMekloKz8r91e7CqU=.5775f960-a1d1-4e28-8aa3-76bfacbac9e3@github.com>

On Fri, 7 Apr 2023 18:24:42 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> IO stream classes like `FileOutputStream` can have assocated NIO channels.
>> 
>> When `close()` is invoked on one of these classes, it in turn invokes `close()` on the associated channel (if any). But when the associated channel's `close()` method is invoked, it in turn invokes `close()` on the associated stream (if any).
>> 
>> As a result, these IO stream `close()` methods invoke themselves reentrantly when there is an associated channel.
>> 
>> This is not a problem for these classes because they are written to handle this (i.e., they are idempotent), but it can be surprising (or worse, just silently bug-inducing) for subclasses that override `close()`.
>> 
>> There are two possible ways to address this:
>> 1. Modify the code to detect and avoid the (unnecessary) reentrant invocations
>> 2. Add a `@implNote` to the Javadoc so subclass implementers are made aware
>> 
>> This patch takes the second, more conservative approach.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13379#pullrequestreview-1377768106

From duke at openjdk.org  Mon Apr 10 17:08:48 2023
From: duke at openjdk.org (jmehrens)
Date: Mon, 10 Apr 2023 17:08:48 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v3]
In-Reply-To: <LUk2Ieylad6F_XsBE_B03FB2ZVoVE5GB06C3f_l1Vmw=.190f1a30-7b54-44ff-ad94-b3102327aeff@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <RtgJpCzuZjU92WPYpxNfz8KsyPm4ZGMoOp7-Ua4qlFU=.277f86a2-b3d8-40d1-a15f-48083ded05dd@github.com>
 <LUk2Ieylad6F_XsBE_B03FB2ZVoVE5GB06C3f_l1Vmw=.190f1a30-7b54-44ff-ad94-b3102327aeff@github.com>
Message-ID: <iVhiXQ-62bGgYCBcfP_E8MqNvUem_BP4nG-as-8SqUk=.db548dfb-5572-485e-abd5-4b24aa55e65e@github.com>

On Mon, 10 Apr 2023 13:17:39 GMT, jmehrens <duke at openjdk.org> wrote:

>> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use spliterator().estimateSize()
>
> src/java.base/share/classes/java/lang/String.java line 3466:
> 
>> 3464:         }
>> 3465:         int size = 0;
>> 3466:         for (CharSequence cs: elements) {
> 
> I would think you have to locally store the result of `elements.spliterator()` and then use Spliterators::iterator to adapt it back to an iterator.  This should correctly handle [early-binding](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Spliterator.html#binding) spliterators.
> 
> I think in the loop the code should use ArraysSupport.newLength.

That if/else looks like a job for Math.clamp.  Something like:

var si = element.spliterator();
String[] elems = new String[Math.clamp(si.estimateSize(), 8, ArraysSupport.SOFT_MAX_ARRAY_LENGTH)];


Perhaps we need to pad the estimate a little bit to try and avoid one resize:

var si = element.spliterator();
String[] elems = new String[Math.clamp(si.estimateSize() + 8L, 8, ArraysSupport.SOFT_MAX_ARRAY_LENGTH)];

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13383#discussion_r1161902142

From jbhateja at openjdk.org  Mon Apr 10 17:24:54 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 10 Apr 2023 17:24:54 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: <ItNcjfH6t0u6JCJxo9rJM9YDp8I3k4TvnZpdIykXHfs=.0c00585d-5737-4447-b6e6-240804fbc3a1@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
 <o-4GAbPsOv3lW_IFRcx5Ii_rPgIJ7pTH1axmmtd7oaA=.c2c248b1-bd0c-43ff-ba25-fb90be3d98a3@github.com>
 <ItNcjfH6t0u6JCJxo9rJM9YDp8I3k4TvnZpdIykXHfs=.0c00585d-5737-4447-b6e6-240804fbc3a1@github.com>
Message-ID: <t2TRAfgbZcmfs5PwMRr19IUge7-58qheQONK_sbTQ1Q=.26d1193d-5b6e-444b-ac59-0f7889760b73@github.com>

On Fri, 7 Apr 2023 18:04:16 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractShuffle.java line 96:
>> 
>>> 94:         }
>>> 95:         Vector<?> shufvec = this.toBitsVector();
>>> 96:         VectorMask<?> vecmask = shufvec.compare(VectorOperators.LT, 0);
>> 
>> This may impact the intrinsification over AVX1 targets for floating point shuffles. Since bits vector is an integral vector and AVX1 does support 32 byte floats but not 32 byte integral vectors.
>
> Yes I think it is a drawback of this approach, however currently we do not support shuffling for 256-bit vectors on AVX1 machines either, and AVX1 seems to be a special case in this regard. This species of float and double may also be less common in the usage of Vector API since it is larger than SPECIES_PREFERRED.

Hi @merykitty , Agree with you that SPECIES_PREFERRED is preferred for vector algorithms intercepting both integral and floating point vectors.

FTR, we see a perf regression with Float256 based micro now on AVX=1 targets,


  public static short micro() {
     VectorShuffle<Float> iota = FloatVector.SPECIES_256.iotaShuffle(0, 1, true);
     return iota.cast(ShortVector.SPECIES_128).toVector().reinterpretAsShorts().lane(1);
  }

CPROMPT>javad --add-modules=jdk.incubator.vector -XX:UseAVX=1 -XX:+PrintIntrinsics -XX:CompileCommand=compileonly,shufflef::micro -cp . shufflef
CompileCommand: compileonly shufflef.micro bool compileonly = true
  ** not supported: arity=1 op=reinterpret/1 vlen1=8 etype1=int ismask=0
  ** not supported: arity=1 op=cast/1 vlen1=8 etype1=int ismask=0
                                    @ 17   java.lang.Object::getClass (0 bytes)   (intrinsic)
                                    @ 24   java.lang.Object::getClass (0 bytes)   (intrinsic)
                                    @ 45   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   failed to inline (intrinsic)
                                  @ 34   java.lang.Object::getClass (0 bytes)   (intrinsic)
                                  @ 54   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   failed to inline (intrinsic)
                                    @ 17   java.lang.Object::getClass (0 bytes)   (intrinsic)
                                    @ 24   java.lang.Object::getClass (0 bytes)   (intrinsic)
                                    @ 45   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   (intrinsic)
                                      @ 292   java.lang.Object::getClass (0 bytes)   (intrinsic)
                                      @ 298   java.lang.Object::getClass (0 bytes)   (intrinsic)
                                      @ 322   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   (intrinsic)
                                      @ 292   java.lang.Object::getClass (0 bytes)   (intrinsic)
                                      @ 298   java.lang.Object::getClass (0 bytes)   (intrinsic)
                                      @ 322   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   (intrinsic)
                                @ 16   jdk.internal.vm.vector.VectorSupport::extract (35 bytes)   (intrinsic)
[time] 386ms  [res]3392
CPROMPT>export JAVA_HOME=/home/jatinbha/softwares/jdk-20/
CPROMPT>export PATH=$JAVA_HOME/bin:$PATH
CPROMPT>javad --add-modules=jdk.incubator.vector -XX:UseAVX=1 -XX:+PrintIntrinsics -XX:CompileCommand=compileonly,shufflef::micro -cp . shufflef
CompileCommand: compileonly shufflef.micro bool compileonly = true
WARNING: Using incubator modules: jdk.incubator.vector
                                      @ 3   jdk.internal.misc.Unsafe::loadFence (5 bytes)   (intrinsic)
                                        @ 3   jdk.internal.misc.Unsafe::loadFence (5 bytes)   (intrinsic)
                                @ 17   jdk.internal.vm.vector.VectorSupport::shuffleToVector (33 bytes)   (intrinsic)
                                      @ 292   java.lang.Object::getClass (0 bytes)   (intrinsic)
                                      @ 298   java.lang.Object::getClass (0 bytes)   (intrinsic)
                                      @ 322   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   (intrinsic)
                                @ 16   jdk.internal.vm.vector.VectorSupport::extract (35 bytes)   (intrinsic)
[time] 7ms  [res]3392

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1161810585

From duke at openjdk.org  Mon Apr 10 17:40:45 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 10 Apr 2023 17:40:45 GMT
Subject: RFR: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection [v3]
In-Reply-To: <iVhiXQ-62bGgYCBcfP_E8MqNvUem_BP4nG-as-8SqUk=.db548dfb-5572-485e-abd5-4b24aa55e65e@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
 <RtgJpCzuZjU92WPYpxNfz8KsyPm4ZGMoOp7-Ua4qlFU=.277f86a2-b3d8-40d1-a15f-48083ded05dd@github.com>
 <LUk2Ieylad6F_XsBE_B03FB2ZVoVE5GB06C3f_l1Vmw=.190f1a30-7b54-44ff-ad94-b3102327aeff@github.com>
 <iVhiXQ-62bGgYCBcfP_E8MqNvUem_BP4nG-as-8SqUk=.db548dfb-5572-485e-abd5-4b24aa55e65e@github.com>
Message-ID: <6AmAEmaZxGoY0a_PMxuXk3gHkjw310Tucq1Oc0XwyKM=.15dfc7cf-845a-4823-ac18-5d6d446beb4f@github.com>

On Mon, 10 Apr 2023 17:05:28 GMT, jmehrens <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 3466:
>> 
>>> 3464:         }
>>> 3465:         int size = 0;
>>> 3466:         for (CharSequence cs: elements) {
>> 
>> I would think you have to locally store the result of `elements.spliterator()` and then use Spliterators::iterator to adapt it back to an iterator.  This should correctly handle [early-binding](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Spliterator.html#binding) spliterators.
>> 
>> I think in the loop the code should use ArraysSupport.newLength.
>
> That if/else looks like a job for Math.clamp.  Something like:
> 
> var si = element.spliterator();
> String[] elems = new String[Math.clamp(si.estimateSize(), 8, ArraysSupport.SOFT_MAX_ARRAY_LENGTH)];
> 
> 
> Perhaps we need to pad the estimate a little bit to try and avoid one resize:
> 
> var si = element.spliterator();
> String[] elems = new String[Math.clamp(si.estimateSize() + 8L, 8, ArraysSupport.SOFT_MAX_ARRAY_LENGTH)];

Note?that this?also has?to?handle the?case where?`si.estimateSize()` returns?values?close to?`Long.MAX_VALUE`:

final var si = elements.spliterator();
final long est = si.estimateSize();
final int length;

final long MIN_LENGTH = 8;
if ((si.hasCharacteristics() & Spliterator.SIZED) != 0) {
	length = (int) Math.clamp(est, MIN_LENGTH, ArraysSupport.SOFT_MAX_ARRAY_LENGTH);
} else if (est == Long.MAX_VALUE) {
	length = MIN_LENGTH;
} else if (est >= ArraysSupport.SOFT_MAX_ARRAY_LENGTH - MIN_LENGTH) {
	length = ArraysSupport.SOFT_MAX_ARRAY_LENGTH;
} else {
	length = (int) Math.clamp(est + MIN_LENGTH, MIN_LENGTH, ArraysSupport.SOFT_MAX_ARRAY_LENGTH);
}

var elems = new String[length];

int size = 0;
for (final var it = Spliterators.iterator(si); it.hasNext();) {
	CharSequence cs = it.next();

// rest of method...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13383#discussion_r1161920643

From liach at openjdk.org  Mon Apr 10 18:06:13 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Apr 2023 18:06:13 GMT
Subject: RFR: 8305807: Spurious right brace in ConstantDescs field Javadocs
Message-ID: <9cdZUWTMnWOnNroEzR0GvP7Xr0pK9g_QR48wGy6DRIs=.baea10e2-beba-40fc-b6a7-3714babe6b73@github.com>

Please review a small patch, fixing extraneous right braces in field javadocs of BSM_EXPLICIT_CAST, BSM_CLASS_DATA, and BSM_CLASS_DATA_AT.

JDK 20: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/constant/ConstantDescs.html#BSM_EXPLICIT_CAST
JDK 21: https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/constant/ConstantDescs.html#field-summary
With this patch: https://cr.openjdk.org/~liach/8305807/java.base/java/lang/constant/ConstantDescs.html#field-summary

-------------

Commit messages:
 - 8305807: Spurious right brace in ConstantDescs field Javadocs

Changes: https://git.openjdk.org/jdk/pull/13410/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13410&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305807
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13410/head:pull/13410

PR: https://git.openjdk.org/jdk/pull/13410

From stsypanov at openjdk.org  Mon Apr 10 18:07:47 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 10 Apr 2023 18:07:47 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v2]
In-Reply-To: <EnY_awqZn5wCuzEeNF5-Ano7LX--rxUVH4Ycc8Mbzgw=.b26ff0a2-4c4c-48df-af4d-bdcf3f01a4f0@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
 <EnY_awqZn5wCuzEeNF5-Ano7LX--rxUVH4Ycc8Mbzgw=.b26ff0a2-4c4c-48df-af4d-bdcf3f01a4f0@github.com>
Message-ID: <998qY75KRrTd50nagFo5wLqPOZ7Ka1j4vaKuFnd7lUk=.faf5d4d5-6f79-495b-a417-ab5b653c1e18@github.com>

On Mon, 13 Mar 2023 19:24:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into dtfb
>>  - Improve padding of DateTimeFormatter
>
> fyi, you might want to wait for https://github.com/openjdk/jdk/pull/12728

@RogerRiggs mentioned PR was merged without suggested repeat-into-position method, so I this code remains as is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12131#issuecomment-1502128631

From mchung at openjdk.org  Mon Apr 10 18:30:33 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 10 Apr 2023 18:30:33 GMT
Subject: RFR: 8305808: Typo in javadoc of
 ConstantDescs::BSM_VARHANDLE_STATIC_FIELD
Message-ID: <wiTTIxtsh5UlXo9NKBXZwRPtrga_LC-6z-EbZJCxsyw=.c76d6bed-5057-4e60-8b8d-40abe69cee38@github.com>

`s/ConstantBootstraps.staticVarHandle/ConstantBootstraps.staticFieldVarHandle`

-------------

Commit messages:
 - 8305808: Typo in javadoc of ConstantDescs::BSM_VARHANDLE_STATIC_FIELD

Changes: https://git.openjdk.org/jdk/pull/13411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13411&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305808
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13411/head:pull/13411

PR: https://git.openjdk.org/jdk/pull/13411

From rriggs at openjdk.org  Mon Apr 10 18:42:23 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 10 Apr 2023 18:42:23 GMT
Subject: RFR: 8305808: Typo in javadoc of
 ConstantDescs::BSM_VARHANDLE_STATIC_FIELD
In-Reply-To: <wiTTIxtsh5UlXo9NKBXZwRPtrga_LC-6z-EbZJCxsyw=.c76d6bed-5057-4e60-8b8d-40abe69cee38@github.com>
References: <wiTTIxtsh5UlXo9NKBXZwRPtrga_LC-6z-EbZJCxsyw=.c76d6bed-5057-4e60-8b8d-40abe69cee38@github.com>
Message-ID: <cAPDaub9he_M0PZuTyeqAFhigYgpp_I3qzOdd1MOPd4=.b7fffb68-5ed0-4e99-b92e-33d0e99d127e@github.com>

On Mon, 10 Apr 2023 18:24:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `s/ConstantBootstraps.staticVarHandle/ConstantBootstraps.staticFieldVarHandle`

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13411#pullrequestreview-1377951177

From iris at openjdk.org  Mon Apr 10 18:42:23 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 10 Apr 2023 18:42:23 GMT
Subject: RFR: 8305808: Typo in javadoc of
 ConstantDescs::BSM_VARHANDLE_STATIC_FIELD
In-Reply-To: <wiTTIxtsh5UlXo9NKBXZwRPtrga_LC-6z-EbZJCxsyw=.c76d6bed-5057-4e60-8b8d-40abe69cee38@github.com>
References: <wiTTIxtsh5UlXo9NKBXZwRPtrga_LC-6z-EbZJCxsyw=.c76d6bed-5057-4e60-8b8d-40abe69cee38@github.com>
Message-ID: <LxwAp8-Eo0brWZYp99HqFLZEzarHJsZorKD8AF3aYPU=.2bdb3a1c-11e6-4a0c-90f7-90caa1f7b56b@github.com>

On Mon, 10 Apr 2023 18:24:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `s/ConstantBootstraps.staticVarHandle/ConstantBootstraps.staticFieldVarHandle`

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13411#pullrequestreview-1377951955

From qamai at openjdk.org  Mon Apr 10 18:43:25 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 10 Apr 2023 18:43:25 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: <JlC26Wq01TsmgcabNz-1BzpyIyTUzKig2cGetS0D4Ds=.d2d387a4-1b9e-414d-9c3b-81ae9a92f29a@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
 <o-4GAbPsOv3lW_IFRcx5Ii_rPgIJ7pTH1axmmtd7oaA=.c2c248b1-bd0c-43ff-ba25-fb90be3d98a3@github.com>
 <fmI--ihud_n-PgIsWGOcty7kScPkSO1rZltNx4ZB2xA=.82c99f84-ede6-4531-9aa8-cd5212121b40@github.com>
 <buzCSAY9Gr87vBrf6IAEfpVejL33HGEvh0myKAsus6k=.237019ac-ff46-422c-8f37-ed7ceef8b4dc@github.com>
 <JlC26Wq01TsmgcabNz-1BzpyIyTUzKig2cGetS0D4Ds=.d2d387a4-1b9e-414d-9c3b-81ae9a92f29a@github.com>
Message-ID: <JbTASRXbFAfCpO_vf_HM29AYrAUv0JEoZCFr18nPYsw=.a834150b-0e67-4fe7-b2e7-8c01246ca4a9@github.com>

On Mon, 10 Apr 2023 15:11:55 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Thanks a lot for your review, I think that transforming a multiplication by a power of 2 into a shift can be done by the C2 compiler. I have added the special case for `start = 0 && step == 1` since it may be more common and can be optimised away when the arguments are constants.
>
> For x86 byte vector multiplication is done at granularity of short lanes, this case shows regression with power of two multiplications which are strength reduced to shifts currently. please file a follow up bug report for this.

@jatin-bhateja I have created [JDK-8305810](https://bugs.openjdk.org/browse/JDK-8305810)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1161976583

From qamai at openjdk.org  Mon Apr 10 19:05:35 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 10 Apr 2023 19:05:35 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: <t2TRAfgbZcmfs5PwMRr19IUge7-58qheQONK_sbTQ1Q=.26d1193d-5b6e-444b-ac59-0f7889760b73@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
 <o-4GAbPsOv3lW_IFRcx5Ii_rPgIJ7pTH1axmmtd7oaA=.c2c248b1-bd0c-43ff-ba25-fb90be3d98a3@github.com>
 <ItNcjfH6t0u6JCJxo9rJM9YDp8I3k4TvnZpdIykXHfs=.0c00585d-5737-4447-b6e6-240804fbc3a1@github.com>
 <t2TRAfgbZcmfs5PwMRr19IUge7-58qheQONK_sbTQ1Q=.26d1193d-5b6e-444b-ac59-0f7889760b73@github.com>
Message-ID: <TPBkyRqIv0pc97w19ipfIzk2nynGb2z-McZSlBiX76A=.d65d0f2a-2177-420c-b887-18facaac41bf@github.com>

On Mon, 10 Apr 2023 15:16:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Yes I think it is a drawback of this approach, however currently we do not support shuffling for 256-bit vectors on AVX1 machines either, and AVX1 seems to be a special case in this regard. This species of float and double may also be less common in the usage of Vector API since it is larger than SPECIES_PREFERRED.
>
> Hi @merykitty , Agree with you that SPECIES_PREFERRED is preferred for vector algorithms intercepting both integral and floating point vectors.
> 
> FTR, we see a perf regression with Float256 based micro now on AVX=1 targets,
> 
> 
>   public static short micro() {
>      VectorShuffle<Float> iota = FloatVector.SPECIES_256.iotaShuffle(0, 1, true);
>      return iota.cast(ShortVector.SPECIES_128).toVector().reinterpretAsShorts().lane(1);
>   }
> 
> CPROMPT>javad --add-modules=jdk.incubator.vector -XX:UseAVX=1 -XX:+PrintIntrinsics -XX:CompileCommand=compileonly,shufflef::micro -cp . shufflef
> CompileCommand: compileonly shufflef.micro bool compileonly = true
>   ** not supported: arity=1 op=reinterpret/1 vlen1=8 etype1=int ismask=0
>   ** not supported: arity=1 op=cast/1 vlen1=8 etype1=int ismask=0
>                                     @ 17   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                     @ 24   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                     @ 45   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   failed to inline (intrinsic)
>                                   @ 34   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                   @ 54   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   failed to inline (intrinsic)
>                                     @ 17   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                     @ 24   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                     @ 45   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   (intrinsic)
>                                       @ 292   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                       @ 298   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                       @ 322   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   (intrinsic)
>                                       @ 292   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                       @ 298   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                       @ 322   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   (intrinsic)
>                                 @ 16   jdk.internal.vm.vector.VectorSupport::extract (35 bytes)   (intrinsic)
> [time] 386ms  [res]3392
> CPROMPT>export JAVA_HOME=/home/jatinbha/softwares/jdk-20/
> CPROMPT>export PATH=$JAVA_HOME/bin:$PATH
> CPROMPT>javad --add-modules=jdk.incubator.vector -XX:UseAVX=1 -XX:+PrintIntrinsics -XX:CompileCommand=compileonly,shufflef::micro -cp . shufflef
> CompileCommand: compileonly shufflef.micro bool compileonly = true
> WARNING: Using incubator modules: jdk.incubator.vector
>                                       @ 3   jdk.internal.misc.Unsafe::loadFence (5 bytes)   (intrinsic)
>                                         @ 3   jdk.internal.misc.Unsafe::loadFence (5 bytes)   (intrinsic)
>                                 @ 17   jdk.internal.vm.vector.VectorSupport::shuffleToVector (33 bytes)   (intrinsic)
>                                       @ 292   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                       @ 298   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                       @ 322   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   (intrinsic)
>                                 @ 16   jdk.internal.vm.vector.VectorSupport::extract (35 bytes)   (intrinsic)
> [time] 7ms  [res]3392

I see, what do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1161994748

From duke at openjdk.org  Mon Apr 10 20:05:03 2023
From: duke at openjdk.org (iaroslavski)
Date: Mon, 10 Apr 2023 20:05:03 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: <FMsY5pWHqm3nJ3_2okm9nOXRhD6_AewpKwnrgl7txnY=.514ec0a0-2e8a-4f89-a94d-f8a51cc3dde0@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

Laurent is finishing benchmarking.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3938#issuecomment-1502248653

From mchung at openjdk.org  Mon Apr 10 20:53:33 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 10 Apr 2023 20:53:33 GMT
Subject: RFR: 8305807: Spurious right brace in ConstantDescs field Javadocs
In-Reply-To: <9cdZUWTMnWOnNroEzR0GvP7Xr0pK9g_QR48wGy6DRIs=.baea10e2-beba-40fc-b6a7-3714babe6b73@github.com>
References: <9cdZUWTMnWOnNroEzR0GvP7Xr0pK9g_QR48wGy6DRIs=.baea10e2-beba-40fc-b6a7-3714babe6b73@github.com>
Message-ID: <tx1EtTVrrlGkj_avsfKcqPKWahUmkU2fqnehT7DUG0c=.af5ebf31-ab33-4893-9845-eaff0a1af2a2@github.com>

On Mon, 10 Apr 2023 17:58:00 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review a small patch, fixing extraneous right braces in field javadocs of BSM_EXPLICIT_CAST, BSM_CLASS_DATA, and BSM_CLASS_DATA_AT.
> 
> JDK 20: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/constant/ConstantDescs.html#BSM_EXPLICIT_CAST
> JDK 21: https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/constant/ConstantDescs.html#field-summary
> With this patch: https://cr.openjdk.org/~liach/8305807/java.base/java/lang/constant/ConstantDescs.html#field-summary

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13410#pullrequestreview-1378116796

From mchung at openjdk.org  Mon Apr 10 20:53:47 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 10 Apr 2023 20:53:47 GMT
Subject: Integrated: 8305808: Typo in javadoc of
 ConstantDescs::BSM_VARHANDLE_STATIC_FIELD
In-Reply-To: <wiTTIxtsh5UlXo9NKBXZwRPtrga_LC-6z-EbZJCxsyw=.c76d6bed-5057-4e60-8b8d-40abe69cee38@github.com>
References: <wiTTIxtsh5UlXo9NKBXZwRPtrga_LC-6z-EbZJCxsyw=.c76d6bed-5057-4e60-8b8d-40abe69cee38@github.com>
Message-ID: <PlQDE2MLeuonzAoRNlwCJRhlWM97ZVA4HnlNofENe_I=.c20dc508-dfaa-4559-819c-ac6e8656614d@github.com>

On Mon, 10 Apr 2023 18:24:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `s/ConstantBootstraps.staticVarHandle/ConstantBootstraps.staticFieldVarHandle`

This pull request has now been integrated.

Changeset: a43a17c8
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a43a17c8eaa68a7a48ff1b9bebd5e37082e835c0
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8305808: Typo in javadoc of ConstantDescs::BSM_VARHANDLE_STATIC_FIELD

Reviewed-by: rriggs, iris

-------------

PR: https://git.openjdk.org/jdk/pull/13411

From iris at openjdk.org  Mon Apr 10 21:10:33 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 10 Apr 2023 21:10:33 GMT
Subject: RFR: 8305807: Spurious right brace in ConstantDescs field Javadocs
In-Reply-To: <9cdZUWTMnWOnNroEzR0GvP7Xr0pK9g_QR48wGy6DRIs=.baea10e2-beba-40fc-b6a7-3714babe6b73@github.com>
References: <9cdZUWTMnWOnNroEzR0GvP7Xr0pK9g_QR48wGy6DRIs=.baea10e2-beba-40fc-b6a7-3714babe6b73@github.com>
Message-ID: <yXFXafcrvvvG7TB05Rb-oQ_FuOaZXP-GPneVGOtLWtU=.c181f461-babf-4c94-9dc7-f29bb66a00f4@github.com>

On Mon, 10 Apr 2023 17:58:00 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review a small patch, fixing extraneous right braces in field javadocs of BSM_EXPLICIT_CAST, BSM_CLASS_DATA, and BSM_CLASS_DATA_AT.
> 
> JDK 20: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/constant/ConstantDescs.html#BSM_EXPLICIT_CAST
> JDK 21: https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/constant/ConstantDescs.html#field-summary
> With this patch: https://cr.openjdk.org/~liach/8305807/java.base/java/lang/constant/ConstantDescs.html#field-summary

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13410#pullrequestreview-1378137496

From rgiulietti at openjdk.org  Mon Apr 10 21:15:55 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 10 Apr 2023 21:15:55 GMT
Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow
In-Reply-To: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
References: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
Message-ID: <zFNfQPzuU1A3cLN6EIDfynx1FiEYVaWBNc-elp636cE=.5ea5d5a5-eb1d-4401-9507-8c2c4921dbe1@github.com>

On Thu, 7 Jul 2022 15:20:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path.

Keep it open

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9410#issuecomment-1502333299

From asemenyuk at openjdk.org  Mon Apr 10 21:24:34 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 10 Apr 2023 21:24:34 GMT
Subject: RFR: 8294806: jpackaged-app ignores splash screen from jar file
Message-ID: <wstI8OIdLBTRs483WBKg2pmZqkiea6LLZzHCExZr9nI=.73f6f78d-baee-441c-bf0d-72aa645681ef@github.com>

When `--main-jar` is specified and the name of the main class is picked from the jar's manifest, set `app.jarfile` property in launcher cfg file instead of `app.mainclass` and `app.classpath` properties to make app launcher run the app from the jar and not as a class from the classpath.

-------------

Commit messages:
 - 8294806: jpackaged-app ignores splash screen from jar file

Changes: https://git.openjdk.org/jdk/pull/13413/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13413&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294806
  Stats: 96 lines in 4 files changed: 50 ins; 40 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13413.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13413/head:pull/13413

PR: https://git.openjdk.org/jdk/pull/13413

From asemenyuk at openjdk.org  Mon Apr 10 21:24:35 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 10 Apr 2023 21:24:35 GMT
Subject: RFR: 8294806: jpackaged-app ignores splash screen from jar file
In-Reply-To: <wstI8OIdLBTRs483WBKg2pmZqkiea6LLZzHCExZr9nI=.73f6f78d-baee-441c-bf0d-72aa645681ef@github.com>
References: <wstI8OIdLBTRs483WBKg2pmZqkiea6LLZzHCExZr9nI=.73f6f78d-baee-441c-bf0d-72aa645681ef@github.com>
Message-ID: <qKSmfy2jxj11O_nBcVvdvZ2i88vJFDMRcjNAuMvMUh0=.ca270e5e-2b9c-4ef4-87ec-37e000a309d8@github.com>

On Mon, 10 Apr 2023 21:16:19 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> When `--main-jar` is specified and the name of the main class is picked from the jar's manifest, set `app.jarfile` property in launcher cfg file instead of `app.mainclass` and `app.classpath` properties to make app launcher run the app from the jar and not as a class from the classpath.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java line 518:

> 516:                 }
> 517:             }
> 518: 

This duplicates functionality from https://github.com/openjdk/jdk/pull/13413/files#diff-50e3f4f576df4f85d94258043607539f7ec5d55705e7092c00f47432309747a6R210-R218 and hence was deleted

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13413#discussion_r1162096525

From jlu at openjdk.org  Mon Apr 10 21:50:19 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 10 Apr 2023 21:50:19 GMT
Subject: Integrated: 6218123: (cal) API: Spec for GregorianCalendar
 constructors and Calendar getInstance is inconsistent.
In-Reply-To: <Y6sYxUG7fkJL1Lsu4JNIzzbLtwU8BPcm59_QsiURv4o=.1e74a01f-5950-45cc-acec-0217e7fb9094@github.com>
References: <Y6sYxUG7fkJL1Lsu4JNIzzbLtwU8BPcm59_QsiURv4o=.1e74a01f-5950-45cc-acec-0217e7fb9094@github.com>
Message-ID: <wR2ig9yHOXuBEu3pQANdvKZEfqTmC6xCVcfN09IOeAM=.5a363866-fde0-4b58-9908-94677e9867b2@github.com>

On Mon, 3 Apr 2023 21:56:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> The GregorianCalendar constructors and Calendar.getInstance() methods that take TimeZone or Locale throw a NullPointerException if any values are null. 
> 
> This PR updates the javadoc to make this apparent.

This pull request has now been integrated.

Changeset: 42965d39
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42965d390c2062c74e2fb9d8125a16513042e857
Stats:     6 lines in 2 files changed: 6 ins; 0 del; 0 mod

6218123: (cal) API: Spec for GregorianCalendar constructors and Calendar getInstance is inconsistent.

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/13310

From jlu at openjdk.org  Mon Apr 10 21:51:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 10 Apr 2023 21:51:17 GMT
Subject: Integrated: 6241286: (cal) API: Calendar.DAY_OF_WEEK definition is
 wrong
In-Reply-To: <Fe3PdyvyvFi_GNbxowh7Ps4ZhCLcqO2MEmiLD3bddyg=.8e8e6669-6549-49fe-93db-a837427c3515@github.com>
References: <Fe3PdyvyvFi_GNbxowh7Ps4ZhCLcqO2MEmiLD3bddyg=.8e8e6669-6549-49fe-93db-a837427c3515@github.com>
Message-ID: <PdNnYngxU1q2RC83RT8euIYYOJx44ybyzhQkJMG_8wU=.04096e05-81be-4d26-ba2d-a875339ba76c@github.com>

On Mon, 3 Apr 2023 21:56:33 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR updates the Calendar.DAY_OF_WEEK documentation to make it clear that the field accepts _any_ value if the calendar is lenient and then normalizes it. Only if the calendar is non-lenient, will the field accept only one of SUNDAY ... SATURDAY.

This pull request has now been integrated.

Changeset: 2aeb0e52
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2aeb0e5267fc836a06b8ca2e67ec7550bb372163
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

6241286: (cal) API: Calendar.DAY_OF_WEEK definition is wrong

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/13311

From almatvee at openjdk.org  Mon Apr 10 21:56:35 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 10 Apr 2023 21:56:35 GMT
Subject: RFR: 8294806: jpackaged-app ignores splash screen from jar file
In-Reply-To: <wstI8OIdLBTRs483WBKg2pmZqkiea6LLZzHCExZr9nI=.73f6f78d-baee-441c-bf0d-72aa645681ef@github.com>
References: <wstI8OIdLBTRs483WBKg2pmZqkiea6LLZzHCExZr9nI=.73f6f78d-baee-441c-bf0d-72aa645681ef@github.com>
Message-ID: <56g19JFNU1TBRUbpMD2tlrVQjrdrLWiavN48wgGiaHw=.a1046562-e157-4052-8831-b90515ec7a6f@github.com>

On Mon, 10 Apr 2023 21:16:19 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> When `--main-jar` is specified and the name of the main class is picked from the jar's manifest, set `app.jarfile` property in launcher cfg file instead of `app.mainclass` and `app.classpath` properties to make app launcher run the app from the jar and not as a class from the classpath.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13413#pullrequestreview-1378179729

From liach at openjdk.org  Mon Apr 10 22:57:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Apr 2023 22:57:42 GMT
Subject: Integrated: 8305807: Spurious right brace in ConstantDescs field
 Javadocs
In-Reply-To: <9cdZUWTMnWOnNroEzR0GvP7Xr0pK9g_QR48wGy6DRIs=.baea10e2-beba-40fc-b6a7-3714babe6b73@github.com>
References: <9cdZUWTMnWOnNroEzR0GvP7Xr0pK9g_QR48wGy6DRIs=.baea10e2-beba-40fc-b6a7-3714babe6b73@github.com>
Message-ID: <o31U4Z7cvyjf2OE3NlM7FsvgDV1MR2ZM5-resj23alA=.3f3a9490-77ec-451e-b1fd-895e2683f91a@github.com>

On Mon, 10 Apr 2023 17:58:00 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review a small patch, fixing extraneous right braces in field javadocs of BSM_EXPLICIT_CAST, BSM_CLASS_DATA, and BSM_CLASS_DATA_AT.
> 
> JDK 20: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/constant/ConstantDescs.html#BSM_EXPLICIT_CAST
> JDK 21: https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/constant/ConstantDescs.html#field-summary
> With this patch: https://cr.openjdk.org/~liach/8305807/java.base/java/lang/constant/ConstantDescs.html#field-summary

This pull request has now been integrated.

Changeset: 0ff2ff67
Author:    Chen Liang <liach at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ff2ff6789a73bd72e0b9c9584ae7650d2001ee9
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8305807: Spurious right brace in ConstantDescs field Javadocs

Reviewed-by: mchung, iris

-------------

PR: https://git.openjdk.org/jdk/pull/13410

From smarks at openjdk.org  Tue Apr 11 01:22:42 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 11 Apr 2023 01:22:42 GMT
Subject: RFR: JDK-8170945: Collectors$Partition should override more Map
 methods
In-Reply-To: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
References: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
Message-ID: <8kcRG7woyhFVTdZEgHtKJl6SDvxLwh7NCxhFz3eFxYU=.10bd9f1a-605f-4992-9c98-3a14914c067e@github.com>

On Wed, 5 Apr 2023 09:19:57 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Adds overrides for common Map operations to avoid having to allocate the entrySet for Collectors$Partition maps.

I don't think there is any useful relationship between this work at SequencedCollections / SequencedMap. The return type of this collector is simply `Map<...>` so the type information won't be visible and the new methods won't be visible either.

It would be useful to examine actual code to see how this is used. SourceGraph to the rescue:

https://sourcegraph.com/search?q=context%3Aglobal+lang%3Ajava+Collectors.partitioningBy&patternType=standard&sm=1&groupBy=repo

I looked at most of the results on the first page of hits, probably about 20-30 or so. Almost every single one was followed by a `map.get(true)` or `map.get(false)`, sometimes immediately, sometimes later in the method, or sometimes in a caller which accepted the partition map as a return value. (The only exception was Google Error Prone, which iterated over the map's keys not using its `keySet()` but using a for-each loop over `ImmutableList.of(false, true)` or `ImmutableList.of(true, false)` and then getting the value, which seemed kind of ... overkill to me.)

Anyway what this tells me is that `get()` is the most important thing to optimize, and filling out things like the various Map views is probably wasted effort.

As an aside, it's interesting to look at how code uses `partitioningBy`. For example, I saw some graph algorithm that was processing edges based on whether the edge was incoming or outgoing. The code looked something like this:

    Map<Boolean, List<Edge>> partitionedEdges = edges.stream()....collect(partitioningBy(Edge::isOutgoing));
    for (var edge : partitionedEdges.get(Boolean.TRUE)) { // outgoing edges
        ... many lines of code ...
    }
    ... many lines of code ...
    for (var edge : partitionedEdges.get(Boolean.FALSE)) { // incoming edges
        ...
    }

(I note that lots of code used `Boolean.TRUE` and `Boolean.FALSE`, presumably to avoid boxing overhead, which is small, because it doesn't allocate anything, but which is a method call instead of a field load.)

Anyway though my conclusion is that having a boolean map is a lousy way to represent the return value. If you have a map, which elements are under true and which are false, if there's no obvious correlation between true/false and the property you're partitioning by, such as incoming/outgoing? Maybe you'd want something like this:

    enum Direction { INCOMING, OUTGOING }

and then you could do a `groupingBy` to get a `Map<Direction, List<Edge>>` but dealing with a map is still kind of clunky.

Maybe what you want is a record instead!

    record EdgesByDirection(List<Edge> incoming, List<Edge> outgoing) { }

OK, enough digression. If anybody is going to put effort in this area, I think it would be better to explore alternative directions such as the above instead of optimizing the "map" that's returned by the `partitioningBy` collector.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13347#issuecomment-1502548705

From dholmes at openjdk.org  Tue Apr 11 03:15:35 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Apr 2023 03:15:35 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v4]
In-Reply-To: <V1mOqqIoiev_kAYV0lyDKLJ2NaxTA-EzY_DiJkI8hig=.1eeea2af-a281-499e-88bb-2beff4262bc2@github.com>
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 <V1mOqqIoiev_kAYV0lyDKLJ2NaxTA-EzY_DiJkI8hig=.1eeea2af-a281-499e-88bb-2beff4262bc2@github.com>
Message-ID: <XMIZ0dYXJOHdI8dybaoy0CKj7LLPHsQjJ9MEQlBc6wQ=.5cc3a8b1-de19-4e8c-9e6d-beb14a75bf1a@github.com>

On Sat, 8 Apr 2023 13:26:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Legacy Boolean to jboolean conversion

Okay. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13139#pullrequestreview-1378388160

From alanb at openjdk.org  Tue Apr 11 05:53:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Apr 2023 05:53:57 GMT
Subject: Integrated: 8304919: Implementation of Virtual Threads
In-Reply-To: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
Message-ID: <uTOLVBeYQYLH3ADIhPbGi0pTitI8vXxA7lAI6VpfNtw=.0863cec1-d11c-4f6d-b6b2-18a47191440a@github.com>

On Tue, 28 Mar 2023 07:28:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
> 
> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
> 
> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
> 
> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
> - ThreadPerTaskExecutor is changed to use FutureTask.
> 
> Testing: tier1-6.

This pull request has now been integrated.

Changeset: 2586f361
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2586f36120317cd206464b1e79d3906f711487cb
Stats:     2275 lines in 206 files changed: 903 ins; 866 del; 506 mod

8304919: Implementation of Virtual Threads

Reviewed-by: lmesnik, cjplummer, psandoz, mchung, sspitsyn, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/13203

From jwaters at openjdk.org  Tue Apr 11 06:52:39 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 11 Apr 2023 06:52:39 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v4]
In-Reply-To: <V1mOqqIoiev_kAYV0lyDKLJ2NaxTA-EzY_DiJkI8hig=.1eeea2af-a281-499e-88bb-2beff4262bc2@github.com>
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 <V1mOqqIoiev_kAYV0lyDKLJ2NaxTA-EzY_DiJkI8hig=.1eeea2af-a281-499e-88bb-2beff4262bc2@github.com>
Message-ID: <-QKehWzWY91LzYWZRQsCO7I-HU7ewzlPBA-c5KvJ7R4=.28f57c31-48fb-463f-8c44-e89e8dcae043@github.com>

On Sat, 8 Apr 2023 13:26:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Legacy Boolean to jboolean conversion

Thanks David!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13139#issuecomment-1502770584

From jwaters at openjdk.org  Tue Apr 11 06:55:46 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 11 Apr 2023 06:55:46 GMT
Subject: Integrated: 8304717: Declaration aliasing between boolean and jboolean
 is wrong
In-Reply-To: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
Message-ID: <HgFrHGYAyOYxww4rbZuP2nFrbMMzlerRb3WY9_hReTQ=.dfd79bd1-d29f-4e73-af8b-40b56cbcc00b@github.com>

On Wed, 22 Mar 2023 14:02:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched

This pull request has now been integrated.

Changeset: cd7d53c8
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd7d53c88c27eedbe16020b88c2219708d170a1e
Stats:     7 lines in 3 files changed: 0 ins; 0 del; 7 mod

8304717: Declaration aliasing between boolean and jboolean is wrong

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/13139

From bmarwell at apache.org  Tue Apr 11 06:59:43 2023
From: bmarwell at apache.org (Benjamin Marwell)
Date: Tue, 11 Apr 2023 08:59:43 +0200
Subject: RFE: SequenceInputStream - Consider new issue for PR #11718
In-Reply-To: <CAKZnr+xnAfrCkuGjyMDnPfLWG8BNXtT03Yi7HfVDdgY3k3-iTw@mail.gmail.com>
References: <CAKZnr+xnAfrCkuGjyMDnPfLWG8BNXtT03Yi7HfVDdgY3k3-iTw@mail.gmail.com>
Message-ID: <CAKZnr+z6utmZwMA7OZPOTOkL2RUWC=VLJq0sYYPBdXAAgqGFOg@mail.gmail.com>

Follow up, I would highly appreciate it if anyone would be so kind as
to open an issue for this enhancement.

Am Sa., 8. Apr. 2023 um 17:36 Uhr schrieb Benjamin Marwell
<bmarwell at apache.org>:
>
> Dear Core-Devs,
>
> There was a PR created for an enhancement of SequenceInputStream [1]
> by Romain Manni-Buceau.
>
> Description by Romain:
>
> > 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)
>
> As the both of us do not have access to the OpenJDK bug tracker,
> kindly open an issue for this PR if you agree with this
> enhancement/PR.
>
> [1]: https://github.com/openjdk/jdk/pull/11718

From duke at openjdk.org  Tue Apr 11 08:47:34 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 11 Apr 2023 08:47:34 GMT
Subject: RFR: JDK-8170945: Collectors$Partition should override more Map
 methods
In-Reply-To: <8kcRG7woyhFVTdZEgHtKJl6SDvxLwh7NCxhFz3eFxYU=.10bd9f1a-605f-4992-9c98-3a14914c067e@github.com>
References: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
 <8kcRG7woyhFVTdZEgHtKJl6SDvxLwh7NCxhFz3eFxYU=.10bd9f1a-605f-4992-9c98-3a14914c067e@github.com>
Message-ID: <KMESiu1lcZUyzJZjBZpcIpFW-LhZiGV9h_jxgTqVxVw=.ff160c72-988a-4214-88e3-fb22f53be67d@github.com>

On Tue, 11 Apr 2023 01:18:53 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Adds overrides for common Map operations to avoid having to allocate the entrySet for Collectors$Partition maps.
>
> I don't think there is any useful relationship between this work at SequencedCollections / SequencedMap. The return type of this collector is simply `Map<...>` so the type information won't be visible and the new methods won't be visible either.
> 
> It would be useful to examine actual code to see how this is used. SourceGraph to the rescue:
> 
> https://sourcegraph.com/search?q=context%3Aglobal+lang%3Ajava+Collectors.partitioningBy&patternType=standard&sm=1&groupBy=repo
> 
> I looked at most of the results on the first page of hits, probably about 20-30 or so. Almost every single one was followed by a `map.get(true)` or `map.get(false)`, sometimes immediately, sometimes later in the method, or sometimes in a caller which accepted the partition map as a return value. (The only exception was Google Error Prone, which iterated over the map's keys not using its `keySet()` but using a for-each loop over `ImmutableList.of(false, true)` or `ImmutableList.of(true, false)` and then getting the value, which seemed kind of ... overkill to me.)
> 
> Anyway what this tells me is that `get()` is the most important thing to optimize, and filling out things like the various Map views is probably wasted effort.
> 
> As an aside, it's interesting to look at how code uses `partitioningBy`. For example, I saw some graph algorithm that was processing edges based on whether the edge was incoming or outgoing. The code looked something like this:
> 
>     Map<Boolean, List<Edge>> partitionedEdges = edges.stream()....collect(partitioningBy(Edge::isOutgoing));
>     for (var edge : partitionedEdges.get(Boolean.TRUE)) { // outgoing edges
>         ... many lines of code ...
>     }
>     ... many lines of code ...
>     for (var edge : partitionedEdges.get(Boolean.FALSE)) { // incoming edges
>         ...
>     }
> 
> (I note that lots of code used `Boolean.TRUE` and `Boolean.FALSE`, presumably to avoid boxing overhead, which is small, because it doesn't allocate anything, but which is a method call instead of a field load.)
> 
> Anyway though my conclusion is that having a boolean map is a lousy way to represent the return value. If you have a map, which elements are under true and which are false, if there's no obvious correlation between true/false and the property you're partitioning by, such as incoming/outgoing? Maybe you'd want something like this:
> 
>     enum Direction { INCOMING, OUTGOING }
> 
> and then you could do a `groupingBy` to get a `Map<Direction, List<Edge>>` but dealing with a map is still kind of clunky.
> 
> Maybe what you want is a record instead!
> 
>     record EdgesByDirection(List<Edge> incoming, List<Edge> outgoing) { }
> 
> OK, enough digression. If anybody is going to put effort in this area, I think it would be better to explore alternative directions such as the above instead of optimizing the "map" that's returned by the `partitioningBy` collector.
> 
> --
> 
> For this change, I'd definitely keep the `get` override. You have to override `entrySet` because it's abstract in `AbstractMap`, so something like this would work:
> 
>     return Set.of(Map.entry(false, forFalse), Map.entry(true, forTrue));
> 
> I'm not sure it's worth overriding even `size` and `isEmpty`; those just get delegated to the `entrySet` anyway (so there is some creation overhead) but nobody seems to use them anyway.

@stuart-marks Yes, it would perhaps make more sense to have a dedicated structure to represent the return value. But as you say, it'd be a different issue altogether. I'll leave it at the proposed changes and hope we can integrate this. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13347#issuecomment-1502924810

From rgiulietti at openjdk.org  Tue Apr 11 08:53:38 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 11 Apr 2023 08:53:38 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v2]
In-Reply-To: <OQI29CEXN1M-5u_8Y7SLcxMC-SEO3OwOoeL-gunFNlE=.2b59085c-72ba-4a11-852f-57528a390819@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <dg6qtk5ave9VNr7E0Jf7nHBB9OgkJdJq-A_17OsP094=.1113df8d-50f7-4baa-a8e8-8aef1ee61ac0@github.com>
 <OQI29CEXN1M-5u_8Y7SLcxMC-SEO3OwOoeL-gunFNlE=.2b59085c-72ba-4a11-852f-57528a390819@github.com>
Message-ID: <n0jDmeSPpLsJYL8DAtebnif-3msgB0c0OFIJGUVWuVk=.9f94e71e-a798-43f9-a8d7-cec81c66eec5@github.com>

On Mon, 10 Apr 2023 14:00:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8305486: Add split() variants that keep the delimiters to String and j.u.r.Pattern
>>   Restored original JavaDoc to existing methods.
>>   Replaced proposed parametrized split(*, boolean) methods with suggested splitWithDelimiters(*) variants.
>>   Adjusted tests accordingly.
>
> src/java.base/share/classes/java/lang/String.java line 3237:
> 
>> 3235:      * the array are in the order in which they occur in this string.  If the
>> 3236:      * expression does not match any part of the input then the resulting array
>> 3237:      * has just one element, namely this string.
> 
> This paragraph duplicates part of the next paragraph.

Right, removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1162498928

From rgiulietti at openjdk.org  Tue Apr 11 08:57:35 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 11 Apr 2023 08:57:35 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v2]
In-Reply-To: <OQI29CEXN1M-5u_8Y7SLcxMC-SEO3OwOoeL-gunFNlE=.2b59085c-72ba-4a11-852f-57528a390819@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <dg6qtk5ave9VNr7E0Jf7nHBB9OgkJdJq-A_17OsP094=.1113df8d-50f7-4baa-a8e8-8aef1ee61ac0@github.com>
 <OQI29CEXN1M-5u_8Y7SLcxMC-SEO3OwOoeL-gunFNlE=.2b59085c-72ba-4a11-852f-57528a390819@github.com>
Message-ID: <B-GMTcADURp1TQC7wyVZIqFsb8nu7CjO3t4-DC96Y9w=.a9e89b48-efe2-4e21-a491-6d48f6754868@github.com>

On Mon, 10 Apr 2023 14:14:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8305486: Add split() variants that keep the delimiters to String and j.u.r.Pattern
>>   Restored original JavaDoc to existing methods.
>>   Replaced proposed parametrized split(*, boolean) methods with suggested splitWithDelimiters(*) variants.
>>   Adjusted tests accordingly.
>
> src/java.base/share/classes/java/lang/String.java line 3253:
> 
>> 3251:      * string then an empty leading substring is included at the beginning
>> 3252:      * of the resulting array. A zero-width match at the beginning however
>> 3253:      * never produces such empty leading substring.
> 
> Is there any case in which it is ambiguous whether the first element is a string or delimiter?
> I'm not sure what patterns could be zero-width.  But perhaps, a regex such as "^|\s", where one of the patterns could be zero-width and the other is non-zero width?
> That could make the API hard to use.

A zero-width match at the beginning is preceded by an empty (sub)string, so neither the empty string nor the empty delimiter are put in the resulting array. That is, even-indexed array elements are strings, odd-indexed elements are delimiters.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1162503798

From rgiulietti at openjdk.org  Tue Apr 11 09:05:45 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 11 Apr 2023 09:05:45 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v3]
In-Reply-To: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
Message-ID: <k9nyCn7Ui196hPb9xapxEVeJfsP-uixSD9-hJeshHAA=.288dbc91-588a-428a-abe2-5b9cdb0b3f33@github.com>

> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8305486: Add split() variants that keep the delimiters to String and j.u.r.Pattern
  Removed duplicate paragraph in Javadoc
  Clarified that the returned array also includes the delimiters

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13305/files
  - new: https://git.openjdk.org/jdk/pull/13305/files/597ee0ce..0cb84a40

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13305&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13305&range=01-02

  Stats: 11 lines in 2 files changed: 2 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13305.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13305/head:pull/13305

PR: https://git.openjdk.org/jdk/pull/13305

From rgiulietti at openjdk.org  Tue Apr 11 09:05:50 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 11 Apr 2023 09:05:50 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v2]
In-Reply-To: <OQI29CEXN1M-5u_8Y7SLcxMC-SEO3OwOoeL-gunFNlE=.2b59085c-72ba-4a11-852f-57528a390819@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <dg6qtk5ave9VNr7E0Jf7nHBB9OgkJdJq-A_17OsP094=.1113df8d-50f7-4baa-a8e8-8aef1ee61ac0@github.com>
 <OQI29CEXN1M-5u_8Y7SLcxMC-SEO3OwOoeL-gunFNlE=.2b59085c-72ba-4a11-852f-57528a390819@github.com>
Message-ID: <lwI-yTh0L8dp1xIim6Qkg7xxQaOcWDAKq7qWdUm9NXQ=.a092f238-071c-40e1-8732-5b16ee0f88c3@github.com>

On Mon, 10 Apr 2023 14:35:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8305486: Add split() variants that keep the delimiters to String and j.u.r.Pattern
>>   Restored original JavaDoc to existing methods.
>>   Replaced proposed parametrized split(*, boolean) methods with suggested splitWithDelimiters(*) variants.
>>   Adjusted tests accordingly.
>
> src/java.base/share/classes/java/lang/String.java line 3302:
> 
>> 3300:      * <tr><!-- o -->
>> 3301:      *     <th scope="row" style="font-weight:normal; text-align:right; padding-right:1em">0</th>
>> 3302:      *     <td>{@code { "b", "o", "", "o", ":::and::f", "o", "", "o" }}</td></tr>
> 
> These cases might be a bit easier to understand if the regex matched characters that looked more like delimiters, perhaps just ":".

The choice of multi-character delimiter is deliberate, to show that the regex really absorbs all the delimiter characters.
The `":+"` examples are followed by the `"o"` examples, where the delimiters are single characters.

> src/java.base/share/classes/java/lang/String.java line 3324:
> 
>> 3322:      *         the result threshold, as described above
>> 3323:      *
>> 3324:      * @return  the array of strings computed by splitting this string
> 
> Add a mention to the delimiters in the result.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1162508256
PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1162508479

From rgiulietti at openjdk.org  Tue Apr 11 09:14:29 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 11 Apr 2023 09:14:29 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v4]
In-Reply-To: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
Message-ID: <J2bOKs8y9SxolEuGLmooVtr5Bque2h_TAQzJ05IB2yc=.a2c7f620-643d-4172-99b7-fa22c9f0d45d@github.com>

> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8305486: Add split() variants that keep the delimiters to String and j.u.r.Patten
  Clarification about zero-width matches at the beginning of the input

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13305/files
  - new: https://git.openjdk.org/jdk/pull/13305/files/0cb84a40..178cb645

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13305&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13305&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13305.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13305/head:pull/13305

PR: https://git.openjdk.org/jdk/pull/13305

From qamai at openjdk.org  Tue Apr 11 09:38:50 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 11 Apr 2023 09:38:50 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: <t2TRAfgbZcmfs5PwMRr19IUge7-58qheQONK_sbTQ1Q=.26d1193d-5b6e-444b-ac59-0f7889760b73@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
 <o-4GAbPsOv3lW_IFRcx5Ii_rPgIJ7pTH1axmmtd7oaA=.c2c248b1-bd0c-43ff-ba25-fb90be3d98a3@github.com>
 <ItNcjfH6t0u6JCJxo9rJM9YDp8I3k4TvnZpdIykXHfs=.0c00585d-5737-4447-b6e6-240804fbc3a1@github.com>
 <t2TRAfgbZcmfs5PwMRr19IUge7-58qheQONK_sbTQ1Q=.26d1193d-5b6e-444b-ac59-0f7889760b73@github.com>
Message-ID: <Hez3RvVjBUtA0F2Uhqjuai5gXX4uA-ZeRLTE3aqXZE8=.f2be38b5-2791-49a3-9cfc-85ab2b47bb2c@github.com>

On Mon, 10 Apr 2023 15:16:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Yes I think it is a drawback of this approach, however currently we do not support shuffling for 256-bit vectors on AVX1 machines either, and AVX1 seems to be a special case in this regard. This species of float and double may also be less common in the usage of Vector API since it is larger than SPECIES_PREFERRED.
>
> Hi @merykitty , Agree with you that SPECIES_PREFERRED is preferred for vector algorithms intercepting both integral and floating point vectors.
> 
> FTR, we see a perf regression with Float256 based micro now on AVX=1 targets,
> 
> 
>   public static short micro() {
>      VectorShuffle<Float> iota = FloatVector.SPECIES_256.iotaShuffle(0, 1, true);
>      return iota.cast(ShortVector.SPECIES_128).toVector().reinterpretAsShorts().lane(1);
>   }
> 
> CPROMPT>javad --add-modules=jdk.incubator.vector -XX:UseAVX=1 -XX:+PrintIntrinsics -XX:CompileCommand=compileonly,shufflef::micro -cp . shufflef
> CompileCommand: compileonly shufflef.micro bool compileonly = true
>   ** not supported: arity=1 op=reinterpret/1 vlen1=8 etype1=int ismask=0
>   ** not supported: arity=1 op=cast/1 vlen1=8 etype1=int ismask=0
>                                     @ 17   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                     @ 24   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                     @ 45   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   failed to inline (intrinsic)
>                                   @ 34   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                   @ 54   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   failed to inline (intrinsic)
>                                     @ 17   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                     @ 24   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                     @ 45   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   (intrinsic)
>                                       @ 292   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                       @ 298   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                       @ 322   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   (intrinsic)
>                                       @ 292   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                       @ 298   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                       @ 322   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   (intrinsic)
>                                 @ 16   jdk.internal.vm.vector.VectorSupport::extract (35 bytes)   (intrinsic)
> [time] 386ms  [res]3392
> CPROMPT>export JAVA_HOME=/home/jatinbha/softwares/jdk-20/
> CPROMPT>export PATH=$JAVA_HOME/bin:$PATH
> CPROMPT>javad --add-modules=jdk.incubator.vector -XX:UseAVX=1 -XX:+PrintIntrinsics -XX:CompileCommand=compileonly,shufflef::micro -cp . shufflef
> CompileCommand: compileonly shufflef.micro bool compileonly = true
> WARNING: Using incubator modules: jdk.incubator.vector
>                                       @ 3   jdk.internal.misc.Unsafe::loadFence (5 bytes)   (intrinsic)
>                                         @ 3   jdk.internal.misc.Unsafe::loadFence (5 bytes)   (intrinsic)
>                                 @ 17   jdk.internal.vm.vector.VectorSupport::shuffleToVector (33 bytes)   (intrinsic)
>                                       @ 292   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                       @ 298   java.lang.Object::getClass (0 bytes)   (intrinsic)
>                                       @ 322   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   (intrinsic)
>                                 @ 16   jdk.internal.vm.vector.VectorSupport::extract (35 bytes)   (intrinsic)
> [time] 7ms  [res]3392

@jatin-bhateja Since `Float256Shuffle` is represented as a 256-bit int vector, which is not supported by AVX1, the compiled code falls back to Java implementation, which explains the regression. However, having a `VectorShuffle` but not for `Vector::rearrange` is not really useful, and the code snippet is similar to `ShortVector.SPECIES_128.iotaShuffle(0, 1, true).toVector().reinterpretAsShorts().lane(1)`. As a result, I think having some regressions in edge cases of AVX1 is acceptable in contrast with the improvement in all other operations on all platforms.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1162555106

From mdoerr at openjdk.org  Tue Apr 11 10:18:44 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 11 Apr 2023 10:18:44 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
Message-ID: <CCDPqtT_cmyHiC5NunYWKPHOe_frC2YuyQT8fyCdjbA=.f4490dd6-261b-4e80-8bb7-c6f8df76f22f@github.com>

On Sat, 8 Apr 2023 18:00:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused static and import of Stabile

Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too.

test/jdk/jdk/internal/util/ArchTest.java line 128:

> 126:             case RISCV64 -> true;
> 127:             case S390 -> false;
> 128:             case PPC64 -> true;

This is not always true. The PPC64 architecture supports both endianness versions. AIX and legacy linux is Big Endian while recent linux is little Endian (determined by platform name "os.arch = ppc64le" instead of "os.arch = ppc64"). Querying the endianness is also possible, of course.

-------------

Changes requested by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1378905956
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162600674

From duke at openjdk.org  Tue Apr 11 10:29:43 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 11 Apr 2023 10:29:43 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <CCDPqtT_cmyHiC5NunYWKPHOe_frC2YuyQT8fyCdjbA=.f4490dd6-261b-4e80-8bb7-c6f8df76f22f@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
 <CCDPqtT_cmyHiC5NunYWKPHOe_frC2YuyQT8fyCdjbA=.f4490dd6-261b-4e80-8bb7-c6f8df76f22f@github.com>
Message-ID: <RAe8ARnMbOWvkONRQ-EcnumPphnKYKuQ_X35Irfgi5E=.d1e942b4-9680-45fa-beec-459247768624@github.com>

On Tue, 11 Apr 2023 10:15:27 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused static and import of Stabile
>
> test/jdk/jdk/internal/util/ArchTest.java line 128:
> 
>> 126:             case RISCV64 -> true;
>> 127:             case S390 -> false;
>> 128:             case PPC64 -> true;
> 
> This is not always true. The PPC64 architecture supports both endianness versions. AIX and legacy linux is Big Endian while recent linux is little Endian (determined by platform name "os.arch = ppc64le" instead of "os.arch = ppc64"). Querying the endianness is also possible, of course.

This?should (probably) be?correct:
Suggestion:

            case PPC64 -> !OperatingSystem.isAix() && Architecture.isLittleEndian();

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162614588

From mdoerr at openjdk.org  Tue Apr 11 10:42:41 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 11 Apr 2023 10:42:41 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <RAe8ARnMbOWvkONRQ-EcnumPphnKYKuQ_X35Irfgi5E=.d1e942b4-9680-45fa-beec-459247768624@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
 <CCDPqtT_cmyHiC5NunYWKPHOe_frC2YuyQT8fyCdjbA=.f4490dd6-261b-4e80-8bb7-c6f8df76f22f@github.com>
 <RAe8ARnMbOWvkONRQ-EcnumPphnKYKuQ_X35Irfgi5E=.d1e942b4-9680-45fa-beec-459247768624@github.com>
Message-ID: <iyzzD01nOt0xHtg15c6H8wl4mJT54weHKb1yKtZFosc=.0c155c27-8cee-4d80-850a-0f32c4ac209d@github.com>

On Tue, 11 Apr 2023 10:26:02 GMT, ExE Boss <duke at openjdk.org> wrote:

>> test/jdk/jdk/internal/util/ArchTest.java line 128:
>> 
>>> 126:             case RISCV64 -> true;
>>> 127:             case S390 -> false;
>>> 128:             case PPC64 -> true;
>> 
>> This is not always true. The PPC64 architecture supports both endianness versions. AIX and legacy linux is Big Endian while recent linux is little Endian (determined by platform name "os.arch = ppc64le" instead of "os.arch = ppc64"). Querying the endianness is also possible, of course.
>
> This?should (probably) be?correct:
> Suggestion:
> 
>             case PPC64 -> !OperatingSystem.isAix() && Architecture.isLittleEndian();

Looks correct, but makes the test pointless for any linux on PPC64.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162628828

From duke at openjdk.org  Tue Apr 11 11:53:42 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 11 Apr 2023 11:53:42 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
Message-ID: <TmkOpylJOmfV6CpwyF8BsuKjp58iqjv2mjDJROpjHHw=.393f6ba9-eecc-4adf-9f4e-b5abb7aaa8a5@github.com>

On Sat, 8 Apr 2023 18:00:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused static and import of Stabile

src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 68:

> 66:     // The variables are named to match the Architecture value names, and
> 67:     // the values are named to match the build variables.
> 68:     static final boolean TARGET_ARCH_IS_X64         = "@@OPENJDK_TARGET_CPU@@" == "x86_64";

Would it be better to rename the enum entry to `X86_64`? I personally prefer the name x86-64 because I feel it is more regular than x64..

src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 82:

> 80:     private static Architecture initArch(String archName) {
> 81:         try {
> 82:             String mapped = switch (archName) {

How about mapping names in the build script instead of at runtime?

I suggest placing only the mapped arch name in `PlatformProps` and moving the `CURRENT_ARCH` to `Architecture`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162686875
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162695586

From liach at openjdk.org  Tue Apr 11 11:59:37 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Apr 2023 11:59:37 GMT
Subject: RFR: 8284871: Use covariant overrides for the
 resolveConstantDesc(Lookup) method in =?UTF-8?B?c3Vi4oCRaW50ZXJmYWNlcw==?= of
 java.lang.constant.ConstantDesc [v4]
In-Reply-To: <DY2phRiG3uDRbfToXvZfSjzy_jyBg1wUE4BSYQQAJNQ=.8774ae82-7d81-40d4-8666-c273bb9cbec8@github.com>
References: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
 <DY2phRiG3uDRbfToXvZfSjzy_jyBg1wUE4BSYQQAJNQ=.8774ae82-7d81-40d4-8666-c273bb9cbec8@github.com>
Message-ID: <trBXFIohvQArBUsGzVhtpuxG9iORyMy_WLR1-YHdRd4=.7f564028-06a7-4bfa-ac78-4aae149a9f3f@github.com>

On Wed, 5 Apr 2023 05:14:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also remove redundant casts to avoid javac warnings.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Redundant casts in benchmark

Keep alive. Would any committer sponsor this patch, simplifying usage of certain overrides of ConstantDesc.resolveConstantDesc?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12986#issuecomment-1503191638

From anhmdq at gmail.com  Tue Apr 11 13:01:56 2023
From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=)
Date: Tue, 11 Apr 2023 21:01:56 +0800
Subject: Add String & Character ASCII case conversion methods
In-Reply-To: <CAJL5A3=N+Mwv0uAa2w=rF2XW2SLVpZeUv_nPrZ=vK1Ek9yF3vA@mail.gmail.com>
References: <5c703745f0ba484c9d66b9666a1218a7@vodafonemail.de>
 <CAJL5A3=N+Mwv0uAa2w=rF2XW2SLVpZeUv_nPrZ=vK1Ek9yF3vA@mail.gmail.com>
Message-ID: <CAPvyiy+cHhBryE4re7aKzFqj2tOkHW=EzvDiDLvfvMq5tven2g@mail.gmail.com>

Hi,

To propose deprecation of String::toLowerCase() and String::toUpperCase(),
you can create a patch as normal, with an addition of a CSR ticket that
describes the situation and the proposed solution. After that, you can ask
for someone from core-libs to review the ticket. The change can be merged
after sufficient reviews and the CSR being approved. You can view
other CSRs in JBS to see the overall structure, as well as other
deprecations in the JDK to see a typical deprecation description. More
details regarding CSRs can be found in the OpenJDK Wiki
<https://wiki.openjdk.org/display/csr/Main>.

Hope this helps,
Quan Anh

On Mon, 10 Apr 2023 at 00:47, Glavo <zjx001202 at gmail.com> wrote:

> Hi,
>
> We discussed this issue on this mailing list[1] earlier this year.
>
> I investigated the usage of these two methods and found that all use cases
> within
> JDK are suspicious, resulting in many imperceptible bugs.
>
> I hope to create a PR for this issue, deprecate these two methods, and
> create
> alternative methods for them. But I don't have the experience of making
> such
> changes, maybe I need some guidance or have more experienced people do
> these things.
>
> Glavo
>
> [1]
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html
>
> On Sun, Apr 9, 2023 at 10:58?PM <
> some-java-user-99206970363698485155 at vodafonemail.de> wrote:
>
>> Hello,
>> could you please add String & Character ASCII case conversion methods,
>> that is, methods which only perform case conversion on ASCII characters in
>> the input and leave any other characters unchanged. The conversion should
>> not depend on the default locale. For example:
>> - String:
>>   - toAsciiLowerCase
>>   - toAsciiUpperCase
>>   - equalsAsciiIgnoreCase (or a better name)
>>   - compareToAsciiIgnoreCase (or a better name)
>> - Character:
>>   - toAsciiLowerCase
>>   - toAsciiUpperCase
>>
>> This would give the following advantages:
>> - Increased performance (+ not be vulnerable to denial of service attacks)
>> - Reduced number of bugs in applications
>>
>>
>> Please read on for a detailed explanation.
>>
>> I assume for historic reasons (Applets) the current case conversion
>> methods use the Unicode conversion rules, and even worse
>> String.toLowerCase() and String.toUpperCase() use the default locale. While
>> this might back then have been a reasonable choice because Applets ran
>> locally in the browser and localization was a nice to have feature (or even
>> a requirement), nowadays Java is largely used for back-end systems and case
>> conversion is pretty often done for technical strings and not display text
>> anymore. In this context applications mostly process ASCII strings.
>> However, because Java does not offer any specific case conversion methods
>> for these cases, users still use the standard String & Character methods.
>> This causes the following problems [1]:
>>
>> - String.toLowerCase() & String.toUpperCase() using default locale
>>   What this means is that depending on the OS locale your application
>> might behave differently or fail [2]. For the scale of this, simply look in
>> the OpenJDK database: https://bugs.openjdk.org/issues/?jql=text ~
>> "turkish locale"
>>   At this point you probably have to add a disclaimer to any Java program
>> that running it on systems with Turkish (and possibly others) as locale is
>> not supported, because either your own code or the libraries you are using
>> might be calling toLowerCase() or toUpperCase() [3].
>>
>> - Bad performance for Unicode aware case conversions
>>   Compared to simply performing ASCII case conversion, applying Unicode
>> case conversion has worse performance. In some cases it can even have
>> extremely bad performance (JDK-8292573). This could have security
>> implications.
>>
>> - Bugs due to case conversion changing string length
>>   Unicode case conversion for certain strings can change the length,
>> either increasing or decreasing the size of the string (or when combining
>> both, shifting position of characters in the string while keeping the
>> length the same). If an application assumes that the length of the string
>> remains the same and uses data derived from the original string (e.g.
>> character indices or length) on the converted string this can lead to
>> exceptions or potentially even security issues.
>>
>> - Unicode characters mapping to ASCII chars
>>   When performing case conversion on certain non-ASCII Unicode
>> characters, the results are ASCII characters. For example
>> `Character.toLowerCase('\u212A') == 'k'`. This could have security
>> implications.
>>
>> - Update to Unicode data changing application behavior
>>   Unicode evolves over time, and the JDK regularly updates the Unicode
>> data it is using. Even if an application is not affected by the issues
>> mentioned above, it could become affected by them when the Unicode data is
>> updated in a newer JDK version.
>>
>> My main point here is that (I assume) in many cases Java applications
>> don't need Unicode case conversion, let alone Unicode case conversion using
>> the default locale. If Java offered ASCII-only case conversion methods,
>> then hopefully users would (where applicable) switch to these methods over
>> time and avoid all the issues mentioned above. And even if they
>> accidentally use the ASCII-only methods for display text, the result might
>> be a minor inconvenience for users seeing the display text, compared to in
>> the other cases application bugs and security vulnerabilities.
>>
>> Related information about other programming languages:
>> - Rust: Has dedicated methods for ASCII case conversion, e.g.
>> https://doc.rust-lang.org/std/string/struct.String.html#method.to_ascii_lowercase
>> - Kotlin: Functions which implicitly use the default locale were
>> deprecated, see https://youtrack.jetbrains.com/issue/KT-43023
>>
>> Risks:
>> - ASCII case conversion could lead to undesired results in some cases,
>> see the example for the word "caf?" on
>> https://doc.rust-lang.org/std/ascii/trait.AsciiExt.html (though that
>> specific example is about a display string, for which these ASCII-only
>> methods are not intended)
>> - When applications start to mix ASCII-only and the existing Unicode
>> conversion methods this could lead to bugs and security issues as well;
>> though it might also indicate a flaw in the application if it performs case
>> conversion on the same value in different places
>>
>> I hope you consider this suggestion. Feedback is appreciated!
>>
>> Kind regards
>>
>> ----
>>
>> [1] I am not saying though that Java is the only affected language, it
>> definitely affects others as well. But that should not prevent improving
>> the Java API.
>> [2] Tool for detecting usage of such methods:
>> https://github.com/policeman-tools/forbidden-apis
>> [3] Maybe it would also be worth discussing deprecating
>> String.toLowerCase() and String.toUpperCase() because they seem to do more
>> harm than good.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230411/bddad5c2/attachment.htm>

From liach at openjdk.org  Tue Apr 11 13:44:44 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Apr 2023 13:44:44 GMT
Subject: Integrated: 8284871: Use covariant overrides for the
 resolveConstantDesc(Lookup) method in =?UTF-8?B?c3Vi4oCRaW50ZXJmYWNlcw==?= of
 java.lang.constant.ConstantDesc
In-Reply-To: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
References: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
Message-ID: <BBcZhzLv4BCJKNNJdxDRwU5iJPaq30gpTO2AVjFTSGM=.8c632d08-cc90-46b4-bcc8-4221cf806913@github.com>

On Sat, 11 Mar 2023 04:59:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> Also remove redundant casts to avoid javac warnings.

This pull request has now been integrated.

Changeset: e5ce7d9e
Author:    Chen Liang <liach at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e5ce7d9e431e54504ddcf321711fe8996ce5ed05
Stats:     103 lines in 15 files changed: 18 ins; 1 del; 84 mod

8284871: Use covariant overrides for the resolveConstantDesc(Lookup) method in sub?interfaces of java.lang.constant.ConstantDesc

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/12986

From weijun at openjdk.org  Tue Apr 11 13:48:36 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 11 Apr 2023 13:48:36 GMT
Subject: RFR: 8305846: Support compilation in Proc test utility
Message-ID: <tJkYNJm75DjmNugz1RxFHkkFSN6NgMBTr7IqQ3Jz8ls=.7afeae60-6738-404d-ae99-a9d7edcfdf0a@github.com>

Enhance the `Proc` utility to support compilation.

-------------

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/13425/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13425&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305846
  Stats: 139 lines in 4 files changed: 121 ins; 8 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13425/head:pull/13425

PR: https://git.openjdk.org/jdk/pull/13425

From brian.burkhalter at oracle.com  Tue Apr 11 16:06:07 2023
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 11 Apr 2023 16:06:07 +0000
Subject: RFE: SequenceInputStream - Consider new issue for PR #11718
In-Reply-To: <CAKZnr+z6utmZwMA7OZPOTOkL2RUWC=VLJq0sYYPBdXAAgqGFOg@mail.gmail.com>
References: <CAKZnr+xnAfrCkuGjyMDnPfLWG8BNXtT03Yi7HfVDdgY3k3-iTw@mail.gmail.com>
 <CAKZnr+z6utmZwMA7OZPOTOkL2RUWC=VLJq0sYYPBdXAAgqGFOg@mail.gmail.com>
Message-ID: <00CEFB76-6D73-41A0-95BB-48F771B9EE1E@oracle.com>

Hello,

You should be able to file an issue yourself at

https://bugreport.java.com/bugreport/start_form

Brian

On Apr 10, 2023, at 11:59 PM, Benjamin Marwell <bmarwell at apache.org<mailto:bmarwell at apache.org>> wrote:

Follow up, I would highly appreciate it if anyone would be so kind as
to open an issue for this enhancement.

Am Sa., 8. Apr. 2023 um 17:36 Uhr schrieb Benjamin Marwell
<bmarwell at apache.org<mailto:bmarwell at apache.org>>:

Dear Core-Devs,

There was a PR created for an enhancement of SequenceInputStream [1]
by Romain Manni-Buceau.

Description by Romain:

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)

As the both of us do not have access to the OpenJDK bug tracker,
kindly open an issue for this PR if you agree with this
enhancement/PR.

[1]: https://github.com/openjdk/jdk/pull/11718

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230411/3f7310f8/attachment.htm>

From asemenyuk at openjdk.org  Tue Apr 11 16:19:45 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 11 Apr 2023 16:19:45 GMT
Subject: Integrated: 8294806: jpackaged-app ignores splash screen from jar file
In-Reply-To: <wstI8OIdLBTRs483WBKg2pmZqkiea6LLZzHCExZr9nI=.73f6f78d-baee-441c-bf0d-72aa645681ef@github.com>
References: <wstI8OIdLBTRs483WBKg2pmZqkiea6LLZzHCExZr9nI=.73f6f78d-baee-441c-bf0d-72aa645681ef@github.com>
Message-ID: <e0SzbR0poEeGQKlLk4G0gscpRy2PvF-ySyeLYOs7eO8=.f69ce1ff-db65-4624-aa72-4c8c2289be21@github.com>

On Mon, 10 Apr 2023 21:16:19 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> When `--main-jar` is specified and the name of the main class is picked from the jar's manifest, set `app.jarfile` property in launcher cfg file instead of `app.mainclass` and `app.classpath` properties to make app launcher run the app from the jar and not as a class from the classpath.

This pull request has now been integrated.

Changeset: 1de772cd
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1de772cd899b535f04380088ee82badc325865be
Stats:     96 lines in 4 files changed: 50 ins; 40 del; 6 mod

8294806: jpackaged-app ignores splash screen from jar file

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/13413

From rriggs at openjdk.org  Tue Apr 11 17:00:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 17:00:51 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <TmkOpylJOmfV6CpwyF8BsuKjp58iqjv2mjDJROpjHHw=.393f6ba9-eecc-4adf-9f4e-b5abb7aaa8a5@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
 <TmkOpylJOmfV6CpwyF8BsuKjp58iqjv2mjDJROpjHHw=.393f6ba9-eecc-4adf-9f4e-b5abb7aaa8a5@github.com>
Message-ID: <zVFAPrR8Iq7X2oD8vVoQ3qb97HybmQTnB3kl6EYXMYw=.937e1d6a-7ce4-4d70-94ff-a1ab36c9adb0@github.com>

On Tue, 11 Apr 2023 11:41:24 GMT, Glavo <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused static and import of Stabile
>
> src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 68:
> 
>> 66:     // The variables are named to match the Architecture value names, and
>> 67:     // the values are named to match the build variables.
>> 68:     static final boolean TARGET_ARCH_IS_X64         = "@@OPENJDK_TARGET_CPU@@" == "x86_64";
> 
> Would it be better to rename the enum entry to `X86_64`? I personally prefer the name x86-64 because I feel it is more regular than x64..

> Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too.

Changing os.arch is out of scope for this PR.
The best way for that would someone supporting ppc to develop and propose a PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163098619

From rriggs at openjdk.org  Tue Apr 11 17:14:41 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 17:14:41 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <iyzzD01nOt0xHtg15c6H8wl4mJT54weHKb1yKtZFosc=.0c155c27-8cee-4d80-850a-0f32c4ac209d@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
 <CCDPqtT_cmyHiC5NunYWKPHOe_frC2YuyQT8fyCdjbA=.f4490dd6-261b-4e80-8bb7-c6f8df76f22f@github.com>
 <RAe8ARnMbOWvkONRQ-EcnumPphnKYKuQ_X35Irfgi5E=.d1e942b4-9680-45fa-beec-459247768624@github.com>
 <iyzzD01nOt0xHtg15c6H8wl4mJT54weHKb1yKtZFosc=.0c155c27-8cee-4d80-850a-0f32c4ac209d@github.com>
Message-ID: <0k8KcVp6piijYrt4MpxXyZzVIM_00uf_Zetj14jTBww=.c09aec26-1e32-4e0d-bf2c-8324b1c47a44@github.com>

On Tue, 11 Apr 2023 10:39:39 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This?should (probably) be?correct:
>> Suggestion:
>> 
>>             case PPC64 -> !OperatingSystem.isAix() && Architecture.isLittleEndian();
>
> Looks correct, but makes the test pointless for any linux on PPC64.

Will change to compare `isLittleEndian` with `!Unsafe.isBigEndian()`.
The runtime must match the build time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163112421

From smarks at openjdk.org  Tue Apr 11 17:24:35 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 11 Apr 2023 17:24:35 GMT
Subject: RFR: JDK-8170945: Collectors$Partition should override more Map
 methods
In-Reply-To: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
References: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
Message-ID: <arzvwSUlgRH3t_Hbnz5YQWK7Kp2bww6ffOiasTFpOw4=.c8ddc7d9-7564-418c-8df9-cf137d0d410b@github.com>

On Wed, 5 Apr 2023 09:19:57 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Adds overrides for common Map operations to avoid having to allocate the entrySet for Collectors$Partition maps.

OK, the change is probably good, including removal of the `booleanValue` call. I'm not sure `containsKey` and `containsValue` are worth it, but they're just one-liners. The `entrySet` method could be simplified, but at a cost of a small change in behavior, maybe not worth fiddling with given the low usage. The main benefit here is `get` (contrary to some suggestions I had made six years ago in the bug report).

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13347#pullrequestreview-1379762188

From jbhateja at openjdk.org  Tue Apr 11 17:50:45 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 11 Apr 2023 17:50:45 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v7]
In-Reply-To: <PAuphp5Wv4xJIe8z3jCYNCHdPqP7yhbk4WX7SRnsst0=.58751569-e28b-4a68-9d49-5bebe56d7881@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <PAuphp5Wv4xJIe8z3jCYNCHdPqP7yhbk4WX7SRnsst0=.58751569-e28b-4a68-9d49-5bebe56d7881@github.com>
Message-ID: <SYw0eLmgUE2Z0v3EI0GLBhKj7t5IMoDgiz1c_c4rEEM=.c3e918d0-bb75-4caa-ada0-56eac49d702a@github.com>

On Fri, 7 Apr 2023 17:13:50 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   special case iotaShuffle

Marked as reviewed by jbhateja (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13093#pullrequestreview-1379800113

From jbhateja at openjdk.org  Tue Apr 11 17:50:48 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 11 Apr 2023 17:50:48 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: <Hez3RvVjBUtA0F2Uhqjuai5gXX4uA-ZeRLTE3aqXZE8=.f2be38b5-2791-49a3-9cfc-85ab2b47bb2c@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>
 <o-4GAbPsOv3lW_IFRcx5Ii_rPgIJ7pTH1axmmtd7oaA=.c2c248b1-bd0c-43ff-ba25-fb90be3d98a3@github.com>
 <ItNcjfH6t0u6JCJxo9rJM9YDp8I3k4TvnZpdIykXHfs=.0c00585d-5737-4447-b6e6-240804fbc3a1@github.com>
 <t2TRAfgbZcmfs5PwMRr19IUge7-58qheQONK_sbTQ1Q=.26d1193d-5b6e-444b-ac59-0f7889760b73@github.com>
 <Hez3RvVjBUtA0F2Uhqjuai5gXX4uA-ZeRLTE3aqXZE8=.f2be38b5-2791-49a3-9cfc-85ab2b47bb2c@github.com>
Message-ID: <92ZNVJBTNzBNw4reI-1HMd5nvWlNdz_-0wfvGvGe5nk=.e601910e-8c04-48f4-a604-cd14e7b75ee0@github.com>

On Tue, 11 Apr 2023 09:36:06 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi @merykitty , Agree with you that SPECIES_PREFERRED is preferred for vector algorithms intercepting both integral and floating point vectors.
>> 
>> FTR, we see a perf regression with Float256 based micro now on AVX=1 targets,
>> 
>> 
>>   public static short micro() {
>>      VectorShuffle<Float> iota = FloatVector.SPECIES_256.iotaShuffle(0, 1, true);
>>      return iota.cast(ShortVector.SPECIES_128).toVector().reinterpretAsShorts().lane(1);
>>   }
>> 
>> CPROMPT>javad --add-modules=jdk.incubator.vector -XX:UseAVX=1 -XX:+PrintIntrinsics -XX:CompileCommand=compileonly,shufflef::micro -cp . shufflef
>> CompileCommand: compileonly shufflef.micro bool compileonly = true
>>   ** not supported: arity=1 op=reinterpret/1 vlen1=8 etype1=int ismask=0
>>   ** not supported: arity=1 op=cast/1 vlen1=8 etype1=int ismask=0
>>                                     @ 17   java.lang.Object::getClass (0 bytes)   (intrinsic)
>>                                     @ 24   java.lang.Object::getClass (0 bytes)   (intrinsic)
>>                                     @ 45   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   failed to inline (intrinsic)
>>                                   @ 34   java.lang.Object::getClass (0 bytes)   (intrinsic)
>>                                   @ 54   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   failed to inline (intrinsic)
>>                                     @ 17   java.lang.Object::getClass (0 bytes)   (intrinsic)
>>                                     @ 24   java.lang.Object::getClass (0 bytes)   (intrinsic)
>>                                     @ 45   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   (intrinsic)
>>                                       @ 292   java.lang.Object::getClass (0 bytes)   (intrinsic)
>>                                       @ 298   java.lang.Object::getClass (0 bytes)   (intrinsic)
>>                                       @ 322   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   (intrinsic)
>>                                       @ 292   java.lang.Object::getClass (0 bytes)   (intrinsic)
>>                                       @ 298   java.lang.Object::getClass (0 bytes)   (intrinsic)
>>                                       @ 322   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   (intrinsic)
>>                                 @ 16   jdk.internal.vm.vector.VectorSupport::extract (35 bytes)   (intrinsic)
>> [time] 386ms  [res]3392
>> CPROMPT>export JAVA_HOME=/home/jatinbha/softwares/jdk-20/
>> CPROMPT>export PATH=$JAVA_HOME/bin:$PATH
>> CPROMPT>javad --add-modules=jdk.incubator.vector -XX:UseAVX=1 -XX:+PrintIntrinsics -XX:CompileCommand=compileonly,shufflef::micro -cp . shufflef
>> CompileCommand: compileonly shufflef.micro bool compileonly = true
>> WARNING: Using incubator modules: jdk.incubator.vector
>>                                       @ 3   jdk.internal.misc.Unsafe::loadFence (5 bytes)   (intrinsic)
>>                                         @ 3   jdk.internal.misc.Unsafe::loadFence (5 bytes)   (intrinsic)
>>                                 @ 17   jdk.internal.vm.vector.VectorSupport::shuffleToVector (33 bytes)   (intrinsic)
>>                                       @ 292   java.lang.Object::getClass (0 bytes)   (intrinsic)
>>                                       @ 298   java.lang.Object::getClass (0 bytes)   (intrinsic)
>>                                       @ 322   jdk.internal.vm.vector.VectorSupport::convert (36 bytes)   (intrinsic)
>>                                 @ 16   jdk.internal.vm.vector.VectorSupport::extract (35 bytes)   (intrinsic)
>> [time] 7ms  [res]3392
>
> @jatin-bhateja Since `Float256Shuffle` is represented as a 256-bit int vector, which is not supported by AVX1, the compiled code falls back to Java implementation, which explains the regression. However, having a `VectorShuffle` but not for `Vector::rearrange` is not really useful, and the code snippet is similar to `ShortVector.SPECIES_128.iotaShuffle(0, 1, true).toVector().reinterpretAsShorts().lane(1)`. As a result, I think having some regressions in edge cases of AVX1 is acceptable in contrast with the improvement in all other operations on all platforms.

Agree, this is also fixing less than 32 bit shuffle vectors case, i.e. shuffles involving Long128, Int64 and Float64 will get benefitted on x86.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1163147535

From jvernee at openjdk.org  Tue Apr 11 17:51:45 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 11 Apr 2023 17:51:45 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v20]
In-Reply-To: <zxEBDsj3-07V4u3Exryupcrs_9mcT14cJ96TOIxWXc8=.07d9f518-7e1f-4ad7-89e0-84b0bf52ed2e@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <zxEBDsj3-07V4u3Exryupcrs_9mcT14cJ96TOIxWXc8=.07d9f518-7e1f-4ad7-89e0-84b0bf52ed2e@github.com>
Message-ID: <lG1fJR2wrtGcsxOlydOvSq6QvgzatSiY7qT1cqkkX-k=.b9d3aeef-c90c-470d-96fd-405d5dbdf3c6@github.com>

On Thu, 6 Apr 2023 10:54:18 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8305369: Issues in zero-length memory segment javadoc section
>  - 8305087: MemoryLayout API checks should be more eager

test/jdk/java/foreign/TestByteBuffer.java line 317:

> 315: 
> 316:     @Test
> 317:     public void testMappedSegmentAsByteBuffer() throws Throwable {

While testing something else, I noticed that this test is failing on Linux/WSL since the WSL 1 kernel does not implement `mincore`. We can simply skip the test in that case, as we already do for other tests. I've submitted a patch here: https://github.com/minborg/jdk/pull/2

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1163148467

From rriggs at openjdk.org  Tue Apr 11 17:58:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 17:58:54 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v10]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <i2siBlNCDjWM4dMLLyPL0c8SFGFTODNdJpKTBIxhJy4=.a9b40975-0efd-49b3-b81b-dbc67c58edbb@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Modified test to check Architecture is64bits() and isLittleEndian()
  against Unsafe respective values.
  Relocated code mapping OS name and arch name from PlatformProps to
  OperatingSystem and Architecture. Kept the mapping of names
  in the template close to where the values are filled in by the build.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/f3646dc9..fc40270a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=08-09

  Stats: 105 lines in 4 files changed: 46 ins; 41 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

PR: https://git.openjdk.org/jdk/pull/13357

From mdoerr at openjdk.org  Tue Apr 11 18:04:49 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 11 Apr 2023 18:04:49 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v10]
In-Reply-To: <i2siBlNCDjWM4dMLLyPL0c8SFGFTODNdJpKTBIxhJy4=.a9b40975-0efd-49b3-b81b-dbc67c58edbb@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <i2siBlNCDjWM4dMLLyPL0c8SFGFTODNdJpKTBIxhJy4=.a9b40975-0efd-49b3-b81b-dbc67c58edbb@github.com>
Message-ID: <XR6XJ8_PlbaCZwAza-qUVbXKrbA0MGgAuZAjS-x-7DA=.db23097f-f88a-4ebf-9985-124eb2b48af3@github.com>

On Tue, 11 Apr 2023 17:58:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified test to check Architecture is64bits() and isLittleEndian()
>   against Unsafe respective values.
>   Relocated code mapping OS name and arch name from PlatformProps to
>   OperatingSystem and Architecture. Kept the mapping of names
>   in the template close to where the values are filled in by the build.

test/jdk/jdk/internal/util/ArchTest.java line 74:

> 72:             case "riscv64" -> RISCV64;  // unverified
> 73:             case "s390x", "s390" -> S390;  // unverified
> 74:             case "ppc64le" -> PPC64;  // unverified

I think "ppc64" should also get mapped to "PPC64".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163161387

From vlivanov at openjdk.org  Tue Apr 11 18:03:50 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 11 Apr 2023 18:03:50 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v20]
In-Reply-To: <zxEBDsj3-07V4u3Exryupcrs_9mcT14cJ96TOIxWXc8=.07d9f518-7e1f-4ad7-89e0-84b0bf52ed2e@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <zxEBDsj3-07V4u3Exryupcrs_9mcT14cJ96TOIxWXc8=.07d9f518-7e1f-4ad7-89e0-84b0bf52ed2e@github.com>
Message-ID: <pDBuUHAi0dohRotzcgIRG1DafzyO85pqu2sGrFkL_Nw=.8b02b998-b013-495f-a6a6-2d0247fb667e@github.com>

On Thu, 6 Apr 2023 10:54:18 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8305369: Issues in zero-length memory segment javadoc section
>  - 8305087: MemoryLayout API checks should be more eager

Hotspot changes look good.

src/hotspot/share/prims/jvm.cpp line 3473:

> 3471: 
> 3472: JVM_LEAF(jboolean, JVM_IsForeignLinkerSupported(void))
> 3473:   return ForeignGlobals::has_port() ? JNI_TRUE : JNI_FALSE;

On naming:  I find `has_port()` confusing. Why don't you simply call VM counterpart `is_foreign_linker_supported`? Alternative ideas: `is_supported()`, `has_native_support()`.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13079#pullrequestreview-1379816547
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1163158810

From mdoerr at openjdk.org  Tue Apr 11 18:11:42 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 11 Apr 2023 18:11:42 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v10]
In-Reply-To: <i2siBlNCDjWM4dMLLyPL0c8SFGFTODNdJpKTBIxhJy4=.a9b40975-0efd-49b3-b81b-dbc67c58edbb@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <i2siBlNCDjWM4dMLLyPL0c8SFGFTODNdJpKTBIxhJy4=.a9b40975-0efd-49b3-b81b-dbc67c58edbb@github.com>
Message-ID: <mBvcRGaKW5CD2m2iTgeBXJ9S-xkgwdFdkgx5fkCNoVI=.0e483496-7ce0-45e9-9a3c-af79c0c20b95@github.com>

On Tue, 11 Apr 2023 17:58:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified test to check Architecture is64bits() and isLittleEndian()
>   against Unsafe respective values.
>   Relocated code mapping OS name and arch name from PlatformProps to
>   OperatingSystem and Architecture. Kept the mapping of names
>   in the template close to where the values are filled in by the build.

Another remark: Old JDK on s390 used "os.arch = zArch_64", current one "os.arch = s390x". @offamitkumar: You probably want to take a look.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1503861585

From duke at openjdk.org  Tue Apr 11 18:11:45 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 11 Apr 2023 18:11:45 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v10]
In-Reply-To: <XR6XJ8_PlbaCZwAza-qUVbXKrbA0MGgAuZAjS-x-7DA=.db23097f-f88a-4ebf-9985-124eb2b48af3@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <i2siBlNCDjWM4dMLLyPL0c8SFGFTODNdJpKTBIxhJy4=.a9b40975-0efd-49b3-b81b-dbc67c58edbb@github.com>
 <XR6XJ8_PlbaCZwAza-qUVbXKrbA0MGgAuZAjS-x-7DA=.db23097f-f88a-4ebf-9985-124eb2b48af3@github.com>
Message-ID: <fqHaub4apueeoOZAjM1K8NsVUm8YvGvDPtDcUFaLObc=.67df51b2-a2e6-4075-9ebb-c6dac5557be4@github.com>

On Tue, 11 Apr 2023 18:02:14 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modified test to check Architecture is64bits() and isLittleEndian()
>>   against Unsafe respective values.
>>   Relocated code mapping OS name and arch name from PlatformProps to
>>   OperatingSystem and Architecture. Kept the mapping of names
>>   in the template close to where the values are filled in by the build.
>
> test/jdk/jdk/internal/util/ArchTest.java line 74:
> 
>> 72:             case "riscv64" -> RISCV64;  // unverified
>> 73:             case "s390x", "s390" -> S390;  // unverified
>> 74:             case "ppc64le" -> PPC64;  // unverified
> 
> I think "ppc64" should also get mapped to "PPC64".

Suggestion:

            case "ppc64", "ppc64le" -> PPC64;  // unverified

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163166827

From jjg at openjdk.org  Tue Apr 11 18:21:56 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 11 Apr 2023 18:21:56 GMT
Subject: RFR: JDK-8305713: DocCommentParser: merge blockContent and
 inlineContent
Message-ID: <UE7CaXR_PLguWd3vHzG5kUeeo1L5_hpQUSY8AVsj0k4=.d67291fa-a1af-4d87-86a7-e2473abdcc49@github.com>

Please review a cleanup in DocCommentParser to merge blockContent and inlineContent into a single method to parse "rich content" in a doc comment.

-------------

Depends on: https://git.openjdk.org/jdk/pull/13362

Commit messages:
 - JDK-8305713: DocCommentParser: merge blockContent and inlineContent
 - 8272119: Typo in JDK documentation (a -> an)
 - 8305461: [vectorapi] Add VectorMask::xor
 - 8305608: Change VMConnection to use "test.class.path"instead of "test.classes"
 - 8274166: Some CDS tests ignore -Dtest.cds.runtime.options
 - 8304745: Lazily initialize byte[] in java.io.BufferedInputStream
 - 8267140: Support closing the HttpClient by making it auto-closable
 - 8269843: typo in LinkedHashMap::removeEldestEntry spec
 - 8305480: test/hotspot/jtreg/runtime/NMT/VirtualAllocCommitMerge.java failing on 32 bit arm
 - 8305607: Remove some unused test parameters in com/sun/jdi tests
 - ... and 6 more: https://git.openjdk.org/jdk/compare/44f33ad1...b8b43eae

Changes: https://git.openjdk.org/jdk/pull/13431/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13431&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305713
  Stats: 5934 lines in 119 files changed: 5071 ins; 480 del; 383 mod
  Patch: https://git.openjdk.org/jdk/pull/13431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13431/head:pull/13431

PR: https://git.openjdk.org/jdk/pull/13431

From jjg at openjdk.org  Tue Apr 11 18:35:12 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 11 Apr 2023 18:35:12 GMT
Subject: RFR: JDK-8305713: DocCommentParser: merge blockContent and
 inlineContent [v2]
In-Reply-To: <UE7CaXR_PLguWd3vHzG5kUeeo1L5_hpQUSY8AVsj0k4=.d67291fa-a1af-4d87-86a7-e2473abdcc49@github.com>
References: <UE7CaXR_PLguWd3vHzG5kUeeo1L5_hpQUSY8AVsj0k4=.d67291fa-a1af-4d87-86a7-e2473abdcc49@github.com>
Message-ID: <m4FKFQc83YnYk50tr42KC2uCVa1Mx6ohf16CAoYkP0U=.6c3c7753-cc46-4ac3-a304-fb3c4abeab0e@github.com>

> Please review a cleanup in DocCommentParser to merge blockContent and inlineContent into a single method to parse "rich content" in a doc comment.

Jonathan Gibbons has updated the pull request incrementally with 42 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8305713.dcp-content
 - 8305809: (fs) Review obsolete Linux kernel dependency on os.version (Unix kernel 2.6.39)
   
   Reviewed-by: rriggs, alanb
 - 8294806: jpackaged-app ignores splash screen from jar file
   
   Reviewed-by: almatvee
 - 8305368: G1 remset chunk claiming may use relaxed memory ordering
   
   Reviewed-by: ayang, iwalulya
 - 8305370: Inconsistent use of for_young_only_phase parameter in G1 predictions
   
   Reviewed-by: iwalulya, kbarrett
 - 8305663: Wrong iteration order of pause array in g1MMUTracker
   
   Reviewed-by: ayang, tschatzl
 - 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries
   
   Reviewed-by: alanb, kevinw
 - 8305419: JDK-8301995 broke building libgraal
   
   Reviewed-by: matsaave, dnsimon, thartmann
 - 8302696: Revert API signature changes made in JDK-8285504 and JDK-8285263
   
   Reviewed-by: mullan
 - 8304738: UnregisteredClassesTable_lock never created
   
   Reviewed-by: iklam, jcking, dholmes
 - ... and 32 more: https://git.openjdk.org/jdk/compare/b8b43eae...ab56c463

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13431/files
  - new: https://git.openjdk.org/jdk/pull/13431/files/b8b43eae..ab56c463

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13431&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13431&range=00-01

  Stats: 9487 lines in 384 files changed: 2654 ins; 5914 del; 919 mod
  Patch: https://git.openjdk.org/jdk/pull/13431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13431/head:pull/13431

PR: https://git.openjdk.org/jdk/pull/13431

From rriggs at openjdk.org  Tue Apr 11 18:35:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 18:35:56 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v11]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <Df_fXzkh2mDAUGTXbMDqTa_2mVwm_T0DThx1JKvEmVk=.ae3f9b07-2c07-4582-885c-a6163ebe996e@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Add ppc64 as mapping to PPC64 Architecture

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/fc40270a..1c0c0220

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

PR: https://git.openjdk.org/jdk/pull/13357

From duke at openjdk.org  Tue Apr 11 18:39:41 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 11 Apr 2023 18:39:41 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <zVFAPrR8Iq7X2oD8vVoQ3qb97HybmQTnB3kl6EYXMYw=.937e1d6a-7ce4-4d70-94ff-a1ab36c9adb0@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
 <TmkOpylJOmfV6CpwyF8BsuKjp58iqjv2mjDJROpjHHw=.393f6ba9-eecc-4adf-9f4e-b5abb7aaa8a5@github.com>
 <zVFAPrR8Iq7X2oD8vVoQ3qb97HybmQTnB3kl6EYXMYw=.937e1d6a-7ce4-4d70-94ff-a1ab36c9adb0@github.com>
Message-ID: <FrhXODydplyZNBZ5bdGY_VGNcfKtCjGcsWj0TepHZPA=.1351c357-4154-4f4a-a140-61699d71b0b9@github.com>

On Tue, 11 Apr 2023 16:58:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> > Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too.
> 
> Changing os.arch is out of scope for this PR. The best way for that would someone supporting ppc to develop and propose a PR.

It seems that you replied in the wrong place.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163192614

From jjg at openjdk.org  Tue Apr 11 18:39:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 11 Apr 2023 18:39:53 GMT
Subject: RFR: JDK-8305713: DocCommentParser: merge blockContent and
 inlineContent [v3]
In-Reply-To: <UE7CaXR_PLguWd3vHzG5kUeeo1L5_hpQUSY8AVsj0k4=.d67291fa-a1af-4d87-86a7-e2473abdcc49@github.com>
References: <UE7CaXR_PLguWd3vHzG5kUeeo1L5_hpQUSY8AVsj0k4=.d67291fa-a1af-4d87-86a7-e2473abdcc49@github.com>
Message-ID: <jr7O3o6GmhaZ6OcVVF0l9qrkBHGju4UC-60To5CDahE=.52854f35-c016-4a1a-8a86-78dcc1453de7@github.com>

> Please review a cleanup in DocCommentParser to merge blockContent and inlineContent into a single method to parse "rich content" in a doc comment.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:

 - Merge branch 'pr/13362' into pr/13362
 - Merge remote-tracking branch 'upstream/master' into 8305713.dcp-content
 - 8305809: (fs) Review obsolete Linux kernel dependency on os.version (Unix kernel 2.6.39)
   
   Reviewed-by: rriggs, alanb
 - 8294806: jpackaged-app ignores splash screen from jar file
   
   Reviewed-by: almatvee
 - 8305368: G1 remset chunk claiming may use relaxed memory ordering
   
   Reviewed-by: ayang, iwalulya
 - 8305370: Inconsistent use of for_young_only_phase parameter in G1 predictions
   
   Reviewed-by: iwalulya, kbarrett
 - 8305663: Wrong iteration order of pause array in g1MMUTracker
   
   Reviewed-by: ayang, tschatzl
 - 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries
   
   Reviewed-by: alanb, kevinw
 - 8305419: JDK-8301995 broke building libgraal
   
   Reviewed-by: matsaave, dnsimon, thartmann
 - 8302696: Revert API signature changes made in JDK-8285504 and JDK-8285263
   
   Reviewed-by: mullan
 - ... and 49 more: https://git.openjdk.org/jdk/compare/5501bf21...45ee028b

-------------

Changes: https://git.openjdk.org/jdk/pull/13431/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13431&range=02
  Stats: 15292 lines in 500 files changed: 7710 ins; 6358 del; 1224 mod
  Patch: https://git.openjdk.org/jdk/pull/13431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13431/head:pull/13431

PR: https://git.openjdk.org/jdk/pull/13431

From vlivanov at openjdk.org  Tue Apr 11 19:01:48 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 11 Apr 2023 19:01:48 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v7]
In-Reply-To: <PAuphp5Wv4xJIe8z3jCYNCHdPqP7yhbk4WX7SRnsst0=.58751569-e28b-4a68-9d49-5bebe56d7881@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <PAuphp5Wv4xJIe8z3jCYNCHdPqP7yhbk4WX7SRnsst0=.58751569-e28b-4a68-9d49-5bebe56d7881@github.com>
Message-ID: <UMEsk128iQZiwkUN3d3DZdnGJRu8lbxtYdS3TGij9Us=.30aa58f1-e816-434b-868a-18588cdb5c15@github.com>

On Fri, 7 Apr 2023 17:13:50 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   special case iotaShuffle

Nice refactoring! Happy to see so much code gone.

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13093#pullrequestreview-1379896647

From vlivanov at openjdk.org  Tue Apr 11 19:06:38 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 11 Apr 2023 19:06:38 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v6]
In-Reply-To: <mvjXG43i2H0ULxXam6DzZR6SPrVjyth_x4Fu7CTjmE0=.04f5e64d-54bd-4556-bc46-212552526853@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <mvjXG43i2H0ULxXam6DzZR6SPrVjyth_x4Fu7CTjmE0=.04f5e64d-54bd-4556-bc46-212552526853@github.com>
Message-ID: <OUYSIb3zl-YY_pNjOE0kmZe__-Gstt65QYoVDFQu-PY=.ba9ea3bd-0e31-48b8-a445-a7a9897d69f9@github.com>

On Tue, 4 Apr 2023 13:46:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
>> 
>> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
>> 
>> Please take a look and have some reviews. Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   style

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java line 2295:

> 2293:                 // to be performant
> 2294:                 @ForceInline
> 2295:                 public ShortVector apply(ShortVector v1, ShortVector v2, int o) {

Have you considered matching the corresponding IR during GVN to produce VectorSlice nodes rather than going through VM intrinsic?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1163216924

From rriggs at openjdk.org  Tue Apr 11 19:37:52 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 19:37:52 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <FrhXODydplyZNBZ5bdGY_VGNcfKtCjGcsWj0TepHZPA=.1351c357-4154-4f4a-a140-61699d71b0b9@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
 <TmkOpylJOmfV6CpwyF8BsuKjp58iqjv2mjDJROpjHHw=.393f6ba9-eecc-4adf-9f4e-b5abb7aaa8a5@github.com>
 <zVFAPrR8Iq7X2oD8vVoQ3qb97HybmQTnB3kl6EYXMYw=.937e1d6a-7ce4-4d70-94ff-a1ab36c9adb0@github.com>
 <FrhXODydplyZNBZ5bdGY_VGNcfKtCjGcsWj0TepHZPA=.1351c357-4154-4f4a-a140-61699d71b0b9@github.com>
Message-ID: <1V5TUTuOnnVWmf7IyjkNZnrl0qRn1eS77yCD5ALEltI=.8f4a049a-eba3-42fe-85ad-80ee5cafa660@github.com>

On Tue, 11 Apr 2023 18:37:11 GMT, Glavo <duke at openjdk.org> wrote:

>>> Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too.
>> 
>> Changing os.arch is out of scope for this PR.
>> The best way for that would someone supporting ppc to develop and propose a PR.
>
>> > Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too.
>> 
>> Changing os.arch is out of scope for this PR. The best way for that would someone supporting ppc to develop and propose a PR.
> 
> It seems that you replied in the wrong place.

Likely, I misunderstood the request.  Mapping ppc64 to PPC64 is easy enough.
But currently, there is no direct support in the build/makefiles for ppc. See [OpenJDK supported platforms](https://wiki.openjdk.org/display/Build/Supported+Build+Platforms).
For anything other than the most trivial and obvious, someone who can build ppc and test should propose the changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163241987

From rriggs at openjdk.org  Tue Apr 11 19:37:53 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 19:37:53 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <1V5TUTuOnnVWmf7IyjkNZnrl0qRn1eS77yCD5ALEltI=.8f4a049a-eba3-42fe-85ad-80ee5cafa660@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
 <TmkOpylJOmfV6CpwyF8BsuKjp58iqjv2mjDJROpjHHw=.393f6ba9-eecc-4adf-9f4e-b5abb7aaa8a5@github.com>
 <zVFAPrR8Iq7X2oD8vVoQ3qb97HybmQTnB3kl6EYXMYw=.937e1d6a-7ce4-4d70-94ff-a1ab36c9adb0@github.com>
 <FrhXODydplyZNBZ5bdGY_VGNcfKtCjGcsWj0TepHZPA=.1351c357-4154-4f4a-a140-61699d71b0b9@github.com>
 <1V5TUTuOnnVWmf7IyjkNZnrl0qRn1eS77yCD5ALEltI=.8f4a049a-eba3-42fe-85ad-80ee5cafa660@github.com>
Message-ID: <lrYWDY79fJuwcq5HClpu_BkxWk9K0PBLQrNFkxUQT4Y=.07c3c110-cb4e-4ab0-b000-4eb59a9c6064@github.com>

On Tue, 11 Apr 2023 19:33:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> > Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too.
>>> 
>>> Changing os.arch is out of scope for this PR. The best way for that would someone supporting ppc to develop and propose a PR.
>> 
>> It seems that you replied in the wrong place.
>
> Likely, I misunderstood the request.  Mapping ppc64 to PPC64 is easy enough.
> But currently, there is no direct support in the build/makefiles for ppc. See [OpenJDK supported platforms](https://wiki.openjdk.org/display/Build/Supported+Build+Platforms).
> For anything other than the most trivial and obvious, someone who can build ppc and test should propose the changes.

The naming of x86_64 was raised earlier and resolved to use X64.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163242850

From zjx001202 at gmail.com  Tue Apr 11 19:40:14 2023
From: zjx001202 at gmail.com (Glavo)
Date: Wed, 12 Apr 2023 03:40:14 +0800
Subject: Add String & Character ASCII case conversion methods
In-Reply-To: <CAPvyiy+cHhBryE4re7aKzFqj2tOkHW=EzvDiDLvfvMq5tven2g@mail.gmail.com>
References: <5c703745f0ba484c9d66b9666a1218a7@vodafonemail.de>
 <CAJL5A3=N+Mwv0uAa2w=rF2XW2SLVpZeUv_nPrZ=vK1Ek9yF3vA@mail.gmail.com>
 <CAPvyiy+cHhBryE4re7aKzFqj2tOkHW=EzvDiDLvfvMq5tven2g@mail.gmail.com>
Message-ID: <CAJL5A3=RMGb44On5o22+S9-tPBPRKuidCy8Bkq=0OqEmRDRV1Q@mail.gmail.com>

Thanks for your reply, I've opened a PR[1] where I hope to continue
discussing this issue.

Glavo

[1] https://github.com/openjdk/jdk/pull/13434

On Tue, Apr 11, 2023 at 9:02?PM Qu?n Anh Mai <anhmdq at gmail.com> wrote:

> Hi,
>
> To propose deprecation of String::toLowerCase() and String::toUpperCase(),
> you can create a patch as normal, with an addition of a CSR ticket that
> describes the situation and the proposed solution. After that, you can ask
> for someone from core-libs to review the ticket. The change can be merged
> after sufficient reviews and the CSR being approved. You can view
> other CSRs in JBS to see the overall structure, as well as other
> deprecations in the JDK to see a typical deprecation description. More
> details regarding CSRs can be found in the OpenJDK Wiki
> <https://wiki.openjdk.org/display/csr/Main>.
>
> Hope this helps,
> Quan Anh
>
> On Mon, 10 Apr 2023 at 00:47, Glavo <zjx001202 at gmail.com> wrote:
>
>> Hi,
>>
>> We discussed this issue on this mailing list[1] earlier this year.
>>
>> I investigated the usage of these two methods and found that all use
>> cases within
>> JDK are suspicious, resulting in many imperceptible bugs.
>>
>> I hope to create a PR for this issue, deprecate these two methods, and
>> create
>> alternative methods for them. But I don't have the experience of making
>> such
>> changes, maybe I need some guidance or have more experienced people do
>> these things.
>>
>> Glavo
>>
>> [1]
>> https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html
>>
>> On Sun, Apr 9, 2023 at 10:58?PM <
>> some-java-user-99206970363698485155 at vodafonemail.de> wrote:
>>
>>> Hello,
>>> could you please add String & Character ASCII case conversion methods,
>>> that is, methods which only perform case conversion on ASCII characters in
>>> the input and leave any other characters unchanged. The conversion should
>>> not depend on the default locale. For example:
>>> - String:
>>>   - toAsciiLowerCase
>>>   - toAsciiUpperCase
>>>   - equalsAsciiIgnoreCase (or a better name)
>>>   - compareToAsciiIgnoreCase (or a better name)
>>> - Character:
>>>   - toAsciiLowerCase
>>>   - toAsciiUpperCase
>>>
>>> This would give the following advantages:
>>> - Increased performance (+ not be vulnerable to denial of service
>>> attacks)
>>> - Reduced number of bugs in applications
>>>
>>>
>>> Please read on for a detailed explanation.
>>>
>>> I assume for historic reasons (Applets) the current case conversion
>>> methods use the Unicode conversion rules, and even worse
>>> String.toLowerCase() and String.toUpperCase() use the default locale. While
>>> this might back then have been a reasonable choice because Applets ran
>>> locally in the browser and localization was a nice to have feature (or even
>>> a requirement), nowadays Java is largely used for back-end systems and case
>>> conversion is pretty often done for technical strings and not display text
>>> anymore. In this context applications mostly process ASCII strings.
>>> However, because Java does not offer any specific case conversion
>>> methods for these cases, users still use the standard String & Character
>>> methods. This causes the following problems [1]:
>>>
>>> - String.toLowerCase() & String.toUpperCase() using default locale
>>>   What this means is that depending on the OS locale your application
>>> might behave differently or fail [2]. For the scale of this, simply look in
>>> the OpenJDK database: https://bugs.openjdk.org/issues/?jql=text ~
>>> "turkish locale"
>>>   At this point you probably have to add a disclaimer to any Java
>>> program that running it on systems with Turkish (and possibly others) as
>>> locale is not supported, because either your own code or the libraries you
>>> are using might be calling toLowerCase() or toUpperCase() [3].
>>>
>>> - Bad performance for Unicode aware case conversions
>>>   Compared to simply performing ASCII case conversion, applying Unicode
>>> case conversion has worse performance. In some cases it can even have
>>> extremely bad performance (JDK-8292573). This could have security
>>> implications.
>>>
>>> - Bugs due to case conversion changing string length
>>>   Unicode case conversion for certain strings can change the length,
>>> either increasing or decreasing the size of the string (or when combining
>>> both, shifting position of characters in the string while keeping the
>>> length the same). If an application assumes that the length of the string
>>> remains the same and uses data derived from the original string (e.g.
>>> character indices or length) on the converted string this can lead to
>>> exceptions or potentially even security issues.
>>>
>>> - Unicode characters mapping to ASCII chars
>>>   When performing case conversion on certain non-ASCII Unicode
>>> characters, the results are ASCII characters. For example
>>> `Character.toLowerCase('\u212A') == 'k'`. This could have security
>>> implications.
>>>
>>> - Update to Unicode data changing application behavior
>>>   Unicode evolves over time, and the JDK regularly updates the Unicode
>>> data it is using. Even if an application is not affected by the issues
>>> mentioned above, it could become affected by them when the Unicode data is
>>> updated in a newer JDK version.
>>>
>>> My main point here is that (I assume) in many cases Java applications
>>> don't need Unicode case conversion, let alone Unicode case conversion using
>>> the default locale. If Java offered ASCII-only case conversion methods,
>>> then hopefully users would (where applicable) switch to these methods over
>>> time and avoid all the issues mentioned above. And even if they
>>> accidentally use the ASCII-only methods for display text, the result might
>>> be a minor inconvenience for users seeing the display text, compared to in
>>> the other cases application bugs and security vulnerabilities.
>>>
>>> Related information about other programming languages:
>>> - Rust: Has dedicated methods for ASCII case conversion, e.g.
>>> https://doc.rust-lang.org/std/string/struct.String.html#method.to_ascii_lowercase
>>> - Kotlin: Functions which implicitly use the default locale were
>>> deprecated, see https://youtrack.jetbrains.com/issue/KT-43023
>>>
>>> Risks:
>>> - ASCII case conversion could lead to undesired results in some cases,
>>> see the example for the word "caf?" on
>>> https://doc.rust-lang.org/std/ascii/trait.AsciiExt.html (though that
>>> specific example is about a display string, for which these ASCII-only
>>> methods are not intended)
>>> - When applications start to mix ASCII-only and the existing Unicode
>>> conversion methods this could lead to bugs and security issues as well;
>>> though it might also indicate a flaw in the application if it performs case
>>> conversion on the same value in different places
>>>
>>> I hope you consider this suggestion. Feedback is appreciated!
>>>
>>> Kind regards
>>>
>>> ----
>>>
>>> [1] I am not saying though that Java is the only affected language, it
>>> definitely affects others as well. But that should not prevent improving
>>> the Java API.
>>> [2] Tool for detecting usage of such methods:
>>> https://github.com/policeman-tools/forbidden-apis
>>> [3] Maybe it would also be worth discussing deprecating
>>> String.toLowerCase() and String.toUpperCase() because they seem to do more
>>> harm than good.
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230412/bd1088a3/attachment-0001.htm>

From duke at openjdk.org  Tue Apr 11 19:53:46 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 11 Apr 2023 19:53:46 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v11]
In-Reply-To: <Df_fXzkh2mDAUGTXbMDqTa_2mVwm_T0DThx1JKvEmVk=.ae3f9b07-2c07-4582-885c-a6163ebe996e@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <Df_fXzkh2mDAUGTXbMDqTa_2mVwm_T0DThx1JKvEmVk=.ae3f9b07-2c07-4582-885c-a6163ebe996e@github.com>
Message-ID: <D1OneTtxzEudKNyw31h5mn03wsXjpnaOoS6PSRhc-Qs=.13f4fd9d-141e-4b18-b789-a38f9b200f48@github.com>

On Tue, 11 Apr 2023 18:35:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add ppc64 as mapping to PPC64 Architecture

src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 58:

> 56:         return switch (archName) {
> 57:             case "x86_64" -> "x64";
> 58:             case "ppc64", "ppc64le" -> "ppc64";

There?s?no `case?"s390" ->?"s390"`, so?this is?also?extraneous:
Suggestion:

            case "ppc64le" -> "ppc64";


--------------------------------------------------------------------------------

The?`case?"ppc64"` was?supposed to?be?added to?`ArchTest.java`.

test/jdk/jdk/internal/util/ArchTest.java line 74:

> 72:             case "riscv64" -> RISCV64;  // unverified
> 73:             case "s390x", "s390" -> S390;  // unverified
> 74:             case "ppc64le" -> PPC64;  // unverified

Suggestion:

            case "ppc64", "ppc64le" -> PPC64;  // unverified

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163257592
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163257861

From zjx001202 at gmail.com  Tue Apr 11 20:02:01 2023
From: zjx001202 at gmail.com (Glavo)
Date: Wed, 12 Apr 2023 04:02:01 +0800
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
Message-ID: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>

Hi everyone,

A few months ago, I discussed in this mailing list[1] whether
toLowerCase()/toUpperCase() should be deprecated.
At that time, I received some approval and no one opposed the
idea. Therefore, I thought it might be time
to continue advancing this work, so I created a PR[2] for this.

This PR is still a draft, welcome to discuss it there.

I don't have much experience in contributing to OpenJDK yet, so I also hope
to get the help of experienced
contributors (such as creating CSR). Thanks!

Glavo

[1]
https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html
[2] https://github.com/openjdk/jdk/pull/13434
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230412/22958830/attachment.htm>

From forax at univ-mlv.fr  Tue Apr 11 20:21:13 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 11 Apr 2023 22:21:13 +0200 (CEST)
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
Message-ID: <233035587.34407903.1681244473362.JavaMail.zimbra@univ-eiffel.fr>

> From: "Glavo" <zjx001202 at gmail.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Tuesday, April 11, 2023 10:02:01 PM
> Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
> insensitive alternative

> Hi everyone,

> A few months ago, I discussed in this mailing list[1] whether
> toLowerCase()/toUpperCase() should be deprecated.
> At that time, I received some approval and no one opposed the idea. Therefore, I
> thought it might be time
> to continue advancing this work, so I created a PR[2] for this.

> This PR is still a draft, welcome to discuss it there.

> I don't have much experience in contributing to OpenJDK yet, so I also hope to
> get the help of experienced
> contributors (such as creating CSR). Thanks!

I think deprecating toLowerCase()/toUpperCase() is a great idea but at the same time, i'm not sure that the methods lowercase() and uppercase() are a good addition. 
Their names are too close to toLowerCase/toUpperCase thus too easy to misuse ones for the others. 

I'm fine with users having to write toLowerCase(Locale.ROOT) or toUpperCase(Locale.Root) because this is already what we teach. 

> Glavo

regards, 
R?mi 

> [1] [ https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html
> | https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html ]
> [2] [ https://github.com/openjdk/jdk/pull/13434 |
> https://github.com/openjdk/jdk/pull/13434 ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230411/2b3dfe20/attachment.htm>

From rriggs at openjdk.org  Tue Apr 11 20:45:35 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 20:45:35 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v2]
In-Reply-To: <lwI-yTh0L8dp1xIim6Qkg7xxQaOcWDAKq7qWdUm9NXQ=.a092f238-071c-40e1-8732-5b16ee0f88c3@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <dg6qtk5ave9VNr7E0Jf7nHBB9OgkJdJq-A_17OsP094=.1113df8d-50f7-4baa-a8e8-8aef1ee61ac0@github.com>
 <OQI29CEXN1M-5u_8Y7SLcxMC-SEO3OwOoeL-gunFNlE=.2b59085c-72ba-4a11-852f-57528a390819@github.com>
 <lwI-yTh0L8dp1xIim6Qkg7xxQaOcWDAKq7qWdUm9NXQ=.a092f238-071c-40e1-8732-5b16ee0f88c3@github.com>
Message-ID: <TnsK7PLQEtOQ4INryFH79SyrqmNmAt6NjfEN3mZVTls=.88e001aa-4ddb-4aed-9079-4bdbfb53ce56@github.com>

On Tue, 11 Apr 2023 08:58:36 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 3302:
>> 
>>> 3300:      * <tr><!-- o -->
>>> 3301:      *     <th scope="row" style="font-weight:normal; text-align:right; padding-right:1em">0</th>
>>> 3302:      *     <td>{@code { "b", "o", "", "o", ":::and::f", "o", "", "o" }}</td></tr>
>> 
>> These cases might be a bit easier to understand if the regex matched characters that looked more like delimiters, perhaps just ":".
>
> The choice of multi-character delimiter is deliberate, to show that the regex really absorbs all the delimiter characters.
> The `":+"` examples are followed by the `"o"` examples, where the delimiters are single characters.

I understood the value of `:+` case.
I found reading the single "o" as a delimiter is not intuitive or easy to parse because it looks like the the strings that are being delimited, not a delimiter.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1163308998

From mdoerr at openjdk.org  Tue Apr 11 20:46:44 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 11 Apr 2023 20:46:44 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v11]
In-Reply-To: <Df_fXzkh2mDAUGTXbMDqTa_2mVwm_T0DThx1JKvEmVk=.ae3f9b07-2c07-4582-885c-a6163ebe996e@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <Df_fXzkh2mDAUGTXbMDqTa_2mVwm_T0DThx1JKvEmVk=.ae3f9b07-2c07-4582-885c-a6163ebe996e@github.com>
Message-ID: <qHaNjGgVAgGT80j3UcOY-_Kda91OXxyqUZ6NdI0R0Vo=.6f7e46f3-79a8-4a4a-9e66-f1d27aab486b@github.com>

On Tue, 11 Apr 2023 18:35:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add ppc64 as mapping to PPC64 Architecture

Thanks for the updates! PPC64 looks basically good except of a upper / lower case issue in the test:
STARTED    ArchTest::nameVsCurrent 'nameVsCurrent()'
org.opentest4j.AssertionFailedError: mismatch in Architecture.current vs ppc64 ==> expected: <PPC64> but was: <OTHER>
...
FAILED     ArchTest::nameVsCurrent 'nameVsCurrent()'
JavaTest Message: JUnit Platform Failure(s): 1

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1504064549

From rriggs at openjdk.org  Tue Apr 11 20:49:33 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 20:49:33 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v4]
In-Reply-To: <J2bOKs8y9SxolEuGLmooVtr5Bque2h_TAQzJ05IB2yc=.a2c7f620-643d-4172-99b7-fa22c9f0d45d@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <J2bOKs8y9SxolEuGLmooVtr5Bque2h_TAQzJ05IB2yc=.a2c7f620-643d-4172-99b7-fa22c9f0d45d@github.com>
Message-ID: <l-RY3ycOG-g7sdDhpS5aicNPjcxApz8187KV-xFxfqk=.ac2bea03-2bac-432a-9492-d03dc6978ebe@github.com>

On Tue, 11 Apr 2023 09:14:29 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8305486: Add split() variants that keep the delimiters to String and j.u.r.Patten
>   Clarification about zero-width matches at the beginning of the input

The CSR can be moved to Proposed to get that review process started.
I think another Reviewer should take a look at the wording also.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13305#issuecomment-1504067637

From zjx001202 at gmail.com  Tue Apr 11 20:51:31 2023
From: zjx001202 at gmail.com (Glavo)
Date: Wed, 12 Apr 2023 04:51:31 +0800
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <233035587.34407903.1681244473362.JavaMail.zimbra@univ-eiffel.fr>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <233035587.34407903.1681244473362.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CAJL5A3nTk5n+byHnON7L_3jmwJ6=-dpc_P1RFgye357VPu-vvw@mail.gmail.com>

Thank you for your reply.

I'm not sure what's best either. I chose to name them lowercase/uppercase
here
because Kotlin chose them, so many users are already familiar with them.
It would be great if there were better ideas.

Glavo

On Wed, Apr 12, 2023 at 4:21?AM Remi Forax <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"Glavo" <zjx001202 at gmail.com>
> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
> *Sent: *Tuesday, April 11, 2023 10:02:01 PM
> *Subject: *Draft: Deprecate toLowerCase()/toUpperCase() and provide
> locale insensitive alternative
>
> Hi everyone,
>
> A few months ago, I discussed in this mailing list[1] whether
> toLowerCase()/toUpperCase() should be deprecated.
> At that time, I received some approval and no one opposed the
> idea. Therefore, I thought it might be time
> to continue advancing this work, so I created a PR[2] for this.
>
> This PR is still a draft, welcome to discuss it there.
>
> I don't have much experience in contributing to OpenJDK yet, so I also
> hope to get the help of experienced
> contributors (such as creating CSR). Thanks!
>
>
> I think deprecating toLowerCase()/toUpperCase() is a great idea but at the
> same time, i'm not sure that the methods lowercase() and uppercase() are a
> good addition.
> Their names are too close to toLowerCase/toUpperCase thus too easy to
> misuse ones for the others.
>
> I'm fine with users having to write toLowerCase(Locale.ROOT) or
> toUpperCase(Locale.Root) because this is already what we teach.
>
>
>
> Glavo
>
>
> regards,
> R?mi
>
>
> [1]
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html
> [2] https://github.com/openjdk/jdk/pull/13434
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230412/2d79174b/attachment.htm>

From msheppar at openjdk.org  Tue Apr 11 20:53:35 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 11 Apr 2023 20:53:35 GMT
Subject: RFR: JDK-8295859 Update Manual Test Groups [v2]
In-Reply-To: <3KeJLP761daIyT87slqdEryg-DaoCH8FcjwzxaVfxIY=.ada66a7b-8cd6-4a8e-bbc2-a185ea5fc7c5@github.com>
References: <A8iSpxnkw9ogc19QG-cGFTM4Xhe7vpX62WJ-c632KcA=.8a238ad1-661a-4809-a2da-b995627623cc@github.com>
 <3KeJLP761daIyT87slqdEryg-DaoCH8FcjwzxaVfxIY=.ada66a7b-8cd6-4a8e-bbc2-a185ea5fc7c5@github.com>
Message-ID: <aDHHOECTFlpz8xM5Jod2J6kjWlQ-q52tetF7LGPv-y0=.05d802c1-c659-4223-84ae-3a76ea32cf64@github.com>

On Mon, 20 Mar 2023 23:29:25 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> The purpose of this task is to add the difference between -manual jdk_core and jdk_core_manual to the jdk_core_manual test goal. Furthermore, in order to streamline the manual test execution process, a new test group called jdk_core_manual_human has been created for manual tests that demand extra preparation or test input.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

test/jdk/TEST.groups line 600:

> 598: 
> 599: jdk_core_manual = \
> 600:     :jdk_core_manual_no_input \

jdk_core_manual_human (as it is now called) should be part of jdk_core_manual, as jdk_core_manual will be used in the corelibs-atr job

test/jdk/TEST.groups line 643:

> 641:     sun/security/tools/jarsigner/compatibility/Compatibility.java
> 642: 
> 643: jdk_core_manual_human = \

jdk_core_manual_requires_human_input gave a good indication of what is needed with this test group ... maybe jdk_core_manual_interactive if we don't want to use requires_human_input

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12840#discussion_r1163314338
PR Review Comment: https://git.openjdk.org/jdk/pull/12840#discussion_r1163316682

From rriggs at openjdk.org  Tue Apr 11 21:09:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 21:09:43 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v12]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Correct mapping and test of ppc64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/1c0c0220..71135e3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=10-11

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

PR: https://git.openjdk.org/jdk/pull/13357

From duke at openjdk.org  Tue Apr 11 21:16:46 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 11 Apr 2023 21:16:46 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v12]
In-Reply-To: <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com>
Message-ID: <gbjsrOlwH12weOz2XBiXQvHM9fJOqfk9gsX5PWqbGdM=.548facca-e367-4e40-9caf-c8364f7899ca@github.com>

On Tue, 11 Apr 2023 21:09:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct mapping and test of ppc64

test/jdk/jdk/internal/util/ArchTest.java line 70:

> 68:             case "x86" -> X86;
> 69:             case "i386" -> X86;
> 70:             case "amd64" -> X64;  // Is alias for X86_64

Suggestion:

            case "x86_64", "amd64" -> X64;
            case "x86", "i386" -> X86;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163340519

From duke at openjdk.org  Tue Apr 11 21:35:25 2023
From: duke at openjdk.org (Andy-Tatman)
Date: Tue, 11 Apr 2023 21:35:25 GMT
Subject: RFR: 8305734: Fixes bug in get(int, int)
Message-ID: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>

See https://bugs.java.com/bugdatabase/view_bug?bug_id=8305734

-------------

Commit messages:
 - Update src/java.base/share/classes/java/util/BitSet.java
 - Removed trailing whitespace
 - 8305734: Fixes bug in get(int, int)

Changes: https://git.openjdk.org/jdk/pull/13388/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13388&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305734
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13388/head:pull/13388

PR: https://git.openjdk.org/jdk/pull/13388

From liach at openjdk.org  Tue Apr 11 21:35:26 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Apr 2023 21:35:26 GMT
Subject: RFR: 8305734: Fixes bug in get(int, int)
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: <JK1A2CMkDhnDQ4K5y_9NUJ-eotbM5b0L6XRpm1OyScc=.f01dbcd0-a93f-4487-b0ed-0597d74ba63e@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

I think what Alan suggested in JBS is better: explicitly reject setting Integer.MAX_VALUE bit so that `len` will never return negative.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1501333246

From duke at openjdk.org  Tue Apr 11 21:35:27 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 11 Apr 2023 21:35:27 GMT
Subject: RFR: 8305734: Fixes bug in get(int, int)
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: <_5aRUPBYiWMjiikz6HHeQI0gvFsfEgIDewD8q1uSVUI=.479794c9-1d91-49be-91e7-4e4cec9a6d1a@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

src/java.base/share/classes/java/util/BitSet.java line 653:

> 651: 
> 652:         int len = length();
> 653:         if ( len < 0 )

Suggestion:

        if (len < 0)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13388#discussion_r1161099741

From zjx001202 at gmail.com  Tue Apr 11 21:51:23 2023
From: zjx001202 at gmail.com (Glavo)
Date: Wed, 12 Apr 2023 05:51:23 +0800
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <233035587.34407903.1681244473362.JavaMail.zimbra@univ-eiffel.fr>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <233035587.34407903.1681244473362.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CAJL5A3njdxe4ctJHk1_pWCtqJFREBNjGJ2Gj-OXocAdiX+2O5w@mail.gmail.com>

>  I'm fine with users having to write toLowerCase(Locale.ROOT) or
toUpperCase(Locale.Root) because this is already what we teach.

This is the current situation, but I don't think it is good.

This idiom forces users to import Locale even in locale-insensitive
scenarios.
I think this brings a lot of noise, so we also need to eliminate it

Glavo

On Wed, Apr 12, 2023 at 4:21?AM Remi Forax <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"Glavo" <zjx001202 at gmail.com>
> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
> *Sent: *Tuesday, April 11, 2023 10:02:01 PM
> *Subject: *Draft: Deprecate toLowerCase()/toUpperCase() and provide
> locale insensitive alternative
>
> Hi everyone,
>
> A few months ago, I discussed in this mailing list[1] whether
> toLowerCase()/toUpperCase() should be deprecated.
> At that time, I received some approval and no one opposed the
> idea. Therefore, I thought it might be time
> to continue advancing this work, so I created a PR[2] for this.
>
> This PR is still a draft, welcome to discuss it there.
>
> I don't have much experience in contributing to OpenJDK yet, so I also
> hope to get the help of experienced
> contributors (such as creating CSR). Thanks!
>
>
> I think deprecating toLowerCase()/toUpperCase() is a great idea but at the
> same time, i'm not sure that the methods lowercase() and uppercase() are a
> good addition.
> Their names are too close to toLowerCase/toUpperCase thus too easy to
> misuse ones for the others.
>
> I'm fine with users having to write toLowerCase(Locale.ROOT) or
> toUpperCase(Locale.Root) because this is already what we teach.
>
>
>
> Glavo
>
>
> regards,
> R?mi
>
>
> [1]
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html
> [2] https://github.com/openjdk/jdk/pull/13434
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230412/f76df482/attachment.htm>

From bhuang at openjdk.org  Tue Apr 11 22:00:34 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 11 Apr 2023 22:00:34 GMT
Subject: RFR: JDK-8295859 Update Manual Test Groups [v2]
In-Reply-To: <aDHHOECTFlpz8xM5Jod2J6kjWlQ-q52tetF7LGPv-y0=.05d802c1-c659-4223-84ae-3a76ea32cf64@github.com>
References: <A8iSpxnkw9ogc19QG-cGFTM4Xhe7vpX62WJ-c632KcA=.8a238ad1-661a-4809-a2da-b995627623cc@github.com>
 <3KeJLP761daIyT87slqdEryg-DaoCH8FcjwzxaVfxIY=.ada66a7b-8cd6-4a8e-bbc2-a185ea5fc7c5@github.com>
 <aDHHOECTFlpz8xM5Jod2J6kjWlQ-q52tetF7LGPv-y0=.05d802c1-c659-4223-84ae-3a76ea32cf64@github.com>
Message-ID: <qleSOxJcK081Y0UPogMC3iUQsluWPvjeAy4JNmPMEb4=.534be1dd-75c6-40ef-a92b-506c9dcf0e85@github.com>

On Tue, 11 Apr 2023 20:50:28 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments.
>
> test/jdk/TEST.groups line 643:
> 
>> 641:     sun/security/tools/jarsigner/compatibility/Compatibility.java
>> 642: 
>> 643: jdk_core_manual_human = \
> 
> jdk_core_manual_requires_human_input gave a good indication of what is needed with this test group ... maybe jdk_core_manual_interactive if we don't want to use requires_human_input

The name "jdk_core_manual_requires_human_input" may not be suitable because some tests in this group require environment preparation or root privilege. I prefer the name "jdk_core_manual_interactive".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12840#discussion_r1163371467

From bhuang at openjdk.org  Tue Apr 11 22:06:30 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 11 Apr 2023 22:06:30 GMT
Subject: RFR: JDK-8295859 Update Manual Test Groups [v3]
In-Reply-To: <A8iSpxnkw9ogc19QG-cGFTM4Xhe7vpX62WJ-c632KcA=.8a238ad1-661a-4809-a2da-b995627623cc@github.com>
References: <A8iSpxnkw9ogc19QG-cGFTM4Xhe7vpX62WJ-c632KcA=.8a238ad1-661a-4809-a2da-b995627623cc@github.com>
Message-ID: <ofbrPO0fX7osDzj3VpcVkN-EIFGe8GTqg14pjTcDxBI=.faa939e1-afe7-40a6-8291-367900dcd54d@github.com>

> The purpose of this task is to add the difference between -manual jdk_core and jdk_core_manual to the jdk_core_manual test goal. Furthermore, in order to streamline the manual test execution process, a new test group called jdk_core_manual_human has been created for manual tests that demand extra preparation or test input.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Renamed jdk_core_manual to jdk_core_manual_interactive

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12840/files
  - new: https://git.openjdk.org/jdk/pull/12840/files/32496d97..7d64305c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12840&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12840&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12840.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12840/head:pull/12840

PR: https://git.openjdk.org/jdk/pull/12840

From archie.cobbs at gmail.com  Tue Apr 11 22:32:45 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 11 Apr 2023 17:32:45 -0500
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <CAJL5A3njdxe4ctJHk1_pWCtqJFREBNjGJ2Gj-OXocAdiX+2O5w@mail.gmail.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <233035587.34407903.1681244473362.JavaMail.zimbra@univ-eiffel.fr>
 <CAJL5A3njdxe4ctJHk1_pWCtqJFREBNjGJ2Gj-OXocAdiX+2O5w@mail.gmail.com>
Message-ID: <CANSoFxtXHr7mN9ishM1QT5JrY-3FGsKv0P5r832wugcktafmWw@mail.gmail.com>

On Tue, Apr 11, 2023 at 4:52?PM Glavo <zjx001202 at gmail.com> wrote:

> i'm not sure that the methods lowercase() and uppercase() are a good
>> addition.
>> Their names are too close to toLowerCase/toUpperCase thus too easy to
>> misuse ones for the others.
>>
>

> I'm fine with users having to write toLowerCase(Locale.ROOT) or
>> toUpperCase(Locale.Root) because this is already what we teach.
>
>
> This is the current situation, but I don't think it is good.
>
> This idiom forces users to import Locale even in locale-insensitive
> scenarios.
>

Possible compromise? How about toUpper() and toLower()?

This would be consistent with the trend whereby newer replacement names
tend to be less verbose (e.g., Enumeration.hasMoreElements() ->
Iterator.hasNext()), while also being different enough that people
shouldn't mistake them for something that already exists, and will
understand that they must mean something new.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230411/bda2fc36/attachment.htm>

From kbarrett at openjdk.org  Wed Apr 12 01:41:34 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 12 Apr 2023 01:41:34 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v3]
In-Reply-To: <a8EKWPPER8vptO3T4DOmt1KwB03s4vc2gkkXOBKEohk=.f898dbf4-dbf0-452e-8d25-3975423bfee5@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <a8EKWPPER8vptO3T4DOmt1KwB03s4vc2gkkXOBKEohk=.f898dbf4-dbf0-452e-8d25-3975423bfee5@github.com>
Message-ID: <ZnAQSD08dhUKz4h9tBWPSkjD7BIEhF_-XGdI4q8S2S0=.9dd6447f-af0c-416e-9f4f-42f473e7b255@github.com>

On Sat, 8 Apr 2023 13:24:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Semicolon

I don't think the other bug/PR (JDK-8250269, PR#11431) to change HotSpot's
ATTRIBUTE_ALIGNED should be combined with the changes outside of HotSpot.
They are doing rather different things, despite the token "alignas" occuring
in both.  I've been meaning to review PR#11431, but have been swamped.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1504401317

From kbarrett at openjdk.org  Wed Apr 12 02:39:36 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 12 Apr 2023 02:39:36 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v3]
In-Reply-To: <a8EKWPPER8vptO3T4DOmt1KwB03s4vc2gkkXOBKEohk=.f898dbf4-dbf0-452e-8d25-3975423bfee5@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <a8EKWPPER8vptO3T4DOmt1KwB03s4vc2gkkXOBKEohk=.f898dbf4-dbf0-452e-8d25-3975423bfee5@github.com>
Message-ID: <d34CsLBhpQKHbitXf_22A1NKaQWS3HhOKO5PVgtA2XA=.e0d9c373-74b6-4497-a23a-3237b248a2f6@github.com>

On Sat, 8 Apr 2023 13:24:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Semicolon

I was pretty confused by the C changes for a while, since I didn't know or had
forgotten that the 32bit Windows ABI only guarantees 4 byte stack alignment,
and permits "misaligned" local variables for types such as long long and
double.  (And I failed to find any definitive documentation for that.)  Yuck!

What is the purpose of removing `defined(_MSC_VER)` from the conditionals?  Is
this to allow for other compilers that similarly only ensure 4 byte alignment
of the stack?  If so, it would have been nice to mention that separate concern
in the PR description, rather than making reviewers guess.  And do such
compilers actually exist?  A bit of research suggests gcc (at least) maintains
16 byte alignment (and may warrant the use of -mstackrealign or other hoops).
See, for example, https://github.com/uTox/uTox/issues/1304.

Is `defined(_WIN32)` really the right conditional?  That's true for pretty
much any Visual Studio supported target, both 32bit and 64bit.  But the
alignment spec is effectively a nop for 64bit platforms, so harmless.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1504466526

From dholmes at openjdk.org  Wed Apr 12 02:48:34 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 12 Apr 2023 02:48:34 GMT
Subject: RFR: 8305846: Support compilation in Proc test utility
In-Reply-To: <tJkYNJm75DjmNugz1RxFHkkFSN6NgMBTr7IqQ3Jz8ls=.7afeae60-6738-404d-ae99-a9d7edcfdf0a@github.com>
References: <tJkYNJm75DjmNugz1RxFHkkFSN6NgMBTr7IqQ3Jz8ls=.7afeae60-6738-404d-ae99-a9d7edcfdf0a@github.com>
Message-ID: <5Wh_IW5bcBDdo_TNuk2hdnSpV9oVuGLeDG4w3tanB1E=.52bef0e6-f6cc-4248-984c-331be4a63b64@github.com>

On Tue, 11 Apr 2023 13:40:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Enhance the `Proc` utility to support compilation.

test/lib/jdk/test/lib/process/Proc.java line 274:

> 272:     }
> 273:     // Compile as well
> 274:     public Proc compile() throws IOException {

Why "throws IOException" ? I'm surprised javac doesn't say it can't be thrown.

test/lib/jdk/test/lib/process/Proc.java line 286:

> 284:         if (cp == null) {
> 285:             return System.getProperty("test.class.path") + File.pathSeparator +
> 286:                     System.getProperty("test.src.path");

Pre-existing by why is the src path put in the classpath?

test/lib/jdk/test/lib/process/Proc.java line 338:

> 336:             if (!comp) {
> 337:                 throw new IOException("Compilation error");
> 338:             }

Seems an odd use of IOException and not very helpful - will the actual compile command produce any diagnostics?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13425#discussion_r1163516184
PR Review Comment: https://git.openjdk.org/jdk/pull/13425#discussion_r1163517536
PR Review Comment: https://git.openjdk.org/jdk/pull/13425#discussion_r1163518613

From dholmes at openjdk.org  Wed Apr 12 02:59:33 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 12 Apr 2023 02:59:33 GMT
Subject: RFR: 8305846: Support compilation in Proc test utility
In-Reply-To: <tJkYNJm75DjmNugz1RxFHkkFSN6NgMBTr7IqQ3Jz8ls=.7afeae60-6738-404d-ae99-a9d7edcfdf0a@github.com>
References: <tJkYNJm75DjmNugz1RxFHkkFSN6NgMBTr7IqQ3Jz8ls=.7afeae60-6738-404d-ae99-a9d7edcfdf0a@github.com>
Message-ID: <WoAQaZkUhxxvnAFJUJWdzph5rLMLuE_hSGbDJdTY2Z0=.d07a63bb-1076-40fb-ba9a-51babc10550f@github.com>

On Tue, 11 Apr 2023 13:40:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Enhance the `Proc` utility to support compilation.

test/lib/jdk/test/lib/process/Proc.java line 331:

> 329: 
> 330:         if (compile) {
> 331:             var comp = CompilerUtils.compile(

I don't find this use of `var` helpful - `var` is useful for saying "some type I don't really care about and can't be bothered to spell out". But here we just have a boolean so it is clearer to just say `boolean compiled` (or `success` or `ok` or some such name that reflects what the return value actually means). Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13425#discussion_r1163528639

From amitkumar at openjdk.org  Wed Apr 12 03:47:43 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 12 Apr 2023 03:47:43 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v10]
In-Reply-To: <mBvcRGaKW5CD2m2iTgeBXJ9S-xkgwdFdkgx5fkCNoVI=.0e483496-7ce0-45e9-9a3c-af79c0c20b95@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <i2siBlNCDjWM4dMLLyPL0c8SFGFTODNdJpKTBIxhJy4=.a9b40975-0efd-49b3-b81b-dbc67c58edbb@github.com>
 <mBvcRGaKW5CD2m2iTgeBXJ9S-xkgwdFdkgx5fkCNoVI=.0e483496-7ce0-45e9-9a3c-af79c0c20b95@github.com>
Message-ID: <gGsAtNpsCBDC_6K6wrgzM3jdMFbOhLl4uKdkma7v-mY=.2eaf5245-84ad-4a44-975f-7a7eb5be4c79@github.com>

On Tue, 11 Apr 2023 18:07:41 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Another remark: Old JDK on s390 used "os.arch = zArch_64", current one "os.arch = s390x". @offamitkumar: You probably want to take a look.

Martin, only concern was that I didn't have a good experience with `s390x` string in [past](https://github.com/openjdk/jdk/pull/13228#issuecomment-1488599607).  But, I assume that `default` in `mapArchString` will unintentionally handle that scenario here. I tested it, and 'ArchTest.java' also passes.

 I guess @RealLucy might have some pointer over this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1504542573

From lmesnik at openjdk.org  Wed Apr 12 03:55:41 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 12 Apr 2023 03:55:41 GMT
Subject: RFR: 8305875: Test TraceVirtualThreadLocals should be run with
 continuations only
Message-ID: <g9W0p02Y0P5LafPHpH05fWqyeH7HEbzRkGk7IXRbXPo=.7e396e18-4634-4efe-add5-496f605f10c5@github.com>

Test TraceVirtualThreadLocals verifies that thread locals are dumped for virtual threads. It fails when continuations are not available and virtual threads are emulated.

The test failed on linux-x86 so I just want to mark it to have green github actions results.

-------------

Commit messages:
 - fixed TraceVirtualThreadLocals.java

Changes: https://git.openjdk.org/jdk/pull/13436/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13436&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305875
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13436.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13436/head:pull/13436

PR: https://git.openjdk.org/jdk/pull/13436

From dholmes at openjdk.org  Wed Apr 12 06:15:33 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 12 Apr 2023 06:15:33 GMT
Subject: RFR: 8305875: Test TraceVirtualThreadLocals should be run with
 continuations only
In-Reply-To: <g9W0p02Y0P5LafPHpH05fWqyeH7HEbzRkGk7IXRbXPo=.7e396e18-4634-4efe-add5-496f605f10c5@github.com>
References: <g9W0p02Y0P5LafPHpH05fWqyeH7HEbzRkGk7IXRbXPo=.7e396e18-4634-4efe-add5-496f605f10c5@github.com>
Message-ID: <Sga5aBCWiaaw4jqEB8Un04PSmLpis55q7FH_ep35xAo=.5855bf2c-7cf4-4d8d-8ea7-3a9fc63f04e9@github.com>

On Tue, 11 Apr 2023 23:38:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test TraceVirtualThreadLocals verifies that thread locals are dumped for virtual threads. It fails when continuations are not available and virtual threads are emulated.
> 
> The test failed on linux-x86 so I just want to mark it to have green github actions results.

Sorry, have to ask, but why does the test fail without continuations? IIRC the emulated VTs use a carrier-per-VT so I would expect the ThreadLocal test to work just fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13436#issuecomment-1504718069

From alanb at openjdk.org  Wed Apr 12 06:29:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Apr 2023 06:29:34 GMT
Subject: RFR: 8305875: Test TraceVirtualThreadLocals should be run with
 continuations only
In-Reply-To: <Sga5aBCWiaaw4jqEB8Un04PSmLpis55q7FH_ep35xAo=.5855bf2c-7cf4-4d8d-8ea7-3a9fc63f04e9@github.com>
References: <g9W0p02Y0P5LafPHpH05fWqyeH7HEbzRkGk7IXRbXPo=.7e396e18-4634-4efe-add5-496f605f10c5@github.com>
 <Sga5aBCWiaaw4jqEB8Un04PSmLpis55q7FH_ep35xAo=.5855bf2c-7cf4-4d8d-8ea7-3a9fc63f04e9@github.com>
Message-ID: <Kch-DPw1X6pZd3bjsWRnXTtppgINlL0TI65gg6B-1Ak=.e3e363db-4b78-423a-a4bb-93d5671154e5@github.com>

On Wed, 12 Apr 2023 06:13:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry, have to ask, but why does the test fail without continuations? IIRC the emulated VTs use a carrier-per-VT so I would expect the ThreadLocal test to work just fine.

The debugging option is for the VirtualThread implementation only at this time, it's a no-op when running with -XX:+UnlockExperimentalVMOptions -XX:-VMContinuations. It could be made to work with the fallback implementation but it risks using thread locals recursively as formatters effectively run arbitrary code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13436#issuecomment-1504728388

From lmesnik at openjdk.org  Wed Apr 12 06:29:36 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 12 Apr 2023 06:29:36 GMT
Subject: RFR: 8305875: Test TraceVirtualThreadLocals should be run with
 continuations only
In-Reply-To: <g9W0p02Y0P5LafPHpH05fWqyeH7HEbzRkGk7IXRbXPo=.7e396e18-4634-4efe-add5-496f605f10c5@github.com>
References: <g9W0p02Y0P5LafPHpH05fWqyeH7HEbzRkGk7IXRbXPo=.7e396e18-4634-4efe-add5-496f605f10c5@github.com>
Message-ID: <38U5ZZOurYM8Uy6dx4PR8FtfpYnHULfRKW5OXwUeEww=.ba6b82b5-cb48-4469-8769-4033dfb382c9@github.com>

On Tue, 11 Apr 2023 23:38:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test TraceVirtualThreadLocals verifies that thread locals are dumped for virtual threads. It fails when continuations are not available and virtual threads are emulated.
> 
> The test failed on linux-x86 so I just want to mark it to have green github actions results.

The test verifies how  property jdk.traceVirtualThreadLocals works to dump info. It works with virtual threads only.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13436#issuecomment-1504729526

From alanb at openjdk.org  Wed Apr 12 06:49:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Apr 2023 06:49:34 GMT
Subject: RFR: 8305734: Fixes bug in get(int, int)
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: <K-vP8vrWjuyUpU1rC5GnePZmzb5A_NCW2aiLjOI5TlY=.80309645-8031-4d82-a2be-157b78d21bdb@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

The BitSet API requires that the logical size fit in an int so I think you'll end up changing the set methods to disallow an index of MAX_VALUE.

Can you change the title of the PR to match the JBS issue? The title on the PR doesn't give any context as to what this issue is about.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1504750626

From qamai at openjdk.org  Wed Apr 12 06:56:51 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 12 Apr 2023 06:56:51 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v7]
In-Reply-To: <SYw0eLmgUE2Z0v3EI0GLBhKj7t5IMoDgiz1c_c4rEEM=.c3e918d0-bb75-4caa-ada0-56eac49d702a@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <PAuphp5Wv4xJIe8z3jCYNCHdPqP7yhbk4WX7SRnsst0=.58751569-e28b-4a68-9d49-5bebe56d7881@github.com>
 <SYw0eLmgUE2Z0v3EI0GLBhKj7t5IMoDgiz1c_c4rEEM=.c3e918d0-bb75-4caa-ada0-56eac49d702a@github.com>
Message-ID: <Y2lobfLbOnGzVujemXkq0ASi5YDtgHylLDx1fZPngM0=.b2d2cbba-f36e-4d2f-991f-345dabcde68c@github.com>

On Tue, 11 Apr 2023 17:47:56 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   special case iotaShuffle
>
> Marked as reviewed by jbhateja (Reviewer).

@jatin-bhateja @iwanowww Thanks a lot for your approvals, I will integrate the patch

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1504758215

From pminborg at openjdk.org  Wed Apr 12 07:00:46 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 12 Apr 2023 07:00:46 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v21]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <xWNlEmr8Y8sy8ujtHEgKai8VHTP6UENN8bQagJkFGlQ=.a5b40de9-bf43-4af4-93c8-9beb905dfefc@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:

 - Merge branch 'master' into PR_21_V2
 - 8305369: Issues in zero-length memory segment javadoc section
 - 8305087: MemoryLayout API checks should be more eager
 - Merge master
 - Improve code snipet
 - Update JEP number and name
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Cleanup finality
 - Merge pull request #1 from JornVernee/Fix_ULE
   
   Fix ULE when intializing LibFallback
 - ... and 26 more: https://git.openjdk.org/jdk/compare/d8af7a60...5de90878

-------------

Changes: https://git.openjdk.org/jdk/pull/13079/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=20
  Stats: 13418 lines in 270 files changed: 5099 ins; 6182 del; 2137 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From jwaters at openjdk.org  Wed Apr 12 07:12:10 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 12 Apr 2023 07:12:10 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v4]
In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
Message-ID: <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>

> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

Julian Waters has updated the pull request incrementally with four additional commits since the last revision:

 - Restore visCPP
 - Restore gcc attribute
 - Revert gcc
 - Revert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13258/files
  - new: https://git.openjdk.org/jdk/pull/13258/files/07f5c702..e63d5938

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=02-03

  Stats: 9 lines in 3 files changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13258/head:pull/13258

PR: https://git.openjdk.org/jdk/pull/13258

From jwaters at openjdk.org  Wed Apr 12 07:20:45 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 12 Apr 2023 07:20:45 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v4]
In-Reply-To: <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>
Message-ID: <opo9-JEediQaWatPUOwV1Naiio0tOzKNN8rkV5eFudk=.58fa4b23-ed08-47a9-afc2-33c28f0a3664@github.com>

On Wed, 12 Apr 2023 07:12:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Restore visCPP
>  - Restore gcc attribute
>  - Revert gcc
>  - Revert

> What is the purpose of removing `defined(_MSC_VER)` from the conditionals? Is this to allow for other compilers that similarly only ensure 4 byte alignment of the stack? If so, it would have been nice to mention that separate concern in the PR description, rather than making reviewers guess. And do such compilers actually exist? A bit of research suggests gcc (at least) maintains 16 byte alignment (and may warrant the use of -mstackrealign or other hoops). See, for example, [uTox/uTox#1304](https://github.com/uTox/uTox/issues/1304).

Admittedly I wasn't sure what the alignment specifier here was for either, but assumed that it was something that was simply required for Windows code, and since _MSC_VER is always the only compiler (for now) that can compile Windows code, the check seemed pretty pointless. It seemed logical then that even if another compiler was added to the mix Windows code would still be under said ABI restrictions, hence the removal of that conditional. I'm now no longer as certain that this is always the case and can revert those changes if that check turns out to be correct

> Is `defined(_WIN32)` really the right conditional? That's true for pretty much any Visual Studio supported target, both 32bit and 64bit. But the alignment spec is effectively a nop for 64bit platforms, so harmless.

Perhaps, since this pretty much specifies that only Windows code should be affected by the alignment (Irrespective of this change). Others might disagree here, though

> I was pretty confused by the C changes for a while, since I didn't know or had forgotten that the 32bit Windows ABI only guarantees 4 byte stack alignment, and permits "misaligned" local variables for types such as long long and double. (And I failed to find any definitive documentation for that.) Yuck!

Haha, that's Microsoft for you ;)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1504786534

From pminborg at openjdk.org  Wed Apr 12 07:21:46 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 12 Apr 2023 07:21:46 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v22]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <ElX9wdpYj1LUhgOk8IYQfjqZ20MtyfzcnQGZ_02HAMc=.61090481-c92a-4bc4-8498-19fb7a9f562a@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #2 from JornVernee/WSL_BB
   
   account for missing functional in WSL in TestByteBuffer
 - account for missing mincore on WSL in TestByteBuffer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/5de90878..6164abe8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=20-21

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Wed Apr 12 07:21:49 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 12 Apr 2023 07:21:49 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v20]
In-Reply-To: <lG1fJR2wrtGcsxOlydOvSq6QvgzatSiY7qT1cqkkX-k=.b9d3aeef-c90c-470d-96fd-405d5dbdf3c6@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <zxEBDsj3-07V4u3Exryupcrs_9mcT14cJ96TOIxWXc8=.07d9f518-7e1f-4ad7-89e0-84b0bf52ed2e@github.com>
 <lG1fJR2wrtGcsxOlydOvSq6QvgzatSiY7qT1cqkkX-k=.b9d3aeef-c90c-470d-96fd-405d5dbdf3c6@github.com>
Message-ID: <6e7bW67JaR5Lv4INrepQU7yN49yx9L4QUXqQ56EiK_g=.25fc906c-871a-4201-b06c-e173120f5204@github.com>

On Tue, 11 Apr 2023 17:48:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8305369: Issues in zero-length memory segment javadoc section
>>  - 8305087: MemoryLayout API checks should be more eager
>
> test/jdk/java/foreign/TestByteBuffer.java line 317:
> 
>> 315: 
>> 316:     @Test
>> 317:     public void testMappedSegmentAsByteBuffer() throws Throwable {
> 
> While testing something else, I noticed that this test is failing on Linux/WSL since the WSL 1 kernel does not implement `mincore`. We can simply skip the test in that case, as we already do for other tests. I've submitted a patch here: https://github.com/minborg/jdk/pull/2

Thanks for providing this patch @JornVernee

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1163721611

From alanb at openjdk.org  Wed Apr 12 07:24:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Apr 2023 07:24:33 GMT
Subject: RFR: 8305875: Test TraceVirtualThreadLocals should be run with
 continuations only
In-Reply-To: <g9W0p02Y0P5LafPHpH05fWqyeH7HEbzRkGk7IXRbXPo=.7e396e18-4634-4efe-add5-496f605f10c5@github.com>
References: <g9W0p02Y0P5LafPHpH05fWqyeH7HEbzRkGk7IXRbXPo=.7e396e18-4634-4efe-add5-496f605f10c5@github.com>
Message-ID: <POlTb7aWkbyu5BNd4srKN7SSmPF95NjyZ_G5olQjNvc=.6668b0bc-14f6-4fa5-81d2-dca0fbb5b0c0@github.com>

On Tue, 11 Apr 2023 23:38:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test TraceVirtualThreadLocals verifies that thread locals are dumped for virtual threads. It fails when continuations are not available and virtual threads are emulated.
> 
> The test failed on linux-x86 so I just want to mark it to have green github actions results.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13436#pullrequestreview-1380684805

From alanb at openjdk.org  Wed Apr 12 07:47:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Apr 2023 07:47:40 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <aLkZlsnCXbRzzku9GhAPRmvXemLy3h_Ug7Vgme7ujNM=.fa1eed04-c389-4614-b1fc-4f65de86cf7d@github.com>

On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

src/hotspot/share/include/jvm.h line 279:

> 277: 
> 278: JNIEXPORT void JNICALL
> 279: JVM_Sleep(JNIEnv *env, jclass threadClass, jlong millis, jint nanos);

I wonder if it would be simpler to just provide a single value, in nanoseconds, to the VM. That's enough for a sleep of 292 years. Windows would still need to convert to milliseconds of course but it overall would avoid sending two values down to the park code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1163750704

From duke at openjdk.org  Wed Apr 12 07:59:16 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 12 Apr 2023 07:59:16 GMT
Subject: RFR: JDK-8170945: Collectors$Partition should override more Map
 methods [v2]
In-Reply-To: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
References: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
Message-ID: <p2n6qybnLXAXyqNaqkxSbluDPgE6z5jU_8dwk4cmI2U=.d667d1ec-d69c-4816-b23e-4a348bcbea4e@github.com>

> Adds overrides for common Map operations to avoid having to allocate the entrySet for Collectors$Partition maps.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Let auto-boxing do its thing for Collectors.get(key)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13347/files
  - new: https://git.openjdk.org/jdk/pull/13347/files/97a48145..15a57ca1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13347&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13347&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13347.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13347/head:pull/13347

PR: https://git.openjdk.org/jdk/pull/13347

From duke at openjdk.org  Wed Apr 12 07:59:18 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 12 Apr 2023 07:59:18 GMT
Subject: RFR: JDK-8170945: Collectors$Partition should override more Map
 methods [v2]
In-Reply-To: <p2n6qybnLXAXyqNaqkxSbluDPgE6z5jU_8dwk4cmI2U=.d667d1ec-d69c-4816-b23e-4a348bcbea4e@github.com>
References: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
 <p2n6qybnLXAXyqNaqkxSbluDPgE6z5jU_8dwk4cmI2U=.d667d1ec-d69c-4816-b23e-4a348bcbea4e@github.com>
Message-ID: <1NPTMF6hpgIMVnkM9Dl2zYHge2nQWJdH_Ugc5nA2XU4=.c544a9be-e4b9-4edf-88f8-3346655be955@github.com>

On Wed, 12 Apr 2023 07:55:28 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Adds overrides for common Map operations to avoid having to allocate the entrySet for Collectors$Partition maps.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Let auto-boxing do its thing for Collectors.get(key)

src/java.base/share/classes/java/util/stream/Collectors.java line 1988:

> 1986:         public T get(Object key) {
> 1987:             if (key instanceof Boolean b) {
> 1988:                 return b ? forTrue : forFalse;

@stuart-marks I've removed the `booleanValue()` here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13347#discussion_r1163760887

From rgiulietti at openjdk.org  Wed Apr 12 08:48:33 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 12 Apr 2023 08:48:33 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v2]
In-Reply-To: <TnsK7PLQEtOQ4INryFH79SyrqmNmAt6NjfEN3mZVTls=.88e001aa-4ddb-4aed-9079-4bdbfb53ce56@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <dg6qtk5ave9VNr7E0Jf7nHBB9OgkJdJq-A_17OsP094=.1113df8d-50f7-4baa-a8e8-8aef1ee61ac0@github.com>
 <OQI29CEXN1M-5u_8Y7SLcxMC-SEO3OwOoeL-gunFNlE=.2b59085c-72ba-4a11-852f-57528a390819@github.com>
 <lwI-yTh0L8dp1xIim6Qkg7xxQaOcWDAKq7qWdUm9NXQ=.a092f238-071c-40e1-8732-5b16ee0f88c3@github.com>
 <TnsK7PLQEtOQ4INryFH79SyrqmNmAt6NjfEN3mZVTls=.88e001aa-4ddb-4aed-9079-4bdbfb53ce56@github.com>
Message-ID: <h9_Ssa9gMZovYiurx65RDUU6R4LoZZJQ4iI3yVmPtdQ=.0bf72af5-3933-4c5c-86fe-ba5c442ff042@github.com>

On Tue, 11 Apr 2023 20:42:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The choice of multi-character delimiter is deliberate, to show that the regex really absorbs all the delimiter characters.
>> The `":+"` examples are followed by the `"o"` examples, where the delimiters are single characters.
>
> I understood the value of `:+` case.
> I found reading the single "o" as a delimiter is not intuitive or easy to parse because it looks like the the strings that are being delimited, not a delimiter.

The `"o"` examples are extended versions of the ones "inherited" from the existing `split(String,int)` variant.
I have no objections in replacing the examples with something else, but at some point there must be a less intuitive example to illustrate the full generality of the method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1163819102

From mdoerr at openjdk.org  Wed Apr 12 09:10:43 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 12 Apr 2023 09:10:43 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v12]
In-Reply-To: <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com>
Message-ID: <7kFdmkpwgMes1T3aGrG6-rE5ZCAhTxeBseoh3SkN1M4=.2fcf70ea-88d5-4138-9dca-2dfcdbb410e1@github.com>

On Tue, 11 Apr 2023 21:09:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct mapping and test of ppc64

Works on PPC64 Big Endian, now. However, little Endian fails:
org.opentest4j.AssertionFailedError: Mismatch PPC64 == PPC64 vs isPPC64 ==> expected: <true> but was: <false>
	at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
	at org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
	at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152)
	at ArchTest.isArch(ArchTest.java:99)
...
System property os.arch: "ppc64le", Architecture.current(): "PPC64"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1504925182

From duke at openjdk.org  Wed Apr 12 09:27:16 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 12 Apr 2023 09:27:16 GMT
Subject: RFR: 8240567: SystemModulesPlugin: Keep stack clean
Message-ID: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>

This refs [https://bugs.openjdk.org/browse/JDK-82405679](8240567). Does NOT fix it, but cleanup `SystemModulesPlugin` a bit to ease working on the bug itself.

Although this change is rather small, I think, it's good to have a "more clean" SystemModulesPlugin available.

-------------

Commit messages:
 - Keep stack clean

Changes: https://git.openjdk.org/jdk/pull/13442/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13442&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8240567
  Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13442.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13442/head:pull/13442

PR: https://git.openjdk.org/jdk/pull/13442

From alanb at openjdk.org  Wed Apr 12 09:45:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Apr 2023 09:45:33 GMT
Subject: RFR: 8240567: SystemModulesPlugin: Keep stack clean
In-Reply-To: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>
References: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>
Message-ID: <3t_QZLhE7QrNeY5GqLY1JfvFDvE8hDUprHii759p1_4=.b83f7e9c-15dc-49ac-8589-3ab3ec8b0321@github.com>

On Wed, 12 Apr 2023 09:18:13 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> This refs [https://bugs.openjdk.org/browse/JDK-82405679](8240567). Does NOT fix it, but cleanup `SystemModulesPlugin` a bit to ease working on the bug itself.
> 
> Although this change is rather small, I think, it's good to have a "more clean" SystemModulesPlugin available.

I think you've got the wrong JBS issue, JDK-8240567 is about changing the SystemModulesPlugin to avoid the 64k limit on method size.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13442#issuecomment-1504976533

From duke at openjdk.org  Wed Apr 12 10:08:33 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 12 Apr 2023 10:08:33 GMT
Subject: RFR: 8240567: SystemModulesPlugin: Keep stack clean
In-Reply-To: <3t_QZLhE7QrNeY5GqLY1JfvFDvE8hDUprHii759p1_4=.b83f7e9c-15dc-49ac-8589-3ab3ec8b0321@github.com>
References: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>
 <3t_QZLhE7QrNeY5GqLY1JfvFDvE8hDUprHii759p1_4=.b83f7e9c-15dc-49ac-8589-3ab3ec8b0321@github.com>
Message-ID: <1J5JxWpISPgnLMhXCwFO5X4u9F0ayc_hOEzG2alJ_24=.a81457cb-d20f-476b-a7f4-047d1feec87f@github.com>

On Wed, 12 Apr 2023 09:43:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think you've got the wrong JBS issue, JDK-8240567 is about changing the SystemModulesPlugin to avoid the 64k limit on method size.

For me, it's the correct one. I was not sure which one to link. I can also drop the reference.

More background: I am currently trying to get https://github.com/openjdk/jdk/pull/10704 finished and saw that improvement. Just in case, I don't manage to get that PR finished, I wanted to keep my small contribution alive. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13442#issuecomment-1505007143

From lucy at openjdk.org  Wed Apr 12 11:32:43 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 12 Apr 2023 11:32:43 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v10]
In-Reply-To: <gGsAtNpsCBDC_6K6wrgzM3jdMFbOhLl4uKdkma7v-mY=.2eaf5245-84ad-4a44-975f-7a7eb5be4c79@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <i2siBlNCDjWM4dMLLyPL0c8SFGFTODNdJpKTBIxhJy4=.a9b40975-0efd-49b3-b81b-dbc67c58edbb@github.com>
 <mBvcRGaKW5CD2m2iTgeBXJ9S-xkgwdFdkgx5fkCNoVI=.0e483496-7ce0-45e9-9a3c-af79c0c20b95@github.com>
 <gGsAtNpsCBDC_6K6wrgzM3jdMFbOhLl4uKdkma7v-mY=.2eaf5245-84ad-4a44-975f-7a7eb5be4c79@github.com>
Message-ID: <qlw7HUDkrTDgEqpZSJmah0SEu3TEGw9EubDqDO9UX-8=.8dc39fe4-ccad-43bd-9077-73355dc1c7da@github.com>

On Wed, 12 Apr 2023 03:44:45 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Another remark: Old JDK on s390 used "os.arch = zArch_64", current one "os.arch = s390x". @offamitkumar: You probably want to take a look.

zArch_64 is not relevant/not used in the OpenJDK port to IBM System z. As noted elsewhere in the PR, it's the architecture name that was used in the initial, proprietary port by SAP. I found just one occurrence of the string in the head revision, and that was in test/lib/jdk/test/lib/Platform.java.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1505110504

From james.laskey at oracle.com  Wed Apr 12 13:14:11 2023
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 12 Apr 2023 13:14:11 +0000
Subject: String Template reviews
Message-ID: <0DEC397B-DC86-4B68-A099-023CE2DD58E8@oracle.com>

As we head toward PTT for JEP 430 String Templates (Preview) it would be nice to get some final reviews of the following;

Implementation API CSR https://bugs.openjdk.org/browse/JDK-8286021
Implementation PR https://github.com/openjdk/jdk/pull/10889

Thank you.

? Jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230412/ef53d36a/attachment.htm>

From msheppar at openjdk.org  Wed Apr 12 13:37:35 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 12 Apr 2023 13:37:35 GMT
Subject: RFR: JDK-8295859 Update Manual Test Groups [v3]
In-Reply-To: <ofbrPO0fX7osDzj3VpcVkN-EIFGe8GTqg14pjTcDxBI=.faa939e1-afe7-40a6-8291-367900dcd54d@github.com>
References: <A8iSpxnkw9ogc19QG-cGFTM4Xhe7vpX62WJ-c632KcA=.8a238ad1-661a-4809-a2da-b995627623cc@github.com>
 <ofbrPO0fX7osDzj3VpcVkN-EIFGe8GTqg14pjTcDxBI=.faa939e1-afe7-40a6-8291-367900dcd54d@github.com>
Message-ID: <3ZTuHyR0RpmJvLBRQZOqA0o3MfzTKKfkG1tuI5ArIiU=.14649b88-5d42-40d5-8eff-c348d921901d@github.com>

On Tue, 11 Apr 2023 22:06:30 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> The purpose of this task is to add the difference between -manual jdk_core and jdk_core_manual to the jdk_core_manual test goal. Furthermore, in order to streamline the manual test execution process, a new test group called jdk_core_manual_human has been created for manual tests that demand extra preparation or test input.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed jdk_core_manual to jdk_core_manual_interactive

Marked as reviewed by msheppar (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12840#pullrequestreview-1381338834

From ecki at zusammenkunft.net  Wed Apr 12 15:40:29 2023
From: ecki at zusammenkunft.net (Bernd)
Date: Wed, 12 Apr 2023 17:40:29 +0200
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide
 locale insensitive alternative
In-Reply-To: <CANSoFxtXHr7mN9ishM1QT5JrY-3FGsKv0P5r832wugcktafmWw@mail.gmail.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <233035587.34407903.1681244473362.JavaMail.zimbra@univ-eiffel.fr>
 <CAJL5A3njdxe4ctJHk1_pWCtqJFREBNjGJ2Gj-OXocAdiX+2O5w@mail.gmail.com>,
 <CANSoFxtXHr7mN9ishM1QT5JrY-3FGsKv0P5r832wugcktafmWw@mail.gmail.com>
Message-ID: <BDFD5B7D-8CB1-9D4B-A623-27E2C3EAD484@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230412/cd2a3037/attachment.htm>

From liach at openjdk.org  Wed Apr 12 15:55:31 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Apr 2023 15:55:31 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v56]
In-Reply-To: <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>
Message-ID: <5QkOHvuy9d8hQXPe6ETbT6fmE1No5e47lBCukDnNldY=.21ede21a-3340-47da-b69e-9322b7b9adc0@github.com>

On Sat, 8 Apr 2023 15:51:36 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.

A few comments on the API/CSR's specification. Thanks for uploading the Javadocs.

src/java.base/share/classes/java/lang/StringTemplate.java line 351:

> 349:      * then it is returned unchanged.
> 350:      */
> 351:     static StringTemplate combine(StringTemplate... stringTemplates) {

Sorry for a late mention, but I believe this method and its List variant are better named `concat` instead: `concat` indicates an explicitly ordered operation (String, Stream, AffineTransform), while `combine` is usually unordered (IntSummaryStatistics, CompletableFuture.thenCombine, Collector.combiner). Using `concat` also brings `String` and `StringTemplate` closer.

All examples come from using the search box with `concat` and `combine` in the code review Javadoc copy: https://cr.openjdk.org/~jlaskey/templates/docs/api/java.base/java/util/FormatProcessor.html

src/java.base/share/classes/java/lang/StringTemplate.java line 522:

> 520:      * {@link String};
> 521:      * {@snippet :
> 522:      * Processor<JSONObject, RuntimeException> jsonProcessor = st -> new JSONObject(st.interpolate());

This isn't quite a good example; it defeats the point of string templates, that injection attacks like `}, "another_key": {` can still happen with JSON.

src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 112:

> 110:         }
> 111:         interpolateMH = MethodHandles.filterArguments(interpolateMH, 0, components);
> 112:         mt = MethodType.methodType(String.class, StringTemplateImpl.class);

This MethodType can be stored in a static final field than created every time on the fly. Don't know if JIT compiler can inline this statement. Same fore that `List.class, StringTemplateImpl.class` type below.

src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 109:

> 107:      * @param lookup          method lookup
> 108:      * @param name            method name
> 109:      * @param type            method type

Maybe mention that the name is ignored, and the type must be convertible from `(String[], Object[])StringTemplate`? The specification says "fragments list" and "values list", which are more accurately described as arrays.

Also, does "large" string template mean there are more than 250~ fragments that the bootstrap method arguments can't fit, or does it mean dynamic number of fragments? Might be worth mentioning that as well.

-------------

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1381542020
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1164313718
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1164324857
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1164284857
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1164278200

From eliu at openjdk.org  Wed Apr 12 16:09:41 2023
From: eliu at openjdk.org (Eric Liu)
Date: Wed, 12 Apr 2023 16:09:41 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v6]
In-Reply-To: <mvjXG43i2H0ULxXam6DzZR6SPrVjyth_x4Fu7CTjmE0=.04f5e64d-54bd-4556-bc46-212552526853@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <mvjXG43i2H0ULxXam6DzZR6SPrVjyth_x4Fu7CTjmE0=.04f5e64d-54bd-4556-bc46-212552526853@github.com>
Message-ID: <4vt3o6jU1_qUlYB4YtkXOUmG8Gi9NzRUHXjYqboYlPU=.3edc8876-bf2a-40a0-bb3e-3c5ea2aea3d5@github.com>

On Tue, 4 Apr 2023 13:46:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
>> 
>> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
>> 
>> Please take a look and have some reviews. Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   style

src/hotspot/share/opto/vectorIntrinsics.cpp line 1953:

> 1951:   Node* v1 = unbox_vector(argument(3), vbox_type, elem_bt, num_elem);
> 1952:   Node* v2 = unbox_vector(argument(4), vbox_type, elem_bt, num_elem);
> 1953:   if (v1 == NULL || v2 == NULL) {

nullptr is more common.

src/hotspot/share/opto/vectornode.cpp line 1999:

> 1997:   // (VectorSlice X Y 0) => X
> 1998:   // (VectorSlice X Y VLENGTH) => Y
> 1999:   if (origin->is_con(0)) {

is_con(0) is pre defined as TypeInt::ZERO.

src/hotspot/share/opto/vectornode.cpp line 2001:

> 1999:   if (origin->is_con(0)) {
> 2000:     return in(1);
> 2001:   } else if (origin->is_con(Matcher::vector_length(this))) {

If they were the same, length() looks simple.
Suggestion:

  } else if (origin->is_con(length())) {

src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 635:

> 633:     }
> 634: 
> 635:     @ForceInline

May I ask why `forceInline` here is necessary?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1164311234
PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1164328793
PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1164346771
PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1164348507

From bhuang at openjdk.org  Wed Apr 12 16:11:43 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 12 Apr 2023 16:11:43 GMT
Subject: Integrated: JDK-8295859 Update Manual Test Groups
In-Reply-To: <A8iSpxnkw9ogc19QG-cGFTM4Xhe7vpX62WJ-c632KcA=.8a238ad1-661a-4809-a2da-b995627623cc@github.com>
References: <A8iSpxnkw9ogc19QG-cGFTM4Xhe7vpX62WJ-c632KcA=.8a238ad1-661a-4809-a2da-b995627623cc@github.com>
Message-ID: <XU5-UQoo5g_-ac421Pounkl2JZWsQKEuN-sM-BKctu8=.be58229a-c404-4066-bc36-ce35bb7092c9@github.com>

On Thu, 2 Mar 2023 21:34:28 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> The purpose of this task is to add the difference between -manual jdk_core and jdk_core_manual to the jdk_core_manual test goal. Furthermore, in order to streamline the manual test execution process, a new test group called jdk_core_manual_human has been created for manual tests that demand extra preparation or test input.

This pull request has now been integrated.

Changeset: 87017b51
Author:    Bill Huang <bhuang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87017b5199522bb26f0225b60fbbc00df255ad2a
Stats:     20 lines in 1 file changed: 11 ins; 4 del; 5 mod

8295859: Update Manual Test Groups

Reviewed-by: msheppar

-------------

PR: https://git.openjdk.org/jdk/pull/12840

From mchhipa at openjdk.org  Wed Apr 12 16:43:27 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 12 Apr 2023 16:43:27 GMT
Subject: RFR: 8305904: java/lang/Character,
 java/lang/String and java/text/Normalizer tests read the unicode data files
 from src directories.
Message-ID: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>

Following tests read the unicode data files (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, these files should be in test directories. No source code is using these files. Only tests are using these files. Tests are :
java/lang/Character/CharPropTest.java
java/lang/Character/CheckProp.java
java/lang/Character/CheckScript.java
java/lang/Character/CheckUnicode.java
java/lang/Character/UnicodeBlock/CheckBlocks.java
java/lang/Character/UnicodeCasingTest.java
java/lang/String/SpecialCasingTest.java
java/lang/String/UnicodeCasingTest.java
java/text/Normalizer/ConformanceTest.java

-------------

Commit messages:
 - JDK-8305904: java/lang/Character, java/lang/String and java/text/Normalizer tests read the unicode data files from src directories.

Changes: https://git.openjdk.org/jdk/pull/13447/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13447&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305904
  Stats: 1 line in 13 files changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13447.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13447/head:pull/13447

PR: https://git.openjdk.org/jdk/pull/13447

From bchristi at openjdk.org  Wed Apr 12 17:07:24 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 12 Apr 2023 17:07:24 GMT
Subject: RFR: 8305762: FileInputStream and FileOutputStream implSpec should be
 corrected or removed
Message-ID: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>

With the removal of the AltFinalizer mechanism from `FileInputStream` and `FileOutputStream` in [JDK-8192939](https://bugs.openjdk.org/browse/JDK-8192939), this portion of the Implementation Requirement in the class JavaDoc is no longer true:

> If this FileOutputStream has been subclassed and the close() method has been overridden, the close() method will be called when the FileInputStream is unreachable."

The class doc, and the doc for close(), are updated to correctly reflect current behavior, and guidance for subclasses is clarified.

-------------

Commit messages:
 - remove blank line
 - Clarify that finalization isn't used for cleanup for FIS/FOS, and that Cleaner should be used instead.

Changes: https://git.openjdk.org/jdk/pull/13437/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13437&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305762
  Stats: 28 lines in 2 files changed: 0 ins; 12 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/13437.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13437/head:pull/13437

PR: https://git.openjdk.org/jdk/pull/13437

From rriggs at openjdk.org  Wed Apr 12 17:31:49 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Apr 2023 17:31:49 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v13]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Fixed isPPC64().
  Consolidated switch cases in ArchTest.
  Moved mapping of build TARGET_OS and TARGET_CPU to the build
  to avoid multiple mappings in more than one place.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/71135e3b..0cd6ce70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=11-12

  Stats: 60 lines in 5 files changed: 19 ins; 22 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

PR: https://git.openjdk.org/jdk/pull/13357

From rriggs at openjdk.org  Wed Apr 12 17:44:38 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Apr 2023 17:44:38 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v2]
In-Reply-To: <8-pc62MG2Qcj0reM0zl85Kunw2rZlQOMVZHyjKKSSSY=.4af17266-9d26-42e3-a357-fcda22f1fd5b@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
 <KR4jLIdgm_Y49RQkIJ9uNHqemm01aE81GRBVz6XznJ8=.c2e99c6d-2fb2-44ce-b23d-6461fac68ff4@github.com>
 <3Im4RP5-AmauuIjCVgA3V4h0HellqriqIlbTSjXjrWU=.a3b7c98f-276a-423a-8d48-c3415633b2cc@github.com>
 <_gJmYty5eyRbpGo3AIlFE4HDkmGWAWPsAOqwJri3mqo=.70b5927c-2be5-484c-98f4-f21933166c55@github.com>
 <8-pc62MG2Qcj0reM0zl85Kunw2rZlQOMVZHyjKKSSSY=.4af17266-9d26-42e3-a357-fcda22f1fd5b@github.com>
Message-ID: <MGPD9mADC-45XPxBYAMM6nRIPJ3oKAwwPcOofSkzmiw=.b54f5929-1992-4089-9a6b-743bd2643a2d@github.com>

On Fri, 24 Mar 2023 19:28:57 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Meant that you should verify that something like this, which just add a little padding, doesn't regress with your changes: 
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>     .appendLiteral("Year:")
>>     .padNext(5)
>>     .appendValue(ChronoField.YEAR)
>>     .toFormatter();
>> ... 
>> dtf.format(LocalDateTime.now());
>> 
>> And similar for effectively no padding (`.padNext(4)` in the above example). As this API might often be used to ensure short 2-4 char fields are correctly padded I think it's important that we're not adding overhead to such use cases.
>
> Added benchmark for this

Special casing for len == 0 and keeping the existing buf.insert for len == 1 would avoid object creation except when it would improve performance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1164453452

From rriggs at openjdk.org  Wed Apr 12 17:44:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Apr 2023 17:44:47 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v3]
In-Reply-To: <5e1c0aIHmpueO2gPCS4suJh3Jo0RVhWpSkUnMmnM2uw=.7592dbee-3c4e-4ba7-8c7c-9184fa3ddcbe@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <5e1c0aIHmpueO2gPCS4suJh3Jo0RVhWpSkUnMmnM2uw=.7592dbee-3c4e-4ba7-8c7c-9184fa3ddcbe@github.com>
Message-ID: <P6G78Sj0a0YnAFiHgvqtfRZGN773tdq1DEdwVwLeubA=.fe8bdf0c-b00d-4b65-969d-ad70385a58a3@github.com>

On Mon, 10 Apr 2023 14:01:53 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into dtfb
>  - 8300818: Add benchmark
>  - 8300818: Add benchmark
>  - Revert irrelevant change
>  - Merge branch 'master' into dtfb
>  - Improve padding of DateTimeFormatter

test/micro/org/openjdk/bench/java/time/format/DateTimeFormatterBench.java line 148:

> 146:         return YEAR_FORMATTER.format(now);
> 147:     }
> 148: 

There benchmarks are run 4 time each because of the @Param that are defined for the pre-existing tests.
I don't know if jmh can be annotated to ignore the params; but to avoid wasting resources create a separate jmh source file for thees new tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1164450924

From liach at openjdk.org  Wed Apr 12 17:46:47 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Apr 2023 17:46:47 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v56]
In-Reply-To: <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>
Message-ID: <P_9HK0RpcWiS9WgNSxyfVYk506xRzIdPZz8KJk0Kz8E=.fe2290a7-d475-4b6d-8293-ba7930196a0d@github.com>

On Sat, 8 Apr 2023 15:51:36 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.

Just curious, in what scenario can `StringTemplateTree.getProcessor()` evaluate to `null`, when `"{variable}"` is not a valid literal without a `StringTemplate.RAW.` qualifier?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10889#issuecomment-1505686329

From rriggs at openjdk.org  Wed Apr 12 17:47:21 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Apr 2023 17:47:21 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v12]
In-Reply-To: <7kFdmkpwgMes1T3aGrG6-rE5ZCAhTxeBseoh3SkN1M4=.2fcf70ea-88d5-4138-9dca-2dfcdbb410e1@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com>
 <7kFdmkpwgMes1T3aGrG6-rE5ZCAhTxeBseoh3SkN1M4=.2fcf70ea-88d5-4138-9dca-2dfcdbb410e1@github.com>
Message-ID: <lgH5VqlldxKdPQ7Q3wZo1zQgOzdaRLcfLHqrZBMeURs=.782b0827-c6e2-472a-b562-e319b9531cca@github.com>

On Wed, 12 Apr 2023 09:07:34 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct mapping and test of ppc64
>
> Works on PPC64 Big Endian, now. However, little Endian fails:
> STARTED    ArchTest::isArch '[6] PPC64, false'
> org.opentest4j.AssertionFailedError: Mismatch PPC64 == PPC64 vs isPPC64 ==> expected: <true> but was: <false>
> 	at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
> 	at org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
> 	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
> 	at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152)
> 	at ArchTest.isArch(ArchTest.java:99)
> ...
> System property os.arch: "ppc64le", Architecture.current(): "PPC64"

@TheRealMDoerr Thanks for the ppc64 feedback and testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1505685254

From jvernee at openjdk.org  Wed Apr 12 17:54:44 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Apr 2023 17:54:44 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v20]
In-Reply-To: <pDBuUHAi0dohRotzcgIRG1DafzyO85pqu2sGrFkL_Nw=.8b02b998-b013-495f-a6a6-2d0247fb667e@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <zxEBDsj3-07V4u3Exryupcrs_9mcT14cJ96TOIxWXc8=.07d9f518-7e1f-4ad7-89e0-84b0bf52ed2e@github.com>
 <pDBuUHAi0dohRotzcgIRG1DafzyO85pqu2sGrFkL_Nw=.8b02b998-b013-495f-a6a6-2d0247fb667e@github.com>
Message-ID: <MCUQ22XpqV9VFRosFaLdBm0nKyr3qCg0wQqxyjVJzcI=.27c0be1d-2fa3-4208-9046-cecfebabfa66@github.com>

On Tue, 11 Apr 2023 17:59:32 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8305369: Issues in zero-length memory segment javadoc section
>>  - 8305087: MemoryLayout API checks should be more eager
>
> src/hotspot/share/prims/jvm.cpp line 3473:
> 
>> 3471: 
>> 3472: JVM_LEAF(jboolean, JVM_IsForeignLinkerSupported(void))
>> 3473:   return ForeignGlobals::has_port() ? JNI_TRUE : JNI_FALSE;
> 
> On naming:  I find `has_port()` confusing. Why don't you simply call VM counterpart `is_foreign_linker_supported`? Alternative ideas: `is_supported()`, `has_native_support()`.

Thanks for the review.

I've created a patch for changing the name to `is_foreign_linker_supported` here: https://github.com/minborg/jdk/pull/3

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1164463475

From jlaskey at openjdk.org  Wed Apr 12 18:09:48 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 12 Apr 2023 18:09:48 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v56]
In-Reply-To: <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>
Message-ID: <HYAv-m_6aRPQs7ierBE4Z86pw2n2pYT65tVoLHN-tgI=.aca4977f-fdb9-4e95-a928-48e8a8d19d1f@github.com>

On Sat, 8 Apr 2023 15:51:36 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.

This is a remnant from when the processor was not required.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10889#issuecomment-1505712211

From mdoerr at openjdk.org  Wed Apr 12 18:20:45 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 12 Apr 2023 18:20:45 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v13]
In-Reply-To: <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
Message-ID: <-7iBud-60uLA3dCL1rKYgWjUok8t7rcMA8XDD2P9RoM=.606c361c-f677-4729-9537-e66c1e1c3ff3@github.com>

On Wed, 12 Apr 2023 17:31:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed isPPC64().
>   Consolidated switch cases in ArchTest.
>   Moved mapping of build TARGET_OS and TARGET_CPU to the build
>   to avoid multiple mappings in more than one place.

Thanks! PPC64 parts look good and the test has passed on both endianness versions.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1381866371

From jlaskey at openjdk.org  Wed Apr 12 19:02:22 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 12 Apr 2023 19:02:22 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:

 - Merge branch 'master' into 8285932
 - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
 - Clean up Error handling
 - Recommended changes
 - RuntimeException is the only exception type that can is deduced from a lambda.
 - Update combine example
 - Merge branch 'master' into 8285932
 - Update StringTemplate.combine javadoc
 - Requested review changes.
 - Clean up list construction
 - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=56
  Stats: 9261 lines in 75 files changed: 9162 ins; 24 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From roger.riggs at oracle.com  Wed Apr 12 20:26:50 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 12 Apr 2023 16:26:50 -0400
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
Message-ID: <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>

Hi,

The status quo takes a balance between trying do the right thing and 
creating a headache for lots of developers.
Deprecating the existing methods would cause lots of warnings and 
provide little actual improvement.
Except in a few locales, the output would be the same as today.
If you're working in a locale where it matters, it has become habit to 
use Locale.root everywhere.

The most positive suggestion from the January thread [1] was to fix the 
uses in the JDK in small batches and carefully review each to make sure 
there are no unintended consequences. Even replacing the existing uses 
with a new method requires the same cautious approach.? Adding new 
methods was also mentioned.

The topics of deprecation and a new API should be treated separately, 
they have different costs and benefits.

As observed, coming to agreement on the naming is likely the hard part.
You might want to start a discussion about that; but it may be too soon 
for a PR.

Regards, Roger



On 4/11/23 4:02 PM, Glavo wrote:
> Hi everyone,
>
> A few months ago, I discussed in this mailing list[1] whether 
> toLowerCase()/toUpperCase()?should be deprecated.
> At that time, I received some approval and no one opposed the 
> idea.?Therefore, I thought it might be time
> to continue advancing this work, so I created a PR[2] for this.
>
> This PR is still a draft, welcome to discuss it there.
>
> I don't have much experience in contributing to OpenJDK yet, so I also 
> hope to get the help of experienced
> contributors (such as creating CSR). Thanks!
>
> Glavo
>
> [1] 
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html
> [2] https://github.com/openjdk/jdk/pull/13434


From aturbanov at openjdk.org  Wed Apr 12 20:54:02 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 12 Apr 2023 20:54:02 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
Message-ID: <FaAsa2tK9mqgLaPcRVKNTaAWdKkzr37TmI1bcVH6Eps=.a575aa4b-bc90-4947-8bab-7dde4b180575@github.com>

On Wed, 12 Apr 2023 19:02:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

src/java.base/share/classes/java/lang/runtime/Carriers.java line 286:

> 284:          */
> 285:         MethodHandle constructor(CarrierShape carrierShape) {
> 286:             int longCount = carrierShape.longCount();

`longCount`/`intCount` seems unused in this method

src/java.base/share/classes/java/lang/runtime/Carriers.java line 369:

> 367:          * Cache mapping {@link MethodType} to previously defined {@link CarrierElements}.
> 368:          */
> 369:         private static Map<MethodType, CarrierElements>

Can it be made `final` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1164641033
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1164640633

From aturbanov at openjdk.org  Wed Apr 12 21:02:00 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 12 Apr 2023 21:02:00 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
Message-ID: <nctaH1CV9Q41hfLZwj6Z1hSrVN_gpBdZ_n4XBcyW0rY=.da4f802d-2626-4c0f-aeac-4bbedbf44223@github.com>

On Wed, 12 Apr 2023 19:02:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

src/java.base/share/classes/jdk/internal/access/JavaTemplateAccess.java line 28:

> 26: package jdk.internal.access;
> 27: 
> 28: import java.lang.invoke.MethodHandle;

Couple of unused imports

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1164647158

From eirbjo at gmail.com  Wed Apr 12 21:11:50 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Wed, 12 Apr 2023 23:11:50 +0200
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
Message-ID: <CA+pBWhsevCcd+xOHD1SOT+5q+H2CXAc2ULz8gVNgVGsU9V8Geg@mail.gmail.com>

On Wed, Apr 12, 2023 at 10:27?PM Roger Riggs <roger.riggs at oracle.com> wrote:

> Hi,
>
> The status quo takes a balance between trying do the right thing and
> creating a headache for lots of developers.
> Deprecating the existing methods would cause lots of warnings and
> provide little actual improvement.
>

It is a matter of fact that case conversion is a locale sensitive
operation. By not deprecating these methods, we can pretend it isn't so,
but that does not make the problem go away, it just hides it.

Except in a few locales, the output would be the same as today.
> If you're working in a locale where it matters, it has become habit to
> use Locale.root everywhere.
>

In a globalized world, the developer's locale and the user's locale are not
necessarily, probably usually, not the same.

Case in point, where a developer in Australia is bitten by this, having
customers in Turkey:

https://mattryall.net/blog/the-infamous-turkish-locale-bug

Bug descriptions and blogs like these are plentiful and easy to find.


> The most positive suggestion from the January thread [1] was to fix the
> uses in the JDK in small batches and carefully review each to make sure
> there are no unintended consequences.


The current draft PR suggests to deprecate and
add @SuppressWarnings("deprecated"), then handle the @SuppressWarnings in
follow-up PRs. This could of course be done in the opposite order.


> The topics of deprecation and a new API should be treated separately,
> they have different costs and benefits.
>

The draft PR now focuses on deprecation only:

https://github.com/openjdk/jdk/pull/13434
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230412/ab82ecf5/attachment.htm>

From duke at openjdk.org  Wed Apr 12 21:47:47 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 12 Apr 2023 21:47:47 GMT
Subject: Integrated: 8303923: ZipOutStream::putEntry should include an apiNote
 to indicate that the STORED compression method should be used when
 writing directory entries
In-Reply-To: <MxdaGLimDdbjNWSyo6yfkpt0KjEn1WTulCzSPmhWtyQ=.96687fb2-6334-4240-ae83-fc3d6cfe613a@github.com>
References: <MxdaGLimDdbjNWSyo6yfkpt0KjEn1WTulCzSPmhWtyQ=.96687fb2-6334-4240-ae83-fc3d6cfe613a@github.com>
Message-ID: <8aYaNe8N_1-ZTGQuwKTP9UcHKL_QmKq_iARvyLr_d0E=.4d21dfaf-6984-4a85-b69b-a453cfba26d8@github.com>

On Tue, 7 Mar 2023 07:46:25 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> ZipOutputStream currently writes directory entries using the DEFLATED compression method. This does not strictly comply with the APPNOTE.TXT specification and is also about 10x slower than using the STORED compression method.
> 
> Because of these concerns, `ZipOutputStream.putNextEntry` should be updated with an `@apiNote` recommending
> the use of the STORED compression method for directory entries.
> 
> Suggested CSR in the first comment.

This pull request has now been integrated.

Changeset: 425ef068
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/425ef0685c584abec80454fbcccdcc6db6558f93
Stats:     16 lines in 1 file changed: 15 ins; 0 del; 1 mod

8303923: ZipOutStream::putEntry should include an apiNote to indicate that the STORED compression method  should be used when writing directory entries

Reviewed-by: lancea, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12899

From pminborg at openjdk.org  Thu Apr 13 06:36:51 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Apr 2023 06:36:51 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v23]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <rEPfAjIskvPNkKDMx3-YNl36ZCdBs3WpD3rMJjWkyi0=.d89033ec-d1b7-4ded-a8f2-6171283b049a@github.com>

> API changes for the FFM API (third preview)
> 
> ### Specdiff
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> ### Javadoc
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
> 
> ### Tests
> 
> - [X] Tier1
> - [X] Tier2
> - [ ] Tier3
> - [ ] Tier4
> - [ ] Tier5
> - [ ] Tier6

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
   
   rename has_port
 - rename has_port

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/6164abe8..91f43d13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=21-22

  Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From eirbjo at gmail.com  Thu Apr 13 06:40:27 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 13 Apr 2023 08:40:27 +0200
Subject: Question: Review process of release notes
Message-ID: <CA+pBWhvoei=fmraNUn-ehjHe5ojRaOEp+Ypr6cdB0wS_vyr+2Q@mail.gmail.com>

Hi,

My understanding of the review process for release notes is a bit sketchy,
I could need some clarification.

Consider my release note for JDK-8205129 Remove java.lang.Compiler as an
example:

https://bugs.openjdk.org/browse/JDK-8304459

The PR is approved and integrated and the issue Resolved as Fixed. However,
the Release Note sub-task is still New and Unresolved

Questions:

- Is the Release note issue considered implicitly reviewed as part of the
PR process?
- Now that the issue is integrated, what should I do with the Release Note
issue? Mark it as fixed in 21 and resolve it?
- The referenced release note does not appear in https://jdk.java.net/21/,
that's perhaps because the JBS issue is not resolved?

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230413/0718316b/attachment.htm>

From qamai at openjdk.org  Thu Apr 13 07:05:54 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 13 Apr 2023 07:05:54 GMT
Subject: Integrated: 8304450: [vectorapi] Refactor VectorShuffle implementation
In-Reply-To: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
Message-ID: <1_1SPocmj-NTrY9ZZ35vVCt7Gc4dVtZVIxeyJwXrBj0=.66358c02-6efa-4d04-9e8b-3ceb12c6af66@github.com>

On Sun, 19 Mar 2023 13:04:19 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> 
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {external_word}
>     vpackusdw %xmm0,%xmm0,%xmm0
>     vpackuswb %xmm0,%xmm0,%xmm0
>     vpmovsxbd %xmm0,%xmm3
>     vpcmpgtd %xmm3,%xmm1,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fc2acb4e0d8
>     vpmovzxbd %xmm0,%xmm0
>     vpermd %ymm2,%ymm0,%ymm0
>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>     vmovdqu %xmm0,0x10(%r10)
> 
>     After:
>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>     vmovdqu 0x10(%r10),%xmm2
>     vpxor  %xmm0,%xmm0,%xmm0
>     vpcmpgtd %xmm2,%xmm0,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fa818b27cb1
>     vpermd %ymm1,%ymm2,%ymm0
>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>     vmovdqu %xmm0,0x10(%r10)
>     
> Please take a look and leave reviews. Thanks a lot.

This pull request has now been integrated.

Changeset: e846a1d7
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e846a1d70043f7b57ae76847e85e5426c86539a5
Stats:     3690 lines in 64 files changed: 1615 ins; 1169 del; 906 mod

8304450: [vectorapi] Refactor VectorShuffle implementation

Reviewed-by: psandoz, xgong, jbhateja, vlivanov

-------------

PR: https://git.openjdk.org/jdk/pull/13093

From david.holmes at oracle.com  Thu Apr 13 07:18:05 2023
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 Apr 2023 17:18:05 +1000
Subject: Question: Review process of release notes
In-Reply-To: <CA+pBWhvoei=fmraNUn-ehjHe5ojRaOEp+Ypr6cdB0wS_vyr+2Q@mail.gmail.com>
References: <CA+pBWhvoei=fmraNUn-ehjHe5ojRaOEp+Ypr6cdB0wS_vyr+2Q@mail.gmail.com>
Message-ID: <b08b02ff-2c10-a8bb-beac-428510d9c05f@oracle.com>

Hi Eirik,

https://openjdk.org/guide/#release-notes

HTH

David

On 13/04/2023 4:40 pm, Eirik Bj?rsn?s wrote:
> Hi,
> 
> My understanding of the review process for release notes is a bit 
> sketchy, I could need some clarification.
> 
> Consider my release note for?JDK-8205129 Remove java.lang.Compiler as an 
> example:
> 
> https://bugs.openjdk.org/browse/JDK-8304459 
> <https://bugs.openjdk.org/browse/JDK-8304459>
> 
> The PR is approved and integrated and the issue Resolved as Fixed. 
> However, the Release Note sub-task is still New and Unresolved
> 
> Questions:
> 
> - Is the Release note issue considered implicitly reviewed as part of 
> the PR process?
> - Now that the issue is integrated, what should I do with the Release 
> Note issue? Mark it as fixed in 21 and resolve it?
> - The referenced release note does not appear in 
> https://jdk.java.net/21/ <https://jdk.java.net/21/>, that's perhaps 
> because the JBS issue is not resolved?
> 
> Thanks,
> Eirik.
> 
> 

From eirbjo at gmail.com  Thu Apr 13 07:20:28 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 13 Apr 2023 09:20:28 +0200
Subject: Question: Review process of release notes
In-Reply-To: <b08b02ff-2c10-a8bb-beac-428510d9c05f@oracle.com>
References: <CA+pBWhvoei=fmraNUn-ehjHe5ojRaOEp+Ypr6cdB0wS_vyr+2Q@mail.gmail.com>
 <b08b02ff-2c10-a8bb-beac-428510d9c05f@oracle.com>
Message-ID: <CA+pBWhvJUKqUXRieKd3EZs5oHbEzfhpd_-VuEKvP1PGbeOcnqA@mail.gmail.com>

>
> https://openjdk.org/guide/#release-notes


Thanks David, I just found this and it seems to answer most of my
questions. It does not explicitly say that the release note is considered
approved when the PR is approved, but I guess I'm safe to assume so.

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230413/1ec33b94/attachment.htm>

From zjx001202 at gmail.com  Thu Apr 13 07:34:27 2023
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 13 Apr 2023 15:34:27 +0800
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
Message-ID: <CAJL5A3mKDLWw4AeToiaKrjs2+50qTPJEDmOc8XuFCWYACbd0BQ@mail.gmail.com>

>
> Deprecating the existing methods would cause lots of warnings and
> provide little actual improvement.
>

I don't think there is only little actual improvement.

**Almost all** use cases of these two methods are misuse. Even the correct
use
of them is not recommended, as there are too many misuses, making it
difficult
to distinguish between correct use and misuse. Replacing them with
toLowerCase(Locale.getDefault()) can express intentions more clearly.
So is it a problem to cause many warnings? I think it's obviously not.

Even these misuses happen to work in most locales, not dealing with them is
just
burying the head in the sand.

The topics of deprecation and a new API should be treated separately,
> they have different costs and benefits.
>

This PR is now only deprecating the old method.

I plan to perform a set of tasks in parallel:

* Create a series of PRs to replace their use cases module by module with
  toLowerCase(Locale)/toUpperCase(Locale);
* Determine the naming of the new methods and then create a PR to implement
it;
* Deprecate the old methods.

If no one has any objections to this, I would like to start them
immediately as
I hope to complete them before Java 21.

After the above work is completed, I can gradually replace
`toLowerCase(Locale.ROOT)`/`toUpperCase(Locale.ROOT)`
with the new API. This work is not urgent and can be carried out at any
time.

Glavo

On Thu, Apr 13, 2023 at 4:27?AM Roger Riggs <roger.riggs at oracle.com> wrote:

> Hi,
>
> The status quo takes a balance between trying do the right thing and
> creating a headache for lots of developers.
> Deprecating the existing methods would cause lots of warnings and
> provide little actual improvement.
> Except in a few locales, the output would be the same as today.
> If you're working in a locale where it matters, it has become habit to
> use Locale.root everywhere.
>
> The most positive suggestion from the January thread [1] was to fix the
> uses in the JDK in small batches and carefully review each to make sure
> there are no unintended consequences. Even replacing the existing uses
> with a new method requires the same cautious approach.  Adding new
> methods was also mentioned.
>
> The topics of deprecation and a new API should be treated separately,
> they have different costs and benefits.
>
> As observed, coming to agreement on the naming is likely the hard part.
> You might want to start a discussion about that; but it may be too soon
> for a PR.
>
> Regards, Roger
>
>
>
> On 4/11/23 4:02 PM, Glavo wrote:
> > Hi everyone,
> >
> > A few months ago, I discussed in this mailing list[1] whether
> > toLowerCase()/toUpperCase() should be deprecated.
> > At that time, I received some approval and no one opposed the
> > idea. Therefore, I thought it might be time
> > to continue advancing this work, so I created a PR[2] for this.
> >
> > This PR is still a draft, welcome to discuss it there.
> >
> > I don't have much experience in contributing to OpenJDK yet, so I also
> > hope to get the help of experienced
> > contributors (such as creating CSR). Thanks!
> >
> > Glavo
> >
> > [1]
> >
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html
> > [2] https://github.com/openjdk/jdk/pull/13434
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230413/8591124e/attachment.htm>

From aturbanov at openjdk.org  Thu Apr 13 07:48:46 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 13 Apr 2023 07:48:46 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
Message-ID: <4Smfn2tAtGrX5g31k9KRWLqq3E_-yh4X9ajnRu0PWsI=.3fb1b2b1-ded4-49d6-8da0-c77078bd7ce8@github.com>

On Wed, 12 Apr 2023 19:02:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 113:

> 111:         @Override
> 112:         public String toString() {
> 113:             return "java.util.WeakKey#" + System.identityHashCode(this);

Why `java.util` ? It's a bit misleading

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 172:

> 170:         @Override
> 171:         public String toString() {
> 172:             return "java.util.SoftKey#" + System.identityHashCode(this);

Why `java.util` ? It's a bit misleading

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 226:

> 224:         @Override
> 225:         public String toString() {
> 226:             return "java.util.StrongKey#" + System.identityHashCode(this);

Why `java.util` ? It's a bit misleading

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 130:

> 128:     }
> 129: 
> 130:     @java.lang.Override

Suggestion:

    @Override

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 131:

> 129: 
> 130:     @java.lang.Override
> 131:     public java.lang.String toString() {

Suggestion:

    public String toString() {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165130712
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165130798
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165132919
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165133244
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165133383

From eirbjo at gmail.com  Thu Apr 13 08:00:48 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 13 Apr 2023 10:00:48 +0200
Subject: RFD: Notes in String.toUpperCase(), String.toLowerCase() could be
 more specific refering to "locale"
Message-ID: <CA+pBWhvytAYMEzff3dckSS7ZCz+fseDSNxbNbVKHSHX90eEKBQ@mail.gmail.com>

Hello,

During a discussion about the deprecation of String.toLowerCase(),
String.toUpperCase [1], it occurred to me that the current Note in the API
documentation could be more specific when talking about locales.

Before going ahead and suggesting a PR/CSR, I'd like to socialize the idea
that we could improve the Notes in these somewhat suspicious methods.

The current notes look like this:

Note: This method is locale sensitive, and may produce unexpected
> results if used for strings that are intended to be interpreted locale
> independently.


Sensitive to which locale? Independently of which locale?

It then goes on to say:

To obtain correct results for locale insensitive strings, use
> toUpperCase(Locale.ROOT)


What are "locale insensitive strings"?

Here is an attempt to be more specific:

Note: This method is sensitive to the default locale for this instance
> of the Java Virtual Machine. It  may produce unexpected
> results if used for strings that are intended to be interpreted
> independent of the default locale.


For the last part, I suggest using "language/country neutral results"
instead of "locale insensitive strings":

To obtain language/country neutral results, use toLowerCase(Locale.ROOT)


Any thoughts?

Thanks,
Eirik.
[1] https://github.com/openjdk/jdk/pull/13434#issuecomment-1505832883
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230413/74ffd8ae/attachment.htm>

From eirbjo at gmail.com  Thu Apr 13 08:18:48 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 13 Apr 2023 10:18:48 +0200
Subject: RFD: Notes in String.toUpperCase(), String.toLowerCase() could be
 more specific refering to "locale"
In-Reply-To: <CA+pBWhvytAYMEzff3dckSS7ZCz+fseDSNxbNbVKHSHX90eEKBQ@mail.gmail.com>
References: <CA+pBWhvytAYMEzff3dckSS7ZCz+fseDSNxbNbVKHSHX90eEKBQ@mail.gmail.com>
Message-ID: <CA+pBWhsD3N8fnKwZr7oKOV4X_x0RriuE9V3_TH75mkDv2YGfUA@mail.gmail.com>

>
> Any thoughts?
>

I'll add my own thoughts, which is that busy developers cannot be expected
to do the "right thing" if they don't understand the API Note.

Improving the note such that more developers understand the consequences of
using the method should help developers write more correct code.

Thanks,
Eirik.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230413/9db48aaf/attachment.htm>

From aturbanov at openjdk.org  Thu Apr 13 09:40:09 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 13 Apr 2023 09:40:09 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
Message-ID: <p81Ik8FFpIo7PzFcTzutZnXrlspAYpfb4WqgmZcXArs=.fdfe8066-1abe-47b6-a9d5-be643fd4be6a@github.com>

On Wed, 12 Apr 2023 19:02:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

src/java.base/share/classes/java/util/FormatItem.java line 71:

> 69:                     MethodType.methodType(MethodHandle.class, long.class));
> 70: 
> 71:     private static final long charMix(long lengthCoder, char value) {

let's drop `final` modifier from `static` methods

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165274119

From david.holmes at oracle.com  Thu Apr 13 10:43:26 2023
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 Apr 2023 20:43:26 +1000
Subject: Question: Review process of release notes
In-Reply-To: <CA+pBWhvJUKqUXRieKd3EZs5oHbEzfhpd_-VuEKvP1PGbeOcnqA@mail.gmail.com>
References: <CA+pBWhvoei=fmraNUn-ehjHe5ojRaOEp+Ypr6cdB0wS_vyr+2Q@mail.gmail.com>
 <b08b02ff-2c10-a8bb-beac-428510d9c05f@oracle.com>
 <CA+pBWhvJUKqUXRieKd3EZs5oHbEzfhpd_-VuEKvP1PGbeOcnqA@mail.gmail.com>
Message-ID: <6824fc5d-50b6-6f80-1758-46fda9b42178@oracle.com>

On 13/04/2023 5:20 pm, Eirik Bj?rsn?s wrote:
>     https://openjdk.org/guide/#release-notes
>     <https://openjdk.org/guide/#release-notes>
> 
> 
> Thanks David, I just found this and it seems to answer most?of my 
> questions. It does not explicitly say that the release note is 
> considered approved when the PR is approved, but I guess I'm safe to 
> assume so.

Unless your reviewers indicate they have seen the Release Note I would 
not assume that. If unclear ask someone to add a comment to the JBS 
issue saying they think it is okay.

Cheers,
David

> Cheers,
> Eirik.

From eirbjo at gmail.com  Thu Apr 13 10:53:15 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 13 Apr 2023 12:53:15 +0200
Subject: Question: Review process of release notes
In-Reply-To: <6824fc5d-50b6-6f80-1758-46fda9b42178@oracle.com>
References: <CA+pBWhvoei=fmraNUn-ehjHe5ojRaOEp+Ypr6cdB0wS_vyr+2Q@mail.gmail.com>
 <b08b02ff-2c10-a8bb-beac-428510d9c05f@oracle.com>
 <CA+pBWhvJUKqUXRieKd3EZs5oHbEzfhpd_-VuEKvP1PGbeOcnqA@mail.gmail.com>
 <6824fc5d-50b6-6f80-1758-46fda9b42178@oracle.com>
Message-ID: <CA+pBWhs9uWkE_cfDL7RqpDh8E7c8RG0HRpgt0dXSLW8ggCoAPg@mail.gmail.com>

>
>
> Unless your reviewers indicate they have seen the Release Note I would
> not assume that. If unclear ask someone to add a comment to the JBS
> issue saying they think it is okay.
>

This was very useful.

Thank,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230413/df8b3a11/attachment.htm>

From duke at openjdk.org  Thu Apr 13 10:55:48 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 13 Apr 2023 10:55:48 GMT
Subject: RFR: 8205129: Remove java.lang.Compiler
In-Reply-To: <k5oL-_x7ZlO48IYXqrBVQK_KhbPiLwrQSAXFgyWu8pk=.9834a282-838a-4893-b751-a8b318b68d37@github.com>
References: <k5oL-_x7ZlO48IYXqrBVQK_KhbPiLwrQSAXFgyWu8pk=.9834a282-838a-4893-b751-a8b318b68d37@github.com>
Message-ID: <7jr3hFzHqo_NkPvPXqJeiJuil7iWM8qlh9W0mgjXItM=.387dbe5b-e2a2-4ad5-8682-0d80ee957a86@github.com>

On Sun, 19 Mar 2023 09:01:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please help review this PR which suggests we remove the class `java.lang.Compiler`. The class seems non-functional for a decade, and was terminally deprecated in Java 9. Time has come to let it go.

The Release Note for this PR did not receive any comments.

It would be good if a Reviewer can take a look at the release note and see if it is conforming to the desired style:

https://bugs.openjdk.org/browse/JDK-8304459

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13092#issuecomment-1506755336

From jlaskey at openjdk.org  Thu Apr 13 12:01:46 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 12:01:46 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v56]
In-Reply-To: <5QkOHvuy9d8hQXPe6ETbT6fmE1No5e47lBCukDnNldY=.21ede21a-3340-47da-b69e-9322b7b9adc0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>
 <5QkOHvuy9d8hQXPe6ETbT6fmE1No5e47lBCukDnNldY=.21ede21a-3340-47da-b69e-9322b7b9adc0@github.com>
Message-ID: <ko_Cs8ZNFbIaFWfomx-LHK-QMtMJQ8mtVoGAaBpS3EA=.fbdd5a4c-0a5b-44bd-8029-70e0cc4a9820@github.com>

On Wed, 12 Apr 2023 15:09:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>
> src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 109:
> 
>> 107:      * @param lookup          method lookup
>> 108:      * @param name            method name
>> 109:      * @param type            method type
> 
> Maybe mention that the name is ignored, and the type must be convertible from `(String[], Object[])StringTemplate`? The specification says "fragments list" and "values list", which are more accurately described as arrays.
> 
> Also, does "large" string template mean there are more than 250~ fragments that the bootstrap method arguments can't fit, or does it mean dynamic number of fragments? Might be worth mentioning that as well.

Updating comments

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165418717

From jlaskey at openjdk.org  Thu Apr 13 12:15:51 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 12:15:51 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v56]
In-Reply-To: <5QkOHvuy9d8hQXPe6ETbT6fmE1No5e47lBCukDnNldY=.21ede21a-3340-47da-b69e-9322b7b9adc0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>
 <5QkOHvuy9d8hQXPe6ETbT6fmE1No5e47lBCukDnNldY=.21ede21a-3340-47da-b69e-9322b7b9adc0@github.com>
Message-ID: <RgGhnFOTuTls6r4HJVObv6MyQZwDqkU0S3PooaSvQcI=.be5eefdb-b214-4aef-9e86-88795eee482a@github.com>

On Wed, 12 Apr 2023 15:15: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:
>> 
>>   Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>
> src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 112:
> 
>> 110:         }
>> 111:         interpolateMH = MethodHandles.filterArguments(interpolateMH, 0, components);
>> 112:         mt = MethodType.methodType(String.class, StringTemplateImpl.class);
> 
> This MethodType can be stored in a static final field than created every time on the fly. Don't know if JIT compiler can inline this statement. Same fore that `List.class, StringTemplateImpl.class` type below.

Changing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165433226

From jlaskey at openjdk.org  Thu Apr 13 12:22:51 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 12:22:51 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <FaAsa2tK9mqgLaPcRVKNTaAWdKkzr37TmI1bcVH6Eps=.a575aa4b-bc90-4947-8bab-7dde4b180575@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
 <FaAsa2tK9mqgLaPcRVKNTaAWdKkzr37TmI1bcVH6Eps=.a575aa4b-bc90-4947-8bab-7dde4b180575@github.com>
Message-ID: <ZO_xat8BU3ZfeyfqSCsmBLSdxWKjpS87ihyB67PIWrM=.875b5c1a-794d-4d1c-8f52-1e1c9b92d142@github.com>

On Wed, 12 Apr 2023 20:50:35 GMT, Andrey Turbanov <aturbanov 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 75 commits:
>> 
>>  - Merge branch 'master' into 8285932
>>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>>  - Clean up Error handling
>>  - Recommended changes
>>  - RuntimeException is the only exception type that can is deduced from a lambda.
>>  - Update combine example
>>  - Merge branch 'master' into 8285932
>>  - Update StringTemplate.combine javadoc
>>  - Requested review changes.
>>  - Clean up list construction
>>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1
>
> src/java.base/share/classes/java/lang/runtime/Carriers.java line 286:
> 
>> 284:          */
>> 285:         MethodHandle constructor(CarrierShape carrierShape) {
>> 286:             int longCount = carrierShape.longCount();
> 
> `longCount`/`intCount` seems unused in this method

Changing

> src/java.base/share/classes/java/lang/runtime/Carriers.java line 369:
> 
>> 367:          * Cache mapping {@link MethodType} to previously defined {@link CarrierElements}.
>> 368:          */
>> 369:         private static Map<MethodType, CarrierElements>
> 
> Can it be made `final` ?

Changing

> src/java.base/share/classes/jdk/internal/access/JavaTemplateAccess.java line 28:
> 
>> 26: package jdk.internal.access;
>> 27: 
>> 28: import java.lang.invoke.MethodHandle;
> 
> Couple of unused imports

Changing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165440095
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165439152
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165442266

From jlaskey at openjdk.org  Thu Apr 13 12:38:10 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 12:38:10 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <4Smfn2tAtGrX5g31k9KRWLqq3E_-yh4X9ajnRu0PWsI=.3fb1b2b1-ded4-49d6-8da0-c77078bd7ce8@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
 <4Smfn2tAtGrX5g31k9KRWLqq3E_-yh4X9ajnRu0PWsI=.3fb1b2b1-ded4-49d6-8da0-c77078bd7ce8@github.com>
Message-ID: <CFwI3PS89j7uNSqy0u0k436ktRFLf2F3mRojjryvAHc=.24eb2c4e-2270-4f96-b1b5-4c6f9acc3ab8@github.com>

On Thu, 13 Apr 2023 07:42:24 GMT, Andrey Turbanov <aturbanov 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 75 commits:
>> 
>>  - Merge branch 'master' into 8285932
>>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>>  - Clean up Error handling
>>  - Recommended changes
>>  - RuntimeException is the only exception type that can is deduced from a lambda.
>>  - Update combine example
>>  - Merge branch 'master' into 8285932
>>  - Update StringTemplate.combine javadoc
>>  - Requested review changes.
>>  - Clean up list construction
>>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1
>
> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 113:
> 
>> 111:         @Override
>> 112:         public String toString() {
>> 113:             return "java.util.WeakKey#" + System.identityHashCode(this);
> 
> Why `java.util` ? It's a bit misleading

Moved and not reflected in the string. Changing to `this.getClass().getCanonicalName() + "#" + System.identityHashCode(this);`

> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 172:
> 
>> 170:         @Override
>> 171:         public String toString() {
>> 172:             return "java.util.SoftKey#" + System.identityHashCode(this);
> 
> Why `java.util` ? It's a bit misleading

same

> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 226:
> 
>> 224:         @Override
>> 225:         public String toString() {
>> 226:             return "java.util.StrongKey#" + System.identityHashCode(this);
> 
> Why `java.util` ? It's a bit misleading

same

> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 130:
> 
>> 128:     }
>> 129: 
>> 130:     @java.lang.Override
> 
> Suggestion:
> 
>     @Override

One of those IntelliJ things - ugh.

> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 131:
> 
>> 129: 
>> 130:     @java.lang.Override
>> 131:     public java.lang.String toString() {
> 
> Suggestion:
> 
>     public String toString() {

same

> src/java.base/share/classes/java/util/FormatItem.java line 71:
> 
>> 69:                     MethodType.methodType(MethodHandle.class, long.class));
>> 70: 
>> 71:     private static final long charMix(long lengthCoder, char value) {
> 
> let's drop `final` modifier from `static` methods

Changing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165449867
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165450204
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165450363
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165452561
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165452753
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165456644

From jlaskey at openjdk.org  Thu Apr 13 12:47:38 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 12:47:38 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v58]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <W8xbsb0XlDvC2JqrUHnti7ogxKW0IuZkYP9-ZsEV2yY=.393178aa-63b3-4993-9564-05e054f25e8c@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Recommended changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/f1b187a1..5e0dfce9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=57
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=56-57

  Stats: 38 lines in 7 files changed: 14 ins; 6 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From rriggs at openjdk.org  Thu Apr 13 13:31:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Apr 2023 13:31:48 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
Message-ID: <9xC6I_K4jt0nkOfBbBxhDMDJ2rdBJuuAKupoW-rKtrI=.9cd35742-ca55-4ad4-aa78-87ae4fc7b2e1@github.com>

On Wed, 12 Apr 2023 19:02:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

src/java.base/share/classes/java/util/Digits.java line 39:

> 37:  * @since 21
> 38:  */
> 39: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)

The Digits utility implementation class is not public and would be useful elsewhere before JEP 430 is final.
The PreviewFeature annotation is not needed and would impede its use else where, for example, in HexFormat.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165524941

From jlaskey at openjdk.org  Thu Apr 13 13:36:57 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 13:36:57 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v59]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <qK50FJFg-4mKgeVzLQak-MSEK_0w_rtFqk7XmNg60v4=.dfef936b-efc8-47de-8bb8-ce8be9e2957e@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Remove preview feature on package private java.util.Digits

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/5e0dfce9..69f49bdf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=58
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=57-58

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Thu Apr 13 13:45:39 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 13:45:39 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <9xC6I_K4jt0nkOfBbBxhDMDJ2rdBJuuAKupoW-rKtrI=.9cd35742-ca55-4ad4-aa78-87ae4fc7b2e1@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
 <9xC6I_K4jt0nkOfBbBxhDMDJ2rdBJuuAKupoW-rKtrI=.9cd35742-ca55-4ad4-aa78-87ae4fc7b2e1@github.com>
Message-ID: <2Orq5gqsqNC3HRWPfyABqMlMk3i5lj2LB1Ib6ECHxQc=.3b7e9f34-96a7-405b-be17-71d9fa6c160a@github.com>

On Thu, 13 Apr 2023 13:29:33 GMT, Roger Riggs <rriggs 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 75 commits:
>> 
>>  - Merge branch 'master' into 8285932
>>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>>  - Clean up Error handling
>>  - Recommended changes
>>  - RuntimeException is the only exception type that can is deduced from a lambda.
>>  - Update combine example
>>  - Merge branch 'master' into 8285932
>>  - Update StringTemplate.combine javadoc
>>  - Requested review changes.
>>  - Clean up list construction
>>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1
>
> src/java.base/share/classes/java/util/Digits.java line 39:
> 
>> 37:  * @since 21
>> 38:  */
>> 39: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 
> The Digits utility implementation class is not public and would be useful elsewhere before JEP 430 is final.
> The PreviewFeature annotation is not needed and would impede its use else where, for example, in HexFormat.

Removing preview feature.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165543387

From roger.riggs at oracle.com  Thu Apr 13 14:12:50 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 13 Apr 2023 10:12:50 -0400
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <CAJL5A3mKDLWw4AeToiaKrjs2+50qTPJEDmOc8XuFCWYACbd0BQ@mail.gmail.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
 <CAJL5A3mKDLWw4AeToiaKrjs2+50qTPJEDmOc8XuFCWYACbd0BQ@mail.gmail.com>
Message-ID: <549e246f-eb19-8a6a-5e83-5b3c615e51ca@oracle.com>

Hi,

In my experience, it will take longer to agree on the deprecation than 
adding a simple API with known semantics.

An important element of the deprecation messaging is the potential 
replacement.
Having the replacement in hand gives a clear message and action that can 
be scripted.
IDE's would also be able to suggest and apply.

And yes, it is a problem to cause many warnings; it creates an immediate 
and pressing need for projects that have tight source requirements and 
don't allow warnings, for example, the JDK itself.

An expectation-wise, the June 8 Rampdown Phase One is closer than it 
appears.
There are significant number of projects that are queuing up to beat the 
deadline, but compete for resources to review.

Regards, Roger


On 4/13/23 3:34 AM, Glavo wrote:
>
>     Deprecating the existing methods would cause lots of warnings and
>     provide little actual improvement.
>
>
> I don't think there is only little actual improvement.
>
> **Almost all** use cases of these two methods are misuse. Even the 
> correct use
> of them is not recommended, as there are too many misuses, making it 
> difficult
> to distinguish between correct use and misuse. Replacing them with
> toLowerCase(Locale.getDefault()) can express intentions more clearly.
> So is it a problem to cause many warnings? I think it's obviously not.
>
> Even these misuses happen to work in most locales, not dealing with 
> them is just
> burying the head in the sand.
>
>     The topics of deprecation and a new API should be treated separately,
>     they have different costs and benefits.
>
>
> This PR is now only deprecating the old method.
>
> I plan to perform a set of tasks in parallel:
>
> * Create a series of PRs to replace their use cases module by module with
> ? toLowerCase(Locale)/toUpperCase(Locale);
> * Determine the naming of the new methods and then create a PR to 
> implement it;
> * Deprecate the old methods.
>
> If no one has any objections to this, I would like to start them 
> immediately as
> I hope to complete them before Java 21.
>
> After the above work is completed, I can gradually replace 
> `toLowerCase(Locale.ROOT)`/`toUpperCase(Locale.ROOT)`
> with the new API. This work is not urgent and can be carried out at 
> any time.
>
> Glavo
>
> On Thu, Apr 13, 2023 at 4:27?AM Roger Riggs <roger.riggs at oracle.com> 
> wrote:
>
>     Hi,
>
>     The status quo takes a balance between trying do the right thing and
>     creating a headache for lots of developers.
>     Deprecating the existing methods would cause lots of warnings and
>     provide little actual improvement.
>     Except in a few locales, the output would be the same as today.
>     If you're working in a locale where it matters, it has become
>     habit to
>     use Locale.root everywhere.
>
>     The most positive suggestion from the January thread [1] was to
>     fix the
>     uses in the JDK in small batches and carefully review each to make
>     sure
>     there are no unintended consequences. Even replacing the existing
>     uses
>     with a new method requires the same cautious approach.? Adding new
>     methods was also mentioned.
>
>     The topics of deprecation and a new API should be treated separately,
>     they have different costs and benefits.
>
>     As observed, coming to agreement on the naming is likely the hard
>     part.
>     You might want to start a discussion about that; but it may be too
>     soon
>     for a PR.
>
>     Regards, Roger
>
>
>
>     On 4/11/23 4:02 PM, Glavo wrote:
>     > Hi everyone,
>     >
>     > A few months ago, I discussed in this mailing list[1] whether
>     > toLowerCase()/toUpperCase()?should be deprecated.
>     > At that time, I received some approval and no one opposed the
>     > idea.?Therefore, I thought it might be time
>     > to continue advancing this work, so I created a PR[2] for this.
>     >
>     > This PR is still a draft, welcome to discuss it there.
>     >
>     > I don't have much experience in contributing to OpenJDK yet, so
>     I also
>     > hope to get the help of experienced
>     > contributors (such as creating CSR). Thanks!
>     >
>     > Glavo
>     >
>     > [1]
>     >
>     https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html
>     > [2] https://github.com/openjdk/jdk/pull/13434
>     <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/13434__;!!ACWV5N9M2RV99hQ!PgzNhsfRigH2Aep5P5810AJ-DSVnZjjOvHTWJac-KQ_TT7fySzsLYqVMqNFai_YcDTi0mAz9JgMHyp2JxxI$>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230413/fb0c5499/attachment-0001.htm>

From zjx001202 at gmail.com  Thu Apr 13 14:58:45 2023
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 13 Apr 2023 22:58:45 +0800
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <549e246f-eb19-8a6a-5e83-5b3c615e51ca@oracle.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
 <CAJL5A3mKDLWw4AeToiaKrjs2+50qTPJEDmOc8XuFCWYACbd0BQ@mail.gmail.com>
 <549e246f-eb19-8a6a-5e83-5b3c615e51ca@oracle.com>
Message-ID: <CAJL5A3kxWKdoWHGL1k70Ae6ED+HTvRCmXXGxOMXvwQ_VBQMF1A@mail.gmail.com>

>  In my experience, it will take longer to agree on the deprecation than
adding a simple API with known semantics.

All right, so I'll focus on creating new APIs first. I hope to get it at
least in Java 21.
It is also acceptable to deprecate the old API at a later date.

As observed, coming to agreement on the naming is likely the hard part.
> You might want to start a discussion about that; but it may be too soon
> for a PR.
>

I thought it might be more efficient to discuss after creating a draft PR.
It seems that it is difficult to attract more experts to participate in the
discussion only on the mailing list. Do you have any suggestions for this?

Glavo

On Thu, Apr 13, 2023 at 10:13?PM Roger Riggs <roger.riggs at oracle.com> wrote:

> Hi,
>
> In my experience, it will take longer to agree on the deprecation than
> adding a simple API with known semantics.
>
> An important element of the deprecation messaging is the potential
> replacement.
> Having the replacement in hand gives a clear message and action that can
> be scripted.
> IDE's would also be able to suggest and apply.
>
> And yes, it is a problem to cause many warnings; it creates an immediate
> and pressing need for projects that have tight source requirements and
> don't allow warnings, for example, the JDK itself.
>
> An expectation-wise, the June 8 Rampdown Phase One is closer than it
> appears.
> There are significant number of projects that are queuing up to beat the
> deadline, but compete for resources to review.
>
> Regards, Roger
>
>
> On 4/13/23 3:34 AM, Glavo wrote:
>
> Deprecating the existing methods would cause lots of warnings and
>> provide little actual improvement.
>>
>
> I don't think there is only little actual improvement.
>
> **Almost all** use cases of these two methods are misuse. Even the correct
> use
> of them is not recommended, as there are too many misuses, making it
> difficult
> to distinguish between correct use and misuse. Replacing them with
> toLowerCase(Locale.getDefault()) can express intentions more clearly.
> So is it a problem to cause many warnings? I think it's obviously not.
>
> Even these misuses happen to work in most locales, not dealing with them
> is just
> burying the head in the sand.
>
> The topics of deprecation and a new API should be treated separately,
>> they have different costs and benefits.
>>
>
> This PR is now only deprecating the old method.
>
> I plan to perform a set of tasks in parallel:
>
> * Create a series of PRs to replace their use cases module by module with
>   toLowerCase(Locale)/toUpperCase(Locale);
> * Determine the naming of the new methods and then create a PR to
> implement it;
> * Deprecate the old methods.
>
> If no one has any objections to this, I would like to start them
> immediately as
> I hope to complete them before Java 21.
>
> After the above work is completed, I can gradually replace
> `toLowerCase(Locale.ROOT)`/`toUpperCase(Locale.ROOT)`
> with the new API. This work is not urgent and can be carried out at any
> time.
>
> Glavo
>
> On Thu, Apr 13, 2023 at 4:27?AM Roger Riggs <roger.riggs at oracle.com>
> wrote:
>
>> Hi,
>>
>> The status quo takes a balance between trying do the right thing and
>> creating a headache for lots of developers.
>> Deprecating the existing methods would cause lots of warnings and
>> provide little actual improvement.
>> Except in a few locales, the output would be the same as today.
>> If you're working in a locale where it matters, it has become habit to
>> use Locale.root everywhere.
>>
>> The most positive suggestion from the January thread [1] was to fix the
>> uses in the JDK in small batches and carefully review each to make sure
>> there are no unintended consequences. Even replacing the existing uses
>> with a new method requires the same cautious approach.  Adding new
>> methods was also mentioned.
>>
>> The topics of deprecation and a new API should be treated separately,
>> they have different costs and benefits.
>>
>> As observed, coming to agreement on the naming is likely the hard part.
>> You might want to start a discussion about that; but it may be too soon
>> for a PR.
>>
>> Regards, Roger
>>
>>
>>
>> On 4/11/23 4:02 PM, Glavo wrote:
>> > Hi everyone,
>> >
>> > A few months ago, I discussed in this mailing list[1] whether
>> > toLowerCase()/toUpperCase() should be deprecated.
>> > At that time, I received some approval and no one opposed the
>> > idea. Therefore, I thought it might be time
>> > to continue advancing this work, so I created a PR[2] for this.
>> >
>> > This PR is still a draft, welcome to discuss it there.
>> >
>> > I don't have much experience in contributing to OpenJDK yet, so I also
>> > hope to get the help of experienced
>> > contributors (such as creating CSR). Thanks!
>> >
>> > Glavo
>> >
>> > [1]
>> >
>> https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html
>> > [2] https://github.com/openjdk/jdk/pull/13434
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/13434__;!!ACWV5N9M2RV99hQ!PgzNhsfRigH2Aep5P5810AJ-DSVnZjjOvHTWJac-KQ_TT7fySzsLYqVMqNFai_YcDTi0mAz9JgMHyp2JxxI$>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230413/78165cfe/attachment.htm>

From archie.cobbs at gmail.com  Thu Apr 13 15:00:57 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 13 Apr 2023 10:00:57 -0500
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <549e246f-eb19-8a6a-5e83-5b3c615e51ca@oracle.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
 <CAJL5A3mKDLWw4AeToiaKrjs2+50qTPJEDmOc8XuFCWYACbd0BQ@mail.gmail.com>
 <549e246f-eb19-8a6a-5e83-5b3c615e51ca@oracle.com>
Message-ID: <CANSoFxuLPVdoTkcN2AAJnCRFCiXXLGOHXVxFchnew4_N9Z+5nQ@mail.gmail.com>

On Thu, Apr 13, 2023 at 9:14?AM Roger Riggs <roger.riggs at oracle.com> wrote:

> And yes, it is a problem to cause many warnings; it creates an immediate
> and pressing need for projects that have tight source requirements and
> don't allow warnings, for example, the JDK itself.
>

Hmm.. I'd agree with this statement if most of the warnings were false
positives. But the argument here is that (quoting): "**Almost all** use
cases of these two methods are misuse"

In that case, isn't there something a little backwards about saying we
should continue sweeping them under the rug? (Am I being too idealistic?)

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230413/ee59b70e/attachment.htm>

From eirbjo at gmail.com  Thu Apr 13 15:39:13 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 13 Apr 2023 17:39:13 +0200
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <CANSoFxuLPVdoTkcN2AAJnCRFCiXXLGOHXVxFchnew4_N9Z+5nQ@mail.gmail.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
 <CAJL5A3mKDLWw4AeToiaKrjs2+50qTPJEDmOc8XuFCWYACbd0BQ@mail.gmail.com>
 <549e246f-eb19-8a6a-5e83-5b3c615e51ca@oracle.com>
 <CANSoFxuLPVdoTkcN2AAJnCRFCiXXLGOHXVxFchnew4_N9Z+5nQ@mail.gmail.com>
Message-ID: <CA+pBWhsSoHD2djVjYvKSMd0kgSzA=E3hOFxEYRaGxCNFUW_6bA@mail.gmail.com>

>
> In that case, isn't there something a little backwards about saying we
> should continue sweeping them under the rug? (Am I being too idealistic?)
>

I sympathise with the concern of causing many warnings/errors, and the
right time to do these things never seems to be "now".

But let's look at it this way: The Turkish population alone is
currently 1.08 percent of the world population. If we assume the number of
Java apps/services per capita is the same around the world, this means that
these methods may return the expected result in 98.92 percent of the
executions. I think that's a bit scary.

Deprecating these methods would require consensus and support from
reviewers, which we don't seem to have at the moment. So I think the
current focus on fixing the uses inside OpenJDK and then adding
alternatives first seems good. Then, maybe someday.. :-)

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230413/682e1956/attachment-0001.htm>

From brian.burkhalter at oracle.com  Thu Apr 13 15:45:30 2023
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 13 Apr 2023 15:45:30 +0000
Subject: RFE: SequenceInputStream - Consider new issue for PR #11718
In-Reply-To: <00CEFB76-6D73-41A0-95BB-48F771B9EE1E@oracle.com>
References: <CAKZnr+xnAfrCkuGjyMDnPfLWG8BNXtT03Yi7HfVDdgY3k3-iTw@mail.gmail.com>
 <CAKZnr+z6utmZwMA7OZPOTOkL2RUWC=VLJq0sYYPBdXAAgqGFOg@mail.gmail.com>
 <00CEFB76-6D73-41A0-95BB-48F771B9EE1E@oracle.com>
Message-ID: <72BE36FF-7496-4A40-A11E-035B09F038FC@oracle.com>

Voila: https://bugs.openjdk.org/browse/JDK-8305947

On Apr 11, 2023, at 9:06 AM, Brian Burkhalter <brian.burkhalter at oracle.com<mailto:brian.burkhalter at oracle.com>> wrote:

Hello,

You should be able to file an issue yourself at

https://bugreport.java.com/bugreport/start_form

Brian

On Apr 10, 2023, at 11:59 PM, Benjamin Marwell <bmarwell at apache.org<mailto:bmarwell at apache.org>> wrote:

Follow up, I would highly appreciate it if anyone would be so kind as
to open an issue for this enhancement.

Am Sa., 8. Apr. 2023 um 17:36 Uhr schrieb Benjamin Marwell
<bmarwell at apache.org<mailto:bmarwell at apache.org>>:

Dear Core-Devs,

There was a PR created for an enhancement of SequenceInputStream [1]
by Romain Manni-Buceau.

Description by Romain:

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)

As the both of us do not have access to the OpenJDK bug tracker,
kindly open an issue for this PR if you agree with this
enhancement/PR.

[1]: https://github.com/openjdk/jdk/pull/11718


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230413/38513d34/attachment.htm>

From naoto.sato at oracle.com  Thu Apr 13 16:08:32 2023
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 13 Apr 2023 09:08:32 -0700
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <CA+pBWhsSoHD2djVjYvKSMd0kgSzA=E3hOFxEYRaGxCNFUW_6bA@mail.gmail.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
 <CAJL5A3mKDLWw4AeToiaKrjs2+50qTPJEDmOc8XuFCWYACbd0BQ@mail.gmail.com>
 <549e246f-eb19-8a6a-5e83-5b3c615e51ca@oracle.com>
 <CANSoFxuLPVdoTkcN2AAJnCRFCiXXLGOHXVxFchnew4_N9Z+5nQ@mail.gmail.com>
 <CA+pBWhsSoHD2djVjYvKSMd0kgSzA=E3hOFxEYRaGxCNFUW_6bA@mail.gmail.com>
Message-ID: <de032adb-3fda-7fe3-fe80-a224b688f072@oracle.com>

I too agree with Roger that deprecation would have high bar.

Another possibility to mitigate the situation rather than introducing 
the new methods is to introduce a new system property and let the users 
decide the default (yes, yet another property, but I believe it 
warrants). Say,

java.lang.String.defaultCaseLocale=[root/display/format]

where each value designates

root -> Locale.ROOT
display -> Locale.getDefault(Locale.Category.DISPLAY)
format -> Locale.getDefault(Locale.Category.FORMAT)

The choice for the "default" default have room to discuss, but format 
may not be bad choice.

As to the current spec, we can emphasize the Turkish issue more visible 
by making "Notes:" to @apiNote.

Naoto

On 4/13/23 8:39 AM, Eirik Bj?rsn?s wrote:
>     In that case, isn't there something a little backwards about saying
>     we should continue sweeping them under the rug? (Am I being too
>     idealistic?)
> 
> 
> I?sympathise with the concern of causing many warnings/errors, and the 
> right time to do these things never seems to be "now".
> 
> But let's look at it this way: The Turkish population alone is 
> currently?1.08 percent of the world population. If we assume the number 
> of Java apps/services per capita is the same around the world, this 
> means that these methods may return the expected result in 98.92 percent 
> of the executions. I think that's a bit scary.
> 
> Deprecating these methods would require consensus?and support from 
> reviewers, which we don't seem to have at the moment. So I think the 
> current focus on fixing the uses inside OpenJDK and then adding 
> alternatives first seems good. Then, maybe someday.. :-)
> 
> Eirik.

From zjx001202 at gmail.com  Thu Apr 13 16:31:33 2023
From: zjx001202 at gmail.com (Glavo)
Date: Fri, 14 Apr 2023 00:31:33 +0800
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <de032adb-3fda-7fe3-fe80-a224b688f072@oracle.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
 <CAJL5A3mKDLWw4AeToiaKrjs2+50qTPJEDmOc8XuFCWYACbd0BQ@mail.gmail.com>
 <549e246f-eb19-8a6a-5e83-5b3c615e51ca@oracle.com>
 <CANSoFxuLPVdoTkcN2AAJnCRFCiXXLGOHXVxFchnew4_N9Z+5nQ@mail.gmail.com>
 <CA+pBWhsSoHD2djVjYvKSMd0kgSzA=E3hOFxEYRaGxCNFUW_6bA@mail.gmail.com>
 <de032adb-3fda-7fe3-fe80-a224b688f072@oracle.com>
Message-ID: <CAJL5A3ncAYXqSyon7F23fLh-0-W7-DeBnkRo6pKEMHdzQyKCRw@mail.gmail.com>

>
> Another possibility to mitigate the situation rather than introducing
> the new methods is to introduce a new system property and let the users
> decide the default (yes, yet another property, but I believe it
> warrants). Say,
>

I think this can only be used as a transitional solution, and it doesn't
really
solve the problem - the semantics of toLowerCase()/toUpperCase() are still
vague,
so toLowerCase(Locale)/toUpperCase(Locale) is still needed to get
deterministic
behavior.

I agree that this solution can be used instead of deprecating these two
APIs,
but I think the new APIs are still necessary.

Glavo

On Fri, Apr 14, 2023 at 12:08?AM Naoto Sato <naoto.sato at oracle.com> wrote:

> I too agree with Roger that deprecation would have high bar.
>
> Another possibility to mitigate the situation rather than introducing
> the new methods is to introduce a new system property and let the users
> decide the default (yes, yet another property, but I believe it
> warrants). Say,
>
> java.lang.String.defaultCaseLocale=[root/display/format]
>
> where each value designates
>
> root -> Locale.ROOT
> display -> Locale.getDefault(Locale.Category.DISPLAY)
> format -> Locale.getDefault(Locale.Category.FORMAT)
>
> The choice for the "default" default have room to discuss, but format
> may not be bad choice.
>
> As to the current spec, we can emphasize the Turkish issue more visible
> by making "Notes:" to @apiNote.
>
> Naoto
>
> On 4/13/23 8:39 AM, Eirik Bj?rsn?s wrote:
> >     In that case, isn't there something a little backwards about saying
> >     we should continue sweeping them under the rug? (Am I being too
> >     idealistic?)
> >
> >
> > I sympathise with the concern of causing many warnings/errors, and the
> > right time to do these things never seems to be "now".
> >
> > But let's look at it this way: The Turkish population alone is
> > currently 1.08 percent of the world population. If we assume the number
> > of Java apps/services per capita is the same around the world, this
> > means that these methods may return the expected result in 98.92 percent
> > of the executions. I think that's a bit scary.
> >
> > Deprecating these methods would require consensus and support from
> > reviewers, which we don't seem to have at the moment. So I think the
> > current focus on fixing the uses inside OpenJDK and then adding
> > alternatives first seems good. Then, maybe someday.. :-)
> >
> > Eirik.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230414/62300cbf/attachment-0001.htm>

From jlaskey at openjdk.org  Thu Apr 13 16:37:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 16:37:37 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v60]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <HNXFWWDeLdcP1Y3r-DnaThYtkv1OeCFmyiNhj6NIMX8=.c7ce520e-e93d-4cc8-9350-c9f800763c93@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  HexDigits -> OctalDigits

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/69f49bdf..961a5417

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=59
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=58-59

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From dfuchs at openjdk.org  Thu Apr 13 16:37:40 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Apr 2023 16:37:40 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v59]
In-Reply-To: <qK50FJFg-4mKgeVzLQak-MSEK_0w_rtFqk7XmNg60v4=.dfef936b-efc8-47de-8bb8-ce8be9e2957e@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <qK50FJFg-4mKgeVzLQak-MSEK_0w_rtFqk7XmNg60v4=.dfef936b-efc8-47de-8bb8-ce8be9e2957e@github.com>
Message-ID: <cqtw3in9QfR2gOdF0kYTHUOcbsXs4XPEM9qVqhleOxc=.1c5aa5cc-2cd5-4393-8105-5c5e460aa0ca@github.com>

On Thu, 13 Apr 2023 13:36:57 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove preview feature on package private java.util.Digits

src/java.base/share/classes/java/util/Digits.java line 233:

> 231: 
> 232:         /**
> 233:          * Singleton instance of HexDigits.

Suggestion:

         * Singleton instance of OctalDigits.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165774156

From jlaskey at openjdk.org  Thu Apr 13 16:37:41 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 16:37:41 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v59]
In-Reply-To: <cqtw3in9QfR2gOdF0kYTHUOcbsXs4XPEM9qVqhleOxc=.1c5aa5cc-2cd5-4393-8105-5c5e460aa0ca@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <qK50FJFg-4mKgeVzLQak-MSEK_0w_rtFqk7XmNg60v4=.dfef936b-efc8-47de-8bb8-ce8be9e2957e@github.com>
 <cqtw3in9QfR2gOdF0kYTHUOcbsXs4XPEM9qVqhleOxc=.1c5aa5cc-2cd5-4393-8105-5c5e460aa0ca@github.com>
Message-ID: <jEAED2oUquyG6rAXh497IQvkaVg5ksQNGNHZs4IMcbA=.14a323d6-30da-4f8c-978f-31a5c1a231b9@github.com>

On Thu, 13 Apr 2023 16:27:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove preview feature on package private java.util.Digits
>
> src/java.base/share/classes/java/util/Digits.java line 233:
> 
>> 231: 
>> 232:         /**
>> 233:          * Singleton instance of HexDigits.
> 
> Suggestion:
> 
>          * Singleton instance of OctalDigits.

Nice catch

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165778236

From dfuchs at openjdk.org  Thu Apr 13 16:42:15 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Apr 2023 16:42:15 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v59]
In-Reply-To: <qK50FJFg-4mKgeVzLQak-MSEK_0w_rtFqk7XmNg60v4=.dfef936b-efc8-47de-8bb8-ce8be9e2957e@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <qK50FJFg-4mKgeVzLQak-MSEK_0w_rtFqk7XmNg60v4=.dfef936b-efc8-47de-8bb8-ce8be9e2957e@github.com>
Message-ID: <HnYdeuWGz5w8lbi8FXkmkFsTwefMsOPgdrUyi_84L4w=.dfbb9045-002c-4397-a584-789cd2d5d940@github.com>

On Thu, 13 Apr 2023 13:36:57 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove preview feature on package private java.util.Digits

src/java.base/share/classes/java/util/FormatProcessor.java line 167:

> 165:      * {@link FormatProcessor#process(StringTemplate)}. This {@link MethodHandle}
> 166:      * is used by {@link FormatProcessor#FMT} and the ilk to perform a more
> 167:      * specialized composition of a result. This is specialization is done by

Typo here? "This is specialization is done"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165785237

From lmesnik at openjdk.org  Thu Apr 13 16:42:45 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 13 Apr 2023 16:42:45 GMT
Subject: Integrated: 8305875: Test TraceVirtualThreadLocals should be run with
 continuations only
In-Reply-To: <g9W0p02Y0P5LafPHpH05fWqyeH7HEbzRkGk7IXRbXPo=.7e396e18-4634-4efe-add5-496f605f10c5@github.com>
References: <g9W0p02Y0P5LafPHpH05fWqyeH7HEbzRkGk7IXRbXPo=.7e396e18-4634-4efe-add5-496f605f10c5@github.com>
Message-ID: <Ibuhl0jVVg4izw6qQRoRDAQ26cr_rZrK8M1FM6PkEKo=.685281c0-4240-41b7-bf23-bd7c253011bf@github.com>

On Tue, 11 Apr 2023 23:38:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test TraceVirtualThreadLocals verifies that thread locals are dumped for virtual threads. It fails when continuations are not available and virtual threads are emulated.
> 
> The test failed on linux-x86 so I just want to mark it to have green github actions results.

This pull request has now been integrated.

Changeset: 92521b10
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92521b100f1eb785eabd101870f631f555c3b135
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8305875: Test TraceVirtualThreadLocals should be run with continuations only

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/13436

From jlaskey at openjdk.org  Thu Apr 13 16:54:43 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 16:54:43 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v59]
In-Reply-To: <HnYdeuWGz5w8lbi8FXkmkFsTwefMsOPgdrUyi_84L4w=.dfbb9045-002c-4397-a584-789cd2d5d940@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <qK50FJFg-4mKgeVzLQak-MSEK_0w_rtFqk7XmNg60v4=.dfef936b-efc8-47de-8bb8-ce8be9e2957e@github.com>
 <HnYdeuWGz5w8lbi8FXkmkFsTwefMsOPgdrUyi_84L4w=.dfbb9045-002c-4397-a584-789cd2d5d940@github.com>
Message-ID: <RxIYh3jdWoE_6WWtfNtigGAvE78IImTdcCn-b2OMPSU=.535b8e07-45db-4a7f-9fd0-8374cc2dd89d@github.com>

On Thu, 13 Apr 2023 16:38:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove preview feature on package private java.util.Digits
>
> src/java.base/share/classes/java/util/FormatProcessor.java line 167:
> 
>> 165:      * {@link FormatProcessor#process(StringTemplate)}. This {@link MethodHandle}
>> 166:      * is used by {@link FormatProcessor#FMT} and the ilk to perform a more
>> 167:      * specialized composition of a result. This is specialization is done by
> 
> Typo here? "This is specialization is done"

removing "is"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165799277

From jlaskey at openjdk.org  Thu Apr 13 17:09:13 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 17:09:13 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v61]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <jayHaXL1Rijkezg5u8iUXIYB0NVds5SnQITdu1NtsUg=.c69b7ca8-d363-4489-ac29-029ae62ec2f1@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/961a5417..f27ad709

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=60
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=59-60

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From naoto at openjdk.org  Thu Apr 13 17:41:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Apr 2023 17:41:33 GMT
Subject: RFR: 8305904: java/lang/Character,
 java/lang/String and java/text/Normalizer tests read the unicode data files
 from src directories.
In-Reply-To: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
References: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
Message-ID: <TI_RZzu0tt9vOe48e932gnCZUZlbCiary4Gu6mVABZc=.2d9259cb-fd03-45ac-a161-0bd6bedb126c@github.com>

On Wed, 12 Apr 2023 16:35:19 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Following tests read the unicode data files (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, these files should be in test directories. No source code is using these files. Only tests are using these files. Tests are :
> java/lang/Character/CharPropTest.java
> java/lang/Character/CheckProp.java
> java/lang/Character/CheckScript.java
> java/lang/Character/CheckUnicode.java
> java/lang/Character/UnicodeBlock/CheckBlocks.java
> java/lang/Character/UnicodeCasingTest.java
> java/lang/String/SpecialCasingTest.java
> java/lang/String/UnicodeCasingTest.java
> java/text/Normalizer/ConformanceTest.java

Hi Mahendra,

What's the point of having the Unicode data files duplicate? That would cause a possible mismatch between the files between src and test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13447#issuecomment-1507365030

From rriggs at openjdk.org  Thu Apr 13 17:55:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Apr 2023 17:55:37 GMT
Subject: RFR: 8305904: java/lang/Character,
 java/lang/String and java/text/Normalizer tests read the unicode data files
 from src directories.
In-Reply-To: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
References: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
Message-ID: <HmOoAQ_gqY_84pfDJdScCGJa9iSLPA6AatLfOIIX9aU=.189361bf-a1c2-4970-83ee-66951c924c3f@github.com>

On Wed, 12 Apr 2023 16:35:19 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Following tests read the unicode data files (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, these files should be in test directories. No source code is using these files. Only tests are using these files. Tests are :
> java/lang/Character/CharPropTest.java
> java/lang/Character/CheckProp.java
> java/lang/Character/CheckScript.java
> java/lang/Character/CheckUnicode.java
> java/lang/Character/UnicodeBlock/CheckBlocks.java
> java/lang/Character/UnicodeCasingTest.java
> java/lang/String/SpecialCasingTest.java
> java/lang/String/UnicodeCasingTest.java
> java/text/Normalizer/ConformanceTest.java

Are you aware of the uses in the makefiles?  

make/modules/java.base/Gendata.gmk
make/modules/java.base/gendata/GendataBreakIterator.gmk
make/modules/java.base/gensrc/GensrcCharacterData.gmk

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13447#issuecomment-1507386116

From zjx001202 at gmail.com  Thu Apr 13 17:58:29 2023
From: zjx001202 at gmail.com (Glavo)
Date: Fri, 14 Apr 2023 01:58:29 +0800
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <de032adb-3fda-7fe3-fe80-a224b688f072@oracle.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
 <CAJL5A3mKDLWw4AeToiaKrjs2+50qTPJEDmOc8XuFCWYACbd0BQ@mail.gmail.com>
 <549e246f-eb19-8a6a-5e83-5b3c615e51ca@oracle.com>
 <CANSoFxuLPVdoTkcN2AAJnCRFCiXXLGOHXVxFchnew4_N9Z+5nQ@mail.gmail.com>
 <CA+pBWhsSoHD2djVjYvKSMd0kgSzA=E3hOFxEYRaGxCNFUW_6bA@mail.gmail.com>
 <de032adb-3fda-7fe3-fe80-a224b688f072@oracle.com>
Message-ID: <CAJL5A3mOkUK_ah4kpQUVrVWZnfJCD=ojqE4=8hh1GTLPLB5-Uw@mail.gmail.com>

The core problem of these two methods is that they should have clear
semantics (locale sensitive),
but due to a large number of misuses, they cannot express the user's
intention.

The only point in making their behavior configurable is that for buggy
legacy code
we can modify the configuration to make it behave correctly. It is not
helpful for
developers who are writing new code, as developers understand in almost
always aware
of whether they need locale sensitivity, so using this vague methods
actually masks
their intentions.

Our only way to make these methods with huge historical burdens usable is
to
change and fix their behavior to be locale insensitive. But this is a
breaking
change and will cause trouble for users who use the new version of JDK but
target the old version of JRE.

In summary, we cannot satisfy users with them, so we can only give them up
and
let all users no longer use them in new code.


Another issue is that we can use
`toLowerCase(Locale.ROOT)`/`toUpperCase(Locale.ROOT)`
to achieve the expected behavior, so why do we need to introduce a new API?

For this issue, we need to take a look at the current way.

Firstly, it is lengthy, so users may feel impatient with it.

This lengthy way not only lacks clarity, but also reduces readability.
It forces the user to use Locale when it is not locale sensitive, which
generates
noise, and also makes it harder for the user to find which parts of the
code are
locale sensitive.

This is why I want to introduce new APIs.


---

These are the steps I believe are reasonable to address these issues:

1. Add new locale insensitive APIs and recommend users to use them in new
code.

   I hope this step can be implemented in Java 21.

2. Add a new system property that allows users to configure the behavior of
   these two methods.

3. Gradually clean up the use cases inside JDK.

   Since this involves a dozen modules and hundreds of source files, I need
to
   split them into many PRs, and some of them require CSR. Reviewing them
may
   take a long time, this step will be done slowly in the future.

4. Deprecate the two methods.

   This step may take place much later.

This is my idea, and I hope to receive your opinion.

Glavo

On Fri, Apr 14, 2023 at 12:08?AM Naoto Sato <naoto.sato at oracle.com> wrote:

> I too agree with Roger that deprecation would have high bar.
>
> Another possibility to mitigate the situation rather than introducing
> the new methods is to introduce a new system property and let the users
> decide the default (yes, yet another property, but I believe it
> warrants). Say,
>
> java.lang.String.defaultCaseLocale=[root/display/format]
>
> where each value designates
>
> root -> Locale.ROOT
> display -> Locale.getDefault(Locale.Category.DISPLAY)
> format -> Locale.getDefault(Locale.Category.FORMAT)
>
> The choice for the "default" default have room to discuss, but format
> may not be bad choice.
>
> As to the current spec, we can emphasize the Turkish issue more visible
> by making "Notes:" to @apiNote.
>
> Naoto
>
> On 4/13/23 8:39 AM, Eirik Bj?rsn?s wrote:
> >     In that case, isn't there something a little backwards about saying
> >     we should continue sweeping them under the rug? (Am I being too
> >     idealistic?)
> >
> >
> > I sympathise with the concern of causing many warnings/errors, and the
> > right time to do these things never seems to be "now".
> >
> > But let's look at it this way: The Turkish population alone is
> > currently 1.08 percent of the world population. If we assume the number
> > of Java apps/services per capita is the same around the world, this
> > means that these methods may return the expected result in 98.92 percent
> > of the executions. I think that's a bit scary.
> >
> > Deprecating these methods would require consensus and support from
> > reviewers, which we don't seem to have at the moment. So I think the
> > current focus on fixing the uses inside OpenJDK and then adding
> > alternatives first seems good. Then, maybe someday.. :-)
> >
> > Eirik.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230414/13c4c2ba/attachment.htm>

From rriggs at openjdk.org  Thu Apr 13 18:13:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Apr 2023 18:13:19 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
Message-ID: <U7ScSkaMKh0oLYW_3qPtTc0dX6rU67_-YBirL9G0QpI=.0fd09d8d-1fd6-4f0b-9b9a-77e79b760fee@github.com>

On Wed, 12 Apr 2023 19:02:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

The PreviewFeature annotations can/should be removed from classes/methods that are not part of the public interface. They are unnecessary and possibly misleading, implying part of the public interface.

src/java.base/share/classes/java/lang/runtime/Carriers.java line 554:

> 552: 
> 553:     /**
> 554:      * Class used to tally ahd track the number of ints, longs and objects.

typo: ahd

src/java.base/share/classes/jdk/internal/util/FormatConcatItem.java line 37:

> 35:  * @since 21
> 36:  */
> 37: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)

Generally, The `PreviewFeature` annotation is not needed on internal APIs and serves little purpose.

-------------

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1383555414
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165702256
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165631226

From rriggs at openjdk.org  Thu Apr 13 18:13:25 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Apr 2023 18:13:25 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v61]
In-Reply-To: <jayHaXL1Rijkezg5u8iUXIYB0NVds5SnQITdu1NtsUg=.c69b7ca8-d363-4489-ac29-029ae62ec2f1@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <jayHaXL1Rijkezg5u8iUXIYB0NVds5SnQITdu1NtsUg=.c69b7ca8-d363-4489-ac29-029ae62ec2f1@github.com>
Message-ID: <PM3kLa9PJ7UhH2SajPm1HwBzBZDUEFDuHz8oupWyFIo=.1a2ea76a-87ff-498c-9b04-624977ee0b11@github.com>

On Thu, 13 Apr 2023 17:09:13 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo

src/jdk.incubator.concurrent/share/classes/module-info.java line 35:

> 33:     exports jdk.incubator.concurrent;
> 34: }
> 35: 

Not related to StringTemplates; could be left as is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165615588

From naoto at openjdk.org  Thu Apr 13 18:14:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Apr 2023 18:14:34 GMT
Subject: RFR: 8305904: java/lang/Character,
 java/lang/String and java/text/Normalizer tests read the unicode data files
 from src directories.
In-Reply-To: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
References: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
Message-ID: <4JLfFmxw_NNLt6ArRgxmxCl7cSfmj0ljX6k77ZDHaac=.69c4ee18-b584-4018-8be7-8ea6258ffb4d@github.com>

On Wed, 12 Apr 2023 16:35:19 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Following tests read the unicode data files (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, these files should be in test directories. No source code is using these files. Only tests are using these files. Tests are :
> java/lang/Character/CharPropTest.java
> java/lang/Character/CheckProp.java
> java/lang/Character/CheckScript.java
> java/lang/Character/CheckUnicode.java
> java/lang/Character/UnicodeBlock/CheckBlocks.java
> java/lang/Character/UnicodeCasingTest.java
> java/lang/String/SpecialCasingTest.java
> java/lang/String/UnicodeCasingTest.java
> java/text/Normalizer/ConformanceTest.java

Missed that the intended change is not duplicating but moving from src->test. No this is not correct.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13447#issuecomment-1507411392

From jlaskey at openjdk.org  Thu Apr 13 19:01:09 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 19:01:09 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v61]
In-Reply-To: <PM3kLa9PJ7UhH2SajPm1HwBzBZDUEFDuHz8oupWyFIo=.1a2ea76a-87ff-498c-9b04-624977ee0b11@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <jayHaXL1Rijkezg5u8iUXIYB0NVds5SnQITdu1NtsUg=.c69b7ca8-d363-4489-ac29-029ae62ec2f1@github.com>
 <PM3kLa9PJ7UhH2SajPm1HwBzBZDUEFDuHz8oupWyFIo=.1a2ea76a-87ff-498c-9b04-624977ee0b11@github.com>
Message-ID: <AEK10ysW4cwzgdKz1H9C1YjE_3ZI-iL2GXKrjBBmqjU=.bdd162b1-aff4-4d5c-a4ed-d273f4444d72@github.com>

On Thu, 13 Apr 2023 14:30:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo
>
> src/jdk.incubator.concurrent/share/classes/module-info.java line 35:
> 
>> 33:     exports jdk.incubator.concurrent;
>> 34: }
>> 35: 
> 
> Not related to StringTemplates; could be left as is.

Agree - I think it must have been a merge issue. I don't recall having a need to change this file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165914905

From jlaskey at openjdk.org  Thu Apr 13 19:01:05 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 19:01:05 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <U7ScSkaMKh0oLYW_3qPtTc0dX6rU67_-YBirL9G0QpI=.0fd09d8d-1fd6-4f0b-9b9a-77e79b760fee@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
 <U7ScSkaMKh0oLYW_3qPtTc0dX6rU67_-YBirL9G0QpI=.0fd09d8d-1fd6-4f0b-9b9a-77e79b760fee@github.com>
Message-ID: <TxUiPpReLmcDuL49va3jxFdzd2eI87l0JUrGSP4hARo=.3102ce2e-29e5-4c66-9495-fa3d9c6f09d5@github.com>

On Thu, 13 Apr 2023 15:27:12 GMT, Roger Riggs <rriggs 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 75 commits:
>> 
>>  - Merge branch 'master' into 8285932
>>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>>  - Clean up Error handling
>>  - Recommended changes
>>  - RuntimeException is the only exception type that can is deduced from a lambda.
>>  - Update combine example
>>  - Merge branch 'master' into 8285932
>>  - Update StringTemplate.combine javadoc
>>  - Requested review changes.
>>  - Clean up list construction
>>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1
>
> src/java.base/share/classes/java/lang/runtime/Carriers.java line 554:
> 
>> 552: 
>> 553:     /**
>> 554:      * Class used to tally ahd track the number of ints, longs and objects.
> 
> typo: ahd

Will fix.

> src/java.base/share/classes/jdk/internal/util/FormatConcatItem.java line 37:
> 
>> 35:  * @since 21
>> 36:  */
>> 37: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 
> Generally, The `PreviewFeature` annotation is not needed on internal APIs and serves little purpose.

PreviewFeature might be heavy handed. I can replace it with a warning to not depend on this file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165915844
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165915665

From jlaskey at openjdk.org  Thu Apr 13 19:45:59 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 19:45:59 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v62]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <EshG5qcfwecXSS9cQj-3YH3tayV0xuXKUkMqQuUvlSo=.b9e627d5-22f9-4326-9780-d069df8d5aa3@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from non-public classes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/f27ad709..70c215c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=61
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=60-61

  Stats: 54 lines in 10 files changed: 30 ins; 23 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From rriggs at openjdk.org  Thu Apr 13 20:28:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Apr 2023 20:28:51 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v62]
In-Reply-To: <EshG5qcfwecXSS9cQj-3YH3tayV0xuXKUkMqQuUvlSo=.b9e627d5-22f9-4326-9780-d069df8d5aa3@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <EshG5qcfwecXSS9cQj-3YH3tayV0xuXKUkMqQuUvlSo=.b9e627d5-22f9-4326-9780-d069df8d5aa3@github.com>
Message-ID: <3v1bFtY5NV-SJ2oeYKedlQfsLCCFCsxq2dOW1CaFd5E=.ba437051-8d3e-488c-8173-b46cf34ac5d2@github.com>

On Thu, 13 Apr 2023 19:45:59 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from non-public classes

Core library files look good to me.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1384156858

From naoto at openjdk.org  Thu Apr 13 20:43:22 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Apr 2023 20:43:22 GMT
Subject: RFR: 8296248: Update CLDR to Version 43.0
Message-ID: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>

Upgrading the CLDR to [version 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual release is their `limited-submission` release so I would not expect regressions caused by formatting changes as we had in JDK20/CLDRv42 (https://inside.java/2023/03/28/quality-heads-up/)

-------------

Commit messages:
 - v42 -> v43 in README, .md files
 - release-43
 - Removed sr-Latn (https://unicode-org.atlassian.net/browse/CLDR-16449)
 - release-43-beta5
 - release-43-beta4
 - release-43-beta3
 - release-43-beta1
 - release-43-beta0
 - Fixing IncludeLocalesPluginTest.java not to include below `basic` locales
 - release-43-alpha2
 - ... and 5 more: https://git.openjdk.org/jdk/compare/92521b10...d61ccf0f

Changes: https://git.openjdk.org/jdk/pull/13469/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13469&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296248
  Stats: 209680 lines in 1036 files changed: 199351 ins; 2906 del; 7423 mod
  Patch: https://git.openjdk.org/jdk/pull/13469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13469/head:pull/13469

PR: https://git.openjdk.org/jdk/pull/13469

From duke at openjdk.org  Thu Apr 13 20:50:37 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Thu, 13 Apr 2023 20:50:37 GMT
Subject: RFR: 8296248: Update CLDR to Version 43.0
In-Reply-To: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
References: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
Message-ID: <zbwxS7_hkDmaDj1DO8wSf9k075dQmeQ8yd-P1YI5hB4=.a110cf9f-3588-4c57-9917-467cc9a31ad2@github.com>

On Thu, 13 Apr 2023 20:20:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the CLDR to [version 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual release is their `limited-submission` release so I would not expect regressions caused by formatting changes as we had in JDK20/CLDRv42 (https://inside.java/2023/03/28/quality-heads-up/)

Marked as reviewed by srl295 at github.com (no known OpenJDK username).

make/data/cldr/common/main/ken.xml line 19:

> 17: 	</localeDisplayNames>
> 18: 	<characters>
> 19: 		<exemplarCharacters>[a ? ? ? b c d e ? ? ? ? {?\u0301} {?\u0300} {?\u030C} f g {gb} {gh} h i ? {?\u0301} {?\u0300} {?\u030C} j k {kp} m n {ny} ? o ? ? ? ? {?\u0301} {?\u0300} {?\u030C} p r s t u ? ? ? ? {?\u0301} {?\u0300} {?\u030C} w y]</exemplarCharacters>

@naotoj  this is in common/main but not at basic level??is this intentional?

make/data/cldr/common/properties/coverageLevels.txt line 115:

> 113: sq ;	modern ;	Albanian
> 114: sr ;	modern ;	Serbian
> 115: sr_Latn ;	modern ;	Serbian (Latin)

@naotoj BTW this was fixed

src/java.base/share/legal/cldr.md line 1:

> 1: ## Unicode Common Local Data Repository (CLDR) v43

BTW the license is now just named `LICENSE` in the repo starting with v44

-------------

PR Review: https://git.openjdk.org/jdk/pull/13469#pullrequestreview-1384183612
PR Review Comment: https://git.openjdk.org/jdk/pull/13469#discussion_r1166009340
PR Review Comment: https://git.openjdk.org/jdk/pull/13469#discussion_r1166009761
PR Review Comment: https://git.openjdk.org/jdk/pull/13469#discussion_r1166010264

From duke at openjdk.org  Thu Apr 13 20:56:31 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Thu, 13 Apr 2023 20:56:31 GMT
Subject: RFR: 8296248: Update CLDR to Version 43.0
In-Reply-To: <zbwxS7_hkDmaDj1DO8wSf9k075dQmeQ8yd-P1YI5hB4=.a110cf9f-3588-4c57-9917-467cc9a31ad2@github.com>
References: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
 <zbwxS7_hkDmaDj1DO8wSf9k075dQmeQ8yd-P1YI5hB4=.a110cf9f-3588-4c57-9917-467cc9a31ad2@github.com>
Message-ID: <2XosFvSf2Grsbxdvt49z4d5JaA4qkgjcJ80kdRsqriU=.b40fb4cc-5ffe-426e-9130-a3a128cc20de@github.com>

On Thu, 13 Apr 2023 20:47:39 GMT, Steven R. Loomis <duke at openjdk.org> wrote:

>> Upgrading the CLDR to [version 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual release is their `limited-submission` release so I would not expect regressions caused by formatting changes as we had in JDK20/CLDRv42 (https://inside.java/2023/03/28/quality-heads-up/)
>
> Marked as reviewed by srl295 at github.com (no known OpenJDK username).

`@srl295 (no known openjdk.org user name / role)` ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13469#issuecomment-1507597408

From naoto at openjdk.org  Thu Apr 13 21:42:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Apr 2023 21:42:46 GMT
Subject: RFR: 8296248: Update CLDR to Version 43.0
In-Reply-To: <zbwxS7_hkDmaDj1DO8wSf9k075dQmeQ8yd-P1YI5hB4=.a110cf9f-3588-4c57-9917-467cc9a31ad2@github.com>
References: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
 <zbwxS7_hkDmaDj1DO8wSf9k075dQmeQ8yd-P1YI5hB4=.a110cf9f-3588-4c57-9917-467cc9a31ad2@github.com>
Message-ID: <KxrbbEJ6ISiH2cwrp0OqbwhU41OpnBuBKoE9r-rZBm0=.7c8ce9b4-a662-4031-9fc5-6154a24faacb@github.com>

On Thu, 13 Apr 2023 20:46:10 GMT, Steven R. Loomis <duke at openjdk.org> wrote:

>> Upgrading the CLDR to [version 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual release is their `limited-submission` release so I would not expect regressions caused by formatting changes as we had in JDK20/CLDRv42 (https://inside.java/2023/03/28/quality-heads-up/)
>
> make/data/cldr/common/main/ken.xml line 19:
> 
>> 17: 	</localeDisplayNames>
>> 18: 	<characters>
>> 19: 		<exemplarCharacters>[a ? ? ? b c d e ? ? ? ? {?\u0301} {?\u0300} {?\u030C} f g {gb} {gh} h i ? {?\u0301} {?\u0300} {?\u030C} j k {kp} m n {ny} ? o ? ? ? ? {?\u0301} {?\u0300} {?\u030C} p r s t u ? ? ? ? {?\u0301} {?\u0300} {?\u030C} w y]</exemplarCharacters>
> 
> @naotoj  this is in common/main but not at basic level??is this intentional?

JDK keeps CLDR sources intact. On building JDK, .xml files are transformed into ResourceBundles and those not at the basic level are filtered out.

> make/data/cldr/common/properties/coverageLevels.txt line 115:
> 
>> 113: sq ;	modern ;	Albanian
>> 114: sr ;	modern ;	Serbian
>> 115: sr_Latn ;	modern ;	Serbian (Latin)
> 
> @naotoj BTW this was fixed

Yes. The patch before was removed with this commit: https://github.com/openjdk/jdk/pull/13469/commits/0e3456c8924960dc0bc488b08b9763bd08557a68

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13469#discussion_r1166055276
PR Review Comment: https://git.openjdk.org/jdk/pull/13469#discussion_r1166055288

From smarks at openjdk.org  Thu Apr 13 21:46:02 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 13 Apr 2023 21:46:02 GMT
Subject: RFR: 8266571: Sequenced Collections [v5]
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: <17ElTlcIN44pYZm5WC46oHw2Ayxi8qoa3wbqbu6A7FY=.fac021df-3cbd-4bc1-bfae-3846afcc39e1@github.com>

> 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 80 commits:

 - Merge branch 'master' into JDK-8266571-SequencedCollections
 - Simplify handling of cached keySet, values, and entrySet views.
 - Merge branch 'master' into JDK-8266571-SequencedCollections
 - Update copyrights.
 - More specification tweaks.
 - Add simple overrides to ArrayList.
 - Specification cleanups.
 - Update spec of CopyOnWriteArrayList::reversed.
 - Move AbstractViewCollection to AbstractMap.ViewCollection to avoid exposing it publicly.
 - Merge branch 'master' into JDK-8266571-SequencedCollections
   Resolve conflict by deleting IdentityLinkedList.java
 - ... and 70 more: https://git.openjdk.org/jdk/compare/76cda9f4...1332c3e2

-------------

Changes: https://git.openjdk.org/jdk/pull/7387/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=04
  Stats: 6644 lines in 39 files changed: 6509 ins; 11 del; 124 mod
  Patch: https://git.openjdk.org/jdk/pull/7387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/7387/head:pull/7387

PR: https://git.openjdk.org/jdk/pull/7387

From naoto at openjdk.org  Thu Apr 13 23:45:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Apr 2023 23:45:45 GMT
Subject: RFR: 8296248: Update CLDR to Version 43.0 [v2]
In-Reply-To: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
References: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
Message-ID: <bdQ09nn5FNT4PShAwGqWV6L9gBv5yt7VRNAtpUXshHE=.f4ae637a-f077-4fa6-8b86-2b26589b9178@github.com>

> Upgrading the CLDR to [version 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual release is their `limited-submission` release so I would not expect regressions caused by formatting changes as we had in JDK20/CLDRv42 (https://inside.java/2023/03/28/quality-heads-up/)

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Short ID test for "America/Ciudad_Juarez"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13469/files
  - new: https://git.openjdk.org/jdk/pull/13469/files/d61ccf0f..7211ffd3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13469&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13469&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13469/head:pull/13469

PR: https://git.openjdk.org/jdk/pull/13469

From kbarrett at openjdk.org  Fri Apr 14 05:03:32 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 14 Apr 2023 05:03:32 GMT
Subject: RFR: 8305762: FileInputStream and FileOutputStream implSpec should
 be corrected or removed
In-Reply-To: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
References: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
Message-ID: <jmTzgWjJNaxOyC85gnB2BFYobfW4lFOXNmngGXErF7s=.b0849878-c30d-4fbd-a769-42b07fae4477@github.com>

On Tue, 11 Apr 2023 23:55:50 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> With the removal of the AltFinalizer mechanism from `FileInputStream` and `FileOutputStream` in [JDK-8192939](https://bugs.openjdk.org/browse/JDK-8192939), this portion of the Implementation Requirement in the class JavaDoc is no longer true:
> 
>> If this FileOutputStream has been subclassed and the close() method has been overridden, the close() method will be called when the FileInputStream is unreachable."
> 
> The class doc, and the doc for close(), are updated to correctly reflect current behavior, and guidance for subclasses is clarified.

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13437#pullrequestreview-1384600764

From alanb at openjdk.org  Fri Apr 14 08:00:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Apr 2023 08:00:41 GMT
Subject: RFR: 8305762: FileInputStream and FileOutputStream implSpec should
 be corrected or removed
In-Reply-To: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
References: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
Message-ID: <8IXpgKy4qK1woM-A3yu8Xn-r4YPrsdOx2PvpXbEImEU=.5690beb6-79e6-4a45-837b-f2d362eb247d@github.com>

On Tue, 11 Apr 2023 23:55:50 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> With the removal of the AltFinalizer mechanism from `FileInputStream` and `FileOutputStream` in [JDK-8192939](https://bugs.openjdk.org/browse/JDK-8192939), this portion of the Implementation Requirement in the class JavaDoc is no longer true:
> 
>> If this FileOutputStream has been subclassed and the close() method has been overridden, the close() method will be called when the FileInputStream is unreachable."
> 
> The class doc, and the doc for close(), are updated to correctly reflect current behavior, and guidance for subclasses is clarified.

src/java.base/share/classes/java/io/FileInputStream.java line 45:

> 43:  * @apiNote
> 44:  * To release resources used by this stream {@link #close} should be called
> 45:  * directly or by try-with-resources.

I wonder if we should re-word the API note at the same time. I think it would be more readable to start with "The close method should be called ...".

src/java.base/share/classes/java/io/FileInputStream.java line 50:

> 48:  * Subclasses are responsible for the cleanup of resources acquired by the subclass.
> 49:  * Subclasses requiring that resource cleanup take place after a stream becomes
> 50:  * unreachable should use the {@link java.lang.ref.Cleaner} mechanism.

This is in the style of an API note for implementors so implSpec is appropriate here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13437#discussion_r1166446385
PR Review Comment: https://git.openjdk.org/jdk/pull/13437#discussion_r1166441998

From duke at openjdk.org  Fri Apr 14 09:19:46 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 14 Apr 2023 09:19:46 GMT
Subject: Integrated: JDK-8170945: Collectors$Partition should override more Map
 methods
In-Reply-To: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
References: <QzHKVzqmcpZRmONd59u-z7nvs1dXxbtxsNjmKkRm8Qk=.ecd01e18-a2cb-4b1d-8356-98cb45dc0d4f@github.com>
Message-ID: <zb8NEXixO1WZsjDyFZ_Rayd5UJnzxs4gFRyQRRIc80g=.89a07b68-0eba-4b3e-af48-e81996e77873@github.com>

On Wed, 5 Apr 2023 09:19:57 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Adds overrides for common Map operations to avoid having to allocate the entrySet for Collectors$Partition maps.

This pull request has now been integrated.

Changeset: 54bf3700
Author:    Viktor Klang <viktor.klang at oracle.com>
Committer: Tagir F. Valeev <tvaleev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/54bf37007959065d5a2c3b7a9d5062f9c682dc4c
Stats:     29 lines in 1 file changed: 29 ins; 0 del; 0 mod

8170945: Collectors$Partition should override more Map methods

Reviewed-by: smarks

-------------

PR: https://git.openjdk.org/jdk/pull/13347

From jpai at openjdk.org  Fri Apr 14 12:28:33 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Apr 2023 12:28:33 GMT
Subject: RFR: 8041676: remove the java.compiler system property
Message-ID: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>

Can I please get a review of this change which removes the `java.compiler` system property? This addresses https://bugs.openjdk.org/browse/JDK-8041676.

A CSR has been filed for this change and is available at https://bugs.openjdk.org/browse/JDK-8305998. The CSR has more details about this proposed change, but to summarize, the `java.compiler` system property wasn't used in any practical way. With the recent removal of `java.lang.Compiler` interface from the JDK, the presence of this system property wasn't of any practical importance.

The commit in this PR, removes its reference from the `System.getProperties()` documentation and also removes the specific implementation from hotspot where it treated the values `NONE` and empty string in the absence of `-Xdebug` in a specific manner and considered it to be an instruction to run the application in interpreter-only mode. `-Xint` option has been around for this purpose, so removal of this `java.compiler` system property support from hotspot implementation wouldn't remove any usable feature for the applications.

Additionally, the hotspot implementation now logs a warning message when it detects the presence of `java.compiler` system property when `java` is launched. This warning message will be removed after a few releases.

The current JDK source has reference to the `java.compiler` system property in numerous NetBeans project build files. The usage of this system property in such files isn't necessary. However, this PR doesn't intend to cleanup those references, since it isn't clear which of those NetBeans projects are still relevant. I think we can use a separate PR to do that cleanup.

tier1, tier2, tier3 testing has been done with these changes and those tests have passed.

-------------

Commit messages:
 - 8041676: remove the java.compiler system property

Changes: https://git.openjdk.org/jdk/pull/13475/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13475&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8041676
  Stats: 36 lines in 3 files changed: 7 ins; 27 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13475/head:pull/13475

PR: https://git.openjdk.org/jdk/pull/13475

From jlahoda at openjdk.org  Fri Apr 14 12:56:51 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 14 Apr 2023 12:56:51 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch
Message-ID: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>

This is the first draft of a patch for JEP 440 and JEP 441. Changes included:

 - the pattern matching for switch and record patterns features are made final, together with updates to tests.
 - parenthesized patterns are removed.
 - qualified enum constants are supported for case labels.

This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

-------------

Commit messages:
 - Fixing test.
 - Assignment to variables declared outside of guard not allowed.
 - Adding test for incorrectly used guards.
 - Merge branch 'master' into JDK-8300543
 - Merge branch 'master' into JDK-8300543
 - Removing trailing whitespace
 - Fixing tests.
 - Post-merge fix.
 - Merge remote-tracking branch 'jdk/reduce-exhaustiveness' into JDK-8300543
 - Support for 'overfitting' patterns.
 - ... and 15 more: https://git.openjdk.org/jdk/compare/cd7d53c8...57445212

Changes: https://git.openjdk.org/jdk/pull/13074/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300543
  Stats: 3662 lines in 157 files changed: 1552 ins; 1682 del; 428 mod
  Patch: https://git.openjdk.org/jdk/pull/13074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074

PR: https://git.openjdk.org/jdk/pull/13074

From jlahoda at openjdk.org  Fri Apr 14 12:56:51 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 14 Apr 2023 12:56:51 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <OA-AkG7E_2g1a_ZIJZVXi0g3i6_9T38LA-q5ypfK1JM=.84ea5ea8-8ac3-42dc-aace-aa83224f9659@github.com>

On Fri, 17 Mar 2023 12:15:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

There's still an open question on enum initialization, but  I'd welcome feedback on the patch. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13074#issuecomment-1508458643

From cwimmer at openjdk.org  Fri Apr 14 12:56:53 2023
From: cwimmer at openjdk.org (Christian Wimmer)
Date: Fri, 14 Apr 2023 12:56:53 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <MkM1D2pdh94wX3KKNo7_Xl_6u8B_5XsDQSodrb5B6VE=.b32b036a-68b7-4360-a9c2-6bccd7f10332@github.com>

On Fri, 17 Mar 2023 12:15:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 1:

> 1: /*

@lahodaj  The way that the boostrap method `enumSwitch` and its corresponding implementation method `doEnumSwitch` are implemented right now has an unfortunate side effect on class initialization: since the bootstrap method already looks up the actual enum values, it triggers class initialization of the enum. This is not a problem when the switched value is non-null, because then obviously the enum is already initialized. But when the switched value is `null`, then the boostrap method triggers class initialization.

Example:

enum E { 
    A, B;

    static {
        new Throwable("Hello, World!").printStackTrace();
    }
}


public class SwitchTest {

    public static int testMethod(E selExpr) {
        return switch (selExpr) {
            case A -> 3;
            case B -> 6;
            case null -> -1;
        };
    }

    public static void main(String argv[]) {
        System.out.println(testMethod(null));
    }
}


It produces the following output (on JDK 20, but I don't see any changes in this PR that would alter the behavior):

java.lang.Throwable: Hello, World!
	at E.<clinit>(SwitchTest.java:5)
	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1160)
	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.ensureClassInitialized(MethodHandleAccessorFactory.java:300)
	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.newMethodAccessor(MethodHandleAccessorFactory.java:71)
	at java.base/jdk.internal.reflect.ReflectionFactory.newMethodAccessor(ReflectionFactory.java:159)
	at java.base/java.lang.reflect.Method.acquireMethodAccessor(Method.java:724)
	at java.base/java.lang.reflect.Method.invoke(Method.java:575)
	at java.base/java.lang.Class.getEnumConstantsShared(Class.java:3938)
	at java.base/java.lang.Class.enumConstantDirectory(Class.java:3961)
	at java.base/java.lang.Enum.valueOf(Enum.java:268)
	at java.base/java.lang.invoke.ConstantBootstraps.enumConstant(ConstantBootstraps.java:144)
	at java.base/java.lang.runtime.SwitchBootstraps.convertEnumConstants(SwitchBootstraps.java:262)
	at java.base/java.lang.runtime.SwitchBootstraps.lambda$enumSwitch$0(SwitchBootstraps.java:238)
	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
	at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:1006)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575)
	at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622)
	at java.base/java.lang.runtime.SwitchBootstraps.enumSwitch(SwitchBootstraps.java:238)
	at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:147)
	at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:316)
	at java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:279)
	at java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:269)
	at SwitchTest.testMethod(SwitchTest.java:13)
	at SwitchTest.main(SwitchTest.java:21)
-1

I argue this is bad because in general because every unnecessary class initialization (and its side effects) should be avoided.

But it is really a problem for any kind of eager-bootstrapping system, like Project Leyden or GraalVM Native Image: if it is not possible to execute the bootstrap methods early due to possible side effects, optimizations are quite limited and the bootstrap method needs to be executed at run time.

A simple solution would be to keep the elements in the data array as `String` instead of enum elements, and in `doEnumSwitch` do a `== target.name` (the method has the comment `// Dumbest possible strategy` anyways).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1164570743

From jlahoda at openjdk.org  Fri Apr 14 12:56:54 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 14 Apr 2023 12:56:54 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch
In-Reply-To: <MkM1D2pdh94wX3KKNo7_Xl_6u8B_5XsDQSodrb5B6VE=.b32b036a-68b7-4360-a9c2-6bccd7f10332@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <MkM1D2pdh94wX3KKNo7_Xl_6u8B_5XsDQSodrb5B6VE=.b32b036a-68b7-4360-a9c2-6bccd7f10332@github.com>
Message-ID: <9K4KarU9rZTTQSyryAkDoyNrpx0G-kv0DAcLPng5AX0=.c0ff9d7d-7ea4-4a9e-9ff3-304a5788b9af@github.com>

On Wed, 12 Apr 2023 19:47:25 GMT, Christian Wimmer <cwimmer at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 1:
> 
>> 1: /*
> 
> @lahodaj  The way that the boostrap method `enumSwitch` and its corresponding implementation method `doEnumSwitch` are implemented right now has an unfortunate side effect on class initialization: since the bootstrap method already looks up the actual enum values, it triggers class initialization of the enum. This is not a problem when the switched value is non-null, because then obviously the enum is already initialized. But when the switched value is `null`, then the boostrap method triggers class initialization.
> 
> Example:
> 
> enum E { 
>     A, B;
> 
>     static {
>         new Throwable("Hello, World!").printStackTrace();
>     }
> }
> 
> 
> public class SwitchTest {
> 
>     public static int testMethod(E selExpr) {
>         return switch (selExpr) {
>             case A -> 3;
>             case B -> 6;
>             case null -> -1;
>         };
>     }
> 
>     public static void main(String argv[]) {
>         System.out.println(testMethod(null));
>     }
> }
> 
> 
> It produces the following output (on JDK 20, but I don't see any changes in this PR that would alter the behavior):
> 
> java.lang.Throwable: Hello, World!
> 	at E.<clinit>(SwitchTest.java:5)
> 	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
> 	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1160)
> 	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.ensureClassInitialized(MethodHandleAccessorFactory.java:300)
> 	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.newMethodAccessor(MethodHandleAccessorFactory.java:71)
> 	at java.base/jdk.internal.reflect.ReflectionFactory.newMethodAccessor(ReflectionFactory.java:159)
> 	at java.base/java.lang.reflect.Method.acquireMethodAccessor(Method.java:724)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:575)
> 	at java.base/java.lang.Class.getEnumConstantsShared(Class.java:3938)
> 	at java.base/java.lang.Class.enumConstantDirectory(Class.java:3961)
> 	at java.base/java.lang.Enum.valueOf(Enum.java:268)
> 	at java.base/java.lang.invoke.ConstantBootstraps.enumConstant(ConstantBootstraps.java:144)
> 	at java.base/java.lang.runtime.SwitchBootstraps.convertEnumConstants(SwitchBootstraps.java:262)
> 	at java.base/java.lang.runtime.SwitchBootstraps.lambda$enumSwitch$0(SwitchBootstraps.java:238)
> 	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
> 	at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:1006)
> 	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
> 	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> 	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575)
> 	at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> 	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
> 	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622)
> 	at java.base/java.lang.runtime.SwitchBootstraps.enumSwitch(SwitchBootstraps.java:238)
> 	at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:147)
> 	at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:316)
> 	at java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:279)
> 	at java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:269)
> 	at SwitchTest.testMethod(SwitchTest.java:13)
> 	at SwitchTest.main(SwitchTest.java:21)
> -1
> 
> I argue this is bad because in general because every unnecessary class initialization (and its side effects) should be avoided.
> 
> But it is really a problem for any kind of eager-bootstrapping system, like Project Leyden or GraalVM Native Image: if it is not possible to execute the bootstrap methods early due to possible side effects, optimizations are quite limited and the bootstrap method needs to be executed at run time.
> 
> A simple solution would be to keep the elements in the data array as `String` instead of enum elements, and in `doEnumSwitch` do a `== target.name` (the method has the comment `// Dumbest possible strategy` anyways).

Hi Christian,

Thanks for the comment.

First, the "Dumbest possible strategy" comment should be interpreted as "we would like to do something better", not that using something slow is OK permanently. There's an attempt to do performance improvements here:
https://github.com/openjdk/jdk/pull/9779

Talking of `enumSwitch` for now (some more on `typeSwitch` later), one thing what I would like allow for the long(er) term are fast(er) implementations. If we just used `String` comparison, it would be extremely difficult to get a really good performance, even for cases where e.g. all the input values are enum constants, where the method can be reduced to a map lookup (as 9779 does).

I think we could probably still avoid the "eager" class initialization, at the cost of using the `MutableCallSite` - first, we would produce a temporary MethodHandle, and on the first non-`null` call (when the class apparently must be initialized), we would produce the real (possibly optimized) MethodHandle.

I suspect (although I may be wrong) that the eager systems may not be able to work with such a call site, but those should be able to replace the bootstrap with a custom static version without changing the semantics in any way.

A slightly bigger problem is `typeSwitch`: a new feature is that enum constants can be part of any pattern matching switch. Like:


enum E {A}
...
Object o = ...;
switch (o) {
    case E.A -> ...
    ...
}


For this, even `typeSwitch` permits enum constants now, and `java.lang.invoke.ConstantBootstraps.enumConstant` is used for that currently. We would probably need a wrapper to describe the enum constant that could be used by `typeSwitch` to avoid initialization (+the `MutableCallSite`, of course).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1165138263

From duke at openjdk.org  Fri Apr 14 12:56:55 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 14 Apr 2023 12:56:55 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch
In-Reply-To: <9K4KarU9rZTTQSyryAkDoyNrpx0G-kv0DAcLPng5AX0=.c0ff9d7d-7ea4-4a9e-9ff3-304a5788b9af@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <MkM1D2pdh94wX3KKNo7_Xl_6u8B_5XsDQSodrb5B6VE=.b32b036a-68b7-4360-a9c2-6bccd7f10332@github.com>
 <9K4KarU9rZTTQSyryAkDoyNrpx0G-kv0DAcLPng5AX0=.c0ff9d7d-7ea4-4a9e-9ff3-304a5788b9af@github.com>
Message-ID: <2svC_yItHpRmOPAkn9PD1rQ_3cEFdXLhbWo0Dw9bU68=.60c529bc-1d52-4159-b395-7fd6c4915c81@github.com>

On Thu, 13 Apr 2023 07:49:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 1:
>> 
>>> 1: /*
>> 
>> @lahodaj  The way that the boostrap method `enumSwitch` and its corresponding implementation method `doEnumSwitch` are implemented right now has an unfortunate side effect on class initialization: since the bootstrap method already looks up the actual enum values, it triggers class initialization of the enum. This is not a problem when the switched value is non-null, because then obviously the enum is already initialized. But when the switched value is `null`, then the boostrap method triggers class initialization.
>> 
>> Example:
>> 
>> enum E { 
>>     A, B;
>> 
>>     static {
>>         new Throwable("Hello, World!").printStackTrace();
>>     }
>> }
>> 
>> 
>> public class SwitchTest {
>> 
>>     public static int testMethod(E selExpr) {
>>         return switch (selExpr) {
>>             case A -> 3;
>>             case B -> 6;
>>             case null -> -1;
>>         };
>>     }
>> 
>>     public static void main(String argv[]) {
>>         System.out.println(testMethod(null));
>>     }
>> }
>> 
>> 
>> It produces the following output (on JDK 20, but I don't see any changes in this PR that would alter the behavior):
>> 
>> java.lang.Throwable: Hello, World!
>> 	at E.<clinit>(SwitchTest.java:5)
>> 	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
>> 	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1160)
>> 	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.ensureClassInitialized(MethodHandleAccessorFactory.java:300)
>> 	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.newMethodAccessor(MethodHandleAccessorFactory.java:71)
>> 	at java.base/jdk.internal.reflect.ReflectionFactory.newMethodAccessor(ReflectionFactory.java:159)
>> 	at java.base/java.lang.reflect.Method.acquireMethodAccessor(Method.java:724)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:575)
>> 	at java.base/java.lang.Class.getEnumConstantsShared(Class.java:3938)
>> 	at java.base/java.lang.Class.enumConstantDirectory(Class.java:3961)
>> 	at java.base/java.lang.Enum.valueOf(Enum.java:268)
>> 	at java.base/java.lang.invoke.ConstantBootstraps.enumConstant(ConstantBootstraps.java:144)
>> 	at java.base/java.lang.runtime.SwitchBootstraps.convertEnumConstants(SwitchBootstraps.java:262)
>> 	at java.base/java.lang.runtime.SwitchBootstraps.lambda$enumSwitch$0(SwitchBootstraps.java:238)
>> 	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
>> 	at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:1006)
>> 	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
>> 	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
>> 	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575)
>> 	at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
>> 	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
>> 	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622)
>> 	at java.base/java.lang.runtime.SwitchBootstraps.enumSwitch(SwitchBootstraps.java:238)
>> 	at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:147)
>> 	at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:316)
>> 	at java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:279)
>> 	at java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:269)
>> 	at SwitchTest.testMethod(SwitchTest.java:13)
>> 	at SwitchTest.main(SwitchTest.java:21)
>> -1
>> 
>> I argue this is bad because in general because every unnecessary class initialization (and its side effects) should be avoided.
>> 
>> But it is really a problem for any kind of eager-bootstrapping system, like Project Leyden or GraalVM Native Image: if it is not possible to execute the bootstrap methods early due to possible side effects, optimizations are quite limited and the bootstrap method needs to be executed at run time.
>> 
>> A simple solution would be to keep the elements in the data array as `String` instead of enum elements, and in `doEnumSwitch` do a `== target.name` (the method has the comment `// Dumbest possible strategy` anyways).
>
> Hi Christian,
> 
> Thanks for the comment.
> 
> First, the "Dumbest possible strategy" comment should be interpreted as "we would like to do something better", not that using something slow is OK permanently. There's an attempt to do performance improvements here:
> https://github.com/openjdk/jdk/pull/9779
> 
> Talking of `enumSwitch` for now (some more on `typeSwitch` later), one thing what I would like allow for the long(er) term are fast(er) implementations. If we just used `String` comparison, it would be extremely difficult to get a really good performance, even for cases where e.g. all the input values are enum constants, where the method can be reduced to a map lookup (as 9779 does).
> 
> I think we could probably still avoid the "eager" class initialization, at the cost of using the `MutableCallSite` - first, we would produce a temporary MethodHandle, and on the first non-`null` call (when the class apparently must be initialized), we would produce the real (possibly optimized) MethodHandle.
> 
> I suspect (although I may be wrong) that the eager systems may not be able to work with such a call site, but those should be able to replace the bootstrap with a custom static version without changing the semantics in any way.
> 
> A slightly bigger problem is `typeSwitch`: a new feature is that enum constants can be part of any pattern matching switch. Like:
> 
> 
> enum E {A}
> ...
> Object o = ...;
> switch (o) {
>     case E.A -> ...
>     ...
> }
> 
> 
> For this, even `typeSwitch` permits enum constants now, and `java.lang.invoke.ConstantBootstraps.enumConstant` is used for that currently. We would probably need a wrapper to describe the enum constant that could be used by `typeSwitch` to avoid initialization (+the `MutableCallSite`, of course).

Note?that?currently, a?`switch` over?an?enum will?already trigger?initialisation of?the?enum?class because?of the?need to?compute the?relevant mapping?array by?the?synthetic helper?class, see?[JDK?7176515] for?details.
- https://github.com/openjdk/jdk/pull/10797

[JDK?7176515]: https://bugs.openjdk.org/browse/JDK-7176515 "[JDK?7176515] ExceptionInInitializerError for an enum with multiple switch statements"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1165362264

From jlahoda at openjdk.org  Fri Apr 14 12:56:55 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 14 Apr 2023 12:56:55 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch
In-Reply-To: <2svC_yItHpRmOPAkn9PD1rQ_3cEFdXLhbWo0Dw9bU68=.60c529bc-1d52-4159-b395-7fd6c4915c81@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <MkM1D2pdh94wX3KKNo7_Xl_6u8B_5XsDQSodrb5B6VE=.b32b036a-68b7-4360-a9c2-6bccd7f10332@github.com>
 <9K4KarU9rZTTQSyryAkDoyNrpx0G-kv0DAcLPng5AX0=.c0ff9d7d-7ea4-4a9e-9ff3-304a5788b9af@github.com>
 <2svC_yItHpRmOPAkn9PD1rQ_3cEFdXLhbWo0Dw9bU68=.60c529bc-1d52-4159-b395-7fd6c4915c81@github.com>
Message-ID: <tBKzWr_T0x_DKmW8YUlz3jnSxIwOfAdiG2NCgicFPu8=.87980d3b-7c46-426a-ac82-075e14685ede@github.com>

On Thu, 13 Apr 2023 10:59:46 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Hi Christian,
>> 
>> Thanks for the comment.
>> 
>> First, the "Dumbest possible strategy" comment should be interpreted as "we would like to do something better", not that using something slow is OK permanently. There's an attempt to do performance improvements here:
>> https://github.com/openjdk/jdk/pull/9779
>> 
>> Talking of `enumSwitch` for now (some more on `typeSwitch` later), one thing what I would like allow for the long(er) term are fast(er) implementations. If we just used `String` comparison, it would be extremely difficult to get a really good performance, even for cases where e.g. all the input values are enum constants, where the method can be reduced to a map lookup (as 9779 does).
>> 
>> I think we could probably still avoid the "eager" class initialization, at the cost of using the `MutableCallSite` - first, we would produce a temporary MethodHandle, and on the first non-`null` call (when the class apparently must be initialized), we would produce the real (possibly optimized) MethodHandle.
>> 
>> I suspect (although I may be wrong) that the eager systems may not be able to work with such a call site, but those should be able to replace the bootstrap with a custom static version without changing the semantics in any way.
>> 
>> A slightly bigger problem is `typeSwitch`: a new feature is that enum constants can be part of any pattern matching switch. Like:
>> 
>> 
>> enum E {A}
>> ...
>> Object o = ...;
>> switch (o) {
>>     case E.A -> ...
>>     ...
>> }
>> 
>> 
>> For this, even `typeSwitch` permits enum constants now, and `java.lang.invoke.ConstantBootstraps.enumConstant` is used for that currently. We would probably need a wrapper to describe the enum constant that could be used by `typeSwitch` to avoid initialization (+the `MutableCallSite`, of course).
>
> Note?that?currently, a?`switch` over?an?enum will?already trigger?initialisation of?the?enum?class because?of the?need to?compute the?relevant mapping?array by?the?synthetic helper?class, see?[JDK?7176515] for?details.
> - https://github.com/openjdk/jdk/pull/10797
> 
> [JDK?7176515]: https://bugs.openjdk.org/browse/JDK-7176515 "[JDK?7176515] ExceptionInInitializerError for an enum with multiple switch statements"

FWIW, a sketch on how avoiding the enum initialization might look like is here:
https://github.com/lahodaj/jdk/compare/JDK-8300543...lahodaj:jdk:JDK-8300543-lazy-enum?expand=1

more work needed to make that work for `typeSwitch`, and to combine that with #9779.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1165427916

From dholmes at openjdk.org  Fri Apr 14 13:09:31 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 14 Apr 2023 13:09:31 GMT
Subject: RFR: 8041676: remove the java.compiler system property
In-Reply-To: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>
References: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>
Message-ID: <-gnEY5qJEOvDy_Q93fIgBAeCuhu41r5fZ2118CC25ic=.bd8d1c20-b396-4630-a81d-dfcbeffcbe6c@github.com>

On Fri, 14 Apr 2023 12:19:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes the `java.compiler` system property? This addresses https://bugs.openjdk.org/browse/JDK-8041676.
> 
> A CSR has been filed for this change and is available at https://bugs.openjdk.org/browse/JDK-8305998. The CSR has more details about this proposed change, but to summarize, the `java.compiler` system property wasn't used in any practical way. With the recent removal of `java.lang.Compiler` interface from the JDK, the presence of this system property wasn't of any practical importance.
> 
> The commit in this PR, removes its reference from the `System.getProperties()` documentation and also removes the specific implementation from hotspot where it treated the values `NONE` and empty string in the absence of `-Xdebug` in a specific manner and considered it to be an instruction to run the application in interpreter-only mode. `-Xint` option has been around for this purpose, so removal of this `java.compiler` system property support from hotspot implementation wouldn't remove any usable feature for the applications.
> 
> Additionally, the hotspot implementation now logs a warning message when it detects the presence of `java.compiler` system property when `java` is launched. This warning message will be removed after a few releases.
> 
> The current JDK source has reference to the `java.compiler` system property in numerous NetBeans project build files. The usage of this system property in such files isn't necessary. However, this PR doesn't intend to cleanup those references, since it isn't clear which of those NetBeans projects are still relevant. I think we can use a separate PR to do that cleanup.
> 
> tier1, tier2, tier3 testing has been done with these changes and those tests have passed.

Code changes look good. Thanks for cleaning this up.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13475#pullrequestreview-1385427592

From alanb at openjdk.org  Fri Apr 14 13:31:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Apr 2023 13:31:34 GMT
Subject: RFR: 8041676: remove the java.compiler system property
In-Reply-To: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>
References: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>
Message-ID: <GOAfLjTwLO9yFfM_CKMUpCBAYAt8qQ5GvP9rRLZ98Ik=.b695c8b4-d954-4ffd-93ba-9fc18f44d25b@github.com>

On Fri, 14 Apr 2023 12:19:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes the `java.compiler` system property? This addresses https://bugs.openjdk.org/browse/JDK-8041676.
> 
> A CSR has been filed for this change and is available at https://bugs.openjdk.org/browse/JDK-8305998. The CSR has more details about this proposed change, but to summarize, the `java.compiler` system property wasn't used in any practical way. With the recent removal of `java.lang.Compiler` interface from the JDK, the presence of this system property wasn't of any practical importance.
> 
> The commit in this PR, removes its reference from the `System.getProperties()` documentation and also removes the specific implementation from hotspot where it treated the values `NONE` and empty string in the absence of `-Xdebug` in a specific manner and considered it to be an instruction to run the application in interpreter-only mode. `-Xint` option has been around for this purpose, so removal of this `java.compiler` system property support from hotspot implementation wouldn't remove any usable feature for the applications.
> 
> Additionally, the hotspot implementation now logs a warning message when it detects the presence of `java.compiler` system property when `java` is launched. This warning message will be removed after a few releases.
> 
> The current JDK source has reference to the `java.compiler` system property in numerous NetBeans project build files. The usage of this system property in such files isn't necessary. However, this PR doesn't intend to cleanup those references, since it isn't clear which of those NetBeans projects are still relevant. I think we can use a separate PR to do that cleanup.
> 
> tier1, tier2, tier3 testing has been done with these changes and those tests have passed.

Marked as reviewed by alanb (Reviewer).

src/hotspot/share/runtime/arguments.cpp line 1313:

> 1311:                 " use -Xint if you want to run the application in interpreted-only mode.");
> 1312:     } else {
> 1313:         warning("The java.compiler system property is obsolete and no longer supported.");

This looks okay although the warning for the empty value and "NONE" case will probably wrap as it's very long. Today, -Djava.compiler=foo is ignored, no warning, seems good to emit a warning about that too.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13475#pullrequestreview-1385463806
PR Review Comment: https://git.openjdk.org/jdk/pull/13475#discussion_r1166837342

From rriggs at openjdk.org  Fri Apr 14 13:34:33 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Apr 2023 13:34:33 GMT
Subject: RFR: 8041676: remove the java.compiler system property
In-Reply-To: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>
References: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>
Message-ID: <g4s8XxNeVFPyC8gsASwK410iyt-K2IfMpcKjZe58bGc=.bd55a779-0b26-4b93-8b20-84d8b27b2660@github.com>

On Fri, 14 Apr 2023 12:19:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes the `java.compiler` system property? This addresses https://bugs.openjdk.org/browse/JDK-8041676.
> 
> A CSR has been filed for this change and is available at https://bugs.openjdk.org/browse/JDK-8305998. The CSR has more details about this proposed change, but to summarize, the `java.compiler` system property wasn't used in any practical way. With the recent removal of `java.lang.Compiler` interface from the JDK, the presence of this system property wasn't of any practical importance.
> 
> The commit in this PR, removes its reference from the `System.getProperties()` documentation and also removes the specific implementation from hotspot where it treated the values `NONE` and empty string in the absence of `-Xdebug` in a specific manner and considered it to be an instruction to run the application in interpreter-only mode. `-Xint` option has been around for this purpose, so removal of this `java.compiler` system property support from hotspot implementation wouldn't remove any usable feature for the applications.
> 
> Additionally, the hotspot implementation now logs a warning message when it detects the presence of `java.compiler` system property when `java` is launched. This warning message will be removed after a few releases.
> 
> The current JDK source has reference to the `java.compiler` system property in numerous NetBeans project build files. The usage of this system property in such files isn't necessary. However, this PR doesn't intend to cleanup those references, since it isn't clear which of those NetBeans projects are still relevant. I think we can use a separate PR to do that cleanup.
> 
> tier1, tier2, tier3 testing has been done with these changes and those tests have passed.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13475#pullrequestreview-1385468802

From rriggs at openjdk.org  Fri Apr 14 13:42:36 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Apr 2023 13:42:36 GMT
Subject: RFR: 8305762: FileInputStream and FileOutputStream implSpec should
 be corrected or removed
In-Reply-To: <8IXpgKy4qK1woM-A3yu8Xn-r4YPrsdOx2PvpXbEImEU=.5690beb6-79e6-4a45-837b-f2d362eb247d@github.com>
References: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
 <8IXpgKy4qK1woM-A3yu8Xn-r4YPrsdOx2PvpXbEImEU=.5690beb6-79e6-4a45-837b-f2d362eb247d@github.com>
Message-ID: <gU13W-4_qEAh4l00YElb9BTMPLhKLaF20sbuUL5DqZc=.8beaa2d6-86b1-4fa2-8312-a37b091bbfcd@github.com>

On Fri, 14 Apr 2023 07:54:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> With the removal of the AltFinalizer mechanism from `FileInputStream` and `FileOutputStream` in [JDK-8192939](https://bugs.openjdk.org/browse/JDK-8192939), this portion of the Implementation Requirement in the class JavaDoc is no longer true:
>> 
>>> If this FileOutputStream has been subclassed and the close() method has been overridden, the close() method will be called when the FileInputStream is unreachable."
>> 
>> The class doc, and the doc for close(), are updated to correctly reflect current behavior, and guidance for subclasses is clarified.
>
> src/java.base/share/classes/java/io/FileInputStream.java line 50:
> 
>> 48:  * Subclasses are responsible for the cleanup of resources acquired by the subclass.
>> 49:  * Subclasses requiring that resource cleanup take place after a stream becomes
>> 50:  * unreachable should use the {@link java.lang.ref.Cleaner} mechanism.
> 
> This is in the style of an API note for implementors so implSpec is appropriate here.

Perhaps add "or other mechanisms" or similar advice.  
There should be some room to use other kinds of queues or polling to do the cleanup.
For example, there are some maps that check for cleanups when doing other operations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13437#discussion_r1166849142

From mchhipa at openjdk.org  Fri Apr 14 13:48:33 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Fri, 14 Apr 2023 13:48:33 GMT
Subject: RFR: 8305904: java/lang/Character,
 java/lang/String and java/text/Normalizer tests read the unicode data files
 from src directories.
In-Reply-To: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
References: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
Message-ID: <KvCPCLYFl-awg4_XcZcY7AM8w4X1udmd0gFtlm-VzIY=.4f57b572-4f11-445d-8bbf-df2e1c7b2391@github.com>

On Wed, 12 Apr 2023 16:35:19 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Following tests read the unicode data files (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, these files should be in test directories. No source code is using these files. Only tests are using these files. Tests are :
> java/lang/Character/CharPropTest.java
> java/lang/Character/CheckProp.java
> java/lang/Character/CheckScript.java
> java/lang/Character/CheckUnicode.java
> java/lang/Character/UnicodeBlock/CheckBlocks.java
> java/lang/Character/UnicodeCasingTest.java
> java/lang/String/SpecialCasingTest.java
> java/lang/String/UnicodeCasingTest.java
> java/text/Normalizer/ConformanceTest.java

> 

Hi Roger,
 Sorry I was not aware of uses in makefiles. I will undo the changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13447#issuecomment-1508531123

From asotona at openjdk.org  Fri Apr 14 14:09:38 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 14 Apr 2023 14:09:38 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails
Message-ID: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>

Classfile API didn't handle transformations of class files version 50 and below correctly. 

Proposed fix have two parts: 
1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
2. StackMapTable attribute is not generated for class file versions below 50.

StackMapsTest is also extended to test this patch.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - added bug test annotation
 - 8305990: Stripping debug info of ASM 9.5 fails

Changes: https://git.openjdk.org/jdk/pull/13478/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305990
  Stats: 42 lines in 5 files changed: 39 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13478/head:pull/13478

PR: https://git.openjdk.org/jdk/pull/13478

From jpai at openjdk.org  Fri Apr 14 14:24:36 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Apr 2023 14:24:36 GMT
Subject: RFR: 8041676: remove the java.compiler system property
In-Reply-To: <GOAfLjTwLO9yFfM_CKMUpCBAYAt8qQ5GvP9rRLZ98Ik=.b695c8b4-d954-4ffd-93ba-9fc18f44d25b@github.com>
References: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>
 <GOAfLjTwLO9yFfM_CKMUpCBAYAt8qQ5GvP9rRLZ98Ik=.b695c8b4-d954-4ffd-93ba-9fc18f44d25b@github.com>
Message-ID: <KUOwl4gjEAeQ3wgy9AVgowAaO1ZLEvDynMtdK31uSWk=.e2cb6510-0522-4083-8ea6-8973811f3a42@github.com>

On Fri, 14 Apr 2023 13:28:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Can I please get a review of this change which removes the `java.compiler` system property? This addresses https://bugs.openjdk.org/browse/JDK-8041676.
>> 
>> A CSR has been filed for this change and is available at https://bugs.openjdk.org/browse/JDK-8305998. The CSR has more details about this proposed change, but to summarize, the `java.compiler` system property wasn't used in any practical way. With the recent removal of `java.lang.Compiler` interface from the JDK, the presence of this system property wasn't of any practical importance.
>> 
>> The commit in this PR, removes its reference from the `System.getProperties()` documentation and also removes the specific implementation from hotspot where it treated the values `NONE` and empty string in the absence of `-Xdebug` in a specific manner and considered it to be an instruction to run the application in interpreter-only mode. `-Xint` option has been around for this purpose, so removal of this `java.compiler` system property support from hotspot implementation wouldn't remove any usable feature for the applications.
>> 
>> Additionally, the hotspot implementation now logs a warning message when it detects the presence of `java.compiler` system property when `java` is launched. This warning message will be removed after a few releases.
>> 
>> The current JDK source has reference to the `java.compiler` system property in numerous NetBeans project build files. The usage of this system property in such files isn't necessary. However, this PR doesn't intend to cleanup those references, since it isn't clear which of those NetBeans projects are still relevant. I think we can use a separate PR to do that cleanup.
>> 
>> tier1, tier2, tier3 testing has been done with these changes and those tests have passed.
>
> src/hotspot/share/runtime/arguments.cpp line 1313:
> 
>> 1311:                 " use -Xint if you want to run the application in interpreted-only mode.");
>> 1312:     } else {
>> 1313:         warning("The java.compiler system property is obsolete and no longer supported.");
> 
> This looks okay although the warning for the empty value and "NONE" case will probably wrap as it's very long. Today, -Djava.compiler=foo is ignored, no warning, seems good to emit a warning about that too.

Hello Alan,

> This looks okay although the warning for the empty value and "NONE" case will probably wrap as it's very long.

Agreed, it's a bit long. I can't think of a simpler message though. If anyone has a suggestion, I'll update accordingly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13475#discussion_r1166902101

From jpai at openjdk.org  Fri Apr 14 14:34:39 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Apr 2023 14:34:39 GMT
Subject: RFR: 8041676: remove the java.compiler system property [v2]
In-Reply-To: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>
References: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>
Message-ID: <7ZpYIwTMkZYOieMdMeRB-5Dey31mn-2XfztAqY8QCEw=.aa601d4d-2534-47e8-9357-dbfae625e692@github.com>

> Can I please get a review of this change which removes the `java.compiler` system property? This addresses https://bugs.openjdk.org/browse/JDK-8041676.
> 
> A CSR has been filed for this change and is available at https://bugs.openjdk.org/browse/JDK-8305998. The CSR has more details about this proposed change, but to summarize, the `java.compiler` system property wasn't used in any practical way. With the recent removal of `java.lang.Compiler` interface from the JDK, the presence of this system property wasn't of any practical importance.
> 
> The commit in this PR, removes its reference from the `System.getProperties()` documentation and also removes the specific implementation from hotspot where it treated the values `NONE` and empty string in the absence of `-Xdebug` in a specific manner and considered it to be an instruction to run the application in interpreter-only mode. `-Xint` option has been around for this purpose, so removal of this `java.compiler` system property support from hotspot implementation wouldn't remove any usable feature for the applications.
> 
> Additionally, the hotspot implementation now logs a warning message when it detects the presence of `java.compiler` system property when `java` is launched. This warning message will be removed after a few releases.
> 
> The current JDK source has reference to the `java.compiler` system property in numerous NetBeans project build files. The usage of this system property in such files isn't necessary. However, this PR doesn't intend to cleanup those references, since it isn't clear which of those NetBeans projects are still relevant. I think we can use a separate PR to do that cleanup.
> 
> tier1, tier2, tier3 testing has been done with these changes and those tests have passed.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Roger's suggestion - improve warning message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13475/files
  - new: https://git.openjdk.org/jdk/pull/13475/files/3a4bf8f7..5c1846e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13475&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13475&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13475/head:pull/13475

PR: https://git.openjdk.org/jdk/pull/13475

From rriggs at openjdk.org  Fri Apr 14 14:34:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Apr 2023 14:34:51 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v13]
In-Reply-To: <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
Message-ID: <lO7M9T25lZ02nQp3bl6kxwsUVibW8hlyCeS4S9QO92A=.7df8551d-3a35-4871-af06-2f171c19ac3b@github.com>

On Wed, 12 Apr 2023 17:31:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed isPPC64().
>   Consolidated switch cases in ArchTest.
>   Moved mapping of build TARGET_OS and TARGET_CPU to the build
>   to avoid multiple mappings in more than one place.

make/modules/java.base/gensrc/GensrcMisc.gmk line 72:

> 70: endif
> 71: 
> 72: $(eval $(call SetupTextFileProcessing, BUILD_PLATFORMPROPERTIES_JAVA, \

@erikj79 Is there a better/good way to do these mappings, or select "local" variable names?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1166913016

From rriggs at openjdk.org  Fri Apr 14 14:34:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Apr 2023 14:34:48 GMT
Subject: RFR: 8041676: remove the java.compiler system property [v2]
In-Reply-To: <KUOwl4gjEAeQ3wgy9AVgowAaO1ZLEvDynMtdK31uSWk=.e2cb6510-0522-4083-8ea6-8973811f3a42@github.com>
References: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>
 <GOAfLjTwLO9yFfM_CKMUpCBAYAt8qQ5GvP9rRLZ98Ik=.b695c8b4-d954-4ffd-93ba-9fc18f44d25b@github.com>
 <KUOwl4gjEAeQ3wgy9AVgowAaO1ZLEvDynMtdK31uSWk=.e2cb6510-0522-4083-8ea6-8973811f3a42@github.com>
Message-ID: <bfz0Knlzb-Y1Vcu_PA5i8c8nk5BleTboh4qfZDunx2A=.27d5e707-2192-4e89-9edf-971687ea510a@github.com>

On Fri, 14 Apr 2023 14:21:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 1313:
>> 
>>> 1311:                 " use -Xint if you want to run the application in interpreted-only mode.");
>>> 1312:     } else {
>>> 1313:         warning("The java.compiler system property is obsolete and no longer supported.");
>> 
>> This looks okay although the warning for the empty value and "NONE" case will probably wrap as it's very long. Today, -Djava.compiler=foo is ignored, no warning, seems good to emit a warning about that too.
>
> Hello Alan,
> 
>> This looks okay although the warning for the empty value and "NONE" case will probably wrap as it's very long.
> 
> Agreed, it's a bit long. I can't think of a simpler message though. If anyone has a suggestion, I'll update accordingly.

Just drop the detailed explanation, they can check the help for -Xint.

"The java.compiler system property is obsolete and no longer supported, use -Xint".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13475#discussion_r1166907316

From jpai at openjdk.org  Fri Apr 14 14:34:50 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Apr 2023 14:34:50 GMT
Subject: RFR: 8041676: remove the java.compiler system property [v2]
In-Reply-To: <bfz0Knlzb-Y1Vcu_PA5i8c8nk5BleTboh4qfZDunx2A=.27d5e707-2192-4e89-9edf-971687ea510a@github.com>
References: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>
 <GOAfLjTwLO9yFfM_CKMUpCBAYAt8qQ5GvP9rRLZ98Ik=.b695c8b4-d954-4ffd-93ba-9fc18f44d25b@github.com>
 <KUOwl4gjEAeQ3wgy9AVgowAaO1ZLEvDynMtdK31uSWk=.e2cb6510-0522-4083-8ea6-8973811f3a42@github.com>
 <bfz0Knlzb-Y1Vcu_PA5i8c8nk5BleTboh4qfZDunx2A=.27d5e707-2192-4e89-9edf-971687ea510a@github.com>
Message-ID: <CvbvjSiJaC3NP5dMavsvamnuzJlDB1AK4rNTPfictVg=.78eb3afa-5fea-4ea8-b4c6-10ff8b4c68fc@github.com>

On Fri, 14 Apr 2023 14:26:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Hello Alan,
>> 
>>> This looks okay although the warning for the empty value and "NONE" case will probably wrap as it's very long.
>> 
>> Agreed, it's a bit long. I can't think of a simpler message though. If anyone has a suggestion, I'll update accordingly.
>
> Just drop the detailed explanation, they can check the help for -Xint.
> 
> "The java.compiler system property is obsolete and no longer supported, use -Xint".

Thank you Roger, updated the PR with this suggested change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13475#discussion_r1166911041

From mchhipa at openjdk.org  Fri Apr 14 14:38:44 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Fri, 14 Apr 2023 14:38:44 GMT
Subject: Withdrawn: 8305904: java/lang/Character,
 java/lang/String and java/text/Normalizer tests read the unicode data files
 from src directories.
In-Reply-To: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
References: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
Message-ID: <wz3luoBfRT9Wdi4vE-Gvhi3al_0emxid1w0eaeSjKzo=.c85b7cbd-774b-42db-970e-68493484f825@github.com>

On Wed, 12 Apr 2023 16:35:19 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Following tests read the unicode data files (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, these files should be in test directories. No source code is using these files. Only tests are using these files. Tests are :
> java/lang/Character/CharPropTest.java
> java/lang/Character/CheckProp.java
> java/lang/Character/CheckScript.java
> java/lang/Character/CheckUnicode.java
> java/lang/Character/UnicodeBlock/CheckBlocks.java
> java/lang/Character/UnicodeCasingTest.java
> java/lang/String/SpecialCasingTest.java
> java/lang/String/UnicodeCasingTest.java
> java/text/Normalizer/ConformanceTest.java

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/13447

From rriggs at openjdk.org  Fri Apr 14 15:02:34 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Apr 2023 15:02:34 GMT
Subject: RFR: 8041676: remove the java.compiler system property [v2]
In-Reply-To: <7ZpYIwTMkZYOieMdMeRB-5Dey31mn-2XfztAqY8QCEw=.aa601d4d-2534-47e8-9357-dbfae625e692@github.com>
References: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>
 <7ZpYIwTMkZYOieMdMeRB-5Dey31mn-2XfztAqY8QCEw=.aa601d4d-2534-47e8-9357-dbfae625e692@github.com>
Message-ID: <bHjAj2AuKuEHIyAw3o_ETZaw2DVJpAwxNw_RU1R3Ixg=.a8a087ab-cd79-474c-9402-a3d57efbae96@github.com>

On Fri, 14 Apr 2023 14:34:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes the `java.compiler` system property? This addresses https://bugs.openjdk.org/browse/JDK-8041676.
>> 
>> A CSR has been filed for this change and is available at https://bugs.openjdk.org/browse/JDK-8305998. The CSR has more details about this proposed change, but to summarize, the `java.compiler` system property wasn't used in any practical way. With the recent removal of `java.lang.Compiler` interface from the JDK, the presence of this system property wasn't of any practical importance.
>> 
>> The commit in this PR, removes its reference from the `System.getProperties()` documentation and also removes the specific implementation from hotspot where it treated the values `NONE` and empty string in the absence of `-Xdebug` in a specific manner and considered it to be an instruction to run the application in interpreter-only mode. `-Xint` option has been around for this purpose, so removal of this `java.compiler` system property support from hotspot implementation wouldn't remove any usable feature for the applications.
>> 
>> Additionally, the hotspot implementation now logs a warning message when it detects the presence of `java.compiler` system property when `java` is launched. This warning message will be removed after a few releases.
>> 
>> The current JDK source has reference to the `java.compiler` system property in numerous NetBeans project build files. The usage of this system property in such files isn't necessary. However, this PR doesn't intend to cleanup those references, since it isn't clear which of those NetBeans projects are still relevant. I think we can use a separate PR to do that cleanup.
>> 
>> tier1, tier2, tier3 testing has been done with these changes and those tests have passed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roger's suggestion - improve warning message

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13475#pullrequestreview-1385634497

From duke at openjdk.org  Fri Apr 14 15:10:35 2023
From: duke at openjdk.org (Andy-Tatman)
Date: Fri, 14 Apr 2023 15:10:35 GMT
Subject: RFR: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: <K-vP8vrWjuyUpU1rC5GnePZmzb5A_NCW2aiLjOI5TlY=.80309645-8031-4d82-a2be-157b78d21bdb@github.com>
References: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
 <K-vP8vrWjuyUpU1rC5GnePZmzb5A_NCW2aiLjOI5TlY=.80309645-8031-4d82-a2be-157b78d21bdb@github.com>
Message-ID: <r1YnlgqY3dpeK4Cy62dcl1OUVo9h6toSaeq48e9Jh84=.ec64f374-c469-42c1-a796-bfa7308d7fdc@github.com>

On Wed, 12 Apr 2023 06:46:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> See https://bugs.java.com/bugdatabase/view_bug?bug_id=8305734
>
> The BitSet API requires that the logical size fit in an int so I think you'll end up changing the set methods to disallow an index of MAX_VALUE.
> 
> Can you change the title of the PR to match the JBS issue? The title on the PR doesn't give any context as to what this issue is about.

@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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1508743927

From alanb at openjdk.org  Fri Apr 14 15:56:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Apr 2023 15:56:36 GMT
Subject: RFR: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: <r1YnlgqY3dpeK4Cy62dcl1OUVo9h6toSaeq48e9Jh84=.ec64f374-c469-42c1-a796-bfa7308d7fdc@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>
Message-ID: <Wz_Ky5w_qBUdBE7zsC9pRMH3XEdHXQyti4Tk2dammPA=.932f5719-dc8d-4c87-9a8a-40397f38ae2f@github.com>

On Fri, 14 Apr 2023 15:07:37 GMT, Andy-Tatman <duke at openjdk.org> wrote:

> 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, it's unfortunate that this wasn't recognised in JDK-8230557..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1508862261

From joehw at openjdk.org  Fri Apr 14 15:58:34 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 14 Apr 2023 15:58:34 GMT
Subject: RFR: 8296248: Update CLDR to Version 43.0 [v2]
In-Reply-To: <bdQ09nn5FNT4PShAwGqWV6L9gBv5yt7VRNAtpUXshHE=.f4ae637a-f077-4fa6-8b86-2b26589b9178@github.com>
References: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
 <bdQ09nn5FNT4PShAwGqWV6L9gBv5yt7VRNAtpUXshHE=.f4ae637a-f077-4fa6-8b86-2b26589b9178@github.com>
Message-ID: <6KyTNUsXdQvIGrCtUZSRdZDZ22yaBzluKwrpgc6PUwY=.6264c04e-aed7-4b56-addb-2d112b7b1b95@github.com>

On Thu, 13 Apr 2023 23:45:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the CLDR to [version 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual release is their `limited-submission` release so I would not expect regressions caused by formatting changes as we had in JDK20/CLDRv42 (https://inside.java/2023/03/28/quality-heads-up/)
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Short ID test for "America/Ciudad_Juarez"

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13469#pullrequestreview-1385726554

From duke at openjdk.org  Fri Apr 14 16:13:35 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 14 Apr 2023 16:13:35 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch
In-Reply-To: <tBKzWr_T0x_DKmW8YUlz3jnSxIwOfAdiG2NCgicFPu8=.87980d3b-7c46-426a-ac82-075e14685ede@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <MkM1D2pdh94wX3KKNo7_Xl_6u8B_5XsDQSodrb5B6VE=.b32b036a-68b7-4360-a9c2-6bccd7f10332@github.com>
 <9K4KarU9rZTTQSyryAkDoyNrpx0G-kv0DAcLPng5AX0=.c0ff9d7d-7ea4-4a9e-9ff3-304a5788b9af@github.com>
 <2svC_yItHpRmOPAkn9PD1rQ_3cEFdXLhbWo0Dw9bU68=.60c529bc-1d52-4159-b395-7fd6c4915c81@github.com>
 <tBKzWr_T0x_DKmW8YUlz3jnSxIwOfAdiG2NCgicFPu8=.87980d3b-7c46-426a-ac82-075e14685ede@github.com>
Message-ID: <tViH_yZaiWwqFSdhiquf0SFi8erhZ6cMyB6mn-icMLs=.419102e3-372d-4cd1-a1b6-7d64e7981994@github.com>

On Thu, 13 Apr 2023 12:07:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Note?that?currently, a?`switch` over?an?enum will?already trigger?initialisation of?the?enum?class because?of the?need to?compute the?relevant mapping?array by?the?synthetic helper?class, see?[JDK?7176515] for?details.
>> - https://github.com/openjdk/jdk/pull/10797
>> 
>> [JDK?7176515]: https://bugs.openjdk.org/browse/JDK-7176515 "[JDK?7176515] ExceptionInInitializerError for an enum with multiple switch statements"
>
> FWIW, a sketch on how avoiding the enum initialization might look like is here:
> https://github.com/lahodaj/jdk/compare/JDK-8300543...lahodaj:jdk:JDK-8300543-lazy-enum?expand=1
> 
> more work needed to make that work for `typeSwitch`, and to combine that with #9779.

FWIW... an observation from working on [JDK-7176515](https://bugs.openjdk.org/browse/JDK-7176515). This is probably redundant but here goes anyway.

In the compiler there are currently three different ways of handling enums in switch statements:
1. The old way, where a separate lookup class is generated for traditional switch-on-enum statements
2. The `ordinal()` way, which is an optimization available when the `enum` type is defined in the same file as the `switch` statement (what JDK-7176515 adds)
3. The new way using bootstrap methods, which is used by the pattern matching stuff

My observation is simply that the old way <span>#</span>1 should be completely eliminated and folded into <span>#</span>3. <span>#</span>1 is just a hold-over from before INVOKEDYNAMIC. Using a bootstrap method is "the right way" to handle enums. Instead, traditional switch-on-enum should be handled as a degenerate case of pattern switch with enums. This will simplify the code and eliminate the ugly extra lookup class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1167032116

From jlahoda at openjdk.org  Fri Apr 14 16:40:35 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 14 Apr 2023 16:40:35 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch
In-Reply-To: <tViH_yZaiWwqFSdhiquf0SFi8erhZ6cMyB6mn-icMLs=.419102e3-372d-4cd1-a1b6-7d64e7981994@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <MkM1D2pdh94wX3KKNo7_Xl_6u8B_5XsDQSodrb5B6VE=.b32b036a-68b7-4360-a9c2-6bccd7f10332@github.com>
 <9K4KarU9rZTTQSyryAkDoyNrpx0G-kv0DAcLPng5AX0=.c0ff9d7d-7ea4-4a9e-9ff3-304a5788b9af@github.com>
 <2svC_yItHpRmOPAkn9PD1rQ_3cEFdXLhbWo0Dw9bU68=.60c529bc-1d52-4159-b395-7fd6c4915c81@github.com>
 <tBKzWr_T0x_DKmW8YUlz3jnSxIwOfAdiG2NCgicFPu8=.87980d3b-7c46-426a-ac82-075e14685ede@github.com>
 <tViH_yZaiWwqFSdhiquf0SFi8erhZ6cMyB6mn-icMLs=.419102e3-372d-4cd1-a1b6-7d64e7981994@github.com>
Message-ID: <Nc3DWxmLzMvtK2Fj5IE4Z-coZA4HNlrWZf1qT7q6tHU=.98a54fb7-476d-4cdb-b45d-b66ba9c0ab49@github.com>

On Fri, 14 Apr 2023 16:10:49 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> FWIW, a sketch on how avoiding the enum initialization might look like is here:
>> https://github.com/lahodaj/jdk/compare/JDK-8300543...lahodaj:jdk:JDK-8300543-lazy-enum?expand=1
>> 
>> more work needed to make that work for `typeSwitch`, and to combine that with #9779.
>
> FWIW... an observation from working on [JDK-7176515](https://bugs.openjdk.org/browse/JDK-7176515). This is probably redundant but here goes anyway.
> 
> In the compiler there are currently three different ways of handling enums in switch statements:
> 1. The old way, where a separate lookup class is generated for traditional switch-on-enum statements
> 2. The `ordinal()` way, which is an optimization available when the `enum` type is defined in the same file as the `switch` statement (what JDK-7176515 adds)
> 3. The new way using bootstrap methods, which is used by the pattern matching stuff
> 
> My observation is simply that the old way <span>#</span>1 should be completely eliminated and folded into <span>#</span>3. <span>#</span>1 is just a hold-over from before INVOKEDYNAMIC. Using a bootstrap method is "the right way" to handle enums. Instead, traditional switch-on-enum should be handled as a degenerate case of pattern switch with enums. This will simplify the code and eliminate the ugly extra lookup class.

Well, I'm aware of this, and https://github.com/openjdk/jdk/pull/9779 even optimizes the case where the `enumSwitch` only gets enum constants as parameters.

And, overall, it is fairly easy to implement, I think I've had at least one implementation in the past. But, the last time I was experimenting with this, there IIRC was a performance hit for using the indy/condy (IIRC it worked as a condy/ldc for a mapping array - but it could as easily be an indy doing the mapping as such). So, frankly, to me, simplifying the compiler slightly (in maybe ~10 years, because we would still need to keep the current desugaring for targets that don't have the bootstrap) while slowing down all other code is not a good balance. *If* we can make the indy/condy at least as fast as the current code, (or faster,) then sure, this is the right way to go. And, as far as javac is concerned that is not really difficult.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1167057614

From rriggs at openjdk.org  Fri Apr 14 16:48:32 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Apr 2023 16:48:32 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch
In-Reply-To: <Nc3DWxmLzMvtK2Fj5IE4Z-coZA4HNlrWZf1qT7q6tHU=.98a54fb7-476d-4cdb-b45d-b66ba9c0ab49@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <MkM1D2pdh94wX3KKNo7_Xl_6u8B_5XsDQSodrb5B6VE=.b32b036a-68b7-4360-a9c2-6bccd7f10332@github.com>
 <9K4KarU9rZTTQSyryAkDoyNrpx0G-kv0DAcLPng5AX0=.c0ff9d7d-7ea4-4a9e-9ff3-304a5788b9af@github.com>
 <2svC_yItHpRmOPAkn9PD1rQ_3cEFdXLhbWo0Dw9bU68=.60c529bc-1d52-4159-b395-7fd6c4915c81@github.com>
 <tBKzWr_T0x_DKmW8YUlz3jnSxIwOfAdiG2NCgicFPu8=.87980d3b-7c46-426a-ac82-075e14685ede@github.com>
 <tViH_yZaiWwqFSdhiquf0SFi8erhZ6cMyB6mn-icMLs=.419102e3-372d-4cd1-a1b6-7d64e7981994@github.com>
 <Nc3DWxmLzMvtK2Fj5IE4Z-coZA4HNlrWZf1qT7q6tHU=.98a54fb7-476d-4cdb-b45d-b66ba9c0ab49@github.com>
Message-ID: <P87UWnjWLYJpvkr2WL0-XcmBpfvMJd91Y7Hsb2_x5uM=.b362c990-142e-4458-932b-3dbeb9b66ef2@github.com>

On Fri, 14 Apr 2023 16:36:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> FWIW... an observation from working on [JDK-7176515](https://bugs.openjdk.org/browse/JDK-7176515). This is probably redundant but here goes anyway.
>> 
>> In the compiler there are currently three different ways of handling enums in switch statements:
>> 1. The old way, where a separate lookup class is generated for traditional switch-on-enum statements
>> 2. The `ordinal()` way, which is an optimization available when the `enum` type is defined in the same file as the `switch` statement (what JDK-7176515 adds)
>> 3. The new way using bootstrap methods, which is used by the pattern matching stuff
>> 
>> My observation is simply that the old way <span>#</span>1 should be completely eliminated and folded into <span>#</span>3. <span>#</span>1 is just a hold-over from before INVOKEDYNAMIC. Using a bootstrap method is "the right way" to handle enums. Instead, traditional switch-on-enum should be handled as a degenerate case of pattern switch with enums. This will simplify the code and eliminate the ugly extra lookup class.
>
> Well, I'm aware of this, and https://github.com/openjdk/jdk/pull/9779 even optimizes the case where the `enumSwitch` only gets enum constants as parameters.
> 
> And, overall, it is fairly easy to implement, I think I've had at least one implementation in the past. But, the last time I was experimenting with this, there IIRC was a performance hit for using the indy/condy (IIRC it worked as a condy/ldc for a mapping array - but it could as easily be an indy doing the mapping as such). So, frankly, to me, simplifying the compiler slightly (in maybe ~10 years, because we would still need to keep the current desugaring for targets that don't have the bootstrap) while slowing down all other code is not a good balance. *If* we can make the indy/condy at least as fast as the current code, (or faster,) then sure, this is the right way to go. And, as far as javac is concerned that is not really difficult.

Is it every too early in JDK startup (Phase 1) to use #3? But you'll find out pretty quick if the JDK won't start.  But it might constrain where we can use Pattern matching (and it won't be the first feature that can't be used in Phase 1).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1167065473

From erikj at openjdk.org  Fri Apr 14 17:10:48 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 14 Apr 2023 17:10:48 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v13]
In-Reply-To: <lO7M9T25lZ02nQp3bl6kxwsUVibW8hlyCeS4S9QO92A=.7df8551d-3a35-4871-af06-2f171c19ac3b@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
 <lO7M9T25lZ02nQp3bl6kxwsUVibW8hlyCeS4S9QO92A=.7df8551d-3a35-4871-af06-2f171c19ac3b@github.com>
Message-ID: <jsUfZmkzbPYQ98Ma4MMLm4t4215obdXNnGHA3SgPdwo=.839c5327-6132-46c9-beb4-5823fd2c02b5@github.com>

On Fri, 14 Apr 2023 14:31:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed isPPC64().
>>   Consolidated switch cases in ArchTest.
>>   Moved mapping of build TARGET_OS and TARGET_CPU to the build
>>   to avoid multiple mappings in more than one place.
>
> make/modules/java.base/gensrc/GensrcMisc.gmk line 72:
> 
>> 70: endif
>> 71: 
>> 72: $(eval $(call SetupTextFileProcessing, BUILD_PLATFORMPROPERTIES_JAVA, \
> 
> @erikj79 Is there a better/good way to do these mappings, or select "local" variable names?

Not sure if it's better, but you could consider doing this directly in the switch statements in `make/autoconf/platform.m4` and add the corresponding variables in `spec.gmk.in`. That would make them available globally in the build, which may also be detrimental as parts of the build could start relying on them, and we end up with even more variants sprinkled around. I think what you have here is better for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1167095379

From duke at openjdk.org  Fri Apr 14 17:26:23 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 14 Apr 2023 17:26:23 GMT
Subject: RFR: 8303920: Avoid calling out to python in
 DataDescriptorSignatureMissing test [v7]
In-Reply-To: <O8QlaVgZodtXVtw_1IaBp7BdNr-WRHLfWKrpTULRyko=.f7f2c640-3205-43a0-ac74-2e96834715c6@github.com>
References: <O8QlaVgZodtXVtw_1IaBp7BdNr-WRHLfWKrpTULRyko=.f7f2c640-3205-43a0-ac74-2e96834715c6@github.com>
Message-ID: <5NiyTUVb6G3-B_aRjLFI0N-Zy9mHMgPJ4AWB3JqQpMg=.d65932ca-162c-4c48-ac46-d5795cb407b4@github.com>

> Please review this PR which brings  the DataDescriptorSignatureMissing test back to life.
> 
> This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` 
> 
> The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  The END header LOC offset field and the second entry's CEN LOC offset fields need to be update to account for the four missing signature bytes.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12959/files
  - new: https://git.openjdk.org/jdk/pull/12959/files/0fb30670..5dd9891b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12959&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12959&range=05-06

  Stats: 23 lines in 1 file changed: 22 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12959.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12959/head:pull/12959

PR: https://git.openjdk.org/jdk/pull/12959

From duke at openjdk.org  Fri Apr 14 17:26:27 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 14 Apr 2023 17:26:27 GMT
Subject: RFR: 8303920: Avoid calling out to python in
 DataDescriptorSignatureMissing test [v6]
In-Reply-To: <OeL-RuE9SFLoxfyecEQ-onOPMSkPJqERdMF8qk3yQLw=.fc66caaa-ce85-4391-ad33-2dcb4ed717a2@github.com>
References: <O8QlaVgZodtXVtw_1IaBp7BdNr-WRHLfWKrpTULRyko=.f7f2c640-3205-43a0-ac74-2e96834715c6@github.com>
 <OeL-RuE9SFLoxfyecEQ-onOPMSkPJqERdMF8qk3yQLw=.fc66caaa-ce85-4391-ad33-2dcb4ed717a2@github.com>
Message-ID: <113940KmfIj-bmzvO8wPoXorfXB_hS_QwteR_cDiKHI=.8bab601c-39e6-4377-8a30-e50cfe74d738@github.com>

On Sat, 11 Mar 2023 08:27:06 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Please review this PR which brings  the DataDescriptorSignatureMissing test back to life.
>> 
>> This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` 
>> 
>> The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically.
>
> Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into signature-less-data-descriptor
>  - Add assertNotNulls to catch unexpectedly missing entries
>  - Revert change to Google copyright line, add an Oracle copyright line instead.
>  - Use "Signatureless" consistently
>  - Remove reference to python in the @summary of DataDescriptorSignatureMissing
>  - Update copyright years
>  - Add method comments
>  - Instead of calling out to python, create a ZIP file and remove the data descriptor signature.

Since we strip 4 bytes from the first entry's data descriptor, we need to account for this by reducing the second CEN header's LOC offset by 4. Similarly, the END header's CEN offset also needs adjustment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12959#issuecomment-1508989195

From iris at openjdk.org  Fri Apr 14 17:56:33 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 14 Apr 2023 17:56:33 GMT
Subject: RFR: 8041676: remove the java.compiler system property [v2]
In-Reply-To: <7ZpYIwTMkZYOieMdMeRB-5Dey31mn-2XfztAqY8QCEw=.aa601d4d-2534-47e8-9357-dbfae625e692@github.com>
References: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>
 <7ZpYIwTMkZYOieMdMeRB-5Dey31mn-2XfztAqY8QCEw=.aa601d4d-2534-47e8-9357-dbfae625e692@github.com>
Message-ID: <S2rtqBYMo--Zpg1ZZJXmr3CB-ZSnEpEsRLxY_-kuG9g=.b1a6ee86-340f-4fb2-a572-670bee40dff3@github.com>

On Fri, 14 Apr 2023 14:34:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes the `java.compiler` system property? This addresses https://bugs.openjdk.org/browse/JDK-8041676.
>> 
>> A CSR has been filed for this change and is available at https://bugs.openjdk.org/browse/JDK-8305998. The CSR has more details about this proposed change, but to summarize, the `java.compiler` system property wasn't used in any practical way. With the recent removal of `java.lang.Compiler` interface from the JDK, the presence of this system property wasn't of any practical importance.
>> 
>> The commit in this PR, removes its reference from the `System.getProperties()` documentation and also removes the specific implementation from hotspot where it treated the values `NONE` and empty string in the absence of `-Xdebug` in a specific manner and considered it to be an instruction to run the application in interpreter-only mode. `-Xint` option has been around for this purpose, so removal of this `java.compiler` system property support from hotspot implementation wouldn't remove any usable feature for the applications.
>> 
>> Additionally, the hotspot implementation now logs a warning message when it detects the presence of `java.compiler` system property when `java` is launched. This warning message will be removed after a few releases.
>> 
>> The current JDK source has reference to the `java.compiler` system property in numerous NetBeans project build files. The usage of this system property in such files isn't necessary. However, this PR doesn't intend to cleanup those references, since it isn't clear which of those NetBeans projects are still relevant. I think we can use a separate PR to do that cleanup.
>> 
>> tier1, tier2, tier3 testing has been done with these changes and those tests have passed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roger's suggestion - improve warning message

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13475#pullrequestreview-1385947099

From vromero at openjdk.org  Fri Apr 14 18:33:31 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 14 Apr 2023 18:33:31 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <grabb-C4Hj_CgzVmK9TXongYjHyDs9Nk5qfRRjAFLVk=.22ca71e6-2ccd-4431-83d1-9dab0acecb61@github.com>

On Fri, 17 Mar 2023 12:15:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4092:

> 4090:                     log.error(DiagnosticFlag.SOURCE_LEVEL, tree.pos(),
> 4091:                               Feature.UNCONDITIONAL_PATTERN_IN_INSTANCEOF.error(this.sourceName));
> 4092:                     allowUnconditionalPatternsInstanceOf = true;

sorry not sure why we are doing this. Either the feature should be allowed or not right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1167168581

From lancea at openjdk.org  Fri Apr 14 20:30:35 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 14 Apr 2023 20:30:35 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream produces
 incorrect exception message
Message-ID: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>

Please review this trivial change when ZipFS returns the wrong java.nio.file.FileSystemException message due the the parameters being reversed.

I also included a simple junit test as part of the fix.

Mach5 tiers1-3 are clean

Best
Lance

-------------

Commit messages:
 - (zipfs) Opening a directory to get input stream produces incorrect exception message

Changes: https://git.openjdk.org/jdk/pull/13482/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13482&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305945
  Stats: 99 lines in 2 files changed: 98 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13482.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13482/head:pull/13482

PR: https://git.openjdk.org/jdk/pull/13482

From jlu at openjdk.org  Fri Apr 14 20:33:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 14 Apr 2023 20:33:29 GMT
Subject: RFR: 4737887: (cal) API: Calendar methods taking field should document
 exceptions
Message-ID: <y65woSohxKGbyGcuLxE9cKokT7YMJIl0uOPpeTiUT0o=.cfdee99e-067b-4139-9802-81def6b81797@github.com>

Many Calendar methods that take in a field parameter should document that they throw an ArrayIndexOutOfBoundsException if field is not between 0 and `Calendar.FIELD_COUNT`.

This PR adds a clause to the class description to make the above apparent.

`Calendar.Roll(int, int)`, `Calendar.roll(int, boolean)`, and `Calendar.add(int, int)` should all be documented that they throw an `IllegalArgumentException` if any calendar fields have out-of-range values in non-lenient mode or if field is
`Calendar.ZONE_OFFSET`, `Calendar.DST_OFFSET`, or unknown.

-------------

Commit messages:
 - Replace method exceptions with a general clause in class description
 - Readjust add and roll to throw IAE (since jCal is private and cannot be specified)
 - Adjust add and roll
 - Adjust Add and Roll spec to use existing wording
 - Add exceptions to Calendar methods

Changes: https://git.openjdk.org/jdk/pull/13234/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13234&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-4737887
  Stats: 20 lines in 1 file changed: 13 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13234/head:pull/13234

PR: https://git.openjdk.org/jdk/pull/13234

From naoto at openjdk.org  Fri Apr 14 21:11:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 14 Apr 2023 21:11:33 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message
In-Reply-To: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
Message-ID: <e9McnwW72ecpPn0f-JYB5rV3nGllciC39U9YsCgNl0c=.b6f8faba-876c-4416-b3c9-98f74db7d63a@github.com>

On Fri, 14 Apr 2023 20:24:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this trivial change when ZipFS returns the wrong java.nio.file.FileSystemException message due the the parameters being reversed.
> 
> I also included a simple junit test as part of the fix.
> 
> Mach5 tiers1-3 are clean
> 
> Best
> Lance

Looks good, Lance. Nit: copyright year -> 2023

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13482#pullrequestreview-1386182062

From naoto at openjdk.org  Fri Apr 14 21:11:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 14 Apr 2023 21:11:34 GMT
Subject: RFR: 4737887: (cal) API: Calendar methods taking field should
 document exceptions
In-Reply-To: <y65woSohxKGbyGcuLxE9cKokT7YMJIl0uOPpeTiUT0o=.cfdee99e-067b-4139-9802-81def6b81797@github.com>
References: <y65woSohxKGbyGcuLxE9cKokT7YMJIl0uOPpeTiUT0o=.cfdee99e-067b-4139-9802-81def6b81797@github.com>
Message-ID: <5Mq7KMkqWvLrLu-fPUSxT40qJcKx5MwB7qIoCEgTAhU=.163f98fa-924a-4780-bb21-946f981c2612@github.com>

On Wed, 29 Mar 2023 22:04:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Many Calendar methods that take in a field parameter should document that they throw an ArrayIndexOutOfBoundsException if field is not between 0 and `Calendar.FIELD_COUNT`.
> 
> This PR adds a clause to the class description to make the above apparent.
> 
> `Calendar.Roll(int, int)`, `Calendar.roll(int, boolean)`, and `Calendar.add(int, int)` should all be documented that they throw an `IllegalArgumentException` if any calendar fields have out-of-range values in non-lenient mode or if field is
> `Calendar.ZONE_OFFSET`, `Calendar.DST_OFFSET`, or unknown.

Looks good, Justin. Nit: copyright year -> 2023

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13234#pullrequestreview-1386182763

From cstein at openjdk.org  Fri Apr 14 21:11:34 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 14 Apr 2023 21:11:34 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message
In-Reply-To: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
Message-ID: <rsGOqtzjQyYVRVbM677Gh8GSWJorVfi-0FmqOMcL3eo=.532a555a-1410-45fc-863e-a1ecc6321860@github.com>

On Fri, 14 Apr 2023 20:24:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this trivial change when ZipFS returns the wrong java.nio.file.FileSystemException message due the the parameters being reversed.
> 
> I also included a simple junit test as part of the fix.
> 
> Mach5 tiers1-3 are clean
> 
> Best
> Lance

Looks good to me.

-------------

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13482#pullrequestreview-1386182752

From jlu at openjdk.org  Fri Apr 14 21:30:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 14 Apr 2023 21:30:25 GMT
Subject: RFR: 4737887: (cal) API: Calendar methods taking field should
 document exceptions [v2]
In-Reply-To: <y65woSohxKGbyGcuLxE9cKokT7YMJIl0uOPpeTiUT0o=.cfdee99e-067b-4139-9802-81def6b81797@github.com>
References: <y65woSohxKGbyGcuLxE9cKokT7YMJIl0uOPpeTiUT0o=.cfdee99e-067b-4139-9802-81def6b81797@github.com>
Message-ID: <9Ki0whashS3r96TLtxDBMHN0wcAggwZ4n54hd78Qkno=.ec6737a3-6b76-4633-9c61-ac393195b9d8@github.com>

> Many Calendar methods that take in a field parameter should document that they throw an ArrayIndexOutOfBoundsException if field is not between 0 and `Calendar.FIELD_COUNT`.
> 
> This PR adds a clause to the class description to make the above apparent.
> 
> `Calendar.Roll(int, int)`, `Calendar.roll(int, boolean)`, and `Calendar.add(int, int)` should all be documented that they throw an `IllegalArgumentException` if any calendar fields have out-of-range values in non-lenient mode or if field is
> `Calendar.ZONE_OFFSET`, `Calendar.DST_OFFSET`, or unknown.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13234/files
  - new: https://git.openjdk.org/jdk/pull/13234/files/bd6b6e60..9932c204

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13234&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13234&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13234/head:pull/13234

PR: https://git.openjdk.org/jdk/pull/13234

From lancea at openjdk.org  Fri Apr 14 21:37:42 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 14 Apr 2023 21:37:42 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message [v2]
In-Reply-To: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
Message-ID: <38So0kM8VMxQCK4V_oDxxPDv7DM4zPUbwiV4t3injAA=.1256bdde-125a-4b08-8898-6cdf16ab80f0@github.com>

> Please review this trivial change when ZipFS returns the wrong java.nio.file.FileSystemException message due the the parameters being reversed.
> 
> I also included a simple junit test as part of the fix.
> 
> Mach5 tiers1-3 are clean
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Update the copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13482/files
  - new: https://git.openjdk.org/jdk/pull/13482/files/e99a91bf..b1dfab8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13482&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13482&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13482.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13482/head:pull/13482

PR: https://git.openjdk.org/jdk/pull/13482

From lancea at openjdk.org  Fri Apr 14 21:37:43 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 14 Apr 2023 21:37:43 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message [v2]
In-Reply-To: <e9McnwW72ecpPn0f-JYB5rV3nGllciC39U9YsCgNl0c=.b6f8faba-876c-4416-b3c9-98f74db7d63a@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
 <e9McnwW72ecpPn0f-JYB5rV3nGllciC39U9YsCgNl0c=.b6f8faba-876c-4416-b3c9-98f74db7d63a@github.com>
Message-ID: <kiVqNswMbnOg2bwoqY3tyTT3NnEpLYu1scZ5TrxLqnc=.1fa3af18-95c5-441d-98cb-00045858387f@github.com>

On Fri, 14 Apr 2023 21:07:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Looks good, Lance. Nit: copyright year -> 2023

Geez, working in too many workspaces.  Thank you, just pushed the update

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13482#issuecomment-1509300245

From lancea at openjdk.org  Fri Apr 14 21:37:45 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 14 Apr 2023 21:37:45 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message [v2]
In-Reply-To: <rsGOqtzjQyYVRVbM677Gh8GSWJorVfi-0FmqOMcL3eo=.532a555a-1410-45fc-863e-a1ecc6321860@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
 <rsGOqtzjQyYVRVbM677Gh8GSWJorVfi-0FmqOMcL3eo=.532a555a-1410-45fc-863e-a1ecc6321860@github.com>
Message-ID: <9Vmn4lSsA8F-2ZWg5NOP1lYMVoE-RmEUfLMR-fcbutQ=.5da1f0bc-2168-4f18-af81-36dfa1694bc0@github.com>

On Fri, 14 Apr 2023 21:08:28 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Looks good to me.

Thank you Christian

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13482#issuecomment-1509301103

From rriggs at openjdk.org  Fri Apr 14 21:38:41 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Apr 2023 21:38:41 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v13]
In-Reply-To: <jsUfZmkzbPYQ98Ma4MMLm4t4215obdXNnGHA3SgPdwo=.839c5327-6132-46c9-beb4-5823fd2c02b5@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
 <lO7M9T25lZ02nQp3bl6kxwsUVibW8hlyCeS4S9QO92A=.7df8551d-3a35-4871-af06-2f171c19ac3b@github.com>
 <jsUfZmkzbPYQ98Ma4MMLm4t4215obdXNnGHA3SgPdwo=.839c5327-6132-46c9-beb4-5823fd2c02b5@github.com>
Message-ID: <0FxAZMAVyrqeR8n81rBSDKzKSL_GF_Qeyv5QbQeRJBI=.8d285dcf-1f72-40bf-a810-94a8cc073e97@github.com>

On Fri, 14 Apr 2023 17:08:10 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> make/modules/java.base/gensrc/GensrcMisc.gmk line 72:
>> 
>>> 70: endif
>>> 71: 
>>> 72: $(eval $(call SetupTextFileProcessing, BUILD_PLATFORMPROPERTIES_JAVA, \
>> 
>> @erikj79 Is there a better/good way to do these mappings, or select "local" variable names?
>
> Not sure if it's better, but you could consider doing this directly in the switch statements in `make/autoconf/platform.m4` and add the corresponding variables in `spec.gmk.in`. That would make them available globally in the build, which may also be detrimental as parts of the build could start relying on them, and we end up with even more variants sprinkled around. I think what you have here is better for now.

ok, I'd rather keep it local.  Thanks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1167290252

From lancea at openjdk.org  Fri Apr 14 21:40:17 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 14 Apr 2023 21:40:17 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message [v3]
In-Reply-To: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
Message-ID: <GN2eZy4G2QoscSL-F5q5PYvR_gwHiyLhNZ4_lWcIVdk=.c994c4f1-bc79-4bf0-9b64-83caf297bd75@github.com>

> Please review this trivial change when ZipFS returns the wrong java.nio.file.FileSystemException message due the the parameters being reversed.
> 
> I also included a simple junit test as part of the fix.
> 
> Mach5 tiers1-3 are clean
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Minor wordsmithing of test comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13482/files
  - new: https://git.openjdk.org/jdk/pull/13482/files/b1dfab8b..8fbf69aa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13482&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13482&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13482.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13482/head:pull/13482

PR: https://git.openjdk.org/jdk/pull/13482

From duke at openjdk.org  Fri Apr 14 21:41:34 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 14 Apr 2023 21:41:34 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message [v3]
In-Reply-To: <GN2eZy4G2QoscSL-F5q5PYvR_gwHiyLhNZ4_lWcIVdk=.c994c4f1-bc79-4bf0-9b64-83caf297bd75@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
 <GN2eZy4G2QoscSL-F5q5PYvR_gwHiyLhNZ4_lWcIVdk=.c994c4f1-bc79-4bf0-9b64-83caf297bd75@github.com>
Message-ID: <UIWrsoCYVtmTA41GVVjWkA6yDESypC7UkUArK_Vo1-A=.283ea3e7-57d8-4902-9028-ae8787e09d5d@github.com>

On Fri, 14 Apr 2023 21:40:17 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this trivial change when ZipFS returns the wrong java.nio.file.FileSystemException message due the the parameters being reversed.
>> 
>> I also included a simple junit test as part of the fix.
>> 
>> Mach5 tiers1-3 are clean
>> 
>> Best
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor wordsmithing of test comment

LGTM. Leaving some minor comments on the test.

test/jdk/jdk/nio/zipfs/ZipFSDirectoryExceptionMessageTest.java line 40:

> 38:  * @test
> 39:  * @bug 8305945
> 40:  * @summary Validate that Zip FS provides the correct exception message

This summary could perhaps be a bit more specific about which condition / message it is testing.

test/jdk/jdk/nio/zipfs/ZipFSDirectoryExceptionMessageTest.java line 56:

> 54:      * Zip file to create
> 55:      */
> 56:     public static final String ZIP_FILE = "directoryExceptionTest.zip";

Maybe ZIP_FILE could be a Path, to avoid Path.of(ZIP_FILE) wrapping later in the test?

-------------

Marked as reviewed by eirbjo at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/13482#pullrequestreview-1386198889
PR Review Comment: https://git.openjdk.org/jdk/pull/13482#discussion_r1167287569
PR Review Comment: https://git.openjdk.org/jdk/pull/13482#discussion_r1167286862

From lancea at openjdk.org  Fri Apr 14 21:59:33 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 14 Apr 2023 21:59:33 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message [v4]
In-Reply-To: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
Message-ID: <dsZl7CJ3rbJPh2JO1yRX4ftqQwrQXLpZGU6M18thqkY=.ff522259-7131-4251-b01a-59b7d7959a9e@github.com>

> Please review this trivial change when ZipFS returns the wrong java.nio.file.FileSystemException message due the the parameters being reversed.
> 
> I also included a simple junit test as part of the fix.
> 
> Mach5 tiers1-3 are clean
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Address additional feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13482/files
  - new: https://git.openjdk.org/jdk/pull/13482/files/8fbf69aa..f91f8f66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13482&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13482&range=02-03

  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13482.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13482/head:pull/13482

PR: https://git.openjdk.org/jdk/pull/13482

From lancea at openjdk.org  Fri Apr 14 21:59:35 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 14 Apr 2023 21:59:35 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message [v4]
In-Reply-To: <UIWrsoCYVtmTA41GVVjWkA6yDESypC7UkUArK_Vo1-A=.283ea3e7-57d8-4902-9028-ae8787e09d5d@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
 <GN2eZy4G2QoscSL-F5q5PYvR_gwHiyLhNZ4_lWcIVdk=.c994c4f1-bc79-4bf0-9b64-83caf297bd75@github.com>
 <UIWrsoCYVtmTA41GVVjWkA6yDESypC7UkUArK_Vo1-A=.283ea3e7-57d8-4902-9028-ae8787e09d5d@github.com>
Message-ID: <3FjxJWsSuHWShonuP4VLRlV9ZkRNvUDG_gOScB4eULc=.86f04540-f517-4521-84d5-ed5c1f56159d@github.com>

On Fri, 14 Apr 2023 21:30:40 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address additional feedback
>
> test/jdk/jdk/nio/zipfs/ZipFSDirectoryExceptionMessageTest.java line 40:
> 
>> 38:  * @test
>> 39:  * @bug 8305945
>> 40:  * @summary Validate that Zip FS provides the correct exception message
> 
> This summary could perhaps be a bit more specific about which condition / message it is testing.

done

> test/jdk/jdk/nio/zipfs/ZipFSDirectoryExceptionMessageTest.java line 56:
> 
>> 54:      * Zip file to create
>> 55:      */
>> 56:     public static final String ZIP_FILE = "directoryExceptionTest.zip";
> 
> Maybe ZIP_FILE could be a Path, to avoid Path.of(ZIP_FILE) wrapping later in the test?

I often do that but chose not to when I created the test but have updated per your suggestion

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13482#discussion_r1167297960
PR Review Comment: https://git.openjdk.org/jdk/pull/13482#discussion_r1167299017

From duke at openjdk.org  Fri Apr 14 22:11:33 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 14 Apr 2023 22:11:33 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message [v4]
In-Reply-To: <dsZl7CJ3rbJPh2JO1yRX4ftqQwrQXLpZGU6M18thqkY=.ff522259-7131-4251-b01a-59b7d7959a9e@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
 <dsZl7CJ3rbJPh2JO1yRX4ftqQwrQXLpZGU6M18thqkY=.ff522259-7131-4251-b01a-59b7d7959a9e@github.com>
Message-ID: <QNCEN51c5nWkzvvTBfoAu6OBz8U3JovgAOfOe1_iBlc=.27695314-7777-46a9-bdf1-4f063aebd1b5@github.com>

On Fri, 14 Apr 2023 21:59:33 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this trivial change when ZipFS returns the wrong java.nio.file.FileSystemException message due the the parameters being reversed.
>> 
>> I also included a simple junit test as part of the fix.
>> 
>> Mach5 tiers1-3 are clean
>> 
>> Best
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address additional feedback

test/jdk/jdk/nio/zipfs/ZipFSDirectoryExceptionMessageTest.java line 96:

> 94:             var file = zipfs.getPath(DIRECTORY_NAME);
> 95:             var x = assertThrows(FileSystemException.class, () -> Files.newInputStream(file));
> 96:             assertEquals(x.getMessage(), DIR_EXCEPTION_MESSAGE);

JUnit asserts have the expected parameter first followed by the actual.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13482#discussion_r1167305606

From bchristi at openjdk.org  Fri Apr 14 22:27:26 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 14 Apr 2023 22:27:26 GMT
Subject: RFR: 8305762: FileInputStream and FileOutputStream implSpec should
 be corrected or removed [v2]
In-Reply-To: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
References: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
Message-ID: <RiMpoHIlzBMFEzGgQ3aD8V4HHmz2kDfNILvU8EEKwZw=.294739e7-80fc-4dc5-a9a7-d5d20445df03@github.com>

> With the removal of the AltFinalizer mechanism from `FileInputStream` and `FileOutputStream` in [JDK-8192939](https://bugs.openjdk.org/browse/JDK-8192939), this portion of the Implementation Requirement in the class JavaDoc is no longer true:
> 
>> If this FileOutputStream has been subclassed and the close() method has been overridden, the close() method will be called when the FileInputStream is unreachable."
> 
> The class doc, and the doc for close(), are updated to correctly reflect current behavior, and guidance for subclasses is clarified.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  updates, per review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13437/files
  - new: https://git.openjdk.org/jdk/pull/13437/files/db7c33e0..3adb17e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13437&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13437&range=00-01

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13437.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13437/head:pull/13437

PR: https://git.openjdk.org/jdk/pull/13437

From bchristi at openjdk.org  Fri Apr 14 22:27:29 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 14 Apr 2023 22:27:29 GMT
Subject: RFR: 8305762: FileInputStream and FileOutputStream implSpec should
 be corrected or removed [v2]
In-Reply-To: <8IXpgKy4qK1woM-A3yu8Xn-r4YPrsdOx2PvpXbEImEU=.5690beb6-79e6-4a45-837b-f2d362eb247d@github.com>
References: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
 <8IXpgKy4qK1woM-A3yu8Xn-r4YPrsdOx2PvpXbEImEU=.5690beb6-79e6-4a45-837b-f2d362eb247d@github.com>
Message-ID: <d09g6PWzN_EdiRInUThQUx4n2S6r4LrqPDnXQMga0vs=.9521b214-8d67-4cdd-8c4c-27c5bc636807@github.com>

On Fri, 14 Apr 2023 07:57:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates, per review comments
>
> src/java.base/share/classes/java/io/FileInputStream.java line 45:
> 
>> 43:  * @apiNote
>> 44:  * To release resources used by this stream {@link #close} should be called
>> 45:  * directly or by try-with-resources.
> 
> I wonder if we should re-word the API note at the same time. I think it would be more readable to start with "The close method should be called ...".

Sounds good to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13437#discussion_r1167310827

From bchristi at openjdk.org  Fri Apr 14 23:13:33 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 14 Apr 2023 23:13:33 GMT
Subject: RFR: 8305762: FileInputStream and FileOutputStream implSpec should
 be corrected or removed [v2]
In-Reply-To: <RiMpoHIlzBMFEzGgQ3aD8V4HHmz2kDfNILvU8EEKwZw=.294739e7-80fc-4dc5-a9a7-d5d20445df03@github.com>
References: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
 <RiMpoHIlzBMFEzGgQ3aD8V4HHmz2kDfNILvU8EEKwZw=.294739e7-80fc-4dc5-a9a7-d5d20445df03@github.com>
Message-ID: <kTQJaN0nr3l0ugkO5jnFVrh21eg9kX1z760kvC4MMDE=.2f76318e-911c-4ebe-9eb3-6bd300453a1c@github.com>

On Fri, 14 Apr 2023 22:27:26 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> With the removal of the AltFinalizer mechanism from `FileInputStream` and `FileOutputStream` in [JDK-8192939](https://bugs.openjdk.org/browse/JDK-8192939), this portion of the Implementation Requirement in the class JavaDoc is no longer true:
>> 
>>> If this FileOutputStream has been subclassed and the close() method has been overridden, the close() method will be called when the FileInputStream is unreachable."
>> 
>> The class doc, and the doc for close(), are updated to correctly reflect current behavior, and guidance for subclasses is clarified.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates, per review comments

In my mind, this is covered by the existing CSR ([8212050](https://bugs.openjdk.org/browse/JDK-8212050)) from JDK 12.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13437#issuecomment-1509381396

From lancea at openjdk.org  Sat Apr 15 00:36:35 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 15 Apr 2023 00:36:35 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message [v5]
In-Reply-To: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
Message-ID: <zmtUmRIk6ROWW5yKE021OHfxCVizgi2kx2I3Pz0Hzns=.388e4b99-ccdc-4ad5-b7c5-50a97e5a9b3f@github.com>

> Please review this trivial change when ZipFS returns the wrong java.nio.file.FileSystemException message due the the parameters being reversed.
> 
> I also included a simple junit test as part of the fix.
> 
> Mach5 tiers1-3 are clean
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  re-arrage assertEquals params

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13482/files
  - new: https://git.openjdk.org/jdk/pull/13482/files/f91f8f66..3067fd17

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13482&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13482&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13482.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13482/head:pull/13482

PR: https://git.openjdk.org/jdk/pull/13482

From duke at openjdk.org  Sat Apr 15 01:38:59 2023
From: duke at openjdk.org (duke)
Date: Sat, 15 Apr 2023 01:38:59 GMT
Subject: Withdrawn: 8300819: -Dfile.encoding=Cp943C option does not work as
 expected since jdk18
In-Reply-To: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
References: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
Message-ID: <dS8Hnk5dCzJ4wvbulDdEZ4sWyPkcGlAmSf75kCF8KIM=.752a44e2-20ce-4453-9767-62badf14af3b@github.com>

On Sun, 22 Jan 2023 09:18:37 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On jdk17, following testcase works fine on Linux platform.
> 
> Testcase
> 
> $ cat cstest1.java
> import java.nio.charset.*;
> 
> public class cstest1 {
>   public static void main(String[] args) throws Exception {
>     Charset cs = Charset.defaultCharset();
>     System.out.println(cs + ", " + cs.getClass() + ", " + cs.getClass().getModule());
>   }
> }
> 
> 
> $ ~/jdk-17.0.6+10/bin/java -Dfile.encoding=Cp943C -showversion cstest1
> openjdk version "17.0.6" 2023-01-17
> OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)
> OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode, sharing)
> x-IBM943C, class sun.nio.cs.ext.IBM943C, module jdk.charsets
> 
> 
> But it does not work as expected on jdk18 and jdk21b06
> 
> $ ~/jdk-18.0.2.1+1/bin/java -Dfile.encoding=Cp943C -showversion cstest1
> openjdk version "18.0.2.1" 2022-08-18
> OpenJDK Runtime Environment Temurin-18.0.2.1+1 (build 18.0.2.1+1)
> OpenJDK 64-Bit Server VM Temurin-18.0.2.1+1 (build 18.0.2.1+1, mixed mode, sharing)
> UTF-8, class sun.nio.cs.UTF_8, module java.base
> $ ~/jdk-21/bin/java -Dfile.encoding=Cp943C -showversion cstest1
> openjdk version "21-ea" 2023-09-19
> OpenJDK Runtime Environment (build 21-ea+6-365)
> OpenJDK 64-Bit Server VM (build 21-ea+6-365, mixed mode, sharing)
> UTF-8, class sun.nio.cs.UTF_8, module java.base
> 
> 
> Fixed result is as follows:
> 
> $ java -Dfile.encoding=Cp943C -showversion PrintDefaultCharset
> openjdk version "21-internal" 2023-09-19
> OpenJDK Runtime Environment (build 21-internal-adhoc.jdktest.jdk)
> OpenJDK 64-Bit Server VM (build 21-internal-adhoc.jdktest.jdk, mixed mode, sharing)
> x-IBM943C

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12132

From duke at openjdk.org  Sat Apr 15 02:01:52 2023
From: duke at openjdk.org (duke)
Date: Sat, 15 Apr 2023 02:01:52 GMT
Subject: Withdrawn: 8298045: Fix hidden but significant trailing whitespace in
 properties files for core-libs code
In-Reply-To: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
References: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
Message-ID: <G6Tw0B0L-RsbxtWAHaDtj3Q11H47PQZYJKw69j5oF9g=.bb2621e8-9cb4-43b8-a12d-a71640263d0c@github.com>

On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11489

From smarks at openjdk.org  Sat Apr 15 03:25:57 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 15 Apr 2023 03:25:57 GMT
Subject: RFR: 8266571: Sequenced Collections [v5]
In-Reply-To: <GJkAIGx5Uz8ZxhsrU_bDnAuY7rcbO-D8uvo3QvRSitk=.a87ab652-f06c-40f5-84e3-7db010320413@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <GJkAIGx5Uz8ZxhsrU_bDnAuY7rcbO-D8uvo3QvRSitk=.a87ab652-f06c-40f5-84e3-7db010320413@github.com>
Message-ID: <NImQYHP42usknATrLWqtKl03V68KbsyzyInzcnzTLD4=.4702e010-2a40-4959-82c1-2e88890f0f07@github.com>

On Thu, 3 Nov 2022 20:33:40 GMT, Chen Liang <liach 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 80 commits:
>> 
>>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>>  - Simplify handling of cached keySet, values, and entrySet views.
>>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>>  - Update copyrights.
>>  - More specification tweaks.
>>  - Add simple overrides to ArrayList.
>>  - Specification cleanups.
>>  - Update spec of CopyOnWriteArrayList::reversed.
>>  - Move AbstractViewCollection to AbstractMap.ViewCollection to avoid exposing it publicly.
>>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>>    Resolve conflict by deleting IdentityLinkedList.java
>>  - ... and 70 more: https://git.openjdk.org/jdk/compare/76cda9f4...1332c3e2
>
> src/java.base/share/classes/java/util/SortedSet.java line 303:
> 
>> 301:      * @since 20
>> 302:      */
>> 303:     default E removeFirst() {
> 
> Should removeFirst/removeLast be overridden in NavigableSet with a new default implementation like:
> 
>     if (this.isEmpty()) {
>         throw new NoSuchElementException();
>     }
>     return this.pollFirst();
> 
> which is probably slightly more efficient?

Good idea, I'll do this now that I'm revisiting the specs of the default methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1167365546

From smarks at openjdk.org  Sat Apr 15 03:35:50 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 15 Apr 2023 03:35:50 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: <3e6DVS8g_L4Yv27PiLlRyv6Fu7RsSR43gvKKHZKQvmw=.296a96fe-6134-407b-8078-d65e54bfbc30@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <AVG0xaAX6FZuBx6zF9rv4HYkltv47a1-uGPJazz0avc=.b2c275f6-807b-4817-89b1-8fc3374de933@github.com>
 <3e6DVS8g_L4Yv27PiLlRyv6Fu7RsSR43gvKKHZKQvmw=.296a96fe-6134-407b-8078-d65e54bfbc30@github.com>
Message-ID: <sXcjryvhob6aK_GhWL_IjXdwc0VesbiKSAhUjxLP7fc=.93b67078-363b-4d1f-99e2-df4c9d53b65b@github.com>

On Sat, 25 Mar 2023 07:09:43 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - More specification tweaks.
>>  - Add simple overrides to ArrayList.
>
> src/java.base/share/classes/java/util/ArrayList.java line 573:
> 
>> 571:         } else {
>> 572:             Object[] es = elementData;
>> 573:             sz--;
> 
> This line and the following two lines can be understood as the field size being updated which is not the case.
> I think it's more readable to use
> 
> @SuppressWarnings("unchecked") E oldValue = (E) es[sz - 1];
> fastRemove(es, sz - 1);
> 
> The JIT will common the subexpression 'sz - 1' at runtime.

Renamed the variable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1167366493

From smarks at openjdk.org  Sat Apr 15 04:17:54 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 15 Apr 2023 04:17:54 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <C2u66ylWBUFGree3MofE_kPuVg325Jr9xcXOhAr9hwg=.78835d20-9032-4e40-ad00-7a51b0b64a26@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 <C2u66ylWBUFGree3MofE_kPuVg325Jr9xcXOhAr9hwg=.78835d20-9032-4e40-ad00-7a51b0b64a26@github.com>
Message-ID: <R7h9WG6dwVnOzDKeJhcQUT8uMjmEj72KBVlCvfhsdAE=.1879ee67-2bcd-4dff-a34e-d6cd3e2ed7f2@github.com>

On Thu, 30 Mar 2023 09:39:14 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> 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.
>
> src/java.base/share/classes/java/util/LinkedHashMap.java line 78:
> 
>> 76:  * on collection-views do <i>not</i> affect the order of iteration of the
>> 77:  * backing map.
>> 78:  *
> 
> I see above the list of methods that affect the encounter order in access-order mode:
>> Invoking the put, putIfAbsent, get, getOrDefault, compute, computeIfAbsent, computeIfPresent, or merge methods results in an access...
> 
> Should we extend it to add new methods like putFirst and putLast? Also, it says that 'In particular, operations on collection-views do not affect the order of iteration of the backing map'. Now, we have a map-view (`reversed()`). We should specify whether operations on the reversed map change the encounter order of the original map, and if yes then how exactly they do this (moving entries to the end, like in the original map, or moving them to the beginning?)

The list of methods that generate accesses shouldn't include any explicit-positioning methods. They should do exactly as one expects and shouldn't change encounter order based on access to an element. For example, firstEntry shouldn't move the entry to the end, and putFirst should put the entry at the front and not at the end. But it's worth clarifying that the same methods on the reversed view generate accesses to the backing map and update the order. And also, an access to an entry in the reversed view should move it to the front. (putAll doesn't work though because of bugs you pointed out elsewhere.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1167370506

From smarks at openjdk.org  Sat Apr 15 04:25:47 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 15 Apr 2023 04:25:47 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <C2u66ylWBUFGree3MofE_kPuVg325Jr9xcXOhAr9hwg=.78835d20-9032-4e40-ad00-7a51b0b64a26@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 <C2u66ylWBUFGree3MofE_kPuVg325Jr9xcXOhAr9hwg=.78835d20-9032-4e40-ad00-7a51b0b64a26@github.com>
Message-ID: <imovpRifeVJbUVw_Lytt4PWaKfMjphqwrnplZJkbkbU=.7ab1e77d-29d2-46e2-a756-2ba9522e627a@github.com>

On Thu, 30 Mar 2023 09:20:16 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> 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.
>
> src/java.base/share/classes/java/util/SequencedCollection.java line 78:
> 
>> 76:  * @since 21
>> 77:  */
>> 78: public interface SequencedCollection<E> extends Collection<E> {
> 
> Should we narrow the specification for `Collection::add` here, saying that `add` is essentially `addLast`? Specification for deque mentions that `add` and `addLast` are equivalent. Otherwise, the implementation of `SequencedCollection::add` that adds the element to a random position will comply the spec.
> 
> Another thing is `remove(Object)`. Should we specify here that it will remove the first instance of Object inside the collection (like it's specified in the list)? Or is it allowed to return a random one?

`add` isn't the same as `addLast` because things like `SortedSet.add` need to add the element in its proper place. The other subtypes `List`, `Deque`, and `LinkedHashSet` specify that added elements go at the end. But we can't rule out some new collection that might have some reasonable rule for adding a new element other than in the last position.

`List` and `Deque` specify that `remove` removes the first occurrence, but this doesn't apply to `LinkedHashSet` or `SortedSet` since they can have only one occurrence of a matching element. Thus we don't have any obvious examples. But somebody might come up with some new collection for which the first occurrence of duplicate elements isn't the right semantics, so I don't think we want to specify that here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1167371303

From alanb at openjdk.org  Sat Apr 15 05:45:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Apr 2023 05:45:34 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message [v5]
In-Reply-To: <zmtUmRIk6ROWW5yKE021OHfxCVizgi2kx2I3Pz0Hzns=.388e4b99-ccdc-4ad5-b7c5-50a97e5a9b3f@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
 <zmtUmRIk6ROWW5yKE021OHfxCVizgi2kx2I3Pz0Hzns=.388e4b99-ccdc-4ad5-b7c5-50a97e5a9b3f@github.com>
Message-ID: <3OwgsaH4m-Py4V_0Naj7k6ZPYQP53ClfsL-2MdVW9v8=.fe1d81bd-89ee-49a8-9cd9-6df9d5971426@github.com>

On Sat, 15 Apr 2023 00:36:35 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this trivial change when ZipFS returns the wrong java.nio.file.FileSystemException message due the the parameters being reversed.
>> 
>> I also included a simple junit test as part of the fix.
>> 
>> Mach5 tiers1-3 are clean
>> 
>> Best
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-arrage assertEquals params

test/jdk/jdk/nio/zipfs/ZipFSDirectoryExceptionMessageTest.java line 96:

> 94:             var file = zipfs.getPath(DIRECTORY_NAME);
> 95:             var x = assertThrows(FileSystemException.class, () -> Files.newInputStream(file));
> 96:             assertEquals(DIR_EXCEPTION_MESSAGE, x.getMessage());

FYI, test doesn't need to depend the exception message. Checking FileSystemException::getOtherFile returns null would be a more robust way of checking that it didn't provide a second file by mistake, e.g.

       try {
            Files.newInputStream(DIRECTORY_NAME);
            fail();
        } catch (FileSystemException e) {
            assertNull(e.getOtherFile());
        } catch (IOException ioe) { 
            // allowed
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13482#discussion_r1167384199

From Alan.Bateman at oracle.com  Sat Apr 15 07:04:28 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 15 Apr 2023 08:04:28 +0100
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <CAJL5A3kxWKdoWHGL1k70Ae6ED+HTvRCmXXGxOMXvwQ_VBQMF1A@mail.gmail.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
 <CAJL5A3mKDLWw4AeToiaKrjs2+50qTPJEDmOc8XuFCWYACbd0BQ@mail.gmail.com>
 <549e246f-eb19-8a6a-5e83-5b3c615e51ca@oracle.com>
 <CAJL5A3kxWKdoWHGL1k70Ae6ED+HTvRCmXXGxOMXvwQ_VBQMF1A@mail.gmail.com>
Message-ID: <a6d6724f-13f4-c134-edd4-e147a5610517@oracle.com>

On 13/04/2023 15:58, Glavo wrote:
> :
>
> I thought it might be more efficient to discuss after creating a draft PR.
> It seems that it is difficult to attract more experts to participate 
> in the
> discussion only on the mailing list. Do you have any suggestions for this?
>

This proposal is not something to be hurried. It could be massively 
disruptive change and would need to be looked at in the context of all 
APIs that use the default locale. It would also need to be looked at in 
the context of new developers starting out and just wanting to get a toy 
program working. It might be confusing for new developers to find 
themselves using a neutral locale. If a new developer is forced to 
choose between Locale.ROOT and Locale.getDefault() during their first 
week of coding then it will give a terrible first impression.

One of your messages lists cleaning up usages in the JDK. Auditing the 
usages to identify any cases that should be changed from using the 
default locale to Locale.ROOT would be a contribution. So if you have 
the energy to do that they it would be useful to start.

-Alan.

From alanb at openjdk.org  Sat Apr 15 07:13:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Apr 2023 07:13:34 GMT
Subject: RFR: 8305762: FileInputStream and FileOutputStream implSpec should
 be corrected or removed [v2]
In-Reply-To: <RiMpoHIlzBMFEzGgQ3aD8V4HHmz2kDfNILvU8EEKwZw=.294739e7-80fc-4dc5-a9a7-d5d20445df03@github.com>
References: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
 <RiMpoHIlzBMFEzGgQ3aD8V4HHmz2kDfNILvU8EEKwZw=.294739e7-80fc-4dc5-a9a7-d5d20445df03@github.com>
Message-ID: <S-X1H-7gQanksYDftQiZwLnrqE1UCqbiD3PIKEsssSg=.b076926d-841e-49fe-a995-940b2c60615c@github.com>

On Fri, 14 Apr 2023 22:27:26 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> With the removal of the AltFinalizer mechanism from `FileInputStream` and `FileOutputStream` in [JDK-8192939](https://bugs.openjdk.org/browse/JDK-8192939), this portion of the Implementation Requirement in the class JavaDoc is no longer true:
>> 
>>> If this FileOutputStream has been subclassed and the close() method has been overridden, the close() method will be called when the FileInputStream is unreachable."
>> 
>> The class doc, and the doc for close(), are updated to correctly reflect current behavior, and guidance for subclasses is clarified.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates, per review comments

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/io/FileInputStream.java line 45:

> 43:  * @apiNote
> 44:  * The {@link #close} method should be called to release resources used by this
> 45:  * stream, either directly, or by try-with-resources.

The updated wording looks much better. It pre-dates your change but maybe "or by try-with-resources" should be changed to "with the {@code try}-with-resources statement" while you are there.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13437#pullrequestreview-1386351626
PR Review Comment: https://git.openjdk.org/jdk/pull/13437#discussion_r1167412577

From zjx001202 at gmail.com  Sat Apr 15 07:50:19 2023
From: zjx001202 at gmail.com (Glavo)
Date: Sat, 15 Apr 2023 15:50:19 +0800
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <a6d6724f-13f4-c134-edd4-e147a5610517@oracle.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
 <CAJL5A3mKDLWw4AeToiaKrjs2+50qTPJEDmOc8XuFCWYACbd0BQ@mail.gmail.com>
 <549e246f-eb19-8a6a-5e83-5b3c615e51ca@oracle.com>
 <CAJL5A3kxWKdoWHGL1k70Ae6ED+HTvRCmXXGxOMXvwQ_VBQMF1A@mail.gmail.com>
 <a6d6724f-13f4-c134-edd4-e147a5610517@oracle.com>
Message-ID: <CAJL5A3=7T=L7n1MSneHc7cwA2LmhrMmhG2HQ42rF=JZ13EDxkw@mail.gmail.com>

Hi Alan,

In discussions with others, my thoughts have changed.

I describe the issue in more detail[1] and have a new plan:

1. Add new locale insensitive APIs and recommend users to use them in new
> code.
>
>    I hope this step can be implemented in Java 21.
>
> 2. Add a new system property that allows users to configure the behavior of
>    these two methods.
>
> 3. Gradually clean up the use cases inside JDK.
>
>    Since this involves a dozen modules and hundreds of source files, I
> need to
>    split them into many PRs, and some of them require CSR. Reviewing them
> may
>    take a long time, this step will be done slowly in the future.
>
> 4. Deprecate the two methods.
>
>    This step may take place much later.
>

I hope to prioritize the first step now, at least introducing a new clean
API in Java 21.
Do you have any opinions on this plan?

Glavo

[1] https://mail.openjdk.org/pipermail/core-libs-dev/2023-April/104118.html

On Sat, Apr 15, 2023 at 3:04?PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 13/04/2023 15:58, Glavo wrote:
> > :
> >
> > I thought it might be more efficient to discuss after creating a draft
> PR.
> > It seems that it is difficult to attract more experts to participate
> > in the
> > discussion only on the mailing list. Do you have any suggestions for
> this?
> >
>
> This proposal is not something to be hurried. It could be massively
> disruptive change and would need to be looked at in the context of all
> APIs that use the default locale. It would also need to be looked at in
> the context of new developers starting out and just wanting to get a toy
> program working. It might be confusing for new developers to find
> themselves using a neutral locale. If a new developer is forced to
> choose between Locale.ROOT and Locale.getDefault() during their first
> week of coding then it will give a terrible first impression.
>
> One of your messages lists cleaning up usages in the JDK. Auditing the
> usages to identify any cases that should be changed from using the
> default locale to Locale.ROOT would be a contribution. So if you have
> the energy to do that they it would be useful to start.
>
> -Alan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230415/725f4678/attachment-0001.htm>

From duke at openjdk.org  Sat Apr 15 08:06:27 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 15 Apr 2023 08:06:27 GMT
Subject: RFR: 8306036: Use @apiNote in String.toLowerCase, String.toUpperCase
Message-ID: <-BY9vNZpmJGzCqABQXT708aGIM6Cb8UFnXPEVZQpoL4=.2dd38e9a-9669-41be-b97e-2e69a2b00a01@github.com>

Please review this PR which suggests to use `@apiNote` in the `String.toLowerCase()` and `String.toUpperCase()` API docs.

These methods include import usage notes which today are encoded using `<b>Note:</b>`.

-------------

Commit messages:
 - Use @apiNote in String.toLowerCase, String.toUpperCase

Changes: https://git.openjdk.org/jdk/pull/13487/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13487&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306036
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13487.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13487/head:pull/13487

PR: https://git.openjdk.org/jdk/pull/13487

From alanb at openjdk.org  Sat Apr 15 08:57:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Apr 2023 08:57:41 GMT
Subject: RFR: 8305904: java/lang/Character,
 java/lang/String and java/text/Normalizer tests read the unicode data files
 from src directories.
In-Reply-To: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
References: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
Message-ID: <NgYRAM73jSjp6yuyL3nwIhGnWMerp4Be-w30WXYZ9tQ=.11dbdeac-27b1-4075-bd02-b2e5161a5186@github.com>

On Wed, 12 Apr 2023 16:35:19 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Following tests read the unicode data files (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, these files should be in test directories. No source code is using these files. Only tests are using these files. Tests are :
> java/lang/Character/CharPropTest.java
> java/lang/Character/CheckProp.java
> java/lang/Character/CheckScript.java
> java/lang/Character/CheckUnicode.java
> java/lang/Character/UnicodeBlock/CheckBlocks.java
> java/lang/Character/UnicodeCasingTest.java
> java/lang/String/SpecialCasingTest.java
> java/lang/String/UnicodeCasingTest.java
> java/text/Normalizer/ConformanceTest.java

I assume this PR should be closed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13447#issuecomment-1509655420

From Alan.Bateman at oracle.com  Sat Apr 15 09:08:34 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 15 Apr 2023 10:08:34 +0100
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <CAJL5A3=7T=L7n1MSneHc7cwA2LmhrMmhG2HQ42rF=JZ13EDxkw@mail.gmail.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
 <CAJL5A3mKDLWw4AeToiaKrjs2+50qTPJEDmOc8XuFCWYACbd0BQ@mail.gmail.com>
 <549e246f-eb19-8a6a-5e83-5b3c615e51ca@oracle.com>
 <CAJL5A3kxWKdoWHGL1k70Ae6ED+HTvRCmXXGxOMXvwQ_VBQMF1A@mail.gmail.com>
 <a6d6724f-13f4-c134-edd4-e147a5610517@oracle.com>
 <CAJL5A3=7T=L7n1MSneHc7cwA2LmhrMmhG2HQ42rF=JZ13EDxkw@mail.gmail.com>
Message-ID: <fa44cb82-67f3-73af-881d-6994ccfd2e62@oracle.com>

On 15/04/2023 08:50, Glavo wrote:
> Hi Alan,
>
> In discussions with others, my thoughts have changed.
>
> I describe the issue in more detail[1] and have a new plan:
>
>     1. Add new locale insensitive APIs and recommend users to use them
>     in new code.
>
>     ? ?I hope this step can be implemented in Java 21.
>
>     2. Add a new system property that allows users to configure the
>     behavior of
>     ? ?these two methods.
>
>     3. Gradually clean up the use cases inside JDK.
>
>     ? ?Since this involves a dozen modules and hundreds of source
>     files, I need to
>     ? ?split them into many PRs, and some of them require CSR.
>     Reviewing them may
>     ? ?take a long time, this step will be done slowly in the future.
>
>     4. Deprecate the two methods.
>
>     ? ?This step may take place much later.
>
>
> I hope to prioritize the first step now, at least introducing a new 
> clean API in Java 21.
> Do you have any opinions on this plan?
>

Sorry Glavo, I cannot support this plan as it appears to be trying to 
rush #1 and #4 into the current release. As I said in the other mail, 
it's very disruptive and requires broader consideration and thinking 
about other locale sensitive APIs.

#3 is the only part of this list that make sense right now.

-Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230415/efd827c7/attachment-0001.htm>

From lancea at openjdk.org  Sat Apr 15 10:29:43 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 15 Apr 2023 10:29:43 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message [v6]
In-Reply-To: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
Message-ID: <LnaTuZyYHa7PTAByK8aoepqkD4PzrbKukRqjTHe6eWg=.4ff600dd-9e5d-4958-aaad-df41418bd9d7@github.com>

> Please review this trivial change when ZipFS returns the wrong java.nio.file.FileSystemException message due the the parameters being reversed.
> 
> I also included a simple junit test as part of the fix.
> 
> Mach5 tiers1-3 are clean
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  added valiation that other file is null

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13482/files
  - new: https://git.openjdk.org/jdk/pull/13482/files/3067fd17..74534d59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13482&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13482&range=04-05

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13482.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13482/head:pull/13482

PR: https://git.openjdk.org/jdk/pull/13482

From lancea at openjdk.org  Sat Apr 15 10:29:44 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 15 Apr 2023 10:29:44 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message [v5]
In-Reply-To: <3OwgsaH4m-Py4V_0Naj7k6ZPYQP53ClfsL-2MdVW9v8=.fe1d81bd-89ee-49a8-9cd9-6df9d5971426@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
 <zmtUmRIk6ROWW5yKE021OHfxCVizgi2kx2I3Pz0Hzns=.388e4b99-ccdc-4ad5-b7c5-50a97e5a9b3f@github.com>
 <3OwgsaH4m-Py4V_0Naj7k6ZPYQP53ClfsL-2MdVW9v8=.fe1d81bd-89ee-49a8-9cd9-6df9d5971426@github.com>
Message-ID: <RugWryBennaYioCZFHa9I0UJkvzojpPf2fhmNZk8EHU=.b402af07-8091-4c76-9943-9cd1d9c797ea@github.com>

On Sat, 15 Apr 2023 05:43:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   re-arrage assertEquals params
>
> test/jdk/jdk/nio/zipfs/ZipFSDirectoryExceptionMessageTest.java line 96:
> 
>> 94:             var file = zipfs.getPath(DIRECTORY_NAME);
>> 95:             var x = assertThrows(FileSystemException.class, () -> Files.newInputStream(file));
>> 96:             assertEquals(DIR_EXCEPTION_MESSAGE, x.getMessage());
> 
> FYI, test doesn't need to depend the exception message. Checking FileSystemException::getOtherFile returns null would be a more robust way of checking that it didn't provide a second file by mistake, e.g.
> 
>        try {
>             Files.newInputStream(DIRECTORY_NAME);
>             fail();
>         } catch (FileSystemException e) {
>             assertNull(e.getOtherFile());
>         } catch (IOException ioe) { 
>             // allowed
>         }

added validation for other file being null but also kept the existing validation of the message

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13482#discussion_r1167471233

From duke at openjdk.org  Sat Apr 15 11:17:34 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 15 Apr 2023 11:17:34 GMT
Subject: RFR: 8306036: Use @apiNote in String.toLowerCase,
 String.toUpperCase [v2]
In-Reply-To: <-BY9vNZpmJGzCqABQXT708aGIM6Cb8UFnXPEVZQpoL4=.2dd38e9a-9669-41be-b97e-2e69a2b00a01@github.com>
References: <-BY9vNZpmJGzCqABQXT708aGIM6Cb8UFnXPEVZQpoL4=.2dd38e9a-9669-41be-b97e-2e69a2b00a01@github.com>
Message-ID: <6KTQ3_DmIbudbhJD6Ei4yhTME93NJj04gllwxKJX_C0=.9a399d1c-334c-423f-af6d-b046643bcc68@github.com>

> Please review this PR which suggests to use `@apiNote` in the `String.toLowerCase()` and `String.toUpperCase()` API docs.
> 
> These methods include important usage notes which today are encoded using `<b>Note:</b>`.

Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into to-ul-case-apinote
 - Use @apiNote in String.toLowerCase, String.toUpperCase

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13487/files
  - new: https://git.openjdk.org/jdk/pull/13487/files/a9ba49e5..044ad67d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13487&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13487&range=00-01

  Stats: 1259 lines in 134 files changed: 69 ins; 130 del; 1060 mod
  Patch: https://git.openjdk.org/jdk/pull/13487.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13487/head:pull/13487

PR: https://git.openjdk.org/jdk/pull/13487

From zjx001202 at gmail.com  Sat Apr 15 12:39:13 2023
From: zjx001202 at gmail.com (Glavo)
Date: Sat, 15 Apr 2023 20:39:13 +0800
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <fa44cb82-67f3-73af-881d-6994ccfd2e62@oracle.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
 <CAJL5A3mKDLWw4AeToiaKrjs2+50qTPJEDmOc8XuFCWYACbd0BQ@mail.gmail.com>
 <549e246f-eb19-8a6a-5e83-5b3c615e51ca@oracle.com>
 <CAJL5A3kxWKdoWHGL1k70Ae6ED+HTvRCmXXGxOMXvwQ_VBQMF1A@mail.gmail.com>
 <a6d6724f-13f4-c134-edd4-e147a5610517@oracle.com>
 <CAJL5A3=7T=L7n1MSneHc7cwA2LmhrMmhG2HQ42rF=JZ13EDxkw@mail.gmail.com>
 <fa44cb82-67f3-73af-881d-6994ccfd2e62@oracle.com>
Message-ID: <CAJL5A3kNp5FoDf5Py7dQ=+oYtfw32FxFyzaWxsYyRJB9EgPr0Q@mail.gmail.com>

>
> Sorry Glavo, I cannot support this plan as it appears to be trying to rush
> #1 and #4 into the current release.
>

This is not true, I only hope that the first step - two new API methods -
can become a part of Java 21.

The fourth step must be completed after the first and third steps are
completed, or perhaps never.

 As I said in the other mail, it's very disruptive and requires broader
> consideration and thinking about other locale sensitive APIs.
>

I don't understand why the first step is disruptive. It just adds two new
methods, replacing toLowerCase(ROOT) and toUpperCase(ROOT).

I've detailed the reasons for introducing a new API earlier, and I hope
you'll take a look at it:

https://mail.openjdk.org/pipermail/core-libs-dev/2023-April/104118.html


Best regards,
Glavo


On Sat, Apr 15, 2023 at 5:08?PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 15/04/2023 08:50, Glavo wrote:
>
> Hi Alan,
>
> In discussions with others, my thoughts have changed.
>
> I describe the issue in more detail[1] and have a new plan:
>
> 1. Add new locale insensitive APIs and recommend users to use them in new
>> code.
>>
>>    I hope this step can be implemented in Java 21.
>>
>> 2. Add a new system property that allows users to configure the behavior
>> of
>>    these two methods.
>>
>> 3. Gradually clean up the use cases inside JDK.
>>
>>    Since this involves a dozen modules and hundreds of source files, I
>> need to
>>    split them into many PRs, and some of them require CSR. Reviewing them
>> may
>>    take a long time, this step will be done slowly in the future.
>>
>> 4. Deprecate the two methods.
>>
>>    This step may take place much later.
>>
>
> I hope to prioritize the first step now, at least introducing a new clean
> API in Java 21.
> Do you have any opinions on this plan?
>
>
> Sorry Glavo, I cannot support this plan as it appears to be trying to rush
> #1 and #4 into the current release. As I said in the other mail, it's very
> disruptive and requires broader consideration and thinking about other
> locale sensitive APIs.
>
> #3 is the only part of this list that make sense right now.
>
> -Alan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230415/127f6fbe/attachment-0001.htm>

From duke at openjdk.org  Sat Apr 15 13:56:40 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 15 Apr 2023 13:56:40 GMT
Subject: RFR: 8305461: [vectorapi] Add VectorMask::xor
In-Reply-To: <d0xuQnDOKYZBo7uu9P8XWouqJl0wujz0wiVX8qkMRlI=.3a9a8874-9929-4ec2-b0ad-7d303261fa0c@github.com>
References: <3qsNbKA1cm_XZnUNTDApkZDGMBq6PXcXZBTvEdv9UC4=.5dc8fed0-684e-4cd1-a007-d5e0c3cd0a65@github.com>
 <jwSNj78SkdTEkWtny9s7dV1VH1RA8qYV1ZD2tONFj0Q=.98bb0702-3d1b-4232-9f69-6f4bcd0d8e4d@github.com>
 <d0xuQnDOKYZBo7uu9P8XWouqJl0wujz0wiVX8qkMRlI=.3a9a8874-9929-4ec2-b0ad-7d303261fa0c@github.com>
Message-ID: <kWuVOQnKQq7aTgwiAb7YSb8LJjm_VRXZwMRQqtr8-8g=.55dd46b2-0367-49bf-aef8-041b48574579@github.com>

On Thu, 6 Apr 2023 03:43:26 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Thank you for doing this. I am guessing it was always intended to be public but was not spotted in previous reviews.
>
> @PaulSandoz Thanks for your timely review, do I need a second review for this patch?

Hello @merykitty,

I'm observing GHA test failure in `jdk/incubator/vector/ShortMaxVectorTests` on `linux-x86` (jdk master):


test ShortMaxVectorTests.sliceShortMaxVectorTestsMasked(short[-i * 5], short[i + 1], mask[true]): failure
java.lang.AssertionError: arrays differ firstly at element [16]; expected value is <12> but was <1>. (ref: [-135, -140, -145, -150, -155, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27], res: [-135, -140, -145, -150, -155, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]), at index #0, at origin #27
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.assertEquals(Assert.java:275)
	at ShortMaxVectorTests.assertArraysEquals(ShortMaxVectorTests.java:854)
	at ShortMaxVectorTests.sliceShortMaxVectorTestsMasked(ShortMaxVectorTests.java:4812)


Could this be caused by changes in this PR?

See https://github.com/eirbjo/jdk/actions/runs/4707493730#user-content-jdk_incubator_vector_shortmaxvectortests

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13277#issuecomment-1509840795

From duke at openjdk.org  Sat Apr 15 17:23:43 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 15 Apr 2023 17:23:43 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v13]
In-Reply-To: <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
Message-ID: <SjWFADdGRi3vkaTtNe8-fezznmFe2p4DsmMb1acXsCI=.9212dade-0358-4a00-bf42-9f94bdf54342@github.com>

On Wed, 12 Apr 2023 17:31:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed isPPC64().
>   Consolidated switch cases in ArchTest.
>   Moved mapping of build TARGET_OS and TARGET_CPU to the build
>   to avoid multiple mappings in more than one place.

The RISC-V 64 part look good, `ArchTest` has passed on Debian RISC-V 64.

test/jdk/jdk/internal/util/ArchTest.java line 70:

> 68:             case "x86", "i386" -> X86;
> 69:             case "aarch64" -> AARCH64;
> 70:             case "riscv64" -> RISCV64;  // unverified

Suggestion:

            case "riscv64" -> RISCV64;

-------------

Marked as reviewed by Glavo at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1386559067
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1167584685

From Alan.Bateman at oracle.com  Sat Apr 15 19:07:25 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 15 Apr 2023 20:07:25 +0100
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <CAJL5A3kNp5FoDf5Py7dQ=+oYtfw32FxFyzaWxsYyRJB9EgPr0Q@mail.gmail.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
 <CAJL5A3mKDLWw4AeToiaKrjs2+50qTPJEDmOc8XuFCWYACbd0BQ@mail.gmail.com>
 <549e246f-eb19-8a6a-5e83-5b3c615e51ca@oracle.com>
 <CAJL5A3kxWKdoWHGL1k70Ae6ED+HTvRCmXXGxOMXvwQ_VBQMF1A@mail.gmail.com>
 <a6d6724f-13f4-c134-edd4-e147a5610517@oracle.com>
 <CAJL5A3=7T=L7n1MSneHc7cwA2LmhrMmhG2HQ42rF=JZ13EDxkw@mail.gmail.com>
 <fa44cb82-67f3-73af-881d-6994ccfd2e62@oracle.com>
 <CAJL5A3kNp5FoDf5Py7dQ=+oYtfw32FxFyzaWxsYyRJB9EgPr0Q@mail.gmail.com>
Message-ID: <c566f8f6-6ff4-ae85-9159-bf883504ab9f@oracle.com>

On 15/04/2023 13:39, Glavo wrote:
> :
>
> I've detailed the reasons for introducing a new API earlier, and I 
> hope you'll take a look at it:
>
>     https://mail.openjdk.org/pipermail/core-libs-dev/2023-April/104118.html
>
>
There's a lot more thinking required before considering adding new APIs 
like this. It requires thinking about new developers writing toy 
programs that could easily be confused by two methods that appear to do 
the same thing. Also needs taking a broader view on how it works with 
other locale sensitive APIs.

In your list, auditing the usages in the JDK to identify usages where it 
should be using Locale.ROOT instead of Locale.getDefault would be helpful.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230415/2d5df34b/attachment-0001.htm>

From alanb at openjdk.org  Sat Apr 15 19:12:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Apr 2023 19:12:32 GMT
Subject: RFR: 8306036: Use @apiNote in String.toLowerCase,
 String.toUpperCase [v2]
In-Reply-To: <6KTQ3_DmIbudbhJD6Ei4yhTME93NJj04gllwxKJX_C0=.9a399d1c-334c-423f-af6d-b046643bcc68@github.com>
References: <-BY9vNZpmJGzCqABQXT708aGIM6Cb8UFnXPEVZQpoL4=.2dd38e9a-9669-41be-b97e-2e69a2b00a01@github.com>
 <6KTQ3_DmIbudbhJD6Ei4yhTME93NJj04gllwxKJX_C0=.9a399d1c-334c-423f-af6d-b046643bcc68@github.com>
Message-ID: <NeZY1X3xbTjEGxhHkEWYB83tO135JvBDIn0zl9AF9eQ=.4b69f34f-2bab-42bc-9539-7d5b67dd131b@github.com>

On Sat, 15 Apr 2023 11:17:34 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Please review this PR which suggests to use `@apiNote` in the `String.toLowerCase()` and `String.toUpperCase()` API docs.
>> 
>> These methods include important usage notes which today are encoded using `<b>Note:</b>`.
>
> Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into to-ul-case-apinote
>  - Use @apiNote in String.toLowerCase, String.toUpperCase

Replaces bolded-"Note" with "API Note" so looks reasonable. There may be a few like this around the JDK that pre-date the apiNote tag.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13487#pullrequestreview-1386605766

From duke at openjdk.org  Sat Apr 15 19:57:31 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 15 Apr 2023 19:57:31 GMT
Subject: RFR: 8306036: Use @apiNote in String.toLowerCase,
 String.toUpperCase [v2]
In-Reply-To: <NeZY1X3xbTjEGxhHkEWYB83tO135JvBDIn0zl9AF9eQ=.4b69f34f-2bab-42bc-9539-7d5b67dd131b@github.com>
References: <-BY9vNZpmJGzCqABQXT708aGIM6Cb8UFnXPEVZQpoL4=.2dd38e9a-9669-41be-b97e-2e69a2b00a01@github.com>
 <6KTQ3_DmIbudbhJD6Ei4yhTME93NJj04gllwxKJX_C0=.9a399d1c-334c-423f-af6d-b046643bcc68@github.com>
 <NeZY1X3xbTjEGxhHkEWYB83tO135JvBDIn0zl9AF9eQ=.4b69f34f-2bab-42bc-9539-7d5b67dd131b@github.com>
Message-ID: <YIYw7mud2uxYS3h0Igt61RNgzktVFJ65AR_WUMfQBms=.6b402c5b-6af8-46fc-b7d8-d698e05a59bc@github.com>

On Sat, 15 Apr 2023 19:09:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There may be a few like this around the JDK that pre-date the apiNote tag.

There are 44 matches in 12 files in `src/java.base/share/classes/java`, including classes such as `HttpURLConnection`, `Character`, `SimpleDateFormat`, `Locale` and `ResourceBundle`.

Would you prefer that I expand this PR to take care of at least a few of those? Happy to do so, but it will require more reviewer cycles. (Although changes should be fairly straightforward).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13487#issuecomment-1509944762

From alanb at openjdk.org  Sun Apr 16 08:23:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Apr 2023 08:23:38 GMT
Subject: RFR: 8240567: SystemModulesPlugin: Keep stack clean
In-Reply-To: <1J5JxWpISPgnLMhXCwFO5X4u9F0ayc_hOEzG2alJ_24=.a81457cb-d20f-476b-a7f4-047d1feec87f@github.com>
References: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>
 <3t_QZLhE7QrNeY5GqLY1JfvFDvE8hDUprHii759p1_4=.b83f7e9c-15dc-49ac-8589-3ab3ec8b0321@github.com>
 <1J5JxWpISPgnLMhXCwFO5X4u9F0ayc_hOEzG2alJ_24=.a81457cb-d20f-476b-a7f4-047d1feec87f@github.com>
Message-ID: <geC6QZc-DB0yiHd33hb7HCN7_o-fhcY46sovtMp00Ss=.e680d9fd-dc60-44aa-978d-51b3d69ae3ba@github.com>

On Wed, 12 Apr 2023 10:05:34 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> For me, it's the correct one. I was not sure which one to link. I can also drop the reference.

I checked the generated code and it looks like the code generated to invoke builder's newRequires, newExports, ... is missing a pop as the return values aren't used. It seems to be benign for now but could bite.  I've created [JDK-8306038](https://bugs.openjdk.org/browse/JDK-8306038) to track it .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13442#issuecomment-1510182294

From alanb at openjdk.org  Sun Apr 16 08:31:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Apr 2023 08:31:39 GMT
Subject: RFR: 8306036: Use @apiNote in String.toLowerCase,
 String.toUpperCase [v2]
In-Reply-To: <YIYw7mud2uxYS3h0Igt61RNgzktVFJ65AR_WUMfQBms=.6b402c5b-6af8-46fc-b7d8-d698e05a59bc@github.com>
References: <-BY9vNZpmJGzCqABQXT708aGIM6Cb8UFnXPEVZQpoL4=.2dd38e9a-9669-41be-b97e-2e69a2b00a01@github.com>
 <6KTQ3_DmIbudbhJD6Ei4yhTME93NJj04gllwxKJX_C0=.9a399d1c-334c-423f-af6d-b046643bcc68@github.com>
 <NeZY1X3xbTjEGxhHkEWYB83tO135JvBDIn0zl9AF9eQ=.4b69f34f-2bab-42bc-9539-7d5b67dd131b@github.com>
 <YIYw7mud2uxYS3h0Igt61RNgzktVFJ65AR_WUMfQBms=.6b402c5b-6af8-46fc-b7d8-d698e05a59bc@github.com>
Message-ID: <oYaEQn8gADZEu4ZDnpe8jXhJrnO_oH1RItTH9TY-eGc=.db189501-ab8c-497a-82ff-88707f70e3e9@github.com>

On Sat, 15 Apr 2023 19:54:41 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Would you prefer that I expand this PR to take care of at least a few of those? Happy to do so, but it will require more reviewer cycles. (Although changes should be fairly straightforward).

Gosh no, my comment was to say that there are likely many other cases where a bolded-"Note" is used to communicate an API note as that was the norm before the apiNote tag was added. Not important but they could be looked at in other PRs, the main thing is to ensure that notes for implementors aren't accidentally changed to API notes, or that text that follows a "Note" doesn't accidentally become part of an API note.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13487#issuecomment-1510186945

From alanb at openjdk.org  Sun Apr 16 08:42:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Apr 2023 08:42:40 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message [v5]
In-Reply-To: <RugWryBennaYioCZFHa9I0UJkvzojpPf2fhmNZk8EHU=.b402af07-8091-4c76-9943-9cd1d9c797ea@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
 <zmtUmRIk6ROWW5yKE021OHfxCVizgi2kx2I3Pz0Hzns=.388e4b99-ccdc-4ad5-b7c5-50a97e5a9b3f@github.com>
 <3OwgsaH4m-Py4V_0Naj7k6ZPYQP53ClfsL-2MdVW9v8=.fe1d81bd-89ee-49a8-9cd9-6df9d5971426@github.com>
 <RugWryBennaYioCZFHa9I0UJkvzojpPf2fhmNZk8EHU=.b402af07-8091-4c76-9943-9cd1d9c797ea@github.com>
Message-ID: <TcJKmqDfL3XIOQERW340E6vyo6rEqFr9_vQOgew_1j8=.5bcbcbf4-42aa-4187-934f-6000912ad9d1@github.com>

On Sat, 15 Apr 2023 10:24:58 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> test/jdk/jdk/nio/zipfs/ZipFSDirectoryExceptionMessageTest.java line 96:
>> 
>>> 94:             var file = zipfs.getPath(DIRECTORY_NAME);
>>> 95:             var x = assertThrows(FileSystemException.class, () -> Files.newInputStream(file));
>>> 96:             assertEquals(DIR_EXCEPTION_MESSAGE, x.getMessage());
>> 
>> FYI, test doesn't need to depend the exception message. Checking FileSystemException::getOtherFile returns null would be a more robust way of checking that it didn't provide a second file by mistake, e.g.
>> 
>>        try {
>>             Files.newInputStream(DIRECTORY_NAME);
>>             fail();
>>         } catch (FileSystemException e) {
>>             assertNull(e.getOtherFile());
>>         } catch (IOException ioe) { 
>>             // allowed
>>         }
>
> added validation for other file being null but also kept the existing validation of the message

Okay, although I assume this test will fail if it throws a more general IOException (it's allowed to do that) or there is any adjustment to the error message.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13482#discussion_r1167784301

From duke at openjdk.org  Sun Apr 16 08:51:33 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sun, 16 Apr 2023 08:51:33 GMT
Subject: RFR: 8306036: Use @apiNote in String.toLowerCase,
 String.toUpperCase [v2]
In-Reply-To: <6KTQ3_DmIbudbhJD6Ei4yhTME93NJj04gllwxKJX_C0=.9a399d1c-334c-423f-af6d-b046643bcc68@github.com>
References: <-BY9vNZpmJGzCqABQXT708aGIM6Cb8UFnXPEVZQpoL4=.2dd38e9a-9669-41be-b97e-2e69a2b00a01@github.com>
 <6KTQ3_DmIbudbhJD6Ei4yhTME93NJj04gllwxKJX_C0=.9a399d1c-334c-423f-af6d-b046643bcc68@github.com>
Message-ID: <7lQxrRcC_iOUDZz5dTbmEhALgNz-1zAQpeQFM3B58bo=.b4b76d9b-28f4-490e-9721-75c7b1414b48@github.com>

On Sat, 15 Apr 2023 11:17:34 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Please review this PR which suggests to use `@apiNote` in the `String.toLowerCase()` and `String.toUpperCase()` API docs.
>> 
>> These methods include important usage notes which today are encoded using `<b>Note:</b>`.
>
> Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into to-ul-case-apinote
>  - Use @apiNote in String.toLowerCase, String.toUpperCase

Thanks for your review Alan, I have integrated as-is. Perhaps you could sponsor?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13487#issuecomment-1510197569

From stsypanov at openjdk.org  Sun Apr 16 09:14:32 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 16 Apr 2023 09:14:32 GMT
Subject: RFR: 8305785: Avoid redundant HashMap.containsKey call in
 java.util.regex
In-Reply-To: <_WLYJq0pH0MAmUOuVtCJsRIYvmjtwi_cwW3_Wy341Ks=.17067b05-2a67-49f8-b167-6b2404165ae5@github.com>
References: <_WLYJq0pH0MAmUOuVtCJsRIYvmjtwi_cwW3_Wy341Ks=.17067b05-2a67-49f8-b167-6b2404165ae5@github.com>
Message-ID: <LRM3MzdEQ7MBAz0RMmrKVKqFWiTw4rFytXKFs_AdVzc=.b20de72d-2d84-445e-a29f-fa80a1576939@github.com>

On Mon, 3 Apr 2023 16:58:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Pattern.namedGroups` and `Matcher.namedGroups` contains only non-null values. It means instead of separate `containsKey`+`get` calls, we can use single `HashMap.get` call and then compare result with null.
> Result code is a bit simpler and faster.

Marked as reviewed by stsypanov (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13303#pullrequestreview-1386780737

From lancea at openjdk.org  Sun Apr 16 10:29:39 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 16 Apr 2023 10:29:39 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message [v5]
In-Reply-To: <TcJKmqDfL3XIOQERW340E6vyo6rEqFr9_vQOgew_1j8=.5bcbcbf4-42aa-4187-934f-6000912ad9d1@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
 <zmtUmRIk6ROWW5yKE021OHfxCVizgi2kx2I3Pz0Hzns=.388e4b99-ccdc-4ad5-b7c5-50a97e5a9b3f@github.com>
 <3OwgsaH4m-Py4V_0Naj7k6ZPYQP53ClfsL-2MdVW9v8=.fe1d81bd-89ee-49a8-9cd9-6df9d5971426@github.com>
 <RugWryBennaYioCZFHa9I0UJkvzojpPf2fhmNZk8EHU=.b402af07-8091-4c76-9943-9cd1d9c797ea@github.com>
 <TcJKmqDfL3XIOQERW340E6vyo6rEqFr9_vQOgew_1j8=.5bcbcbf4-42aa-4187-934f-6000912ad9d1@github.com>
Message-ID: <A57pQYRbof1wEy9LObJ-1BRM78v10Ry96WcuXJK_bYw=.09ec7986-b535-43cf-9b55-273b4d7ab101@github.com>

On Sun, 16 Apr 2023 08:39:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> added validation for other file being null but also kept the existing validation of the message
>
> Okay, although I assume this test will fail if it throws a more general IOException (it's allowed to do that) or there is any adjustment to the error message.

Yes, in the unlikely event that either  FileSystemException or  the code below from zipfs is changed, then yes the error message could evolve



            if (e.isDir())
                throw new FileSystemException(getString(path), null, "is a directory"); 


I do not have a strong preference once way or the other and am happy to remove the message validation if that is what you prefer.  I kept the validation as the original issue was surrounding the actual message being generated which aligns with the text included by zipfs when it threw the exception when obtaining the inputstream

I think it is worth mentioning that we have other tests that also validate exception messages(and we recently updated a couple zip tests because the message changed).    So if we are going to move in the direction of not validating exception messages in tests, we should probably consider adding verbiage to the developers guide to provide that guidance and be consistent within the test suite

Let me know your preference and thank you for your thoughts as it is a useful discussion

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13482#discussion_r1167813939

From stsypanov at openjdk.org  Sun Apr 16 11:20:46 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 16 Apr 2023 11:20:46 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v4]
In-Reply-To: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
Message-ID: <LqYM4DGlvbhjOITWOedQLcKL4B3y4sQ09tIHc_E2vRs=.0cf7cb11-9af0-486b-9a14-14d79b2706ea@github.com>

> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
> 
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>   .appendLiteral("Date:")
>   .padNext(20, ' ')
>   .append(DateTimeFormatter.ISO_DATE)
>   .toFormatter();
> String text = dtf.format(LocalDateTime.now());

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8300818: Extract separate benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12131/files
  - new: https://git.openjdk.org/jdk/pull/12131/files/b40de5a8..198cb6ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12131&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12131&range=02-03

  Stats: 96 lines in 2 files changed: 66 ins; 27 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12131/head:pull/12131

PR: https://git.openjdk.org/jdk/pull/12131

From stsypanov at openjdk.org  Sun Apr 16 11:20:52 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 16 Apr 2023 11:20:52 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v3]
In-Reply-To: <P6G78Sj0a0YnAFiHgvqtfRZGN773tdq1DEdwVwLeubA=.fe8bdf0c-b00d-4b65-969d-ad70385a58a3@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <5e1c0aIHmpueO2gPCS4suJh3Jo0RVhWpSkUnMmnM2uw=.7592dbee-3c4e-4ba7-8c7c-9184fa3ddcbe@github.com>
 <P6G78Sj0a0YnAFiHgvqtfRZGN773tdq1DEdwVwLeubA=.fe8bdf0c-b00d-4b65-969d-ad70385a58a3@github.com>
Message-ID: <V0lc7_4isxYZzPVHzE5QBZIh5wHNRow8TFqIn8MBmLA=.13ef1bd8-2648-4785-9fde-7d6b9ea03004@github.com>

On Wed, 12 Apr 2023 17:39:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into dtfb
>>  - 8300818: Add benchmark
>>  - 8300818: Add benchmark
>>  - Revert irrelevant change
>>  - Merge branch 'master' into dtfb
>>  - Improve padding of DateTimeFormatter
>
> test/micro/org/openjdk/bench/java/time/format/DateTimeFormatterBench.java line 148:
> 
>> 146:         return YEAR_FORMATTER.format(now);
>> 147:     }
>> 148: 
> 
> There benchmarks are run 4 time each because of the @Param that are defined for the pre-existing tests.
> I don't know if jmh can be annotated to ignore the params; but to avoid wasting resources create a separate jmh source file for thees new tests.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1167835249

From stsypanov at openjdk.org  Sun Apr 16 11:47:34 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 16 Apr 2023 11:47:34 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v2]
In-Reply-To: <MGPD9mADC-45XPxBYAMM6nRIPJ3oKAwwPcOofSkzmiw=.b54f5929-1992-4089-9a6b-743bd2643a2d@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
 <KR4jLIdgm_Y49RQkIJ9uNHqemm01aE81GRBVz6XznJ8=.c2e99c6d-2fb2-44ce-b23d-6461fac68ff4@github.com>
 <3Im4RP5-AmauuIjCVgA3V4h0HellqriqIlbTSjXjrWU=.a3b7c98f-276a-423a-8d48-c3415633b2cc@github.com>
 <_gJmYty5eyRbpGo3AIlFE4HDkmGWAWPsAOqwJri3mqo=.70b5927c-2be5-484c-98f4-f21933166c55@github.com>
 <8-pc62MG2Qcj0reM0zl85Kunw2rZlQOMVZHyjKKSSSY=.4af17266-9d26-42e3-a357-fcda22f1fd5b@github.com>
 <MGPD9mADC-45XPxBYAMM6nRIPJ3oKAwwPcOofSkzmiw=.b54f5929-1992-4089-9a6b-743bd2643a2d@github.com>
Message-ID: <0tZH5cpkJrPjxa3UNQ3MC0LvRkFGIs2W5v21v4GS1pA=.1dd39ae4-d6cd-4356-a9cc-5b83832d4319@github.com>

On Wed, 12 Apr 2023 17:41:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Added benchmark for this
>
> Special casing for len == 0 and keeping the existing buf.insert for len == 1 would avoid object creation except when it would improve performance.

@RogerRiggs sorry I don't get it. Maybe you mean speacial casing for `padWidth - len`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1167869599

From zjx001202 at gmail.com  Sun Apr 16 15:47:25 2023
From: zjx001202 at gmail.com (Glavo)
Date: Sun, 16 Apr 2023 23:47:25 +0800
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <c566f8f6-6ff4-ae85-9159-bf883504ab9f@oracle.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
 <CAJL5A3mKDLWw4AeToiaKrjs2+50qTPJEDmOc8XuFCWYACbd0BQ@mail.gmail.com>
 <549e246f-eb19-8a6a-5e83-5b3c615e51ca@oracle.com>
 <CAJL5A3kxWKdoWHGL1k70Ae6ED+HTvRCmXXGxOMXvwQ_VBQMF1A@mail.gmail.com>
 <a6d6724f-13f4-c134-edd4-e147a5610517@oracle.com>
 <CAJL5A3=7T=L7n1MSneHc7cwA2LmhrMmhG2HQ42rF=JZ13EDxkw@mail.gmail.com>
 <fa44cb82-67f3-73af-881d-6994ccfd2e62@oracle.com>
 <CAJL5A3kNp5FoDf5Py7dQ=+oYtfw32FxFyzaWxsYyRJB9EgPr0Q@mail.gmail.com>
 <c566f8f6-6ff4-ae85-9159-bf883504ab9f@oracle.com>
Message-ID: <CAJL5A3noonJCRTxb8Xvh22EMV=N=M=LRQtne9wERfOLTa01pEw@mail.gmail.com>

>
> There's a lot more thinking required before considering adding new APIs
> like this. It requires thinking about new developers writing toy programs
> that could easily be confused by two methods that appear to do the same
> thing. Also needs taking a broader view on how it works with other locale
> sensitive APIs.
>

One of the important reasons why I am so eager to have new APIs is to solve
the problems caused by toLowerCase()/toUpperCase() for new developers.

At present, if we want to teach new developers how to convert between
uppercase and lowercase, we have two options:

* Tell them to use toLowerCase()/toUpperCase()

This is a concise choice, but the learners often do not realize the true
meaning of these methods.

As mentioned earlier, these two methods are often misused in most cases.
If we teach like this, learners may write more problematic code in the
future.

* Tell them to use toLowerCase(Locale.ROOT)/toUpperCase(Locale.ROOT)

This is the right choice, but unfortunately, it is very complex.

Its meaning is not as concise and intuitive, and we have to encourage users
to learn about Locale earlier.


The correct writing is lengthy and not intuitive, while problematic writing
is actually shorter.
Short but problematic writing and lengthy but correct writing may cause
confusion for users.

 It requires thinking about new developers writing toy programs that could
> easily be confused by two methods that appear to do the same thing.
>

Due to the above reasons, I think what you said is completely reversed.

What will cause confusion to users is the current situation, and the new
APIs will solve these issues.
The new API will provide a short and correct writing that is intuitive and
can maintain consistency with the semantics of
compareIgnoreCase/equalsIgnoreCase.
For toLowerCase()/toUpperCase(), we just need to tell the user that they
are just legacy issues and never use them.


I understand that Java 21 is around the corner and you have a lot of work
to do, so I'm sorry for taking up so much of your time.
But for this issue, I think it really needs to be corrected. If new APIs
cannot be added in Java 21, it means that correcting these legacy issues in
the community will take at least two more years.
I earnestly request that you pay more attention to this issue, and I am
extremely grateful.

Glavo

On Sun, Apr 16, 2023 at 3:07?AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 15/04/2023 13:39, Glavo wrote:
>
> :
>
> I've detailed the reasons for introducing a new API earlier, and I hope
> you'll take a look at it:
>
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-April/104118.html
>
>
> There's a lot more thinking required before considering adding new APIs
> like this. It requires thinking about new developers writing toy programs
> that could easily be confused by two methods that appear to do the same
> thing. Also needs taking a broader view on how it works with other locale
> sensitive APIs.
>
> In your list, auditing the usages in the JDK to identify usages where it
> should be using Locale.ROOT instead of Locale.getDefault would be helpful.
>
> -Alan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230416/b611a671/attachment-0001.htm>

From duke at openjdk.org  Sun Apr 16 17:47:38 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Sun, 16 Apr 2023 17:47:38 GMT
Subject: RFR: 8306038: SystemModulesPlugin: Keep stack clean
In-Reply-To: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>
References: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>
Message-ID: <HoWJ98ECyCVPndGuQTUbMEGCEoUAxR6EU7qid3N4QNI=.8437023b-0de9-4a84-a746-db44b3e5a514@github.com>

On Wed, 12 Apr 2023 09:18:13 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> This refs [https://bugs.openjdk.org/browse/JDK-8306038](8306038). 
> 
> (Before this referenced 8240567)
> 
> Although this change is rather small, I think, it's good to have a "more clean" SystemModulesPlugin available.

Thank you for creating the issue. - I added the pop at the "missing" places as there already wore pops at other places in that class.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13442#issuecomment-1510440935

From some-java-user-99206970363698485155 at vodafonemail.de  Sun Apr 16 22:16:06 2023
From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de)
Date: Mon, 17 Apr 2023 00:16:06 +0200
Subject: Add String & Character ASCII case conversion methods
In-Reply-To: <e938dfc2b03444a4a64d1107620816f9@vodafonemail.de>
Message-ID: <8e22222082754851a2c28c0af84dd70d@vodafonemail.de>

Thanks for your effort on deprecating the error-prone toLowerCase() and toUpperCase() methods!

Though that only addresses one aspect of my original proposal. Do you or anyone else have any opinion or feedback regarding the proposed ASCII case conversion methods? Even if you think these methods are not needed, such feedback would already be useful (assuming you explain why you think that is the case, and why the issues I presented are not a problem).

Maybe I will also submit this as "Request for Enhancement" to the bug tracker.

Kind regards

> Hi,
> We discussed this issue on this mailing list[1] earlier this year.
> 
> I investigated the usage of these two methods and found that all use cases within
> JDK are suspicious, resulting in many imperceptible bugs.
> 
> I hope to create a PR for this issue, deprecate these two methods, and create
> alternative methods for them. But I don't have the experience of making such
> changes, maybe I need some guidance or have more experienced people do these things.
> 
> Glavo
> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html



From jpai at openjdk.org  Mon Apr 17 01:56:42 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Apr 2023 01:56:42 GMT
Subject: RFR: 8306036: Use @apiNote in String.toLowerCase,
 String.toUpperCase [v2]
In-Reply-To: <6KTQ3_DmIbudbhJD6Ei4yhTME93NJj04gllwxKJX_C0=.9a399d1c-334c-423f-af6d-b046643bcc68@github.com>
References: <-BY9vNZpmJGzCqABQXT708aGIM6Cb8UFnXPEVZQpoL4=.2dd38e9a-9669-41be-b97e-2e69a2b00a01@github.com>
 <6KTQ3_DmIbudbhJD6Ei4yhTME93NJj04gllwxKJX_C0=.9a399d1c-334c-423f-af6d-b046643bcc68@github.com>
Message-ID: <0mANukn-Zo5qQhw1ft5DUb_nMksKZBaakuCwfv756Og=.3e7e9cc1-8433-4455-a84b-972220a470de@github.com>

On Sat, 15 Apr 2023 11:17:34 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Please review this PR which suggests to use `@apiNote` in the `String.toLowerCase()` and `String.toUpperCase()` API docs.
>> 
>> These methods include important usage notes which today are encoded using `<b>Note:</b>`.
>
> Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into to-ul-case-apinote
>  - Use @apiNote in String.toLowerCase, String.toUpperCase

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13487#pullrequestreview-1387144844

From duke at openjdk.org  Mon Apr 17 05:27:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 17 Apr 2023 05:27:49 GMT
Subject: Integrated: 8306036: Use @apiNote in String.toLowerCase,
 String.toUpperCase
In-Reply-To: <-BY9vNZpmJGzCqABQXT708aGIM6Cb8UFnXPEVZQpoL4=.2dd38e9a-9669-41be-b97e-2e69a2b00a01@github.com>
References: <-BY9vNZpmJGzCqABQXT708aGIM6Cb8UFnXPEVZQpoL4=.2dd38e9a-9669-41be-b97e-2e69a2b00a01@github.com>
Message-ID: <OXcxBgmhkH7VwqxuKRvn1q0Evr8HjHR9X0X7hYizLH8=.05ea73d0-5c73-4993-b0a0-73441f6e091b@github.com>

On Sat, 15 Apr 2023 07:56:17 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this PR which suggests to use `@apiNote` in the `String.toLowerCase()` and `String.toUpperCase()` API docs.
> 
> These methods include important usage notes which today are encoded using `<b>Note:</b>`.

This pull request has now been integrated.

Changeset: 7f56de8f
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f56de8f78c0b54e5cf313f53213102a3495234f
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8306036: Use @apiNote in String.toLowerCase, String.toUpperCase

Reviewed-by: alanb, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/13487

From alanb at openjdk.org  Mon Apr 17 08:24:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Apr 2023 08:24:32 GMT
Subject: RFR: 8306038: SystemModulesPlugin: Keep stack clean
In-Reply-To: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>
References: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>
Message-ID: <laQKKG_wgwd83URh76XNBXn-fk-ZP54u8_iftrPPnHg=.f8d934e3-781c-4f46-843a-87103091f6b1@github.com>

On Wed, 12 Apr 2023 09:18:13 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> This refs [https://bugs.openjdk.org/browse/JDK-8306038](8306038). 
> 
> (Before this referenced 8240567)
> 
> Although this change is rather small, I think, it's good to have a "more clean" SystemModulesPlugin available.

This looks okay.

This looks right. I assume you've checked  `java -XX:+UnlockDiagnosticVMOptions  -XX:+BytecodeVerificationLocal -version` as this code is not normally verified. Also I assume you've run tier2 with the jlink tests.

You will need to edit the PR so it matches the JBS title.

@mlchung @asotona, do you want to look at this too? I think it pre-dates the conversion to the class file API.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13442#pullrequestreview-1387522396
PR Comment: https://git.openjdk.org/jdk/pull/13442#issuecomment-1510912251

From asotona at openjdk.org  Mon Apr 17 10:47:34 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Apr 2023 10:47:34 GMT
Subject: RFR: 8304932: MethodTypeDescImpl can be mutated by argument passed
 to MethodTypeDesc.of [v2]
In-Reply-To: <xrT2u2IywBEi6VgzUMg55wQg5ft3lhhsCn-EBipdzAI=.43c4bb6b-2836-4eff-a47a-9656b56cfedf@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
 <xrT2u2IywBEi6VgzUMg55wQg5ft3lhhsCn-EBipdzAI=.43c4bb6b-2836-4eff-a47a-9656b56cfedf@github.com>
Message-ID: <HWimoDMQGxeI7WFA0uv456c5LN4NcjQOCHvfAGrZy50=.a14b2186-d005-4870-a929-705ba3d4fd6b@github.com>

On Sun, 26 Mar 2023 20:45:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Fixed the bug where if a caller keeps a reference to the array passed into `MethodTypeDesc.of`, the caller may mutate the Desc via the array and can create invalid MethodTypeDesc.
>> 
>> Unfortunately, since the input array now needs to be copied, the `of` factory suffers from a performance drop. But otherwise, this patch has minor performance gains on `ofDescriptor` factory, even compared to Adam's patch that optimized `ofDescriptor` in #12945.
>> 
>> This patch moves the parameters to an immutable list, to avoid allocations on `parameterList` as well.
>> 
>> Benchmark of Oracle JDK 20: https://gist.github.com/683c6219e183cbc2b336224fc2c0d50a
>> Benchmark of this patch: https://gist.github.com/22be9371a2370fb4a7b44f1684750ec4
>> Benchmark of [asotona's patch](https://github.com/openjdk/jdk/pull/12945/files#diff-ac8e413d3e13532a2b0d34a90253c6ddd7a4f04082f792b9d076e9b5a33f2078): https://gist.github.com/eb98579c3b51cafae481049a95a78f80
>> 
>> [sotona vs this](https://jmh.morethan.io/?gists=eb98579c3b51cafae481049a95a78f80,22be9371a2370fb4a7b44f1684750ec4); [20 vs this](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,22be9371a2370fb4a7b44f1684750ec4); [20 vs sotona](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,eb98579c3b51cafae481049a95a78f80), for reference
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix some inconsistencies in the method descriptor derivation methods

> Additional comments:
> 
> 1. Maybe it's feasible to add another factory:
> 
> ```java
> static MethodTypeDesc of(ClassDesc returnType, List<ClassDesc> parameterTypes) {
>     return new MethodTypeDescImpl(returnType, List.copyOf(parameterTypes));
> }
> ```
> 
> which would avoid another copy if `parameterTypes` is already a list from `List.of` factories.
> 
> 2. Avoiding copies in `parameterList` can speed up its users, such as stack map generation in the Classfile API.

Yes, any improvements avoiding unnecessary arrays copying are welcome. `ClassDesc` and `MethodTypeDesc` are key pieces of the Classfile API with significant performance impact.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13186#issuecomment-1511111107

From duke at openjdk.org  Mon Apr 17 11:10:44 2023
From: duke at openjdk.org (olivergillespie)
Date: Mon, 17 Apr 2023 11:10:44 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode
Message-ID: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>

Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.

Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075).

### Benchmark



Before:

Benchmark              Mode  Cnt  Score   Error  Units
# Intel Cascade lake
EnumHashCode.constant  avgt   15  1.602 ? 0.011  ns/op
EnumHashCode.field     avgt   15  1.681 ? 0.014  ns/op
# Arm Neoverse N1
EnumHashCode.constant  avgt   15  1.642 ? 0.033  ns/op
EnumHashCode.field     avgt   15  1.717 ? 0.059  ns/op



After:

Benchmark              Mode  Cnt  Score   Error  Units
# Intel Cascade lake
EnumHashCode.constant  avgt   15  0.479 ? 0.001  ns/op
EnumHashCode.field     avgt   15  0.799 ? 0.002  ns/op
# Arm Neoverse N1
EnumHashCode.constant  avgt   15  0.802 ? 0.002  ns/op
EnumHashCode.field     avgt   15  1.059 ? 0.056  ns/op


Using `-prof perfasm` on the benchmark, we can compare the generated code for x86_64:

Before:

? 0x00007fae4868dd17:   lea    (%r12,%r10,8),%rsi           ;*getfield e {reexecute=0 rethrow=0 return_oop=0}
?                                                           ; - org.sample.EnumHashCode::field at 1 (line 24)
?                                                           ; - org.sample.jmh_generated.EnumHashCode_field_jmhTest::field_avgt_jmhStub at 17 (line 186)
? 0x00007fae4868dd1b:   mov    (%rsi),%r10
? 0x00007fae4868dd1e:   mov    %r10,%r11
? 0x00007fae4868dd21:   and    $0x3,%r11
? 0x00007fae4868dd25:   cmp    $0x1,%r11
? 0x00007fae4868dd29:   jne    0x00007fae4868dcc6
? 0x00007fae4868dd2b:   shr    $0x8,%r10
? 0x00007fae4868dd2f:   mov    %r10d,%eax
? 0x00007fae4868dd32:   and    $0x7fffffff,%eax
? 0x00007fae4868dd37:   test   %eax,%eax
? 0x00007fae4868dd39:   je     0x00007fae4868dcc6           ;*invokespecial hashCode {reexecute=0 rethrow=0 return_oop=0}
?                                                           ; - java.lang.Enum::hashCode at 1 (line 175)


This is the normal Object.hashCode intrinsic, which involves reading the object header, extracting the hash code and handling two slow-path cases (displaced object header, hash not initialized).

After:


  ?  0x00007f550068e3b4:   mov    0x10(%r12,%r10,8),%r8d  <-- read the hash field
  ?  0x00007f550068e3b9:   test   %r8d,%r8d               <-- if (hash == 0)
  ?  0x00007f550068e3bc:   je     0x00007f550068e413      <-- slow init path, only taken on first use


Thanks @shipilev for help with the implementation and interpreting the generated code.

-------------

Commit messages:
 - 8306075: Micro-optimize Enum.hashCode

Changes: https://git.openjdk.org/jdk/pull/13491/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13491&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306075
  Stats: 74 lines in 2 files changed: 73 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13491/head:pull/13491

PR: https://git.openjdk.org/jdk/pull/13491

From mcimadamore at openjdk.org  Mon Apr 17 12:04:48 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 17 Apr 2023 12:04:48 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <AKnM4ZWxdoTMFa242vrWpPQMFEXm2_YF2fG2HbrRLak=.f2016eab-f6c0-4381-83b7-aab64226a2cd@github.com>

On Fri, 17 Mar 2023 12:15:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 879:

> 877:                 }
> 878:                 case TYPEVAR -> components(((TypeVar) seltype).getUpperBound());
> 879:                 default -> {

The block here is redundant

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 890:

> 888:          * for the sealed supertype.
> 889:          */
> 890:         private List<PatternDescription> reduceBindingPatterns(Type selectorType, List<PatternDescription> patterns) {

This method doesn't seem to work for the following case:


class Test {
    sealed interface I permits A, B, C { }
    sealed interface I3 permits I2 { }
    sealed interface I2 extends I3 permits B, C { }
    final class A implements I {}
    final class B implements I, I2 {}
    final class C implements I, I2 {}

    int m(I i) {
        return switch (i) {
            case A a -> 1;
            case I3 e -> 2;
        };
    }
}


There seems to be some ordering issue in the way we visit the patterns.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 901:

> 899:                             Type clazzErasure = types.erasure(clazz.type);
> 900:                             if (components(selectorType).stream()
> 901:                                                         .map(c -> types.erasure(c))

Suggestion:

                                                        .map(Types::erasure)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 914:

> 912:                             permitted.remove(bpOne.type.tsym);
> 913:                             bindings.append(it1.head);
> 914:                             for (var it2 = it1.tail; it2.nonEmpty(); it2 = it2.tail) {

This could be a for-each loop?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 971:

> 969:             /* implementation note:
> 970:              * finding a sub-set of patterns that only differ in a single
> 971:              * column is time consuming task, so this method speeds it up by:

Suggestion:

             * column is time-consuming task, so this method speeds it up by:

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 974:

> 972:              * - group the patterns by their record class
> 973:              * - for each column (nested pattern) do:
> 974:              * -- group patterns by their hashs

Suggestion:

             * -- group patterns by their hash

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 976:

> 974:              * -- group patterns by their hashs
> 975:              * -- in each such by-hash group, find sub-sets that only differ in
> 976:              *    the chosen column, and tcall reduceBindingPatterns and reduceNestedPatterns

Suggestion:

             *    the chosen column, and call reduceBindingPatterns and reduceNestedPatterns

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 977:

> 975:              * -- in each such by-hash group, find sub-sets that only differ in
> 976:              *    the chosen column, and tcall reduceBindingPatterns and reduceNestedPatterns
> 977:              *    on patterns in the chosed column, as described above

Suggestion:

             *    on patterns in the chosen column, as described above

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 999:

> 997:                              .collect(groupingBy(pd -> pd.hashCode(mismatchingCandidateFin)));
> 998:                     for (var candidates : groupByHashes.values()) {
> 999:                         var candidatesArr = candidates.toArray(s -> new RecordPattern[s]);

Could this be an array constructor reference? E.g. `RecordPattern[]::new` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1077:

> 1075:          */
> 1076:         private List<PatternDescription> reduceRecordPatterns(List<PatternDescription> patterns) {
> 1077:             var newList = new ListBuffer<PatternDescription>();

Maybe `newPatterns` would be a better name?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1079:

> 1077:             var newList = new ListBuffer<PatternDescription>();
> 1078:             boolean modified = false;
> 1079:             for (var it = patterns; it.nonEmpty(); it = it.tail) {

for-each loop here?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1081:

> 1079:             for (var it = patterns; it.nonEmpty(); it = it.tail) {
> 1080:                 if (it.head instanceof RecordPattern rpOne) {
> 1081:                     PatternDescription nue = reduceRecordPattern(rpOne);

I find the name `nue` (here and elsewhere) particularly obscure.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1084:

> 1082:                     if (nue != rpOne) {
> 1083:                         newList.append(nue);
> 1084:                         modified |= true;

Suggestion:

                        modified = true;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1168552492
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1168546493
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1168560655
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1168560880
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1168551434
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1168551577
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1168551859
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1168552121
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1168553071
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1168556508
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1168557288
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1168554679
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1168554833

From prappo at openjdk.org  Mon Apr 17 12:26:38 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 17 Apr 2023 12:26:38 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode
In-Reply-To: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
Message-ID: <jQWXWn_rma-JtYK5AlSO1W2CH8q9VAKK4DS0_Gqk26c=.428eadeb-f203-4e25-915a-a346befa3163@github.com>

On Mon, 17 Apr 2023 10:59:34 GMT, olivergillespie <duke at openjdk.org> wrote:

> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
> 
> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075).
> 
> ### Benchmark
> 
> 
> 
> Before:
> 
> Benchmark              Mode  Cnt  Score   Error  Units
> # Intel Cascade lake
> EnumHashCode.constant  avgt   15  1.602 ? 0.011  ns/op
> EnumHashCode.field     avgt   15  1.681 ? 0.014  ns/op
> # Arm Neoverse N1
> EnumHashCode.constant  avgt   15  1.642 ? 0.033  ns/op
> EnumHashCode.field     avgt   15  1.717 ? 0.059  ns/op
> 
> 
> 
> After:
> 
> Benchmark              Mode  Cnt  Score   Error  Units
> # Intel Cascade lake
> EnumHashCode.constant  avgt   15  0.479 ? 0.001  ns/op
> EnumHashCode.field     avgt   15  0.799 ? 0.002  ns/op
> # Arm Neoverse N1
> EnumHashCode.constant  avgt   15  0.802 ? 0.002  ns/op
> EnumHashCode.field     avgt   15  1.059 ? 0.056  ns/op
> 
> 
> Using `-prof perfasm` on the benchmark, we can compare the generated code for x86_64:
> 
> Before:
> 
> ? 0x00007fae4868dd17:   lea    (%r12,%r10,8),%rsi           ;*getfield e {reexecute=0 rethrow=0 return_oop=0}
> ?                                                           ; - org.sample.EnumHashCode::field at 1 (line 24)
> ?                                                           ; - org.sample.jmh_generated.EnumHashCode_field_jmhTest::field_avgt_jmhStub at 17 (line 186)
> ? 0x00007fae4868dd1b:   mov    (%rsi),%r10
> ? 0x00007fae4868dd1e:   mov    %r10,%r11
> ? 0x00007fae4868dd21:   and    $0x3,%r11
> ? 0x00007fae4868dd25:   cmp    $0x1,%r11
> ? 0x00007fae4868dd29:   jne    0x00007fae4868dcc6
> ? 0x00007fae4868dd2b:   shr    $0x8,%r10
> ? 0x00007fae4868dd2f:   mov    %r10d,%eax
> ? 0x00007fae4868dd32:   and    $0x7fffffff,%eax
> ? 0x00007fae4868dd37:   test   %eax,%eax
> ? 0x00007fae4868dd39:   je     0x00007fae4868dcc6           ;*invokespecial hashCode {reexecute=0 rethrow=0 return_oop=0}
> ?                                                           ; - java.lang.Enum::hashCode at 1 (line 175)
> 
> 
> This is the normal Object.hashCode intrinsic, which involves reading the object header, extracting the hash code and handling two slow-path cases (displaced object header, hash not initialized).
> 
> After:
> 
> 
>   ?  0x00007f550068e3b4:   mov    0x10(%r12,%r10,8),%r8d  <-- read the hash field
>   ?  0x00007f550068e3b9:   test   %r8d,%r8d               <-- if (hash == 0)
>   ?  0x00007f550068e3bc:   je     0x00007f550068e413      <-- slow init path, only taken on first use
> 
> 
> Thanks @shipilev for help with the implementation and interpreting the generated code.

src/java.base/share/classes/java/lang/Enum.java line 175:

> 173:      *
> 174:      * @implNote Once initialized, the field value does not change.
> 175:      * Hotspot's identity hash code generation also never returns zero

> Hotspot's identity hash code generation also never returns zero

Isn't that behavior VM-specific? Also, where is it documented?

src/java.base/share/classes/java/lang/Enum.java line 191:

> 189:         int hc = hash;
> 190:         if (hc == 0) {
> 191:             hc = hash = System.identityHashCode(this);

Why not `hc = hash = super.hashCode()`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168593999
PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168601440

From shade at openjdk.org  Mon Apr 17 13:03:35 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Apr 2023 13:03:35 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode
In-Reply-To: <jQWXWn_rma-JtYK5AlSO1W2CH8q9VAKK4DS0_Gqk26c=.428eadeb-f203-4e25-915a-a346befa3163@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <jQWXWn_rma-JtYK5AlSO1W2CH8q9VAKK4DS0_Gqk26c=.428eadeb-f203-4e25-915a-a346befa3163@github.com>
Message-ID: <_ddg8NNgXP2qnKZLqcf15YmiQCTgdcr1yY2P1OFJ6Ks=.d0ab6b0f-a6a5-441e-ba31-c05c8af3932f@github.com>

On Mon, 17 Apr 2023 12:14:55 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075).
>> 
>> ### Benchmark
>> 
>> 
>> 
>> Before:
>> 
>> Benchmark              Mode  Cnt  Score   Error  Units
>> # Intel Cascade lake
>> EnumHashCode.constant  avgt   15  1.602 ? 0.011  ns/op
>> EnumHashCode.field     avgt   15  1.681 ? 0.014  ns/op
>> # Arm Neoverse N1
>> EnumHashCode.constant  avgt   15  1.642 ? 0.033  ns/op
>> EnumHashCode.field     avgt   15  1.717 ? 0.059  ns/op
>> 
>> 
>> 
>> After:
>> 
>> Benchmark              Mode  Cnt  Score   Error  Units
>> # Intel Cascade lake
>> EnumHashCode.constant  avgt   15  0.479 ? 0.001  ns/op
>> EnumHashCode.field     avgt   15  0.799 ? 0.002  ns/op
>> # Arm Neoverse N1
>> EnumHashCode.constant  avgt   15  0.802 ? 0.002  ns/op
>> EnumHashCode.field     avgt   15  1.059 ? 0.056  ns/op
>> 
>> 
>> Using `-prof perfasm` on the benchmark, we can compare the generated code for x86_64:
>> 
>> Before:
>> 
>> ? 0x00007fae4868dd17:   lea    (%r12,%r10,8),%rsi           ;*getfield e {reexecute=0 rethrow=0 return_oop=0}
>> ?                                                           ; - org.sample.EnumHashCode::field at 1 (line 24)
>> ?                                                           ; - org.sample.jmh_generated.EnumHashCode_field_jmhTest::field_avgt_jmhStub at 17 (line 186)
>> ? 0x00007fae4868dd1b:   mov    (%rsi),%r10
>> ? 0x00007fae4868dd1e:   mov    %r10,%r11
>> ? 0x00007fae4868dd21:   and    $0x3,%r11
>> ? 0x00007fae4868dd25:   cmp    $0x1,%r11
>> ? 0x00007fae4868dd29:   jne    0x00007fae4868dcc6
>> ? 0x00007fae4868dd2b:   shr    $0x8,%r10
>> ? 0x00007fae4868dd2f:   mov    %r10d,%eax
>> ? 0x00007fae4868dd32:   and    $0x7fffffff,%eax
>> ? 0x00007fae4868dd37:   test   %eax,%eax
>> ? 0x00007fae4868dd39:   je     0x00007fae4868dcc6           ;*invokespecial hashCode {reexecute=0 rethrow=0 return_oop=0}
>> ?                                                           ; - java.lang.Enum::hashCode at 1 (line 175)
>> 
>> 
>> This is the normal Object.hashCode intrinsic, which involves reading the object header, extracting the hash code and handling two slow-path cases (displaced object header, hash not initialized).
>> 
>> After:
>> 
>> 
>>   ?  0x00007f550068e3b4:   mov    0x10(%r12,%r10,8),%r8d  <-- read the hash field
>>   ?  0x00007f550068e3b9:   test   %r8d,%r8d               <-- if (hash == 0)
>>   ?  0x00007f550068e3bc:   je     0x00007f550068e413      <-- slow init path, only taken on first use
>> 
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> src/java.base/share/classes/java/lang/Enum.java line 175:
> 
>> 173:      *
>> 174:      * @implNote Once initialized, the field value does not change.
>> 175:      * Hotspot's identity hash code generation also never returns zero
> 
>> Hotspot's identity hash code generation also never returns zero
> 
> Isn't that behavior VM-specific? Also, where is it documented?

Yes, it is implementation-specific, that is why it says "Hotspot's identity hash code". The relevant code blocks are https://github.com/openjdk/jdk/blob/cc60f2ff3f16bdb04917e09cb87f09bd544f1f8b/src/hotspot/share/oops/markWord.hpp#L231-L233 (property) and https://github.com/openjdk/jdk/blob/cc60f2ff3f16bdb04917e09cb87f09bd544f1f8b/src/hotspot/share/runtime/synchronizer.cpp#L826-L827 (invariant).

> src/java.base/share/classes/java/lang/Enum.java line 191:
> 
>> 189:         int hc = hash;
>> 190:         if (hc == 0) {
>> 191:             hc = hash = System.identityHashCode(this);
> 
> Why not `hc = hash = super.hashCode()`?

Saves the virtual call, makes for a simpler intrinsic path (no need to handle NPE and fold away, for example), since we know the super-class is already `java.lang.Object`. Unless I miss something else here...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168654218
PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168656186

From shade at openjdk.org  Mon Apr 17 13:11:34 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Apr 2023 13:11:34 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode
In-Reply-To: <_ddg8NNgXP2qnKZLqcf15YmiQCTgdcr1yY2P1OFJ6Ks=.d0ab6b0f-a6a5-441e-ba31-c05c8af3932f@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <jQWXWn_rma-JtYK5AlSO1W2CH8q9VAKK4DS0_Gqk26c=.428eadeb-f203-4e25-915a-a346befa3163@github.com>
 <_ddg8NNgXP2qnKZLqcf15YmiQCTgdcr1yY2P1OFJ6Ks=.d0ab6b0f-a6a5-441e-ba31-c05c8af3932f@github.com>
Message-ID: <bN9YMQjWh24MhE17zbN1b1iSKW9VIiJ1u4xn7kV22mg=.0fa0d03a-6e5b-4a91-a0d6-f4f42de894f6@github.com>

On Mon, 17 Apr 2023 12:58:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Enum.java line 175:
>> 
>>> 173:      *
>>> 174:      * @implNote Once initialized, the field value does not change.
>>> 175:      * Hotspot's identity hash code generation also never returns zero
>> 
>>> Hotspot's identity hash code generation also never returns zero
>> 
>> Isn't that behavior VM-specific? Also, where is it documented?
>
> Yes, it is implementation-specific, that is why it says "Hotspot's identity hash code". The relevant code blocks are https://github.com/openjdk/jdk/blob/cc60f2ff3f16bdb04917e09cb87f09bd544f1f8b/src/hotspot/share/oops/markWord.hpp#L231-L233 (property) and https://github.com/openjdk/jdk/blob/cc60f2ff3f16bdb04917e09cb87f09bd544f1f8b/src/hotspot/share/runtime/synchronizer.cpp#L826-L827 (invariant).

It would not break the code functionally if that invariant ever breaks: we would "just" call the (intrinsic) method on zero hash code. That `implNote` only shows that it would not happen with current implementation at all.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168667338

From duke at openjdk.org  Mon Apr 17 13:23:35 2023
From: duke at openjdk.org (olivergillespie)
Date: Mon, 17 Apr 2023 13:23:35 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v2]
In-Reply-To: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
Message-ID: <OdBP0DSFX1Y18NpEX0a0_9fdfleDxScUck4SDzK4nQ8=.03aae349-dc2a-44fa-a74d-4b7a650f1cd2@github.com>

> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
> 
> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075).
> 
> ### Benchmark
> 
> 
> 
> Before:
> 
> Benchmark              Mode  Cnt  Score   Error  Units
> # Intel Cascade lake
> EnumHashCode.constant  avgt   15  1.602 ? 0.011  ns/op
> EnumHashCode.field     avgt   15  1.681 ? 0.014  ns/op
> # Arm Neoverse N1
> EnumHashCode.constant  avgt   15  1.642 ? 0.033  ns/op
> EnumHashCode.field     avgt   15  1.717 ? 0.059  ns/op
> 
> 
> 
> After:
> 
> Benchmark              Mode  Cnt  Score   Error  Units
> # Intel Cascade lake
> EnumHashCode.constant  avgt   15  0.479 ? 0.001  ns/op
> EnumHashCode.field     avgt   15  0.799 ? 0.002  ns/op
> # Arm Neoverse N1
> EnumHashCode.constant  avgt   15  0.802 ? 0.002  ns/op
> EnumHashCode.field     avgt   15  1.059 ? 0.056  ns/op
> 
> 
> Using `-prof perfasm` on the benchmark, we can compare the generated code for x86_64:
> 
> Before:
> 
> ? 0x00007fae4868dd17:   lea    (%r12,%r10,8),%rsi           ;*getfield e {reexecute=0 rethrow=0 return_oop=0}
> ?                                                           ; - org.sample.EnumHashCode::field at 1 (line 24)
> ?                                                           ; - org.sample.jmh_generated.EnumHashCode_field_jmhTest::field_avgt_jmhStub at 17 (line 186)
> ? 0x00007fae4868dd1b:   mov    (%rsi),%r10
> ? 0x00007fae4868dd1e:   mov    %r10,%r11
> ? 0x00007fae4868dd21:   and    $0x3,%r11
> ? 0x00007fae4868dd25:   cmp    $0x1,%r11
> ? 0x00007fae4868dd29:   jne    0x00007fae4868dcc6
> ? 0x00007fae4868dd2b:   shr    $0x8,%r10
> ? 0x00007fae4868dd2f:   mov    %r10d,%eax
> ? 0x00007fae4868dd32:   and    $0x7fffffff,%eax
> ? 0x00007fae4868dd37:   test   %eax,%eax
> ? 0x00007fae4868dd39:   je     0x00007fae4868dcc6           ;*invokespecial hashCode {reexecute=0 rethrow=0 return_oop=0}
> ?                                                           ; - java.lang.Enum::hashCode at 1 (line 175)
> 
> 
> This is the normal Object.hashCode intrinsic, which involves reading the object header, extracting the hash code and handling two slow-path cases (displaced object header, hash not initialized).
> 
> After:
> 
> 
>   ?  0x00007f550068e3b4:   mov    0x10(%r12,%r10,8),%r8d  <-- read the hash field
>   ?  0x00007f550068e3b9:   test   %r8d,%r8d               <-- if (hash == 0)
>   ?  0x00007f550068e3bc:   je     0x00007f550068e413      <-- slow init path, only taken on first use
> 
> 
> Thanks @shipilev for help with the implementation and interpreting the generated code.

olivergillespie has updated the pull request incrementally with one additional commit since the last revision:

  Make the new field transient
  
  Avoid changing the serialized form.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13491/files
  - new: https://git.openjdk.org/jdk/pull/13491/files/5039ffff..f5608481

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13491&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13491&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13491/head:pull/13491

PR: https://git.openjdk.org/jdk/pull/13491

From duke at openjdk.org  Mon Apr 17 13:27:43 2023
From: duke at openjdk.org (olivergillespie)
Date: Mon, 17 Apr 2023 13:27:43 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v3]
In-Reply-To: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
Message-ID: <rxW1QE76yFWsv6WxEpRSoa9l_3G1ejR2qJG9DeSOsCg=.5a4e002f-4f26-4d2b-9369-d1bebbe4c332@github.com>

> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
> 
> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075).
> 
> ### Benchmark
> 
> 
> 
> Before:
> 
> Benchmark              Mode  Cnt  Score   Error  Units
> # Intel Cascade lake
> EnumHashCode.constant  avgt   15  1.602 ? 0.011  ns/op
> EnumHashCode.field     avgt   15  1.681 ? 0.014  ns/op
> # Arm Neoverse N1
> EnumHashCode.constant  avgt   15  1.642 ? 0.033  ns/op
> EnumHashCode.field     avgt   15  1.717 ? 0.059  ns/op
> 
> 
> 
> After:
> 
> Benchmark              Mode  Cnt  Score   Error  Units
> # Intel Cascade lake
> EnumHashCode.constant  avgt   15  0.479 ? 0.001  ns/op
> EnumHashCode.field     avgt   15  0.799 ? 0.002  ns/op
> # Arm Neoverse N1
> EnumHashCode.constant  avgt   15  0.802 ? 0.002  ns/op
> EnumHashCode.field     avgt   15  1.059 ? 0.056  ns/op
> 
> 
> Using `-prof perfasm` on the benchmark, we can compare the generated code for x86_64:
> 
> Before:
> 
> ? 0x00007fae4868dd17:   lea    (%r12,%r10,8),%rsi           ;*getfield e {reexecute=0 rethrow=0 return_oop=0}
> ?                                                           ; - org.sample.EnumHashCode::field at 1 (line 24)
> ?                                                           ; - org.sample.jmh_generated.EnumHashCode_field_jmhTest::field_avgt_jmhStub at 17 (line 186)
> ? 0x00007fae4868dd1b:   mov    (%rsi),%r10
> ? 0x00007fae4868dd1e:   mov    %r10,%r11
> ? 0x00007fae4868dd21:   and    $0x3,%r11
> ? 0x00007fae4868dd25:   cmp    $0x1,%r11
> ? 0x00007fae4868dd29:   jne    0x00007fae4868dcc6
> ? 0x00007fae4868dd2b:   shr    $0x8,%r10
> ? 0x00007fae4868dd2f:   mov    %r10d,%eax
> ? 0x00007fae4868dd32:   and    $0x7fffffff,%eax
> ? 0x00007fae4868dd37:   test   %eax,%eax
> ? 0x00007fae4868dd39:   je     0x00007fae4868dcc6           ;*invokespecial hashCode {reexecute=0 rethrow=0 return_oop=0}
> ?                                                           ; - java.lang.Enum::hashCode at 1 (line 175)
> 
> 
> This is the normal Object.hashCode intrinsic, which involves reading the object header, extracting the hash code and handling two slow-path cases (displaced object header, hash not initialized).
> 
> After:
> 
> 
>   ?  0x00007f550068e3b4:   mov    0x10(%r12,%r10,8),%r8d  <-- read the hash field
>   ?  0x00007f550068e3b9:   test   %r8d,%r8d               <-- if (hash == 0)
>   ?  0x00007f550068e3bc:   je     0x00007f550068e413      <-- slow init path, only taken on first use
> 
> 
> Thanks @shipilev for help with the implementation and interpreting the generated code.

olivergillespie has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:

  8306075: Micro-optimize Enum.hashCode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13491/files
  - new: https://git.openjdk.org/jdk/pull/13491/files/f5608481..5039ffff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13491&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13491&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13491/head:pull/13491

PR: https://git.openjdk.org/jdk/pull/13491

From redestad at openjdk.org  Mon Apr 17 13:30:32 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 17 Apr 2023 13:30:32 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v2]
In-Reply-To: <OdBP0DSFX1Y18NpEX0a0_9fdfleDxScUck4SDzK4nQ8=.03aae349-dc2a-44fa-a74d-4b7a650f1cd2@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <OdBP0DSFX1Y18NpEX0a0_9fdfleDxScUck4SDzK4nQ8=.03aae349-dc2a-44fa-a74d-4b7a650f1cd2@github.com>
Message-ID: <tKtmu72sFvYrxBq-qja07Jorm8YOKpnCTel3vEYZ7xM=.cf4d9ba3-42ac-4eff-9122-69cb9b6df6e1@github.com>

On Mon, 17 Apr 2023 13:23:35 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075).
>> 
>> ### Benchmark
>> 
>> 
>> 
>> Before:
>> 
>> Benchmark              Mode  Cnt  Score   Error  Units
>> # Intel Cascade lake
>> EnumHashCode.constant  avgt   15  1.602 ? 0.011  ns/op
>> EnumHashCode.field     avgt   15  1.681 ? 0.014  ns/op
>> # Arm Neoverse N1
>> EnumHashCode.constant  avgt   15  1.642 ? 0.033  ns/op
>> EnumHashCode.field     avgt   15  1.717 ? 0.059  ns/op
>> 
>> 
>> 
>> After:
>> 
>> Benchmark              Mode  Cnt  Score   Error  Units
>> # Intel Cascade lake
>> EnumHashCode.constant  avgt   15  0.479 ? 0.001  ns/op
>> EnumHashCode.field     avgt   15  0.799 ? 0.002  ns/op
>> # Arm Neoverse N1
>> EnumHashCode.constant  avgt   15  0.802 ? 0.002  ns/op
>> EnumHashCode.field     avgt   15  1.059 ? 0.056  ns/op
>> 
>> 
>> Using `-prof perfasm` on the benchmark, we can compare the generated code for x86_64:
>> 
>> Before:
>> 
>> ? 0x00007fae4868dd17:   lea    (%r12,%r10,8),%rsi           ;*getfield e {reexecute=0 rethrow=0 return_oop=0}
>> ?                                                           ; - org.sample.EnumHashCode::field at 1 (line 24)
>> ?                                                           ; - org.sample.jmh_generated.EnumHashCode_field_jmhTest::field_avgt_jmhStub at 17 (line 186)
>> ? 0x00007fae4868dd1b:   mov    (%rsi),%r10
>> ? 0x00007fae4868dd1e:   mov    %r10,%r11
>> ? 0x00007fae4868dd21:   and    $0x3,%r11
>> ? 0x00007fae4868dd25:   cmp    $0x1,%r11
>> ? 0x00007fae4868dd29:   jne    0x00007fae4868dcc6
>> ? 0x00007fae4868dd2b:   shr    $0x8,%r10
>> ? 0x00007fae4868dd2f:   mov    %r10d,%eax
>> ? 0x00007fae4868dd32:   and    $0x7fffffff,%eax
>> ? 0x00007fae4868dd37:   test   %eax,%eax
>> ? 0x00007fae4868dd39:   je     0x00007fae4868dcc6           ;*invokespecial hashCode {reexecute=0 rethrow=0 return_oop=0}
>> ?                                                           ; - java.lang.Enum::hashCode at 1 (line 175)
>> 
>> 
>> This is the normal Object.hashCode intrinsic, which involves reading the object header, extracting the hash code and handling two slow-path cases (displaced object header, hash not initialized).
>> 
>> After:
>> 
>> 
>>   ?  0x00007f550068e3b4:   mov    0x10(%r12,%r10,8),%r8d  <-- read the hash field
>>   ?  0x00007f550068e3b9:   test   %r8d,%r8d               <-- if (hash == 0)
>>   ?  0x00007f550068e3bc:   je     0x00007f550068e413      <-- slow init path, only taken on first use
>> 
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.

Why isn't `Enum::hashCode` simply doing `return ordinal;`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1511348832

From duke at openjdk.org  Mon Apr 17 13:30:33 2023
From: duke at openjdk.org (olivergillespie)
Date: Mon, 17 Apr 2023 13:30:33 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v2]
In-Reply-To: <tKtmu72sFvYrxBq-qja07Jorm8YOKpnCTel3vEYZ7xM=.cf4d9ba3-42ac-4eff-9122-69cb9b6df6e1@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <OdBP0DSFX1Y18NpEX0a0_9fdfleDxScUck4SDzK4nQ8=.03aae349-dc2a-44fa-a74d-4b7a650f1cd2@github.com>
 <tKtmu72sFvYrxBq-qja07Jorm8YOKpnCTel3vEYZ7xM=.cf4d9ba3-42ac-4eff-9122-69cb9b6df6e1@github.com>
Message-ID: <D14tz4RCkzTi8GtRWYqh7D78lDPhhTFUSbaptCismP8=.ff2e18c2-7a3f-4b28-b278-5cc0586a73cd@github.com>

On Mon, 17 Apr 2023 13:26:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Why isn't `Enum::hashCode` simply doing `return ordinal;`?

See https://bugs.openjdk.org/browse/JDK-8050217

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1511350037

From duke at openjdk.org  Mon Apr 17 13:30:38 2023
From: duke at openjdk.org (olivergillespie)
Date: Mon, 17 Apr 2023 13:30:38 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v3]
In-Reply-To: <rxW1QE76yFWsv6WxEpRSoa9l_3G1ejR2qJG9DeSOsCg=.5a4e002f-4f26-4d2b-9369-d1bebbe4c332@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <rxW1QE76yFWsv6WxEpRSoa9l_3G1ejR2qJG9DeSOsCg=.5a4e002f-4f26-4d2b-9369-d1bebbe4c332@github.com>
Message-ID: <JpzhBGirFcbIOzZWbuRmUgr6U8rgNXMLplPRuAxySeY=.1cec9270-f940-4e33-8a31-fe5486bc435d@github.com>

On Mon, 17 Apr 2023 13:27:43 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075).
>> 
>> ### Benchmark
>> 
>> 
>> 
>> Before:
>> 
>> Benchmark              Mode  Cnt  Score   Error  Units
>> # Intel Cascade lake
>> EnumHashCode.constant  avgt   15  1.602 ? 0.011  ns/op
>> EnumHashCode.field     avgt   15  1.681 ? 0.014  ns/op
>> # Arm Neoverse N1
>> EnumHashCode.constant  avgt   15  1.642 ? 0.033  ns/op
>> EnumHashCode.field     avgt   15  1.717 ? 0.059  ns/op
>> 
>> 
>> 
>> After:
>> 
>> Benchmark              Mode  Cnt  Score   Error  Units
>> # Intel Cascade lake
>> EnumHashCode.constant  avgt   15  0.479 ? 0.001  ns/op
>> EnumHashCode.field     avgt   15  0.799 ? 0.002  ns/op
>> # Arm Neoverse N1
>> EnumHashCode.constant  avgt   15  0.802 ? 0.002  ns/op
>> EnumHashCode.field     avgt   15  1.059 ? 0.056  ns/op
>> 
>> 
>> Using `-prof perfasm` on the benchmark, we can compare the generated code for x86_64:
>> 
>> Before:
>> 
>> ? 0x00007fae4868dd17:   lea    (%r12,%r10,8),%rsi           ;*getfield e {reexecute=0 rethrow=0 return_oop=0}
>> ?                                                           ; - org.sample.EnumHashCode::field at 1 (line 24)
>> ?                                                           ; - org.sample.jmh_generated.EnumHashCode_field_jmhTest::field_avgt_jmhStub at 17 (line 186)
>> ? 0x00007fae4868dd1b:   mov    (%rsi),%r10
>> ? 0x00007fae4868dd1e:   mov    %r10,%r11
>> ? 0x00007fae4868dd21:   and    $0x3,%r11
>> ? 0x00007fae4868dd25:   cmp    $0x1,%r11
>> ? 0x00007fae4868dd29:   jne    0x00007fae4868dcc6
>> ? 0x00007fae4868dd2b:   shr    $0x8,%r10
>> ? 0x00007fae4868dd2f:   mov    %r10d,%eax
>> ? 0x00007fae4868dd32:   and    $0x7fffffff,%eax
>> ? 0x00007fae4868dd37:   test   %eax,%eax
>> ? 0x00007fae4868dd39:   je     0x00007fae4868dcc6           ;*invokespecial hashCode {reexecute=0 rethrow=0 return_oop=0}
>> ?                                                           ; - java.lang.Enum::hashCode at 1 (line 175)
>> 
>> 
>> This is the normal Object.hashCode intrinsic, which involves reading the object header, extracting the hash code and handling two slow-path cases (displaced object header, hash not initialized).
>> 
>> After:
>> 
>> 
>>   ?  0x00007f550068e3b4:   mov    0x10(%r12,%r10,8),%r8d  <-- read the hash field
>>   ?  0x00007f550068e3b9:   test   %r8d,%r8d               <-- if (hash == 0)
>>   ?  0x00007f550068e3bc:   je     0x00007f550068e413      <-- slow init path, only taken on first use
>> 
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8306075: Micro-optimize Enum.hashCode

src/java.base/share/classes/java/lang/Enum.java line 181:

> 179:      */
> 180:     @Stable
> 181:     private int hash;

Note that `transient` is not needed here, as per https://docs.oracle.com/en/java/javase/17/docs/specs/serialization/serial-arch.html#serialization-of-enum-constants

> The serialized form of an enum constant consists solely of its name; field values of the constant are not present in the form.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168692940

From redestad at openjdk.org  Mon Apr 17 13:43:42 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 17 Apr 2023 13:43:42 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v3]
In-Reply-To: <rxW1QE76yFWsv6WxEpRSoa9l_3G1ejR2qJG9DeSOsCg=.5a4e002f-4f26-4d2b-9369-d1bebbe4c332@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <rxW1QE76yFWsv6WxEpRSoa9l_3G1ejR2qJG9DeSOsCg=.5a4e002f-4f26-4d2b-9369-d1bebbe4c332@github.com>
Message-ID: <9qwAutQfyn2Kk-S2zKRZu6wzLvA1bffOQ1T3DmhYW5Q=.d94b3a2c-fcd6-4efa-a2dc-6e8acbc0fbea@github.com>

On Mon, 17 Apr 2023 13:27:43 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075).
>> 
>> ### Benchmark
>> 
>> 
>> 
>> Before:
>> 
>> Benchmark              Mode  Cnt  Score   Error  Units
>> # Intel Cascade lake
>> EnumHashCode.constant  avgt   15  1.602 ? 0.011  ns/op
>> EnumHashCode.field     avgt   15  1.681 ? 0.014  ns/op
>> # Arm Neoverse N1
>> EnumHashCode.constant  avgt   15  1.642 ? 0.033  ns/op
>> EnumHashCode.field     avgt   15  1.717 ? 0.059  ns/op
>> 
>> 
>> 
>> After:
>> 
>> Benchmark              Mode  Cnt  Score   Error  Units
>> # Intel Cascade lake
>> EnumHashCode.constant  avgt   15  0.479 ? 0.001  ns/op
>> EnumHashCode.field     avgt   15  0.799 ? 0.002  ns/op
>> # Arm Neoverse N1
>> EnumHashCode.constant  avgt   15  0.802 ? 0.002  ns/op
>> EnumHashCode.field     avgt   15  1.059 ? 0.056  ns/op
>> 
>> 
>> Using `-prof perfasm` on the benchmark, we can compare the generated code for x86_64:
>> 
>> Before:
>> 
>> ? 0x00007fae4868dd17:   lea    (%r12,%r10,8),%rsi           ;*getfield e {reexecute=0 rethrow=0 return_oop=0}
>> ?                                                           ; - org.sample.EnumHashCode::field at 1 (line 24)
>> ?                                                           ; - org.sample.jmh_generated.EnumHashCode_field_jmhTest::field_avgt_jmhStub at 17 (line 186)
>> ? 0x00007fae4868dd1b:   mov    (%rsi),%r10
>> ? 0x00007fae4868dd1e:   mov    %r10,%r11
>> ? 0x00007fae4868dd21:   and    $0x3,%r11
>> ? 0x00007fae4868dd25:   cmp    $0x1,%r11
>> ? 0x00007fae4868dd29:   jne    0x00007fae4868dcc6
>> ? 0x00007fae4868dd2b:   shr    $0x8,%r10
>> ? 0x00007fae4868dd2f:   mov    %r10d,%eax
>> ? 0x00007fae4868dd32:   and    $0x7fffffff,%eax
>> ? 0x00007fae4868dd37:   test   %eax,%eax
>> ? 0x00007fae4868dd39:   je     0x00007fae4868dcc6           ;*invokespecial hashCode {reexecute=0 rethrow=0 return_oop=0}
>> ?                                                           ; - java.lang.Enum::hashCode at 1 (line 175)
>> 
>> 
>> This is the normal Object.hashCode intrinsic, which involves reading the object header, extracting the hash code and handling two slow-path cases (displaced object header, hash not initialized).
>> 
>> After:
>> 
>> 
>>   ?  0x00007f550068e3b4:   mov    0x10(%r12,%r10,8),%r8d  <-- read the hash field
>>   ?  0x00007f550068e3b9:   test   %r8d,%r8d               <-- if (hash == 0)
>>   ?  0x00007f550068e3bc:   je     0x00007f550068e413      <-- slow init path, only taken on first use
>> 
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8306075: Micro-optimize Enum.hashCode

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13491#pullrequestreview-1388096639

From redestad at openjdk.org  Mon Apr 17 13:43:44 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 17 Apr 2023 13:43:44 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v2]
In-Reply-To: <D14tz4RCkzTi8GtRWYqh7D78lDPhhTFUSbaptCismP8=.ff2e18c2-7a3f-4b28-b278-5cc0586a73cd@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <OdBP0DSFX1Y18NpEX0a0_9fdfleDxScUck4SDzK4nQ8=.03aae349-dc2a-44fa-a74d-4b7a650f1cd2@github.com>
 <tKtmu72sFvYrxBq-qja07Jorm8YOKpnCTel3vEYZ7xM=.cf4d9ba3-42ac-4eff-9122-69cb9b6df6e1@github.com>
 <D14tz4RCkzTi8GtRWYqh7D78lDPhhTFUSbaptCismP8=.ff2e18c2-7a3f-4b28-b278-5cc0586a73cd@github.com>
Message-ID: <aJdN6W8q1Kd3yTWvy1qQhdjM2VY-Pogdxd5j8RXVK0M=.4afc1785-534c-4a97-8dcc-8950c7eb7d0c@github.com>

On Mon, 17 Apr 2023 13:27:43 GMT, olivergillespie <duke at openjdk.org> wrote:

> > Why isn't `Enum::hashCode` simply doing `return ordinal;`?
> 
> See https://bugs.openjdk.org/browse/JDK-8050217

Thanks! If there are apps where `Enum::hashCode` is performance sensitive then run-to-run stability may be a stronger argument than @stuart-marks et al argues it is here, though there might be some unspoken arguments about how it might affect iteration order et.c... 

Adding a cached field to `Enum` seem innocuous though, whether it disappears into a padding gap or not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1511370298

From asotona at openjdk.org  Mon Apr 17 13:47:00 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Apr 2023 13:47:00 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
Message-ID: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@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

-------------

Commit messages:
 - fixed TestClassNameWarning
 - Merge branch 'master' into JDK-8294969-javap
 - consolidated safeguarding of IAE in javap
 - consolidation of constant pool originating IAEs and IOOBEs into ConstantPoolException extending IAE
 - Safeguarding CP errors + test
 - Merge branch 'master' into JDK-8294969-javap
 - fixed tools/javap/TestClassNameWarning.java
 - fixed tools/javap/T6866657.java and tools/javap/T7186925.java
 - fix of tools/javap/attribute_length/AttributeLengthTest.java
 - Merge remote-tracking branch 'upstream/master' into JDK-8294969-javap
 - ... and 203 more: https://git.openjdk.org/jdk/compare/c0b4957f...5872761b

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294969
  Stats: 3742 lines in 28 files changed: 904 ins; 1723 del; 1115 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 asotona at openjdk.org  Mon Apr 17 13:47:05 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Apr 2023 13:47:05 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
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: <JoTLq9U8NjEqWkEH9JWUYoWJ5stw6WV9c5Ka8-s4m0s=.134b43bc-6079-4af7-9d29-8649a31dfdd8@github.com>

On Tue, 29 Nov 2022 10:26:31 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

failing `hotspot/jtreg/serviceability/sa/ClhsdbDumpclass.java` test is caused by [JDK-8305490](https://bugs.openjdk.org/browse/JDK-8305490)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11411#issuecomment-1494742529

From liach at openjdk.org  Mon Apr 17 13:47:03 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Apr 2023 13:47:03 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
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: <Bk2-EOljbEJKzqXjB85MOKNlUjBRYCj6r5GLcu5FYgs=.a57374dd-2864-4a91-b611-f95a3b8dd518@github.com>

On Tue, 29 Nov 2022 10:26:31 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

I took a look at this patch locally; 4 of the javap tests fail. The main problem with this port is that javap has in-depth constant pool error handling; for instance, if an interface list is broken with some invalid class entries, the old library allows to report the valid entries, while classfile api just interprets the whole interface list at once and fails with IllegalArgumentException or IndexOutOfBoundsException for invalid constant pool indices. It's quite complicated to safeguard every potentially erroneous call.

test/langtools/tools/javap/TestClassNameWarning.java line 180:

> 178:                 cf.magic, cf.minor_version, cf.major_version, cf.constant_pool,
> 179:                 cf.access_flags,
> 180:                 cf.this_class,

Should we just remove this no-name-class case since it's already an invalid class file?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11411#issuecomment-1493109566
PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1158595266

From asotona at openjdk.org  Mon Apr 17 13:47:05 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Apr 2023 13:47:05 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
In-Reply-To: <Bk2-EOljbEJKzqXjB85MOKNlUjBRYCj6r5GLcu5FYgs=.a57374dd-2864-4a91-b611-f95a3b8dd518@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
 <Bk2-EOljbEJKzqXjB85MOKNlUjBRYCj6r5GLcu5FYgs=.a57374dd-2864-4a91-b611-f95a3b8dd518@github.com>
Message-ID: <2PEN_lDyRj6J_Kf_UUm7k2SzSJ5IxjExEe9p-2tB8lc=.9abff196-6709-4398-b215-7f19df9711f1@github.com>

On Sat, 1 Apr 2023 20:31:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> It's quite complicated to safeguard every potentially erroneous call.

I agree, it is complicated, however possible. The question however is whether it is desirable. See for example silently failing `ClhsdbDumpclass` test with many safeguarded erroneous calls in [JDK-8305490](https://bugs.openjdk.org/browse/JDK-8305490).

Current javap implementation seems to lack the final failure (returning error exit code) after any safeguarded error.

> test/langtools/tools/javap/TestClassNameWarning.java line 180:
> 
>> 178:                 cf.magic, cf.minor_version, cf.major_version, cf.constant_pool,
>> 179:                 cf.access_flags,
>> 180:                 cf.this_class,
> 
> Should we just remove this no-name-class case since it's already an invalid class file?

I've fixed this test so it reflects actual javap behaviour.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11411#issuecomment-1495446682
PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1168713924

From prappo at openjdk.org  Mon Apr 17 13:48:42 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 17 Apr 2023 13:48:42 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v3]
In-Reply-To: <bN9YMQjWh24MhE17zbN1b1iSKW9VIiJ1u4xn7kV22mg=.0fa0d03a-6e5b-4a91-a0d6-f4f42de894f6@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <jQWXWn_rma-JtYK5AlSO1W2CH8q9VAKK4DS0_Gqk26c=.428eadeb-f203-4e25-915a-a346befa3163@github.com>
 <_ddg8NNgXP2qnKZLqcf15YmiQCTgdcr1yY2P1OFJ6Ks=.d0ab6b0f-a6a5-441e-ba31-c05c8af3932f@github.com>
 <bN9YMQjWh24MhE17zbN1b1iSKW9VIiJ1u4xn7kV22mg=.0fa0d03a-6e5b-4a91-a0d6-f4f42de894f6@github.com>
Message-ID: <RiA_-5Oc5KWMr0z1UaEWpEsCs4hNNht2Qk2WlYh0LO8=.f74431c1-9c9b-4395-9ddb-7c54912225a6@github.com>

On Mon, 17 Apr 2023 13:08:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Yes, it is implementation-specific, that is why it says "Hotspot's identity hash code". The relevant code blocks are https://github.com/openjdk/jdk/blob/cc60f2ff3f16bdb04917e09cb87f09bd544f1f8b/src/hotspot/share/oops/markWord.hpp#L231-L233 (property) and https://github.com/openjdk/jdk/blob/cc60f2ff3f16bdb04917e09cb87f09bd544f1f8b/src/hotspot/share/runtime/synchronizer.cpp#L826-L827 (invariant).
>
> It would not break the code functionally if that invariant ever breaks: we would "just" call the (intrinsic) method on zero hash code. That `implNote` only shows that it would not happen with current implementation at all.

>From that impl note it seemed like it was a big deal for hash code to never return 0 for an object. Could you maybe de-emphasize the importance of that HotSpot behavior in the note?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168725310

From apangin at openjdk.org  Mon Apr 17 13:48:50 2023
From: apangin at openjdk.org (Andrei Pangin)
Date: Mon, 17 Apr 2023 13:48:50 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v3]
In-Reply-To: <rxW1QE76yFWsv6WxEpRSoa9l_3G1ejR2qJG9DeSOsCg=.5a4e002f-4f26-4d2b-9369-d1bebbe4c332@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <rxW1QE76yFWsv6WxEpRSoa9l_3G1ejR2qJG9DeSOsCg=.5a4e002f-4f26-4d2b-9369-d1bebbe4c332@github.com>
Message-ID: <2sc7tIUMfTOFZBni-1cQGoO8uCD8JpU-U53pG1PmvoY=.a7c12f3d-094f-4d54-80ad-97aae67a0978@github.com>

On Mon, 17 Apr 2023 13:27:43 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075).
>> 
>> ### Benchmark
>> 
>> 
>> 
>> Before:
>> 
>> Benchmark              Mode  Cnt  Score   Error  Units
>> # Intel Cascade lake
>> EnumHashCode.constant  avgt   15  1.602 ? 0.011  ns/op
>> EnumHashCode.field     avgt   15  1.681 ? 0.014  ns/op
>> # Arm Neoverse N1
>> EnumHashCode.constant  avgt   15  1.642 ? 0.033  ns/op
>> EnumHashCode.field     avgt   15  1.717 ? 0.059  ns/op
>> 
>> 
>> 
>> After:
>> 
>> Benchmark              Mode  Cnt  Score   Error  Units
>> # Intel Cascade lake
>> EnumHashCode.constant  avgt   15  0.479 ? 0.001  ns/op
>> EnumHashCode.field     avgt   15  0.799 ? 0.002  ns/op
>> # Arm Neoverse N1
>> EnumHashCode.constant  avgt   15  0.802 ? 0.002  ns/op
>> EnumHashCode.field     avgt   15  1.059 ? 0.056  ns/op
>> 
>> 
>> Using `-prof perfasm` on the benchmark, we can compare the generated code for x86_64:
>> 
>> Before:
>> 
>> ? 0x00007fae4868dd17:   lea    (%r12,%r10,8),%rsi           ;*getfield e {reexecute=0 rethrow=0 return_oop=0}
>> ?                                                           ; - org.sample.EnumHashCode::field at 1 (line 24)
>> ?                                                           ; - org.sample.jmh_generated.EnumHashCode_field_jmhTest::field_avgt_jmhStub at 17 (line 186)
>> ? 0x00007fae4868dd1b:   mov    (%rsi),%r10
>> ? 0x00007fae4868dd1e:   mov    %r10,%r11
>> ? 0x00007fae4868dd21:   and    $0x3,%r11
>> ? 0x00007fae4868dd25:   cmp    $0x1,%r11
>> ? 0x00007fae4868dd29:   jne    0x00007fae4868dcc6
>> ? 0x00007fae4868dd2b:   shr    $0x8,%r10
>> ? 0x00007fae4868dd2f:   mov    %r10d,%eax
>> ? 0x00007fae4868dd32:   and    $0x7fffffff,%eax
>> ? 0x00007fae4868dd37:   test   %eax,%eax
>> ? 0x00007fae4868dd39:   je     0x00007fae4868dcc6           ;*invokespecial hashCode {reexecute=0 rethrow=0 return_oop=0}
>> ?                                                           ; - java.lang.Enum::hashCode at 1 (line 175)
>> 
>> 
>> This is the normal Object.hashCode intrinsic, which involves reading the object header, extracting the hash code and handling two slow-path cases (displaced object header, hash not initialized).
>> 
>> After:
>> 
>> 
>>   ?  0x00007f550068e3b4:   mov    0x10(%r12,%r10,8),%r8d  <-- read the hash field
>>   ?  0x00007f550068e3b9:   test   %r8d,%r8d               <-- if (hash == 0)
>>   ?  0x00007f550068e3bc:   je     0x00007f550068e413      <-- slow init path, only taken on first use
>> 
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8306075: Micro-optimize Enum.hashCode

src/java.base/share/classes/java/lang/Enum.java line 181:

> 179:      */
> 180:     @Stable
> 181:     private int hash;

Should not we hide the field from reflection?

I understand this is an implementation detail, however, it makes a big difference that you add a private field to the *public* class that is *meant* to be inherited by user classes. Although I'm not aware of a particular example, this can be a breaking change for user code that does introspection on enums.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168724994

From shade at openjdk.org  Mon Apr 17 13:57:35 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Apr 2023 13:57:35 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v3]
In-Reply-To: <RiA_-5Oc5KWMr0z1UaEWpEsCs4hNNht2Qk2WlYh0LO8=.f74431c1-9c9b-4395-9ddb-7c54912225a6@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <jQWXWn_rma-JtYK5AlSO1W2CH8q9VAKK4DS0_Gqk26c=.428eadeb-f203-4e25-915a-a346befa3163@github.com>
 <_ddg8NNgXP2qnKZLqcf15YmiQCTgdcr1yY2P1OFJ6Ks=.d0ab6b0f-a6a5-441e-ba31-c05c8af3932f@github.com>
 <bN9YMQjWh24MhE17zbN1b1iSKW9VIiJ1u4xn7kV22mg=.0fa0d03a-6e5b-4a91-a0d6-f4f42de894f6@github.com>
 <RiA_-5Oc5KWMr0z1UaEWpEsCs4hNNht2Qk2WlYh0LO8=.f74431c1-9c9b-4395-9ddb-7c54912225a6@github.com>
Message-ID: <rH0yJmozlZzn7E3gQzHCjZfuYTdtdp8wkjJCoByhp-E=.dc94dfea-3b52-443c-8205-dc80f554dec9@github.com>

On Mon, 17 Apr 2023 13:45:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> It would not break the code functionally if that invariant ever breaks: we would "just" call the (intrinsic) method on zero hash code. That `implNote` only shows that it would not happen with current implementation at all.
>
> From that impl note it seemed like it was a big deal for hash code to never return 0 for an object. Could you maybe de-emphasize the importance of that HotSpot behavior in the note?

All right, we can change "This allows to treat zero as the marker..." to "This makes zero a convenient marker...", I think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168731359

From prappo at openjdk.org  Mon Apr 17 13:57:39 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 17 Apr 2023 13:57:39 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v3]
In-Reply-To: <rxW1QE76yFWsv6WxEpRSoa9l_3G1ejR2qJG9DeSOsCg=.5a4e002f-4f26-4d2b-9369-d1bebbe4c332@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <rxW1QE76yFWsv6WxEpRSoa9l_3G1ejR2qJG9DeSOsCg=.5a4e002f-4f26-4d2b-9369-d1bebbe4c332@github.com>
Message-ID: <gIdiQl11if-dJeoy53CRYS9L9GISheJsM_mBcRifdLM=.7fdeb567-1e26-4239-8059-1b1aa9b41500@github.com>

On Mon, 17 Apr 2023 13:27:43 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075).
>> 
>> ### Benchmark
>> 
>> 
>> 
>> Before:
>> 
>> Benchmark              Mode  Cnt  Score   Error  Units
>> # Intel Cascade lake
>> EnumHashCode.constant  avgt   15  1.602 ? 0.011  ns/op
>> EnumHashCode.field     avgt   15  1.681 ? 0.014  ns/op
>> # Arm Neoverse N1
>> EnumHashCode.constant  avgt   15  1.642 ? 0.033  ns/op
>> EnumHashCode.field     avgt   15  1.717 ? 0.059  ns/op
>> 
>> 
>> 
>> After:
>> 
>> Benchmark              Mode  Cnt  Score   Error  Units
>> # Intel Cascade lake
>> EnumHashCode.constant  avgt   15  0.479 ? 0.001  ns/op
>> EnumHashCode.field     avgt   15  0.799 ? 0.002  ns/op
>> # Arm Neoverse N1
>> EnumHashCode.constant  avgt   15  0.802 ? 0.002  ns/op
>> EnumHashCode.field     avgt   15  1.059 ? 0.056  ns/op
>> 
>> 
>> Using `-prof perfasm` on the benchmark, we can compare the generated code for x86_64:
>> 
>> Before:
>> 
>> ? 0x00007fae4868dd17:   lea    (%r12,%r10,8),%rsi           ;*getfield e {reexecute=0 rethrow=0 return_oop=0}
>> ?                                                           ; - org.sample.EnumHashCode::field at 1 (line 24)
>> ?                                                           ; - org.sample.jmh_generated.EnumHashCode_field_jmhTest::field_avgt_jmhStub at 17 (line 186)
>> ? 0x00007fae4868dd1b:   mov    (%rsi),%r10
>> ? 0x00007fae4868dd1e:   mov    %r10,%r11
>> ? 0x00007fae4868dd21:   and    $0x3,%r11
>> ? 0x00007fae4868dd25:   cmp    $0x1,%r11
>> ? 0x00007fae4868dd29:   jne    0x00007fae4868dcc6
>> ? 0x00007fae4868dd2b:   shr    $0x8,%r10
>> ? 0x00007fae4868dd2f:   mov    %r10d,%eax
>> ? 0x00007fae4868dd32:   and    $0x7fffffff,%eax
>> ? 0x00007fae4868dd37:   test   %eax,%eax
>> ? 0x00007fae4868dd39:   je     0x00007fae4868dcc6           ;*invokespecial hashCode {reexecute=0 rethrow=0 return_oop=0}
>> ?                                                           ; - java.lang.Enum::hashCode at 1 (line 175)
>> 
>> 
>> This is the normal Object.hashCode intrinsic, which involves reading the object header, extracting the hash code and handling two slow-path cases (displaced object header, hash not initialized).
>> 
>> After:
>> 
>> 
>>   ?  0x00007f550068e3b4:   mov    0x10(%r12,%r10,8),%r8d  <-- read the hash field
>>   ?  0x00007f550068e3b9:   test   %r8d,%r8d               <-- if (hash == 0)
>>   ?  0x00007f550068e3bc:   je     0x00007f550068e413      <-- slow init path, only taken on first use
>> 
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8306075: Micro-optimize Enum.hashCode

src/java.base/share/classes/java/lang/Enum.java line 175:

> 173:      *
> 174:      * @implNote Once initialized, the field value does not change.
> 175:      * Hotspot's identity hash code generation also never returns zero

Trivial: it's camel case in HotSpot

For example: https://en.wikipedia.org/wiki/HotSpot_(virtual_machine)

src/java.base/share/classes/java/lang/Enum.java line 177:

> 175:      * Hotspot's identity hash code generation also never returns zero
> 176:      * as the identity hash code. This allows to treat zero as the marker
> 177:      * for the un-initialized value for both {#link @Stable} and the lazy

Typo: `{#link @Stable}`

I'd suggest using either `{@link Stable}` or `{@code @Stable}`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168731449
PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168734730

From liach at openjdk.org  Mon Apr 17 13:57:43 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Apr 2023 13:57:43 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v3]
In-Reply-To: <2sc7tIUMfTOFZBni-1cQGoO8uCD8JpU-U53pG1PmvoY=.a7c12f3d-094f-4d54-80ad-97aae67a0978@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <rxW1QE76yFWsv6WxEpRSoa9l_3G1ejR2qJG9DeSOsCg=.5a4e002f-4f26-4d2b-9369-d1bebbe4c332@github.com>
 <2sc7tIUMfTOFZBni-1cQGoO8uCD8JpU-U53pG1PmvoY=.a7c12f3d-094f-4d54-80ad-97aae67a0978@github.com>
Message-ID: <aU5WsYUZ26GfAetL_E6zWaXowfF_o8Ij2dx2dUR1ctU=.d91b35a1-7924-4011-a95e-6d4b8fe22c4b@github.com>

On Mon, 17 Apr 2023 13:45:05 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> olivergillespie has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
>> 
>>   8306075: Micro-optimize Enum.hashCode
>
> src/java.base/share/classes/java/lang/Enum.java line 181:
> 
>> 179:      */
>> 180:     @Stable
>> 181:     private int hash;
> 
> Should not we hide the field from reflection?
> 
> I understand this is an implementation detail, however, it makes a big difference that you add a private field to the *public* class that is *meant* to be inherited by user classes. Although I'm not aware of a particular example, this can be a breaking change for user code that does introspection on enums.

How is this a big difference? It's only discovered by getDeclaredFields. This can only be modified if users break jdk internal encapsulation in command line, which means they can change everything else.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168738513

From duke at openjdk.org  Mon Apr 17 14:15:39 2023
From: duke at openjdk.org (olivergillespie)
Date: Mon, 17 Apr 2023 14:15:39 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v4]
In-Reply-To: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
Message-ID: <e8onn7g2EOBa0Y8o01DsOiyQ7vzVlrApOUaz6vef17s=.ed1003dd-0da3-4040-a1ed-3e570673a7d7@github.com>

> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
> 
> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075).
> 
> ### Benchmark
> 
> 
> 
> Before:
> 
> Benchmark              Mode  Cnt  Score   Error  Units
> # Intel Cascade lake
> EnumHashCode.constant  avgt   15  1.602 ? 0.011  ns/op
> EnumHashCode.field     avgt   15  1.681 ? 0.014  ns/op
> # Arm Neoverse N1
> EnumHashCode.constant  avgt   15  1.642 ? 0.033  ns/op
> EnumHashCode.field     avgt   15  1.717 ? 0.059  ns/op
> 
> 
> 
> After:
> 
> Benchmark              Mode  Cnt  Score   Error  Units
> # Intel Cascade lake
> EnumHashCode.constant  avgt   15  0.479 ? 0.001  ns/op
> EnumHashCode.field     avgt   15  0.799 ? 0.002  ns/op
> # Arm Neoverse N1
> EnumHashCode.constant  avgt   15  0.802 ? 0.002  ns/op
> EnumHashCode.field     avgt   15  1.059 ? 0.056  ns/op
> 
> 
> Using `-prof perfasm` on the benchmark, we can compare the generated code for x86_64:
> 
> Before:
> 
> ? 0x00007fae4868dd17:   lea    (%r12,%r10,8),%rsi           ;*getfield e {reexecute=0 rethrow=0 return_oop=0}
> ?                                                           ; - org.sample.EnumHashCode::field at 1 (line 24)
> ?                                                           ; - org.sample.jmh_generated.EnumHashCode_field_jmhTest::field_avgt_jmhStub at 17 (line 186)
> ? 0x00007fae4868dd1b:   mov    (%rsi),%r10
> ? 0x00007fae4868dd1e:   mov    %r10,%r11
> ? 0x00007fae4868dd21:   and    $0x3,%r11
> ? 0x00007fae4868dd25:   cmp    $0x1,%r11
> ? 0x00007fae4868dd29:   jne    0x00007fae4868dcc6
> ? 0x00007fae4868dd2b:   shr    $0x8,%r10
> ? 0x00007fae4868dd2f:   mov    %r10d,%eax
> ? 0x00007fae4868dd32:   and    $0x7fffffff,%eax
> ? 0x00007fae4868dd37:   test   %eax,%eax
> ? 0x00007fae4868dd39:   je     0x00007fae4868dcc6           ;*invokespecial hashCode {reexecute=0 rethrow=0 return_oop=0}
> ?                                                           ; - java.lang.Enum::hashCode at 1 (line 175)
> 
> 
> This is the normal Object.hashCode intrinsic, which involves reading the object header, extracting the hash code and handling two slow-path cases (displaced object header, hash not initialized).
> 
> After:
> 
> 
>   ?  0x00007f550068e3b4:   mov    0x10(%r12,%r10,8),%r8d  <-- read the hash field
>   ?  0x00007f550068e3b9:   test   %r8d,%r8d               <-- if (hash == 0)
>   ?  0x00007f550068e3bc:   je     0x00007f550068e413      <-- slow init path, only taken on first use
> 
> 
> Thanks @shipilev for help with the implementation and interpreting the generated code.

olivergillespie has updated the pull request incrementally with one additional commit since the last revision:

  Fix two typos

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13491/files
  - new: https://git.openjdk.org/jdk/pull/13491/files/5039ffff..79af4952

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13491&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13491&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13491/head:pull/13491

PR: https://git.openjdk.org/jdk/pull/13491

From prappo at openjdk.org  Mon Apr 17 14:25:38 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 17 Apr 2023 14:25:38 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v4]
In-Reply-To: <e8onn7g2EOBa0Y8o01DsOiyQ7vzVlrApOUaz6vef17s=.ed1003dd-0da3-4040-a1ed-3e570673a7d7@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <e8onn7g2EOBa0Y8o01DsOiyQ7vzVlrApOUaz6vef17s=.ed1003dd-0da3-4040-a1ed-3e570673a7d7@github.com>
Message-ID: <-21bRVESVZd_7-wRBjZtqTQzz3fNd6o0Nn03CBtW9rQ=.d382c9f4-01b7-40e6-af22-34ff186e1539@github.com>

On Mon, 17 Apr 2023 14:15:39 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075).
>> 
>> ### Benchmark
>> 
>> 
>> 
>> Before:
>> 
>> Benchmark              Mode  Cnt  Score   Error  Units
>> # Intel Cascade lake
>> EnumHashCode.constant  avgt   15  1.602 ? 0.011  ns/op
>> EnumHashCode.field     avgt   15  1.681 ? 0.014  ns/op
>> # Arm Neoverse N1
>> EnumHashCode.constant  avgt   15  1.642 ? 0.033  ns/op
>> EnumHashCode.field     avgt   15  1.717 ? 0.059  ns/op
>> 
>> 
>> 
>> After:
>> 
>> Benchmark              Mode  Cnt  Score   Error  Units
>> # Intel Cascade lake
>> EnumHashCode.constant  avgt   15  0.479 ? 0.001  ns/op
>> EnumHashCode.field     avgt   15  0.799 ? 0.002  ns/op
>> # Arm Neoverse N1
>> EnumHashCode.constant  avgt   15  0.802 ? 0.002  ns/op
>> EnumHashCode.field     avgt   15  1.059 ? 0.056  ns/op
>> 
>> 
>> Using `-prof perfasm` on the benchmark, we can compare the generated code for x86_64:
>> 
>> Before:
>> 
>> ? 0x00007fae4868dd17:   lea    (%r12,%r10,8),%rsi           ;*getfield e {reexecute=0 rethrow=0 return_oop=0}
>> ?                                                           ; - org.sample.EnumHashCode::field at 1 (line 24)
>> ?                                                           ; - org.sample.jmh_generated.EnumHashCode_field_jmhTest::field_avgt_jmhStub at 17 (line 186)
>> ? 0x00007fae4868dd1b:   mov    (%rsi),%r10
>> ? 0x00007fae4868dd1e:   mov    %r10,%r11
>> ? 0x00007fae4868dd21:   and    $0x3,%r11
>> ? 0x00007fae4868dd25:   cmp    $0x1,%r11
>> ? 0x00007fae4868dd29:   jne    0x00007fae4868dcc6
>> ? 0x00007fae4868dd2b:   shr    $0x8,%r10
>> ? 0x00007fae4868dd2f:   mov    %r10d,%eax
>> ? 0x00007fae4868dd32:   and    $0x7fffffff,%eax
>> ? 0x00007fae4868dd37:   test   %eax,%eax
>> ? 0x00007fae4868dd39:   je     0x00007fae4868dcc6           ;*invokespecial hashCode {reexecute=0 rethrow=0 return_oop=0}
>> ?                                                           ; - java.lang.Enum::hashCode at 1 (line 175)
>> 
>> 
>> This is the normal Object.hashCode intrinsic, which involves reading the object header, extracting the hash code and handling two slow-path cases (displaced object header, hash not initialized).
>> 
>> After:
>> 
>> 
>>   ?  0x00007f550068e3b4:   mov    0x10(%r12,%r10,8),%r8d  <-- read the hash field
>>   ?  0x00007f550068e3b9:   test   %r8d,%r8d               <-- if (hash == 0)
>>   ?  0x00007f550068e3bc:   je     0x00007f550068e413      <-- slow init path, only taken on first use
>> 
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix two typos

src/java.base/share/classes/java/lang/Enum.java line 177:

> 175:      * HotSpot's identity hash code generation also never returns zero
> 176:      * as the identity hash code. This makes zero a convenient marker
> 177:      * for the un-initialized value for both {@link @Stable} and the lazy

I'm sorry, but `@Stable` won't work with `@link`. `@Stable` is not a class, interface, member name, etc. See https://docs.oracle.com/en/java/javase/20/docs/specs/javadoc/doc-comment-spec.html#references

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168783477

From rriggs at openjdk.org  Mon Apr 17 14:55:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Apr 2023 14:55:37 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v4]
In-Reply-To: <e8onn7g2EOBa0Y8o01DsOiyQ7vzVlrApOUaz6vef17s=.ed1003dd-0da3-4040-a1ed-3e570673a7d7@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <e8onn7g2EOBa0Y8o01DsOiyQ7vzVlrApOUaz6vef17s=.ed1003dd-0da3-4040-a1ed-3e570673a7d7@github.com>
Message-ID: <5BccwXOTQiZkdvImQ-eV0EUVXwADUbE9EQnXH_xSOi0=.124dee05-ef8f-4507-a807-5792275623fd@github.com>

On Mon, 17 Apr 2023 14:15:39 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075).
>> 
>> ### Benchmark
>> 
>> 
>> 
>> Before:
>> 
>> Benchmark              Mode  Cnt  Score   Error  Units
>> # Intel Cascade lake
>> EnumHashCode.constant  avgt   15  1.602 ? 0.011  ns/op
>> EnumHashCode.field     avgt   15  1.681 ? 0.014  ns/op
>> # Arm Neoverse N1
>> EnumHashCode.constant  avgt   15  1.642 ? 0.033  ns/op
>> EnumHashCode.field     avgt   15  1.717 ? 0.059  ns/op
>> 
>> 
>> 
>> After:
>> 
>> Benchmark              Mode  Cnt  Score   Error  Units
>> # Intel Cascade lake
>> EnumHashCode.constant  avgt   15  0.479 ? 0.001  ns/op
>> EnumHashCode.field     avgt   15  0.799 ? 0.002  ns/op
>> # Arm Neoverse N1
>> EnumHashCode.constant  avgt   15  0.802 ? 0.002  ns/op
>> EnumHashCode.field     avgt   15  1.059 ? 0.056  ns/op
>> 
>> 
>> Using `-prof perfasm` on the benchmark, we can compare the generated code for x86_64:
>> 
>> Before:
>> 
>> ? 0x00007fae4868dd17:   lea    (%r12,%r10,8),%rsi           ;*getfield e {reexecute=0 rethrow=0 return_oop=0}
>> ?                                                           ; - org.sample.EnumHashCode::field at 1 (line 24)
>> ?                                                           ; - org.sample.jmh_generated.EnumHashCode_field_jmhTest::field_avgt_jmhStub at 17 (line 186)
>> ? 0x00007fae4868dd1b:   mov    (%rsi),%r10
>> ? 0x00007fae4868dd1e:   mov    %r10,%r11
>> ? 0x00007fae4868dd21:   and    $0x3,%r11
>> ? 0x00007fae4868dd25:   cmp    $0x1,%r11
>> ? 0x00007fae4868dd29:   jne    0x00007fae4868dcc6
>> ? 0x00007fae4868dd2b:   shr    $0x8,%r10
>> ? 0x00007fae4868dd2f:   mov    %r10d,%eax
>> ? 0x00007fae4868dd32:   and    $0x7fffffff,%eax
>> ? 0x00007fae4868dd37:   test   %eax,%eax
>> ? 0x00007fae4868dd39:   je     0x00007fae4868dcc6           ;*invokespecial hashCode {reexecute=0 rethrow=0 return_oop=0}
>> ?                                                           ; - java.lang.Enum::hashCode at 1 (line 175)
>> 
>> 
>> This is the normal Object.hashCode intrinsic, which involves reading the object header, extracting the hash code and handling two slow-path cases (displaced object header, hash not initialized).
>> 
>> After:
>> 
>> 
>>   ?  0x00007f550068e3b4:   mov    0x10(%r12,%r10,8),%r8d  <-- read the hash field
>>   ?  0x00007f550068e3b9:   test   %r8d,%r8d               <-- if (hash == 0)
>>   ?  0x00007f550068e3bc:   je     0x00007f550068e413      <-- slow init path, only taken on first use
>> 
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix two typos

Can the detailed explanation be moved to a comment. The full description from the PR is included in every email and it makes it inconvenient to find the continuing comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1511522601

From prappo at openjdk.org  Mon Apr 17 14:59:36 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 17 Apr 2023 14:59:36 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v3]
In-Reply-To: <rH0yJmozlZzn7E3gQzHCjZfuYTdtdp8wkjJCoByhp-E=.dc94dfea-3b52-443c-8205-dc80f554dec9@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <jQWXWn_rma-JtYK5AlSO1W2CH8q9VAKK4DS0_Gqk26c=.428eadeb-f203-4e25-915a-a346befa3163@github.com>
 <_ddg8NNgXP2qnKZLqcf15YmiQCTgdcr1yY2P1OFJ6Ks=.d0ab6b0f-a6a5-441e-ba31-c05c8af3932f@github.com>
 <bN9YMQjWh24MhE17zbN1b1iSKW9VIiJ1u4xn7kV22mg=.0fa0d03a-6e5b-4a91-a0d6-f4f42de894f6@github.com>
 <RiA_-5Oc5KWMr0z1UaEWpEsCs4hNNht2Qk2WlYh0LO8=.f74431c1-9c9b-4395-9ddb-7c54912225a6@github.com>
 <rH0yJmozlZzn7E3gQzHCjZfuYTdtdp8wkjJCoByhp-E=.dc94dfea-3b52-443c-8205-dc80f554dec9@github.com>
Message-ID: <gFlr2HmIwD18o3-yGUY58Ez876tY4ap7-8AXm5_v3EU=.b6bd90a8-5f6d-4911-b0dd-5f1693df5df7@github.com>

On Mon, 17 Apr 2023 13:49:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> From that impl note it seemed like it was a big deal for hash code to never return 0 for an object. Could you maybe de-emphasize the importance of that HotSpot behavior in the note?
>
> All right, we can change "This allows to treat zero as the marker..." to "This makes zero a convenient marker...", I think?

To me, the proposed implementation looks similar to that of String::hashCode before Compact Strings (JEP 254).

The interesting detail here is the fact that unlike String::hashCode, which can legitimately return 0, Object::hashCode cannot, at least in HotSpot. This is great news, because to be performant, java.lang.Enum does not need to be bloated with extra mechanics, such as that boolean `hashIsZero` introduced for java.lang.String in 8221836: Avoid recalculating String.hash when zero.

If the essence of that can be compressed to a few simple sentences and possibly moved to an inline comment in Enum::hashCode, that _might_ be better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168853799

From rriggs at openjdk.org  Mon Apr 17 14:59:39 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Apr 2023 14:59:39 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v4]
In-Reply-To: <-21bRVESVZd_7-wRBjZtqTQzz3fNd6o0Nn03CBtW9rQ=.d382c9f4-01b7-40e6-af22-34ff186e1539@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <e8onn7g2EOBa0Y8o01DsOiyQ7vzVlrApOUaz6vef17s=.ed1003dd-0da3-4040-a1ed-3e570673a7d7@github.com>
 <-21bRVESVZd_7-wRBjZtqTQzz3fNd6o0Nn03CBtW9rQ=.d382c9f4-01b7-40e6-af22-34ff186e1539@github.com>
Message-ID: <h9g2ThCnsriuFWrBgqx5J6rRUFT_JB8z-oIsrLs9PRs=.570f2656-7f49-44c2-a57e-71f2a65548dc@github.com>

On Mon, 17 Apr 2023 14:23:01 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> olivergillespie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix two typos
>
> src/java.base/share/classes/java/lang/Enum.java line 177:
> 
>> 175:      * HotSpot's identity hash code generation also never returns zero
>> 176:      * as the identity hash code. This makes zero a convenient marker
>> 177:      * for the un-initialized value for both {@link @Stable} and the lazy
> 
> I'm sorry, but `@Stable` won't work with `@link`. `@Stable` is not a class, interface, member name, etc. See https://docs.oracle.com/en/java/javase/20/docs/specs/javadoc/doc-comment-spec.html#references

The @implNote is more appropriate for an internal comment. It is not needed to be in the published javadoc; its only useful to someone viewing the source code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168852243

From cstein at openjdk.org  Mon Apr 17 15:03:29 2023
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 17 Apr 2023 15:03:29 GMT
Subject: RFR: 8304896: Update to use jtreg 7.2
Message-ID: <SW7PTuDcEugo22nTk04k3aEL9Ineq5T25CRUnhDc7Vo=.0e4e96d2-f171-45c2-a4a7-5b83c3cdb548@github.com>

Please review the change to update to using jtreg 7.2.

The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

-------------

Commit messages:
 - JDK-8304896: Updated to use jtreg 7.2
 - JDK-8304896: Back to use build number 1
 - JDK-8304896: Use CI build number
 - JDK-8304896: Update to use jtreg 7.2

Changes: https://git.openjdk.org/jdk/pull/13496/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13496&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304896
  Stats: 9 lines in 8 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13496.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13496/head:pull/13496

PR: https://git.openjdk.org/jdk/pull/13496

From prappo at openjdk.org  Mon Apr 17 15:08:37 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 17 Apr 2023 15:08:37 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v4]
In-Reply-To: <h9g2ThCnsriuFWrBgqx5J6rRUFT_JB8z-oIsrLs9PRs=.570f2656-7f49-44c2-a57e-71f2a65548dc@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <e8onn7g2EOBa0Y8o01DsOiyQ7vzVlrApOUaz6vef17s=.ed1003dd-0da3-4040-a1ed-3e570673a7d7@github.com>
 <-21bRVESVZd_7-wRBjZtqTQzz3fNd6o0Nn03CBtW9rQ=.d382c9f4-01b7-40e6-af22-34ff186e1539@github.com>
 <h9g2ThCnsriuFWrBgqx5J6rRUFT_JB8z-oIsrLs9PRs=.570f2656-7f49-44c2-a57e-71f2a65548dc@github.com>
Message-ID: <JPQXCBzGMjqKfZrm1pw_wlJRk_-v7asJsLM7PcEJiz0=.417fc5da-ef96-4c0b-813e-7010fc7a02b4@github.com>

On Mon, 17 Apr 2023 14:56:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The @implNote is more appropriate for an internal comment. It is not needed to be in the published javadoc; its only useful to someone viewing the source code.

Is it a comment to me or to the author? If it's the former, then I note, that if one bothers to mark up a comment, that markup should be valid.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168866435

From rriggs at openjdk.org  Mon Apr 17 15:20:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Apr 2023 15:20:37 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v4]
In-Reply-To: <JPQXCBzGMjqKfZrm1pw_wlJRk_-v7asJsLM7PcEJiz0=.417fc5da-ef96-4c0b-813e-7010fc7a02b4@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <e8onn7g2EOBa0Y8o01DsOiyQ7vzVlrApOUaz6vef17s=.ed1003dd-0da3-4040-a1ed-3e570673a7d7@github.com>
 <-21bRVESVZd_7-wRBjZtqTQzz3fNd6o0Nn03CBtW9rQ=.d382c9f4-01b7-40e6-af22-34ff186e1539@github.com>
 <h9g2ThCnsriuFWrBgqx5J6rRUFT_JB8z-oIsrLs9PRs=.570f2656-7f49-44c2-a57e-71f2a65548dc@github.com>
 <JPQXCBzGMjqKfZrm1pw_wlJRk_-v7asJsLM7PcEJiz0=.417fc5da-ef96-4c0b-813e-7010fc7a02b4@github.com>
Message-ID: <wIE2H9DKi2sxb2n_bOMTBBCKlvk1SheU0uK2umZyj9U=.70da1834-9365-4fe5-aad1-a39faaac15e7@github.com>

On Mon, 17 Apr 2023 15:05:46 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> The @implNote is more appropriate for an internal comment. It is not needed to be in the published javadoc; its only useful to someone viewing the source code.
>
>> The @implNote is more appropriate for an internal comment. It is not needed to be in the published javadoc; its only useful to someone viewing the source code.
> 
> Is it a comment to me or to the author? If it's the former, then I note, that if one bothers to mark up a comment, that markup should be valid.

I would change this to be an non-javadoc comment.  (Change /** to /*)
An there is no need for javadoc \implNote or @link javadoc markup.
There is very little value in being able to generate javadoc for --private.
(In part because most private implementations are not documented to javadoc standards).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168885558

From rriggs at openjdk.org  Mon Apr 17 15:24:38 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Apr 2023 15:24:38 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v2]
In-Reply-To: <0tZH5cpkJrPjxa3UNQ3MC0LvRkFGIs2W5v21v4GS1pA=.1dd39ae4-d6cd-4356-a9cc-5b83832d4319@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
 <KR4jLIdgm_Y49RQkIJ9uNHqemm01aE81GRBVz6XznJ8=.c2e99c6d-2fb2-44ce-b23d-6461fac68ff4@github.com>
 <3Im4RP5-AmauuIjCVgA3V4h0HellqriqIlbTSjXjrWU=.a3b7c98f-276a-423a-8d48-c3415633b2cc@github.com>
 <_gJmYty5eyRbpGo3AIlFE4HDkmGWAWPsAOqwJri3mqo=.70b5927c-2be5-484c-98f4-f21933166c55@github.com>
 <8-pc62MG2Qcj0reM0zl85Kunw2rZlQOMVZHyjKKSSSY=.4af17266-9d26-42e3-a357-fcda22f1fd5b@github.com>
 <MGPD9mADC-45XPxBYAMM6nRIPJ3oKAwwPcOofSkzmiw=.b54f5929-1992-4089-9a6b-743bd2643a2d@github.com>
 <0tZH5cpkJrPjxa3UNQ3MC0LvRkFGIs2W5v21v4GS1pA=.1dd39ae4-d6cd-4356-a9cc-5b83832d4319@github.com>
Message-ID: <VENDtZkxIpFevgc-FaY3nL-RzOjyoo-ioPEfvLV_USw=.9e4beaae-ed0f-4015-9c37-023b19d09ac8@github.com>

On Sun, 16 Apr 2023 11:44:52 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Special casing for len == 0 and keeping the existing buf.insert for len == 1 would avoid object creation except when it would improve performance.
>
> @RogerRiggs sorry I don't get it. Maybe you mean speacial casing for `padWidth - len`?

Yes, I meant on the length of the inserted padding.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1168891583

From darcy at openjdk.org  Mon Apr 17 15:27:38 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 17 Apr 2023 15:27:38 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v7]
In-Reply-To: <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
Message-ID: <nY3pIlRP7j_X2SAVPtNTMffe0pB9RmEIejZq8oVlAL4=.accfe353-869f-412a-a4dc-a9dcd96bb832@github.com>

On Fri, 17 Mar 2023 15:38:49 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
>> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`.
>> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>>  
>> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
>> 
>>     ResolvedJavaMethod method = ...;
>>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>>     return switch (a.kind()) {
>>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The same code using the new API:
>> 
>> 
>>     ResolvedJavaMethod method = ...;
>>     ResolvedJavaType explodeLoopType = ...;
>>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>>     return switch (a.getEnum("kind").getName()) {
>>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [skip ci] formatting fixes

src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 184:

> 182: 
> 183:     /**
> 184:      * Parses {@code rawAnnotationBytes} into a list of {@link Annotation}s and then

Nit: the parameter is named "rawAnnotations" rather than "rawAnnotationBytes".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12810#discussion_r1168897797

From alanb at openjdk.org  Mon Apr 17 15:33:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Apr 2023 15:33:40 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v4]
In-Reply-To: <wIE2H9DKi2sxb2n_bOMTBBCKlvk1SheU0uK2umZyj9U=.70da1834-9365-4fe5-aad1-a39faaac15e7@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <e8onn7g2EOBa0Y8o01DsOiyQ7vzVlrApOUaz6vef17s=.ed1003dd-0da3-4040-a1ed-3e570673a7d7@github.com>
 <-21bRVESVZd_7-wRBjZtqTQzz3fNd6o0Nn03CBtW9rQ=.d382c9f4-01b7-40e6-af22-34ff186e1539@github.com>
 <h9g2ThCnsriuFWrBgqx5J6rRUFT_JB8z-oIsrLs9PRs=.570f2656-7f49-44c2-a57e-71f2a65548dc@github.com>
 <JPQXCBzGMjqKfZrm1pw_wlJRk_-v7asJsLM7PcEJiz0=.417fc5da-ef96-4c0b-813e-7010fc7a02b4@github.com>
 <wIE2H9DKi2sxb2n_bOMTBBCKlvk1SheU0uK2umZyj9U=.70da1834-9365-4fe5-aad1-a39faaac15e7@github.com>
Message-ID: <F-470N3LAd3d1jbnwpbXKTW25NTqskujMGP4MuVw1qM=.aab810c4-8f37-4843-a904-9dfeda18e60f@github.com>

On Mon, 17 Apr 2023 15:18:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> The @implNote is more appropriate for an internal comment. It is not needed to be in the published javadoc; its only useful to someone viewing the source code.
>> 
>> Is it a comment to me or to the author? If it's the former, then I note, that if one bothers to mark up a comment, that markup should be valid.
>
> I would change this to be an non-javadoc comment.  (Change /** to /*)
> An there is no need for javadoc \implNote or @link javadoc markup.
> There is very little value in being able to generate javadoc for --private.
> (In part because most private implementations are not documented to javadoc standards).

Yes, it is a bit strange to see @implNote here as this is a private field that isn't going to show up in the javadoc. The javadoc for non-transient fields in Serializable classes does show up in the Serialized Form page but this Enum which is special.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168909665

From bpb at openjdk.org  Mon Apr 17 15:33:41 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 17 Apr 2023 15:33:41 GMT
Subject: RFR: 8305762: FileInputStream and FileOutputStream implSpec should
 be corrected or removed [v2]
In-Reply-To: <RiMpoHIlzBMFEzGgQ3aD8V4HHmz2kDfNILvU8EEKwZw=.294739e7-80fc-4dc5-a9a7-d5d20445df03@github.com>
References: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
 <RiMpoHIlzBMFEzGgQ3aD8V4HHmz2kDfNILvU8EEKwZw=.294739e7-80fc-4dc5-a9a7-d5d20445df03@github.com>
Message-ID: <aZTd47vCSvYulkQdFsA4MyzAh9pSmuL4hrE_qSiGYAo=.50a3c9e9-d518-4f7b-8e34-a57232d0ab3f@github.com>

On Fri, 14 Apr 2023 22:27:26 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> With the removal of the AltFinalizer mechanism from `FileInputStream` and `FileOutputStream` in [JDK-8192939](https://bugs.openjdk.org/browse/JDK-8192939), this portion of the Implementation Requirement in the class JavaDoc is no longer true:
>> 
>>> If this FileOutputStream has been subclassed and the close() method has been overridden, the close() method will be called when the FileInputStream is unreachable."
>> 
>> The class doc, and the doc for close(), are updated to correctly reflect current behavior, and guidance for subclasses is clarified.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates, per review comments

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13437#pullrequestreview-1388404760

From darcy at openjdk.org  Mon Apr 17 15:35:38 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 17 Apr 2023 15:35:38 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v7]
In-Reply-To: <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
Message-ID: <Sb5jb5BTeWm7-9_PPHoykJMl2khf5TRo7ROYHqmVWnA=.c5098ecf-4e96-4934-84fa-c6df38eb6020@github.com>

On Fri, 17 Mar 2023 15:38:49 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
>> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`.
>> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>>  
>> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
>> 
>>     ResolvedJavaMethod method = ...;
>>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>>     return switch (a.kind()) {
>>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The same code using the new API:
>> 
>> 
>>     ResolvedJavaMethod method = ...;
>>     ResolvedJavaType explodeLoopType = ...;
>>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>>     return switch (a.getEnum("kind").getName()) {
>>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [skip ci] formatting fixes

src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 234:

> 232:      * Encodes a list of annotations to a byte array. The byte array can be decoded with {@link #decodeAnnotations(byte[], AnnotationDecoder)}.
> 233:      */
> 234:     public static byte[] encodeAnnotations(Collection<Annotation> annotations) {

I don't think it matters much in this use case, but it looks like  encodeAnnotations could be changed to take a List rather than a Collection, as the comment implies.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12810#discussion_r1168913137

From duke at openjdk.org  Mon Apr 17 15:44:34 2023
From: duke at openjdk.org (olivergillespie)
Date: Mon, 17 Apr 2023 15:44:34 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v4]
In-Reply-To: <F-470N3LAd3d1jbnwpbXKTW25NTqskujMGP4MuVw1qM=.aab810c4-8f37-4843-a904-9dfeda18e60f@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <e8onn7g2EOBa0Y8o01DsOiyQ7vzVlrApOUaz6vef17s=.ed1003dd-0da3-4040-a1ed-3e570673a7d7@github.com>
 <-21bRVESVZd_7-wRBjZtqTQzz3fNd6o0Nn03CBtW9rQ=.d382c9f4-01b7-40e6-af22-34ff186e1539@github.com>
 <h9g2ThCnsriuFWrBgqx5J6rRUFT_JB8z-oIsrLs9PRs=.570f2656-7f49-44c2-a57e-71f2a65548dc@github.com>
 <JPQXCBzGMjqKfZrm1pw_wlJRk_-v7asJsLM7PcEJiz0=.417fc5da-ef96-4c0b-813e-7010fc7a02b4@github.com>
 <wIE2H9DKi2sxb2n_bOMTBBCKlvk1SheU0uK2umZyj9U=.70da1834-9365-4fe5-aad1-a39faaac15e7@github.com>
 <F-470N3LAd3d1jbnwpbXKTW25NTqskujMGP4MuVw1qM=.aab810c4-8f37-4843-a904-9dfeda18e60f@github.com>
Message-ID: <TsWbBzcI0Lt9m7FK6MjMLC7UFCe_4_Y2VYLPhUDfY8g=.2aab1945-a098-4b3f-98d6-e0600aefa5b1@github.com>

On Mon, 17 Apr 2023 15:30:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I would change this to be an non-javadoc comment.  (Change /** to /*)
>> An there is no need for javadoc \implNote or @link javadoc markup.
>> There is very little value in being able to generate javadoc for --private.
>> (In part because most private implementations are not documented to javadoc standards).
>
> Yes, it is a bit strange to see @implNote here as this is a private field that isn't going to show up in the javadoc. The javadoc for non-transient fields in Serializable classes does show up in the Serialized Form page but this Enum which is special.

Thanks, so I'll switch to a `/*` comment with no markup?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168924827

From darcy at openjdk.org  Mon Apr 17 15:51:38 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 17 Apr 2023 15:51:38 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v7]
In-Reply-To: <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
Message-ID: <m8kK_v5yFY1wYK4rscLtNylg1lsHWXw9Et6hnuScNuI=.550fbccc-21f7-4ec8-87c6-6be3a828ccb1@github.com>

On Fri, 17 Mar 2023 15:38:49 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
>> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`.
>> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>>  
>> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
>> 
>>     ResolvedJavaMethod method = ...;
>>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>>     return switch (a.kind()) {
>>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The same code using the new API:
>> 
>> 
>>     ResolvedJavaMethod method = ...;
>>     ResolvedJavaType explodeLoopType = ...;
>>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>>     return switch (a.getEnum("kind").getName()) {
>>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [skip ci] formatting fixes

src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 419:

> 417:      * @param <X> type of the object representing a decoded error
> 418:      */
> 419:     public interface AnnotationDecoder<T, A, E, X> {

I think it would be better to include some bound on the type parameters to better capture their intention
A extends java.lang.Annotatoin
E extends java.lang.Enum
etc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12810#discussion_r1168933556

From duke at openjdk.org  Mon Apr 17 15:54:30 2023
From: duke at openjdk.org (olivergillespie)
Date: Mon, 17 Apr 2023 15:54:30 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v5]
In-Reply-To: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
Message-ID: <OfhyeBt_a1YtUR2Ju7cwWAQWpVRNPDLEv3PpmM8dnh4=.037b46c2-a348-49b4-8895-c6b51fe110c9@github.com>

> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
> 
> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075). [Benchmark results and generated code analysis moved to comment]
> 
> Thanks @shipilev for help with the implementation and interpreting the generated code.

olivergillespie has updated the pull request incrementally with one additional commit since the last revision:

  Switch to non-javadoc comment and remove markup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13491/files
  - new: https://git.openjdk.org/jdk/pull/13491/files/79af4952..f4b5c546

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13491&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13491&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13491/head:pull/13491

PR: https://git.openjdk.org/jdk/pull/13491

From duke at openjdk.org  Mon Apr 17 15:54:33 2023
From: duke at openjdk.org (olivergillespie)
Date: Mon, 17 Apr 2023 15:54:33 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v4]
In-Reply-To: <e8onn7g2EOBa0Y8o01DsOiyQ7vzVlrApOUaz6vef17s=.ed1003dd-0da3-4040-a1ed-3e570673a7d7@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <e8onn7g2EOBa0Y8o01DsOiyQ7vzVlrApOUaz6vef17s=.ed1003dd-0da3-4040-a1ed-3e570673a7d7@github.com>
Message-ID: <UZJS6cBQsV5jCJ-yf03YYVLRZ7bAGOeJbBcDWfT55pY=.87dae022-f7bd-4685-896a-435c690bcec4@github.com>

On Mon, 17 Apr 2023 14:15:39 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075). [Benchmark results and generated code analysis moved to comment]
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix two typos

(Moving benchmark results and generated code analysis here from PR description as requested.)

### Benchmark



Before:

Benchmark              Mode  Cnt  Score   Error  Units
# Intel Cascade lake
EnumHashCode.constant  avgt   15  1.602 ? 0.011  ns/op
EnumHashCode.field     avgt   15  1.681 ? 0.014  ns/op
# Arm Neoverse N1
EnumHashCode.constant  avgt   15  1.642 ? 0.033  ns/op
EnumHashCode.field     avgt   15  1.717 ? 0.059  ns/op



After:

Benchmark              Mode  Cnt  Score   Error  Units
# Intel Cascade lake
EnumHashCode.constant  avgt   15  0.479 ? 0.001  ns/op
EnumHashCode.field     avgt   15  0.799 ? 0.002  ns/op
# Arm Neoverse N1
EnumHashCode.constant  avgt   15  0.802 ? 0.002  ns/op
EnumHashCode.field     avgt   15  1.059 ? 0.056  ns/op


Using `-prof perfasm` on the benchmark, we can compare the generated code for x86_64:

Before:

? 0x00007fae4868dd17:   lea    (%r12,%r10,8),%rsi           ;*getfield e {reexecute=0 rethrow=0 return_oop=0}
?                                                           ; - org.sample.EnumHashCode::field at 1 (line 24)
?                                                           ; - org.sample.jmh_generated.EnumHashCode_field_jmhTest::field_avgt_jmhStub at 17 (line 186)
? 0x00007fae4868dd1b:   mov    (%rsi),%r10
? 0x00007fae4868dd1e:   mov    %r10,%r11
? 0x00007fae4868dd21:   and    $0x3,%r11
? 0x00007fae4868dd25:   cmp    $0x1,%r11
? 0x00007fae4868dd29:   jne    0x00007fae4868dcc6
? 0x00007fae4868dd2b:   shr    $0x8,%r10
? 0x00007fae4868dd2f:   mov    %r10d,%eax
? 0x00007fae4868dd32:   and    $0x7fffffff,%eax
? 0x00007fae4868dd37:   test   %eax,%eax
? 0x00007fae4868dd39:   je     0x00007fae4868dcc6           ;*invokespecial hashCode {reexecute=0 rethrow=0 return_oop=0}
?                                                           ; - java.lang.Enum::hashCode at 1 (line 175)


This is the normal Object.hashCode intrinsic, which involves reading the object header, extracting the hash code and handling two slow-path cases (displaced object header, hash not initialized).

After:


  ?  0x00007f550068e3b4:   mov    0x10(%r12,%r10,8),%r8d  <-- read the hash field
  ?  0x00007f550068e3b9:   test   %r8d,%r8d               <-- if (hash == 0)
  ?  0x00007f550068e3bc:   je     0x00007f550068e413      <-- slow init path, only taken on first use

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1511630835

From shade at openjdk.org  Mon Apr 17 15:58:38 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Apr 2023 15:58:38 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v5]
In-Reply-To: <OfhyeBt_a1YtUR2Ju7cwWAQWpVRNPDLEv3PpmM8dnh4=.037b46c2-a348-49b4-8895-c6b51fe110c9@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <OfhyeBt_a1YtUR2Ju7cwWAQWpVRNPDLEv3PpmM8dnh4=.037b46c2-a348-49b4-8895-c6b51fe110c9@github.com>
Message-ID: <AQz9J6NPgoMYFtuoAfUWj_uTVTbsRYYmcYuQ95Cnopc=.46689ccb-dfc4-4647-b6d7-cd7f7e8629b2@github.com>

On Mon, 17 Apr 2023 15:54:30 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075). [Benchmark results and generated code analysis moved to comment]
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Switch to non-javadoc comment and remove markup

src/java.base/share/classes/java/lang/Enum.java line 171:

> 169:     }
> 170: 
> 171:     /*

Should be `/**` (Javadoc style), like other `private` fields.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168948675

From erikj at openjdk.org  Mon Apr 17 16:04:33 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 17 Apr 2023 16:04:33 GMT
Subject: RFR: 8304896: Update to use jtreg 7.2
In-Reply-To: <SW7PTuDcEugo22nTk04k3aEL9Ineq5T25CRUnhDc7Vo=.0e4e96d2-f171-45c2-a4a7-5b83c3cdb548@github.com>
References: <SW7PTuDcEugo22nTk04k3aEL9Ineq5T25CRUnhDc7Vo=.0e4e96d2-f171-45c2-a4a7-5b83c3cdb548@github.com>
Message-ID: <eNqpTP44T5SFBQ8n_bn8IpMYIYesya4iBnvMo7wIGG8=.b55c915a-05b6-45e4-a3e6-741c211cf45d@github.com>

On Mon, 17 Apr 2023 14:56:16 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.2.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13496#pullrequestreview-1388478429

From prappo at openjdk.org  Mon Apr 17 16:07:38 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 17 Apr 2023 16:07:38 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v5]
In-Reply-To: <AQz9J6NPgoMYFtuoAfUWj_uTVTbsRYYmcYuQ95Cnopc=.46689ccb-dfc4-4647-b6d7-cd7f7e8629b2@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <OfhyeBt_a1YtUR2Ju7cwWAQWpVRNPDLEv3PpmM8dnh4=.037b46c2-a348-49b4-8895-c6b51fe110c9@github.com>
 <AQz9J6NPgoMYFtuoAfUWj_uTVTbsRYYmcYuQ95Cnopc=.46689ccb-dfc4-4647-b6d7-cd7f7e8629b2@github.com>
Message-ID: <YQto09pi9fi_TwpC5nELhenlrciWPEtT9vMNbmlkYiQ=.4561f631-0d9f-4aca-9343-d7ce5876325c@github.com>

On Mon, 17 Apr 2023 15:55:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> olivergillespie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Switch to non-javadoc comment and remove markup
>
> src/java.base/share/classes/java/lang/Enum.java line 171:
> 
>> 169:     }
>> 170: 
>> 171:     /*
> 
> Should be `/**` (Javadoc style), like other `private` fields.

I think the reviewers are fine with the essence of this PR. As for the comment, we could split it in two: the javadoc part, which stays with the field, and the inline part, which moves to the method. See String.hash and String::hashCode.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168963655

From shade at openjdk.org  Mon Apr 17 16:28:35 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Apr 2023 16:28:35 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v4]
In-Reply-To: <TsWbBzcI0Lt9m7FK6MjMLC7UFCe_4_Y2VYLPhUDfY8g=.2aab1945-a098-4b3f-98d6-e0600aefa5b1@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <e8onn7g2EOBa0Y8o01DsOiyQ7vzVlrApOUaz6vef17s=.ed1003dd-0da3-4040-a1ed-3e570673a7d7@github.com>
 <-21bRVESVZd_7-wRBjZtqTQzz3fNd6o0Nn03CBtW9rQ=.d382c9f4-01b7-40e6-af22-34ff186e1539@github.com>
 <h9g2ThCnsriuFWrBgqx5J6rRUFT_JB8z-oIsrLs9PRs=.570f2656-7f49-44c2-a57e-71f2a65548dc@github.com>
 <JPQXCBzGMjqKfZrm1pw_wlJRk_-v7asJsLM7PcEJiz0=.417fc5da-ef96-4c0b-813e-7010fc7a02b4@github.com>
 <wIE2H9DKi2sxb2n_bOMTBBCKlvk1SheU0uK2umZyj9U=.70da1834-9365-4fe5-aad1-a39faaac15e7@github.com>
 <F-470N3LAd3d1jbnwpbXKTW25NTqskujMGP4MuVw1qM=.aab810c4-8f37-4843-a904-9dfeda18e60f@github.com>
 <TsWbBzcI0Lt9m7FK6MjMLC7UFCe_4_Y2VYLPhUDfY8g=.2aab1945-a098-4b3f-98d6-e0600aefa5b1@github.com>
Message-ID: <yq666hFosN6jaAkOyC5M27ydOePrE5zhK0yLwZSExCE=.0d5fe9c9-0fc1-4040-b7b5-f82ab3bf6707@github.com>

On Mon, 17 Apr 2023 15:41:34 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Yes, it is a bit strange to see @implNote here as this is a private field that isn't going to show up in the javadoc. The javadoc for non-transient fields in Serializable classes does show up in the Serialized Form page but this Enum which is special.
>
> Thanks, so I'll switch to a `/*` comment with no markup?

No. Existing `private` fields, `name` and `ordinal` use Javadoc-style `/**` comment. New field should use `/**` to match the style. The only thing that we might want is to move implementation discussion into the method body, like this:


    /**
     * The hash code of this enumeration constant.
     */
    @Stable
    private int hash;

    /**
     * Returns a hash code for this enum constant.
     *
     * @return a hash code for this enum constant.
     */
    public final int hashCode() {
        // Once initialized, the hash field value does not change.
        // HotSpot's identity hash code generation also never returns zero
        // as the identity hash code. This makes zero a convenient marker
        // for the un-initialized value for both @Stable and the lazy
        // initialization code below.

        int hc = hash;
        if (hc == 0) {
            hc = hash = System.identityHashCode(this);
        }
        return hc;
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1168987865

From naoto at openjdk.org  Mon Apr 17 16:38:49 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Apr 2023 16:38:49 GMT
Subject: Integrated: 8296248: Update CLDR to Version 43.0
In-Reply-To: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
References: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
Message-ID: <02MVmGxQ0KhWjNsXuPHSABk-628O_YjPFPZM1i5eVt8=.3b8b07e2-81d3-4947-a11b-72a4b2bb65ef@github.com>

On Thu, 13 Apr 2023 20:20:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the CLDR to [version 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual release is their `limited-submission` release so I would not expect regressions caused by formatting changes as we had in JDK20/CLDRv42 (https://inside.java/2023/03/28/quality-heads-up/)

This pull request has now been integrated.

Changeset: 4ed933cf
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ed933cf774f8124b18ae68d0bf8cded9244a2e2
Stats:     209683 lines in 1037 files changed: 199352 ins; 2906 del; 7425 mod

8296248: Update CLDR to Version 43.0

Reviewed-by: joehw

-------------

PR: https://git.openjdk.org/jdk/pull/13469

From duke at openjdk.org  Mon Apr 17 16:42:38 2023
From: duke at openjdk.org (olivergillespie)
Date: Mon, 17 Apr 2023 16:42:38 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v6]
In-Reply-To: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
Message-ID: <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>

> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
> 
> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075). [Benchmark results and generated code analysis moved to comment]
> 
> Thanks @shipilev for help with the implementation and interpreting the generated code.

olivergillespie has updated the pull request incrementally with one additional commit since the last revision:

  Shuffle docs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13491/files
  - new: https://git.openjdk.org/jdk/pull/13491/files/f4b5c546..21882c10

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13491&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13491&range=04-05

  Stats: 12 lines in 1 file changed: 5 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13491/head:pull/13491

PR: https://git.openjdk.org/jdk/pull/13491

From shade at openjdk.org  Mon Apr 17 16:47:39 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Apr 2023 16:47:39 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v6]
In-Reply-To: <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
Message-ID: <CVfqwvrUrnZrRQMUbKIsS3dgTrrxyXqKq9yFPeJ97wA=.9f01b8c8-824f-4621-8f19-0724e7666ddb@github.com>

On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075). [Benchmark results and generated code analysis moved to comment]
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shuffle docs

I am okay with this new version, thanks. (You need other commenters to approve as well.)

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13491#pullrequestreview-1388555699

From rriggs at openjdk.org  Mon Apr 17 16:51:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Apr 2023 16:51:40 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v6]
In-Reply-To: <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
Message-ID: <wNHaPpJeX0v_ZZJA-1b1DT0TP42V3V_cryqvqUUTQbo=.e553c47f-f4bb-4be7-8a81-f23c2f714eb5@github.com>

On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075). [Benchmark results and generated code analysis moved to comment]
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shuffle docs

Thanks for moving the explanation to the method.  :)

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13491#pullrequestreview-1388563184

From prappo at openjdk.org  Mon Apr 17 16:51:43 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 17 Apr 2023 16:51:43 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v6]
In-Reply-To: <CVfqwvrUrnZrRQMUbKIsS3dgTrrxyXqKq9yFPeJ97wA=.9f01b8c8-824f-4621-8f19-0724e7666ddb@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
 <CVfqwvrUrnZrRQMUbKIsS3dgTrrxyXqKq9yFPeJ97wA=.9f01b8c8-824f-4621-8f19-0724e7666ddb@github.com>
Message-ID: <bGGeHBKOyetd7ag0GoPXqHN1kTKKgE6kLemG5jGaVz4=.bcb99d8c-c275-40a3-9605-68c69b32c15c@github.com>

On Mon, 17 Apr 2023 16:44:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am okay with this new version, thanks. (You need other commenters to approve as well.)

While there's already one more reviewer who approved this PR (@cl4es) and technically it can be already integrated, I'd leave it for a day or two so that other Reviewers could see it too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1511731776

From darcy at openjdk.org  Mon Apr 17 16:53:37 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 17 Apr 2023 16:53:37 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v7]
In-Reply-To: <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
Message-ID: <bMMKsW3chzWzfdCFNp-lLY6ur8yI39bUn_SmTOr_N1g=.c2e703d1-753f-4cfa-9687-02c4a1ad0f76@github.com>

On Fri, 17 Mar 2023 15:38:49 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
>> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`.
>> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>>  
>> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
>> 
>>     ResolvedJavaMethod method = ...;
>>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>>     return switch (a.kind()) {
>>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The same code using the new API:
>> 
>> 
>>     ResolvedJavaMethod method = ...;
>>     ResolvedJavaType explodeLoopType = ...;
>>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>>     return switch (a.getEnum("kind").getName()) {
>>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [skip ci] formatting fixes

A few higher-level comments:

>From the long-term perspective, it is likely that the set of kinds of elements that can occur in an annotation will be expanded, for example, method references are a repeated request. Easing future maintenance to gives more inter-source linkage in this situation and error handling for this case in the libgraal code would be prudent IMO.

The java.lang.reflect.AnnotatedElement API (https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/reflect/AnnotatedElement.html) defines different ways an annotation can be affiliated with an element:

"The terms directly present, indirectly present, present, and associated are used throughout this interface to describe precisely which annotations are returned by methods: "

tl;dr these terms relate to which of inheriting annotations and looking through repeated annotations the methods do on behalf of the caller. I think the methods should phrase their operations in terms of these concepts, such as "Construct the annotations present..." since inheritance is taken into account.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12810#issuecomment-1511735022

From alanb at openjdk.org  Mon Apr 17 17:07:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Apr 2023 17:07:36 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message [v5]
In-Reply-To: <A57pQYRbof1wEy9LObJ-1BRM78v10Ry96WcuXJK_bYw=.09ec7986-b535-43cf-9b55-273b4d7ab101@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
 <zmtUmRIk6ROWW5yKE021OHfxCVizgi2kx2I3Pz0Hzns=.388e4b99-ccdc-4ad5-b7c5-50a97e5a9b3f@github.com>
 <3OwgsaH4m-Py4V_0Naj7k6ZPYQP53ClfsL-2MdVW9v8=.fe1d81bd-89ee-49a8-9cd9-6df9d5971426@github.com>
 <RugWryBennaYioCZFHa9I0UJkvzojpPf2fhmNZk8EHU=.b402af07-8091-4c76-9943-9cd1d9c797ea@github.com>
 <TcJKmqDfL3XIOQERW340E6vyo6rEqFr9_vQOgew_1j8=.5bcbcbf4-42aa-4187-934f-6000912ad9d1@github.com>
 <A57pQYRbof1wEy9LObJ-1BRM78v10Ry96WcuXJK_bYw=.09ec7986-b535-43cf-9b55-273b4d7ab101@github.com>
Message-ID: <CytgRrv2y-J_ohhHwQtWlnh8G73QNcOVhnwt1Ku21F4=.38934b2d-bd79-442f-a7ac-d4caae18990c@github.com>

On Sun, 16 Apr 2023 10:27:07 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Okay, although I assume this test will fail if it throws a more general IOException (it's allowed to do that) or there is any adjustment to the error message.
>
> Yes, in the unlikely event that either  FileSystemException or  the code below from zipfs is changed, then yes the error message could evolve
> 
> 
> 
>             if (e.isDir())
>                 throw new FileSystemException(getString(path), null, "is a directory"); 
> 
> 
> I do not have a strong preference once way or the other and am happy to remove the message validation if that is what you prefer.  I kept the validation as the original issue was surrounding the actual message being generated which aligns with the text included by zipfs when it threw the exception when obtaining the inputstream
> 
> I think it is worth mentioning that we have other tests that also validate exception messages(and we recently updated a couple zip tests because the message changed).    So if we are going to move in the direction of not validating exception messages in tests, we should probably consider adding verbiage to the developers guide to provide that guidance and be consistent within the test suite
> 
> Let me know your preference and thank you for your thoughts as it is a useful discussion

What you have is fine, I'm just making the point that the exception message is somewhat secondary, the important test is that if FileSystemException is thrown then its getOtherFile return should null as there is only one file in this operation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13482#discussion_r1169034373

From rriggs at openjdk.org  Mon Apr 17 17:14:33 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Apr 2023 17:14:33 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v14]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <rkbmsfbX1jjvKtcTmVuQUY4kvXRQiHpOBNftKRLVKDs=.a3a45760-b38d-49bb-ba8f-e306ee0e2501@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  ArchTest on Debian RISC-V 64 confirmed by reviewer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/0cd6ce70..7094db61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=12-13

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

PR: https://git.openjdk.org/jdk/pull/13357

From stuart.marks at oracle.com  Mon Apr 17 17:18:20 2023
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 17 Apr 2023 10:18:20 -0700
Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
 insensitive alternative
In-Reply-To: <CAJL5A3noonJCRTxb8Xvh22EMV=N=M=LRQtne9wERfOLTa01pEw@mail.gmail.com>
References: <CAJL5A3mZBaGCpEDOadJwHuLBEnStXchhLNS=WJwtNkS4DZPiiQ@mail.gmail.com>
 <b59700b6-3949-f3b8-a2b1-074dbcf91b1e@oracle.com>
 <CAJL5A3mKDLWw4AeToiaKrjs2+50qTPJEDmOc8XuFCWYACbd0BQ@mail.gmail.com>
 <549e246f-eb19-8a6a-5e83-5b3c615e51ca@oracle.com>
 <CAJL5A3kxWKdoWHGL1k70Ae6ED+HTvRCmXXGxOMXvwQ_VBQMF1A@mail.gmail.com>
 <a6d6724f-13f4-c134-edd4-e147a5610517@oracle.com>
 <CAJL5A3=7T=L7n1MSneHc7cwA2LmhrMmhG2HQ42rF=JZ13EDxkw@mail.gmail.com>
 <fa44cb82-67f3-73af-881d-6994ccfd2e62@oracle.com>
 <CAJL5A3kNp5FoDf5Py7dQ=+oYtfw32FxFyzaWxsYyRJB9EgPr0Q@mail.gmail.com>
 <c566f8f6-6ff4-ae85-9159-bf883504ab9f@oracle.com>
 <CAJL5A3noonJCRTxb8Xvh22EMV=N=M=LRQtne9wERfOLTa01pEw@mail.gmail.com>
Message-ID: <18797f79-ba06-eb2f-66df-61a689a86ad0@oracle.com>


On 4/16/23 8:47 AM, Glavo wrote:
> I understand that Java 21 is around the corner and you have a lot of work to do, 
> so I'm sorry for taking up so much of your time.
> But for this issue, I think it really needs to be corrected. If new APIs cannot be 
> added in Java 21, it means that correcting these legacy issues in the community 
> will take at least two more years.
> I earnestly request that you pay more attention to this issue, and I am extremely 
> grateful.

There is a lot more to say about the technical issues, but I want to highlight the 
above. It indicates that you are trying to rush this change into JDK 21 because 
otherwise the solution will take two more years. This is a mistake. This is why we 
moved the JDK to six-month releases. Yes, I'm aware that JDK 21 is an Oracle LTS 
release. Rushing something into the next release because it's an LTS is a *bigger 
mistake.*

The reason that it's a mistake is that if you rush something in, and errors are 
discovered later, *other people will have to maintain it in perpetuity.*

Again, there are many other issues to discuss about this change, and in fact there 
are legitimate problems in this area that ought to be solved. However, I refuse to 
discuss them if it contributes to an immature change being rushed into JDK 21.

s'marks



From smarks at openjdk.org  Mon Apr 17 17:28:35 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 17 Apr 2023 17:28:35 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: <3RSsql8jL57BkpBbsDPG_WU9qtKi1vRkAwSk1X3D1KY=.13ae2a0f-8608-4d93-8d23-78eb2ec65fc9@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

The workaround mentioned in JDK-8230557 applies to `size()` and not `length()`. (But `length()` probably has similar behavior to `size()`.) Moreover, this is only a workaround, not an "accepted workaround" that code should be relying upon.

As @AlanBateman said, we probably need to revisit the specs and behaviors comprehensively at some point. This is mostly around behavior and handling of setting and getting the `Integer.MAX_VALUE` bit.

That said, it's probably possible to improve the behavior of `get(int, int)` by writing a new, internal method that inspects the object's state properly and acts on it, instead of relying on the current, bogus behavior of a public method.

There should also be a regression test for such a change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1511782837

From duke at openjdk.org  Mon Apr 17 17:31:41 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 17 Apr 2023 17:31:41 GMT
Subject: RFR: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message [v5]
In-Reply-To: <CytgRrv2y-J_ohhHwQtWlnh8G73QNcOVhnwt1Ku21F4=.38934b2d-bd79-442f-a7ac-d4caae18990c@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
 <zmtUmRIk6ROWW5yKE021OHfxCVizgi2kx2I3Pz0Hzns=.388e4b99-ccdc-4ad5-b7c5-50a97e5a9b3f@github.com>
 <3OwgsaH4m-Py4V_0Naj7k6ZPYQP53ClfsL-2MdVW9v8=.fe1d81bd-89ee-49a8-9cd9-6df9d5971426@github.com>
 <RugWryBennaYioCZFHa9I0UJkvzojpPf2fhmNZk8EHU=.b402af07-8091-4c76-9943-9cd1d9c797ea@github.com>
 <TcJKmqDfL3XIOQERW340E6vyo6rEqFr9_vQOgew_1j8=.5bcbcbf4-42aa-4187-934f-6000912ad9d1@github.com>
 <A57pQYRbof1wEy9LObJ-1BRM78v10Ry96WcuXJK_bYw=.09ec7986-b535-43cf-9b55-273b4d7ab101@github.com>
 <CytgRrv2y-J_ohhHwQtWlnh8G73QNcOVhnwt1Ku21F4=.38934b2d-bd79-442f-a7ac-d4caae18990c@github.com>
Message-ID: <xcDZrvcDWzfj3NF8u1cz1KzZ2CLJr1X3qFRrjgck4dA=.7845eac6-088e-484e-ada3-81b663ce94df@github.com>

On Mon, 17 Apr 2023 17:04:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> What you have is fine, I'm just making the point that the exception message is somewhat secondary

I guess this is also a question of testing the interface vs. testing the implementation.

To get good coverage of validation scenarios, I often find it quite useful to test on the actual message. This makes the test overspecific to the interface, but it helps make sure that each error condition is covered independently. Without asserting on the actual message, it can be hard to know if you are being shadowed by another higher level error condition. I've seen this a lot when adding test coverage for various ZIP processing code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13482#discussion_r1169058586

From rriggs at openjdk.org  Mon Apr 17 17:31:52 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Apr 2023 17:31:52 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v13]
In-Reply-To: <SjWFADdGRi3vkaTtNe8-fezznmFe2p4DsmMb1acXsCI=.9212dade-0358-4a00-bf42-9f94bdf54342@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
 <SjWFADdGRi3vkaTtNe8-fezznmFe2p4DsmMb1acXsCI=.9212dade-0358-4a00-bf42-9f94bdf54342@github.com>
Message-ID: <aBPpSZdnrmZifebNEszsNOJWU9A3eyLGqslSPdt8P5s=.911d9778-a8ec-4b1f-9f56-238e5e82839d@github.com>

On Sat, 15 Apr 2023 17:17:13 GMT, Glavo <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed isPPC64().
>>   Consolidated switch cases in ArchTest.
>>   Moved mapping of build TARGET_OS and TARGET_CPU to the build
>>   to avoid multiple mappings in more than one place.
>
> test/jdk/jdk/internal/util/ArchTest.java line 70:
> 
>> 68:             case "x86", "i386" -> X86;
>> 69:             case "aarch64" -> AARCH64;
>> 70:             case "riscv64" -> RISCV64;  // unverified
> 
> Suggestion:
> 
>             case "riscv64" -> RISCV64;

@Glavo Thanks for verifying.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1169059529

From rgiulietti at openjdk.org  Mon Apr 17 18:04:34 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 17 Apr 2023 18:04:34 GMT
Subject: RFR: 8132995: Matcher$ImmutableMatchResult should be optimized to
 reduce space usage
In-Reply-To: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
References: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
Message-ID: <NkQOLUyY50yCCy31D5FCdUtbCXJx6zc6HZAhxvJBKmA=.a229d721-d885-446f-9a25-9e6971dc69d2@github.com>

On Wed, 29 Mar 2023 18:09:22 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> When appropriate and useful, copies only the relevant portion of the `CharSequence` to the match result.

@stuart-marks As the reporter of the issue, would this interest you?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13231#issuecomment-1511841564

From bchristi at openjdk.org  Mon Apr 17 18:56:06 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 17 Apr 2023 18:56:06 GMT
Subject: RFR: 8305762: FileInputStream and FileOutputStream implSpec should
 be corrected or removed [v3]
In-Reply-To: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
References: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
Message-ID: <yZxBows1uAHLsB3QGuyFQuSCiAkb-ciEIJQ2E5wp--M=.7c81f06f-ba8e-4c16-bcf3-f7dba6d00fac@github.com>

> With the removal of the AltFinalizer mechanism from `FileInputStream` and `FileOutputStream` in [JDK-8192939](https://bugs.openjdk.org/browse/JDK-8192939), this portion of the Implementation Requirement in the class JavaDoc is no longer true:
> 
>> If this FileOutputStream has been subclassed and the close() method has been overridden, the close() method will be called when the FileInputStream is unreachable."
> 
> The class doc, and the doc for close(), are updated to correctly reflect current behavior, and guidance for subclasses is clarified.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  improve TWR phrasing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13437/files
  - new: https://git.openjdk.org/jdk/pull/13437/files/3adb17e2..8d8c35fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13437&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13437&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13437.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13437/head:pull/13437

PR: https://git.openjdk.org/jdk/pull/13437

From bchristi at openjdk.org  Mon Apr 17 18:56:09 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 17 Apr 2023 18:56:09 GMT
Subject: RFR: 8305762: FileInputStream and FileOutputStream implSpec should
 be corrected or removed [v2]
In-Reply-To: <S-X1H-7gQanksYDftQiZwLnrqE1UCqbiD3PIKEsssSg=.b076926d-841e-49fe-a995-940b2c60615c@github.com>
References: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
 <RiMpoHIlzBMFEzGgQ3aD8V4HHmz2kDfNILvU8EEKwZw=.294739e7-80fc-4dc5-a9a7-d5d20445df03@github.com>
 <S-X1H-7gQanksYDftQiZwLnrqE1UCqbiD3PIKEsssSg=.b076926d-841e-49fe-a995-940b2c60615c@github.com>
Message-ID: <uSnQLHFoWEiqNu8iAG3nJssdiYCxAgRgBJz2vhGn6XM=.56560ec9-b861-4729-80ec-f3c58deb5c7f@github.com>

On Sat, 15 Apr 2023 07:10:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates, per review comments
>
> src/java.base/share/classes/java/io/FileInputStream.java line 45:
> 
>> 43:  * @apiNote
>> 44:  * The {@link #close} method should be called to release resources used by this
>> 45:  * stream, either directly, or by try-with-resources.
> 
> The updated wording looks much better. It pre-dates your change but maybe "or by try-with-resources" should be changed to "with the {@code try}-with-resources statement" while you are there.

Good idea

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13437#discussion_r1169153013

From bpb at openjdk.org  Mon Apr 17 19:16:11 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 17 Apr 2023 19:16:11 GMT
Subject: RFR: 8305762: FileInputStream and FileOutputStream implSpec should
 be corrected or removed [v3]
In-Reply-To: <yZxBows1uAHLsB3QGuyFQuSCiAkb-ciEIJQ2E5wp--M=.7c81f06f-ba8e-4c16-bcf3-f7dba6d00fac@github.com>
References: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
 <yZxBows1uAHLsB3QGuyFQuSCiAkb-ciEIJQ2E5wp--M=.7c81f06f-ba8e-4c16-bcf3-f7dba6d00fac@github.com>
Message-ID: <LC3fyElOqHQ4vcOB_r8hjDq7u5CRmFEbjnbKsJybjQ8=.00d1b5af-1ab6-4338-9236-a5199d3ef514@github.com>

On Mon, 17 Apr 2023 18:56:06 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> With the removal of the AltFinalizer mechanism from `FileInputStream` and `FileOutputStream` in [JDK-8192939](https://bugs.openjdk.org/browse/JDK-8192939), this portion of the Implementation Requirement in the class JavaDoc is no longer true:
>> 
>>> If this FileOutputStream has been subclassed and the close() method has been overridden, the close() method will be called when the FileInputStream is unreachable."
>> 
>> The class doc, and the doc for close(), are updated to correctly reflect current behavior, and guidance for subclasses is clarified.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve TWR phrasing

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13437#pullrequestreview-1388799339

From alanb at openjdk.org  Mon Apr 17 19:38:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Apr 2023 19:38:50 GMT
Subject: RFR: 8305762: FileInputStream and FileOutputStream implSpec should
 be corrected or removed [v3]
In-Reply-To: <yZxBows1uAHLsB3QGuyFQuSCiAkb-ciEIJQ2E5wp--M=.7c81f06f-ba8e-4c16-bcf3-f7dba6d00fac@github.com>
References: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
 <yZxBows1uAHLsB3QGuyFQuSCiAkb-ciEIJQ2E5wp--M=.7c81f06f-ba8e-4c16-bcf3-f7dba6d00fac@github.com>
Message-ID: <40C4ApIxk95gDjoQYrSyuwrxi_iltemDrR_Nb1Ts0Yw=.b67a48fa-eff7-4d9c-9a39-21e4b4aa79d6@github.com>

On Mon, 17 Apr 2023 18:56:06 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> With the removal of the AltFinalizer mechanism from `FileInputStream` and `FileOutputStream` in [JDK-8192939](https://bugs.openjdk.org/browse/JDK-8192939), this portion of the Implementation Requirement in the class JavaDoc is no longer true:
>> 
>>> If this FileOutputStream has been subclassed and the close() method has been overridden, the close() method will be called when the FileInputStream is unreachable."
>> 
>> The class doc, and the doc for close(), are updated to correctly reflect current behavior, and guidance for subclasses is clarified.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve TWR phrasing

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13437#pullrequestreview-1388829949

From dnsimon at openjdk.org  Mon Apr 17 20:27:08 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 17 Apr 2023 20:27:08 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v7]
In-Reply-To: <m8kK_v5yFY1wYK4rscLtNylg1lsHWXw9Et6hnuScNuI=.550fbccc-21f7-4ec8-87c6-6be3a828ccb1@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
 <m8kK_v5yFY1wYK4rscLtNylg1lsHWXw9Et6hnuScNuI=.550fbccc-21f7-4ec8-87c6-6be3a828ccb1@github.com>
Message-ID: <fUqZmhZEdNzO86XMYfVu1aSfp3SWsr7VdSECkgYa74c=.007c6ccf-9811-4922-bdfa-801122e2c18f@github.com>

On Mon, 17 Apr 2023 15:48:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   [skip ci] formatting fixes
>
> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 419:
> 
>> 417:      * @param <X> type of the object representing a decoded error
>> 418:      */
>> 419:     public interface AnnotationDecoder<T, A, E, X> {
> 
> I think it would be better to include some bound on the type parameters to better capture their intention
> A extends java.lang.Annotatoin
> E extends java.lang.Enum
> etc.

These types are *alternatives* to `java.lang.Annotation`, `java.lang.Enum` etc. That's the primary motivation for this PR, i.e. to be able to represent annotations without having to reify them as `java.lang.Annotation` objects.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12810#discussion_r1169232602

From dnsimon at openjdk.org  Mon Apr 17 20:36:48 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 17 Apr 2023 20:36:48 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v7]
In-Reply-To: <Sb5jb5BTeWm7-9_PPHoykJMl2khf5TRo7ROYHqmVWnA=.c5098ecf-4e96-4934-84fa-c6df38eb6020@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
 <Sb5jb5BTeWm7-9_PPHoykJMl2khf5TRo7ROYHqmVWnA=.c5098ecf-4e96-4934-84fa-c6df38eb6020@github.com>
Message-ID: <SyueliXjJrqRY-z7qAK4emeA7GJufzvpS0OMD6FhwNg=.0443d63a-758b-4ecb-8569-f9895c7465ed@github.com>

On Mon, 17 Apr 2023 15:32:56 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   [skip ci] formatting fixes
>
> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 234:
> 
>> 232:      * Encodes a list of annotations to a byte array. The byte array can be decoded with {@link #decodeAnnotations(byte[], AnnotationDecoder)}.
>> 233:      */
>> 234:     public static byte[] encodeAnnotations(Collection<Annotation> annotations) {
> 
> I don't think it matters much in this use case, but it looks like  encodeAnnotations could be changed to take a List rather than a Collection, as the comment implies.

Just above (line 228) you can see a call to this method where the argument comes from `Map.values()` whose type is `Collection` so I'd prefer to leave it as is rather than have to convert the argument to a `List`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12810#discussion_r1169240341

From dnsimon at openjdk.org  Mon Apr 17 20:36:49 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 17 Apr 2023 20:36:49 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v7]
In-Reply-To: <SyueliXjJrqRY-z7qAK4emeA7GJufzvpS0OMD6FhwNg=.0443d63a-758b-4ecb-8569-f9895c7465ed@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
 <Sb5jb5BTeWm7-9_PPHoykJMl2khf5TRo7ROYHqmVWnA=.c5098ecf-4e96-4934-84fa-c6df38eb6020@github.com>
 <SyueliXjJrqRY-z7qAK4emeA7GJufzvpS0OMD6FhwNg=.0443d63a-758b-4ecb-8569-f9895c7465ed@github.com>
Message-ID: <wjApUHjLq5tUtsKuocpGAbWq7pWHkO3oOtKyRbio8-s=.8becaf8a-874c-4670-a457-c5bc029a1048@github.com>

On Mon, 17 Apr 2023 20:33:26 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 234:
>> 
>>> 232:      * Encodes a list of annotations to a byte array. The byte array can be decoded with {@link #decodeAnnotations(byte[], AnnotationDecoder)}.
>>> 233:      */
>>> 234:     public static byte[] encodeAnnotations(Collection<Annotation> annotations) {
>> 
>> I don't think it matters much in this use case, but it looks like  encodeAnnotations could be changed to take a List rather than a Collection, as the comment implies.
>
> Just above (line 228) you can see a call to this method where the argument comes from `Map.values()` whose type is `Collection` so I'd prefer to leave it as is rather than have to convert the argument to a `List`.

Just above (line 228) you can see a call to this method where the argument comes from `Map.values()` whose type is `Collection` so I'd prefer to leave it as is rather than have to convert the argument to a `List`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12810#discussion_r1169240392

From bchristi at openjdk.org  Mon Apr 17 20:43:51 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 17 Apr 2023 20:43:51 GMT
Subject: Integrated: 8305762: FileInputStream and FileOutputStream implSpec
 should be corrected or removed
In-Reply-To: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
References: <nnF8zHQ-7IBN5W4BESwYW7cuYZ1-wuBOGEoMG-ZYBqY=.9675609b-a7f4-4bdb-b354-1169f1e5c7cc@github.com>
Message-ID: <zJ52onoorTzm8BqoHnMZ8n6qNNbzII5dMEgmgdQGAWI=.1300172c-5dfc-4e6c-9172-f82b1a90c669@github.com>

On Tue, 11 Apr 2023 23:55:50 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> With the removal of the AltFinalizer mechanism from `FileInputStream` and `FileOutputStream` in [JDK-8192939](https://bugs.openjdk.org/browse/JDK-8192939), this portion of the Implementation Requirement in the class JavaDoc is no longer true:
> 
>> If this FileOutputStream has been subclassed and the close() method has been overridden, the close() method will be called when the FileInputStream is unreachable."
> 
> The class doc, and the doc for close(), are updated to correctly reflect current behavior, and guidance for subclasses is clarified.

This pull request has now been integrated.

Changeset: bb1a7bb3
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb1a7bb3e15096fbdb5d3cc28db09fd486a6ba03
Stats:     30 lines in 2 files changed: 0 ins; 12 del; 18 mod

8305762: FileInputStream and FileOutputStream implSpec should be corrected or removed

Reviewed-by: kbarrett, alanb, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/13437

From dnsimon at openjdk.org  Mon Apr 17 20:49:43 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 17 Apr 2023 20:49:43 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v7]
In-Reply-To: <bMMKsW3chzWzfdCFNp-lLY6ur8yI39bUn_SmTOr_N1g=.c2e703d1-753f-4cfa-9687-02c4a1ad0f76@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
 <bMMKsW3chzWzfdCFNp-lLY6ur8yI39bUn_SmTOr_N1g=.c2e703d1-753f-4cfa-9687-02c4a1ad0f76@github.com>
Message-ID: <Hh99vd9E7a3bLHZEjlhvJWp8cPpi2AyhsHksTqFYMjo=.7af759f2-0c37-40d6-909d-4bf8764003ec@github.com>

On Mon, 17 Apr 2023 16:50:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> From the long-term perspective, it is likely that the set of kinds of elements that can occur in an annotation will be expanded, for example, method references are a repeated request. Easing future maintenance to gives more inter-source linkage in this situation and error handling for this case in the libgraal code would be prudent IMO.

I'm not sure what you're suggesting in terms of how I should update this PR. Do you mean `AnnotationData.get` needs to somehow be more flexible? If so, could you please give a concrete example of what you're after.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12810#issuecomment-1512063544

From rriggs at openjdk.org  Mon Apr 17 20:59:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Apr 2023 20:59:06 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v15]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

Roger Riggs 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 8304915-arch-enum
 - ArchTest on Debian RISC-V 64 confirmed by reviewer
 - Fixed isPPC64().
   Consolidated switch cases in ArchTest.
   Moved mapping of build TARGET_OS and TARGET_CPU to the build
   to avoid multiple mappings in more than one place.
 - Correct mapping and test of ppc64
 - Add ppc64 as mapping to PPC64 Architecture
 - Modified test to check Architecture is64bits() and isLittleEndian()
   against Unsafe respective values.
   Relocated code mapping OS name and arch name from PlatformProps to
   OperatingSystem and Architecture. Kept the mapping of names
   in the template close to where the values are filled in by the build.
 - Remove unused static and import of Stabile
 - Rename OperatingSystemProps to PlatformProps.
   Refactor OperatingSystem initialization to use strings instead of integers.
 - Revised mapping mechanism of build target architecture names to enum values.
   Unrecognized values from the build are mapped to enum value "OTHER".
   Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
   Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
 - Revert changes to jdk.accessibility AccessBridge
 - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e

-------------

Changes: https://git.openjdk.org/jdk/pull/13357/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=14
  Stats: 410 lines in 7 files changed: 342 ins; 57 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

PR: https://git.openjdk.org/jdk/pull/13357

From dnsimon at openjdk.org  Mon Apr 17 21:02:50 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 17 Apr 2023 21:02:50 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v8]
In-Reply-To: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
Message-ID: <DhBfWHQ4yAaEfEPjptIRHeXoVdBUId7BIOGH73Pjq4A=.b5df001d-f0f4-4f5b-9843-ea08c3710ec2@github.com>

> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`.
> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>  
> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
> 
>     ResolvedJavaMethod method = ...;
>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>     return switch (a.kind()) {
>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The same code using the new API:
> 
> 
>     ResolvedJavaMethod method = ...;
>     ResolvedJavaType explodeLoopType = ...;
>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>     return switch (a.getEnum("kind").getName()) {
>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.

Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - rephrased javadoc Annotated to more precisely describe which annotations are returned
 - fixed comment
 - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8303431
 - [skip ci] formatting fixes
 - addressed review feedback
 - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8303431
 - switched to use of lists and maps instead of arrays
 - fixed whitespace
 - added support for inherited annotations
 - Merge branch 'master' into JDK-8303431
 - ... and 2 more: https://git.openjdk.org/jdk/compare/525a91e3...362738a6

-------------

Changes: https://git.openjdk.org/jdk/pull/12810/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=07
  Stats: 2319 lines in 34 files changed: 2268 ins; 23 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/12810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12810/head:pull/12810

PR: https://git.openjdk.org/jdk/pull/12810

From dnsimon at openjdk.org  Mon Apr 17 21:02:51 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 17 Apr 2023 21:02:51 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v7]
In-Reply-To: <bMMKsW3chzWzfdCFNp-lLY6ur8yI39bUn_SmTOr_N1g=.c2e703d1-753f-4cfa-9687-02c4a1ad0f76@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
 <bMMKsW3chzWzfdCFNp-lLY6ur8yI39bUn_SmTOr_N1g=.c2e703d1-753f-4cfa-9687-02c4a1ad0f76@github.com>
Message-ID: <rB8Iqlh6rAtjJ8BgnI3_MA_VZqAxIGKf78lwshod2ck=.f253e524-a2e4-4193-af5e-1f02f798e306@github.com>

On Mon, 17 Apr 2023 16:50:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> the methods should phrase their operations in terms of these concepts...

I think this is what you're suggesting: https://github.com/openjdk/jdk/pull/12810/commits/362738a61410cc8d60d8c4c4fc9e3e8ed0393aed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12810#issuecomment-1512074497

From mchung at openjdk.org  Mon Apr 17 21:07:44 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 17 Apr 2023 21:07:44 GMT
Subject: RFR: 8304932: MethodTypeDescImpl can be mutated by argument passed
 to MethodTypeDesc.of [v2]
In-Reply-To: <xrT2u2IywBEi6VgzUMg55wQg5ft3lhhsCn-EBipdzAI=.43c4bb6b-2836-4eff-a47a-9656b56cfedf@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
 <xrT2u2IywBEi6VgzUMg55wQg5ft3lhhsCn-EBipdzAI=.43c4bb6b-2836-4eff-a47a-9656b56cfedf@github.com>
Message-ID: <7MB6CjQvPYX-w0INtwXnuwCx4kgvbl9vmm0Rn4BdCpg=.c14e5843-e1bf-4e88-a1e6-9b4e03109067@github.com>

On Sun, 26 Mar 2023 20:45:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Fixed the bug where if a caller keeps a reference to the array passed into `MethodTypeDesc.of`, the caller may mutate the Desc via the array and can create invalid MethodTypeDesc.
>> 
>> Unfortunately, since the input array now needs to be copied, the `of` factory suffers from a performance drop. But otherwise, this patch has minor performance gains on `ofDescriptor` factory, even compared to Adam's patch that optimized `ofDescriptor` in #12945.
>> 
>> This patch moves the parameters to an immutable list, to avoid allocations on `parameterList` as well.
>> 
>> Benchmark of Oracle JDK 20: https://gist.github.com/683c6219e183cbc2b336224fc2c0d50a
>> Benchmark of this patch: https://gist.github.com/22be9371a2370fb4a7b44f1684750ec4
>> Benchmark of [asotona's patch](https://github.com/openjdk/jdk/pull/12945/files#diff-ac8e413d3e13532a2b0d34a90253c6ddd7a4f04082f792b9d076e9b5a33f2078): https://gist.github.com/eb98579c3b51cafae481049a95a78f80
>> 
>> [sotona vs this](https://jmh.morethan.io/?gists=eb98579c3b51cafae481049a95a78f80,22be9371a2370fb4a7b44f1684750ec4); [20 vs this](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,22be9371a2370fb4a7b44f1684750ec4); [20 vs sotona](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,eb98579c3b51cafae481049a95a78f80), for reference
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix some inconsistencies in the method descriptor derivation methods

Have you considered that the caller of instantiating `MethodTypeDescImpl` is responsible for passing a trusted array?  I think that `MethodTypeDescImpl` implementation already assumes it's a trusted array.  So `MethodTypeDesc::of` to call `new MethodTypeDescImpl` with a cloned array.   `MethodTypeDescImpl`  should call `new MethodTypeDescImpl`  instead of  `MethodTypeDesc::of` as this PR did. 

That way will avoid using `JavaUtilCollectionAccess` to create an immutable list without copying the input array.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13186#issuecomment-1512084178

From liach at openjdk.org  Mon Apr 17 21:12:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Apr 2023 21:12:42 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails
In-Reply-To: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
Message-ID: <tfpnNygzjd3Kr3_ctD7rc4bikx63yfjzIodkrm5I_3E=.fd9605d2-9bbe-451a-ba48-16a85ba97a43@github.com>

On Fri, 14 Apr 2023 14:02:46 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Classfile API didn't handle transformations of class files version 50 and below correctly. 
> 
> Proposed fix have two parts: 
> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
> 2. StackMapTable attribute is not generated for class file versions below 50.
> 
> StackMapsTest is also extended to test this patch.
> 
> Please review.
> 
> Thanks,
> Adam

Since this takes care of Java 6, what about versions before Java 5 that have jsr and ret, which are currently unsupported in the Classfile API? They are no longer supported due to introduction of stack map tables, but they can totally appear in older compiled try-finally statements.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13478#issuecomment-1512090693

From jvernee at openjdk.org  Mon Apr 17 21:18:46 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 17 Apr 2023 21:18:46 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v2]
In-Reply-To: <aJdN6W8q1Kd3yTWvy1qQhdjM2VY-Pogdxd5j8RXVK0M=.4afc1785-534c-4a97-8dcc-8950c7eb7d0c@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <OdBP0DSFX1Y18NpEX0a0_9fdfleDxScUck4SDzK4nQ8=.03aae349-dc2a-44fa-a74d-4b7a650f1cd2@github.com>
 <tKtmu72sFvYrxBq-qja07Jorm8YOKpnCTel3vEYZ7xM=.cf4d9ba3-42ac-4eff-9122-69cb9b6df6e1@github.com>
 <D14tz4RCkzTi8GtRWYqh7D78lDPhhTFUSbaptCismP8=.ff2e18c2-7a3f-4b28-b278-5cc0586a73cd@github.com>
 <aJdN6W8q1Kd3yTWvy1qQhdjM2VY-Pogdxd5j8RXVK0M=.4afc1785-534c-4a97-8dcc-8950c7eb7d0c@github.com>
Message-ID: <YAe6A3Ae_y1w7rxBzUTzgKapVaiRWxvOW-EShOZqLjw=.b8135bde-37d4-4504-b79e-90be50d7d20f@github.com>

On Mon, 17 Apr 2023 13:40:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > > Why isn't `Enum::hashCode` simply doing `return ordinal;`?
> > 
> > 
> > See https://bugs.openjdk.org/browse/JDK-8050217
> 
> Thanks! If there are apps where `Enum::hashCode` is performance sensitive then run-to-run stability may be a stronger argument than @stuart-marks et al argues it is here, though there might be some unspoken arguments about how it might affect iteration order et.c...

Identity hash code might theoretically be stable from run-to-run, but it's not like it's very stable in the first place. The hash code is generated using some thread-local state, so the value depends on how many times an identity hash code has been generated on the same thread before the hash code of the enum constant is generated (when `hashCode` is first called)

So, using ordinal as a hash code would, AFAICS, be no more unstable than the current implementation: if the code is altered (re-ordering the constants. Or calling hashCode for the first time at a different point in the application), the identity hash code can change. However, using the ordinal has the benefit of simplicity as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1512094546

From liach at openjdk.org  Mon Apr 17 21:24:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Apr 2023 21:24:42 GMT
Subject: RFR: 8304932: MethodTypeDescImpl can be mutated by argument passed
 to MethodTypeDesc.of [v2]
In-Reply-To: <7MB6CjQvPYX-w0INtwXnuwCx4kgvbl9vmm0Rn4BdCpg=.c14e5843-e1bf-4e88-a1e6-9b4e03109067@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
 <xrT2u2IywBEi6VgzUMg55wQg5ft3lhhsCn-EBipdzAI=.43c4bb6b-2836-4eff-a47a-9656b56cfedf@github.com>
 <7MB6CjQvPYX-w0INtwXnuwCx4kgvbl9vmm0Rn4BdCpg=.c14e5843-e1bf-4e88-a1e6-9b4e03109067@github.com>
Message-ID: <XC-FMse9CKtM7IY9gJ6dgB4jqJz5t8DoVC_EJ9KiIeo=.b485daff-9aca-4faf-a270-2580b0e7e96f@github.com>

On Mon, 17 Apr 2023 21:04:31 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Have you considered that the caller of instantiating `MethodTypeDescImpl` is responsible for passing a trusted array? I think that `MethodTypeDescImpl` implementation already assumes it's a trusted array. So `MethodTypeDesc::of` to call `new MethodTypeDescImpl` with a cloned array. `MethodTypeDescImpl` should call `new MethodTypeDescImpl` instead of `MethodTypeDesc::of` as this PR did.
> 
> That way will avoid using `JavaUtilCollectionAccess` to create an immutable list without copying the input array.

My plan was that `MethodType` will expose extra entry points:

static MethodTypeDesc of(ClassDesc returnType) {
    return of(returnType, List.of());
}

static MethodTypeDesc of(ClassDesc returnType, Collection<ClassDesc> paramTypes) {
    return of(returnType, List.copyOf(paramTypes));
}


The `Collection` version can avoid copying if the user-provided list is already a null-hostile immutable list. If this API is added, I can safely swap all existing `new MethodTypeDescImpl` with `MethodTypeDesc.of` without problems.

For the backing structure for parameters, I still believe an immutable list is better than an array; unlike MethodType that needs to interact with the VM which loves arrays better, MTD is mainly user-oriented and `parameterList` is often used by programmers. By avoiding list copies in `parameterList()` alone, I think there will be immediate benefit to users.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13186#issuecomment-1512102844

From lmesnik at openjdk.org  Mon Apr 17 21:43:43 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 17 Apr 2023 21:43:43 GMT
Subject: RFR: 8304896: Update to use jtreg 7.2
In-Reply-To: <SW7PTuDcEugo22nTk04k3aEL9Ineq5T25CRUnhDc7Vo=.0e4e96d2-f171-45c2-a4a7-5b83c3cdb548@github.com>
References: <SW7PTuDcEugo22nTk04k3aEL9Ineq5T25CRUnhDc7Vo=.0e4e96d2-f171-45c2-a4a7-5b83c3cdb548@github.com>
Message-ID: <j8-3yKM9OZSqbbqNxWLFCd2FJ6t6Tb40KwZp_Ud8Nt8=.41ccc847-e0e1-4948-b594-fb3ec9711a0b@github.com>

On Mon, 17 Apr 2023 14:56:16 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.2.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13496#pullrequestreview-1388984542

From iris at openjdk.org  Mon Apr 17 21:48:42 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 17 Apr 2023 21:48:42 GMT
Subject: RFR: 8304896: Update to use jtreg 7.2
In-Reply-To: <SW7PTuDcEugo22nTk04k3aEL9Ineq5T25CRUnhDc7Vo=.0e4e96d2-f171-45c2-a4a7-5b83c3cdb548@github.com>
References: <SW7PTuDcEugo22nTk04k3aEL9Ineq5T25CRUnhDc7Vo=.0e4e96d2-f171-45c2-a4a7-5b83c3cdb548@github.com>
Message-ID: <VsofabpFgQOto7PZ9sOlppNRV4n3yGX1eDPlj09P3cc=.7b499df8-738b-49a9-a2a3-63c055ef3617@github.com>

On Mon, 17 Apr 2023 14:56:16 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.2.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13496#pullrequestreview-1388989497

From jrose at openjdk.org  Mon Apr 17 23:41:47 2023
From: jrose at openjdk.org (John R Rose)
Date: Mon, 17 Apr 2023 23:41:47 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v6]
In-Reply-To: <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
Message-ID: <xnXHYmYhfDYnyQKjGVYedsTh6dWLSab2PLlta0QM9ic=.b2763d81-f01f-415a-a38b-6f0e8cf52632@github.com>

On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075). [Benchmark results and generated code analysis moved to comment]
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shuffle docs

I don?t have a strong objection to this, but I would like to say for the record that it is likely we will want to reconsider enums in a larger sense after Valhalla starts to ship.

Specifically, if an enum is represented as a value object, it should be represented as a single ordinal value after flattening.  This means both the old name and the new hash fields should not be present in a value-class version of an enum; they should be computed by using the ordinal as a key into some other table or algorithm.

In the long-running discussion about enum hash codes I added a comment here FTR:

https://bugs.openjdk.org/browse/JDK-8050217?focusedCommentId=14574367&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14574367

This sketches in more detail what I mean by deriving the hash from the ordinal and the class.  These suggestions may be of interest to people looking at this RFE.  But I am not suggesting a change to this RFE.

I do have one comment:  Since identity hash codes are typically reasonably well-conditioned, it is perfectly reasonable to recondition an occasional 0 by replacing it with 1, in order to store it in a stable variable for later reuse.  (Those hash codes are not so well-conditioned that that one tweak would cause quality tests to go from green to red; a test that could detect the tweak would already be red.)  But it?s also harmless to leave it as zero; it just means you will occasionally see a failure of constant folding.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1512238902

From smarks at openjdk.org  Mon Apr 17 23:53:00 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 17 Apr 2023 23:53:00 GMT
Subject: RFR: 8266571: Sequenced Collections [v5]
In-Reply-To: <Up2YjCsx6LbIR-APwjrCykNSeSk89mwhL45PRsN3fO8=.bd1cef22-13d0-4f0f-892f-60821b3642ef@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <bjHr9kQ6PfiSzt5IqgFWisQqzk_Jiawi5jGCDOKgeXI=.44293975-edcb-42de-99dd-9b7590b86914@github.com>
 <Up2YjCsx6LbIR-APwjrCykNSeSk89mwhL45PRsN3fO8=.bd1cef22-13d0-4f0f-892f-60821b3642ef@github.com>
Message-ID: <hu22iRzZn5CbJTRPWjXb5LZ4OufgHKaeDDOC5x_whyQ=.d049248c-08d7-4932-bdef-f1a56f6bb889@github.com>

On Tue, 28 Mar 2023 01:28:16 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/LinkedHashMap.java line 1123:
>> 
>>> 1121: 
>>> 1122:         public V put(K key, V value) {
>>> 1123:             return base.put(key, value);
>> 
>> Why `put()` simply delegates to `base.put()` while `putAll()` below does more complex containsKey-put-putFirst procedure? I think that `putAll()` should be equivalent to `for(var e : m.entrySet()) put(e.getKey(), e.getValue());`. Am I missing something?
>
> I think you're right, you're not missing anything. The entry that is put() should always go at the end of this view, and since this is the reversed view, it should go at the front of the base map. And putAll() should follow.

OK, it turns out that it was I who was missing something. My intent was that put() on the reversed view should go "at the end." But I implemented this only for putAll() and not for put() itself. However, revisiting this, I think my intent was wrong, and the implementation was doubly wrong, because it didn't even implement the (incorrect) intent correctly.

Elsewhere you had asked whether SequencedCollection.add should be specified to go "at the end" and I demurred. In fact I think the semantics of SequencedCollection.add and for SequencedMap.put should be to add the element or entry "at the right place." For List and Deque, the right place is the end. For NavigableSet/Map the right place is in the right sorting order. For LinkedHashSet/Map, the right place is either insertion order or access order. For an insertion-ordered map or set, the order is from oldest to newest, that is, from least to most recently inserted. Therefore, the reversed view should be in the _opposite_ order, from newest to oldest.

Therefore, my statement above "put() should always go at the end of this view" is wrong.

Adding an element to the backing map should go at the end, which is the front of the reversed view. Adding an element to the reversed view should also go at the end of the backing map but the front of the reversed view.

The fix is to take out the special-case of containsKey-put-putFirst from LinkedHashMap's reversed view and to take out similar logic from LinkedHashSet's reversed view. The methods should all just end up delegating to the backing map.

(It turns out that access-ordered maps already behave correctly; an access moves the entry to the end of a LHM and to the front of the reversed view, regardless of whether the access occurred via the backing map or the reversed view.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1169359933

From smarks at openjdk.org  Mon Apr 17 23:58:59 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 17 Apr 2023 23:58:59 GMT
Subject: RFR: 8266571: Sequenced Collections [v5]
In-Reply-To: <Sv4mNGSLotZhcgt77LThrPg_UyBEAGJ-A081HYQWlCw=.49b2a682-b6c4-4065-9f01-54dad3b8dbe7@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <bjHr9kQ6PfiSzt5IqgFWisQqzk_Jiawi5jGCDOKgeXI=.44293975-edcb-42de-99dd-9b7590b86914@github.com>
 <Sv4mNGSLotZhcgt77LThrPg_UyBEAGJ-A081HYQWlCw=.49b2a682-b6c4-4065-9f01-54dad3b8dbe7@github.com>
Message-ID: <fY-e0Z6tIA8QAR-Yv_SykPLU7M3XP_571Mfx66cwuDo=.723d7fd9-5282-444c-95a8-ffdd672b3c56@github.com>

On Thu, 30 Mar 2023 09:50:51 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/LinkedHashMap.java line 1197:
>> 
>>> 1195: 
>>> 1196:         public V computeIfAbsent(K key, Function<? super K, ? extends V> mappingFunction) {
>>> 1197:             return base.computeIfAbsent(key, mappingFunction);
>> 
>> Again, it's somewhat worrysome that methods like `computeIfAbsent` will actually add new nodes to the end of original LinkedHashMap instead of to the beginning. Probably not very big deal but looks inconsistent...
>
> Likely, for the first iteration it's possible to remove specializations for compute*/merge methods and use the default implementation from the `Map` interface, which will properly insert the new item to the beginning (if we properly implement reversed `put`). Later it could be optimized if necessary. What do you think?

Per my previous comment on put/putAll: if compute*/merge methods end up inserting a new entry, the entry should end up in the right place in insertion order (end of the backing map, or front of the reversed view) so all of these should be fine just delegating to the backing map.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1169362682

From smarks at openjdk.org  Tue Apr 18 00:04:01 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 18 Apr 2023 00:04:01 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: <XQrl8O2c4aNvXCac0lNsK1ee8BSL94-JbGmiGPVaniQ=.a6aefeb5-3828-4bc3-9bf9-99d93c2fc368@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <AVG0xaAX6FZuBx6zF9rv4HYkltv47a1-uGPJazz0avc=.b2c275f6-807b-4817-89b1-8fc3374de933@github.com>
 <XQrl8O2c4aNvXCac0lNsK1ee8BSL94-JbGmiGPVaniQ=.a6aefeb5-3828-4bc3-9bf9-99d93c2fc368@github.com>
Message-ID: <vAQbUvvZh6ONtJKcSF4P7vXYBhAZOQK991yq9NGNsmM=.cef0083d-213a-4f64-8ccc-be769a882b16@github.com>

On Sat, 25 Mar 2023 07:15:16 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - More specification tweaks.
>>  - Add simple overrides to ArrayList.
>
> src/java.base/share/classes/java/util/Collections.java line 1184:
> 
>> 1182: 
>> 1183:         @SuppressWarnings("unchecked")
>> 1184:         private SequencedCollection<E> rc() {
> 
> I suggest to use 'delegate' as name instead of 'rc' (no idea what 'rc' means)

"rc" stood for ReversibleCollection, which was the old name for SequencedCollection.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1169364573

From smarks at openjdk.org  Tue Apr 18 00:14:00 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 18 Apr 2023 00:14:00 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: <QzEjdyEzPzOPJq9Z01nsIcMDAIhzamM3wkHTdX8KTl4=.eb101a67-63dc-41ea-9e1d-709cf3366c98@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <AVG0xaAX6FZuBx6zF9rv4HYkltv47a1-uGPJazz0avc=.b2c275f6-807b-4817-89b1-8fc3374de933@github.com>
 <QzEjdyEzPzOPJq9Z01nsIcMDAIhzamM3wkHTdX8KTl4=.eb101a67-63dc-41ea-9e1d-709cf3366c98@github.com>
Message-ID: <D742G4K1KxNE0ouHOesM__NVeQu5I2N4Livom1Ym5Nc=.5c52077f-215a-4ec5-9356-7fbd85a20d92@github.com>

On Sat, 25 Mar 2023 07:28:46 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - More specification tweaks.
>>  - Add simple overrides to ArrayList.
>
> src/java.base/share/classes/java/util/LinkedList.java line 1293:
> 
>> 1291:     @SuppressWarnings("serial")
>> 1292:     static class ReverseOrderLinkedListView<E> extends LinkedList<E> implements java.io.Externalizable {
>> 1293:         final LinkedList<E> list;
> 
> Using 3 different fields feel ugly given it seems you only need one.
> Why do you not use the casting strategy you are using for the other views ?

The three fields are all instances of different classes.

> src/java.base/share/classes/java/util/List.java line 802:
> 
>> 800:      */
>> 801:     default E getFirst() {
>> 802:         if (this.isEmpty())
> 
> weirdly, sometimes you use braces around the ''if and sometimes you don't ?

Yes, some of the code here is badly formatted. Laziness on my part.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1169368443
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1169368619

From smarks at openjdk.org  Tue Apr 18 00:21:59 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 18 Apr 2023 00:21:59 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: <QzEjdyEzPzOPJq9Z01nsIcMDAIhzamM3wkHTdX8KTl4=.eb101a67-63dc-41ea-9e1d-709cf3366c98@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <AVG0xaAX6FZuBx6zF9rv4HYkltv47a1-uGPJazz0avc=.b2c275f6-807b-4817-89b1-8fc3374de933@github.com>
 <QzEjdyEzPzOPJq9Z01nsIcMDAIhzamM3wkHTdX8KTl4=.eb101a67-63dc-41ea-9e1d-709cf3366c98@github.com>
Message-ID: <tgCWG5Mw5t4xRTiTPWwyqF0firx05IK8pEP5-7ciFw0=.5c6e793f-f850-4990-870d-0aac2b7dee8e@github.com>

On Sat, 25 Mar 2023 07:34:51 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - More specification tweaks.
>>  - Add simple overrides to ArrayList.
>
> src/java.base/share/classes/java/util/ReverseOrderListView.java line 191:
> 
>> 189:         if (o == this)
>> 190:             return true;
>> 191:         if (!(o instanceof List))
> 
> should be `if (!(o instanceof List<?> list))`

This and similar code are copied from AbstractList. Instead of fiddling around with formatting, I will eventually refactor this into some common support class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1169371895

From smarks at openjdk.org  Tue Apr 18 00:41:00 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 18 Apr 2023 00:41:00 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <bvC1bZAPG4HVrez7a9gCe3IoStyBOsGFM1ZAMNTJ-kE=.96af85d9-7809-4dcf-b5ce-e3dc2278d413@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 <YkNylSy1A-OrfuTOhg_vCZrb3mDinwnTZ45kGUbtPIY=.2962cb0d-f8da-4a92-adaa-8f3fbd59ab41@github.com>
 <bvC1bZAPG4HVrez7a9gCe3IoStyBOsGFM1ZAMNTJ-kE=.96af85d9-7809-4dcf-b5ce-e3dc2278d413@github.com>
Message-ID: <XQLktuOLO91WIqGLdTyDTdqtB405K7-Dh8xG3E6ZGag=.1650fea8-1f5e-40a6-ae5d-c50b5651cbb0@github.com>

On Thu, 30 Mar 2023 11:33:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In the JEP:
>>> A sequenced collection supports common operations at either end, and it supports processing the elements from first to last and from last to first (i.e., forward and reverse).
>> 
>>> The reverse-ordered view enables all the different sequenced types to process elements in both directions, using all the usual iteration mechanisms: Enhanced for loops, explicit iterator() loops, forEach(), stream(), parallelStream(), and toArray().
>> 
>> This implies that for the reversed view, collection operations are not only supported, but can potentially be optimized. Our design should anticipate implementations of `SequencedCollection` to provide specific reversed implementations, like what we are already doing with `addAll` in ArrayList and ArrayDeque. If a collection cannot have efficient reverse-sequenced operations, it shouldn't be retrofitted into `SequencedCollection`, just like how we don't fit Deques into Lists.
>> 
>> Hence, I recommend:
>> 1. Declare `reversed()` and one of the (First/Last) operation sets (add|get|remove) `abstract`, and delegae the other set to default call the operation on the reversed instead. 
>>    - Since we tend to work with the end of collections, I'd declare the `Last` methods to be abstract and delegate the `First` default implementations to `this.reversed().xxxLast()`
>> 2. I don't think leaving `addLast()` implemented by default is a good idea, for modifiable implementations cannot discover that they missed the `addLast()` at compile time and can only discover when the implementation is actually used.
>> 3. In the default `reversed()` implementation of `List` and `Deque`, add API notes to indicate to implementations opportunities to optimize the implementation, especially batch operations like `addAll` when the base implementation offers such an optimization.
>
>> @liach
>> 
>> I understand that you're suggesting adding various default implementations in order to make it easier for people to bring up implementations of SequencedCollections. However, adding default implementations to SequencedCollection itself is unlikely to help. I expect that most implementations will override both addFirst and addLast. Requiring overriding of only one of them will hardly help anything, because the more difficult task is implementing the reverse-ordered view. I'd prefer to concentrate on some kind of implementation assistance for doing that. For example, there could be an "AbstractSequencedCollection" that would require overriding only a couple methods, rather like `AbstractCollection`. I'm a bit reluctant to introduce new abstract classes into the public API though. An alternative might be to have some kind of static factory method that takes something like a Collection and a reverse iterator and returns a SequencedCollection.
>> 
>> It's not clear to me that such support is necessary. It's pretty easy to bring up a List using AbstractList, and a List is a SequencedCollection. But if we do add something, it should be driven by use cases, and not speculation.
> 
> Then shouldn't we leave all methods in SewuencedCollection abstract as users almost always override them?

@liach 

> Then shouldn't we leave all methods in SequencedCollection abstract as users almost always override them?

No. The getX and removeX default methods are built on iterators, upon which a full collection implementation can be built. See AbstractCollection. If you have a reversed iterator, you can build a reversed view from that, and you're done. In fact these default methods are used by the sequenced view collections of SequencedMap.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1512279356

From darcy at openjdk.org  Tue Apr 18 01:09:56 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Apr 2023 01:09:56 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v7]
In-Reply-To: <wjApUHjLq5tUtsKuocpGAbWq7pWHkO3oOtKyRbio8-s=.8becaf8a-874c-4670-a457-c5bc029a1048@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
 <Sb5jb5BTeWm7-9_PPHoykJMl2khf5TRo7ROYHqmVWnA=.c5098ecf-4e96-4934-84fa-c6df38eb6020@github.com>
 <SyueliXjJrqRY-z7qAK4emeA7GJufzvpS0OMD6FhwNg=.0443d63a-758b-4ecb-8569-f9895c7465ed@github.com>
 <wjApUHjLq5tUtsKuocpGAbWq7pWHkO3oOtKyRbio8-s=.8becaf8a-874c-4670-a457-c5bc029a1048@github.com>
Message-ID: <NdwkkW2nGAUqZlwFuMadYV07DLFRKnVLAi0ZchHK3lQ=.17314777-9000-4768-a3a8-6a254953636b@github.com>

On Mon, 17 Apr 2023 20:33:30 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 234:
>> 
>>> 232:      * Encodes a list of annotations to a byte array. The byte array can be decoded with {@link #decodeAnnotations(byte[], AnnotationDecoder)}.
>>> 233:      */
>>> 234:     public static byte[] encodeAnnotations(Collection<Annotation> annotations) {
>> 
>> I don't think it matters much in this use case, but it looks like  encodeAnnotations could be changed to take a List rather than a Collection, as the comment implies.
>
> Just above (line 228) you can see a call to this method where the argument comes from `Map.values()` whose type is `Collection` so I'd prefer to leave it as is rather than have to convert the argument to a `List`.

In that case, I think the comment on line 232 should be updated to not say "list".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12810#discussion_r1169391239

From darcy at openjdk.org  Tue Apr 18 02:24:53 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Apr 2023 02:24:53 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v7]
In-Reply-To: <Hh99vd9E7a3bLHZEjlhvJWp8cPpi2AyhsHksTqFYMjo=.7af759f2-0c37-40d6-909d-4bf8764003ec@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
 <bMMKsW3chzWzfdCFNp-lLY6ur8yI39bUn_SmTOr_N1g=.c2e703d1-753f-4cfa-9687-02c4a1ad0f76@github.com>
 <Hh99vd9E7a3bLHZEjlhvJWp8cPpi2AyhsHksTqFYMjo=.7af759f2-0c37-40d6-909d-4bf8764003ec@github.com>
Message-ID: <kEd4U82PMT5F6CHF2aRoSwkUPif2OMsOK44UfdwdXIg=.c3107bb3-ce1a-40d3-8bf4-66498d6ab058@github.com>

On Mon, 17 Apr 2023 20:46:36 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> > From the long-term perspective, it is likely that the set of kinds of elements that can occur in an annotation will be expanded, for example, method references are a repeated request. Easing future maintenance to gives more inter-source linkage in this situation and error handling for this case in the libgraal code would be prudent IMO.
> 
> I'm not sure what you're suggesting in terms of how I should update this PR. Do you mean `AnnotationData.get` needs to somehow be more flexible? If so, could you please give a concrete example of what you're after.

Let me explain my concerns in more detail.

We have (at least) two separate annotations implementations in the JDK, one in javac for compile-time and other in core reflection for runtime. Due to various technical constraints, the implementations are necessarily separate (although the annotation objects constructed by javac do also implement the java.lang.annotation.Annotation interface also used by core reflection).

This work is proposing to add another partial implementation to satisfy other technical goals, reusing portions of the existing core reflection machinery.

If at some point the universe of objects that can be encoded as annotation is expanded, e..g method literals as mentioned previously, it is well-understood that core reflection and javac will need to be updated. I think it would be relatively easy to overlook the need to make corresponding updates to libgraal API and all regression tests might still pass.

As a concrete suggestion, if such an unknown annotation was handed over to libgraal, I think the code should reject it (AssertionError("unexpected annotation component") etc.) in hope of the omission getting corrected sooner. Also, leaving some bread crumb comments to future maintainers of core reflection annotations in that implementation package would be helpful too, e.g. "// used by libgraal".

HTH

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12810#issuecomment-1512343062

From duke at openjdk.org  Tue Apr 18 04:52:45 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 18 Apr 2023 04:52:45 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v3]
In-Reply-To: <_ddg8NNgXP2qnKZLqcf15YmiQCTgdcr1yY2P1OFJ6Ks=.d0ab6b0f-a6a5-441e-ba31-c05c8af3932f@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <jQWXWn_rma-JtYK5AlSO1W2CH8q9VAKK4DS0_Gqk26c=.428eadeb-f203-4e25-915a-a346befa3163@github.com>
 <_ddg8NNgXP2qnKZLqcf15YmiQCTgdcr1yY2P1OFJ6Ks=.d0ab6b0f-a6a5-441e-ba31-c05c8af3932f@github.com>
Message-ID: <AfKZDBfg4SEXoVvC2vso3vVi9LryRJZOU74lO8K7al8=.a2148933-faaa-43cb-9be5-3c6e5c4a62a8@github.com>

On Mon, 17 Apr 2023 13:00:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Enum.java line 191:
>> 
>>> 189:         int hc = hash;
>>> 190:         if (hc == 0) {
>>> 191:             hc = hash = System.identityHashCode(this);
>> 
>> Why not `hc = hash = super.hashCode()`?
>
> Saves the virtual call, makes for a simpler intrinsic path (no need to handle NPE and fold away, for example), since we know the super-class is already `java.lang.Object`. Unless I miss something else here...

Shouldn?t?`invokespecial` produce a?non?virtual?call as?well?

And?`this`/`super` can?never be?`null`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1169484780

From dnsimon at openjdk.org  Tue Apr 18 07:03:45 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 18 Apr 2023 07:03:45 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v7]
In-Reply-To: <NdwkkW2nGAUqZlwFuMadYV07DLFRKnVLAi0ZchHK3lQ=.17314777-9000-4768-a3a8-6a254953636b@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
 <Sb5jb5BTeWm7-9_PPHoykJMl2khf5TRo7ROYHqmVWnA=.c5098ecf-4e96-4934-84fa-c6df38eb6020@github.com>
 <SyueliXjJrqRY-z7qAK4emeA7GJufzvpS0OMD6FhwNg=.0443d63a-758b-4ecb-8569-f9895c7465ed@github.com>
 <wjApUHjLq5tUtsKuocpGAbWq7pWHkO3oOtKyRbio8-s=.8becaf8a-874c-4670-a457-c5bc029a1048@github.com>
 <NdwkkW2nGAUqZlwFuMadYV07DLFRKnVLAi0ZchHK3lQ=.17314777-9000-4768-a3a8-6a254953636b@github.com>
Message-ID: <p9aw51I2D5YZZXva3ohZTrTTSUIXhNTikaBpIoq1njk=.d03cff7e-94c6-4c90-b27c-0bb7b15cc438@github.com>

On Tue, 18 Apr 2023 01:06:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Just above (line 228) you can see a call to this method where the argument comes from `Map.values()` whose type is `Collection` so I'd prefer to leave it as is rather than have to convert the argument to a `List`.
>
> In that case, I think the comment on line 232 should be updated to not say "list".

I changed the comment to "Encodes annotations to a byte array."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12810#discussion_r1169582963

From dnsimon at openjdk.org  Tue Apr 18 07:27:47 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 18 Apr 2023 07:27:47 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v9]
In-Reply-To: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
Message-ID: <tSOY4bLeZKlucGnZHlKrhI0z9fUwSva5UyGrRAlp_4M=.ce362a15-9aa0-4f19-9f80-4a9ecb9794cd@github.com>

> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`.
> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>  
> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
> 
>     ResolvedJavaMethod method = ...;
>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>     return switch (a.kind()) {
>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The same code using the new API:
> 
> 
>     ResolvedJavaMethod method = ...;
>     ResolvedJavaType explodeLoopType = ...;
>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>     return switch (a.getEnum("kind").getName()) {
>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.

Doug Simon has updated the pull request incrementally with two additional commits since the last revision:

 - added breadcrumb in AnnotationParser about considering JVMCI should new annotation element types be added
 - fixed javadoc comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12810/files
  - new: https://git.openjdk.org/jdk/pull/12810/files/362738a6..bad23a0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=07-08

  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12810/head:pull/12810

PR: https://git.openjdk.org/jdk/pull/12810

From dnsimon at openjdk.org  Tue Apr 18 07:27:49 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 18 Apr 2023 07:27:49 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v7]
In-Reply-To: <kEd4U82PMT5F6CHF2aRoSwkUPif2OMsOK44UfdwdXIg=.c3107bb3-ce1a-40d3-8bf4-66498d6ab058@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>
 <bMMKsW3chzWzfdCFNp-lLY6ur8yI39bUn_SmTOr_N1g=.c2e703d1-753f-4cfa-9687-02c4a1ad0f76@github.com>
 <Hh99vd9E7a3bLHZEjlhvJWp8cPpi2AyhsHksTqFYMjo=.7af759f2-0c37-40d6-909d-4bf8764003ec@github.com>
 <kEd4U82PMT5F6CHF2aRoSwkUPif2OMsOK44UfdwdXIg=.c3107bb3-ce1a-40d3-8bf4-66498d6ab058@github.com>
Message-ID: <RVPuKWknntZH2VH2HRp--S5i9kpYUw4z9HP3BjwKm8k=.b13da661-6410-4ea7-a695-d72ea397d650@github.com>

On Tue, 18 Apr 2023 02:22:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I think the code should reject it

The `AnnotationData` constructor already has a check for unknown annotation element types so I think this concern is covered.

> leaving some bread crumb comments to future maintainers of core reflection annotations

Done here: https://github.com/openjdk/jdk/pull/12810/commits/bad23a0c90743f7568c3b8ed5b57350e62503dcf

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12810#issuecomment-1512577686

From asotona at openjdk.org  Tue Apr 18 08:38:46 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 18 Apr 2023 08:38:46 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails
In-Reply-To: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
Message-ID: <qkWfAcKpiVY_GGt0t3mD57PoKnNDuWA9C5CNR40-gow=.462a0b40-d97c-464e-bf7e-9b5cf370bb25@github.com>

On Fri, 14 Apr 2023 14:02:46 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Classfile API didn't handle transformations of class files version 50 and below correctly. 
> 
> Proposed fix have two parts: 
> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
> 2. StackMapTable attribute is not generated for class file versions below 50.
> 
> StackMapsTest is also extended to test this patch.
> 
> Please review.
> 
> Thanks,
> Adam

Absence of support for jsr and ret is very important point and it is necessary to re-evaluate the fix completely.
Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13478#issuecomment-1512683242

From shade at openjdk.org  Tue Apr 18 08:39:46 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Apr 2023 08:39:46 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v6]
In-Reply-To: <xnXHYmYhfDYnyQKjGVYedsTh6dWLSab2PLlta0QM9ic=.b2763d81-f01f-415a-a38b-6f0e8cf52632@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
 <xnXHYmYhfDYnyQKjGVYedsTh6dWLSab2PLlta0QM9ic=.b2763d81-f01f-415a-a38b-6f0e8cf52632@github.com>
Message-ID: <z5mT7wYOau7pxOgA4R81Gc6d3IDDt26pAnvB11Gs_uc=.8937529a-8821-4c84-8656-8751bb9dfebe@github.com>

On Mon, 17 Apr 2023 23:38:31 GMT, John R Rose <jrose at openjdk.org> wrote:

> I do have one comment: Since identity hash codes are typically reasonably well-conditioned, it is perfectly reasonable to recondition an occasional 0 by replacing it with 1, in order to store it in a stable variable for later reuse.

As comment in the code change says, this is already handled on Hotspot side: https://github.com/openjdk/jdk/blob/cc60f2ff3f16bdb04917e09cb87f09bd544f1f8b/src/hotspot/share/runtime/synchronizer.cpp#L826-L827 -- if only to disambiguate the "unset" IHC in the object header. So the stars have already aligned well for us to use `0` as uninitialized marker!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1512684621

From shade at openjdk.org  Tue Apr 18 08:39:49 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Apr 2023 08:39:49 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v3]
In-Reply-To: <AfKZDBfg4SEXoVvC2vso3vVi9LryRJZOU74lO8K7al8=.a2148933-faaa-43cb-9be5-3c6e5c4a62a8@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <jQWXWn_rma-JtYK5AlSO1W2CH8q9VAKK4DS0_Gqk26c=.428eadeb-f203-4e25-915a-a346befa3163@github.com>
 <_ddg8NNgXP2qnKZLqcf15YmiQCTgdcr1yY2P1OFJ6Ks=.d0ab6b0f-a6a5-441e-ba31-c05c8af3932f@github.com>
 <AfKZDBfg4SEXoVvC2vso3vVi9LryRJZOU74lO8K7al8=.a2148933-faaa-43cb-9be5-3c6e5c4a62a8@github.com>
Message-ID: <RWHWJNE1Sw44eqSYc5y9oJL5U4GHEKcgIDgyRyBZzXE=.9ae79ef5-a564-4e06-b931-97982ec1a77e@github.com>

On Tue, 18 Apr 2023 04:49:46 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Saves the virtual call, makes for a simpler intrinsic path (no need to handle NPE and fold away, for example), since we know the super-class is already `java.lang.Object`. Unless I miss something else here...
>
> Shouldn?t?`invokespecial` produce a?non?virtual?call as?well?
> 
> And?`this`/`super` can?never be?`null`.

`super.hashCode()` is a virtual call. `System.identityHashCode` is the static call. I don't understand where `invokespecial` enters the picture here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1169690617

From shade at openjdk.org  Tue Apr 18 09:05:50 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Apr 2023 09:05:50 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v2]
In-Reply-To: <YAe6A3Ae_y1w7rxBzUTzgKapVaiRWxvOW-EShOZqLjw=.b8135bde-37d4-4504-b79e-90be50d7d20f@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <OdBP0DSFX1Y18NpEX0a0_9fdfleDxScUck4SDzK4nQ8=.03aae349-dc2a-44fa-a74d-4b7a650f1cd2@github.com>
 <tKtmu72sFvYrxBq-qja07Jorm8YOKpnCTel3vEYZ7xM=.cf4d9ba3-42ac-4eff-9122-69cb9b6df6e1@github.com>
 <D14tz4RCkzTi8GtRWYqh7D78lDPhhTFUSbaptCismP8=.ff2e18c2-7a3f-4b28-b278-5cc0586a73cd@github.com>
 <aJdN6W8q1Kd3yTWvy1qQhdjM2VY-Pogdxd5j8RXVK0M=.4afc1785-534c-4a97-8dcc-8950c7eb7d0c@github.com>
 <YAe6A3Ae_y1w7rxBzUTzgKapVaiRWxvOW-EShOZqLjw=.b8135bde-37d4-4504-b79e-90be50d7d20f@github.com>
Message-ID: <CFFaGDZ-RaRqCt_jUPv_e3j-e4hb7ftFnTd4oxm7M88=.db937679-4324-416c-bc18-78f025e82cf3@github.com>

On Mon, 17 Apr 2023 21:12:58 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> (if anything, using the ordinal would be _more_ stable, since it is only affected by the order of the constants, rather than by other code that runs before the identity hash code is generated).

Here lies the major original concern -- that I share -- about hooking up `ordinal` as `hashCode`, I think. It opens up enum for the similar sort of algorithmic collisions, perhaps even deliberate ones, like we had with `String`-s. Arguably, switching enum hashcode from IHC to ordinal is a step backwards.

Of course, as John says above, this might change when Valhalla arrives, but in that case we would give up the collision-resistant enum hashcodes for clear benefit of enums being flattened: it would be the "one step back, two steps forward" kind of deal. Today, however, there seem to be to reason to give up this resistance without getting anything in return. The "return" might have been better performance, but this PR eliminates that part as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1512723491

From jlahoda at openjdk.org  Tue Apr 18 09:13:01 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 18 Apr 2023 09:13:01 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:

 - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
 - Reflecting review comments.
 - Fixing exhaustiveness for unsealed supertype pattern.
 - No need to enable features after error reported.
 - SwitchBootstraps.typeSwitch should not initialize enum classes.
 - A prototype of avoiding enum initialization.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13074/files
  - new: https://git.openjdk.org/jdk/pull/13074/files/57445212..a6ba602b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=00-01

  Stats: 332 lines in 8 files changed: 260 ins; 32 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/13074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074

PR: https://git.openjdk.org/jdk/pull/13074

From duke at openjdk.org  Tue Apr 18 09:33:47 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Tue, 18 Apr 2023 09:33:47 GMT
Subject: RFR: 8306038: SystemModulesPlugin: Keep stack clean
In-Reply-To: <laQKKG_wgwd83URh76XNBXn-fk-ZP54u8_iftrPPnHg=.f8d934e3-781c-4f46-843a-87103091f6b1@github.com>
References: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>
 <laQKKG_wgwd83URh76XNBXn-fk-ZP54u8_iftrPPnHg=.f8d934e3-781c-4f46-843a-87103091f6b1@github.com>
Message-ID: <1IWymq0beLKAxCA5yNVB6GZyNtMlMguQY_TLRAECnDo=.3ec67fb0-0b5a-4a75-9b15-7ab23a2a85b1@github.com>

On Mon, 17 Apr 2023 08:21:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This looks right. I assume you've checked `java -XX:+UnlockDiagnosticVMOptions -XX:+BytecodeVerificationLocal -version` as this code is not normally verified


koppor at DESKTOP-KAK953S /cygdrive/c/git-repositories/jdk/jdk/build/windows-x86_64-server-release/jdk/bin
$ ./java -XX:+UnlockDiagnosticVMOptions  -XX:+BytecodeVerificationLocal -version
openjdk version "21-internal" 2023-09-19
OpenJDK Runtime Environment (build 21-internal-adhoc.koppor.jdk)
OpenJDK 64-Bit Server VM (build 21-internal-adhoc.koppor.jdk, mixed mode)


> Also I assume you've run tier2 with the jlink tests.

TBH, I assumed there is a CI in place checking `tier2`, too.

Locally, they do not run here. Example:


test ZipFileSystemTest.testInvalidRequestURIGET(): failure
java.lang.AssertionError: expected [134] but found [146]
        at org.testng.Assert.fail(Assert.java:99)
        at org.testng.Assert.failNotEquals(Assert.java:1037)
        at org.testng.Assert.assertEqualsImpl(Assert.java:140)
...
JavaTest Message: Test threw exception: java.lang.RuntimeException: javax.security.auth.login.LoginException: F?r NT sind keine LoginModules konfiguriert
JavaTest Message: shutting down test


I assume, I should run the test on a dedicated linux machine?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13442#issuecomment-1512755693

From mdoerr at openjdk.org  Tue Apr 18 10:44:03 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 18 Apr 2023 10:44:03 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v22]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <i_lgp3XQaEdsnbxlhXV2TG9vgbGeZj5LhYrFQrDxO2E=.ab081f0c-8350-46ee-b7c0-c4fe08b9c37c@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Adaptation for JDK-8305668
 - Merge remote-tracking branch 'origin' into PPC64_Panama
 - Move ABIv2CallArranger out of linux subdirectory. ABIv1/2 does match the AIX/linux separation.
 - Adaptation for JDK-8303022.
 - Adaptation for JDK-8303684.
 - Merge branch 'openjdk:master' into PPC64_Panama
 - Merge branch 'master' into PPC64_Panama
 - Fix Copyright format.
 - Fix storing 32 bit integers into Java frames. Enable TestArrayStructs.
 - Allow TestHFA to run on musl. Add Upcalls.
 - ... and 14 more: https://git.openjdk.org/jdk/compare/3bba8995...725732a0

-------------

Changes: https://git.openjdk.org/jdk/pull/12708/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=21
  Stats: 2440 lines in 62 files changed: 2330 ins; 1 del; 109 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From phofer at openjdk.org  Tue Apr 18 11:12:42 2023
From: phofer at openjdk.org (Peter Hofer)
Date: Tue, 18 Apr 2023 11:12:42 GMT
Subject: RFR: 8305746: InitializeEncoding should cache Charset object instead
 of charset name
Message-ID: <n_LC8ej_4-qM15pCWVFcirQyB6RNiH7xQtHiJBWNmI0=.c05c9ac5-5602-4f13-98b6-ec1a126c0975@github.com>

Store `Charset` object in `jnuEncoding` and use `String(byte[], Charset)` and `String.getBytes(Charset)` instead of passing the charset name.

-------------

Commit messages:
 - 8305746: InitializeEncoding should cache Charset object instead of charset name

Changes: https://git.openjdk.org/jdk/pull/13499/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13499&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305746
  Stats: 49 lines in 1 file changed: 18 ins; 14 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/13499.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13499/head:pull/13499

PR: https://git.openjdk.org/jdk/pull/13499

From phofer at openjdk.org  Tue Apr 18 11:12:42 2023
From: phofer at openjdk.org (Peter Hofer)
Date: Tue, 18 Apr 2023 11:12:42 GMT
Subject: RFR: 8305746: InitializeEncoding should cache Charset object
 instead of charset name
In-Reply-To: <n_LC8ej_4-qM15pCWVFcirQyB6RNiH7xQtHiJBWNmI0=.c05c9ac5-5602-4f13-98b6-ec1a126c0975@github.com>
References: <n_LC8ej_4-qM15pCWVFcirQyB6RNiH7xQtHiJBWNmI0=.c05c9ac5-5602-4f13-98b6-ec1a126c0975@github.com>
Message-ID: <3cr6MJDgQQa9_s9Z9203R0jUbpqLXaoVAYH6-JaMAZk=.fd2c3305-8f16-4794-a4e7-2ce59473b987@github.com>

On Mon, 17 Apr 2023 17:47:04 GMT, Peter Hofer <phofer at openjdk.org> wrote:

> Store `Charset` object in `jnuEncoding` and use `String(byte[], Charset)` and `String.getBytes(Charset)` instead of passing the charset name.

@naotoj please find here my changes to `InitializeEncoding`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13499#issuecomment-1511828734

From phofer at openjdk.org  Tue Apr 18 11:34:45 2023
From: phofer at openjdk.org (Peter Hofer)
Date: Tue, 18 Apr 2023 11:34:45 GMT
Subject: RFR: 8305746: InitializeEncoding should cache Charset object
 instead of charset name [v2]
In-Reply-To: <n_LC8ej_4-qM15pCWVFcirQyB6RNiH7xQtHiJBWNmI0=.c05c9ac5-5602-4f13-98b6-ec1a126c0975@github.com>
References: <n_LC8ej_4-qM15pCWVFcirQyB6RNiH7xQtHiJBWNmI0=.c05c9ac5-5602-4f13-98b6-ec1a126c0975@github.com>
Message-ID: <O_XJ0eMteZz8UGUp948M219MSbVruXARZxgwN5uJaWw=.16adb547-c449-4007-9cbe-f04e755831ba@github.com>

> Store `Charset` object in `jnuEncoding` and use `String(byte[], Charset)` and `String.getBytes(Charset)` instead of passing the charset name.

Peter Hofer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8305746: InitializeEncoding should cache Charset object instead of charset name

-------------

Changes: https://git.openjdk.org/jdk/pull/13499/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13499&range=01
  Stats: 49 lines in 1 file changed: 18 ins; 14 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/13499.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13499/head:pull/13499

PR: https://git.openjdk.org/jdk/pull/13499

From jlahoda at openjdk.org  Tue Apr 18 11:47:50 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 18 Apr 2023 11:47:50 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <P87UWnjWLYJpvkr2WL0-XcmBpfvMJd91Y7Hsb2_x5uM=.b362c990-142e-4458-932b-3dbeb9b66ef2@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <MkM1D2pdh94wX3KKNo7_Xl_6u8B_5XsDQSodrb5B6VE=.b32b036a-68b7-4360-a9c2-6bccd7f10332@github.com>
 <9K4KarU9rZTTQSyryAkDoyNrpx0G-kv0DAcLPng5AX0=.c0ff9d7d-7ea4-4a9e-9ff3-304a5788b9af@github.com>
 <2svC_yItHpRmOPAkn9PD1rQ_3cEFdXLhbWo0Dw9bU68=.60c529bc-1d52-4159-b395-7fd6c4915c81@github.com>
 <tBKzWr_T0x_DKmW8YUlz3jnSxIwOfAdiG2NCgicFPu8=.87980d3b-7c46-426a-ac82-075e14685ede@github.com>
 <tViH_yZaiWwqFSdhiquf0SFi8erhZ6cMyB6mn-icMLs=.419102e3-372d-4cd1-a1b6-7d64e7981994@github.com>
 <Nc3DWxmLzMvtK2Fj5IE4Z-coZA4HNlrWZf1qT7q6tHU=.98a54fb7-476d-4cdb-b45d-b66ba9c0ab49@github.com>
 <P87UWnjWLYJpvkr2WL0-XcmBpfvMJd91Y7Hsb2_x5uM=.b362c990-142e-4458-932b-3dbeb9b66ef2@github.com>
Message-ID: <FFrLhWXp-3ByU6ZBDueRAH68vCDnIUJAmGxHCRG7tUQ=.03472dc1-7e7c-4a30-90b9-742d3ade6b29@github.com>

On Fri, 14 Apr 2023 16:45:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Well, I'm aware of this, and https://github.com/openjdk/jdk/pull/9779 even optimizes the case where the `enumSwitch` only gets enum constants as parameters.
>> 
>> And, overall, it is fairly easy to implement, I think I've had at least one implementation in the past. But, the last time I was experimenting with this, there IIRC was a performance hit for using the indy/condy (IIRC it worked as a condy/ldc for a mapping array - but it could as easily be an indy doing the mapping as such). So, frankly, to me, simplifying the compiler slightly (in maybe ~10 years, because we would still need to keep the current desugaring for targets that don't have the bootstrap) while slowing down all other code is not a good balance. *If* we can make the indy/condy at least as fast as the current code, (or faster,) then sure, this is the right way to go. And, as far as javac is concerned that is not really difficult.
>
> Is it ever too early in JDK startup (Phase 1) to use #3? But you'll find out pretty quick if the JDK won't start.  But it might constrain where we can use Pattern matching (and it won't be the first feature that can't be used in Phase 1).

FWIW, I've changed the bootstraps to not initialize the enum classes. But, I don't think I can promise `ConstantCallSite` will be used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1169905066

From jlahoda at openjdk.org  Tue Apr 18 11:47:53 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 18 Apr 2023 11:47:53 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <grabb-C4Hj_CgzVmK9TXongYjHyDs9Nk5qfRRjAFLVk=.22ca71e6-2ccd-4431-83d1-9dab0acecb61@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <grabb-C4Hj_CgzVmK9TXongYjHyDs9Nk5qfRRjAFLVk=.22ca71e6-2ccd-4431-83d1-9dab0acecb61@github.com>
Message-ID: <YwX1cLnb7E6YlePXHF2WERbMU51yFWI2wC25ynUcHDg=.dc2b091a-006c-42b8-96c9-e7c8c9cee62c@github.com>

On Fri, 14 Apr 2023 18:30:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>>  - Reflecting review comments.
>>  - Fixing exhaustiveness for unsealed supertype pattern.
>>  - No need to enable features after error reported.
>>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>>  - A prototype of avoiding enum initialization.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4092:
> 
>> 4090:                     log.error(DiagnosticFlag.SOURCE_LEVEL, tree.pos(),
>> 4091:                               Feature.UNCONDITIONAL_PATTERN_IN_INSTANCEOF.error(this.sourceName));
>> 4092:                     allowUnconditionalPatternsInstanceOf = true;
> 
> sorry not sure why we are doing this. Either the feature should be allowed or not right?

We normally don't produce multiple source level errors, but it is true Log does that us by itself, so no need to set the flag, fixed:
https://github.com/openjdk/jdk/pull/13074/commits/bb26b52268c25863ba358843441d4c4352f877fd

Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1169907081

From jlahoda at openjdk.org  Tue Apr 18 11:48:05 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 18 Apr 2023 11:48:05 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <AKnM4ZWxdoTMFa242vrWpPQMFEXm2_YF2fG2HbrRLak=.f2016eab-f6c0-4381-83b7-aab64226a2cd@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <AKnM4ZWxdoTMFa242vrWpPQMFEXm2_YF2fG2HbrRLak=.f2016eab-f6c0-4381-83b7-aab64226a2cd@github.com>
Message-ID: <xC-ZESmG_WBffiNjwjuiPirG2nuqW7tnGjlwxCxmH8U=.85c9a5ba-449f-4879-8720-e0a77c8c4fa7@github.com>

On Mon, 17 Apr 2023 11:33:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>>  - Reflecting review comments.
>>  - Fixing exhaustiveness for unsealed supertype pattern.
>>  - No need to enable features after error reported.
>>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>>  - A prototype of avoiding enum initialization.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 879:
> 
>> 877:                 }
>> 878:                 case TYPEVAR -> components(((TypeVar) seltype).getUpperBound());
>> 879:                 default -> {
> 
> The block here is redundant

Fixed:
https://github.com/openjdk/jdk/pull/13074/commits/4a70b8d9710a21a7c230fe747af3f4f7ba6a388a

Thanks!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 890:
> 
>> 888:          * for the sealed supertype.
>> 889:          */
>> 890:         private List<PatternDescription> reduceBindingPatterns(Type selectorType, List<PatternDescription> patterns) {
> 
> This method doesn't seem to work for the following case:
> 
> 
> class Test {
>     sealed interface I permits A, B, C { }
>     sealed interface I3 permits I2 { }
>     sealed interface I2 extends I3 permits B, C { }
>     final class A implements I {}
>     final class B implements I, I2 {}
>     final class C implements I, I2 {}
> 
>     int m(I i) {
>         return switch (i) {
>             case A a -> 1;
>             case I3 e -> 2;
>         };
>     }
> }
> 
> 
> There seems to be some ordering issue in the way we visit the patterns.

Hopefully fixed:
https://github.com/openjdk/jdk/pull/13074/commits/857980847e21aee0dee4665f19c1a8a54cff4973

Thanks!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 901:
> 
>> 899:                             Type clazzErasure = types.erasure(clazz.type);
>> 900:                             if (components(selectorType).stream()
>> 901:                                                         .map(c -> types.erasure(c))
> 
> Suggestion:
> 
>                                                         .map(Types::erasure)

Fixed:
https://github.com/openjdk/jdk/pull/13074/commits/4a70b8d9710a21a7c230fe747af3f4f7ba6a388a

Thanks!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 914:
> 
>> 912:                             permitted.remove(bpOne.type.tsym);
>> 913:                             bindings.append(it1.head);
>> 914:                             for (var it2 = it1.tail; it2.nonEmpty(); it2 = it2.tail) {
> 
> This could be a for-each loop?

Fixed:
https://github.com/openjdk/jdk/pull/13074/commits/4a70b8d9710a21a7c230fe747af3f4f7ba6a388a

Thanks!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 971:
> 
>> 969:             /* implementation note:
>> 970:              * finding a sub-set of patterns that only differ in a single
>> 971:              * column is time consuming task, so this method speeds it up by:
> 
> Suggestion:
> 
>              * column is time-consuming task, so this method speeds it up by:

Fixed:
https://github.com/openjdk/jdk/pull/13074/commits/4a70b8d9710a21a7c230fe747af3f4f7ba6a388a

Thanks!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 976:
> 
>> 974:              * -- group patterns by their hashs
>> 975:              * -- in each such by-hash group, find sub-sets that only differ in
>> 976:              *    the chosen column, and tcall reduceBindingPatterns and reduceNestedPatterns
> 
> Suggestion:
> 
>              *    the chosen column, and call reduceBindingPatterns and reduceNestedPatterns

Fixed:
https://github.com/openjdk/jdk/pull/13074/commits/4a70b8d9710a21a7c230fe747af3f4f7ba6a388a

Thanks!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 977:
> 
>> 975:              * -- in each such by-hash group, find sub-sets that only differ in
>> 976:              *    the chosen column, and tcall reduceBindingPatterns and reduceNestedPatterns
>> 977:              *    on patterns in the chosed column, as described above
> 
> Suggestion:
> 
>              *    on patterns in the chosen column, as described above

Fixed:
https://github.com/openjdk/jdk/pull/13074/commits/4a70b8d9710a21a7c230fe747af3f4f7ba6a388a

Thanks!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 999:
> 
>> 997:                              .collect(groupingBy(pd -> pd.hashCode(mismatchingCandidateFin)));
>> 998:                     for (var candidates : groupByHashes.values()) {
>> 999:                         var candidatesArr = candidates.toArray(s -> new RecordPattern[s]);
> 
> Could this be an array constructor reference? E.g. `RecordPattern[]::new` ?

Fixed:
https://github.com/openjdk/jdk/pull/13074/commits/4a70b8d9710a21a7c230fe747af3f4f7ba6a388a

Thanks!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1077:
> 
>> 1075:          */
>> 1076:         private List<PatternDescription> reduceRecordPatterns(List<PatternDescription> patterns) {
>> 1077:             var newList = new ListBuffer<PatternDescription>();
> 
> Maybe `newPatterns` would be a better name?

Fixed:
https://github.com/openjdk/jdk/pull/13074/commits/4a70b8d9710a21a7c230fe747af3f4f7ba6a388a

Thanks!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1079:
> 
>> 1077:             var newList = new ListBuffer<PatternDescription>();
>> 1078:             boolean modified = false;
>> 1079:             for (var it = patterns; it.nonEmpty(); it = it.tail) {
> 
> for-each loop here?

Fixed:
https://github.com/openjdk/jdk/pull/13074/commits/4a70b8d9710a21a7c230fe747af3f4f7ba6a388a

Thanks!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1081:
> 
>> 1079:             for (var it = patterns; it.nonEmpty(); it = it.tail) {
>> 1080:                 if (it.head instanceof RecordPattern rpOne) {
>> 1081:                     PatternDescription nue = reduceRecordPattern(rpOne);
> 
> I find the name `nue` (here and elsewhere) particularly obscure.

Renamed `nue` to different names on this and other places:
https://github.com/openjdk/jdk/pull/13074/commits/4a70b8d9710a21a7c230fe747af3f4f7ba6a388a

Thanks!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1084:
> 
>> 1082:                     if (nue != rpOne) {
>> 1083:                         newList.append(nue);
>> 1084:                         modified |= true;
> 
> Suggestion:
> 
>                         modified = true;

Fixed:
https://github.com/openjdk/jdk/pull/13074/commits/4a70b8d9710a21a7c230fe747af3f4f7ba6a388a

Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1169908961
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1169907961
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1169910615
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1169910699
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1169908669
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1169908754
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1169908874
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1169909065
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1169910097
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1169910379
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1169909734
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1169909809

From aturbanov at openjdk.org  Tue Apr 18 12:11:43 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 18 Apr 2023 12:11:43 GMT
Subject: RFR: 8304896: Update to use jtreg 7.2
In-Reply-To: <SW7PTuDcEugo22nTk04k3aEL9Ineq5T25CRUnhDc7Vo=.0e4e96d2-f171-45c2-a4a7-5b83c3cdb548@github.com>
References: <SW7PTuDcEugo22nTk04k3aEL9Ineq5T25CRUnhDc7Vo=.0e4e96d2-f171-45c2-a4a7-5b83c3cdb548@github.com>
Message-ID: <Dw2T0UWmKOPtpW-fgTSoY50wzY2ajgj8P1lu-vLY_g0=.2cf33a08-40a5-4fb5-9d3a-b058cd107908@github.com>

On Mon, 17 Apr 2023 14:56:16 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.2.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

Interesting, why this JBS ticked is considered as a bug?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13496#issuecomment-1512977295

From qamai at openjdk.org  Tue Apr 18 12:40:42 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 18 Apr 2023 12:40:42 GMT
Subject: RFR: 8306008: Several Vector API tests fail for client VM after
 JDK-8304450
Message-ID: <TDcfSAbMANHhRfHfZSAoKxfHPrsVqHrbE0gz1RwUBcg=.de344a1c-8d0e-477b-b8a2-209595967254@github.com>

Hi,

Please review this patch which fixes the errors on machines where TypeMaxVector has a length of 64 bits. I take an extra cautious approach and fall back to putting elements one by one if the length is an unexpected value.

All jdk/incubator/vector tests passed with MaxVectorSize=8, which fails without this patch.

Thanks a lot.

-------------

Commit messages:
 - extra cautious
 - fix DoubleMaxShuffle.intoArray

Changes: https://git.openjdk.org/jdk/pull/13508/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13508&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306008
  Stats: 275 lines in 11 files changed: 205 ins; 0 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/13508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13508/head:pull/13508

PR: https://git.openjdk.org/jdk/pull/13508

From mdoerr at openjdk.org  Tue Apr 18 12:56:47 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 18 Apr 2023 12:56:47 GMT
Subject: RFR: 8306008: Several Vector API tests fail for client VM after
 JDK-8304450
In-Reply-To: <TDcfSAbMANHhRfHfZSAoKxfHPrsVqHrbE0gz1RwUBcg=.de344a1c-8d0e-477b-b8a2-209595967254@github.com>
References: <TDcfSAbMANHhRfHfZSAoKxfHPrsVqHrbE0gz1RwUBcg=.de344a1c-8d0e-477b-b8a2-209595967254@github.com>
Message-ID: <SC1nni1MF760p2hqlMDN5Y4jqX1OesezyNfp_lBritg=.a4adfb8b-8249-4aa9-a865-cb10a6da8719@github.com>

On Tue, 18 Apr 2023 12:21:11 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Please review this patch which fixes the errors on machines where TypeMaxVector has a length of 64 bits. I take an extra cautious approach and fall back to putting elements one by one if the length is an unexpected value.
> 
> All jdk/incubator/vector tests passed with MaxVectorSize=8, which fails without this patch.
> 
> Thanks a lot.

Thanks for fixing it! This PR fixes the issues in Vector64ConversionTests on PPC64.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13508#issuecomment-1513071561

From mcimadamore at openjdk.org  Tue Apr 18 13:15:54 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Apr 2023 13:15:54 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
Message-ID: <wRIxmUAvctNy7oRqk-oOIzfCWDmojJx5PYgQNvyW43U=.1a1d959a-52c5-4161-aff5-a1faf0e00b55@github.com>

On Tue, 18 Apr 2023 09:13:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>  - Reflecting review comments.
>  - Fixing exhaustiveness for unsealed supertype pattern.
>  - No need to enable features after error reported.
>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>  - A prototype of avoiding enum initialization.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 953:

> 951:                     }
> 952: 
> 953:                     Set<PatternDescription> cleanedToRemove = new HashSet<>(toRemove);

Another way to do this would be to compute the intersection between `toRemove` and `toAdd` (e.g. with `retainAll`), and then remove the intersection from both sets.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1169854290

From jlaskey at openjdk.org  Tue Apr 18 13:40:04 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 18 Apr 2023 13:40:04 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v63]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <detyyRHhaFRUMjl6xHiBrjMLwXIKzp0G6AzHJGGzYu0=.d97e0788-c644-4d91-af5a-3a3f5d7cb672@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Spacing
 - Tidy up

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/70c215c6..c6d943c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=62
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=61-62

  Stats: 7 lines in 4 files changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jvernee at openjdk.org  Tue Apr 18 13:45:57 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 18 Apr 2023 13:45:57 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v5]
In-Reply-To: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
Message-ID: <DD0nvfK8sVvqOdwEKyIzOz1mRkSnRD63xf34EFDXvkE=.c73f7231-a80d-4d71-9586-b27e67f4a5f3@github.com>

> This patch adds checks in AbstractLinker to reject packed structs and structs with excess padding (e.g. unnamed bitfields), since both of those are currently not supported, and the ABI/spec seems too vague to base support on.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - fix TestIllegalLink
 - Merge branch 'PR_21' into RejectPacked
 - Merge branch 'PR_21' into RejectPacked
 - add javadoc + fixes for trailing padding
 - fix check for padding. Add check for trailing padding too
 - Reject packed structs and structs with extra padding
 - Check byte order of layouts passed to linker

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13164/files
  - new: https://git.openjdk.org/jdk/pull/13164/files/819214b2..eaf0c9c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13164&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13164&range=03-04

  Stats: 41274 lines in 1168 files changed: 20700 ins; 16740 del; 3834 mod
  Patch: https://git.openjdk.org/jdk/pull/13164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13164/head:pull/13164

PR: https://git.openjdk.org/jdk/pull/13164

From mcimadamore at openjdk.org  Tue Apr 18 13:46:48 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Apr 2023 13:46:48 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
Message-ID: <NYQhH7mCsIMtfI9UsMGPyVtVYob1yqSHYWMl_i26qL8=.e261753c-ac40-417c-8404-6b1d2fa16727@github.com>

On Tue, 18 Apr 2023 09:13:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>  - Reflecting review comments.
>  - Fixing exhaustiveness for unsealed supertype pattern.
>  - No need to enable features after error reported.
>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>  - A prototype of avoiding enum initialization.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 812:

> 810:                     if (l instanceof JCPatternCaseLabel patternLabel) {
> 811:                         for (Type component : components(selector.type)) {
> 812:                             patterns = patterns.prepend(PatternDescription.from(types, component, patternLabel.pat));

I noted that this code ends up adding redundant pattern descriptions to the list - for instance:


class Test {
    sealed interface I1 permits B, C { }
    sealed interface I2 permits B, C { }

    static final class B implements I1, I2 { }
    static final class C implements I1, I2 { }

    <Z extends I1 & I2> int test(Z z) {
        return switch (z) {
            case B c -> 2;
            case C d -> 3;
        };
    }
}


In this case the list ends up with 6 elements, [ B, B, B, C, C, C ]. Given that the complexity of the algorithm depends on the number of patterns in the list, it would probably be better to use a set here and try to make the list as small as possible from early on.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 915:

> 913: 
> 914:                             for (PatternDescription pdOther : patterns) {
> 915:                                 if (pdOther instanceof BindingPattern bpOther) {

This code redundantly checks a pattern against itself, which I think we can avoid.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1170062325
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1170062982

From mcimadamore at openjdk.org  Tue Apr 18 13:57:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Apr 2023 13:57:50 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <NYQhH7mCsIMtfI9UsMGPyVtVYob1yqSHYWMl_i26qL8=.e261753c-ac40-417c-8404-6b1d2fa16727@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <NYQhH7mCsIMtfI9UsMGPyVtVYob1yqSHYWMl_i26qL8=.e261753c-ac40-417c-8404-6b1d2fa16727@github.com>
Message-ID: <jKDM0ZhYxskkzMotMi4wW8f9R-2aAjxob5AxiFaS7tU=.f5fcfd7f-74c1-4078-bc89-f2992fb5a806@github.com>

On Tue, 18 Apr 2023 13:43:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>>  - Reflecting review comments.
>>  - Fixing exhaustiveness for unsealed supertype pattern.
>>  - No need to enable features after error reported.
>>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>>  - A prototype of avoiding enum initialization.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 812:
> 
>> 810:                     if (l instanceof JCPatternCaseLabel patternLabel) {
>> 811:                         for (Type component : components(selector.type)) {
>> 812:                             patterns = patterns.prepend(PatternDescription.from(types, component, patternLabel.pat));
> 
> I noted that this code ends up adding redundant pattern descriptions to the list - for instance:
> 
> 
> class Test {
>     sealed interface I1 permits B, C { }
>     sealed interface I2 permits B, C { }
> 
>     static final class B implements I1, I2 { }
>     static final class C implements I1, I2 { }
> 
>     <Z extends I1 & I2> int test(Z z) {
>         return switch (z) {
>             case B c -> 2;
>             case C d -> 3;
>         };
>     }
> }
> 
> 
> In this case the list ends up with 6 elements, [ B, B, B, C, C, C ]. Given that the complexity of the algorithm depends on the number of patterns in the list, it would probably be better to use a set here and try to make the list as small as possible from early on.

I've also found an infinite loop with this:


class Test {
    sealed interface I0 permits I1, I2 { }
    sealed interface I00 permits I1, I2 { }

    sealed interface I1 extends I0, I00 permits B, C { }
    sealed interface I2 extends I0, I00 permits B, C { }

    static final class B implements I1, I2 { }
    static final class C implements I1, I2 { }

    int test(Object o) {
        return switch (o) {
            case B c -> 2;
            case C d -> 3;
        };
    }
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1170079092

From mcimadamore at openjdk.org  Tue Apr 18 14:19:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Apr 2023 14:19:50 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <jKDM0ZhYxskkzMotMi4wW8f9R-2aAjxob5AxiFaS7tU=.f5fcfd7f-74c1-4078-bc89-f2992fb5a806@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <NYQhH7mCsIMtfI9UsMGPyVtVYob1yqSHYWMl_i26qL8=.e261753c-ac40-417c-8404-6b1d2fa16727@github.com>
 <jKDM0ZhYxskkzMotMi4wW8f9R-2aAjxob5AxiFaS7tU=.f5fcfd7f-74c1-4078-bc89-f2992fb5a806@github.com>
Message-ID: <Fiin2pina341hgkOUxMQEGmSIb6yUXD6HrXFMmoWm_s=.3aca7930-a874-4904-a26a-522a5716e00b@github.com>

On Tue, 18 Apr 2023 13:54:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I've also found an infinite loop with this:

I believe this has to do with the fact that the list of pattern is not a set - so we can end up adding the same pattern descriptions over and over.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1170110465

From mcimadamore at openjdk.org  Tue Apr 18 14:31:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Apr 2023 14:31:53 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
Message-ID: <dpPYMeqThhoH94lWbOWQe-_YHbiax5piNayiA1uh0gQ=.55abaf01-c4a3-438a-a772-08472ce81d57@github.com>

On Tue, 18 Apr 2023 09:13:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>  - Reflecting review comments.
>  - Fixing exhaustiveness for unsealed supertype pattern.
>  - No need to enable features after error reported.
>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>  - A prototype of avoiding enum initialization.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 927:

> 925:                                             it.remove();
> 926:                                             reduces = true;
> 927:                                             continue PERMITTED;

the label can be dropped here as there's no nested loop

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1170127214

From mcimadamore at openjdk.org  Tue Apr 18 14:37:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Apr 2023 14:37:55 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
Message-ID: <tIWahIj-COGg9xaz4H4MVXX4Zv8Y3wRGEQFdCLKrqJo=.d3841341-4256-4e91-a028-580c16a9a3c9@github.com>

On Tue, 18 Apr 2023 09:13:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>  - Reflecting review comments.
>  - Fixing exhaustiveness for unsealed supertype pattern.
>  - No need to enable features after error reported.
>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>  - A prototype of avoiding enum initialization.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1021:

> 1019:              *    on patterns in the chosen column, as described above
> 1020:              */
> 1021:             var grouppedPerRecordClass =

Suggestion:

            var groupedPerRecordClass =

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1058:

> 1056:                                     for (int i = 0; i < rpOne.nested.length; i++) {
> 1057:                                         if (i != mismatchingCandidate &&
> 1058:                                             !exactlyMatches(rpOne.nested[i], rpOther.nested[i])) {

should `exactlyMatches` be the implementation of `equals` in the `PatternDescriptor` class?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1170131443
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1170135800

From mcimadamore at openjdk.org  Tue Apr 18 14:37:56 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Apr 2023 14:37:56 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <tIWahIj-COGg9xaz4H4MVXX4Zv8Y3wRGEQFdCLKrqJo=.d3841341-4256-4e91-a028-580c16a9a3c9@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <tIWahIj-COGg9xaz4H4MVXX4Zv8Y3wRGEQFdCLKrqJo=.d3841341-4256-4e91-a028-580c16a9a3c9@github.com>
Message-ID: <xe5wRww8xjp21Hg-_0Vt0P5NoGVtUDQdDWcTGAlkw2A=.d0675328-b7dc-4276-abe6-facd0bbfc85f@github.com>

On Tue, 18 Apr 2023 14:31:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>>  - Reflecting review comments.
>>  - Fixing exhaustiveness for unsealed supertype pattern.
>>  - No need to enable features after error reported.
>>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>>  - A prototype of avoiding enum initialization.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1021:
> 
>> 1019:              *    on patterns in the chosen column, as described above
>> 1020:              */
>> 1021:             var grouppedPerRecordClass =
> 
> Suggestion:
> 
>             var groupedPerRecordClass =

or `patternsByRecordClass`, or `groupByRecordClass` (the latter would be consistent with `groupByHash` which is used below)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1170131872

From jjg at openjdk.org  Tue Apr 18 15:18:39 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 18 Apr 2023 15:18:39 GMT
Subject: RFR: 8304896: Update to use jtreg 7.2
In-Reply-To: <Dw2T0UWmKOPtpW-fgTSoY50wzY2ajgj8P1lu-vLY_g0=.2cf33a08-40a5-4fb5-9d3a-b058cd107908@github.com>
References: <SW7PTuDcEugo22nTk04k3aEL9Ineq5T25CRUnhDc7Vo=.0e4e96d2-f171-45c2-a4a7-5b83c3cdb548@github.com>
 <Dw2T0UWmKOPtpW-fgTSoY50wzY2ajgj8P1lu-vLY_g0=.2cf33a08-40a5-4fb5-9d3a-b058cd107908@github.com>
Message-ID: <uvE4eHD9WZuwI9g9s2VK8h7_ij2pGg6RWpV-mIhZ8eg=.639ff315-c828-412e-8baa-e3f88cab8a81@github.com>

On Tue, 18 Apr 2023 12:08:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Interesting, why this JBS ticked is considered as a bug?

There's no obvious best choice here (bug, enhancement, task) and as is, it was the same as for similar previous items.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13496#issuecomment-1513340471

From aturbanov at openjdk.org  Tue Apr 18 16:42:13 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 18 Apr 2023 16:42:13 GMT
Subject: RFR: 8304896: Update to use jtreg 7.2
In-Reply-To: <SW7PTuDcEugo22nTk04k3aEL9Ineq5T25CRUnhDc7Vo=.0e4e96d2-f171-45c2-a4a7-5b83c3cdb548@github.com>
References: <SW7PTuDcEugo22nTk04k3aEL9Ineq5T25CRUnhDc7Vo=.0e4e96d2-f171-45c2-a4a7-5b83c3cdb548@github.com>
Message-ID: <qoDttmclwTowKzrVOgkPWKr8Omraemmqa0FK11yx_Zo=.8817d541-5a9c-48bb-a7f5-666ee268c55a@github.com>

On Mon, 17 Apr 2023 14:56:16 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.2.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

7.1 was an enhancement https://bugs.openjdk.org/browse/JDK-8296710
7.1.1 update was a bug because of https://bugs.openjdk.org/browse/CODETOOLS-7903390
I think enhancement suits better here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13496#issuecomment-1513478868

From duke at openjdk.org  Tue Apr 18 16:55:52 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 18 Apr 2023 16:55:52 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v2]
In-Reply-To: <h4Hxt92uq_55x0DbUAJPizCoyNPfLkAQ5i5JZaYEykg=.31676601-f43f-4435-9738-21743d72d223@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <h4Hxt92uq_55x0DbUAJPizCoyNPfLkAQ5i5JZaYEykg=.31676601-f43f-4435-9738-21743d72d223@github.com>
Message-ID: <0RcSipJ5V0CS9JlIzCIaIpSWUUI_eoHj2posMR3ifLY=.9b9429ff-9d46-417e-9e18-bd8b42f38dad@github.com>

On Wed, 29 Mar 2023 10:48:57 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.
>> 
>> While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.
>> 
>> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:
>> 
>> 
>> When extracting, if the zip64 extended information extra 
>> field is present for the file the compressed and 
>> uncompressed sizes will be 8 byte values.
>> 
>> 
>> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:
>> 
>> `echo hello | zip -fd > hello.zip`
>> 
>> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use block comments instead of javadoc comments to avoid doclint warnings

Mark Thomas of Apache chimed in on the JBS to say that this limitation of ZipInputStream is affecting Tomcat migration tooling:

>This bug is affecting the library Apache Tomcat uses to automatically migrate web applications from Java EE to Jakarta EE.
https://github.com/apache/tomcat-jakartaee-migration/issues/46

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1513497317

From duke at openjdk.org  Tue Apr 18 17:26:22 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 18 Apr 2023 17:26:22 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v3]
In-Reply-To: <RWHWJNE1Sw44eqSYc5y9oJL5U4GHEKcgIDgyRyBZzXE=.9ae79ef5-a564-4e06-b931-97982ec1a77e@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <jQWXWn_rma-JtYK5AlSO1W2CH8q9VAKK4DS0_Gqk26c=.428eadeb-f203-4e25-915a-a346befa3163@github.com>
 <_ddg8NNgXP2qnKZLqcf15YmiQCTgdcr1yY2P1OFJ6Ks=.d0ab6b0f-a6a5-441e-ba31-c05c8af3932f@github.com>
 <AfKZDBfg4SEXoVvC2vso3vVi9LryRJZOU74lO8K7al8=.a2148933-faaa-43cb-9be5-3c6e5c4a62a8@github.com>
 <RWHWJNE1Sw44eqSYc5y9oJL5U4GHEKcgIDgyRyBZzXE=.9ae79ef5-a564-4e06-b931-97982ec1a77e@github.com>
Message-ID: <yHhmsFXr99f0Me3r4t5Ld97kjjJCIAWJ5AwO72Tgh5U=.8d43126e-c766-4366-aec6-c73072e005f8@github.com>

On Tue, 18 Apr 2023 08:34:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Shouldn?t?`invokespecial` produce a?non?virtual?call as?well?
>> 
>> And?`this`/`super` can?never be?`null`.
>
> `super.hashCode()` is a virtual call. `System.identityHashCode` is the static call. I don't understand where `invokespecial` enters the picture here.

`invokespecial` is?used to?call instance?methods in?a?non?virtual?manner.

--------------------------------------------------------------------------------

Using?`super.hashCode()` in?`java.lang.Enum` produces?the?bytecode:

aload_0;
invokespecial java/lang/Object.hashCode:()I;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1170358043

From shade at openjdk.org  Tue Apr 18 17:59:07 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Apr 2023 17:59:07 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v2]
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <gmaueV00mqBdRJV0Yg8I27nJnilkbQlkBv7sa-YDuhk=.f894de51-f8ba-4f49-888b-53cddf54faf9@github.com>

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Aleksey Shipilev 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 JDK-83050920-thread-sleep-subms
 - Work
 - Draft work
 - Merge branch 'master' into JDK-83050920-thread-sleep-subms
 - Merge branch 'master' into JDK-83050920-thread-sleep-subms
 - More fixes
 - Fix Windows yet again
 - Helper method should be inline, not static
 - Work

-------------

Changes: https://git.openjdk.org/jdk/pull/13225/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=01
  Stats: 277 lines in 16 files changed: 216 ins; 31 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/13225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13225/head:pull/13225

PR: https://git.openjdk.org/jdk/pull/13225

From shade at openjdk.org  Tue Apr 18 17:59:10 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Apr 2023 17:59:10 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v2]
In-Reply-To: <aLkZlsnCXbRzzku9GhAPRmvXemLy3h_Ug7Vgme7ujNM=.fa1eed04-c389-4614-b1fc-4f65de86cf7d@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <aLkZlsnCXbRzzku9GhAPRmvXemLy3h_Ug7Vgme7ujNM=.fa1eed04-c389-4614-b1fc-4f65de86cf7d@github.com>
Message-ID: <dwTTsPY_ZbIPIdZE8RreAGXq4zObjThMsfSX68iKc0o=.162336be-b9c9-4bc8-9965-3a86de6570cd@github.com>

On Wed, 12 Apr 2023 07:44:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>>  - Work
>>  - Draft work
>>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>>  - More fixes
>>  - Fix Windows yet again
>>  - Helper method should be inline, not static
>>  - Work
>
> src/hotspot/share/include/jvm.h line 279:
> 
>> 277: 
>> 278: JNIEXPORT void JNICALL
>> 279: JVM_Sleep(JNIEnv *env, jclass threadClass, jlong millis, jint nanos);
> 
> I wonder if it would be simpler to just provide a single value, in nanoseconds, to the VM. That's enough for a sleep of 292 years. Windows would still need to convert to milliseconds of course but it overall would avoid sending two values down to the park code.

Right, that might be better. New revision should address that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1170386627

From shade at openjdk.org  Tue Apr 18 17:59:12 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Apr 2023 17:59:12 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v2]
In-Reply-To: <aiC2OQ_-DUYUsdfgamJ_LRBVPWdU55V-KYQszbsSqpI=.151c93ea-f09d-4626-b708-7772e80dab2d@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <aiC2OQ_-DUYUsdfgamJ_LRBVPWdU55V-KYQszbsSqpI=.151c93ea-f09d-4626-b708-7772e80dab2d@github.com>
Message-ID: <78WWvars1HHkiXvVZYVWNzUzIZCV4gEDU_mZd2BOEYI=.419a34ec-d53f-4075-ae4f-81524ad4c536@github.com>

On Thu, 30 Mar 2023 01:26:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>>  - Work
>>  - Draft work
>>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>>  - More fixes
>>  - Fix Windows yet again
>>  - Helper method should be inline, not static
>>  - Work
>
> src/hotspot/share/runtime/javaThread.cpp line 1981:
> 
>> 1979: }
>> 1980: 
>> 1981: bool JavaThread::sleep(jlong millis, jint nanos) {
> 
> You don't need the overloads at this level - the incoming call should always have millis and nanos, even if nanos is zero.

I think the distinction between millis and nanos makes our life unnecessarily hard here. `jlong nanos` is already quite big for practical uses, and so we can simplify this code by only passing `nanos` around. In new revision, I still do two overloads to avoid "unit" mistakes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1170390101

From shade at openjdk.org  Tue Apr 18 17:59:14 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Apr 2023 17:59:14 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v2]
In-Reply-To: <a-0HBVWhYvxYpHicxDKAkUXF2CPKPqsBWyVUlmSCwpo=.6a8fef20-3fb2-48db-b6ea-8d0f6257ff77@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <D3WmCB5j0L2scJaMYCC1dRnLabkbry2jeqolFwMxdEk=.d1ae02ef-8a09-44a4-bb4f-648106da3b9b@github.com>
 <ry1FPsIyROnWaoVmGxDppMYCuK7xQ9IBnDFBTeg-UMQ=.dbce9f3c-2f8a-49bd-abfa-7a07a4a3e628@github.com>
 <a-0HBVWhYvxYpHicxDKAkUXF2CPKPqsBWyVUlmSCwpo=.6a8fef20-3fb2-48db-b6ea-8d0f6257ff77@github.com>
Message-ID: <F7_8fapHyw4HhIMI3iFK-DymnlYx9HJvrP_vZKvnVNA=.81db0172-c4b9-4127-8cc7-85720139587f@github.com>

On Wed, 29 Mar 2023 19:57:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Yes, let me fix that. `TimeUnit.toNanos` handles it well itself, it seems.
>
>> Yes, let me fix that. `TimeUnit.toNanos` handles it well itself, it seems.
> 
> This code is refactored in PR 13203 so we'll have to merge at some point.

Merged!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1170390739

From lancea at openjdk.org  Tue Apr 18 18:22:04 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Apr 2023 18:22:04 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v2]
In-Reply-To: <h4Hxt92uq_55x0DbUAJPizCoyNPfLkAQ5i5JZaYEykg=.31676601-f43f-4435-9738-21743d72d223@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <h4Hxt92uq_55x0DbUAJPizCoyNPfLkAQ5i5JZaYEykg=.31676601-f43f-4435-9738-21743d72d223@github.com>
Message-ID: <3bPjLKsXGaWR5pNgsBKNtSJE8n3Sm28K_YpPR6sHegw=.72763c8f-ec8f-4987-a6f7-dab8fb2e71b5@github.com>

On Wed, 29 Mar 2023 10:48:57 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.
>> 
>> While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.
>> 
>> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:
>> 
>> 
>> When extracting, if the zip64 extended information extra 
>> field is present for the file the compressed and 
>> uncompressed sizes will be 8 byte values.
>> 
>> 
>> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:
>> 
>> `echo hello | zip -fd > hello.zip`
>> 
>> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use block comments instead of javadoc comments to avoid doclint warnings

> Mark Thomas of Apache chimed in on the JBS to say that this limitation of ZipInputStream is affecting Tomcat migration tooling:
> 
> > This bug is affecting the library Apache Tomcat uses to automatically migrate web applications from Java EE to Jakarta EE.
> > [apache/tomcat-jakartaee-migration#46](https://github.com/apache/tomcat-jakartaee-migration/issues/46)

It would be useful to obtain the zip/jar in question to validate that your proposed patch addresses the issue as well as verifying if ZipfFile can be used to process the zip/jar as reading the long thread appears that ZipFile:getInputStream is fine.

Do you know how the Zip in question is being created, is it via ApacheCommons and could there be an issue there?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1513610001

From duke at openjdk.org  Tue Apr 18 18:26:31 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 18 Apr 2023 18:26:31 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v2]
In-Reply-To: <3bPjLKsXGaWR5pNgsBKNtSJE8n3Sm28K_YpPR6sHegw=.72763c8f-ec8f-4987-a6f7-dab8fb2e71b5@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <h4Hxt92uq_55x0DbUAJPizCoyNPfLkAQ5i5JZaYEykg=.31676601-f43f-4435-9738-21743d72d223@github.com>
 <3bPjLKsXGaWR5pNgsBKNtSJE8n3Sm28K_YpPR6sHegw=.72763c8f-ec8f-4987-a6f7-dab8fb2e71b5@github.com>
Message-ID: <SK7_SNQ3volnd5n-ewkIphKlOOFZPl20tz9cAlxAcyo=.984cc466-afcf-4c19-823a-1bdade07131e@github.com>

On Tue, 18 Apr 2023 18:19:20 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Do you know how the Zip in question is being created, is it via ApacheCommons and could there be an issue there?

Currently investigating. The Tomcat build is using the Ant `jar` task to create the `tomcat-embed-core.jar`, but then calls `zip` in update mode to update the jar with some Graal related files. This is where the ZIP64 extra fields get introduced.

I'll take a look at testing this PR with this Tomcat jar once I have a better understanding why the `zip` task introduces ZIP64.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1513615536

From lancea at openjdk.org  Tue Apr 18 18:30:58 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Apr 2023 18:30:58 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v2]
In-Reply-To: <SK7_SNQ3volnd5n-ewkIphKlOOFZPl20tz9cAlxAcyo=.984cc466-afcf-4c19-823a-1bdade07131e@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <h4Hxt92uq_55x0DbUAJPizCoyNPfLkAQ5i5JZaYEykg=.31676601-f43f-4435-9738-21743d72d223@github.com>
 <3bPjLKsXGaWR5pNgsBKNtSJE8n3Sm28K_YpPR6sHegw=.72763c8f-ec8f-4987-a6f7-dab8fb2e71b5@github.com>
 <SK7_SNQ3volnd5n-ewkIphKlOOFZPl20tz9cAlxAcyo=.984cc466-afcf-4c19-823a-1bdade07131e@github.com>
Message-ID: <B0RfZZAFP2OfkFQTl5uVOPq42jyw5DgFf4z9zAD76dc=.18858be0-7608-47ec-b20f-ff184f917085@github.com>

On Tue, 18 Apr 2023 18:24:01 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> > Do you know how the Zip in question is being created, is it via ApacheCommons and could there be an issue there?
> 
> Currently investigating. The Tomcat build is using the Ant `jar` task to create the `tomcat-embed-core.jar`, but then calls `zip` in update mode to update the jar with some Graal related files. This is where the ZIP64 extra fields get introduced.
> 
> I'll take a look at testing this PR with this Tomcat jar once I have a better understanding why the `zip` task introduces ZIP64.

Thank you Eirik, probably need to know which zip and which command line options are being used

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1513620437

From naoto at openjdk.org  Tue Apr 18 18:46:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Apr 2023 18:46:50 GMT
Subject: RFR: 8306323: Update license files in CLDR v43
Message-ID: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>

The upgrade to CLDR v43 was missing the license-related file updates. Here are the supplemental updates.

-------------

Commit messages:
 - 8306323: Update license files in CLDR v43

Changes: https://git.openjdk.org/jdk/pull/13517/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13517&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306323
  Stats: 194 lines in 3 files changed: 98 ins; 90 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13517/head:pull/13517

PR: https://git.openjdk.org/jdk/pull/13517

From mchung at openjdk.org  Tue Apr 18 18:49:44 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 18 Apr 2023 18:49:44 GMT
Subject: RFR: 8306038: SystemModulesPlugin: Keep stack clean
In-Reply-To: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>
References: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>
Message-ID: <4s_mD7mtF9Dd3BP2-BBhUp3LatO2Fn9z_Xan2MHqvv0=.c696ff79-dae6-4001-a240-cf966966da3d@github.com>

On Wed, 12 Apr 2023 09:18:13 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> This refs [https://bugs.openjdk.org/browse/JDK-8306038](8306038). 
> 
> (Before this referenced 8240567)
> 
> Although this change is rather small, I think, it's good to have a "more clean" SystemModulesPlugin available.

or you can just run jlink test with this command:


make test TEST=test/jdk/tools/jlink

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13442#issuecomment-1513640498

From stsypanov at openjdk.org  Tue Apr 18 18:49:54 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 18 Apr 2023 18:49:54 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v5]
In-Reply-To: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
Message-ID: <8EBRIAmr9MzpU6U654LjdVS4w54tcsfCDqhnX5HvuHI=.7da22500-928c-4048-a13e-27c15b95c356@github.com>

> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
> 
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>   .appendLiteral("Date:")
>   .padNext(20, ' ')
>   .append(DateTimeFormatter.ISO_DATE)
>   .toFormatter();
> String text = dtf.format(LocalDateTime.now());

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8300818: special cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12131/files
  - new: https://git.openjdk.org/jdk/pull/12131/files/198cb6ae..07215c1f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12131&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12131&range=03-04

  Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12131/head:pull/12131

PR: https://git.openjdk.org/jdk/pull/12131

From stsypanov at openjdk.org  Tue Apr 18 18:49:56 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 18 Apr 2023 18:49:56 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v4]
In-Reply-To: <LqYM4DGlvbhjOITWOedQLcKL4B3y4sQ09tIHc_E2vRs=.0cf7cb11-9af0-486b-9a14-14d79b2706ea@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <LqYM4DGlvbhjOITWOedQLcKL4B3y4sQ09tIHc_E2vRs=.0cf7cb11-9af0-486b-9a14-14d79b2706ea@github.com>
Message-ID: <fd6hWIdZn5b_g4iEnw6QGQ33KoNbxKHLI31XsVtC22w=.9aced287-4b80-472d-b199-f0814617cfa0@github.com>

On Sun, 16 Apr 2023 11:20:46 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300818: Extract separate benchmark

With latest changes

baseline

Benchmark                                                                     Mode  Cnt      Score     Error   Units
DateTimeFormatterWithPaddingBench.formatWithPadding                          thrpt   15   5848.753 ? 223.592  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPadding:?gc.alloc.rate           thrpt   15   1070.358 ?  40.881  MB/sec
DateTimeFormatterWithPaddingBench.formatWithPadding:?gc.alloc.rate.norm      thrpt   15    192.000 ?   0.001    B/op
DateTimeFormatterWithPaddingBench.formatWithPadding:?gc.count                thrpt   15     53.000            counts
DateTimeFormatterWithPaddingBench.formatWithPadding:?gc.time                 thrpt   15    479.000                ms
DateTimeFormatterWithPaddingBench.formatWithZeroPadding                      thrpt   15  22032.107 ? 481.443  ops/ms
DateTimeFormatterWithPaddingBench.formatWithZeroPadding:?gc.alloc.rate       thrpt   15   3192.003 ?  69.901  MB/sec
DateTimeFormatterWithPaddingBench.formatWithZeroPadding:?gc.alloc.rate.norm  thrpt   15    152.000 ?   0.001    B/op
DateTimeFormatterWithPaddingBench.formatWithZeroPadding:?gc.count            thrpt   15     83.000            counts
DateTimeFormatterWithPaddingBench.formatWithZeroPadding:?gc.time             thrpt   15   1046.000                ms

patch

Benchmark                                                                     Mode  Cnt      Score     Error   Units
DateTimeFormatterWithPaddingBench.formatWithPadding                          thrpt   15   7982.747 ? 374.638  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPadding:?gc.alloc.rate           thrpt   15   1704.393 ?  80.063  MB/sec
DateTimeFormatterWithPaddingBench.formatWithPadding:?gc.alloc.rate.norm      thrpt   15    224.000 ?   0.001    B/op
DateTimeFormatterWithPaddingBench.formatWithPadding:?gc.count                thrpt   15     64.000            counts
DateTimeFormatterWithPaddingBench.formatWithPadding:?gc.time                 thrpt   15    641.000                ms
DateTimeFormatterWithPaddingBench.formatWithZeroPadding                      thrpt   15  22024.559 ? 794.713  ops/ms
DateTimeFormatterWithPaddingBench.formatWithZeroPadding:?gc.alloc.rate       thrpt   15   3190.932 ? 115.145  MB/sec
DateTimeFormatterWithPaddingBench.formatWithZeroPadding:?gc.alloc.rate.norm  thrpt   15    152.000 ?   0.001    B/op
DateTimeFormatterWithPaddingBench.formatWithZeroPadding:?gc.count            thrpt   15     85.000            counts
DateTimeFormatterWithPaddingBench.formatWithZeroPadding:?gc.time             thrpt   15   1019.000                ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12131#issuecomment-1513638998

From lancea at openjdk.org  Tue Apr 18 18:50:51 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Apr 2023 18:50:51 GMT
Subject: RFR: 8306323: Update license files in CLDR v43
In-Reply-To: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
References: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
Message-ID: <XFaMZDSL4S4f2WFa_RzQfFsb55z6gWWzDCX_Y8tK7JE=.f15aa5b5-9054-4e36-bcf9-44a751086888@github.com>

On Tue, 18 Apr 2023 18:40:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The upgrade to CLDR v43 was missing the license-related file updates. Here are the supplemental updates.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13517#pullrequestreview-1390742707

From duke at openjdk.org  Tue Apr 18 18:53:44 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Tue, 18 Apr 2023 18:53:44 GMT
Subject: RFR: 8306323: Update license files in CLDR v43
In-Reply-To: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
References: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
Message-ID: <DmJZDsrUaoxmJxN-r948Ro1LItB1AEQWlDyLKSSEFxM=.86fb4d78-25f1-4178-b6f2-1a7762a665a8@github.com>

On Tue, 18 Apr 2023 18:40:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The upgrade to CLDR v43 was missing the license-related file updates. Here are the supplemental updates.

Marked as reviewed by srl295 at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13517#pullrequestreview-1390749259

From duke at openjdk.org  Tue Apr 18 19:26:46 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 18 Apr 2023 19:26:46 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v2]
In-Reply-To: <CFFaGDZ-RaRqCt_jUPv_e3j-e4hb7ftFnTd4oxm7M88=.db937679-4324-416c-bc18-78f025e82cf3@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <OdBP0DSFX1Y18NpEX0a0_9fdfleDxScUck4SDzK4nQ8=.03aae349-dc2a-44fa-a74d-4b7a650f1cd2@github.com>
 <tKtmu72sFvYrxBq-qja07Jorm8YOKpnCTel3vEYZ7xM=.cf4d9ba3-42ac-4eff-9122-69cb9b6df6e1@github.com>
 <D14tz4RCkzTi8GtRWYqh7D78lDPhhTFUSbaptCismP8=.ff2e18c2-7a3f-4b28-b278-5cc0586a73cd@github.com>
 <aJdN6W8q1Kd3yTWvy1qQhdjM2VY-Pogdxd5j8RXVK0M=.4afc1785-534c-4a97-8dcc-8950c7eb7d0c@github.com>
 <YAe6A3Ae_y1w7rxBzUTzgKapVaiRWxvOW-EShOZqLjw=.b8135bde-37d4-4504-b79e-90be50d7d20f@github.com>
 <CFFaGDZ-RaRqCt_jUPv_e3j-e4hb7ftFnTd4oxm7M88=.db937679-4324-416c-bc18-78f025e82cf3@github.com>
Message-ID: <m3f72NnbWZiA-pGTiRmnJ1bumivCCB62uAKPywxAJog=.1eaca6ff-a559-41a8-ae85-d3275bbb673b@github.com>

On Tue, 18 Apr 2023 09:02:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> > > Why isn't `Enum::hashCode` simply doing `return ordinal;`?
>>> > 
>>> > 
>>> > See https://bugs.openjdk.org/browse/JDK-8050217
>>> 
>>> Thanks! If there are apps where `Enum::hashCode` is performance sensitive then run-to-run stability may be a stronger argument than @stuart-marks et al argues it is here, though there might be some unspoken arguments about how it might affect iteration order et.c...
>> 
>> Identity hash code might theoretically be stable from run-to-run, but it's not like it's very stable in the first place. The hash code is generated using some thread-local state, so the value depends on how many times an identity hash code has been generated on the same thread before the hash code of the enum constant is generated (when `hashCode` is first called)
>> 
>> So, using ordinal as a hash code would, AFAICS, be no more unstable than the current implementation: if the code is altered (re-ordering the constants. Or calling hashCode for the first time at a different point in the application), the identity hash code can change. However, using the ordinal has the benefit of simplicity as well. (if anything, using the ordinal would be _more_ stable, since it is only affected by the order of the constants, rather than by other code that runs before the identity hash code is generated).
>
>> (if anything, using the ordinal would be _more_ stable, since it is only affected by the order of the constants, rather than by other code that runs before the identity hash code is generated).
> 
> Here lies the major original concern -- that I share -- about hooking up `ordinal` as `hashCode`, I think. It opens up enum for the similar sort of algorithmic collisions, perhaps even deliberate ones, like we had with `String`-s. Arguably, switching enum hashcode from IHC to ordinal is a step backwards.
> 
> Of course, as John says above, this might change when Valhalla arrives, but in that case we would give up the collision-resistant enum hashcodes for clear benefit of enums being flattened: it would be the "one step back, two steps forward" kind of deal. Today, however, there seem to be to reason to give up this resistance without getting anything in return. The "return" might have been better performance, but this PR eliminates that part as well.

@shipilev @rose00 Yes, ideally hashCode of enums should only depend on type + ordinal?as I presume that it is desirable that different enums of different types but bearing the same ordinal values shouldn't collide when mixed in a `HashMap<Enum,Object>`.

Given "on the wire" representation the information regarding type would either need to be out-of-bound or transmitted as a part of the value.

In such a case, would it not be "better" to base the HC on getClass().getName().hashCode() which is specced and stable mixed with the ordinal to improve distribution over the 32-bit space?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1513682849

From duke at openjdk.org  Tue Apr 18 19:31:53 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 18 Apr 2023 19:31:53 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v2]
In-Reply-To: <3bPjLKsXGaWR5pNgsBKNtSJE8n3Sm28K_YpPR6sHegw=.72763c8f-ec8f-4987-a6f7-dab8fb2e71b5@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <h4Hxt92uq_55x0DbUAJPizCoyNPfLkAQ5i5JZaYEykg=.31676601-f43f-4435-9738-21743d72d223@github.com>
 <3bPjLKsXGaWR5pNgsBKNtSJE8n3Sm28K_YpPR6sHegw=.72763c8f-ec8f-4987-a6f7-dab8fb2e71b5@github.com>
Message-ID: <qqghs0G-7abz2O2Rd-ucpV1d8NeLfqR8aq-warmCDQA=.a1d01733-9275-407e-844e-3a7917125672@github.com>

On Tue, 18 Apr 2023 18:19:20 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> It would be useful to obtain the zip/jar in question to validate that your proposed patch addresses the issue as well as verifying if ZipfFile can be used to process the zip/jar as reading the long thread appears that ZipFile:getInputStream is fine.

The original input file to the Tomcat Migration tool is found here:

https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-core/10.1.7/tomcat-embed-core-10.1.7.jar

I have tested reading this file using `ZipInputStream` in this PR branch and it processes the 8 byte data descriptors successfully.

> Do you know how the Zip in question is being created, is it via ApacheCommons and could there be an issue there?

The file is produced in the Tomcat Ant release targets. First, the `jar` target produces the file, followed by postprocessing by `bnd` for OSGi purposes. At this point the file is still not in ZIP64 mode. Finally, the `zip` task is used to update the jar file with some Graal releated files , and this is where the ZIP64 seems to be introduced. 

I might want to do some more investigation on the Ant side to see if this behavior could be improved.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1513687801

From iris at openjdk.org  Tue Apr 18 19:33:46 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 18 Apr 2023 19:33:46 GMT
Subject: RFR: 8306323: Update license files in CLDR v43
In-Reply-To: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
References: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
Message-ID: <9_yDCYhSWH6UDSOTfAQqyGkh8KAU2OCRUAW-D9oKrTY=.c3124de8-e14f-4631-a6f1-c1cd5f8d95f4@github.com>

On Tue, 18 Apr 2023 18:40:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The upgrade to CLDR v43 was missing the license-related file updates. Here are the supplemental updates.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13517#pullrequestreview-1390801345

From shade at openjdk.org  Tue Apr 18 19:35:48 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Apr 2023 19:35:48 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v2]
In-Reply-To: <m3f72NnbWZiA-pGTiRmnJ1bumivCCB62uAKPywxAJog=.1eaca6ff-a559-41a8-ae85-d3275bbb673b@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <OdBP0DSFX1Y18NpEX0a0_9fdfleDxScUck4SDzK4nQ8=.03aae349-dc2a-44fa-a74d-4b7a650f1cd2@github.com>
 <tKtmu72sFvYrxBq-qja07Jorm8YOKpnCTel3vEYZ7xM=.cf4d9ba3-42ac-4eff-9122-69cb9b6df6e1@github.com>
 <D14tz4RCkzTi8GtRWYqh7D78lDPhhTFUSbaptCismP8=.ff2e18c2-7a3f-4b28-b278-5cc0586a73cd@github.com>
 <aJdN6W8q1Kd3yTWvy1qQhdjM2VY-Pogdxd5j8RXVK0M=.4afc1785-534c-4a97-8dcc-8950c7eb7d0c@github.com>
 <YAe6A3Ae_y1w7rxBzUTzgKapVaiRWxvOW-EShOZqLjw=.b8135bde-37d4-4504-b79e-90be50d7d20f@github.com>
 <CFFaGDZ-RaRqCt_jUPv_e3j-e4hb7ftFnTd4oxm7M88=.db937679-4324-416c-bc18-78f025e82cf3@github.com>
 <m3f72NnbWZiA-pGTiRmnJ1bumivCCB62uAKPywxAJog=.1eaca6ff-a559-41a8-ae85-d3275bbb673b@github.com>
Message-ID: <IC2wNh-sH-y0HzFXLnpXAqdV2e_xE7wFeQzu6xGSzXI=.724deef6-3e3f-40c4-9606-6950b113fce8@github.com>

On Tue, 18 Apr 2023 19:23:59 GMT, Viktor Klang <duke at openjdk.org> wrote:

> In such a case, would it not be "better" to base the HC on getClass().getName().hashCode() which is specced and stable mixed with the ordinal to improve distribution over the 32-bit space?

Maybe, even though it still raises lots of collision-resistance questions, given that both `String` (class) name and ordinal are constructable, and have hash codes that are easy to collide. Anyhow, I strongly believe this goes way beyond the scope of this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1513688458

From shade at openjdk.org  Tue Apr 18 19:35:50 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Apr 2023 19:35:50 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v3]
In-Reply-To: <yHhmsFXr99f0Me3r4t5Ld97kjjJCIAWJ5AwO72Tgh5U=.8d43126e-c766-4366-aec6-c73072e005f8@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <jQWXWn_rma-JtYK5AlSO1W2CH8q9VAKK4DS0_Gqk26c=.428eadeb-f203-4e25-915a-a346befa3163@github.com>
 <_ddg8NNgXP2qnKZLqcf15YmiQCTgdcr1yY2P1OFJ6Ks=.d0ab6b0f-a6a5-441e-ba31-c05c8af3932f@github.com>
 <AfKZDBfg4SEXoVvC2vso3vVi9LryRJZOU74lO8K7al8=.a2148933-faaa-43cb-9be5-3c6e5c4a62a8@github.com>
 <RWHWJNE1Sw44eqSYc5y9oJL5U4GHEKcgIDgyRyBZzXE=.9ae79ef5-a564-4e06-b931-97982ec1a77e@github.com>
 <yHhmsFXr99f0Me3r4t5Ld97kjjJCIAWJ5AwO72Tgh5U=.8d43126e-c766-4366-aec6-c73072e005f8@github.com>
Message-ID: <NPqJcEtakewAkb8-AGnckQbIHK4wcqHFLzTnE0pc9_M=.c12f4c07-b0a2-4c2c-9ca6-8c2c0582aea6@github.com>

On Tue, 18 Apr 2023 17:23:54 GMT, ExE Boss <duke at openjdk.org> wrote:

>> `super.hashCode()` is a virtual call. `System.identityHashCode` is the static call. I don't understand where `invokespecial` enters the picture here.
>
> `invokespecial` is?used to?call instance?methods in?a?non?virtual?manner.
> 
> --------------------------------------------------------------------------------
> 
> Using?`super.hashCode()` in?`java.lang.Enum` produces?the?bytecode:
> 
> aload_0;
> invokespecial java/lang/Object.hashCode:()I;

I see. It does not matter here, because for performance, we largely only care about the distinction between virtual/static cases in C2 intrinsic for hashcode.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1170485705

From shade at openjdk.org  Tue Apr 18 19:38:12 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Apr 2023 19:38:12 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v3]
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Fix gtests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13225/files
  - new: https://git.openjdk.org/jdk/pull/13225/files/f4818237..33fa34f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=01-02

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13225/head:pull/13225

PR: https://git.openjdk.org/jdk/pull/13225

From mchung at openjdk.org  Tue Apr 18 19:44:45 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 18 Apr 2023 19:44:45 GMT
Subject: RFR: 8306038: SystemModulesPlugin: Keep stack clean
In-Reply-To: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>
References: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>
Message-ID: <kyYX7kVQ4WIDlWKDfpsfnAJcWvIrHfm6C1qHBl5P_QQ=.eab90350-b2ec-410c-97e3-0250e6d1df92@github.com>

On Wed, 12 Apr 2023 09:18:13 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> This refs [https://bugs.openjdk.org/browse/JDK-8306038](8306038). 
> 
> (Before this referenced 8240567)
> 
> Although this change is rather small, I think, it's good to have a "more clean" SystemModulesPlugin available.

I ran tier1-tier3 tests with your patch and all passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13442#issuecomment-1513704534

From srl at openjdk.org  Tue Apr 18 20:18:46 2023
From: srl at openjdk.org (Steven Loomis)
Date: Tue, 18 Apr 2023 20:18:46 GMT
Subject: RFR: 8306323: Update license files in CLDR v43
In-Reply-To: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
References: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
Message-ID: <oWR7w3mvahNSg8zL6U9EMKQvV-gyYFveP-JIJkIBpi0=.c1d98b3d-40a2-4bc1-b5ea-441a10dbffb6@github.com>

On Tue, 18 Apr 2023 18:40:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The upgrade to CLDR v43 was missing the license-related file updates. Here are the supplemental updates.

Marked as reviewed by srl (Committer).

[testing]

Marked as reviewed by srl (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13517#pullrequestreview-1390862217
Changes requested by srl (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13517#pullrequestreview-1390862891
PR Review: https://git.openjdk.org/jdk/pull/13517#pullrequestreview-1390863607

From srl at openjdk.org  Tue Apr 18 20:18:48 2023
From: srl at openjdk.org (Steven Loomis)
Date: Tue, 18 Apr 2023 20:18:48 GMT
Subject: RFR: 8306323: Update license files in CLDR v43
In-Reply-To: <oWR7w3mvahNSg8zL6U9EMKQvV-gyYFveP-JIJkIBpi0=.c1d98b3d-40a2-4bc1-b5ea-441a10dbffb6@github.com>
References: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
 <oWR7w3mvahNSg8zL6U9EMKQvV-gyYFveP-JIJkIBpi0=.c1d98b3d-40a2-4bc1-b5ea-441a10dbffb6@github.com>
Message-ID: <DxSc7sYAFRDBx6liZFBvHKNlvOgxQ65sNh6B-HMnChA=.7b07371e-d43c-41c6-91b7-ce660e843863@github.com>

On Tue, 18 Apr 2023 20:15:32 GMT, Steven Loomis <srl at openjdk.org> wrote:

>> The upgrade to CLDR v43 was missing the license-related file updates. Here are the supplemental updates.
>
> Marked as reviewed by srl (Committer).

- [Steven Loomis](https://openjdk.org/census#srl) (@srl295 - Committer) ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13517#issuecomment-1513743510

From vromero at openjdk.org  Tue Apr 18 20:27:47 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 18 Apr 2023 20:27:47 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
Message-ID: <86wPks_z959-kxY0Kfp8nx6IK-OvI7k7GaTt9HU-tGE=.d8ace5b0-fd4f-4c25-aa38-b7fe354e1401@github.com>

On Tue, 18 Apr 2023 09:13:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>  - Reflecting review comments.
>  - Fixing exhaustiveness for unsealed supertype pattern.
>  - No need to enable features after error reported.
>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>  - A prototype of avoiding enum initialization.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 94:

> 92:      *   <li>the element is of type {@code String} or {@code Integer} and
> 93:      *       equals to the target.</li>
> 94:      *   <li>the element is of type {@code EnumDesc}, that describes a constant that is

I think that at ~line 76, up in this same javadoc you need to add a reference to EnumDesc in the general description. Where it says:


The static arguments are an array of case labels which must be non-null and of type
{@code String} or {@code Integer} or {@code Class}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1170531849

From rriggs at openjdk.org  Tue Apr 18 20:34:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 18 Apr 2023 20:34:57 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v15]
In-Reply-To: <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
Message-ID: <0mWtWPVJ_Rb3lP1w1l5jS5C0uM8S6LbuDqoG_VoHjp4=.46e0a172-0ac8-4453-badb-fea41c4275ee@github.com>

On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs 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 8304915-arch-enum
>  - ArchTest on Debian RISC-V 64 confirmed by reviewer
>  - Fixed isPPC64().
>    Consolidated switch cases in ArchTest.
>    Moved mapping of build TARGET_OS and TARGET_CPU to the build
>    to avoid multiple mappings in more than one place.
>  - Correct mapping and test of ppc64
>  - Add ppc64 as mapping to PPC64 Architecture
>  - Modified test to check Architecture is64bits() and isLittleEndian()
>    against Unsafe respective values.
>    Relocated code mapping OS name and arch name from PlatformProps to
>    OperatingSystem and Architecture. Kept the mapping of names
>    in the template close to where the values are filled in by the build.
>  - Remove unused static and import of Stabile
>  - Rename OperatingSystemProps to PlatformProps.
>    Refactor OperatingSystem initialization to use strings instead of integers.
>  - Revised mapping mechanism of build target architecture names to enum values.
>    Unrecognized values from the build are mapped to enum value "OTHER".
>    Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
>    Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
>  - Revert changes to jdk.accessibility AccessBridge
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e

Last call for Reviewers.  Tnx

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1513760009

From naoto at openjdk.org  Tue Apr 18 21:17:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Apr 2023 21:17:45 GMT
Subject: RFR: 8305746: InitializeEncoding should cache Charset object
 instead of charset name [v2]
In-Reply-To: <O_XJ0eMteZz8UGUp948M219MSbVruXARZxgwN5uJaWw=.16adb547-c449-4007-9cbe-f04e755831ba@github.com>
References: <n_LC8ej_4-qM15pCWVFcirQyB6RNiH7xQtHiJBWNmI0=.c05c9ac5-5602-4f13-98b6-ec1a126c0975@github.com>
 <O_XJ0eMteZz8UGUp948M219MSbVruXARZxgwN5uJaWw=.16adb547-c449-4007-9cbe-f04e755831ba@github.com>
Message-ID: <c5XTNkrfnbmMYkIrnJeJ_batLoaEa7A_mVDimh9Wxvc=.8f06d03f-7d8d-46cf-bdfd-d21d786ed232@github.com>

On Tue, 18 Apr 2023 11:34:45 GMT, Peter Hofer <phofer at openjdk.org> wrote:

>> Store `Charset` object in `jnuEncoding` and use `String(byte[], Charset)` and `String.getBytes(Charset)` instead of passing the charset name.
>
> Peter Hofer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8305746: InitializeEncoding should cache Charset object instead of charset name

Looks good to me (with minor nits). Since it would be hard to write a regression test, what kind of tests have you done? Did you run your patch on platforms that made sure your new code path work?

src/java.base/share/native/libjava/jni_util.c line 628:

> 626: 
> 627: static int fastEncoding = NO_ENCODING_YET;
> 628: static jobject jnuEncoding = NULL;

Maybe `jnuCharset` is clearer that it is a `Charset` object.

src/java.base/share/native/libjava/jni_util.c line 757:

> 755:                 jnuEncoding = (*env)->NewGlobalRef(env, charset.l);
> 756:                 (*env)->DeleteLocalRef(env, charset.l);
> 757:                 break;

Could return immediately

-------------

PR Review: https://git.openjdk.org/jdk/pull/13499#pullrequestreview-1390934727
PR Review Comment: https://git.openjdk.org/jdk/pull/13499#discussion_r1170569204
PR Review Comment: https://git.openjdk.org/jdk/pull/13499#discussion_r1170568134

From erikj at openjdk.org  Tue Apr 18 21:54:57 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 18 Apr 2023 21:54:57 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v15]
In-Reply-To: <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
Message-ID: <HmrCuYFeASmQWyUayx9CEqPoAOTgGGYjzKK7xNP2ino=.9d99f952-cb89-4d6a-b6b1-47b2237d3916@github.com>

On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs 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 8304915-arch-enum
>  - ArchTest on Debian RISC-V 64 confirmed by reviewer
>  - Fixed isPPC64().
>    Consolidated switch cases in ArchTest.
>    Moved mapping of build TARGET_OS and TARGET_CPU to the build
>    to avoid multiple mappings in more than one place.
>  - Correct mapping and test of ppc64
>  - Add ppc64 as mapping to PPC64 Architecture
>  - Modified test to check Architecture is64bits() and isLittleEndian()
>    against Unsafe respective values.
>    Relocated code mapping OS name and arch name from PlatformProps to
>    OperatingSystem and Architecture. Kept the mapping of names
>    in the template close to where the values are filled in by the build.
>  - Remove unused static and import of Stabile
>  - Rename OperatingSystemProps to PlatformProps.
>    Refactor OperatingSystem initialization to use strings instead of integers.
>  - Revised mapping mechanism of build target architecture names to enum values.
>    Unrecognized values from the build are mapped to enum value "OTHER".
>    Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
>    Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
>  - Revert changes to jdk.accessibility AccessBridge
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e

Build changes look good.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1390984858

From smarks at openjdk.org  Tue Apr 18 22:15:03 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 18 Apr 2023 22:15:03 GMT
Subject: RFR: 8266571: Sequenced Collections [v6]
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: <5eEr-l6cIJ53ublp5CK0ize8fYL1l-5k2YfaG4RDMM0=.3abff6aa-c4c4-4e6b-9f8c-0682390449de@github.com>

> PR for Sequenced Collections implementation.

Stuart Marks has updated the pull request incrementally with four additional commits since the last revision:

 - Clarify LHM and LHS specs regarding semantics of reverse-ordered views.
 - Remove special-cases for reversed LHM and LHS putAll and add.
 - Minor cleanups including formatting, naming, comments, modifiers.
 - Add @implSpec to default methods where it was missing.
   Add removeFirst/removeLast default methods to NavigableSet.
   Add throwing putFirst/putLast to TreeMap & ConcurrentSkipListMap
   Add throwing addFirst/addLast to TreeSet & ConcurrentSkipListSet
   Clarify access order specification for LinkedHashMap.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7387/files
  - new: https://git.openjdk.org/jdk/pull/7387/files/1332c3e2..0b8e6dfe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=04-05

  Stats: 351 lines in 18 files changed: 290 ins; 13 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/7387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/7387/head:pull/7387

PR: https://git.openjdk.org/jdk/pull/7387

From vromero at openjdk.org  Tue Apr 18 22:18:48 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 18 Apr 2023 22:18:48 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
Message-ID: <dE1Bp9jAexjQnXMa_Xd530RnrFc568WvYGlMCXFUVj0=.c44870c0-29d4-4db5-b7c6-bf341da14916@github.com>

On Tue, 18 Apr 2023 09:13:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>  - Reflecting review comments.
>  - Fixing exhaustiveness for unsealed supertype pattern.
>  - No need to enable features after error reported.
>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>  - A prototype of avoiding enum initialization.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 149:

> 147:             throw new IllegalArgumentException("label with illegal type found: " + label.getClass());
> 148:         }
> 149:     }

side: are there any cases for which the `startIndex` argument passed to method `doTypeSwitch` is not `0`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1170618764

From mcimadamore at openjdk.org  Tue Apr 18 22:20:48 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Apr 2023 22:20:48 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v5]
In-Reply-To: <DD0nvfK8sVvqOdwEKyIzOz1mRkSnRD63xf34EFDXvkE=.c73f7231-a80d-4d71-9586-b27e67f4a5f3@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
 <DD0nvfK8sVvqOdwEKyIzOz1mRkSnRD63xf34EFDXvkE=.c73f7231-a80d-4d71-9586-b27e67f4a5f3@github.com>
Message-ID: <ro98kdnxpFUFHxlbire-LCADfFhx4EfRTi6o0YWAhak=.9c7ed81b-64aa-494f-a456-53124ce38f02@github.com>

On Tue, 18 Apr 2023 13:45:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch adds checks in AbstractLinker to reject packed structs and structs with excess padding (e.g. unnamed bitfields), since both of those are currently not supported, and the ABI/spec seems too vague to base support on.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - fix TestIllegalLink
>  - Merge branch 'PR_21' into RejectPacked
>  - Merge branch 'PR_21' into RejectPacked
>  - add javadoc + fixes for trailing padding
>  - fix check for padding. Add check for trailing padding too
>  - Reject packed structs and structs with extra padding
>  - Check byte order of layouts passed to linker

src/java.base/share/classes/java/lang/foreign/Linker.java line 200:

> 198:  * </table></blockquote>
> 199:  * <p>
> 200:  * Due to limited ABI specification coverage, all the native linker implementations limit the function

`All the native linker implementations support function function descriptors that contain only so-called...`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13164#discussion_r1170619687

From mcimadamore at openjdk.org  Tue Apr 18 22:28:47 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Apr 2023 22:28:47 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v5]
In-Reply-To: <DD0nvfK8sVvqOdwEKyIzOz1mRkSnRD63xf34EFDXvkE=.c73f7231-a80d-4d71-9586-b27e67f4a5f3@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
 <DD0nvfK8sVvqOdwEKyIzOz1mRkSnRD63xf34EFDXvkE=.c73f7231-a80d-4d71-9586-b27e67f4a5f3@github.com>
Message-ID: <L3i2q92HgKXJeg_mm5pak7g1Rb59_Vt0VtJGjcUQ5ds=.ffb1e341-f694-4bae-af3c-0bc5f08e750e@github.com>

On Tue, 18 Apr 2023 13:45:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch adds checks in AbstractLinker to reject packed structs and structs with excess padding (e.g. unnamed bitfields), since both of those are currently not supported, and the ABI/spec seems too vague to base support on.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - fix TestIllegalLink
>  - Merge branch 'PR_21' into RejectPacked
>  - Merge branch 'PR_21' into RejectPacked
>  - add javadoc + fixes for trailing padding
>  - fix check for padding. Add check for trailing padding too
>  - Reject packed structs and structs with extra padding
>  - Check byte order of layouts passed to linker

src/java.base/share/classes/java/lang/foreign/Linker.java line 202:

> 200:  * Due to limited ABI specification coverage, all the native linker implementations limit the function
> 201:  * descriptors that they support to those that contain only so-called <em>canonical</em> layouts. These layouts
> 202:  * have the following restrictions:

I think it's better to phrase this more or less as:

A canonical layout has the following characteristics:
* Its alignment constraint is equal to its natural alignment
* If the layout is a value layout (linkplain), its byte order matches that of the platform in which the JVM is executing (link to nativeOrder())
*  If the layout is a group layout (linkplain), it must not contain more padding layout (linkplain) elements than those strictly necessary to satisfy the alignment constraints of the non-padding elements of the group layout.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13164#discussion_r1170624323

From mcimadamore at openjdk.org  Tue Apr 18 22:28:48 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Apr 2023 22:28:48 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v5]
In-Reply-To: <L3i2q92HgKXJeg_mm5pak7g1Rb59_Vt0VtJGjcUQ5ds=.ffb1e341-f694-4bae-af3c-0bc5f08e750e@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
 <DD0nvfK8sVvqOdwEKyIzOz1mRkSnRD63xf34EFDXvkE=.c73f7231-a80d-4d71-9586-b27e67f4a5f3@github.com>
 <L3i2q92HgKXJeg_mm5pak7g1Rb59_Vt0VtJGjcUQ5ds=.ffb1e341-f694-4bae-af3c-0bc5f08e750e@github.com>
Message-ID: <9PSdCi4zwiha6GclDU4KfSCwSjZebxAlWLMinhrSF_A=.a2f8ef6a-031e-4a8b-9886-a8a3d3b9aec4@github.com>

On Tue, 18 Apr 2023 22:25:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - fix TestIllegalLink
>>  - Merge branch 'PR_21' into RejectPacked
>>  - Merge branch 'PR_21' into RejectPacked
>>  - add javadoc + fixes for trailing padding
>>  - fix check for padding. Add check for trailing padding too
>>  - Reject packed structs and structs with extra padding
>>  - Check byte order of layouts passed to linker
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 202:
> 
>> 200:  * Due to limited ABI specification coverage, all the native linker implementations limit the function
>> 201:  * descriptors that they support to those that contain only so-called <em>canonical</em> layouts. These layouts
>> 202:  * have the following restrictions:
> 
> I think it's better to phrase this more or less as:
> 
> A canonical layout has the following characteristics:
> * Its alignment constraint is equal to its natural alignment
> * If the layout is a value layout (linkplain), its byte order matches that of the platform in which the JVM is executing (link to nativeOrder())
> *  If the layout is a group layout (linkplain), it must not contain more padding layout (linkplain) elements than those strictly necessary to satisfy the alignment constraints of the non-padding elements of the group layout.

Also, isn't it the case that, for structs, we want the size of the layout to be a multiple of its alignment constraint?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13164#discussion_r1170624776

From mcimadamore at openjdk.org  Tue Apr 18 22:34:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Apr 2023 22:34:50 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v5]
In-Reply-To: <DD0nvfK8sVvqOdwEKyIzOz1mRkSnRD63xf34EFDXvkE=.c73f7231-a80d-4d71-9586-b27e67f4a5f3@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
 <DD0nvfK8sVvqOdwEKyIzOz1mRkSnRD63xf34EFDXvkE=.c73f7231-a80d-4d71-9586-b27e67f4a5f3@github.com>
Message-ID: <SqYeT2M-1hc_9YmZYxfROlds6BUkQaN5XUQ2pdW4WPM=.819d4d96-d98d-45dc-9442-680e314b2edd@github.com>

On Tue, 18 Apr 2023 13:45:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch adds checks in AbstractLinker to reject packed structs and structs with excess padding (e.g. unnamed bitfields), since both of those are currently not supported, and the ABI/spec seems too vague to base support on.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - fix TestIllegalLink
>  - Merge branch 'PR_21' into RejectPacked
>  - Merge branch 'PR_21' into RejectPacked
>  - add javadoc + fixes for trailing padding
>  - fix check for padding. Add check for trailing padding too
>  - Reject packed structs and structs with extra padding
>  - Check byte order of layouts passed to linker

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 120:

> 118:     private void checkLayoutsRecursive(MemoryLayout layout) {
> 119:         checkHasNaturalAlignment(layout);
> 120:         checkByteOrder(layout);

for uniformity, shoudn't this check be inside an `if (layout instanceof ValueLayout) ...` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13164#discussion_r1170628266

From psandoz at openjdk.org  Tue Apr 18 23:04:43 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 18 Apr 2023 23:04:43 GMT
Subject: RFR: 8306008: Several Vector API tests fail for client VM after
 JDK-8304450
In-Reply-To: <TDcfSAbMANHhRfHfZSAoKxfHPrsVqHrbE0gz1RwUBcg=.de344a1c-8d0e-477b-b8a2-209595967254@github.com>
References: <TDcfSAbMANHhRfHfZSAoKxfHPrsVqHrbE0gz1RwUBcg=.de344a1c-8d0e-477b-b8a2-209595967254@github.com>
Message-ID: <N8Wue6_EP4R9WNNlk4bDhpgvT4p6YJppoZ4PcwtSSRw=.f3f18ca9-0ab6-4f55-953c-ef05985d9196@github.com>

On Tue, 18 Apr 2023 12:21:11 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Please review this patch which fixes the errors on machines where TypeMaxVector has a length of 64 bits. I take an extra cautious approach and fall back to putting elements one by one if the length is an unexpected value.
> 
> All jdk/incubator/vector tests passed with MaxVectorSize=8, which fails without this patch.
> 
> Thanks a lot.

Looks good.

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13508#pullrequestreview-1391044568

From liach at openjdk.org  Wed Apr 19 01:11:00 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Apr 2023 01:11:00 GMT
Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API [v7]
In-Reply-To: <3PN6riy9fxQHRz1646Xi5fo-V7pTeF_r4Ojgt3yMRtg=.eb0d3145-3d0c-4c3e-b158-d836f7460110@github.com>
References: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
 <3PN6riy9fxQHRz1646Xi5fo-V7pTeF_r4Ojgt3yMRtg=.eb0d3145-3d0c-4c3e-b158-d836f7460110@github.com>
Message-ID: <jW19W0aUQvHZWqZ-UmTmnJyAs5zLpVzibK9_SXBNRm8=.5a2b5495-5a5b-4a29-8f90-c0a6a5285f5d@github.com>

On Tue, 21 Mar 2023 21:39:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Summaries:
>> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before
>> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API.
>> 3. Most tests are included in tier1, but some are not:
>> In `:jdk_io`: (tier2, part 2)
>> 
>> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
>> test/jdk/java/io/Serializable/records/ProhibitedMethods.java
>> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
>> 
>> In `:jdk_instrument`: (tier 3)
>> 
>> test/jdk/java/lang/instrument/RetransformAgent.java
>> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
>> test/jdk/java/lang/instrument/asmlib/Instrumentor.java
>> 
>> 
>> @asotona Would you mind reviewing?
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Switch to ConstantDescs for <init> <clinit> and void constants
>  - Merge AnnotationsTest, remove ModuleTargetAttribute call
>  - Merge branch 'invoke-test-classfile' of https://github.com/liachmodded/jdk into invoke-test-classfile
>  - Update test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Merge branch 'master' into invoke-test-classfile
>  - Fix LambdaStackTrace after running
>  - formatting
>  - Fix failed LambdaStackTrace test, use more convenient APIs
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into invoke-test-classfile
>  - Shorten lines, move from mask() to ACC_ constants, other misc improvements
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/0deb6489...7dc785b3

keep alive. this might not be integrated until classfile api has been previewed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13009#issuecomment-1513989606

From liach at openjdk.org  Wed Apr 19 02:17:57 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Apr 2023 02:17:57 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v3]
In-Reply-To: <NPqJcEtakewAkb8-AGnckQbIHK4wcqHFLzTnE0pc9_M=.c12f4c07-b0a2-4c2c-9ca6-8c2c0582aea6@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <jQWXWn_rma-JtYK5AlSO1W2CH8q9VAKK4DS0_Gqk26c=.428eadeb-f203-4e25-915a-a346befa3163@github.com>
 <_ddg8NNgXP2qnKZLqcf15YmiQCTgdcr1yY2P1OFJ6Ks=.d0ab6b0f-a6a5-441e-ba31-c05c8af3932f@github.com>
 <AfKZDBfg4SEXoVvC2vso3vVi9LryRJZOU74lO8K7al8=.a2148933-faaa-43cb-9be5-3c6e5c4a62a8@github.com>
 <RWHWJNE1Sw44eqSYc5y9oJL5U4GHEKcgIDgyRyBZzXE=.9ae79ef5-a564-4e06-b931-97982ec1a77e@github.com>
 <yHhmsFXr99f0Me3r4t5Ld97kjjJCIAWJ5AwO72Tgh5U=.8d43126e-c766-4366-aec6-c73072e005f8@github.com>
 <NPqJcEtakewAkb8-AGnckQbIHK4wcqHFLzTnE0pc9_M=.c12f4c07-b0a2-4c2c-9ca6-8c2c0582aea6@github.com>
Message-ID: <qQMQOn1H9N48lvPQ6na0U52xsjdl5CnCQvzVx9Jp26s=.114f1095-0913-463d-bebd-cddbb45a8a0a@github.com>

On Tue, 18 Apr 2023 19:32:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> `invokespecial` is?used to?call instance?methods in?a?non?virtual?manner.
>> 
>> --------------------------------------------------------------------------------
>> 
>> Using?`super.hashCode()` in?`java.lang.Enum` produces?the?bytecode:
>> 
>> aload_0;
>> invokespecial java/lang/Object.hashCode:()I;
>
> I see. It does not matter here, because for performance, we largely only care about the distinction between virtual/static cases in C2 intrinsic for hashcode.

Also fyi invokespecial now can be virtual calls (mainly calling private methods in the nest) since introduction of nestmates.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13491#discussion_r1170735370

From smarks at openjdk.org  Wed Apr 19 02:18:11 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 19 Apr 2023 02:18:11 GMT
Subject: RFR: 8266571: Sequenced Collections [v6]
In-Reply-To: <bjHr9kQ6PfiSzt5IqgFWisQqzk_Jiawi5jGCDOKgeXI=.44293975-edcb-42de-99dd-9b7590b86914@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <bjHr9kQ6PfiSzt5IqgFWisQqzk_Jiawi5jGCDOKgeXI=.44293975-edcb-42de-99dd-9b7590b86914@github.com>
Message-ID: <C-0jFPcA_6K7wzUJtMNYuJAjHH9f21C7x44TRoumlVE=.ddaf7124-5c3c-4279-8b88-faca8ccba7e3@github.com>

On Fri, 24 Mar 2023 21:57:40 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Clarify LHM and LHS specs regarding semantics of reverse-ordered views.
>>  - Remove special-cases for reversed LHM and LHS putAll and add.
>>  - Minor cleanups including formatting, naming, comments, modifiers.
>>  - Add @implSpec to default methods where it was missing.
>>    Add removeFirst/removeLast default methods to NavigableSet.
>>    Add throwing putFirst/putLast to TreeMap & ConcurrentSkipListMap
>>    Add throwing addFirst/addLast to TreeSet & ConcurrentSkipListSet
>>    Clarify access order specification for LinkedHashMap.
>
> src/java.base/share/classes/java/util/ReverseOrderDequeView.java line 103:
> 
>> 101:     }
>> 102: 
>> 103:     // copied from AbstractCollection
> 
> Probably not the part of this PR, but it could be reasonable to create some utility CollectionSupport class and create static methods (e.g. `static boolean remove(Collection<?> c, Object o)`) with the implementations of common collection algorithms, like this one. WDYT?

Probably. I think I'll definitely need to do that with the spliterators, and likely also with other interating and bulk operations such as this one. But yes, not part of this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1170735013

From smarks at openjdk.org  Wed Apr 19 02:44:09 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 19 Apr 2023 02:44:09 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: <XQrl8O2c4aNvXCac0lNsK1ee8BSL94-JbGmiGPVaniQ=.a6aefeb5-3828-4bc3-9bf9-99d93c2fc368@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <AVG0xaAX6FZuBx6zF9rv4HYkltv47a1-uGPJazz0avc=.b2c275f6-807b-4817-89b1-8fc3374de933@github.com>
 <XQrl8O2c4aNvXCac0lNsK1ee8BSL94-JbGmiGPVaniQ=.a6aefeb5-3828-4bc3-9bf9-99d93c2fc368@github.com>
Message-ID: <wkdXEl8MLGmt9oJx-u7f-HoZmrAm8jgHBv0UFdhcLqY=.fe86b655-7159-4495-9d21-0021793688ed@github.com>

On Sat, 25 Mar 2023 07:19:49 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - More specification tweaks.
>>  - Add simple overrides to ArrayList.
>
> src/java.base/share/classes/java/util/Collections.java line 6023:
> 
>> 6021:      */
>> 6022:     private static class SequencedSetFromMap<E> extends SetFromMap<E> implements SequencedSet<E> {
>> 6023:         private final E nsee(Map.Entry<E, Boolean> e) {
> 
> `static` instead of `final`

Can't be static because it needs to have type variable E in scope.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1170750250

From darcy at openjdk.org  Wed Apr 19 02:52:46 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 19 Apr 2023 02:52:46 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v9]
In-Reply-To: <tSOY4bLeZKlucGnZHlKrhI0z9fUwSva5UyGrRAlp_4M=.ce362a15-9aa0-4f19-9f80-4a9ecb9794cd@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <tSOY4bLeZKlucGnZHlKrhI0z9fUwSva5UyGrRAlp_4M=.ce362a15-9aa0-4f19-9f80-4a9ecb9794cd@github.com>
Message-ID: <JuQJsyUzmokVAcuBBTKNp-Esy7iLZG7RcHTi61RK_OY=.b1910d3b-64ed-4c2c-971a-e6253b8acb2d@github.com>

On Tue, 18 Apr 2023 07:27:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
>> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`.
>> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>>  
>> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
>> 
>>     ResolvedJavaMethod method = ...;
>>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>>     return switch (a.kind()) {
>>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The same code using the new API:
>> 
>> 
>>     ResolvedJavaMethod method = ...;
>>     ResolvedJavaType explodeLoopType = ...;
>>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>>     return switch (a.getEnum("kind").getName()) {
>>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.
>
> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - added breadcrumb in AnnotationParser about considering JVMCI should new annotation element types be added
>  - fixed javadoc comment

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12810#pullrequestreview-1391189154

From smarks at openjdk.org  Wed Apr 19 02:58:11 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 19 Apr 2023 02:58:11 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: <QzEjdyEzPzOPJq9Z01nsIcMDAIhzamM3wkHTdX8KTl4=.eb101a67-63dc-41ea-9e1d-709cf3366c98@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <AVG0xaAX6FZuBx6zF9rv4HYkltv47a1-uGPJazz0avc=.b2c275f6-807b-4817-89b1-8fc3374de933@github.com>
 <QzEjdyEzPzOPJq9Z01nsIcMDAIhzamM3wkHTdX8KTl4=.eb101a67-63dc-41ea-9e1d-709cf3366c98@github.com>
Message-ID: <J8lIHB1anY5NocXSSpu3y3K_L-dFZ7boHlVn4BGcc9o=.0c7b702f-5710-4d7e-a588-e7a3a5c93d29@github.com>

On Sat, 25 Mar 2023 07:25:33 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - More specification tweaks.
>>  - Add simple overrides to ArrayList.
>
> src/java.base/share/classes/java/util/LinkedHashSet.java line 297:
> 
>> 295:      */
>> 296:     public SequencedSet<E> reversed() {
>> 297:         class ReverseLinkedHashSetView extends AbstractSet<E> implements SequencedSet<E> {
> 
> This class should be declared `static` (and private) which means it should not be declared inside reversed.

Can't be static because it uses type variable `E` and also refers to `this`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1170751498

From smarks at openjdk.org  Wed Apr 19 02:58:16 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 19 Apr 2023 02:58:16 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <C2u66ylWBUFGree3MofE_kPuVg325Jr9xcXOhAr9hwg=.78835d20-9032-4e40-ad00-7a51b0b64a26@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 <C2u66ylWBUFGree3MofE_kPuVg325Jr9xcXOhAr9hwg=.78835d20-9032-4e40-ad00-7a51b0b64a26@github.com>
Message-ID: <vkhTosjfxEr5ITiK9QyQk0KRc-pR5fn36I5lcv8X4xk=.6a4e247e-f8f4-467f-9b1e-79701c648dc7@github.com>

On Thu, 30 Mar 2023 09:23:04 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> 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.
>
> src/java.base/share/classes/java/util/SequencedCollection.java line 45:
> 
>> 43:  * required to operate on elements in encounter order include the following:
>> 44:  * {@link Iterable#forEach forEach}, {@link Collection#parallelStream parallelStream},
>> 45:  * {@link Collection#spliterator spliterator}, {@link Collection#stream stream},
> 
> Should we require in specification that the implementations of `SequencedCollection::spliterator` must have the `ORDERED` charactersitic?

In principle yes, and for some spliterators the characteristics are specified. But there are a bunch of issues in JDK regarding spliterators that seem like they ought to have certain characteristics present but in fact do not. And also, most of the spliterator characteristics aren't used. They're mostly optimization hints anyway. I'm reluctant to add requirements for characteristics that might generate a bunch of testable assertions that will need to be met, generating a lot of work for not much gain. But overall spliterator characteristics should be revisited across the JDK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1170756176

From dzhang at openjdk.org  Wed Apr 19 03:06:43 2023
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 19 Apr 2023 03:06:43 GMT
Subject: RFR: 8306008: Several Vector API tests fail for client VM after
 JDK-8304450
In-Reply-To: <TDcfSAbMANHhRfHfZSAoKxfHPrsVqHrbE0gz1RwUBcg=.de344a1c-8d0e-477b-b8a2-209595967254@github.com>
References: <TDcfSAbMANHhRfHfZSAoKxfHPrsVqHrbE0gz1RwUBcg=.de344a1c-8d0e-477b-b8a2-209595967254@github.com>
Message-ID: <vCiz3SbxlsBnmGcIyoAl77at10nZ0zfok8Q2avZTYzg=.2b50c969-c76c-481c-af74-b20d3e82e1d0@github.com>

On Tue, 18 Apr 2023 12:21:11 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Please review this patch which fixes the errors on machines where TypeMaxVector has a length of 64 bits. I take an extra cautious approach and fall back to putting elements one by one if the length is an unexpected value.
> 
> All jdk/incubator/vector tests passed with MaxVectorSize=8, which fails without this patch.
> 
> Thanks a lot.

Thanks for this patch! This PR fixes the issue on RISC-V (qemu and unmatched without useRVV).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13508#issuecomment-1514068455

From vromero at openjdk.org  Wed Apr 19 03:33:49 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 19 Apr 2023 03:33:49 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
Message-ID: <83Wk_vnUqk8YZ-gudlkIDQATpbIAXGkvs-jisf3k9kA=.cc78a51a-754c-4f6f-9cff-4e7291631b1d@github.com>

On Tue, 18 Apr 2023 09:13:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>  - Reflecting review comments.
>  - Fixing exhaustiveness for unsealed supertype pattern.
>  - No need to enable features after error reported.
>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>  - A prototype of avoiding enum initialization.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 271:

> 269:                                                    ", expected the provided enum class: " + enumClassTemplate);
> 270:             }
> 271:         } else if (labelClass == String.class) {

I think that if the condition is changed to `labelClass != String.class` then `throw` we can drop an `else` branch

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1170770395

From smarks at openjdk.org  Wed Apr 19 03:37:05 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 19 Apr 2023 03:37:05 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>

> PR for Sequenced Collections implementation.

Stuart Marks has updated the pull request incrementally with three additional commits since the last revision:

 - Remove unnecessary 'final' from a couple places.
 - Clarify ordering of Collection.addAll and Map.putAll; add links to
   encounter order.
 - Make constructors private for several reverse-ordered views.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7387/files
  - new: https://git.openjdk.org/jdk/pull/7387/files/0b8e6dfe..364c2d00

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=05-06

  Stats: 28 lines in 8 files changed: 9 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/7387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/7387/head:pull/7387

PR: https://git.openjdk.org/jdk/pull/7387

From vromero at openjdk.org  Wed Apr 19 04:09:47 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 19 Apr 2023 04:09:47 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
Message-ID: <wjSlPu3uSsQgLS31xyP2xaY7SeTazIn-QbyGRSRUbEg=.780fd41d-86ea-4267-af37-81a0e41f9739@github.com>

On Tue, 18 Apr 2023 09:13:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>  - Reflecting review comments.
>  - Fixing exhaustiveness for unsealed supertype pattern.
>  - No need to enable features after error reported.
>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>  - A prototype of avoiding enum initialization.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 170:

> 168:             } else if (label instanceof EnumDesc<?> enumDesc) {
> 169:                 if (target.getClass().isEnum() &&
> 170:                     ((Enum<?>) target).describeConstable().stream().anyMatch(d -> d.equals(enumDesc))) {

probably a matter of style but isn't it a bit too much to use streams here? there will be always only one element right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1170784311

From liach at openjdk.org  Wed Apr 19 04:11:04 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Apr 2023 04:11:04 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
Message-ID: <HbVwzZcESf2OXeCF2hL3cbjGhkqqRlCgZG3iiLC6y7s=.3fd0596c-90a2-4db9-a022-cbfcdaeefe29@github.com>

On Wed, 19 Apr 2023 03:37:05 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unnecessary 'final' from a couple places.
>  - Clarify ordering of Collection.addAll and Map.putAll; add links to
>    encounter order.
>  - Make constructors private for several reverse-ordered views.

Quick question: In your updated specdiff in the CSR, I don't see `Since: 21` on `CopyOnWriteArrayList.reversed()`, while it's supposed to inherit the `@since 21` from `List.reversed()`. Is that a bug with specdiff or javadoc tool? Can you check how it renders in the API specifications?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1514104176

From vromero at openjdk.org  Wed Apr 19 04:23:51 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 19 Apr 2023 04:23:51 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
Message-ID: <1wHPrQ0Ze1bFFpWE7tocbvOC-B3juu5clCXTzYdtJCA=.0b3c021c-a524-42aa-a9ee-b439a40211e8@github.com>

On Tue, 18 Apr 2023 09:13:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>  - Reflecting review comments.
>  - Fixing exhaustiveness for unsealed supertype pattern.
>  - No need to enable features after error reported.
>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>  - A prototype of avoiding enum initialization.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 263:

> 261:     private static <E extends Enum<E>> void validateEnumLabel(Class<?> enumClassTemplate, Object label) {
> 262:         if (label == null) {
> 263:             throw new IllegalArgumentException("null label found");

I think that this one is not hit by any test

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 274:

> 272:             //OK
> 273:         } else {
> 274:             throw new IllegalArgumentException("label with illegal type found: " + labelClass +

I think that this code is not being tested by any test

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1170788337
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1170786847

From liach at openjdk.org  Wed Apr 19 04:41:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Apr 2023 04:41:10 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
Message-ID: <UQFv9mQcYOEgU_FMhks5VpQ5n52_eKtQ-SkVFWIJxfA=.f210d862-89a9-4da8-be7b-41edfa06fb39@github.com>

On Wed, 19 Apr 2023 03:37:05 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unnecessary 'final' from a couple places.
>  - Clarify ordering of Collection.addAll and Map.putAll; add links to
>    encounter order.
>  - Make constructors private for several reverse-ordered views.

src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 409:

> 407:      * {@inheritDoc}
> 408:      */
> 409:     public E getFirst() {

Javadoc will automatically copy the specification from the overridden method, so the javadoc block is not necessary and can be replaced by an `@Override` to indicate inheritance.

src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 1716:

> 1714:      * in the reversed view. Sublists and iterators of the reversed view have
> 1715:      * the same restrictions as those of this list.
> 1716:      */

Suggestion:

     *
     * @since 21
     */

Per [8029241](https://bugs.openjdk.org/browse/JDK-8029241?focusedCommentId=14492604&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14492604), `@since` tags are not inherited at all and must be manually specified each time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1170797315
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1170797866

From dholmes at openjdk.org  Wed Apr 19 06:17:52 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Apr 2023 06:17:52 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v3]
In-Reply-To: <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>
Message-ID: <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>

On Tue, 18 Apr 2023 19:38:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
>> 
>> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
>> 
>> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
>> 
>> Additional testing:
>>   - [x] New regression test
>>   - [x] New benchmark
>>   - [x] Linux x86_64 `tier1`
>>   - [x] Linux AArch64 `tier1`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix gtests

You seemed to have missed:

./cpu/x86/rdtsc_x86.cpp:    JavaThread::current()->sleep(FT_SLEEP_MILLISECS);
./share/compiler/compileBroker.cpp:  sleep(DeoptimizeObjectsALotInterval);

so not sure how this is building ???

A few other comments below.

Thanks

src/hotspot/os/posix/os_posix.cpp line 1545:

> 1543: 
> 1544: int PlatformEvent::park_nanos(jlong nanos) {
> 1545:   assert(0 <= nanos, "nanos are in range");

`nanos` should never be zero else you call the untimed park.

src/hotspot/os/posix/park_posix.hpp line 57:

> 55:   void park();
> 56:   int  park_millis(jlong millis);
> 57:   int  park_nanos(jlong nanos);

Still not sure we need this API split but if we keep `park(jlong millis)` and just add `park_nanos(jlong nanos)` then you can avoid touching so many places in the code.

src/hotspot/os/windows/os_windows.cpp line 5253:

> 5251: 
> 5252: int PlatformEvent::park_nanos(jlong nanos) {
> 5253:   assert(0 <= nanos, "nanos are in range");

`nanos` should never be zero else you call the untimed park.

src/hotspot/os/windows/os_windows.cpp line 5257:

> 5255:   // Windows timers are still quite unpredictable to handle sub-millisecond granularity.
> 5256:   // Instead of implementing this method, fall back to the millisecond sleep, treating
> 5257:   // any positive requested nanos as a full millisecond.

Is this how the code currently works?

src/hotspot/os/windows/os_windows.cpp line 5259:

> 5257:   // any positive requested nanos as a full millisecond.
> 5258:   jlong millis = align_up(nanos, NANOSECS_PER_MILLISEC) / NANOSECS_PER_MILLISEC;
> 5259:   assert(nanos == 0 || millis != 0, "Only pass zero millis on zero nanos");

Not sure what this is trying to check.

Nit: s/on/or/

src/hotspot/share/runtime/javaThread.hpp line 1145:

> 1143: public:
> 1144:   bool sleep_millis(jlong millis);
> 1145:   bool sleep_nanos(jlong nanos);

I prefer just one sleep that takes nanos.

src/java.base/share/classes/java/lang/Thread.java line 576:

> 574:         long millis = NANOSECONDS.toMillis(nanos);
> 575:         nanos -= MILLISECONDS.toNanos(millis);
> 576:         sleep(millis, (int)nanos);

This double conversion seems  a bit kludgy - why not just keep the vthread check and call `sleep0(nanos)`?

test/jdk/java/lang/Thread/SleepSanity.java line 75:

> 73:     }
> 74: 
> 75:     private static void testTimes(TestCase t, long min, long max) throws Exception {

Not obvious without reading all the code that min and max are in ms. `msMin` and `msMax` might be clearer.

test/jdk/java/lang/Thread/SleepSanity.java line 84:

> 82:     }
> 83: 
> 84:     private static void testTimeout(TestCase t, long timeout) throws Exception {

Suggestion: s/timeout/millis/ again so unit is clear.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13225#pullrequestreview-1391285246
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1170851742
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1170827783
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1170840798
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1170824754
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1170841030
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1170846464
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1170831695
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1170835700
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1170835903

From dholmes at openjdk.org  Wed Apr 19 06:17:54 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Apr 2023 06:17:54 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v3]
In-Reply-To: <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>
 <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
Message-ID: <OL3lA_22HCBqzonvN6t4TKcoy0xW9r2UP2UFJQxLG70=.647e2ccb-be34-4a3c-b0c3-fae730a5b8ee@github.com>

On Wed, 19 Apr 2023 05:31:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix gtests
>
> src/hotspot/os/windows/os_windows.cpp line 5257:
> 
>> 5255:   // Windows timers are still quite unpredictable to handle sub-millisecond granularity.
>> 5256:   // Instead of implementing this method, fall back to the millisecond sleep, treating
>> 5257:   // any positive requested nanos as a full millisecond.
> 
> Is this how the code currently works?

Hmmm I changed that comment ...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1170848229

From dholmes at openjdk.org  Wed Apr 19 06:17:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Apr 2023 06:17:55 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v3]
In-Reply-To: <OL3lA_22HCBqzonvN6t4TKcoy0xW9r2UP2UFJQxLG70=.647e2ccb-be34-4a3c-b0c3-fae730a5b8ee@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>
 <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
 <OL3lA_22HCBqzonvN6t4TKcoy0xW9r2UP2UFJQxLG70=.647e2ccb-be34-4a3c-b0c3-fae730a5b8ee@github.com>
Message-ID: <Ji_swKc708i16wMdJBujYQKjgTrcMx1cRq6E6Y5roNk=.f265e728-09bf-4dd9-a944-3335a613a6eb@github.com>

On Wed, 19 Apr 2023 06:09:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 5257:
>> 
>>> 5255:   // Windows timers are still quite unpredictable to handle sub-millisecond granularity.
>>> 5256:   // Instead of implementing this method, fall back to the millisecond sleep, treating
>>> 5257:   // any positive requested nanos as a full millisecond.
>> 
>> Is this how the code currently works?
>
> Hmmm I changed that comment ...

My actual comment was changed to:
> I suggest extending the comment to add

This is how Thread.sleep(millis, nanos) has always behaved with only millisecond granularity.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1170850062

From stsypanov at openjdk.org  Wed Apr 19 06:28:45 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 19 Apr 2023 06:28:45 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v2]
In-Reply-To: <VENDtZkxIpFevgc-FaY3nL-RzOjyoo-ioPEfvLV_USw=.9e4beaae-ed0f-4015-9c37-023b19d09ac8@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
 <KR4jLIdgm_Y49RQkIJ9uNHqemm01aE81GRBVz6XznJ8=.c2e99c6d-2fb2-44ce-b23d-6461fac68ff4@github.com>
 <3Im4RP5-AmauuIjCVgA3V4h0HellqriqIlbTSjXjrWU=.a3b7c98f-276a-423a-8d48-c3415633b2cc@github.com>
 <_gJmYty5eyRbpGo3AIlFE4HDkmGWAWPsAOqwJri3mqo=.70b5927c-2be5-484c-98f4-f21933166c55@github.com>
 <8-pc62MG2Qcj0reM0zl85Kunw2rZlQOMVZHyjKKSSSY=.4af17266-9d26-42e3-a357-fcda22f1fd5b@github.com>
 <MGPD9mADC-45XPxBYAMM6nRIPJ3oKAwwPcOofSkzmiw=.b54f5929-1992-4089-9a6b-743bd2643a2d@github.com>
 <0tZH5cpkJrPjxa3UNQ3MC0LvRkFGIs2W5v21v4GS1pA=.1dd39ae4-d6cd-4356-a9cc-5b83832d4319@github.com>
 <VENDtZkxIpFevgc-FaY3nL-RzOjyoo-ioPEfvLV_USw=.9e4beaae-ed0f-4015-9c37-023b19d09ac8@github.com>
Message-ID: <D0253hmZS62g441iW0vmGh0mPPfbFKznYZlmrLgyMkI=.2520d83c-a677-4213-9f2f-9885c19c39ce@github.com>

On Mon, 17 Apr 2023 15:21:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> @RogerRiggs sorry I don't get it. Maybe you mean speacial casing for `padWidth - len`?
>
> Yes, I meant on the length of the inserted padding.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1170860774

From phofer at openjdk.org  Wed Apr 19 06:53:45 2023
From: phofer at openjdk.org (Peter Hofer)
Date: Wed, 19 Apr 2023 06:53:45 GMT
Subject: RFR: 8305746: InitializeEncoding should cache Charset object
 instead of charset name [v2]
In-Reply-To: <c5XTNkrfnbmMYkIrnJeJ_batLoaEa7A_mVDimh9Wxvc=.8f06d03f-7d8d-46cf-bdfd-d21d786ed232@github.com>
References: <n_LC8ej_4-qM15pCWVFcirQyB6RNiH7xQtHiJBWNmI0=.c05c9ac5-5602-4f13-98b6-ec1a126c0975@github.com>
 <O_XJ0eMteZz8UGUp948M219MSbVruXARZxgwN5uJaWw=.16adb547-c449-4007-9cbe-f04e755831ba@github.com>
 <c5XTNkrfnbmMYkIrnJeJ_batLoaEa7A_mVDimh9Wxvc=.8f06d03f-7d8d-46cf-bdfd-d21d786ed232@github.com>
Message-ID: <-5FJaGjKracEn1TuejgAwOfz_6VYHdC2o-OFWHJt1uo=.5cf6a646-b835-4f6a-8cbb-9a0ba3b25482@github.com>

On Tue, 18 Apr 2023 21:04:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Peter Hofer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   8305746: InitializeEncoding should cache Charset object instead of charset name
>
> src/java.base/share/native/libjava/jni_util.c line 757:
> 
>> 755:                 jnuEncoding = (*env)->NewGlobalRef(env, charset.l);
>> 756:                 (*env)->DeleteLocalRef(env, charset.l);
>> 757:                 break;
> 
> Could return immediately

No, then the method id cache would not get initialized below. But I will add a comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13499#discussion_r1170880852

From phofer at openjdk.org  Wed Apr 19 07:08:53 2023
From: phofer at openjdk.org (Peter Hofer)
Date: Wed, 19 Apr 2023 07:08:53 GMT
Subject: RFR: 8305746: InitializeEncoding should cache Charset object
 instead of charset name [v3]
In-Reply-To: <n_LC8ej_4-qM15pCWVFcirQyB6RNiH7xQtHiJBWNmI0=.c05c9ac5-5602-4f13-98b6-ec1a126c0975@github.com>
References: <n_LC8ej_4-qM15pCWVFcirQyB6RNiH7xQtHiJBWNmI0=.c05c9ac5-5602-4f13-98b6-ec1a126c0975@github.com>
Message-ID: <RohbIQaAUjTjxuaqWfptye1N6HaUSsiK77qHfAUfOes=.01d5b37a-2043-458b-851f-f8a3690a2c60@github.com>

> Store `Charset` object in `jnuEncoding` and use `String(byte[], Charset)` and `String.getBytes(Charset)` instead of passing the charset name.

Peter Hofer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8305746
 - Rename jnuEncoding to jnuCharset.
 - 8305746: InitializeEncoding should cache Charset object instead of charset name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13499/files
  - new: https://git.openjdk.org/jdk/pull/13499/files/9f2494d5..9d10b1da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13499&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13499&range=01-02

  Stats: 445 lines in 39 files changed: 226 ins; 81 del; 138 mod
  Patch: https://git.openjdk.org/jdk/pull/13499.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13499/head:pull/13499

PR: https://git.openjdk.org/jdk/pull/13499

From pminborg at openjdk.org  Wed Apr 19 07:13:48 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 19 Apr 2023 07:13:48 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v8]
In-Reply-To: <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
Message-ID: <raBAgoUakoc-uMqxotfoehCK8yUqfbgzo-fgeERuTD4=.a9059b99-4d5f-406c-95a2-3c4248256ab5@github.com>

On Thu, 9 Feb 2023 13:46:14 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.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unused setup method
>  - Rename method in test
>  - Add copyright header

Keep alive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12346#issuecomment-1514237804

From phofer at openjdk.org  Wed Apr 19 07:19:44 2023
From: phofer at openjdk.org (Peter Hofer)
Date: Wed, 19 Apr 2023 07:19:44 GMT
Subject: RFR: 8305746: InitializeEncoding should cache Charset object
 instead of charset name [v3]
In-Reply-To: <RohbIQaAUjTjxuaqWfptye1N6HaUSsiK77qHfAUfOes=.01d5b37a-2043-458b-851f-f8a3690a2c60@github.com>
References: <n_LC8ej_4-qM15pCWVFcirQyB6RNiH7xQtHiJBWNmI0=.c05c9ac5-5602-4f13-98b6-ec1a126c0975@github.com>
 <RohbIQaAUjTjxuaqWfptye1N6HaUSsiK77qHfAUfOes=.01d5b37a-2043-458b-851f-f8a3690a2c60@github.com>
Message-ID: <M0VufBgz2WOmQeTUu5Yh4pccyDqxW6ngpLxVZZGnXjc=.a4b7119f-58f2-411e-a1e5-c2553359dda3@github.com>

On Wed, 19 Apr 2023 07:08:53 GMT, Peter Hofer <phofer at openjdk.org> wrote:

>> Store `Charset` object in `jnuEncoding` and use `String(byte[], Charset)` and `String.getBytes(Charset)` instead of passing the charset name.
>
> Peter Hofer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8305746
>  - Rename jnuEncoding to jnuCharset.
>  - 8305746: InitializeEncoding should cache Charset object instead of charset name

I have a test in GraalVM which passes with this change in place and will periodically run and start failing in case of a regression. Other issues with this code should become obvious quickly because the code paths are exercised even for non-7bit UTF-8 strings.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13499#issuecomment-1514244592

From duke at openjdk.org  Wed Apr 19 07:42:53 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Wed, 19 Apr 2023 07:42:53 GMT
Subject: RFR: 8306431: The documentation of File.listRoots should be modifid
 after JDK-8208077
Message-ID: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>

I fixed File.listRoots description.
* remove "the insertion or ejection of removable media"
* change "available" to "existing"

Please review this change.

-------------

Commit messages:
 - 8306431: The documentation of File.listRoots should be modifid after JDK-8208077

Changes: https://git.openjdk.org/jdk/pull/13526/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13526&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306431
  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13526.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13526/head:pull/13526

PR: https://git.openjdk.org/jdk/pull/13526

From alanb at openjdk.org  Wed Apr 19 08:13:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Apr 2023 08:13:43 GMT
Subject: RFR: 8306431: The documentation of File.listRoots should be
 modifid after JDK-8208077
In-Reply-To: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
Message-ID: <hl1jxPIUowSG9WCZge1BkouVBe0l0w6WtKvC6aL2bbk=.57a18d03-a3af-4e29-88b1-147f893ed4e0@github.com>

On Wed, 19 Apr 2023 07:34:30 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

> I fixed File.listRoots description.
> * remove "the insertion or ejection of removable media"
> * change "available" to "existing"
> 
> Please review this change.

The text you are proposing to change goes back a long way, it pre-dates the work on Files.listRoots in JDK 10 (JDK-818271) and the subsequent back-out (JDK-8208077).

If we are changing the method description then we could move the descriptions about Unix and Windows behavior to an implNote.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13526#issuecomment-1514317248

From alanb at openjdk.org  Wed Apr 19 08:18:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Apr 2023 08:18:52 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v3]
In-Reply-To: <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>
 <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
Message-ID: <igw6j3rw190cHA00jr3Boh1XwZ3atundWCMN9i7QVkY=.d66b1f52-63ef-4596-ab71-a21f2e00fa79@github.com>

On Wed, 19 Apr 2023 05:43:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix gtests
>
> src/java.base/share/classes/java/lang/Thread.java line 576:
> 
>> 574:         long millis = NANOSECONDS.toMillis(nanos);
>> 575:         nanos -= MILLISECONDS.toNanos(millis);
>> 576:         sleep(millis, (int)nanos);
> 
> This double conversion seems  a bit kludgy - why not just keep the vthread check and call `sleep0(nanos)`?

Yes, I wondering that too as the method has the sleep time in nanos already so more readable to just call sleep0(nanos).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1170984132

From shade at openjdk.org  Wed Apr 19 09:06:59 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 09:06:59 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v3]
In-Reply-To: <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>
 <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
Message-ID: <O6GfqpSCgaqhvX1glVfh0HN6LjHZ3jf4lWEk3yTKhgM=.684fca70-09af-4021-8633-120fae6f20d5@github.com>

On Wed, 19 Apr 2023 05:50:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix gtests
>
> test/jdk/java/lang/Thread/SleepSanity.java line 75:
> 
>> 73:     }
>> 74: 
>> 75:     private static void testTimes(TestCase t, long min, long max) throws Exception {
> 
> Not obvious without reading all the code that min and max are in ms. `msMin` and `msMax` might be clearer.

Done.

> test/jdk/java/lang/Thread/SleepSanity.java line 84:
> 
>> 82:     }
>> 83: 
>> 84:     private static void testTimeout(TestCase t, long timeout) throws Exception {
> 
> Suggestion: s/timeout/millis/ again so unit is clear.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1171043726
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1171043842

From shade at openjdk.org  Wed Apr 19 09:22:44 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 09:22:44 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v3]
In-Reply-To: <igw6j3rw190cHA00jr3Boh1XwZ3atundWCMN9i7QVkY=.d66b1f52-63ef-4596-ab71-a21f2e00fa79@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>
 <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
 <igw6j3rw190cHA00jr3Boh1XwZ3atundWCMN9i7QVkY=.d66b1f52-63ef-4596-ab71-a21f2e00fa79@github.com>
Message-ID: <WTADl-KCs0-jh4mQxMSuBkl5aP9WJ0wb6eHyCU6A_fM=.8cde57cb-bbad-4ddb-babd-de20417815e6@github.com>

On Wed, 19 Apr 2023 08:15:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Thread.java line 576:
>> 
>>> 574:         long millis = NANOSECONDS.toMillis(nanos);
>>> 575:         nanos -= MILLISECONDS.toNanos(millis);
>>> 576:         sleep(millis, (int)nanos);
>> 
>> This double conversion seems  a bit kludgy - why not just keep the vthread check and call `sleep0(nanos)`?
>
> Yes, I wondering that too as the method has the sleep time in nanos already so more readable to just call sleep0(nanos).

True. I was trying to merge some paths in `Thread.java` in the first revision of the patch, but after recent refactorings, we can just call into `sleep0(nanos)` and be done with it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1171065587

From aturbanov at openjdk.org  Wed Apr 19 09:30:59 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 19 Apr 2023 09:30:59 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v23]
In-Reply-To: <rEPfAjIskvPNkKDMx3-YNl36ZCdBs3WpD3rMJjWkyi0=.d89033ec-d1b7-4ded-a8f2-6171283b049a@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <rEPfAjIskvPNkKDMx3-YNl36ZCdBs3WpD3rMJjWkyi0=.d89033ec-d1b7-4ded-a8f2-6171283b049a@github.com>
Message-ID: <M3E52U0pVCuu8h3gcCNII3ZReOZTBTU1bocJ3HRIQPY=.c971283c-94a6-4c48-a106-93a892a165db@github.com>

On Thu, 13 Apr 2023 06:36:51 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> ### Specdiff
>> https://cr.openjdk.org/~pminborg/panama/21/v2/specdiff/overview-summary.html
>> 
>> ### Javadoc
>> https://cr.openjdk.org/~pminborg/panama/21/v2/javadoc/api/java.base/java/lang/foreign/package-summary.html
>> 
>> ### Tests
>> 
>> - [X] Tier1
>> - [X] Tier2
>> - [ ] Tier3
>> - [ ] Tier4
>> - [ ] Tier5
>> - [ ] Tier6
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
>    
>    rename has_port
>  - rename has_port

test/jdk/java/foreign/TestByteBuffer.java line 335:

> 333:                     assertEquals(byteBuffer.isReadOnly(), segment.isReadOnly());
> 334:                     assertTrue(byteBuffer.isDirect());
> 335:                 } catch(IOException e) {

nit
Suggestion:

                } catch (IOException e) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1171075598

From alanb at openjdk.org  Wed Apr 19 09:30:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Apr 2023 09:30:53 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v3]
In-Reply-To: <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>
Message-ID: <PZEvTYW7o0FhKT2ZV-fuGY86tkQggCbkZOPmhIjL33Y=.d6299993-16fc-4dc2-846e-631b556647ae@github.com>

On Tue, 18 Apr 2023 19:38:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
>> 
>> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
>> 
>> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
>> 
>> Additional testing:
>>   - [x] New regression test
>>   - [x] New benchmark
>>   - [x] Linux x86_64 `tier1`
>>   - [x] Linux AArch64 `tier1`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix gtests

You might need to check that  test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/OwnedMonitorsStackDepthInfo/ownedMonitorsStackDepthInfo001/ownedMonitorsStackDepthInfo001a.java is passing. I haven't tried your changes but I remember needing to change this test when doing experimental changes in this area.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1514418262

From shade at openjdk.org  Wed Apr 19 09:30:56 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 09:30:56 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v3]
In-Reply-To: <Ji_swKc708i16wMdJBujYQKjgTrcMx1cRq6E6Y5roNk=.f265e728-09bf-4dd9-a944-3335a613a6eb@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>
 <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
 <OL3lA_22HCBqzonvN6t4TKcoy0xW9r2UP2UFJQxLG70=.647e2ccb-be34-4a3c-b0c3-fae730a5b8ee@github.com>
 <Ji_swKc708i16wMdJBujYQKjgTrcMx1cRq6E6Y5roNk=.f265e728-09bf-4dd9-a944-3335a613a6eb@github.com>
Message-ID: <URmGBH_XTHhy3Ij_IgAbjHtTHNY9j7YEXeBZ2_FKHkc=.ffa5eee0-b172-4d23-96f9-55bb39dc1ac7@github.com>

On Wed, 19 Apr 2023 06:12:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hmmm I changed that comment ...
>
> My actual comment was changed to:
>> I suggest extending the comment to add
> 
> This is how Thread.sleep(millis, nanos) has always behaved with only millisecond granularity.

Reworded, added comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1171072783

From shade at openjdk.org  Wed Apr 19 09:30:59 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 09:30:59 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v3]
In-Reply-To: <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>
 <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
Message-ID: <DlC7QkGUJcXbTaBYT4crjj5f2SLExFJeYeyOXW6u8R8=.119bbab4-d52e-4af4-a734-ddf6d0256924@github.com>

On Wed, 19 Apr 2023 05:58:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix gtests
>
> src/hotspot/os/windows/os_windows.cpp line 5259:
> 
>> 5257:   // any positive requested nanos as a full millisecond.
>> 5258:   jlong millis = align_up(nanos, NANOSECS_PER_MILLISEC) / NANOSECS_PER_MILLISEC;
>> 5259:   assert(nanos == 0 || millis != 0, "Only pass zero millis on zero nanos");
> 
> Not sure what this is trying to check.
> 
> Nit: s/on/or/

Right, I thought we are allowed to pass zero downstream, but there is a `guarantee(Millis > 0)`, which would fail. So there is no reason to do this. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1171074176

From shade at openjdk.org  Wed Apr 19 09:50:53 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 09:50:53 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v3]
In-Reply-To: <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>
 <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
Message-ID: <FbRnvyRwmZUZvbEdDuePZlaLnbo-N5bGfcbogXz9iqk=.36dfb8d8-7374-4b4b-94e3-afdf06e753ad@github.com>

On Wed, 19 Apr 2023 05:58:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix gtests
>
> src/hotspot/os/windows/os_windows.cpp line 5253:
> 
>> 5251: 
>> 5252: int PlatformEvent::park_nanos(jlong nanos) {
>> 5253:   assert(0 <= nanos, "nanos are in range");
> 
> `nanos` should never be zero else you call the untimed park.

Changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1171098893

From shade at openjdk.org  Wed Apr 19 09:56:50 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 09:56:50 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v3]
In-Reply-To: <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>
 <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
Message-ID: <KFOlJ4E7rsAMc-9v6pjyEcp47gYCz_ZY9CYsNC2WAfU=.4b876731-dd1e-4c00-b36a-8e46d0d3eab3@github.com>

On Wed, 19 Apr 2023 06:14:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix gtests
>
> src/hotspot/os/posix/os_posix.cpp line 1545:
> 
>> 1543: 
>> 1544: int PlatformEvent::park_nanos(jlong nanos) {
>> 1545:   assert(0 <= nanos, "nanos are in range");
> 
> `nanos` should never be zero else you call the untimed park.

OK, I see how is that guaranteed in the Windows case. In POSIX case, calling `park()` is untimed wait, but `park(0)` is converted to absolute time that is already passed, and so `pthread_cond_timedwait` would return immediately, right? So `park(0)` is not equivalent to just `park()`? Still, the strongest behavior from Windows case takes precedence here. Changed the assert.

> src/hotspot/os/posix/park_posix.hpp line 57:
> 
>> 55:   void park();
>> 56:   int  park_millis(jlong millis);
>> 57:   int  park_nanos(jlong nanos);
> 
> Still not sure we need this API split but if we keep `park(jlong millis)` and just add `park_nanos(jlong nanos)` then you can avoid touching so many places in the code.

I thought the exposure to `park` -> `park_millis` renames would be smaller, but apparently there is a considerable number of uses. I left `park(millis)` (old) and added `park_nanos(nanos)` (new), and reverted `park_millis` changes.

> src/hotspot/share/runtime/javaThread.hpp line 1145:
> 
>> 1143: public:
>> 1144:   bool sleep_millis(jlong millis);
>> 1145:   bool sleep_nanos(jlong nanos);
> 
> I prefer just one sleep that takes nanos.

If we do only `sleep(jlong nanos)`, then there is an accident waiting to happen, when some unfixed code would call `sleep` with `millis` argument, not knowing it is now `nanos`. That was the reason why I made the names explicit. `sleep_millis` also does the conversion to nanos that does not overflow. But, like with `park` above, I think there is an argument to keep `sleep(millis)` and add `sleep_nanos(nanos)`, to keep code changes at minimum.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1171103473
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1171103664
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1171103560

From shade at openjdk.org  Wed Apr 19 09:56:44 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 09:56:44 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v4]
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <xtMJj7I3PmyMOXW02YZBSuORVvvCTKLlD6UJ6O0IYt8=.027ed5a3-8ad6-4574-aeb5-176fb50de05b@github.com>

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Aleksey Shipilev has updated the pull request incrementally with six additional commits since the last revision:

 - Adjust assert
 - Replace (park|sleep)_millis back with just (park|sleep)
 - More review touchups
 - Revert some Thread refactorings
 - Add a few missing sleep_millis renames
 - Adjust the test a bit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13225/files
  - new: https://git.openjdk.org/jdk/pull/13225/files/33fa34f1..f78aef54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=02-03

  Stats: 57 lines in 16 files changed: 23 ins; 2 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/13225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13225/head:pull/13225

PR: https://git.openjdk.org/jdk/pull/13225

From shade at openjdk.org  Wed Apr 19 10:02:46 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 10:02:46 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v3]
In-Reply-To: <PZEvTYW7o0FhKT2ZV-fuGY86tkQggCbkZOPmhIjL33Y=.d6299993-16fc-4dc2-846e-631b556647ae@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>
 <PZEvTYW7o0FhKT2ZV-fuGY86tkQggCbkZOPmhIjL33Y=.d6299993-16fc-4dc2-846e-631b556647ae@github.com>
Message-ID: <x_AAzlFETrESwWwMIW7X5JPe5vfgtpGX3I0ZlKarNDw=.783cd236-38d7-4cc5-a5a8-ee2f5487974c@github.com>

On Wed, 19 Apr 2023 09:27:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> You might need to check that test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/OwnedMonitorsStackDepthInfo/ownedMonitorsStackDepthInfo001/ownedMonitorsStackDepthInfo001a.java is passing. I haven't tried your changes but I remember needing to change this test when doing experimental changes in this area.

Oh, so that test checks the owned monitors are in frames at particular stack depths! So my previous PR breaks that test because it makes a delegated call to `sleep` in `java.lang.Thread`: all actual offsets are off by one. New PR drops that delegation and the entirety of `vmTestbase/nsk/jdwp/ThreadReference` now passes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1514461529

From shade at openjdk.org  Wed Apr 19 10:13:01 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 10:13:01 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v3]
In-Reply-To: <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>
 <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
Message-ID: <mRK1y4212CQfgZPKLzFrCtz7TTtM7tXPxv0qKUwYEdc=.806a8083-4220-45cf-84c7-2720bad3b30d@github.com>

On Wed, 19 Apr 2023 06:07:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> You seemed to have missed:
> 
> ```
> ./cpu/x86/rdtsc_x86.cpp:    JavaThread::current()->sleep(FT_SLEEP_MILLISECS);
> ./share/compiler/compileBroker.cpp:  sleep(DeoptimizeObjectsALotInterval);
> ```
> 
> so not sure how this is building ???

Should not code when tired, having only Mac M1 on my hands! Argh.

Fun fact: at least on Darwin, we get standard `sleep` in `CompileBroker` if we rename `JavaThread::sleep` to something else. I think we would need to fully qualify those uses to avoid this trap in future -- I'll do a separate PR for this.

Other comments should be addressed in the series of new commits.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1514476031

From mcimadamore at openjdk.org  Wed Apr 19 10:28:51 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Apr 2023 10:28:51 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
Message-ID: <2VZHlvixMlSQeOmv5N4g0HC9pDratOm-7zpJ2MWJbA8=.08b208b5-2a6c-40d7-8955-980c2fe1c1a9@github.com>

On Tue, 18 Apr 2023 09:13:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>  - Reflecting review comments.
>  - Fixing exhaustiveness for unsealed supertype pattern.
>  - No need to enable features after error reported.
>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>  - A prototype of avoiding enum initialization.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 847:

> 845:     /** Skip parens and return the enclosed expression
> 846:      */
> 847:     //XXX: remove??

What about this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1171141708

From prappo at openjdk.org  Wed Apr 19 10:33:06 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 19 Apr 2023 10:33:06 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <UQFv9mQcYOEgU_FMhks5VpQ5n52_eKtQ-SkVFWIJxfA=.f210d862-89a9-4da8-be7b-41edfa06fb39@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
 <UQFv9mQcYOEgU_FMhks5VpQ5n52_eKtQ-SkVFWIJxfA=.f210d862-89a9-4da8-be7b-41edfa06fb39@github.com>
Message-ID: <gFEW30ltuY4EnrgaKyeIKV3tCqUEhO7RjxoAbRx2Fg8=.dc998f69-9f51-4fde-a96c-514a38226ce8@github.com>

On Wed, 19 Apr 2023 04:36:28 GMT, Chen Liang <liach at openjdk.org> wrote:

> Javadoc will automatically copy the specification from the overridden method, so the javadoc block is not necessary and can be replaced by an `@Override` to indicate inheritance.

I guess, this PR has converged enough for us to discuss some trivial stuff; so here it goes.

While you are right when saying that a doc comment consisting of a lone `{@inheritDoc}` is -- and I'm paraphrasing here -- the same as no comment at all, such a comment effectively is a copy of the overridden method _main description_, which is the part of a doc comment from its beginning to the first block tag or the end of the comment (if the comment has no block tags).

Parameters, return value and exception information -- all those are copied because they are mentioned in the method declaration. While this might give an impression that it's the result of `{@inheritDoc}`, it is important to understand that it isn't. For example, since runtime exceptions and errors aren't required to be mentioned in the `throws` clause of a method declaration, no `@throws` tags corresponding to such throwables will be copied automatically; the doc comment has to explicitly inherit those. In our case, either would do:

    /**
     * @throws NoSuchElementException {@inheritDoc}
     */
    public E getFirst() {

    /**
     * {@inheritDoc}
     * @throws NoSuchElementException {@inheritDoc}
     */
    public E getFirst() {

Speaking of which: @stuart-marks, do you think you could add those everywhere?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171145153

From alanb at openjdk.org  Wed Apr 19 12:34:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Apr 2023 12:34:57 GMT
Subject: RFR: 8306038: SystemModulesPlugin: Keep stack clean
In-Reply-To: <kyYX7kVQ4WIDlWKDfpsfnAJcWvIrHfm6C1qHBl5P_QQ=.eab90350-b2ec-410c-97e3-0250e6d1df92@github.com>
References: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>
 <kyYX7kVQ4WIDlWKDfpsfnAJcWvIrHfm6C1qHBl5P_QQ=.eab90350-b2ec-410c-97e3-0250e6d1df92@github.com>
Message-ID: <gSLl8ue03ctMfCpZ2MrQlTHXCjZ2sHlEtj9Yl1nsr-E=.43a3c156-6609-44b3-9f46-5d703497620a@github.com>

On Tue, 18 Apr 2023 19:42:23 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I ran tier1-tier3 tests with your patch and all passed.

Good. @koppor You can edit the PR title to match the JBS issue, then enter "/integrate" and one of us will sponsor.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13442#issuecomment-1514654957

From liach at openjdk.org  Wed Apr 19 13:02:51 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Apr 2023 13:02:51 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v8]
In-Reply-To: <bCgmNILETnu3TOKZKH9QsSMYuyFI2r-LWE_SNp8Fj2Y=.4d32285a-cf0b-43b7-b6a7-2c002a2792ee@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
 <vPOZgVXPdg_rgVjefz-1vOC2lkM1-BVhLgzY5siKMkw=.28efeb0e-414f-4de6-b739-b06f3c4cb4ae@github.com>
 <rUg86GFR5OZEgCHGfuNGM_Jgot88RxxcXPPvQlJn3Yo=.31ef295f-6ebc-4b09-a37d-1c0147984d09@github.com>
 <bCgmNILETnu3TOKZKH9QsSMYuyFI2r-LWE_SNp8Fj2Y=.4d32285a-cf0b-43b7-b6a7-2c002a2792ee@github.com>
Message-ID: <U6fjZANzE_5CIspjg0-ymP17EU_JEIOoRyMZP4gNjRQ=.35a4469b-23b5-491a-9517-3d2cf37c1283@github.com>

On Tue, 21 Mar 2023 13:53:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> It is possible but this keeps the mapper more local and only accessible where it is supposed to be used. For testing purposed, it might be better to have the class as you propose.
>
> If we want it local, I suppose we can convert the whole `ZoneOffsetMapper` local with this singleton in `ofTotalSeconds` static method as well.

What I mean is:

final class LazyZoneOffsetMapper implements IntFunction<ZoneOffset> {
    private static final LazyZoneOffsetMapper INSTANCE = new LazyZoneOffsetMapper();

    @Override
    public ZoneOffset apply(int slot) {
        int totalSeconds = slotToSeconds(slot);
        ZoneOffset newValue = new ZoneOffset(totalSeconds);
        ZoneOffset existing = ID_CACHE.putIfAbsent(newValue.getId(), newValue);
        return existing == null ? newValue : existing;
    }
}

we can inline this local class so we don't declare two classes nested `ZoneOffsetMapper` and local `Holder` for one purpose. This local class is still lazily loaded only if the `INSTANCE` field is used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1171302695

From liach at openjdk.org  Wed Apr 19 13:02:55 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Apr 2023 13:02:55 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v8]
In-Reply-To: <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
Message-ID: <krg9DVuIDEYGVKd-u1VBI13u1QJI9uJmLutWoeGmAWY=.415fe3ac-94b1-42d1-b135-65a28b92403b@github.com>

On Thu, 9 Feb 2023 13:46:14 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.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unused setup method
>  - Rename method in test
>  - Add copyright header

src/java.base/share/classes/java/time/ZoneOffset.java line 451:

> 449:             ZoneOffset newValue = new ZoneOffset(totalSeconds);
> 450:             ID_CACHE.putIfAbsent(newValue.getId(), newValue);
> 451:             return newValue;

Suggestion:

            ZoneOffset existing = ID_CACHE.putIfAbsent(newValue.getId(), newValue);
            return existing == null ? newValue : existing;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1171288185

From duke at openjdk.org  Wed Apr 19 13:05:59 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 19 Apr 2023 13:05:59 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v15]
In-Reply-To: <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
Message-ID: <1P4W0dAhJfkFtBtGoeQ0ZQ30sKh1mDJCj6NdEZnrolI=.f8cb190a-ad8a-4ddc-8e06-02dc055371a4@github.com>

On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs 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 8304915-arch-enum
>  - ArchTest on Debian RISC-V 64 confirmed by reviewer
>  - Fixed isPPC64().
>    Consolidated switch cases in ArchTest.
>    Moved mapping of build TARGET_OS and TARGET_CPU to the build
>    to avoid multiple mappings in more than one place.
>  - Correct mapping and test of ppc64
>  - Add ppc64 as mapping to PPC64 Architecture
>  - Modified test to check Architecture is64bits() and isLittleEndian()
>    against Unsafe respective values.
>    Relocated code mapping OS name and arch name from PlatformProps to
>    OperatingSystem and Architecture. Kept the mapping of names
>    in the template close to where the values are filled in by the build.
>  - Remove unused static and import of Stabile
>  - Rename OperatingSystemProps to PlatformProps.
>    Refactor OperatingSystem initialization to use strings instead of integers.
>  - Revised mapping mechanism of build target architecture names to enum values.
>    Unrecognized values from the build are mapped to enum value "OTHER".
>    Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
>    Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
>  - Revert changes to jdk.accessibility AccessBridge
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e

Looks good, tests still pass on Debian RISC-V 64.

-------------

Marked as reviewed by Glavo at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1392016242

From asotona at openjdk.org  Wed Apr 19 13:06:20 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 19 Apr 2023 13:06:20 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v2]
In-Reply-To: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
Message-ID: <vEoUufevgfR5pb2hZ_E3nA8m0ahl0KdOQCCbeaw9zWk=.aa89bcfb-6eaf-429e-bc80-f9142f301630@github.com>

> Classfile API didn't handle transformations of class files version 50 and below correctly. 
> 
> Proposed fix have two parts: 
> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
> 2. StackMapTable attribute is not generated for class file versions below 50.
> 
> StackMapsTest is also extended to test this patch.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  DiscontinuedInstruction implementation + test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13478/files
  - new: https://git.openjdk.org/jdk/pull/13478/files/b47bc7e5..78be462a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=00-01

  Stats: 363 lines in 10 files changed: 328 ins; 14 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/13478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13478/head:pull/13478

PR: https://git.openjdk.org/jdk/pull/13478

From dholmes at openjdk.org  Wed Apr 19 13:08:53 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Apr 2023 13:08:53 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v4]
In-Reply-To: <xtMJj7I3PmyMOXW02YZBSuORVvvCTKLlD6UJ6O0IYt8=.027ed5a3-8ad6-4574-aeb5-176fb50de05b@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <xtMJj7I3PmyMOXW02YZBSuORVvvCTKLlD6UJ6O0IYt8=.027ed5a3-8ad6-4574-aeb5-176fb50de05b@github.com>
Message-ID: <FjCIugciylzcDim0koJzWoRb-ZdF4OOVgzRpzDZV5WE=.0ae2746e-bd75-4812-bbeb-4af044b6a3f3@github.com>

On Wed, 19 Apr 2023 09:56:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
>> 
>> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
>> 
>> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
>> 
>> Additional testing:
>>   - [x] New regression test
>>   - [x] New benchmark
>>   - [x] Linux x86_64 `tier1`
>>   - [x] Linux AArch64 `tier1`
>
> Aleksey Shipilev has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Adjust assert
>  - Replace (park|sleep)_millis back with just (park|sleep)
>  - More review touchups
>  - Revert some Thread refactorings
>  - Add a few missing sleep_millis renames
>  - Adjust the test a bit

Further to Alan's comment about checking tests, I think this may also impact the strace00n tests that are currently being fixed by https://github.com/openjdk/jdk/pull/13476 - the changes in Thread.java may change the maximum stack depth.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1514702679

From dholmes at openjdk.org  Wed Apr 19 13:17:48 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Apr 2023 13:17:48 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v3]
In-Reply-To: <KFOlJ4E7rsAMc-9v6pjyEcp47gYCz_ZY9CYsNC2WAfU=.4b876731-dd1e-4c00-b36a-8e46d0d3eab3@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <yEN_33lSr_3ZEGkeY6xN4-R6ldsqWacMZ9PZPCJgOuY=.fb18e0e0-e175-45dc-adf2-a515beabeb18@github.com>
 <4mZ9m57CMeqwSLbTwnxfjs9g_dvI4bPEHcYgbND02xQ=.c9585bb0-8436-4d99-a862-4295465190be@github.com>
 <KFOlJ4E7rsAMc-9v6pjyEcp47gYCz_ZY9CYsNC2WAfU=.4b876731-dd1e-4c00-b36a-8e46d0d3eab3@github.com>
Message-ID: <AUBhfWex27lkj5w_iDKk5dYfmApaHAvVZbg3_IuRpn4=.4e4072c4-e09f-45da-beef-5c6920282416@github.com>

On Wed, 19 Apr 2023 09:51:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/os/posix/os_posix.cpp line 1545:
>> 
>>> 1543: 
>>> 1544: int PlatformEvent::park_nanos(jlong nanos) {
>>> 1545:   assert(0 <= nanos, "nanos are in range");
>> 
>> `nanos` should never be zero else you call the untimed park.
>
> OK, I see how is that guaranteed in the Windows case. In POSIX case, calling `park()` is untimed wait, but `park(0)` is converted to absolute time that is already passed, and so `pthread_cond_timedwait` would return immediately, right? So `park(0)` is not equivalent to just `park()`? Still, the strongest behavior from Windows case takes precedence here. Changed the assert.

Posix is missing the assertion that Windows has, but if you check the callers you will find we never pass 0. The typical pattern is:

        if (millis <= 0) {
          self->_ParkEvent->park();
        } else {
          self->_ParkEvent->park(millis);
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1171323075

From pminborg at openjdk.org  Wed Apr 19 13:21:59 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 19 Apr 2023 13:21:59 GMT
Subject: Withdrawn: 8299852: Modernize ConcurrentHashMap
In-Reply-To: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
References: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
Message-ID: <kUvxOoBTc8mJjFAgdRMZHcYCrqwt5NRBb92d9Dzso48=.9852c897-7d56-43a6-9952-7328cebc378c@github.com>

On Tue, 10 Jan 2023 10:32:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been updated to reflect the current state of Java and can be modernized: 
> 
> * Add `@Serial` annotations 
> * Seal classes and restrict subclassing for internal classes 
> * Use pattern matching for instance 
> * Remove redundant modifiers (such as some final declarations) 
> * Use Objects.requireNonNull for invariant checking 
> * Use diamond operators instead of explicit types 
> * Simplify expressions using Math::max

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11924

From mdoerr at openjdk.org  Wed Apr 19 13:26:02 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 19 Apr 2023 13:26:02 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v15]
In-Reply-To: <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
Message-ID: <N_Q4PZHygDCHkRCmB0QS3iSVuqgfNYRzx9YtgKyjUMk=.d987527f-55bb-432e-a450-c7ac6e675ca9@github.com>

On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs 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 8304915-arch-enum
>  - ArchTest on Debian RISC-V 64 confirmed by reviewer
>  - Fixed isPPC64().
>    Consolidated switch cases in ArchTest.
>    Moved mapping of build TARGET_OS and TARGET_CPU to the build
>    to avoid multiple mappings in more than one place.
>  - Correct mapping and test of ppc64
>  - Add ppc64 as mapping to PPC64 Architecture
>  - Modified test to check Architecture is64bits() and isLittleEndian()
>    against Unsafe respective values.
>    Relocated code mapping OS name and arch name from PlatformProps to
>    OperatingSystem and Architecture. Kept the mapping of names
>    in the template close to where the values are filled in by the build.
>  - Remove unused static and import of Stabile
>  - Rename OperatingSystemProps to PlatformProps.
>    Refactor OperatingSystem initialization to use strings instead of integers.
>  - Revised mapping mechanism of build target architecture names to enum values.
>    Unrecognized values from the build are mapped to enum value "OTHER".
>    Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
>    Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
>  - Revert changes to jdk.accessibility AccessBridge
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e

test/jdk/jdk/internal/util/ArchTest.java line 71:

> 69:             case "aarch64" -> AARCH64;
> 70:             case "riscv64" -> RISCV64;
> 71:             case "s390x", "s390" -> S390;  // unverified

This was also verified according to comments. Right, @offamitkumar?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1171335657

From asotona at openjdk.org  Wed Apr 19 13:35:50 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 19 Apr 2023 13:35:50 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v2]
In-Reply-To: <vEoUufevgfR5pb2hZ_E3nA8m0ahl0KdOQCCbeaw9zWk=.aa89bcfb-6eaf-429e-bc80-f9142f301630@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <vEoUufevgfR5pb2hZ_E3nA8m0ahl0KdOQCCbeaw9zWk=.aa89bcfb-6eaf-429e-bc80-f9142f301630@github.com>
Message-ID: <I9kDxHs4soAa0OLz4946WKGyOpCL3hMevY338DvI0iw=.12a2af56-4235-4b62-8daf-23ada198dcf2@github.com>

On Wed, 19 Apr 2023 13:06:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API didn't handle transformations of class files version 50 and below correctly. 
>> 
>> Proposed fix have two parts: 
>> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
>> 2. StackMapTable attribute is not generated for class file versions below 50.
>> 
>> StackMapsTest is also extended to test this patch.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   DiscontinuedInstruction implementation + test

I?m proposing following changes to Classfile API:
-	Drop Opcode.Kind.UNSUPPORTED and add Opcode.Kind.DISCONTINUED_JSR and DISCONTINUED_RET
-	Add DiscontinuedInstruction interface with inner JsrInstruction and RetInstruction with standard factory methods
-	CodeImpl will parse and stream these instructions when present in the Code attribute
-	Do not add any new conveniency methods to CodeBuilder, the only way to build a code with these instructions will be cob.with(DiscontinuedInstruction. JsrInstruction.of(?)) and similar for RetInstruction
-	Fix DirectCodeBuilder so it invokes StackMapGenerator only for class file version >= 51.0 (BufWriterImpl must hold class version for that purpose)
-	Fix  StackMapGenerator error message when these instruction appear in during generation
-	Implement fallback to jump target inflation in CodeImpl when the StackMapTable attribute is missing and class file version is < 51.0
-	Extend tests to verify JSR and RET instructions are correctly generated, transformed and reported as error (based on class file version).

Next step is to implement simple maxStack and maxLocals counter into DirectCodeBuilder for the cases where StackMapGenerator is not involved. Actual default to maxStack = maxLocals = 255 is not correct.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13478#issuecomment-1514739739

From liach at openjdk.org  Wed Apr 19 13:35:52 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Apr 2023 13:35:52 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v2]
In-Reply-To: <vEoUufevgfR5pb2hZ_E3nA8m0ahl0KdOQCCbeaw9zWk=.aa89bcfb-6eaf-429e-bc80-f9142f301630@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <vEoUufevgfR5pb2hZ_E3nA8m0ahl0KdOQCCbeaw9zWk=.aa89bcfb-6eaf-429e-bc80-f9142f301630@github.com>
Message-ID: <wtvStAUbHzc5UkDjmKYN2me5iE2-voGFZfECGv0E2R4=.6b57848d-9276-4632-85cb-5468666d132a@github.com>

On Wed, 19 Apr 2023 13:06:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API didn't handle transformations of class files version 50 and below correctly. 
>> 
>> Proposed fix have two parts: 
>> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
>> 2. StackMapTable attribute is not generated for class file versions below 50.
>> 
>> StackMapsTest is also extended to test this patch.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   DiscontinuedInstruction implementation + test

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 343:

> 341:                 }
> 342:                 else {
> 343:                     maxStack = maxLocals = 255;

Will this have a negative effect, such as slowing down the vm at runtime?

Edit: sorry, didn't see your summary comment when I was reviewing the updated patch. Otherwise it looks all good!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13478#discussion_r1171348201

From pminborg at openjdk.org  Wed Apr 19 13:37:15 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 19 Apr 2023 13:37:15 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v24]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <znkZ0Yg1tP8eBeZuIer1NWrySNSJOM7EgZyIvIXsx3w=.fc4362ca-8148-4454-a7f0-7659c1f28d31@github.com>

> API changes for the FFM API (third preview)
> 
> ### Specdiff
> https://cr.openjdk.org/~pminborg/panama/21/v2/specdiff/overview-summary.html
> 
> ### Javadoc
> https://cr.openjdk.org/~pminborg/panama/21/v2/javadoc/api/java.base/java/lang/foreign/package-summary.html
> 
> ### Tests
> 
> - [X] Tier1
> - [X] Tier2
> - [ ] Tier3
> - [ ] Tier4
> - [ ] Tier5
> - [ ] Tier6

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:

 - Merge branch 'master' into PR_21_V2
 - Update test/jdk/java/foreign/TestByteBuffer.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
   
   rename has_port
 - rename has_port
 - Merge pull request #2 from JornVernee/WSL_BB
   
   account for missing functional in WSL in TestByteBuffer
 - account for missing mincore on WSL in TestByteBuffer
 - Merge branch 'master' into PR_21_V2
 - 8305369: Issues in zero-length memory segment javadoc section
 - 8305087: MemoryLayout API checks should be more eager
 - Merge master
 - ... and 32 more: https://git.openjdk.org/jdk/compare/9fb53adf...ba04f5cc

-------------

Changes: https://git.openjdk.org/jdk/pull/13079/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=23
  Stats: 13421 lines in 270 files changed: 5102 ins; 6182 del; 2137 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From shade at openjdk.org  Wed Apr 19 13:42:50 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 13:42:50 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v4]
In-Reply-To: <xtMJj7I3PmyMOXW02YZBSuORVvvCTKLlD6UJ6O0IYt8=.027ed5a3-8ad6-4574-aeb5-176fb50de05b@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <xtMJj7I3PmyMOXW02YZBSuORVvvCTKLlD6UJ6O0IYt8=.027ed5a3-8ad6-4574-aeb5-176fb50de05b@github.com>
Message-ID: <DQspy3z4FWxG1B7--8Y8sFdPhjYwCWGht7Q2Yb8rpcs=.99249eef-5bf7-4452-9ef9-ef3850871a7c@github.com>

On Wed, 19 Apr 2023 09:56:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
>> 
>> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
>> 
>> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
>> 
>> Additional testing:
>>   - [x] New regression test
>>   - [x] New benchmark
>>   - [x] Linux x86_64 `tier1`
>>   - [x] Linux AArch64 `tier1`
>
> Aleksey Shipilev has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Adjust assert
>  - Replace (park|sleep)_millis back with just (park|sleep)
>  - More review touchups
>  - Revert some Thread refactorings
>  - Add a few missing sleep_millis renames
>  - Adjust the test a bit

> Further to Alan's comment about checking tests, I think this may also impact the strace00n tests that are currently being fixed by #13476 - the changes in Thread.java may change the maximum stack depth.

I think current PR does not break Java stack tests anymore, because it does not change the depth of Java stacks. I ran `vmTestbase/nsk/monitoring/stress/thread` without problems with this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1514756102

From asotona at openjdk.org  Wed Apr 19 13:44:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 19 Apr 2023 13:44:47 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v3]
In-Reply-To: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
Message-ID: <NDZsJbnOay2IPYbjJ-E_asohiAS8eJpqd0mHbh1EmsE=.7d30affe-510c-476e-8def-042ced74b017@github.com>

> Classfile API didn't handle transformations of class files version 50 and below correctly. 
> 
> Proposed fix have two parts: 
> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
> 2. StackMapTable attribute is not generated for class file versions below 50.
> 
> StackMapsTest is also extended to test this patch.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed ClassPrinterImpl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13478/files
  - new: https://git.openjdk.org/jdk/pull/13478/files/78be462a..473fc8e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=01-02

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13478/head:pull/13478

PR: https://git.openjdk.org/jdk/pull/13478

From shade at openjdk.org  Wed Apr 19 13:53:51 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 13:53:51 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v6]
In-Reply-To: <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
Message-ID: <0SzNX_YPWTZssLkV1VUqvWaQDAjv7ZSJtf6ZswwXU5k=.11bd2e6f-26a7-4b69-8306-451d647c83ad@github.com>

On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075). [Benchmark results and generated code analysis moved to comment]
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shuffle docs

@AlanBateman, @apangin, @ExE-Boss, @liach, @pavelrappo -- you had comments on this PR, could you please see if those are still relevant or not addressed? If you are good with the current version, can you please formally approve the PR? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1514773988

From shade at openjdk.org  Wed Apr 19 14:05:43 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 14:05:43 GMT
Subject: RFR: 8306452: Fix Amazon copyright in JDK-8305425 test
Message-ID: <qL6kNqSUJfDoIZ1i7j_Y_pH-xkOiTECYF5quWlc2szs=.55164a77-c92f-43e6-afac-0f51b23b55a2@github.com>

Someone^W I did commit a test in the OpenJDK repo that has Amazon copyright notice in the form that is not inline with the preferred one (intentionally without copyright year):

"Copyright Amazon.com Inc. or its affiliates. All Rights Reserved."

These should be fixed.

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/13534/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13534&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306452
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13534.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13534/head:pull/13534

PR: https://git.openjdk.org/jdk/pull/13534

From simonis at openjdk.org  Wed Apr 19 14:05:44 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 19 Apr 2023 14:05:44 GMT
Subject: RFR: 8306452: Fix Amazon copyright in JDK-8305425 test
In-Reply-To: <qL6kNqSUJfDoIZ1i7j_Y_pH-xkOiTECYF5quWlc2szs=.55164a77-c92f-43e6-afac-0f51b23b55a2@github.com>
References: <qL6kNqSUJfDoIZ1i7j_Y_pH-xkOiTECYF5quWlc2szs=.55164a77-c92f-43e6-afac-0f51b23b55a2@github.com>
Message-ID: <0QRbqAM-24xvKhMqpcBIr1LNC9_JDKyw85lfFQT6he0=.0fa4f889-efbd-400b-bf7c-d4a5348316e4@github.com>

On Wed, 19 Apr 2023 13:57:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Someone^W I did commit a test in the OpenJDK repo that has Amazon copyright notice in the form that is not inline with the preferred one (intentionally without copyright year):
> 
> "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved."
> 
> These should be fixed.

Looks good.

Thanks for fixing!

-------------

Marked as reviewed by simonis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13534#pullrequestreview-1392140964

From liach at openjdk.org  Wed Apr 19 14:15:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Apr 2023 14:15:05 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v6]
In-Reply-To: <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
Message-ID: <7tDTj2Peuf5S69SkbLJU-4ZdVp3yjnNxhSdUl50GlP8=.f6196454-c0ca-4de1-9e38-6bd5315a09b4@github.com>

On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075). [Benchmark results and generated code analysis moved to comment]
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shuffle docs

Thanks for the poke Aleksey. I have been pleased with this patch; my comments were simply to dismiss the concerns about the behavior under reflection and to clarify that an `invokespecial` may be virtual since the introduction of private overrides with nest mates.

-------------

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/13491#pullrequestreview-1392170035

From liach at openjdk.org  Wed Apr 19 14:39:40 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Apr 2023 14:39:40 GMT
Subject: RFR: 8306455: Wrong majorVersion for multiple attributes in Classfile
 API
Message-ID: <mSyXLLN7qBVlAVaiYrvFSyAb8QAm-g9TAZ-ZSL_oiZI=.ec069d21-00c2-4343-adb6-01de938ddfc6@github.com>

Spotted the typo for BootstrapMethods, and another review over the API exposed the typo on PermittedSubclasses.

-------------

Commit messages:
 - 8306455: Wrong majorVersion for multiple attributes in Classfile API

Changes: https://git.openjdk.org/jdk/pull/13536/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13536&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306455
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13536.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13536/head:pull/13536

PR: https://git.openjdk.org/jdk/pull/13536

From apangin at openjdk.org  Wed Apr 19 14:42:59 2023
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 19 Apr 2023 14:42:59 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v6]
In-Reply-To: <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
Message-ID: <0eWciQNQ5FkhgHBXevRDeOMdSAawrPIHd_jR8VrUdJk=.6d31c414-f608-4f95-ac62-3fd3a901719b@github.com>

On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075). [Benchmark results and generated code analysis moved to comment]
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shuffle docs

Marked as reviewed by apangin (no project role).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13491#pullrequestreview-1392235226

From nlisker at openjdk.org  Wed Apr 19 14:45:46 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 19 Apr 2023 14:45:46 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
Message-ID: <aE6pPGD9JA2INISEE2aADCdIPZLeO1xm4VeIO2bPnYo=.ebb83366-e9b4-4d22-8c57-a92cd8cee43f@github.com>

On Wed, 19 Apr 2023 03:37:05 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unnecessary 'final' from a couple places.
>  - Clarify ordering of Collection.addAll and Map.putAll; add links to
>    encounter order.
>  - Make constructors private for several reverse-ordered views.

I reviewed some of the public documentation and left some comments and thoughts. As a general remark, the documentation could use [Code Snippets](https://openjdk.org/jeps/413) to avoid the `<pre>{@code` pattern.

src/java.base/share/classes/java/util/Collection.java line 511:

> 509:      * nonempty.) If the specified collection has a defined
> 510:      * <a href="SequencedCollection.html#encounter">encounter order</a>,
> 511:      * processing of its elements generally occurs in that order.

Shouldn't `remove` also contain such a note? From its docs:

"More formally, removes an element e such that `Objects.equals(o, e)`, if this collection contains one or more such elements." Can add something like "If the specified collection has a defined *encounter order*, generally removes the first encountered element in that order".

src/java.base/share/classes/java/util/Collections.java line 374:

> 372:      * @apiNote
> 373:      * This method mutates the specified list in-place. To obtain a
> 374:      * reversed-ordered view of a list without mutating it, use the

The term that has been usually used is "reverse-ordered".

src/java.base/share/classes/java/util/Collections.java line 380:

> 378:      * @throws UnsupportedOperationException if the specified list or
> 379:      *         its list-iterator does not support the {@code set} operation.
> 380:      * @see    List#reversed List.reversed

Is the `@see` tag really useful if you're already linking the method directly?

src/java.base/share/classes/java/util/Collections.java line 6069:

> 6067:      *
> 6068:      * @apiNote
> 6069:      * This method provides a view that inverts the sense of certain operations,

I think that "inverts the operation of certain methods" is clearer.

src/java.base/share/classes/java/util/Collections.java line 6070:

> 6068:      * @apiNote
> 6069:      * This method provides a view that inverts the sense of certain operations,
> 6070:      * but it doesn't reverse the encounter order. To obtain a reversed-ordered

The term that has been usually used is "reverse-ordered".

src/java.base/share/classes/java/util/Collections.java line 6071:

> 6069:      * This method provides a view that inverts the sense of certain operations,
> 6070:      * but it doesn't reverse the encounter order. To obtain a reversed-ordered
> 6071:      * view, use the {@link Deque#reversed Deque::reversed} method.

In `@link` tags in other places, the display name uses `Class.method` formatting, not `Class::method`. Might want to consolidate this.

src/java.base/share/classes/java/util/List.java line 813:

> 811:      *
> 812:      * @implSpec
> 813:      * If this List is not empty, the implementation in this class returns the result

`{@code List}`

Same in other places.

src/java.base/share/classes/java/util/List.java line 882:

> 880:      * @implSpec
> 881:      * The implementation in this class returns an instance of a reverse-ordered
> 882:      * List that delegates its operations to this List.

`{@code List}`

src/java.base/share/classes/java/util/NavigableSet.java line 361:

> 359:      * {@inheritDoc}
> 360:      * <p>
> 361:      * This method is equivalent to {@link #descendingSet descendingSet}.

Doesn't `{@link #descendingSet}` display as `descendingSet` already? The same pattern appears in other places.

src/java.base/share/classes/java/util/SequencedCollection.java line 1:

> 1: /*

I wonder if there's a point to mention the relation of reversal to the "enhanced for-each" loop. The loop uses the iterator behind the scenes. That means that a reversed collection will iterate backwards in a loop ("enhanced each-for" loop :) ). A backwards iteration can be achieved by

for (E element : collection.reversed()) {...}

For collections that support removal, this construct can also be used to remove elements without the concurrent modification problem of removal during iteration which messes up the indices. See, for example, https://stackoverflow.com/questions/10431981/remove-elements-from-collection-while-iterating.

src/java.base/share/classes/java/util/SequencedCollection.java line 34:

> 32:  * from the first element to the last element. Given any two elements, one element is
> 33:  * either before (closer to the first element) or after (closer to the last element)
> 34:  * the other element.

The last sentence seems a bit clumsy owing to the abundance of parenthesized content and the confusion of "first element" of the collection with the first element of the 2 chosen for the explanation. How about something like:
"Given any two elements, one element is either before the other element (it is closer to the collection's start) or after it (closer to the collection's end)"?

src/java.base/share/classes/java/util/SequencedCollection.java line 49:

> 47:  * <p>
> 48:  * This interface provides methods to add elements, to retrieve elements, and to remove
> 49:  * elements at either end of the collection.

Maybe this phrasing will be easier to read:
"This interface provides methods to add, retrieve, and remove elements..."

src/java.base/share/classes/java/util/SequencedCollection.java line 93:

> 91: 
> 92:     /**
> 93:      * Adds an element as the first element of this collection (optional operation).

"Adds an element as the first element" is a bit confusing. Maybe "at the first position".

src/java.base/share/classes/java/util/SequencedCollection.java line 98:

> 96:      *
> 97:      * @implSpec
> 98:      * The implementation in this class always throws {@code UnsupportedOperationException}.

class -> interface? This appears in other interfaces as well. We tend to code to interfaces with collections, so this distinction seems relevant.

src/java.base/share/classes/java/util/SequencedCollection.java line 102:

> 100:      * @param e the element to be added
> 101:      * @throws NullPointerException if the specified element is null and this
> 102:      *         collection does not permit null elements

Not sure if the JDK encourages "null" to be in `@code`. I personally think it's better since it's a literal.

src/java.base/share/classes/java/util/SequencedCollection.java line 123:

> 121:      * @throws UnsupportedOperationException if this collection implementation
> 122:      *         does not support this operation
> 123:      */

Same comments as in `addFirst`.

src/java.base/share/classes/java/util/SequencedMap.java line 29:

> 27: 
> 28: /**
> 29:  * A Map that has a well-defined encounter order, that supports operations at both ends, and

`{@code Map}`

src/java.base/share/classes/java/util/SequencedMap.java line 49:

> 47:  * {@link #keySet keySet},
> 48:  * {@link #values values}, and
> 49:  * {@link #entrySet entrySet} methods are not sequenced <i>types</i>, the elements

These were just linked before, I don't think they should be linked again. `@code` should suffice.

src/java.base/share/classes/java/util/SequencedMap.java line 59:

> 57:  * <p>
> 58:  * This interface provides methods to add mappings, to retrieve mappings, and to remove
> 59:  * mappings at either end of the map's encounter order.

Similar to the other place, I recommend "...to add, retrieve, and remove mappings...".

src/java.base/share/classes/java/util/SequencedMap.java line 74:

> 72:  * <pre>{@code
> 73:  *     var itr = sequencedMap.reversed().entrySet().iterator();
> 74:  * }</pre>

To avoid confusion, I would mention the relation between this example and

sequencedMap.sequencedEntrySet().reversed().iterator();

Or, in general, reversing the map and then obtaining a view, compared to obtaining a view and then reversing it.

src/java.base/share/classes/java/util/SequencedMap.java line 85:

> 83:  * <p>
> 84:  * The {@link Map.Entry} instances obtained by iterating the {@link #entrySet} view, the
> 85:  * {@link #sequencedEntrySet} view, and its reverse-ordered view, maintain a connection to the

`#entrySet` and `#sequencedEntrySet` were linked above, no need to link them again.

src/java.base/share/classes/java/util/SequencedMap.java line 88:

> 86:  * underlying map. This connection is guaranteed only during the iteration. It is unspecified
> 87:  * whether the connection is maintained outside of the iteration. If the underlying map permits
> 88:  * it, calling an Entry's {@link Map.Entry#setValue setValue} method will modify the value of the

`{@code Entry}`

src/java.base/share/classes/java/util/SequencedMap.java line 99:

> 97:  * return {@link Map.Entry} instances that represent snapshots of mappings as
> 98:  * of the time of the call. They do <em>not</em> support mutation of the
> 99:  * underlying map via the optional {@link Map.Entry#setValue setValue} method.

Previously linked.

src/java.base/share/classes/java/util/SequencedMap.java line 110:

> 108:  * {@code Entry} thus obtained will update a mapping in the underlying map, or whether
> 109:  * it will throw an exception, or whether changes to the underlying map are visible in
> 110:  * that {@code Entry}.

These 3 paragraphs all talk about `Entry`s' connection to the map. I think that they can be reconciled by explicitly noting each way to get an entry and the conditions that apply on it. In broad strokes:

> `{@link Map.Entry}` instances can be obtained in several ways.
> By iterating the `{@link #entrySet}` view... These entries maintain a connection...
> By calling the `{@link #firstEntry}`... methods. These entries represent snapshots of...
> By other means, such as from methods of views of the map (`sequencedMap.sequencedEntrySet().getFirst();`). These entries entries might or might not be connected...

src/java.base/share/classes/java/util/SequencedSet.java line 30:

> 28: /**
> 29:  * A collection that is both a {@link SequencedCollection} and a {@link Set}. As such, it can be
> 30:  * thought of as either as a {@code Set} that also has a well-defined encounter order, or as a

"thought of ~~as~~ either"

src/java.base/share/classes/java/util/SequencedSet.java line 30:

> 28: /**
> 29:  * A collection that is both a {@link SequencedCollection} and a {@link Set}. As such, it can be
> 30:  * thought of as either as a {@code Set} that also has a well-defined encounter order, or as a

Usually you link to `encounter order`, like in `SequencedMap`.

src/java.base/share/classes/java/util/SortedSet.java line 358:

> 356:      * @implSpec
> 357:      * The implementation in this class returns an instance of a reverse-ordered
> 358:      * SortedSet that delegates its operations to this SortedSet.

`{@code SortedSet}`

-------------

PR Review: https://git.openjdk.org/jdk/pull/7387#pullrequestreview-1391301308
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1170836342
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171047117
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1170840446
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171044881
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171047614
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1170998217
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171150721
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171246754
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171264376
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171093839
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171018726
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171010122
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171098628
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171121296
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171123147
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171125802
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171271109
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171282680
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171280805
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171293778
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171296055
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171298023
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171299868
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171417481
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171267859
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171273471
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171246074

From shade at openjdk.org  Wed Apr 19 14:48:53 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 14:48:53 GMT
Subject: RFR: 8306452: Fix Amazon copyright in JDK-8305425 test
In-Reply-To: <0QRbqAM-24xvKhMqpcBIr1LNC9_JDKyw85lfFQT6he0=.0fa4f889-efbd-400b-bf7c-d4a5348316e4@github.com>
References: <qL6kNqSUJfDoIZ1i7j_Y_pH-xkOiTECYF5quWlc2szs=.55164a77-c92f-43e6-afac-0f51b23b55a2@github.com>
 <0QRbqAM-24xvKhMqpcBIr1LNC9_JDKyw85lfFQT6he0=.0fa4f889-efbd-400b-bf7c-d4a5348316e4@github.com>
Message-ID: <5VBVAanb9C6tzNUCAjPx_7Y5dmzLIm4U7mY4cGqjfwU=.55175654-a496-4e07-95e4-43f8234284a7@github.com>

On Wed, 19 Apr 2023 13:59:09 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Looks good.
> 
> Thanks for fixing!

Thanks! Trivial, right?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13534#issuecomment-1514871013

From prappo at openjdk.org  Wed Apr 19 15:07:03 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 19 Apr 2023 15:07:03 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v6]
In-Reply-To: <0SzNX_YPWTZssLkV1VUqvWaQDAjv7ZSJtf6ZswwXU5k=.11bd2e6f-26a7-4b69-8306-451d647c83ad@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
 <0SzNX_YPWTZssLkV1VUqvWaQDAjv7ZSJtf6ZswwXU5k=.11bd2e6f-26a7-4b69-8306-451d647c83ad@github.com>
Message-ID: <3zJog1MLxFphWSmMrUqesoIt8f_eRn4JvD2v58xb7Zo=.828ee212-cbd2-41c5-b39d-9a9c209c5e2d@github.com>

On Wed, 19 Apr 2023 13:50:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> @AlanBateman, @apangin, @ExE-Boss, @liach, @pavelrappo -- you had comments on this PR, could you please see if those are still relevant or not addressed? If you are good with the current version, can you please formally approve the PR? Thanks!

Don't mind me: I had minor, mostly unrelated comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1514898960

From vromero at openjdk.org  Wed Apr 19 15:39:53 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 19 Apr 2023 15:39:53 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
Message-ID: <-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com>

On Tue, 18 Apr 2023 09:13:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>  - Reflecting review comments.
>  - Fixing exhaustiveness for unsealed supertype pattern.
>  - No need to enable features after error reported.
>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>  - A prototype of avoiding enum initialization.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 279:

> 277:     }
> 278: 
> 279:     private static int lazyDoEnumSwitch(Enum<?> target, int startIndex, Object[] labels, MethodHandles.Lookup lookup, Class<?> enumClass, MutableCallSite callSite) throws Throwable {

out of curiosity, under what conditions the `startIndex` would be different from `0`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1171523963

From mchhipa at openjdk.org  Wed Apr 19 15:57:39 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 19 Apr 2023 15:57:39 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed
Message-ID: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>

Test is updated to create the binary files during test execution.

-------------

Commit messages:
 - JDK-8077371: Binary files in JAXP test should be removed

Changes: https://git.openjdk.org/jdk/pull/13537/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8077371
  Stats: 140 lines in 9 files changed: 45 ins; 54 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/13537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13537/head:pull/13537

PR: https://git.openjdk.org/jdk/pull/13537

From duke at openjdk.org  Wed Apr 19 15:59:59 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 19 Apr 2023 15:59:59 GMT
Subject: Integrated: 8306038: SystemModulesPlugin generates code that doesn't
 pop when return value not used
In-Reply-To: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>
References: <O5AXXxe9ZsAfdoG-rtcLtDlcHT4htOiHVBDbbOw6V_M=.48a0f229-800b-4446-a3e1-f6d963fd6fa8@github.com>
Message-ID: <mTaSc6OrdmQjyNnGUavxeT-djq9ecKAdJLu_gk0H8Ls=.9cb2b8c7-e63c-4816-b37d-aac009380d65@github.com>

On Wed, 12 Apr 2023 09:18:13 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> This refs [8306038](https://bugs.openjdk.org/browse/JDK-8306038)
> 
> (Before this referenced 8240567)
> 
> Although this change is rather small, I think, it's good to have a "more clean" SystemModulesPlugin available.

This pull request has now been integrated.

Changeset: c57af319
Author:    Oliver Kopp <kopp.dev at gmail.com>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c57af319f668e10b2b357bb961903a6236d5521f
Stats:     8 lines in 1 file changed: 4 ins; 0 del; 4 mod

8306038: SystemModulesPlugin generates code that doesn't pop when return value not used

Reviewed-by: alanb, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/13442

From shade at openjdk.org  Wed Apr 19 16:02:08 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 16:02:08 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v5]
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <UyIr5-Bf33M8kJdtAQe0w_6IxUoVEBbJ6WKcckkj1Ko=.7bd80f6b-10c0-4f50-8f1c-150be20285ed@github.com>

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Windows fixes: align(...) is only for power-of-two alignments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13225/files
  - new: https://git.openjdk.org/jdk/pull/13225/files/f78aef54..29c7df36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=03-04

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13225/head:pull/13225

PR: https://git.openjdk.org/jdk/pull/13225

From dnsimon at openjdk.org  Wed Apr 19 16:05:08 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 19 Apr 2023 16:05:08 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v9]
In-Reply-To: <tSOY4bLeZKlucGnZHlKrhI0z9fUwSva5UyGrRAlp_4M=.ce362a15-9aa0-4f19-9f80-4a9ecb9794cd@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <tSOY4bLeZKlucGnZHlKrhI0z9fUwSva5UyGrRAlp_4M=.ce362a15-9aa0-4f19-9f80-4a9ecb9794cd@github.com>
Message-ID: <qA5qq62c1XjS_LbDHjcK5KSmjCUC6hKMrX6pD3Ir64o=.64e994d2-daeb-4d80-ac19-f8e95c1df034@github.com>

On Tue, 18 Apr 2023 07:27:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
>> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`.
>> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>>  
>> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
>> 
>>     ResolvedJavaMethod method = ...;
>>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>>     return switch (a.kind()) {
>>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The same code using the new API:
>> 
>> 
>>     ResolvedJavaMethod method = ...;
>>     ResolvedJavaType explodeLoopType = ...;
>>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>>     return switch (a.getEnum("kind").getName()) {
>>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.
>
> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - added breadcrumb in AnnotationParser about considering JVMCI should new annotation element types be added
>  - fixed javadoc comment

Thanks for the reviews @turbanoff , @vnkozlov and @jddarcy.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12810#issuecomment-1514985140

From dnsimon at openjdk.org  Wed Apr 19 16:05:13 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 19 Apr 2023 16:05:13 GMT
Subject: Integrated: 8303431: [JVMCI] libgraal annotation API
In-Reply-To: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
Message-ID: <nRu7VURc1OqmrK2OnUwJgJqNRMRzKMgZ6_69707-THI=.024a6ef7-8a19-4a78-a617-b6cfde42d8b6@github.com>

On Wed, 1 Mar 2023 18:07:34 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`.
> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>  
> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
> 
>     ResolvedJavaMethod method = ...;
>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>     return switch (a.kind()) {
>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The same code using the new API:
> 
> 
>     ResolvedJavaMethod method = ...;
>     ResolvedJavaType explodeLoopType = ...;
>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>     return switch (a.getEnum("kind").getName()) {
>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.

This pull request has now been integrated.

Changeset: 48fd4f2b
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/48fd4f2bd37562a159e4089b15aa108e0b1bebeb
Stats:     2321 lines in 34 files changed: 2270 ins; 23 del; 28 mod

8303431: [JVMCI] libgraal annotation API

Reviewed-by: kvn, never, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/12810

From naoto at openjdk.org  Wed Apr 19 16:07:56 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Apr 2023 16:07:56 GMT
Subject: Integrated: 8306323: Update license files in CLDR v43
In-Reply-To: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
References: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
Message-ID: <3vVwZa-_CWFCdKb7J6-1Z7B_1sFwEgwKQFoLbsDwqhg=.0035c258-f1fd-4dd0-a7c3-bfe7490c7bb2@github.com>

On Tue, 18 Apr 2023 18:40:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The upgrade to CLDR v43 was missing the license-related file updates. Here are the supplemental updates.

This pull request has now been integrated.

Changeset: 85de01e6
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85de01e67638cf1356d5ad08ebd4a630df6bae03
Stats:     194 lines in 3 files changed: 98 ins; 90 del; 6 mod

8306323: Update license files in CLDR v43

Reviewed-by: lancea, srl, iris

-------------

PR: https://git.openjdk.org/jdk/pull/13517

From simonis at openjdk.org  Wed Apr 19 16:20:46 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 19 Apr 2023 16:20:46 GMT
Subject: RFR: 8306452: Fix Amazon copyright in JDK-8305425 test
In-Reply-To: <qL6kNqSUJfDoIZ1i7j_Y_pH-xkOiTECYF5quWlc2szs=.55164a77-c92f-43e6-afac-0f51b23b55a2@github.com>
References: <qL6kNqSUJfDoIZ1i7j_Y_pH-xkOiTECYF5quWlc2szs=.55164a77-c92f-43e6-afac-0f51b23b55a2@github.com>
Message-ID: <vDEKWi7q6sZEzsNxRBTMddxzEEiQvrQ2OaaXyOJNb9c=.0754bf20-d062-46ca-971a-58ea577fdc63@github.com>

On Wed, 19 Apr 2023 13:57:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Someone^W I did commit a test in the OpenJDK repo that has Amazon copyright notice in the form that is not inline with the preferred one (intentionally without copyright year):
> 
> "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved."
> 
> These should be fixed.

Sure, more than trivial :)

Ship it!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13534#issuecomment-1515014390

From amitkumar at openjdk.org  Wed Apr 19 16:26:02 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 19 Apr 2023 16:26:02 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v15]
In-Reply-To: <N_Q4PZHygDCHkRCmB0QS3iSVuqgfNYRzx9YtgKyjUMk=.d987527f-55bb-432e-a450-c7ac6e675ca9@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
 <N_Q4PZHygDCHkRCmB0QS3iSVuqgfNYRzx9YtgKyjUMk=.d987527f-55bb-432e-a450-c7ac6e675ca9@github.com>
Message-ID: <j2mRsyfdr2C1wXxCK9OaKdxMJlluaQ-Ynl22G0JqZ8c=.f382277e-57bb-4976-abe4-37d0f99aa66e@github.com>

On Wed, 19 Apr 2023 13:22:54 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Roger Riggs 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 8304915-arch-enum
>>  - ArchTest on Debian RISC-V 64 confirmed by reviewer
>>  - Fixed isPPC64().
>>    Consolidated switch cases in ArchTest.
>>    Moved mapping of build TARGET_OS and TARGET_CPU to the build
>>    to avoid multiple mappings in more than one place.
>>  - Correct mapping and test of ppc64
>>  - Add ppc64 as mapping to PPC64 Architecture
>>  - Modified test to check Architecture is64bits() and isLittleEndian()
>>    against Unsafe respective values.
>>    Relocated code mapping OS name and arch name from PlatformProps to
>>    OperatingSystem and Architecture. Kept the mapping of names
>>    in the template close to where the values are filled in by the build.
>>  - Remove unused static and import of Stabile
>>  - Rename OperatingSystemProps to PlatformProps.
>>    Refactor OperatingSystem initialization to use strings instead of integers.
>>  - Revised mapping mechanism of build target architecture names to enum values.
>>    Unrecognized values from the build are mapped to enum value "OTHER".
>>    Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
>>    Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
>>  - Revert changes to jdk.accessibility AccessBridge
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e
>
> test/jdk/jdk/internal/util/ArchTest.java line 71:
> 
>> 69:             case "aarch64" -> AARCH64;
>> 70:             case "riscv64" -> RISCV64;
>> 71:             case "s390x", "s390" -> S390;  // unverified
> 
> This was also verified according to comments. Right, @offamitkumar?

Yes, you're correct @TheRealMDoerr

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1171580811

From amitkumar at openjdk.org  Wed Apr 19 16:29:57 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 19 Apr 2023 16:29:57 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v15]
In-Reply-To: <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
Message-ID: <gxHeSPU6S7putMSzEFeMMoFG9Fmeuu7X2bfP8U6_VQc=.6cb3f50a-d1ff-453a-924e-44ba28b74029@github.com>

On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs 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 8304915-arch-enum
>  - ArchTest on Debian RISC-V 64 confirmed by reviewer
>  - Fixed isPPC64().
>    Consolidated switch cases in ArchTest.
>    Moved mapping of build TARGET_OS and TARGET_CPU to the build
>    to avoid multiple mappings in more than one place.
>  - Correct mapping and test of ppc64
>  - Add ppc64 as mapping to PPC64 Architecture
>  - Modified test to check Architecture is64bits() and isLittleEndian()
>    against Unsafe respective values.
>    Relocated code mapping OS name and arch name from PlatformProps to
>    OperatingSystem and Architecture. Kept the mapping of names
>    in the template close to where the values are filled in by the build.
>  - Remove unused static and import of Stabile
>  - Rename OperatingSystemProps to PlatformProps.
>    Refactor OperatingSystem initialization to use strings instead of integers.
>  - Revised mapping mechanism of build target architecture names to enum values.
>    Unrecognized values from the build are mapped to enum value "OTHER".
>    Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
>    Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
>  - Revert changes to jdk.accessibility AccessBridge
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e

for s390x, build is fine and tier1 (specifically `ArchTest.java`) passes. 

Thanks for the change.

-------------

Marked as reviewed by amitkumar (Author).

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1392455297

From duke at openjdk.org  Wed Apr 19 16:34:50 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 19 Apr 2023 16:34:50 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v5]
In-Reply-To: <UyIr5-Bf33M8kJdtAQe0w_6IxUoVEBbJ6WKcckkj1Ko=.7bd80f6b-10c0-4f50-8f1c-150be20285ed@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <UyIr5-Bf33M8kJdtAQe0w_6IxUoVEBbJ6WKcckkj1Ko=.7bd80f6b-10c0-4f50-8f1c-150be20285ed@github.com>
Message-ID: <lOyDTU0tztLvQPxeU2Pb2qlyTWPVJXNcQjSr_o_7oxI=.a65b43ef-f9fd-4fc9-9165-c3c245e6a530@github.com>

On Wed, 19 Apr 2023 16:02:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
>> 
>> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
>> 
>> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
>> 
>> Additional testing:
>>   - [x] New regression test
>>   - [x] New benchmark
>>   - [x] Linux x86_64 `tier1`
>>   - [x] Linux AArch64 `tier1`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Windows fixes: align(...) is only for power-of-two alignments

src/java.base/share/classes/java/lang/Thread.java line 516:

> 514:     }
> 515: 
> 516:     private static native void sleep0(long nanos) throws InterruptedException;

Maybe?name?this `sleepNanos0`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1171590875

From vromero at openjdk.org  Wed Apr 19 16:47:52 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 19 Apr 2023 16:47:52 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
Message-ID: <LKbcXB4x0lWXcYeoG-xpoSZDc1Kdp5M5Cb1FaA5Ts4Q=.9d32c4ed-0e57-4153-9124-4ed961631532@github.com>

On Tue, 18 Apr 2023 09:13:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>  - Reflecting review comments.
>  - Fixing exhaustiveness for unsealed supertype pattern.
>  - No need to enable features after error reported.
>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>  - A prototype of avoiding enum initialization.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 279:

> 277:     }
> 278: 
> 279:     private static int lazyDoEnumSwitch(Enum<?> target, int startIndex, Object[] labels, MethodHandles.Lookup lookup, Class<?> enumClass, MutableCallSite callSite) throws Throwable {

can `doEnumSwitch` be folded into `lazyDoEnumSwitch`? just a suggestion, I'm OK with either way just that now it is not clear that we need two methods here. Also in `doEnumSwitch` and out of curiosity what example of user code could hit this section:


            if (label instanceof Class<?> c) {
                if (c.isAssignableFrom(targetClass))
                    return i;
            }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1171605248

From duke at openjdk.org  Wed Apr 19 16:53:45 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 19 Apr 2023 16:53:45 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v3]
In-Reply-To: <NDZsJbnOay2IPYbjJ-E_asohiAS8eJpqd0mHbh1EmsE=.7d30affe-510c-476e-8def-042ced74b017@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <NDZsJbnOay2IPYbjJ-E_asohiAS8eJpqd0mHbh1EmsE=.7d30affe-510c-476e-8def-042ced74b017@github.com>
Message-ID: <c-LRHLH8gGGaSl037UMETxL744GNx3NFHRaYPN85Vbc=.6ded3436-f389-46a2-896c-a7d8ef040d58@github.com>

On Wed, 19 Apr 2023 13:44:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API didn't handle transformations of class files version 50 and below correctly. 
>> 
>> Proposed fix have two parts: 
>> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
>> 2. StackMapTable attribute is not generated for class file versions below 50.
>> 
>> StackMapsTest is also extended to test this patch.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed ClassPrinterImpl

src/java.base/share/classes/jdk/internal/classfile/Opcode.java line 261:

> 259:         NEW_OBJECT, NEW_PRIMITIVE_ARRAY, NEW_REF_ARRAY, NEW_MULTI_ARRAY,
> 260:         TYPE_CHECK, ARRAY_LOAD, ARRAY_STORE, STACK, CONVERT, OPERATOR, CONSTANT,
> 261:         MONITOR, NOP, DISCONTINUED_JSR, DISCONTINUED_RET ;

**Nit:** extraneous?space:
Suggestion:

        MONITOR, NOP, DISCONTINUED_JSR, DISCONTINUED_RET;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13478#discussion_r1171604873

From simonis at openjdk.org  Wed Apr 19 16:56:59 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 19 Apr 2023 16:56:59 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle negative
 array sizes without throwing NegativeArraySizeExceptions
Message-ID: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>

This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))

Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.

If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:

Returns:
the non-negative number of array elements when deserializing an array of the class, otherwise -1

but currently returns a negative value if the array length is negative.

-------------

Commit messages:
 - 8306461: ObjectInputStream::readObject() should handle negative array sizes without throwing NegativeArraySizeExceptions

Changes: https://git.openjdk.org/jdk/pull/13540/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13540&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306461
  Stats: 115 lines in 2 files changed: 114 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13540/head:pull/13540

PR: https://git.openjdk.org/jdk/pull/13540

From naoto at openjdk.org  Wed Apr 19 17:00:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Apr 2023 17:00:53 GMT
Subject: RFR: 8305746: InitializeEncoding should cache Charset object
 instead of charset name [v2]
In-Reply-To: <-5FJaGjKracEn1TuejgAwOfz_6VYHdC2o-OFWHJt1uo=.5cf6a646-b835-4f6a-8cbb-9a0ba3b25482@github.com>
References: <n_LC8ej_4-qM15pCWVFcirQyB6RNiH7xQtHiJBWNmI0=.c05c9ac5-5602-4f13-98b6-ec1a126c0975@github.com>
 <O_XJ0eMteZz8UGUp948M219MSbVruXARZxgwN5uJaWw=.16adb547-c449-4007-9cbe-f04e755831ba@github.com>
 <c5XTNkrfnbmMYkIrnJeJ_batLoaEa7A_mVDimh9Wxvc=.8f06d03f-7d8d-46cf-bdfd-d21d786ed232@github.com>
 <-5FJaGjKracEn1TuejgAwOfz_6VYHdC2o-OFWHJt1uo=.5cf6a646-b835-4f6a-8cbb-9a0ba3b25482@github.com>
Message-ID: <Zml4xRoA90abbcancPh_-JCuvMJwrHvEe9w9dqZq4_o=.1903d056-032f-4a75-b3ca-f2a97e439e74@github.com>

On Wed, 19 Apr 2023 06:50:45 GMT, Peter Hofer <phofer at openjdk.org> wrote:

>> src/java.base/share/native/libjava/jni_util.c line 757:
>> 
>>> 755:                 jnuEncoding = (*env)->NewGlobalRef(env, charset.l);
>>> 756:                 (*env)->DeleteLocalRef(env, charset.l);
>>> 757:                 break;
>> 
>> Could return immediately
>
> No, then the method id cache would not get initialized below. But I will add a comment.

You are right, those init code should follow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13499#discussion_r1171618399

From naoto at openjdk.org  Wed Apr 19 17:00:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Apr 2023 17:00:50 GMT
Subject: RFR: 8305746: InitializeEncoding should cache Charset object
 instead of charset name [v3]
In-Reply-To: <RohbIQaAUjTjxuaqWfptye1N6HaUSsiK77qHfAUfOes=.01d5b37a-2043-458b-851f-f8a3690a2c60@github.com>
References: <n_LC8ej_4-qM15pCWVFcirQyB6RNiH7xQtHiJBWNmI0=.c05c9ac5-5602-4f13-98b6-ec1a126c0975@github.com>
 <RohbIQaAUjTjxuaqWfptye1N6HaUSsiK77qHfAUfOes=.01d5b37a-2043-458b-851f-f8a3690a2c60@github.com>
Message-ID: <FGbuQDwMghK14nDsOlX0PmkEvilO-Mn5YJIKck4Ngi4=.bd121e45-ba88-431a-acc5-844359cc8679@github.com>

On Wed, 19 Apr 2023 07:08:53 GMT, Peter Hofer <phofer at openjdk.org> wrote:

>> Store `Charset` object in `jnuEncoding` and use `String(byte[], Charset)` and `String.getBytes(Charset)` instead of passing the charset name.
>
> Peter Hofer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8305746
>  - Rename jnuEncoding to jnuCharset.
>  - 8305746: InitializeEncoding should cache Charset object instead of charset name

Looks good to me. Thanks for the change.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13499#pullrequestreview-1392505454

From darcy at openjdk.org  Wed Apr 19 17:06:45 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 19 Apr 2023 17:06:45 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions
In-Reply-To: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
Message-ID: <7vStHe4ivE6O9xL3fd98AJGKvvDRdkwymAqF2lNgw6A=.91eb28e0-7d9a-433c-9b47-80084e822454@github.com>

On Wed, 19 Apr 2023 16:47:33 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
> 
> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
> 
> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
> 
> Returns:
> the non-negative number of array elements when deserializing an array of the class, otherwise -1
> 
> but currently returns a negative value if the array length is negative.

Please file a CSR for the proposed behavioral change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13540#issuecomment-1515077819

From liach at openjdk.org  Wed Apr 19 17:07:57 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Apr 2023 17:07:57 GMT
Subject: RFR: 8306457: Classfile API components implementations should not be
 exposed
Message-ID: <67PAXfiqaTaU8vYbbA31WJBG029RHK454HIDp5ZlYx8=.ec9b4ddd-fe42-4236-9e44-ef63e164e906@github.com>

The jdk.internal.classfile.components package's interfaces have implementations in their nested classes, which are implicitly public and exported with the package. They are now moved to the impl package to avoid unwanted exposures. Fixed a few minor javadoc issues in the interfaces as well.

In conflict with #13021; one needs updating if the other is merged.

-------------

Commit messages:
 - 8306457: Classfile API components implementations should not be exposed

Changes: https://git.openjdk.org/jdk/pull/13541/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13541&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306457
  Stats: 1770 lines in 8 files changed: 919 ins; 825 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/13541.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13541/head:pull/13541

PR: https://git.openjdk.org/jdk/pull/13541

From liach at openjdk.org  Wed Apr 19 17:12:50 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Apr 2023 17:12:50 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v3]
In-Reply-To: <NDZsJbnOay2IPYbjJ-E_asohiAS8eJpqd0mHbh1EmsE=.7d30affe-510c-476e-8def-042ced74b017@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <NDZsJbnOay2IPYbjJ-E_asohiAS8eJpqd0mHbh1EmsE=.7d30affe-510c-476e-8def-042ced74b017@github.com>
Message-ID: <VkimOrcXslKpl6DeJGdC16MCpM7H-5lCJBZH3tDcS5c=.22ec33d2-285d-4c0c-bd8d-aacbe86405a5@github.com>

On Wed, 19 Apr 2023 13:44:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API didn't handle transformations of class files version 50 and below correctly. 
>> 
>> Proposed fix have two parts: 
>> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
>> 2. StackMapTable attribute is not generated for class file versions below 50.
>> 
>> StackMapsTest is also extended to test this patch.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed ClassPrinterImpl

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java line 724:

> 722:         public int branchByteOffset() {
> 723:             return size == 3
> 724:                    ? (int) (short) code.classReader.readU2(pos + 1)

Suggestion:

                   ? code.classReader.readS2(pos + 1)

the assembly of this offset is the same as the assembly of the increment amount in wide iinc.

src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 86:

> 84:     }
> 85: 
> 86:     public void setMajorVersion(int majorVersion) {

We should ensure the version is not changed once writing has already happened, and the constant pool builder should have access to the major version as well to prevent writing of invalid entries (like condy before java 11)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13478#discussion_r1171622180
PR Review Comment: https://git.openjdk.org/jdk/pull/13478#discussion_r1171630285

From mchhipa at openjdk.org  Wed Apr 19 17:32:49 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 19 Apr 2023 17:32:49 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v2]
In-Reply-To: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
Message-ID: <3lnrGKNGhXmeJeCu5gY4R8vpoIOC-vh-U7VuX0KXS_M=.bffd3422-f532-4716-9692-8be5e0f3c8b1@github.com>

> Test is updated to create the binary files during test execution.

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  closed file handlers.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13537/files
  - new: https://git.openjdk.org/jdk/pull/13537/files/911da859..209152ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13537/head:pull/13537

PR: https://git.openjdk.org/jdk/pull/13537

From liach at openjdk.org  Wed Apr 19 17:36:49 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Apr 2023 17:36:49 GMT
Subject: RFR: 8304148: Remapping a class with Invokedynamic constant loses
 static bootstrap arguments [v2]
In-Reply-To: <EIUs05Df8NiqCYKNz7X_US5InbJK2xh69x1quzsq_Fo=.a17a0743-ed3a-41c5-a268-c6ca9af1dfa0@github.com>
References: <BRqOfbw2AgskyvSwhb6zwW0m-hDgAtW77OlztQcjOfA=.8ce1a503-d4e3-40d4-b1db-22610910ea3c@github.com>
 <EIUs05Df8NiqCYKNz7X_US5InbJK2xh69x1quzsq_Fo=.a17a0743-ed3a-41c5-a268-c6ca9af1dfa0@github.com>
Message-ID: <nPTxpLJVRAuwc8unj7elafZLdfgQbMuKfIAXvMM10EE=.dcd45f92-e240-47bc-8de1-991a4028d531@github.com>

On Wed, 22 Mar 2023 11:59:30 GMT, Thiago Henrique H?pner <duke at openjdk.org> wrote:

>> 8304148: Remapping a class with Invokedynamic constant loses static bootstrap arguments
>
> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Keep-alive; if a reviewer can approve this and have this integrated, I can base my work on 8306547 upon this to resolve conflicts.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13021#issuecomment-1515113795

From rriggs at openjdk.org  Wed Apr 19 17:44:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Apr 2023 17:44:47 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v5]
In-Reply-To: <8EBRIAmr9MzpU6U654LjdVS4w54tcsfCDqhnX5HvuHI=.7da22500-928c-4048-a13e-27c15b95c356@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <8EBRIAmr9MzpU6U654LjdVS4w54tcsfCDqhnX5HvuHI=.7da22500-928c-4048-a13e-27c15b95c356@github.com>
Message-ID: <QdSgT5wv0x_cDw-eMBv3PcGp9MGb5XpsvMf69MiR43g=.cd518257-b2d6-4ae4-8c31-91f468954203@github.com>

On Tue, 18 Apr 2023 18:49:54 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300818: special cases

test/micro/org/openjdk/bench/java/time/format/DateTimeFormatterBench.java line 122:

> 120:     }
> 121: 
> 122: }

Drop this blank line and there will be no changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1171524385

From simonis at openjdk.org  Wed Apr 19 17:48:43 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 19 Apr 2023 17:48:43 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions
In-Reply-To: <7vStHe4ivE6O9xL3fd98AJGKvvDRdkwymAqF2lNgw6A=.91eb28e0-7d9a-433c-9b47-80084e822454@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <7vStHe4ivE6O9xL3fd98AJGKvvDRdkwymAqF2lNgw6A=.91eb28e0-7d9a-433c-9b47-80084e822454@github.com>
Message-ID: <wa2Z0G7yHSuSG-6W_rSFkV_wrZh0lnDllTrhGqcjJpk=.aa9ca185-09c7-470d-b6dd-9228d00a60b5@github.com>

On Wed, 19 Apr 2023 17:04:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> Please file a CSR for the proposed behavioral change.

Hi @jddarcy,

I'm happy to create a CSR for this change, but I'm a little bit unsure about the details. From my understanding this qualifies as a behavioral change, right? But this behavior wasn't specified before at all. Neither did the API specification of `ObjectInputStream::readObject()` mention that it can throw a `NegativeArraySizeException` nor did the [Serialization Specification](https://docs.oracle.com/en/java/javase/20/docs/specs/serialization/index.html) mentioned the case of a negative array size.

Previously, `readObject()` could throw a `NegativeArraySizeException` which will now, with this PR, be changed into a `InvalidClassException`. Do you agree that this is an implementation detail and therefor the CSR should have "Implementation" Scope?

Thanks,
Volker

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13540#issuecomment-1515129984

From smarks at openjdk.org  Wed Apr 19 18:01:28 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 19 Apr 2023 18:01:28 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <aE6pPGD9JA2INISEE2aADCdIPZLeO1xm4VeIO2bPnYo=.ebb83366-e9b4-4d22-8c57-a92cd8cee43f@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
 <aE6pPGD9JA2INISEE2aADCdIPZLeO1xm4VeIO2bPnYo=.ebb83366-e9b4-4d22-8c57-a92cd8cee43f@github.com>
Message-ID: <kkhS6fopg4vgpkZ-knedP-sEzF0oYZxC-0sy7Xu67OY=.44151bba-40c6-40f9-918f-9cd5e443a95b@github.com>

On Wed, 19 Apr 2023 05:51:11 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove unnecessary 'final' from a couple places.
>>  - Clarify ordering of Collection.addAll and Map.putAll; add links to
>>    encounter order.
>>  - Make constructors private for several reverse-ordered views.
>
> src/java.base/share/classes/java/util/Collection.java line 511:
> 
>> 509:      * nonempty.) If the specified collection has a defined
>> 510:      * <a href="SequencedCollection.html#encounter">encounter order</a>,
>> 511:      * processing of its elements generally occurs in that order.
> 
> Shouldn't `remove` also contain such a note? From its docs:
> 
> "More formally, removes an element e such that `Objects.equals(o, e)`, if this collection contains one or more such elements." Can add something like "If the specified collection has a defined *encounter order*, generally removes the first encountered element in that order".

No, the stipulation for removing the first element only applies to explicit-positioned collections like List and Deque.

> src/java.base/share/classes/java/util/Collections.java line 374:
> 
>> 372:      * @apiNote
>> 373:      * This method mutates the specified list in-place. To obtain a
>> 374:      * reversed-ordered view of a list without mutating it, use the
> 
> The term that has been usually used is "reverse-ordered".

Typo.

> src/java.base/share/classes/java/util/Collections.java line 380:
> 
>> 378:      * @throws UnsupportedOperationException if the specified list or
>> 379:      *         its list-iterator does not support the {@code set} operation.
>> 380:      * @see    List#reversed List.reversed
> 
> Is the `@see` tag really useful if you're already linking the method directly?

Requested by another reviewer.

> src/java.base/share/classes/java/util/SequencedCollection.java line 34:
> 
>> 32:  * from the first element to the last element. Given any two elements, one element is
>> 33:  * either before (closer to the first element) or after (closer to the last element)
>> 34:  * the other element.
> 
> The last sentence seems a bit clumsy owing to the abundance of parenthesized content and the confusion of "first element" of the collection with the first element of the 2 chosen for the explanation. How about something like:
> "Given any two elements, one element is either before the other element (it is closer to the collection's start) or after it (closer to the collection's end)"?

Doesn't seem like an improvement.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171686221
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171688269
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171686536
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171687102

From rriggs at openjdk.org  Wed Apr 19 18:08:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Apr 2023 18:08:40 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v16]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <SFXvfinAdc_NguDE-7Pbg6-e29KfL5xmDl1a8gtjKSk=.b07c2f89-f489-44bb-8c31-39035e6969ca@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Use and test of "s390" verified by reviewer.
 - Merge branch 'master' into 8304915-arch-enum
 - Merge branch 'master' into 8304915-arch-enum
 - ArchTest on Debian RISC-V 64 confirmed by reviewer
 - Fixed isPPC64().
   Consolidated switch cases in ArchTest.
   Moved mapping of build TARGET_OS and TARGET_CPU to the build
   to avoid multiple mappings in more than one place.
 - Correct mapping and test of ppc64
 - Add ppc64 as mapping to PPC64 Architecture
 - Modified test to check Architecture is64bits() and isLittleEndian()
   against Unsafe respective values.
   Relocated code mapping OS name and arch name from PlatformProps to
   OperatingSystem and Architecture. Kept the mapping of names
   in the template close to where the values are filled in by the build.
 - Remove unused static and import of Stabile
 - Rename OperatingSystemProps to PlatformProps.
   Refactor OperatingSystem initialization to use strings instead of integers.
 - ... and 9 more: https://git.openjdk.org/jdk/compare/0f3828dd...b95a312d

-------------

Changes: https://git.openjdk.org/jdk/pull/13357/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=15
  Stats: 410 lines in 7 files changed: 342 ins; 57 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

PR: https://git.openjdk.org/jdk/pull/13357

From smarks at openjdk.org  Wed Apr 19 18:08:52 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 19 Apr 2023 18:08:52 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <aE6pPGD9JA2INISEE2aADCdIPZLeO1xm4VeIO2bPnYo=.ebb83366-e9b4-4d22-8c57-a92cd8cee43f@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
 <aE6pPGD9JA2INISEE2aADCdIPZLeO1xm4VeIO2bPnYo=.ebb83366-e9b4-4d22-8c57-a92cd8cee43f@github.com>
Message-ID: <grUCVtPDjHVdfzrYpFOKCmhfuY3jzRzr9EjBvugi-BQ=.aa32f9a0-36cf-43c8-97dd-a47ff774a854@github.com>

On Wed, 19 Apr 2023 09:43:44 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove unnecessary 'final' from a couple places.
>>  - Clarify ordering of Collection.addAll and Map.putAll; add links to
>>    encounter order.
>>  - Make constructors private for several reverse-ordered views.
>
> src/java.base/share/classes/java/util/SequencedCollection.java line 1:
> 
>> 1: /*
> 
> I wonder if there's a point to mention the relation of reversal to the "enhanced for-each" loop. The loop uses the iterator behind the scenes. That means that a reversed collection will iterate backwards in a loop ("enhanced each-for" loop :) ). A backwards iteration can be achieved by
> 
> for (E element : collection.reversed()) {...}
> 
> For collections that support removal, this construct can also be used to remove elements without the concurrent modification problem of removal during iteration which messes up the indices. See, for example, https://stackoverflow.com/questions/10431981/remove-elements-from-collection-while-iterating.

Can't remove using the iterator since it's hidden, and can't remove directly from the collection during iteration without potentially suffering CME. The reverse-iteration trick for removal generally only works for index-based iteration. Not sure what would be useful to add here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171694499

From smarks at openjdk.org  Wed Apr 19 18:15:35 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 19 Apr 2023 18:15:35 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <aE6pPGD9JA2INISEE2aADCdIPZLeO1xm4VeIO2bPnYo=.ebb83366-e9b4-4d22-8c57-a92cd8cee43f@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
 <aE6pPGD9JA2INISEE2aADCdIPZLeO1xm4VeIO2bPnYo=.ebb83366-e9b4-4d22-8c57-a92cd8cee43f@github.com>
Message-ID: <uXyluMOKw59w5RpOE5_fyKeMrPDu_fe1JNU_RoKzsNg=.edd0a65b-fdf4-4dd6-9b8e-ef5da1dc37c1@github.com>

On Wed, 19 Apr 2023 10:06:38 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove unnecessary 'final' from a couple places.
>>  - Clarify ordering of Collection.addAll and Map.putAll; add links to
>>    encounter order.
>>  - Make constructors private for several reverse-ordered views.
>
> src/java.base/share/classes/java/util/SequencedCollection.java line 98:
> 
>> 96:      *
>> 97:      * @implSpec
>> 98:      * The implementation in this class always throws {@code UnsupportedOperationException}.
> 
> class -> interface? This appears in other interfaces as well. We tend to code to interfaces with collections, so this distinction seems relevant.

There's some ambiguity here; "class" can refer to an ordinary concrete or abstract class, a record class, an interface, an enumeration, an annotation type, and probably more things in the future. This is referring to the implementation that actually resides in `java.util.SequencedCollection.class`. If "interface" were used this would tend to imply that it's inherited by implementations of SequencedCollection, which it definitely isn't. I'm leaning toward standardized `@implSpec` wording of "the implementation in this class..."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171701316

From smarks at openjdk.org  Wed Apr 19 18:25:13 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 19 Apr 2023 18:25:13 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <aE6pPGD9JA2INISEE2aADCdIPZLeO1xm4VeIO2bPnYo=.ebb83366-e9b4-4d22-8c57-a92cd8cee43f@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
 <aE6pPGD9JA2INISEE2aADCdIPZLeO1xm4VeIO2bPnYo=.ebb83366-e9b4-4d22-8c57-a92cd8cee43f@github.com>
Message-ID: <E_2N7pkTJzQY15jp82QSdCtpUZAeJNLZ03Q2XdIZK8w=.96f2142f-2d96-4b20-8ed8-48ecea7654e8@github.com>

On Wed, 19 Apr 2023 14:19:01 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove unnecessary 'final' from a couple places.
>>  - Clarify ordering of Collection.addAll and Map.putAll; add links to
>>    encounter order.
>>  - Make constructors private for several reverse-ordered views.
>
> src/java.base/share/classes/java/util/SequencedMap.java line 110:
> 
>> 108:  * {@code Entry} thus obtained will update a mapping in the underlying map, or whether
>> 109:  * it will throw an exception, or whether changes to the underlying map are visible in
>> 110:  * that {@code Entry}.
> 
> These 3 paragraphs all talk about `Entry`s' connection to the map. I think that they can be reconciled by explicitly noting each way to get an entry and the conditions that apply on it. In broad strokes:
> 
>> `{@link Map.Entry}` instances can be obtained in several ways.
>> By iterating the `{@link #entrySet}` view... These entries maintain a connection...
>> By calling the `{@link #firstEntry}`... methods. These entries represent snapshots of...
>> By other means, such as from methods of views of the map (`sequencedMap.sequencedEntrySet().getFirst();`). These entries entries might or might not be connected...

Not sure what you're suggesting here. There are indeed different ways to obtain entries, but they can't be reconciled because the spec imposes different requirements (or explicitly leaves things unspecified) on entries obtained by different means.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171710625

From smarks at openjdk.org  Wed Apr 19 18:32:07 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 19 Apr 2023 18:32:07 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <aE6pPGD9JA2INISEE2aADCdIPZLeO1xm4VeIO2bPnYo=.ebb83366-e9b4-4d22-8c57-a92cd8cee43f@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
 <aE6pPGD9JA2INISEE2aADCdIPZLeO1xm4VeIO2bPnYo=.ebb83366-e9b4-4d22-8c57-a92cd8cee43f@github.com>
Message-ID: <-6D1156PjJrBk8F3V5vvEJ_IVv9Yqsf6xHJuvGjcVJA=.0b1e1f19-3b1a-4bb6-90c9-e054807b09a7@github.com>

On Wed, 19 Apr 2023 12:27:41 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove unnecessary 'final' from a couple places.
>>  - Clarify ordering of Collection.addAll and Map.putAll; add links to
>>    encounter order.
>>  - Make constructors private for several reverse-ordered views.
>
> src/java.base/share/classes/java/util/NavigableSet.java line 361:
> 
>> 359:      * {@inheritDoc}
>> 360:      * <p>
>> 361:      * This method is equivalent to {@link #descendingSet descendingSet}.
> 
> Doesn't `{@link #descendingSet}` display as `descendingSet` already? The same pattern appears in other places.

It would display as `descendingSet()` with the empty parens for the arguments. Not a big deal in this case. If there were arguments, though, the parameter types would all be listed as well, adding considerable clutter. Out of habit I use the plain form consistently.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171716527

From shade at openjdk.org  Wed Apr 19 18:38:55 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 18:38:55 GMT
Subject: RFR: 8306452: Fix Amazon copyright in JDK-8305425 test
In-Reply-To: <qL6kNqSUJfDoIZ1i7j_Y_pH-xkOiTECYF5quWlc2szs=.55164a77-c92f-43e6-afac-0f51b23b55a2@github.com>
References: <qL6kNqSUJfDoIZ1i7j_Y_pH-xkOiTECYF5quWlc2szs=.55164a77-c92f-43e6-afac-0f51b23b55a2@github.com>
Message-ID: <921bb4ORGGdcYieWuDyl4GA2VfJ_S81pAmb_T5EnVaE=.79bfe0a3-5d83-486b-a5ef-01d7d1135e0d@github.com>

On Wed, 19 Apr 2023 13:57:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Someone^W I did commit a test in the OpenJDK repo that has Amazon copyright notice in the form that is not inline with the preferred one (intentionally without copyright year):
> 
> "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved."
> 
> These should be fixed.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13534#issuecomment-1515191371

From shade at openjdk.org  Wed Apr 19 18:38:57 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 18:38:57 GMT
Subject: Integrated: 8306452: Fix Amazon copyright in JDK-8305425 test
In-Reply-To: <qL6kNqSUJfDoIZ1i7j_Y_pH-xkOiTECYF5quWlc2szs=.55164a77-c92f-43e6-afac-0f51b23b55a2@github.com>
References: <qL6kNqSUJfDoIZ1i7j_Y_pH-xkOiTECYF5quWlc2szs=.55164a77-c92f-43e6-afac-0f51b23b55a2@github.com>
Message-ID: <o7X9Gr4u6B7OZ4NbCTY-vkjq5jAbRx5znjPqVpFk2ww=.e074ca2e-6e58-4c2a-8f53-b49c0867b488@github.com>

On Wed, 19 Apr 2023 13:57:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Someone^W I did commit a test in the OpenJDK repo that has Amazon copyright notice in the form that is not inline with the preferred one (intentionally without copyright year):
> 
> "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved."
> 
> These should be fixed.

This pull request has now been integrated.

Changeset: e764e9b7
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e764e9b740509ae1262ed0a41ab0dee9c313074d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8306452: Fix Amazon copyright in JDK-8305425 test

Reviewed-by: simonis

-------------

PR: https://git.openjdk.org/jdk/pull/13534

From shade at openjdk.org  Wed Apr 19 18:40:50 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 18:40:50 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v5]
In-Reply-To: <lOyDTU0tztLvQPxeU2Pb2qlyTWPVJXNcQjSr_o_7oxI=.a65b43ef-f9fd-4fc9-9165-c3c245e6a530@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <UyIr5-Bf33M8kJdtAQe0w_6IxUoVEBbJ6WKcckkj1Ko=.7bd80f6b-10c0-4f50-8f1c-150be20285ed@github.com>
 <lOyDTU0tztLvQPxeU2Pb2qlyTWPVJXNcQjSr_o_7oxI=.a65b43ef-f9fd-4fc9-9165-c3c245e6a530@github.com>
Message-ID: <DFXqQZmkCkLcZVWWH9p6tApw94O4pHqzn3sLnX7KpF4=.dc48f22f-597d-43c5-8541-0f51ff493e66@github.com>

On Wed, 19 Apr 2023 16:32:05 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Windows fixes: align(...) is only for power-of-two alignments
>
> src/java.base/share/classes/java/lang/Thread.java line 516:
> 
>> 514:     }
>> 515: 
>> 516:     private static native void sleep0(long nanos) throws InterruptedException;
> 
> Maybe?name?this `sleepNanos0`?

No, I don't think so. The name of this function is not relevant, as nothing else is calling it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1171725698

From shade at openjdk.org  Wed Apr 19 18:46:49 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 18:46:49 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v6]
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <-sDYWBguIUjiok6GP3WWaDkIKNLCCg6PcOkGkApY1lc=.87611b1b-f317-4eb8-b030-f36d8c93069c@github.com>

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Windows again

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13225/files
  - new: https://git.openjdk.org/jdk/pull/13225/files/29c7df36..0e05a2f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13225/head:pull/13225

PR: https://git.openjdk.org/jdk/pull/13225

From alanb at openjdk.org  Wed Apr 19 18:53:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Apr 2023 18:53:48 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v5]
In-Reply-To: <UyIr5-Bf33M8kJdtAQe0w_6IxUoVEBbJ6WKcckkj1Ko=.7bd80f6b-10c0-4f50-8f1c-150be20285ed@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <UyIr5-Bf33M8kJdtAQe0w_6IxUoVEBbJ6WKcckkj1Ko=.7bd80f6b-10c0-4f50-8f1c-150be20285ed@github.com>
Message-ID: <_d0byYtDkJ2aDfgwQjWMSas2GtW359jasdHJOvAkBg4=.87bef233-43c6-4bf1-8986-80761cd333f1@github.com>

On Wed, 19 Apr 2023 16:02:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
>> 
>> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
>> 
>> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
>> 
>> Additional testing:
>>   - [x] New regression test
>>   - [x] New benchmark
>>   - [x] Linux x86_64 `tier1`
>>   - [x] Linux AArch64 `tier1`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Windows fixes: align(...) is only for power-of-two alignments

test/jdk/java/lang/Thread/SleepSanity.java line 48:

> 46: 
> 47:         for (final int millis : TRY_MILLIS) {
> 48:             testTimes(() -> Thread.sleep(millis), millis, 10_000);

I wonder if 10s is enough a tolerance. JDK-8303633 has some sightings of sleep(1000) taking 5.5s. We've since changed all of these to 20s. It might be that 10s is okay, it's just that we seem to run on some test systems (Windows mostly) where we need very high tolerance for tests like this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1171736726

From aturbanov at openjdk.org  Wed Apr 19 19:08:43 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 19 Apr 2023 19:08:43 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions
In-Reply-To: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
Message-ID: <yBs7xJfNYmHqVBA1mekhNjuoIJjGDk3lzqz8qDQN1Vs=.c0a27536-325c-4c1d-b1ac-0c5b9cc4662a@github.com>

On Wed, 19 Apr 2023 16:47:33 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
> 
> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
> 
> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
> 
> Returns:
> the non-negative number of array elements when deserializing an array of the class, otherwise -1
> 
> but currently returns a negative value if the array length is negative.

test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 69:

> 67:         serializedData[firstPos+5] = (byte) 0xfe;
> 68: 
> 69:         return  serializedData;

Suggestion:

        return serializedData;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1171750038

From joehw at openjdk.org  Wed Apr 19 19:20:44 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 19 Apr 2023 19:20:44 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v2]
In-Reply-To: <3lnrGKNGhXmeJeCu5gY4R8vpoIOC-vh-U7VuX0KXS_M=.bffd3422-f532-4716-9692-8be5e0f3c8b1@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
 <3lnrGKNGhXmeJeCu5gY4R8vpoIOC-vh-U7VuX0KXS_M=.bffd3422-f532-4716-9692-8be5e0f3c8b1@github.com>
Message-ID: <AMowtnuv3yvtPNUzBREaNsCZAxyUjTD4vZS0a6BnNcU=.40c40820-2901-4463-8f99-1b86751c23d5@github.com>

On Wed, 19 Apr 2023 17:32:49 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Test is updated to create the binary files during test execution.
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   closed file handlers.

Looks good overall

test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 89:

> 87:             }
> 88:             if(!Files.exists(Path.of(filePath, jdkVersion+"t"+FILENAME_DURATION ))) {
> 89:                 DatatypeFactory dtf = DatatypeFactory.newInstance();

Probably share the factory rather than creating one in each loop and twice.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13537#pullrequestreview-1392731286
PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1171758806

From shade at openjdk.org  Wed Apr 19 19:55:38 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 19:55:38 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v7]
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <vHGXWJN2gsfsb9F53ya4eVlsVctH8yUnsvJd9YnkBHI=.4f5983b9-1793-444d-a99e-c0572dac6436@github.com>

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Adjust test times

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13225/files
  - new: https://git.openjdk.org/jdk/pull/13225/files/0e05a2f8..8617b5ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=05-06

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13225/head:pull/13225

PR: https://git.openjdk.org/jdk/pull/13225

From shade at openjdk.org  Wed Apr 19 19:55:42 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 19:55:42 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v5]
In-Reply-To: <_d0byYtDkJ2aDfgwQjWMSas2GtW359jasdHJOvAkBg4=.87bef233-43c6-4bf1-8986-80761cd333f1@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <UyIr5-Bf33M8kJdtAQe0w_6IxUoVEBbJ6WKcckkj1Ko=.7bd80f6b-10c0-4f50-8f1c-150be20285ed@github.com>
 <_d0byYtDkJ2aDfgwQjWMSas2GtW359jasdHJOvAkBg4=.87bef233-43c6-4bf1-8986-80761cd333f1@github.com>
Message-ID: <WX9pf62mRZPMpocf4Mzc6HUpkDD25wC7NGTphlyABKU=.fca121e7-62b5-48d3-97b1-7a6c69f264c7@github.com>

On Wed, 19 Apr 2023 18:50:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Windows fixes: align(...) is only for power-of-two alignments
>
> test/jdk/java/lang/Thread/SleepSanity.java line 48:
> 
>> 46: 
>> 47:         for (final int millis : TRY_MILLIS) {
>> 48:             testTimes(() -> Thread.sleep(millis), millis, 10_000);
> 
> I wonder if 10s is enough a tolerance. JDK-8303633 has some sightings of sleep(1000) taking 5.5s. We've since changed all of these to 20s. It might be that 10s is okay, it's just that we seem to run on some test systems (Windows mostly) where we need very high tolerance for tests like this.

Yeah, I was wondering about the same when writing the test. I have not seen it failing yet, and it was pretty slow without the parallelization. To handle the ~5s hiccups, I bumped all "times" tests from 10s to 20s. I kept "timeout" tests at the same 5s timeout, because they normally do wait for those 5s. The accidental hiccup would make timeout test accidentally pass, which I think is a fair trade for keeping the test execution times low.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1171789353

From jlu at openjdk.org  Wed Apr 19 19:59:36 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 19 Apr 2023 19:59:36 GMT
Subject: RFR: 8306031: Update IANA Language Subtag Registry to Version
 2023-04-13
Message-ID: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>

Update the registry and accompanying tests with the **IANA 4/13/2022** update.

This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.

This causes unexpected failures in JDK tests because of how locale equivalencies are created.

eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`

Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following


...
singleEquivMap.put("ar-ajp", "ajp");
singleEquivMap.put("ajp", "ar-ajp");
...
multiEquivsMap.put("apj", new String[] {"apc", "ar-apc"});
multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
...


When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:

`apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`

When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.

To address this, the build process must be adjusted so that the equivalencies are built as 


...
multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
...


As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.

-------------

Commit messages:
 - Adjust build and test to account for new case
 - ajp should follow apc
 - Fix order of langs
 - Update test with preffered value: ajp
 - Update registry

Changes: https://git.openjdk.org/jdk/pull/13501/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13501&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306031
  Stats: 28 lines in 3 files changed: 19 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13501.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13501/head:pull/13501

PR: https://git.openjdk.org/jdk/pull/13501

From jlu at openjdk.org  Wed Apr 19 20:07:32 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 19 Apr 2023 20:07:32 GMT
Subject: RFR: 8306031: Update IANA Language Subtag Registry to Version
 2023-04-13 [v2]
In-Reply-To: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
Message-ID: <rIjFDs6KOwnkWJTLtfvHYb08re-2STSCQWrSyiTdTuk=.c221d2da-11d8-4ff2-b9ec-0df188092fdc@github.com>

> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
> 
> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
> 
> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
> 
> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
> 
> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
> 
> 
> ...
> singleEquivMap.put("ar-ajp", "ajp");
> singleEquivMap.put("ajp", "ar-ajp");
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
> ...
> 
> 
> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
> 
> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
> 
> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
> 
> To address this, the build process must be adjusted so that the equivalencies are built as 
> 
> 
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
> ...
> 
> 
> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13501/files
  - new: https://git.openjdk.org/jdk/pull/13501/files/30e0ef83..e5d332ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13501&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13501&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13501.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13501/head:pull/13501

PR: https://git.openjdk.org/jdk/pull/13501

From naoto at openjdk.org  Wed Apr 19 22:54:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Apr 2023 22:54:48 GMT
Subject: RFR: 8306031: Update IANA Language Subtag Registry to Version
 2023-04-13 [v2]
In-Reply-To: <rIjFDs6KOwnkWJTLtfvHYb08re-2STSCQWrSyiTdTuk=.c221d2da-11d8-4ff2-b9ec-0df188092fdc@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
 <rIjFDs6KOwnkWJTLtfvHYb08re-2STSCQWrSyiTdTuk=.c221d2da-11d8-4ff2-b9ec-0df188092fdc@github.com>
Message-ID: <FH2rUqpAjgRhVlqZE0VrdSc0H21Qz0b2-BJh0VyyC4o=.ac80c0db-66c5-42d8-847c-193cf6cce217@github.com>

On Wed, 19 Apr 2023 20:07:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
>> 
>> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
>> 
>> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
>> 
>> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
>> 
>> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
>> 
>> 
>> ...
>> singleEquivMap.put("ar-ajp", "ajp");
>> singleEquivMap.put("ajp", "ar-ajp");
>> ...
>> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
>> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
>> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
>> ...
>> 
>> 
>> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
>> 
>> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
>> 
>> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
>> 
>> To address this, the build process must be adjusted so that the equivalencies are built as 
>> 
>> 
>> ...
>> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
>> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
>> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
>> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
>> ...
>> 
>> 
>> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 2:

> 1: /*
> 2:  * Copyright (c) 2012, 2023, Oracle and/or its affiliates. All rights reserved.

Cannot comment on unmodified lines, but instead of calculating the initial load itself, `HashMap.newHashMap()` can be used for initializing maps.

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 144:

> 142:                 boolean foundInOther = false;
> 143:                 final String finalPref = ","+preferred;
> 144:                 final String inbtwnPref = ","+preferred+",";

This could utilize regex?

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 146:

> 144:                 final String inbtwnPref = ","+preferred+",";
> 145:                 // Check if current pref exists inside a value for another pref
> 146:                 List<StringBuilder> doublePrefs = initialLanguageMap.entrySet()

`values()` fits here

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 150:

> 148:                                 e.getValue().toString().contains(inbtwnPref)))
> 149:                         .map(Map.Entry::getValue)
> 150:                         .collect(Collectors.toList());

Can replace `collect()` with `toList()`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1171923706
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1171920639
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1171922562
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1171923033

From vromero at openjdk.org  Wed Apr 19 23:21:49 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 19 Apr 2023 23:21:49 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
Message-ID: <Z4xq7PIsD_bVcAgmhQmoS_Fape68e0_wUuUaRXlaWrU=.26c54a19-7de9-4d86-95fb-315a5808ac36@github.com>

On Tue, 18 Apr 2023 09:13:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>  - Reflecting review comments.
>  - Fixing exhaustiveness for unsealed supertype pattern.
>  - No need to enable features after error reported.
>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>  - A prototype of avoiding enum initialization.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 201:

> 199:     /** Are unconditional patterns in instanceof allowed
> 200:      */
> 201:     private boolean allowUnconditionalPatternsInstanceOf;

so I guess this field can be made final now

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 909:

> 907: 
> 908:                             Set<Symbol> permitted = allPermittedSubTypes(clazz, csym -> {
> 909:                                 Type instantiated = infer.instantiatePatternType(selectorType, csym);

for some cases, when there are no type parameters, this invocation is a no-op, do we really need inference at this point?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1171830887
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1171936405

From smarks at openjdk.org  Thu Apr 20 00:04:06 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 20 Apr 2023 00:04:06 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <aE6pPGD9JA2INISEE2aADCdIPZLeO1xm4VeIO2bPnYo=.ebb83366-e9b4-4d22-8c57-a92cd8cee43f@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
 <aE6pPGD9JA2INISEE2aADCdIPZLeO1xm4VeIO2bPnYo=.ebb83366-e9b4-4d22-8c57-a92cd8cee43f@github.com>
Message-ID: <ZK2bIZNUAnCBzUiBy-K800zo69HPuG5bQPcEe1m0B88=.55760617-4145-4f8f-be79-ade4b0d3f8bd@github.com>

On Wed, 19 Apr 2023 14:41:59 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove unnecessary 'final' from a couple places.
>>  - Clarify ordering of Collection.addAll and Map.putAll; add links to
>>    encounter order.
>>  - Make constructors private for several reverse-ordered views.
>
> I reviewed some of the public documentation and left some comments and thoughts. As a general remark, the documentation could use [Code Snippets](https://openjdk.org/jeps/413) to avoid the `<pre>{@code` pattern.

@nlisker OK I've accepted some of the editorial comments, converted code samples to snippets, etc. However I didn't add markup around every keyword as `{@code List}` when it's used as an ordinary noun. That's the prevailing style in this area, at least mine (though there are probably inconsistencies across the JDK). I find that excessive markup clutters both the marked-up javadoc and also the visually rendered output.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1515526836

From jvernee at openjdk.org  Thu Apr 20 00:34:50 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Apr 2023 00:34:50 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v5]
In-Reply-To: <ro98kdnxpFUFHxlbire-LCADfFhx4EfRTi6o0YWAhak=.9c7ed81b-64aa-494f-a456-53124ce38f02@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
 <DD0nvfK8sVvqOdwEKyIzOz1mRkSnRD63xf34EFDXvkE=.c73f7231-a80d-4d71-9586-b27e67f4a5f3@github.com>
 <ro98kdnxpFUFHxlbire-LCADfFhx4EfRTi6o0YWAhak=.9c7ed81b-64aa-494f-a456-53124ce38f02@github.com>
Message-ID: <f4MSrzIO9D5znEJ6apoFysBq0R7DiA0KLj2Tu-wwZyA=.62b4b670-2577-47f4-8456-c624e869a055@github.com>

On Tue, 18 Apr 2023 22:17:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - fix TestIllegalLink
>>  - Merge branch 'PR_21' into RejectPacked
>>  - Merge branch 'PR_21' into RejectPacked
>>  - add javadoc + fixes for trailing padding
>>  - fix check for padding. Add check for trailing padding too
>>  - Reject packed structs and structs with extra padding
>>  - Check byte order of layouts passed to linker
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 200:
> 
>> 198:  * </table></blockquote>
>> 199:  * <p>
>> 200:  * Due to limited ABI specification coverage, all the native linker implementations limit the function
> 
> `All the native linker implementations support function function descriptors that contain only so-called...`

So, just drop the 'Due to limited ABI specification coverage'? I guess it's not really needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13164#discussion_r1171968181

From jvernee at openjdk.org  Thu Apr 20 00:44:46 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Apr 2023 00:44:46 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v5]
In-Reply-To: <9PSdCi4zwiha6GclDU4KfSCwSjZebxAlWLMinhrSF_A=.a2f8ef6a-031e-4a8b-9886-a8a3d3b9aec4@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
 <DD0nvfK8sVvqOdwEKyIzOz1mRkSnRD63xf34EFDXvkE=.c73f7231-a80d-4d71-9586-b27e67f4a5f3@github.com>
 <L3i2q92HgKXJeg_mm5pak7g1Rb59_Vt0VtJGjcUQ5ds=.ffb1e341-f694-4bae-af3c-0bc5f08e750e@github.com>
 <9PSdCi4zwiha6GclDU4KfSCwSjZebxAlWLMinhrSF_A=.a2f8ef6a-031e-4a8b-9886-a8a3d3b9aec4@github.com>
Message-ID: <0nZpSOymNiVVzyH-Bcp6FSX3l6ub5yhKk9S4KPrUU-M=.ebe95392-5b2b-403d-b4d9-231f218122af@github.com>

On Tue, 18 Apr 2023 22:26:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 202:
>> 
>>> 200:  * Due to limited ABI specification coverage, all the native linker implementations limit the function
>>> 201:  * descriptors that they support to those that contain only so-called <em>canonical</em> layouts. These layouts
>>> 202:  * have the following restrictions:
>> 
>> I think it's better to phrase this more or less as:
>> 
>> A canonical layout has the following characteristics:
>> * Its alignment constraint is equal to its natural alignment
>> * If the layout is a value layout (linkplain), its byte order matches that of the platform in which the JVM is executing (link to nativeOrder())
>> *  If the layout is a group layout (linkplain), it must not contain more padding layout (linkplain) elements than those strictly necessary to satisfy the alignment constraints of the non-padding elements of the group layout.
>
> Also, isn't it the case that, for structs, we want the size of the layout to be a multiple of its alignment constraint?

The third item in the list is for group size needing to be a multiple of the alignment constraint, the forth item refers to that, so I'll keep the ordered list.

WRT byte order: I think it's fine to just say "native byte order". Keep it simple. Or do you think there might be confusion about the meaning of "native"? (It looks like not even ByteOrder::nativeOrder explains that term: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/nio/ByteOrder.html#nativeOrder())

"padding layout elements" is not quite right I think, since they also have to be the right size. I think saying just "padding" is more accurate (and simpler).

I'll switch to using plain links instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13164#discussion_r1171971387

From jvernee at openjdk.org  Thu Apr 20 00:44:52 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Apr 2023 00:44:52 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v5]
In-Reply-To: <SqYeT2M-1hc_9YmZYxfROlds6BUkQaN5XUQ2pdW4WPM=.819d4d96-d98d-45dc-9442-680e314b2edd@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
 <DD0nvfK8sVvqOdwEKyIzOz1mRkSnRD63xf34EFDXvkE=.c73f7231-a80d-4d71-9586-b27e67f4a5f3@github.com>
 <SqYeT2M-1hc_9YmZYxfROlds6BUkQaN5XUQ2pdW4WPM=.819d4d96-d98d-45dc-9442-680e314b2edd@github.com>
Message-ID: <1DFbwL-K8cI8nCUoY2Au6vmsfav2pLESTwWF4Z31O-Y=.1f9d1507-5c70-4c59-ac8a-a9e0ddb8947b@github.com>

On Tue, 18 Apr 2023 22:32:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - fix TestIllegalLink
>>  - Merge branch 'PR_21' into RejectPacked
>>  - Merge branch 'PR_21' into RejectPacked
>>  - add javadoc + fixes for trailing padding
>>  - fix check for padding. Add check for trailing padding too
>>  - Reject packed structs and structs with extra padding
>>  - Check byte order of layouts passed to linker
>
> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 120:
> 
>> 118:     private void checkLayoutsRecursive(MemoryLayout layout) {
>> 119:         checkHasNaturalAlignment(layout);
>> 120:         checkByteOrder(layout);
> 
> for uniformity, shoudn't this check be inside an `if (layout instanceof ValueLayout) ...` ?

Yes, will do.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13164#discussion_r1171971742

From kvn at openjdk.org  Thu Apr 20 01:07:14 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 20 Apr 2023 01:07:14 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v9]
In-Reply-To: <qA5qq62c1XjS_LbDHjcK5KSmjCUC6hKMrX6pD3Ir64o=.64e994d2-daeb-4d80-ac19-f8e95c1df034@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <tSOY4bLeZKlucGnZHlKrhI0z9fUwSva5UyGrRAlp_4M=.ce362a15-9aa0-4f19-9f80-4a9ecb9794cd@github.com>
 <qA5qq62c1XjS_LbDHjcK5KSmjCUC6hKMrX6pD3Ir64o=.64e994d2-daeb-4d80-ac19-f8e95c1df034@github.com>
Message-ID: <yjpMLVHnzJh_0NNTjQzUtTqH9NnAL7mQkXqjyFoBVQw=.f5997cea-2468-47b2-9d2e-5f2468209910@github.com>

On Wed, 19 Apr 2023 16:00:18 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - added breadcrumb in AnnotationParser about considering JVMCI should new annotation element types be added
>>  - fixed javadoc comment
>
> Thanks for the reviews @turbanoff , @vnkozlov and @jddarcy.

@dougxc I see next 2 JVMCI tests failed when run with `-XX:TypeProfileLevel=222` on all platforms (our stress testing):

compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java
compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java

#  Internal Error (/workspace/open/src/hotspot/cpu/x86/macroAssembler_x86.cpp:829), pid=2430194, tid=2430218
#  fatal error: DEBUG MESSAGE: exact klass and actual klass differ

Current thread (0x00007f9ff8460480):  JavaThread "MainThread" [_thread_in_Java, id=2430218, stack(0x00007f9fe06b7000,0x00007f9fe07b8000)]

Stack: [0x00007f9fe06b7000,0x00007f9fe07b8000],  sp=0x00007f9fe07b44e0,  free space=1013k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x12b8d35]  MacroAssembler::debug64(char*, long, long*)+0x45  (macroAssembler_x86.cpp:829)
J 1935 c1 sun.reflect.annotation.AnnotationParser.parseAnnotation2(Ljava/nio/ByteBuffer;Ljdk/internal/reflect/ConstantPool;Ljava/lang/Class;Z[Ljava/lang/Class;)Ljava/lang/annotation/Annotation; java.base at 21-internal (275 bytes) @ 0x00007f9fe10d4cc6 [0x00007f9fe10d4740+0x0000000000000586]

[error occurred during error reporting (printing native stack (with source info))

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12810#issuecomment-1515565983

From jvernee at openjdk.org  Thu Apr 20 01:12:44 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Apr 2023 01:12:44 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v6]
In-Reply-To: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
Message-ID: <BS09rPZXEqgvig3E1sM6foHnEzF7c56HxyhuM-ufgdM=.4d2e50df-906f-4f20-a011-9a83313344c9@github.com>

> This patch adds checks in AbstractLinker to reject packed structs and structs with excess padding (e.g. unnamed bitfields), since both of those are currently not supported, and the ABI/spec seems too vague to base support on.

Jorn Vernee has updated the pull request incrementally with four additional commits since the last revision:

 - restrictions -> characteristics
 - polish pt. 2
 - polish wording
 - review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13164/files
  - new: https://git.openjdk.org/jdk/pull/13164/files/eaf0c9c6..62cd5ee4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13164&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13164&range=04-05

  Stats: 16 lines in 2 files changed: 1 ins; 2 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/13164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13164/head:pull/13164

PR: https://git.openjdk.org/jdk/pull/13164

From jvernee at openjdk.org  Thu Apr 20 01:12:46 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Apr 2023 01:12:46 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v5]
In-Reply-To: <0nZpSOymNiVVzyH-Bcp6FSX3l6ub5yhKk9S4KPrUU-M=.ebe95392-5b2b-403d-b4d9-231f218122af@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
 <DD0nvfK8sVvqOdwEKyIzOz1mRkSnRD63xf34EFDXvkE=.c73f7231-a80d-4d71-9586-b27e67f4a5f3@github.com>
 <L3i2q92HgKXJeg_mm5pak7g1Rb59_Vt0VtJGjcUQ5ds=.ffb1e341-f694-4bae-af3c-0bc5f08e750e@github.com>
 <9PSdCi4zwiha6GclDU4KfSCwSjZebxAlWLMinhrSF_A=.a2f8ef6a-031e-4a8b-9886-a8a3d3b9aec4@github.com>
 <0nZpSOymNiVVzyH-Bcp6FSX3l6ub5yhKk9S4KPrUU-M=.ebe95392-5b2b-403d-b4d9-231f218122af@github.com>
Message-ID: <FbMCOt6B3SLkFThTV9sVEAdSqnbQ4mXRbOVLbcvEEvg=.3c8e2d66-e034-467c-be66-7915bcafe976@github.com>

On Thu, 20 Apr 2023 00:40:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Also, isn't it the case that, for structs, we want the size of the layout to be a multiple of its alignment constraint?
>
> The third item in the list is for group size needing to be a multiple of the alignment constraint, the forth item refers to that, so I'll keep the ordered list.
> 
> WRT byte order: I think it's fine to just say "native byte order". Keep it simple. Or do you think there might be confusion about the meaning of "native"? (It looks like not even ByteOrder::nativeOrder explains that term: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/nio/ByteOrder.html#nativeOrder())
> 
> "padding layout elements" is not quite right I think, since they also have to be the right size. I think saying just "padding" is more accurate (and simpler).
> 
> I'll switch to using plain links instead.

Uploaded another version

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13164#discussion_r1171979964

From jpai at openjdk.org  Thu Apr 20 01:53:02 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Apr 2023 01:53:02 GMT
Subject: RFR: 8041676: remove the java.compiler system property [v2]
In-Reply-To: <7ZpYIwTMkZYOieMdMeRB-5Dey31mn-2XfztAqY8QCEw=.aa601d4d-2534-47e8-9357-dbfae625e692@github.com>
References: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>
 <7ZpYIwTMkZYOieMdMeRB-5Dey31mn-2XfztAqY8QCEw=.aa601d4d-2534-47e8-9357-dbfae625e692@github.com>
Message-ID: <RsUx5Uv9AwwsAu3i0-V9-VuieMcl9y5rG-GhB0NCLl4=.b2a98c10-7cd7-4727-a8b3-58e8153e4743@github.com>

On Fri, 14 Apr 2023 14:34:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes the `java.compiler` system property? This addresses https://bugs.openjdk.org/browse/JDK-8041676.
>> 
>> A CSR has been filed for this change and is available at https://bugs.openjdk.org/browse/JDK-8305998. The CSR has more details about this proposed change, but to summarize, the `java.compiler` system property wasn't used in any practical way. With the recent removal of `java.lang.Compiler` interface from the JDK, the presence of this system property wasn't of any practical importance.
>> 
>> The commit in this PR, removes its reference from the `System.getProperties()` documentation and also removes the specific implementation from hotspot where it treated the values `NONE` and empty string in the absence of `-Xdebug` in a specific manner and considered it to be an instruction to run the application in interpreter-only mode. `-Xint` option has been around for this purpose, so removal of this `java.compiler` system property support from hotspot implementation wouldn't remove any usable feature for the applications.
>> 
>> Additionally, the hotspot implementation now logs a warning message when it detects the presence of `java.compiler` system property when `java` is launched. This warning message will be removed after a few releases.
>> 
>> The current JDK source has reference to the `java.compiler` system property in numerous NetBeans project build files. The usage of this system property in such files isn't necessary. However, this PR doesn't intend to cleanup those references, since it isn't clear which of those NetBeans projects are still relevant. I think we can use a separate PR to do that cleanup.
>> 
>> tier1, tier2, tier3 testing has been done with these changes and those tests have passed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roger's suggestion - improve warning message

Thank you everyone for the reviews. The CSR has been approved, I'll go ahead and integrate this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13475#issuecomment-1515597263

From jpai at openjdk.org  Thu Apr 20 01:53:05 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Apr 2023 01:53:05 GMT
Subject: Integrated: 8041676: remove the java.compiler system property
In-Reply-To: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>
References: <vYh0OgP6gLCqiWvpSaRQ3l2eobiXZLnrBg6oRWvdUt0=.c24a4512-b644-4891-af6a-395a944e5d9d@github.com>
Message-ID: <v2D59VSEQDc8aGEGFc032vMlSldiLtu1aOV7fNV5Os8=.c0a84c46-2cea-4a35-9bbd-fcae89bfc104@github.com>

On Fri, 14 Apr 2023 12:19:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes the `java.compiler` system property? This addresses https://bugs.openjdk.org/browse/JDK-8041676.
> 
> A CSR has been filed for this change and is available at https://bugs.openjdk.org/browse/JDK-8305998. The CSR has more details about this proposed change, but to summarize, the `java.compiler` system property wasn't used in any practical way. With the recent removal of `java.lang.Compiler` interface from the JDK, the presence of this system property wasn't of any practical importance.
> 
> The commit in this PR, removes its reference from the `System.getProperties()` documentation and also removes the specific implementation from hotspot where it treated the values `NONE` and empty string in the absence of `-Xdebug` in a specific manner and considered it to be an instruction to run the application in interpreter-only mode. `-Xint` option has been around for this purpose, so removal of this `java.compiler` system property support from hotspot implementation wouldn't remove any usable feature for the applications.
> 
> Additionally, the hotspot implementation now logs a warning message when it detects the presence of `java.compiler` system property when `java` is launched. This warning message will be removed after a few releases.
> 
> The current JDK source has reference to the `java.compiler` system property in numerous NetBeans project build files. The usage of this system property in such files isn't necessary. However, this PR doesn't intend to cleanup those references, since it isn't clear which of those NetBeans projects are still relevant. I think we can use a separate PR to do that cleanup.
> 
> tier1, tier2, tier3 testing has been done with these changes and those tests have passed.

This pull request has now been integrated.

Changeset: b8f0a668
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8f0a668dd69b831d9f0e617ac3cb65830f69909
Stats:     35 lines in 3 files changed: 6 ins; 27 del; 2 mod

8041676: remove the java.compiler system property

Reviewed-by: dholmes, alanb, rriggs, iris

-------------

PR: https://git.openjdk.org/jdk/pull/13475

From dholmes at openjdk.org  Thu Apr 20 02:36:51 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Apr 2023 02:36:51 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v7]
In-Reply-To: <vHGXWJN2gsfsb9F53ya4eVlsVctH8yUnsvJd9YnkBHI=.4f5983b9-1793-444d-a99e-c0572dac6436@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <vHGXWJN2gsfsb9F53ya4eVlsVctH8yUnsvJd9YnkBHI=.4f5983b9-1793-444d-a99e-c0572dac6436@github.com>
Message-ID: <GjekBLa-Gdk31PYuoHL9fjZllVgyzQEfU8sn-YzLzXc=.e7b5e9e1-d09c-41ce-91d6-ad126236a763@github.com>

On Wed, 19 Apr 2023 19:55:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
>> 
>> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
>> 
>> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
>> 
>> Additional testing:
>>   - [x] New regression test
>>   - [x] New benchmark
>>   - [x] Linux x86_64 `tier1`
>>   - [x] Linux AArch64 `tier1`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust test times

Looking much cleaner/simpler. A couple more comments below. Thanks.

src/hotspot/os/windows/os_windows.cpp line 5263:

> 5261:   if (nanos_left > 0) {
> 5262:     millis++;
> 5263:   }

You could simplify this to:

if (nanos > millis * NANOSECS_PER_MILLISEC) {
  millis++;
}

src/hotspot/os/windows/park_windows.hpp line 53:

> 51:     void park () ;
> 52:     void unpark () ;
> 53:     int  park(jlong millis);

While you are here could you get rid of the spaces on park/unpark before the parentheses - thanks.

src/hotspot/share/runtime/javaThread.cpp line 1983:

> 1981: }
> 1982: 
> 1983: bool JavaThread::sleep(jlong millis) {

Perhaps a comment:

// Internal convenience function for millisecond resolution sleeps.

src/java.base/share/classes/java/lang/Thread.java line 1:

> 1: /*

Why doesn't `Thread.sleep(long millis)` simply call `Thread.sleep(millis, 0)` instead of duplicating most of the code?

-------------

PR Review: https://git.openjdk.org/jdk/pull/13225#pullrequestreview-1393107848
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1172011960
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1172013223
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1172014393
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1172017034

From duke at openjdk.org  Thu Apr 20 02:58:35 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Thu, 20 Apr 2023 02:58:35 GMT
Subject: RFR: 8306431: The documentation of File.listRoots should be
 modifid after JDK-8208077 [v2]
In-Reply-To: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
Message-ID: <_4xQ6WRQuJ6BB29pf255unrNYgeuPraXoTJ9XL6F3Yk=.6c2688c8-6875-466f-b59b-b7a6152ed026@github.com>

> I fixed File.listRoots description.
> * remove "the insertion or ejection of removable media"
> * change "available" to "existing"
> 
> Please review this change.

Nagata-Haruhito has updated the pull request incrementally with one additional commit since the last revision:

  8306431: The documentation of File.listRoots should be modifid after JDK-8208077

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13526/files
  - new: https://git.openjdk.org/jdk/pull/13526/files/4a90d283..ff1a5ce5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13526&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13526&range=00-01

  Stats: 12 lines in 1 file changed: 7 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13526.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13526/head:pull/13526

PR: https://git.openjdk.org/jdk/pull/13526

From duke at openjdk.org  Thu Apr 20 02:58:35 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Thu, 20 Apr 2023 02:58:35 GMT
Subject: RFR: 8306431: The documentation of File.listRoots should be
 modifid after JDK-8208077
In-Reply-To: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
Message-ID: <HFTS3v84fobzESW-Tj-0l-zRryue3hcDW36OxW-gasY=.8ad7e698-4b91-48a6-9306-f033e4a15b2d@github.com>

On Wed, 19 Apr 2023 07:34:30 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

> I fixed File.listRoots description.
> * remove "the insertion or ejection of removable media"
> * change "available" to "existing"
> 
> Please review this change.

Thanks for your comment.

I added @implNote and moved descriptions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13526#issuecomment-1515638732

From liach at openjdk.org  Thu Apr 20 03:02:45 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Apr 2023 03:02:45 GMT
Subject: RFR: 8304031: Classfile API cannot encode Primitive Class as Condy
 [v3]
In-Reply-To: <W69ydc4m58tfuh9AmeKspIBpNgGyj9nPVt7vaWwDxGs=.61155c4b-121e-440e-94a8-527292758a2b@github.com>
References: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com>
 <W69ydc4m58tfuh9AmeKspIBpNgGyj9nPVt7vaWwDxGs=.61155c4b-121e-440e-94a8-527292758a2b@github.com>
Message-ID: <dem4ItSlkG68UXKqLfeNvgSA0Lc_G3T5McffllVtj-Y=.a22c6973-62c2-4153-8028-76cd8a594a3e@github.com>

On Wed, 22 Mar 2023 22:52:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Without this patch, the Classfile API tries to encode PrimitiveClassDesc as CONSTANT_Class_info and error in `toInternalName`.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PrimitiveClassConstantTest check the other 2 API endpoints, move to junit

Keep-alive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12996#issuecomment-1515642233

From duke at openjdk.org  Thu Apr 20 04:16:13 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Thu, 20 Apr 2023 04:16:13 GMT
Subject: RFR: 8306431: The documentation of File.listRoots should be
 modifid after JDK-8208077 [v3]
In-Reply-To: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
Message-ID: <Ika8MWyIi6jGiwbn3b2c6pKQI2xWskdN9d-HeprcJKU=.88ae32bd-f559-4029-bb7e-8bcf0e941119@github.com>

> I fixed File.listRoots description.
> * remove "the insertion or ejection of removable media"
> * change "available" to "existing"
> 
> Please review this change.

Nagata-Haruhito has 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 two new commits since the last revision:

 - 8306431: The documentation of File.listRoots should be modifid after JDK-8208077
 - 8306431: File.listRoots method description should be re-examined

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13526/files
  - new: https://git.openjdk.org/jdk/pull/13526/files/ff1a5ce5..ef38a529

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13526&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13526&range=01-02

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13526.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13526/head:pull/13526

PR: https://git.openjdk.org/jdk/pull/13526

From smarks at openjdk.org  Thu Apr 20 04:19:57 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 20 Apr 2023 04:19:57 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <gFEW30ltuY4EnrgaKyeIKV3tCqUEhO7RjxoAbRx2Fg8=.dc998f69-9f51-4fde-a96c-514a38226ce8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
 <UQFv9mQcYOEgU_FMhks5VpQ5n52_eKtQ-SkVFWIJxfA=.f210d862-89a9-4da8-be7b-41edfa06fb39@github.com>
 <gFEW30ltuY4EnrgaKyeIKV3tCqUEhO7RjxoAbRx2Fg8=.dc998f69-9f51-4fde-a96c-514a38226ce8@github.com>
Message-ID: <3H2vsVn6_RvIXnR2Y_02RScaLHS9LLuGkWMFqLMwYsE=.8a56e190-3777-4060-ac6c-dd2834cb035d@github.com>

On Wed, 19 Apr 2023 10:29:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 409:
>> 
>>> 407:      * {@inheritDoc}
>>> 408:      */
>>> 409:     public E getFirst() {
>> 
>> Javadoc will automatically copy the specification from the overridden method, so the javadoc block is not necessary and can be replaced by an `@Override` to indicate inheritance.
>
>> Javadoc will automatically copy the specification from the overridden method, so the javadoc block is not necessary and can be replaced by an `@Override` to indicate inheritance.
> 
> I guess, this PR has converged enough for us to discuss some trivial stuff; so here it goes.
> 
> While you are right when saying that a doc comment consisting of a lone `{@inheritDoc}` is -- and I'm paraphrasing here -- the same as no comment at all, such a comment effectively is a copy of the overridden method _main description_, which is the part of a doc comment from its beginning to the first block tag or the end of the comment (if the comment has no block tags).
> 
> Parameters, return value and exception information -- all those are copied because they are mentioned in the method declaration. While this might give an impression that it's the result of `{@inheritDoc}`, it is important to understand that it isn't. For example, since runtime exceptions and errors aren't required to be mentioned in the `throws` clause of a method declaration, no `@throws` tags corresponding to such throwables will be copied automatically; the doc comment has to explicitly inherit those. In our case, either would do:
> 
>     /**
>      * @throws NoSuchElementException {@inheritDoc}
>      */
>     public E getFirst() {
> 
>     /**
>      * {@inheritDoc}
>      * @throws NoSuchElementException {@inheritDoc}
>      */
>     public E getFirst() {
> 
> Speaking of which: @stuart-marks, do you think you could add those everywhere?

@pavelrappo Arrrrggh.

> I guess, this PR has converged enough for us to discuss some trivial stuff; so here it goes.

All this "trivial" stuff is generating a lot of work! :-) Well, no big deal, Joe D still has more CSR comments coming.

I didn't know about the need to specify `@throws` in order to generate the throws-clauses in the docs. Ah, well, turns out it wasn't THAT bad to run through the hierarchy and check all the inherited methods. Done.

As an aside, I note that some methods such as ArrayList.addFirst/addLast had this javadoc:

    /**
     * @inheritDoc
     */

It didn't appear at all in the javadoc output, I guess because of `--override-methods=summary`. Not surprising in isolation, but it seemed strange because the getX and removeX methods were in the detail section but the addX methods seemed "missing". Is there a way to inherit the doc from a superclass but force a particular method to have its details included? It's kind of moot because these are also missing a `@since` tag, and adding that did cause the method detail to be included. Seems like the summary/detail stuff still needs some things to be worked out.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1172062252

From smarks at openjdk.org  Thu Apr 20 04:19:55 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 20 Apr 2023 04:19:55 GMT
Subject: RFR: 8266571: Sequenced Collections [v8]
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: <xhWK9e-orFi_yRPH1xyUWf2ye5tP1BrysvQrLhqCLbY=.c316918e-793f-4bdc-bee6-c5267efa6c5c@github.com>

> PR for Sequenced Collections implementation.

Stuart Marks has updated the pull request incrementally with four additional commits since the last revision:

 - Add missing @throws and @since tags.
 - Convert code samples to snippets.
 - Various editorial changes.
 - Fix up toArray(T[]) on reverse-ordered views.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7387/files
  - new: https://git.openjdk.org/jdk/pull/7387/files/364c2d00..79747247

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=06-07

  Stats: 121 lines in 14 files changed: 96 ins; 5 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/7387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/7387/head:pull/7387

PR: https://git.openjdk.org/jdk/pull/7387

From smarks at openjdk.org  Thu Apr 20 04:31:05 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 20 Apr 2023 04:31:05 GMT
Subject: RFR: 8266571: Sequenced Collections [v8]
In-Reply-To: <bjHr9kQ6PfiSzt5IqgFWisQqzk_Jiawi5jGCDOKgeXI=.44293975-edcb-42de-99dd-9b7590b86914@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <bjHr9kQ6PfiSzt5IqgFWisQqzk_Jiawi5jGCDOKgeXI=.44293975-edcb-42de-99dd-9b7590b86914@github.com>
Message-ID: <Uedu48SqcMS8aIIrKErU4lzUyhvsn_DfWAh8qBRO1Jk=.429e2942-cd49-4d73-b8fc-c21c4350873d@github.com>

On Fri, 24 Mar 2023 22:01:11 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Add missing @throws and @since tags.
>>  - Convert code samples to snippets.
>>  - Various editorial changes.
>>  - Fix up toArray(T[]) on reverse-ordered views.
>
> src/java.base/share/classes/java/util/ReverseOrderDequeView.java line 167:
> 
>> 165:     public <T> T[] toArray(T[] a) {
>> 166:         // TODO can probably optimize this
>> 167:         return toArray(i -> (T[]) java.lang.reflect.Array.newInstance(a.getClass().getComponentType(), i));
> 
> Hm... Does it follow the spec when the size of `a` is greater than the size of this collection? In this case, we should return the supplied array filling it partially and setting the next element to null. Here, we will always create a new array, which seems to violate the spec.

I've rewritten the `toArray(T[] a)` implementation here and in other places.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1172067817

From smarks at openjdk.org  Thu Apr 20 04:43:05 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 20 Apr 2023 04:43:05 GMT
Subject: RFR: 8266571: Sequenced Collections [v8]
In-Reply-To: <bjHr9kQ6PfiSzt5IqgFWisQqzk_Jiawi5jGCDOKgeXI=.44293975-edcb-42de-99dd-9b7590b86914@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <bjHr9kQ6PfiSzt5IqgFWisQqzk_Jiawi5jGCDOKgeXI=.44293975-edcb-42de-99dd-9b7590b86914@github.com>
Message-ID: <tVo2dsMfKHU1vS-MIs5cPuN_G5NP4rVqghldLzzjmXs=.1e84002b-81d3-4003-9e99-d49776154867@github.com>

On Fri, 24 Mar 2023 22:13:29 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Add missing @throws and @since tags.
>>  - Convert code samples to snippets.
>>  - Various editorial changes.
>>  - Fix up toArray(T[]) on reverse-ordered views.
>
> src/java.base/share/classes/java/util/ReverseOrderSortedMapView.java line 99:
> 
>> 97: 
>> 98:     public Set<K> keySet() {
>> 99:         return new AbstractSet<>() {
> 
> At very least, please delegate `contains`, `remove`, and `clear`, to avoid O(N) complexity there. Same for `values()` and `entrySet()`

OK. I've delegated all of these through the base map's views instead of taking shortcuts (e.g., the keyset's clear() is `base.keySet().clear()` instead of `base.clear()`) in order to preserve any special semantics the underlying map might have for these methods on its views.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1172072870

From smarks at openjdk.org  Thu Apr 20 04:55:05 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 20 Apr 2023 04:55:05 GMT
Subject: RFR: 8266571: Sequenced Collections [v8]
In-Reply-To: <bjHr9kQ6PfiSzt5IqgFWisQqzk_Jiawi5jGCDOKgeXI=.44293975-edcb-42de-99dd-9b7590b86914@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <bjHr9kQ6PfiSzt5IqgFWisQqzk_Jiawi5jGCDOKgeXI=.44293975-edcb-42de-99dd-9b7590b86914@github.com>
Message-ID: <GqdmUwMN3sKG7TMrZFp_0qYc2jf-HEW-sXNJfioyYLA=.da6dbb8f-d69d-419e-8e24-47557115cce5@github.com>

On Fri, 24 Mar 2023 22:16:54 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Add missing @throws and @since tags.
>>  - Convert code samples to snippets.
>>  - Various editorial changes.
>>  - Fix up toArray(T[]) on reverse-ordered views.
>
> src/java.base/share/classes/java/util/ReverseOrderSortedMapView.java line 185:
> 
>> 183: 
>> 184:     static <K, V> Iterator<K> descendingKeyIterator(SortedMap<K, V> map) {
>> 185:         return new Iterator<>() {
> 
> Probably create `descendingEntryIterator` as base, and derive `descendingKeyIterator` and `descendingValueIterator`? This way, `map.get()` inside `descendingValueIterator` and `descendingEntryIterator` could be avoided.

Not sure this will help. The fundamentals of advancing the descending iterator for SortedMap involve getting the last key of the current view (via the `lastKey` method) and then excluding it from the view with `headMap(lastKey)`. This allows iterating the keys in reverse without any `get` calls (though of course the inclusive/exclusive searching for the last key does involve probing the map). To build a descending entrySet iterator, one would have to do all of the above and then add a `get` call to obtain the value to construct the Entry. This adds a `get` call here but then saves a `get` call elsewhere. Seems like a wash to me.

It's kind of a shame because `TreeMap` internally has `getLastEntry`. Its `lastKey` method calls it and then throws away the Entry. :-( But this doesn't matter, since `TreeMap` is a `NavigableMap` and its reverse iteration and views are all based on `descendingMap`, so the `ReverseOrderSortedMapView` stuff isn't used at all.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1172078247

From jlu at openjdk.org  Thu Apr 20 06:14:46 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 06:14:46 GMT
Subject: RFR: 8306031: Update IANA Language Subtag Registry to Version
 2023-04-13 [v3]
In-Reply-To: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
Message-ID: <tB6qWExQrl8J2RXmQH8i0s7R-pgJI5SQNZWt_Ot4Mg0=.64338596-9982-4826-b0ca-f076c9010c96@github.com>

> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
> 
> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
> 
> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
> 
> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
> 
> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
> 
> 
> ...
> singleEquivMap.put("ar-ajp", "ajp");
> singleEquivMap.put("ajp", "ar-ajp");
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
> ...
> 
> 
> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
> 
> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
> 
> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
> 
> To address this, the build process must be adjusted so that the equivalencies are built as 
> 
> 
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
> ...
> 
> 
> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Improve stream processing and hash map creation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13501/files
  - new: https://git.openjdk.org/jdk/pull/13501/files/e5d332ee..4a75417f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13501&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13501&range=01-02

  Stats: 15 lines in 1 file changed: 2 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13501.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13501/head:pull/13501

PR: https://git.openjdk.org/jdk/pull/13501

From jlu at openjdk.org  Thu Apr 20 06:16:47 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 06:16:47 GMT
Subject: RFR: 8306031: Update IANA Language Subtag Registry to Version
 2023-04-13 [v2]
In-Reply-To: <FH2rUqpAjgRhVlqZE0VrdSc0H21Qz0b2-BJh0VyyC4o=.ac80c0db-66c5-42d8-847c-193cf6cce217@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
 <rIjFDs6KOwnkWJTLtfvHYb08re-2STSCQWrSyiTdTuk=.c221d2da-11d8-4ff2-b9ec-0df188092fdc@github.com>
 <FH2rUqpAjgRhVlqZE0VrdSc0H21Qz0b2-BJh0VyyC4o=.ac80c0db-66c5-42d8-847c-193cf6cce217@github.com>
Message-ID: <u_S5pgXCM8b2DWTOJRRr96D8ZA8kWflLVsQVGP2YkOc=.c14b7e45-cb00-4b00-9f60-2f3dff450e8c@github.com>

On Wed, 19 Apr 2023 22:46:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright
>
> make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 144:
> 
>> 142:                 boolean foundInOther = false;
>> 143:                 final String finalPref = ","+preferred;
>> 144:                 final String inbtwnPref = ","+preferred+",";
> 
> This could utilize regex?

Much better that way, fixed

> make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 146:
> 
>> 144:                 final String inbtwnPref = ","+preferred+",";
>> 145:                 // Check if current pref exists inside a value for another pref
>> 146:                 List<StringBuilder> doublePrefs = initialLanguageMap.entrySet()
> 
> `values()` fits here

fixed

> make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 150:
> 
>> 148:                                 e.getValue().toString().contains(inbtwnPref)))
>> 149:                         .map(Map.Entry::getValue)
>> 150:                         .collect(Collectors.toList());
> 
> Can replace `collect()` with `toList()`

Changed this, as well as the other existing occurrence

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1172122929
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1172123278
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1172123190

From jlu at openjdk.org  Thu Apr 20 06:36:47 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 06:36:47 GMT
Subject: RFR: 8306031: Update IANA Language Subtag Registry to Version
 2023-04-13 [v4]
In-Reply-To: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
Message-ID: <4-zyZv_-bDaqfjsOI6cKOq-GVRC-RTrBeDk2xDEkZzg=.8d0e7bfc-c347-4b88-b4fc-7049c958eab3@github.com>

> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
> 
> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
> 
> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
> 
> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
> 
> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
> 
> 
> ...
> singleEquivMap.put("ar-ajp", "ajp");
> singleEquivMap.put("ajp", "ar-ajp");
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
> ...
> 
> 
> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
> 
> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
> 
> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
> 
> To address this, the build process must be adjusted so that the equivalencies are built as 
> 
> 
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
> ...
> 
> 
> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Hash map should be initialized with numMappings

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13501/files
  - new: https://git.openjdk.org/jdk/pull/13501/files/4a75417f..7d3021a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13501&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13501&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13501.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13501/head:pull/13501

PR: https://git.openjdk.org/jdk/pull/13501

From jlu at openjdk.org  Thu Apr 20 06:36:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 06:36:51 GMT
Subject: RFR: 8306031: Update IANA Language Subtag Registry to Version
 2023-04-13 [v2]
In-Reply-To: <FH2rUqpAjgRhVlqZE0VrdSc0H21Qz0b2-BJh0VyyC4o=.ac80c0db-66c5-42d8-847c-193cf6cce217@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
 <rIjFDs6KOwnkWJTLtfvHYb08re-2STSCQWrSyiTdTuk=.c221d2da-11d8-4ff2-b9ec-0df188092fdc@github.com>
 <FH2rUqpAjgRhVlqZE0VrdSc0H21Qz0b2-BJh0VyyC4o=.ac80c0db-66c5-42d8-847c-193cf6cce217@github.com>
Message-ID: <HtmWoo5fWH8To4Cc4AulVyOtx0Gi_XKQm3didOTIO7k=.3cd5b8c3-719c-47a2-a4ee-09dfa4d61943@github.com>

On Wed, 19 Apr 2023 22:51:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright
>
> make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2012, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Cannot comment on unmodified lines, but instead of calculating the initial load itself, `HashMap.newHashMap()` can be used for initializing maps.

Fixed, so they are created with numMappings and not initialLoad

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1172135340

From jlu at openjdk.org  Thu Apr 20 06:48:49 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 06:48:49 GMT
Subject: RFR: 8305207: Calendar.aggregateStamp(int,
 int) return value can be simplified
Message-ID: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>

Small cleanup / tweak spotted in Calendar to improve readability.

-------------

Commit messages:
 - Replace ternary with max()

Changes: https://git.openjdk.org/jdk/pull/13554/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13554&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305207
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13554.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13554/head:pull/13554

PR: https://git.openjdk.org/jdk/pull/13554

From shade at openjdk.org  Thu Apr 20 08:18:08 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Apr 2023 08:18:08 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v7]
In-Reply-To: <GjekBLa-Gdk31PYuoHL9fjZllVgyzQEfU8sn-YzLzXc=.e7b5e9e1-d09c-41ce-91d6-ad126236a763@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <vHGXWJN2gsfsb9F53ya4eVlsVctH8yUnsvJd9YnkBHI=.4f5983b9-1793-444d-a99e-c0572dac6436@github.com>
 <GjekBLa-Gdk31PYuoHL9fjZllVgyzQEfU8sn-YzLzXc=.e7b5e9e1-d09c-41ce-91d6-ad126236a763@github.com>
Message-ID: <fan5ziVJc7mtPzcnywX4cW5KBTFzx4KKyqiTwZjy_8c=.5e7b639a-2698-48e6-8468-f7a001ea6fc4@github.com>

On Thu, 20 Apr 2023 02:14:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust test times
>
> src/hotspot/os/windows/os_windows.cpp line 5263:
> 
>> 5261:   if (nanos_left > 0) {
>> 5262:     millis++;
>> 5263:   }
> 
> You could simplify this to:
> 
> if (nanos > millis * NANOSECS_PER_MILLISEC) {
>   millis++;
> }

True, simplified.

> src/hotspot/os/windows/park_windows.hpp line 53:
> 
>> 51:     void park () ;
>> 52:     void unpark () ;
>> 53:     int  park(jlong millis);
> 
> While you are here could you get rid of the spaces on park/unpark before the parentheses - thanks.

Right, did so.

> src/hotspot/share/runtime/javaThread.cpp line 1983:
> 
>> 1981: }
>> 1982: 
>> 1983: bool JavaThread::sleep(jlong millis) {
> 
> Perhaps a comment:
> 
> // Internal convenience function for millisecond resolution sleeps.

Added!

> src/java.base/share/classes/java/lang/Thread.java line 1:
> 
>> 1: /*
> 
> Why doesn't `Thread.sleep(long millis)` simply call `Thread.sleep(millis, 0)` instead of duplicating most of the code?

That would change the stack depth, for which some tests are sensitive. https://github.com/openjdk/jdk/pull/13225#issuecomment-1514461529. I think merging `sleep` implementations is something to do in a targeted cleanup, which would handle those test updates too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1172237713
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1172238273
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1172237000
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1172236374

From shade at openjdk.org  Thu Apr 20 08:24:10 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Apr 2023 08:24:10 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v8]
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <fKfaeKpxY9xC0nwxwE2g9E23SusxzT2B7nnzknZ7cp0=.2991397d-21a1-4f9b-954b-8933a6619103@github.com>

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  More review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13225/files
  - new: https://git.openjdk.org/jdk/pull/13225/files/8617b5ce..6a2bcf0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=06-07

  Stats: 5 lines in 3 files changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13225/head:pull/13225

PR: https://git.openjdk.org/jdk/pull/13225

From asotona at openjdk.org  Thu Apr 20 08:28:00 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 20 Apr 2023 08:28:00 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v3]
In-Reply-To: <VkimOrcXslKpl6DeJGdC16MCpM7H-5lCJBZH3tDcS5c=.22ec33d2-285d-4c0c-bd8d-aacbe86405a5@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <NDZsJbnOay2IPYbjJ-E_asohiAS8eJpqd0mHbh1EmsE=.7d30affe-510c-476e-8def-042ced74b017@github.com>
 <VkimOrcXslKpl6DeJGdC16MCpM7H-5lCJBZH3tDcS5c=.22ec33d2-285d-4c0c-bd8d-aacbe86405a5@github.com>
Message-ID: <17g0Sr-olv2KDrNF4ZSHOtzmxiRDOPi6QYfazhyyBBs=.51559233-5e1f-4199-8082-e936a3031f6b@github.com>

On Wed, 19 Apr 2023 17:08:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed ClassPrinterImpl
>
> src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 86:
> 
>> 84:     }
>> 85: 
>> 86:     public void setMajorVersion(int majorVersion) {
> 
> We should ensure the version is not changed once writing has already happened, and the constant pool builder should have access to the major version as well to prevent writing of invalid entries (like condy before java 11)

The class version is set into the BufWriterImpl at the last stage and user cannot affect it later.

For the invalid entries I would like to see a use case where it may happen unintentionally. Otherwise the Classfile API is not a spec-enforcing library. The library should guide to create valid classfile with minimal effort (using defaults), however it should also allow to construct whatever classfile, if it is user intention.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13478#discussion_r1172251297

From asotona at openjdk.org  Thu Apr 20 08:34:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 20 Apr 2023 08:34:48 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v4]
In-Reply-To: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
Message-ID: <58I0jbvWcktU4jPRQN0xnxalsDBuQaOi7UE-plU3qdU=.e362dd18-599b-4d2f-99d8-aa78712f3cfa@github.com>

> Classfile API didn't handle transformations of class files version 50 and below correctly. 
> 
> Proposed fix have two parts: 
> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
> 2. StackMapTable attribute is not generated for class file versions below 50.
> 
> StackMapsTest is also extended to test this patch.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/classfile/Opcode.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13478/files
  - new: https://git.openjdk.org/jdk/pull/13478/files/473fc8e8..cc2c1059

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13478/head:pull/13478

PR: https://git.openjdk.org/jdk/pull/13478

From asotona at openjdk.org  Thu Apr 20 09:04:03 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 20 Apr 2023 09:04:03 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v5]
In-Reply-To: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
Message-ID: <RFa-CrpskZKQYMzBsxoSDsOk1kA6MGjBC9y3nT12GEE=.740bc6f7-4413-4336-a6ba-68b2ceb3297d@github.com>

> Classfile API didn't handle transformations of class files version 50 and below correctly. 
> 
> Proposed fix have two parts: 
> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
> 2. StackMapTable attribute is not generated for class file versions below 50.
> 
> StackMapsTest is also extended to test this patch.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Making some BufWriter fields final

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13478/files
  - new: https://git.openjdk.org/jdk/pull/13478/files/cc2c1059..dfea3cde

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=03-04

  Stats: 20 lines in 2 files changed: 6 ins; 10 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13478/head:pull/13478

PR: https://git.openjdk.org/jdk/pull/13478

From nlisker at openjdk.org  Thu Apr 20 09:06:12 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 20 Apr 2023 09:06:12 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <aE6pPGD9JA2INISEE2aADCdIPZLeO1xm4VeIO2bPnYo=.ebb83366-e9b4-4d22-8c57-a92cd8cee43f@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
 <aE6pPGD9JA2INISEE2aADCdIPZLeO1xm4VeIO2bPnYo=.ebb83366-e9b4-4d22-8c57-a92cd8cee43f@github.com>
Message-ID: <-K52vxZ98LppXXNqvsRlOPXrI9xnWv1CLQClCIiPEEc=.959dbc0a-291f-46f0-8d7a-d7ce28147dc0@github.com>

On Wed, 19 Apr 2023 14:41:59 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove unnecessary 'final' from a couple places.
>>  - Clarify ordering of Collection.addAll and Map.putAll; add links to
>>    encounter order.
>>  - Make constructors private for several reverse-ordered views.
>
> I reviewed some of the public documentation and left some comments and thoughts. As a general remark, the documentation could use [Code Snippets](https://openjdk.org/jeps/413) to avoid the `<pre>{@code` pattern.

> @nlisker OK I've accepted some of the editorial comments, converted code samples to snippets, etc. However I didn't add markup around every keyword as `{@code List}` when it's used as an ordinary noun. That's the prevailing style in this area, at least mine (though there are probably inconsistencies across the JDK). I find that excessive markup clutters both the marked-up javadoc and also the visually rendered output.

That's fine, I wasn't sure what style you follow. The comments are more suggestions or thought than requests. I'll finish the other half of the docs review so the CSR can be update.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1515972772

From prappo at openjdk.org  Thu Apr 20 09:06:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 20 Apr 2023 09:06:13 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <3H2vsVn6_RvIXnR2Y_02RScaLHS9LLuGkWMFqLMwYsE=.8a56e190-3777-4060-ac6c-dd2834cb035d@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
 <UQFv9mQcYOEgU_FMhks5VpQ5n52_eKtQ-SkVFWIJxfA=.f210d862-89a9-4da8-be7b-41edfa06fb39@github.com>
 <gFEW30ltuY4EnrgaKyeIKV3tCqUEhO7RjxoAbRx2Fg8=.dc998f69-9f51-4fde-a96c-514a38226ce8@github.com>
 <3H2vsVn6_RvIXnR2Y_02RScaLHS9LLuGkWMFqLMwYsE=.8a56e190-3777-4060-ac6c-dd2834cb035d@github.com>
Message-ID: <XRv7PT9QdKJYYkNdzEbHmTAl317iVYZm2VUH7-fIqJk=.e5c5efb8-22fb-405c-893c-19d2641adc72@github.com>

On Thu, 20 Apr 2023 04:13:57 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> I didn't know about the need to specify `@throws` in order to generate the throws-clauses in the docs. 

You need to explicitly inherit `@throws` only for exceptions that aren't mentioned in the `throws` clause.

> As an aside, I note that some methods such as ArrayList.addFirst/addLast had this javadoc:
> 
> ```
> /**
>  * @inheritDoc
>  */
> ```
> 
> It didn't appear at all in the javadoc output, I guess because of `--override-methods=summary`.

Correct: it shouldn't have appeared in "Method Details" because of that option. But if it didn't appear at all (i.e. not even in the "Method Summary / Methods declared in ..." table at the top of the page), it's a bug.

> Is there a way to inherit the doc from a superclass but force a particular method to have its details included? It's kind of moot because these are also missing a `@since` tag, and adding that did cause the method detail to be included.

Other than to add to the inherited documentation? Not that I know of. Yes, adding a `@since` tag will cause the method detail to appear.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1172297190

From dnsimon at openjdk.org  Thu Apr 20 09:12:02 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 20 Apr 2023 09:12:02 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v9]
In-Reply-To: <tSOY4bLeZKlucGnZHlKrhI0z9fUwSva5UyGrRAlp_4M=.ce362a15-9aa0-4f19-9f80-4a9ecb9794cd@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <tSOY4bLeZKlucGnZHlKrhI0z9fUwSva5UyGrRAlp_4M=.ce362a15-9aa0-4f19-9f80-4a9ecb9794cd@github.com>
Message-ID: <lc_ucsidKr-ChuTyisHJnAFNk4tLpWRRXOQGWiCYm48=.c1eecd88-1d4c-404d-a380-3215186e28e7@github.com>

On Tue, 18 Apr 2023 07:27:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
>> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`.
>> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>>  
>> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
>> 
>>     ResolvedJavaMethod method = ...;
>>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>>     return switch (a.kind()) {
>>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The same code using the new API:
>> 
>> 
>>     ResolvedJavaMethod method = ...;
>>     ResolvedJavaType explodeLoopType = ...;
>>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>>     return switch (a.getEnum("kind").getName()) {
>>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.
>
> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - added breadcrumb in AnnotationParser about considering JVMCI should new annotation element types be added
>  - fixed javadoc comment

I can reproduce this locally as well but really don't know where to start in terms of debugging this. Can you please provide hints as to what may cause this failure C1 compiled code?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12810#issuecomment-1515986311

From shade at openjdk.org  Thu Apr 20 09:29:43 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Apr 2023 09:29:43 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v9]
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <ZK7HhQs6pOSLV0j7cP4ywj0Ng-9atw2KFa_tU2zbVBs=.df722eba-d680-48e4-9a1f-313d4beedaf7@github.com>

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Handle overflows

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13225/files
  - new: https://git.openjdk.org/jdk/pull/13225/files/6a2bcf0b..a759556d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=07-08

  Stats: 16 lines in 2 files changed: 14 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13225/head:pull/13225

PR: https://git.openjdk.org/jdk/pull/13225

From mcimadamore at openjdk.org  Thu Apr 20 09:30:52 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Apr 2023 09:30:52 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v6]
In-Reply-To: <BS09rPZXEqgvig3E1sM6foHnEzF7c56HxyhuM-ufgdM=.4d2e50df-906f-4f20-a011-9a83313344c9@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
 <BS09rPZXEqgvig3E1sM6foHnEzF7c56HxyhuM-ufgdM=.4d2e50df-906f-4f20-a011-9a83313344c9@github.com>
Message-ID: <A0Yb6AXcRLSq69LEQLmgdimBzBBa-wYF_TP0N76-VVM=.5780da13-a414-4f2b-a754-7f3f9f2dfc73@github.com>

On Thu, 20 Apr 2023 01:12:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch adds checks in AbstractLinker to reject packed structs and structs with excess padding (e.g. unnamed bitfields), since both of those are currently not supported, and the ABI/spec seems too vague to base support on.
>
> Jorn Vernee has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - restrictions -> characteristics
>  - polish pt. 2
>  - polish wording
>  - review comments

Looks good.

One (optional, for future?) thing that came to mind, is that if we wanted to speed up the check we could compute whether a layout is canonical or not on construction (since for structs we already have to go through all the elements and check alignment).

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13164#pullrequestreview-1393584926

From shade at openjdk.org  Thu Apr 20 09:35:48 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Apr 2023 09:35:48 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v9]
In-Reply-To: <ZK7HhQs6pOSLV0j7cP4ywj0Ng-9atw2KFa_tU2zbVBs=.df722eba-d680-48e4-9a1f-313d4beedaf7@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <ZK7HhQs6pOSLV0j7cP4ywj0Ng-9atw2KFa_tU2zbVBs=.df722eba-d680-48e4-9a1f-313d4beedaf7@github.com>
Message-ID: <0gqzpwJ7mn92hLaHvQVq4YgrslTWWdICKYzpWo8BgOw=.abfafe78-363e-4de8-a79c-387b5de5f524@github.com>

On Thu, 20 Apr 2023 09:29:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
>> 
>> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
>> 
>> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
>> 
>> Additional testing:
>>   - [x] New regression test
>>   - [x] New benchmark
>>   - [x] Linux x86_64 `tier1`
>>   - [x] Linux AArch64 `tier1`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handle overflows

While writing the CSR, I realized we still need to keep the `MAX_SECS` cap at POSIX path for individual sleeps, if only to care for downstream Solaris ports that are still maintained. We also would like to care about accidentally calling `JavaThread::sleep(jlong millis)` with e.g. `max_jlong`. New commit should handle both.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1516018689

From mchhipa at openjdk.org  Thu Apr 20 10:06:33 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 20 Apr 2023 10:06:33 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v3]
In-Reply-To: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
Message-ID: <zpnk-wC0R3qZwiWhd1umWZZZQre0DhXI_52DEGQKclQ=.71067494-6bcd-431c-8b90-ab72c0b42378@github.com>

> Test is updated to create the binary files during test execution.

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Implemented the review comment.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13537/files
  - new: https://git.openjdk.org/jdk/pull/13537/files/209152ad..45567f28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13537/head:pull/13537

PR: https://git.openjdk.org/jdk/pull/13537

From shade at openjdk.org  Thu Apr 20 12:01:54 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Apr 2023 12:01:54 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions
In-Reply-To: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
Message-ID: <689URy0mqJMJ_339lBAJeTbAJgh1rzPs9ZGBBk2CK34=.c1f164ef-fc58-47ba-bd60-f95c449f31f8@github.com>

On Wed, 19 Apr 2023 16:47:33 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
> 
> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
> 
> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
> 
> Returns:
> the non-negative number of array elements when deserializing an array of the class, otherwise -1
> 
> but currently returns a negative value if the array length is negative.

Some suggestions

src/java.base/share/classes/java/io/ObjectInputStream.java line 2142:

> 2140:         int len = bin.readInt();
> 2141:         if (len < 0) {
> 2142:             throw new InvalidClassException(desc.getName(), "Array length < 0 (" + len + ")");

Suggestion:

            throw new InvalidClassException(desc.getName(), "Array length (" + len + ") is negative");

test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 43:

> 41: public class NegativeArraySizeTest {
> 42: 
> 43:     private static byte[] _buildPayload() throws IOException {

`_buildPayload` -> `buildPayload`.

test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 44:

> 42: 
> 43:     private static byte[] _buildPayload() throws IOException {
> 44:         String[] simpleArray = new String[1];

Inline this variable?

test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 55:

> 53:         // Find the right location to modify, looking for the first instance of TC_ENDBLOCKDATA
> 54:         int firstPos = 0;
> 55:         for (int i=0; i<serializedData.length-1; i++) {

Suggestion:

        for (int i = 0; i < serializedData.length - 1; i++) {

test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 95:

> 93:     public static void main(String[] args) throws Exception {
> 94:         try {
> 95:             test_simpleArray_negative();

Inline these `test_*` methods. Move the `CustomFilter` as test class nested.

test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 99:

> 97:             throw new Exception("ObjectInputStream::readObject() shouldn't throw a NegativeArraySizeException", nase);
> 98:         } catch (ObjectStreamException ose) {
> 99:             // OK, because a NegativeArraySizeException should be converted into a ObjectStreamException

Check the message from `ose` here?

test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 109:

> 107:                 throw new Exception("ObjectInputStream::readObject() should catch NegativeArraySizeExceptions before filtering", ice);
> 108:             }
> 109:             // OK, because a NegativeArraySizeException should be converted into a ObjectStreamException *before* filtering

Sounds like we should really test for ICE with "Array length ... is negative" here. This would cover the case when filter rejected the class before that exception is thrown.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13540#pullrequestreview-1393736956
PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1172423915
PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1172424270
PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1172424783
PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1172425065
PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1172465910
PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1172467222
PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1172482373

From nlisker at openjdk.org  Thu Apr 20 12:04:13 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 20 Apr 2023 12:04:13 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <E_2N7pkTJzQY15jp82QSdCtpUZAeJNLZ03Q2XdIZK8w=.96f2142f-2d96-4b20-8ed8-48ecea7654e8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
 <aE6pPGD9JA2INISEE2aADCdIPZLeO1xm4VeIO2bPnYo=.ebb83366-e9b4-4d22-8c57-a92cd8cee43f@github.com>
 <E_2N7pkTJzQY15jp82QSdCtpUZAeJNLZ03Q2XdIZK8w=.96f2142f-2d96-4b20-8ed8-48ecea7654e8@github.com>
Message-ID: <T9CPP1X8Wp79jD9DRabwQu6_pMJ3p1Iu2lVWyN6e4gc=.ea900e20-61b0-4a34-8729-114ae43c1a7d@github.com>

On Wed, 19 Apr 2023 18:22:28 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/SequencedMap.java line 110:
>> 
>>> 108:  * {@code Entry} thus obtained will update a mapping in the underlying map, or whether
>>> 109:  * it will throw an exception, or whether changes to the underlying map are visible in
>>> 110:  * that {@code Entry}.
>> 
>> These 3 paragraphs all talk about `Entry`s' connection to the map. I think that they can be reconciled by explicitly noting each way to get an entry and the conditions that apply on it. In broad strokes:
>> 
>>> `{@link Map.Entry}` instances can be obtained in several ways.
>>> By iterating the `{@link #entrySet}` view... These entries maintain a connection...
>>> By calling the `{@link #firstEntry}`... methods. These entries represent snapshots of...
>>> By other means, such as from methods of views of the map (`sequencedMap.sequencedEntrySet().getFirst();`). These entries entries might or might not be connected...
>
> Not sure what you're suggesting here. There are indeed different ways to obtain entries, but they can't be reconciled because the spec imposes different requirements (or explicitly leaves things unspecified) on entries obtained by different means.

What I'm suggesting is this: these 3 paragraphs read like a mini-section about entries. I think that if a sentence is added at their beginning, like 

> `{@link Map.Entry}` instances can be obtained in several/the following ways."

and/or if the language used in them was more consistent, like

> Entries obtained by <method of obtaining> are <requirements>

then it will make this part of the docs easier to follow. More concretely, if the first paragraph uses the language

> The `{@link Map.Entry}` instances obtained by iterating the `{@link #entrySet}` view...

then the second could use

> The `{@code Map.Entry}` instances obtained by the methods `{@link #firstEntry}`...

and the third

> The `{@code Entry}` instances obtained by other means...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1172484646

From dholmes at openjdk.org  Thu Apr 20 12:12:51 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Apr 2023 12:12:51 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v9]
In-Reply-To: <ZK7HhQs6pOSLV0j7cP4ywj0Ng-9atw2KFa_tU2zbVBs=.df722eba-d680-48e4-9a1f-313d4beedaf7@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <ZK7HhQs6pOSLV0j7cP4ywj0Ng-9atw2KFa_tU2zbVBs=.df722eba-d680-48e4-9a1f-313d4beedaf7@github.com>
Message-ID: <kfsajxtDhc1KxOB5pFr8y3VO70BTdsfk8Wn_lbx4gMs=.6c127426-0a67-415c-bbf2-0dea302061e7@github.com>

On Thu, 20 Apr 2023 09:29:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
>> 
>> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
>> 
>> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
>> 
>> Additional testing:
>>   - [x] New regression test
>>   - [x] New benchmark
>>   - [x] Linux x86_64 `tier1`
>>   - [x] Linux AArch64 `tier1`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handle overflows

src/hotspot/os/posix/os_posix.cpp line 1342:

> 1340: }
> 1341: 
> 1342: static jlong nanos_to_nanos_bounded(jlong nanos) {

I don't think we actually need this for nanos. There is no overflow potential and the MAX_SECS limit will be handled later.

src/hotspot/share/runtime/javaThread.cpp line 1987:

> 1985:   jlong nanos;
> 1986:   if (millis > max_jlong / NANOUNITS_PER_MILLIUNIT) {
> 1987:     // Conversion to nanos would overflow, saturate at max

Good catch! I had assumed `millis_to_nanos` handled this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1172488236
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1172490688

From shade at openjdk.org  Thu Apr 20 12:12:52 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Apr 2023 12:12:52 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v9]
In-Reply-To: <kfsajxtDhc1KxOB5pFr8y3VO70BTdsfk8Wn_lbx4gMs=.6c127426-0a67-415c-bbf2-0dea302061e7@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <ZK7HhQs6pOSLV0j7cP4ywj0Ng-9atw2KFa_tU2zbVBs=.df722eba-d680-48e4-9a1f-313d4beedaf7@github.com>
 <kfsajxtDhc1KxOB5pFr8y3VO70BTdsfk8Wn_lbx4gMs=.6c127426-0a67-415c-bbf2-0dea302061e7@github.com>
Message-ID: <LSfNJQ6TWqn-bvb3Zq3Szvo-sZqmJ4ypGPDITWJ2HfM=.1466a30f-0b5d-49d3-a6a4-f171cf239802@github.com>

On Thu, 20 Apr 2023 12:04:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Handle overflows
>
> src/hotspot/os/posix/os_posix.cpp line 1342:
> 
>> 1340: }
>> 1341: 
>> 1342: static jlong nanos_to_nanos_bounded(jlong nanos) {
> 
> I don't think we actually need this for nanos. There is no overflow potential and the MAX_SECS limit will be handled later.

Hm, "later" where? Because I see the call to `pthread_condwait_timed` right after we produced abstime using `nanos_to_nanos_bounded`, and this looks like the last opportunity to handle the `MAX_SECS` limit:
https://github.com/openjdk/jdk/pull/13225/files#diff-7daa601d72ef74e5281faf8256b537b4ec9c5e5c236b716902592da12fa2aad2R1582

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1172492842

From dholmes at openjdk.org  Thu Apr 20 12:34:53 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Apr 2023 12:34:53 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v9]
In-Reply-To: <LSfNJQ6TWqn-bvb3Zq3Szvo-sZqmJ4ypGPDITWJ2HfM=.1466a30f-0b5d-49d3-a6a4-f171cf239802@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <ZK7HhQs6pOSLV0j7cP4ywj0Ng-9atw2KFa_tU2zbVBs=.df722eba-d680-48e4-9a1f-313d4beedaf7@github.com>
 <kfsajxtDhc1KxOB5pFr8y3VO70BTdsfk8Wn_lbx4gMs=.6c127426-0a67-415c-bbf2-0dea302061e7@github.com>
 <LSfNJQ6TWqn-bvb3Zq3Szvo-sZqmJ4ypGPDITWJ2HfM=.1466a30f-0b5d-49d3-a6a4-f171cf239802@github.com>
Message-ID: <VF8YAoCeEslHJOhklS-0tTiXKD5PpizULgcxpzIyFGY=.5a4138a2-46d0-4e06-8acc-4e49b4274190@github.com>

On Thu, 20 Apr 2023 12:09:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/os/posix/os_posix.cpp line 1342:
>> 
>>> 1340: }
>>> 1341: 
>>> 1342: static jlong nanos_to_nanos_bounded(jlong nanos) {
>> 
>> I don't think we actually need this for nanos. There is no overflow potential and the MAX_SECS limit will be handled later.
>
> Hm, "later" where? Because I see the call to `pthread_condwait_timed` right after we produced abstime using `nanos_to_nanos_bounded`, and this looks like the last opportunity to handle the `MAX_SECS` limit:
> https://github.com/openjdk/jdk/pull/13225/files#diff-7daa601d72ef74e5281faf8256b537b4ec9c5e5c236b716902592da12fa2aad2R1582

`to_abst_time` will call ` calc_rel_time` which checks for MAX_SECS.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1172515211

From shade at openjdk.org  Thu Apr 20 12:34:54 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Apr 2023 12:34:54 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v9]
In-Reply-To: <VF8YAoCeEslHJOhklS-0tTiXKD5PpizULgcxpzIyFGY=.5a4138a2-46d0-4e06-8acc-4e49b4274190@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <ZK7HhQs6pOSLV0j7cP4ywj0Ng-9atw2KFa_tU2zbVBs=.df722eba-d680-48e4-9a1f-313d4beedaf7@github.com>
 <kfsajxtDhc1KxOB5pFr8y3VO70BTdsfk8Wn_lbx4gMs=.6c127426-0a67-415c-bbf2-0dea302061e7@github.com>
 <LSfNJQ6TWqn-bvb3Zq3Szvo-sZqmJ4ypGPDITWJ2HfM=.1466a30f-0b5d-49d3-a6a4-f171cf239802@github.com>
 <VF8YAoCeEslHJOhklS-0tTiXKD5PpizULgcxpzIyFGY=.5a4138a2-46d0-4e06-8acc-4e49b4274190@github.com>
Message-ID: <VPqcHsWOAXkZgKa3sDTioibtJMayrwkIDW52s6PqQT0=.6fc9d5fb-ae37-4445-bf80-3fa03d6b7e07@github.com>

On Thu, 20 Apr 2023 12:28:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hm, "later" where? Because I see the call to `pthread_condwait_timed` right after we produced abstime using `nanos_to_nanos_bounded`, and this looks like the last opportunity to handle the `MAX_SECS` limit:
>> https://github.com/openjdk/jdk/pull/13225/files#diff-7daa601d72ef74e5281faf8256b537b4ec9c5e5c236b716902592da12fa2aad2R1582
>
> `to_abst_time` will call ` calc_rel_time` which checks for MAX_SECS.

I see, good! I dropped `nanos_to_nanos_bounded` locally, and I would re-merge from master once GHA-s are healthy again. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1172519235

From nlisker at openjdk.org  Thu Apr 20 13:09:11 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 20 Apr 2023 13:09:11 GMT
Subject: RFR: 8266571: Sequenced Collections [v8]
In-Reply-To: <xhWK9e-orFi_yRPH1xyUWf2ye5tP1BrysvQrLhqCLbY=.c316918e-793f-4bdc-bee6-c5267efa6c5c@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <xhWK9e-orFi_yRPH1xyUWf2ye5tP1BrysvQrLhqCLbY=.c316918e-793f-4bdc-bee6-c5267efa6c5c@github.com>
Message-ID: <OKv7JIh0Sw-bk4Xf1Wixv_pgSA-JKjF9SqLRYp_OMRw=.036864e8-3e65-45ef-9714-e3e0f3e0b133@github.com>

On Thu, 20 Apr 2023 04:19:55 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Add missing @throws and @since tags.
>  - Convert code samples to snippets.
>  - Various editorial changes.
>  - Fix up toArray(T[]) on reverse-ordered views.

src/java.base/share/classes/java/util/NavigableMap.java line 442:

> 440:      * @return a reverse-ordered view of this map, as a {@code NavigableMap}
> 441:      * @since 21
> 442:      */

`NavigableSet` words its `reversed` doc a bit differently.

src/java.base/share/classes/java/util/SequencedMap.java line 127:

> 125:      * Returns a reverse-ordered <a href="Collection.html#view">view</a> of this map.
> 126:      * The encounter order of elements in the returned view is the inverse of the encounter
> 127:      * order of elements in this map. The reverse ordering affects all order-sensitive operations,

Although I think this is clear as-is, you defined *encounter order* in a map with respect to mappings, not elements, and that is also the language used in the methods here, so you might want to use this language here too.

src/java.base/share/classes/java/util/SequencedMap.java line 152:

> 150:         var it = entrySet().iterator();
> 151:         return it.hasNext() ? Map.Entry.copyOf(it.next()) : null;
> 152:     }

Would is be better to first check `Map.isEmpty()` and only then obtain the iterator? That would eliminate also the `hasNext` check.

default Map.Entry<K,V> firstEntry() {
    return isEmpty() ? null : Map.Entry.copyOf(entrySet().iterator().next());
}


Same question for the other methods.

src/java.base/share/classes/java/util/SequencedMap.java line 263:

> 261:      *
> 262:      * @implSpec
> 263:      * The implementation of this method in this class returns a {@code SequencedSet}

Some of the methods here use "of this method" and some skip it, noting in case you want to streamline it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1172518086
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1172493367
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1172499047
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1172507205

From jlahoda at openjdk.org  Thu Apr 20 13:35:56 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 20 Apr 2023 13:35:56 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <wjSlPu3uSsQgLS31xyP2xaY7SeTazIn-QbyGRSRUbEg=.780fd41d-86ea-4267-af37-81a0e41f9739@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <wjSlPu3uSsQgLS31xyP2xaY7SeTazIn-QbyGRSRUbEg=.780fd41d-86ea-4267-af37-81a0e41f9739@github.com>
Message-ID: <aGTwk7FII6Z6t5i_0cDZtnuNgUPEyRw3Modc2g7pM0A=.b202ebe2-00eb-40ba-9801-5a10e54c09ab@github.com>

On Wed, 19 Apr 2023 04:06:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>>  - Reflecting review comments.
>>  - Fixing exhaustiveness for unsealed supertype pattern.
>>  - No need to enable features after error reported.
>>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>>  - A prototype of avoiding enum initialization.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 170:
> 
>> 168:             } else if (label instanceof EnumDesc<?> enumDesc) {
>> 169:                 if (target.getClass().isEnum() &&
>> 170:                     ((Enum<?>) target).describeConstable().stream().anyMatch(d -> d.equals(enumDesc))) {
> 
> probably a matter of style but isn't it a bit too much to use streams here? there will be always only one element right?

Technically, one element, but the type is optional, so formally could be no elements. I could use `.get()`, but that feels a bit ugly and against optional?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172599496

From vromero at openjdk.org  Thu Apr 20 13:44:53 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 20 Apr 2023 13:44:53 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <aGTwk7FII6Z6t5i_0cDZtnuNgUPEyRw3Modc2g7pM0A=.b202ebe2-00eb-40ba-9801-5a10e54c09ab@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <wjSlPu3uSsQgLS31xyP2xaY7SeTazIn-QbyGRSRUbEg=.780fd41d-86ea-4267-af37-81a0e41f9739@github.com>
 <aGTwk7FII6Z6t5i_0cDZtnuNgUPEyRw3Modc2g7pM0A=.b202ebe2-00eb-40ba-9801-5a10e54c09ab@github.com>
Message-ID: <Xdn3kPpkZXA-KqEGeIiaJWcLiOw22-hTdMkZESEAkA4=.32d5bc43-6c52-4006-afc5-13e90caf3a5b@github.com>

On Thu, 20 Apr 2023 13:33:17 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 170:
>> 
>>> 168:             } else if (label instanceof EnumDesc<?> enumDesc) {
>>> 169:                 if (target.getClass().isEnum() &&
>>> 170:                     ((Enum<?>) target).describeConstable().stream().anyMatch(d -> d.equals(enumDesc))) {
>> 
>> probably a matter of style but isn't it a bit too much to use streams here? there will be always only one element right?
>
> Technically, one element, but the type is optional, so formally could be no elements. I could use `.get()`, but that feels a bit ugly and against optional?

yep I know, up to you I'm not strong on this, I guess I was thinking about performance but probably not using streams won't make a difference in this case

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172609916

From jlahoda at openjdk.org  Thu Apr 20 13:44:56 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 20 Apr 2023 13:44:56 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com>
Message-ID: <vhDVxbO8kOdrvJDQNi0M-gvqjb9qpD9EKBhGPl9YXEU=.ac1dffda-0ed4-454e-9a08-84af46380d16@github.com>

On Wed, 19 Apr 2023 15:36:08 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>>  - Reflecting review comments.
>>  - Fixing exhaustiveness for unsealed supertype pattern.
>>  - No need to enable features after error reported.
>>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>>  - A prototype of avoiding enum initialization.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 279:
> 
>> 277:     }
>> 278: 
>> 279:     private static int lazyDoEnumSwitch(Enum<?> target, int startIndex, Object[] labels, MethodHandles.Lookup lookup, Class<?> enumClass, MutableCallSite callSite) throws Throwable {
> 
> out of curiosity, under what conditions the `startIndex` would be different from `0`? also shouldn't we check that `startIndex` is `>= 0`?

`startIndex` may be non-0 when there are guards in the switch. In the case of the `enumSwitch`, something like:

enum E {A, B;}
E e = E.B;
switch (e) {
     case E ee when ee == E.A -> {}
     case E ee -> {}
}


the method will be called twice, one with `startIndex == 0` and once with `startIndex == 1`, after the guard fails/returns `false`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172609212

From jlahoda at openjdk.org  Thu Apr 20 13:51:52 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 20 Apr 2023 13:51:52 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <LKbcXB4x0lWXcYeoG-xpoSZDc1Kdp5M5Cb1FaA5Ts4Q=.9d32c4ed-0e57-4153-9124-4ed961631532@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <LKbcXB4x0lWXcYeoG-xpoSZDc1Kdp5M5Cb1FaA5Ts4Q=.9d32c4ed-0e57-4153-9124-4ed961631532@github.com>
Message-ID: <iFiDwHOs53muIyNfMxLl9KIPWE55dPDl1P7PQJzEdNI=.e309a187-a402-4172-9715-6aa48c2feb96@github.com>

On Wed, 19 Apr 2023 16:45:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>>  - Reflecting review comments.
>>  - Fixing exhaustiveness for unsealed supertype pattern.
>>  - No need to enable features after error reported.
>>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>>  - A prototype of avoiding enum initialization.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 279:
> 
>> 277:     }
>> 278: 
>> 279:     private static int lazyDoEnumSwitch(Enum<?> target, int startIndex, Object[] labels, MethodHandles.Lookup lookup, Class<?> enumClass, MutableCallSite callSite) throws Throwable {
> 
> can `doEnumSwitch` be folded into `lazyDoEnumSwitch`? just a suggestion, I'm OK with either way just that now it is not clear that we need two methods here. Also in `doEnumSwitch` and out of curiosity what example of user code could hit this section:
> 
> 
>             if (label instanceof Class<?> c) {
>                 if (c.isAssignableFrom(targetClass))
>                     return i;
>             }
> 
> EDIT: nvm I found one example

The intent here is to avoid eager initialization of enums - so, until the enum is initialized, `lazyDoEnumSwitch` will be used (which, by itself, won't compute any results, except the result for `null`), which is then replaced with `doEnumSwitch` using the enum constants directly.

The enum switches support patterns as well, so something like:

enum E {A;}
E e = ...;
switch (e) {
     case E ee -> {}
}

is valid, and should trigger the part with Class labels.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172623143

From vromero at openjdk.org  Thu Apr 20 14:09:51 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 20 Apr 2023 14:09:51 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <vhDVxbO8kOdrvJDQNi0M-gvqjb9qpD9EKBhGPl9YXEU=.ac1dffda-0ed4-454e-9a08-84af46380d16@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com>
 <vhDVxbO8kOdrvJDQNi0M-gvqjb9qpD9EKBhGPl9YXEU=.ac1dffda-0ed4-454e-9a08-84af46380d16@github.com>
Message-ID: <SeEkE8PYhEdySCf8tzCopY4ilEkuUYiK-V55Zy9Aemg=.d2449ccd-aaee-4106-8757-f913aaa6160d@github.com>

On Thu, 20 Apr 2023 13:41:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 279:
>> 
>>> 277:     }
>>> 278: 
>>> 279:     private static int lazyDoEnumSwitch(Enum<?> target, int startIndex, Object[] labels, MethodHandles.Lookup lookup, Class<?> enumClass, MutableCallSite callSite) throws Throwable {
>> 
>> out of curiosity, under what conditions the `startIndex` would be different from `0`? also shouldn't we check that `startIndex` is `>= 0`?
>
> `startIndex` may be non-0 when there are guards in the switch. In the case of the `enumSwitch`, something like:
> 
> enum E {A, B;}
> E e = E.B;
> switch (e) {
>      case E ee when ee == E.A -> {}
>      case E ee -> {}
> }
> 
> 
> the method will be called twice, one with `startIndex == 0` and once with `startIndex == 1`, after the guard fails/returns `false`.

I see, thanks

>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 279:
>> 
>>> 277:     }
>>> 278: 
>>> 279:     private static int lazyDoEnumSwitch(Enum<?> target, int startIndex, Object[] labels, MethodHandles.Lookup lookup, Class<?> enumClass, MutableCallSite callSite) throws Throwable {
>> 
>> can `doEnumSwitch` be folded into `lazyDoEnumSwitch`? just a suggestion, I'm OK with either way just that now it is not clear that we need two methods here. Also in `doEnumSwitch` and out of curiosity what example of user code could hit this section:
>> 
>> 
>>             if (label instanceof Class<?> c) {
>>                 if (c.isAssignableFrom(targetClass))
>>                     return i;
>>             }
>> 
>> EDIT: nvm I found one example
>
> The intent here is to avoid eager initialization of enums - so, until the enum is initialized, `lazyDoEnumSwitch` will be used (which, by itself, won't compute any results, except the result for `null`), which is then replaced with `doEnumSwitch` using the enum constants directly.
> 
> The enum switches support patterns as well, so something like:
> 
> enum E {A;}
> E e = ...;
> switch (e) {
>      case E ee -> {}
> }
> 
> is valid, and should trigger the part with Class labels.

yep I found a similar test case triggering this code

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172646957
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172647746

From lancea at openjdk.org  Thu Apr 20 14:13:02 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 20 Apr 2023 14:13:02 GMT
Subject: Integrated: 8305945: (zipfs) Opening a directory to get input stream
 produces incorrect exception message
In-Reply-To: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
References: <DTWY9GlEU01fjd4aAs5CpH9TDwzzl97bV7CSygeR8Eg=.f682a0c2-5a22-4045-bf46-c72e2e44e581@github.com>
Message-ID: <iztpHX5jQYv2mjXZ8RF2zDo2EAhPIZxeRlnUpKBAIZQ=.a061a844-ee4f-44c1-98fb-0f4f551c1e9b@github.com>

On Fri, 14 Apr 2023 20:24:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this trivial change when ZipFS returns the wrong java.nio.file.FileSystemException message due the the parameters being reversed.
> 
> I also included a simple junit test as part of the fix.
> 
> Mach5 tiers1-3 are clean
> 
> Best
> Lance

This pull request has now been integrated.

Changeset: c6a288dc
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6a288dcd63824230638f2d08a1372f1d6e16829
Stats:     103 lines in 2 files changed: 102 ins; 0 del; 1 mod

8305945: (zipfs) Opening a directory to get input stream produces incorrect exception message

Reviewed-by: naoto, cstein

-------------

PR: https://git.openjdk.org/jdk/pull/13482

From stsypanov at openjdk.org  Thu Apr 20 15:05:18 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 20 Apr 2023 15:05:18 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v6]
In-Reply-To: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
Message-ID: <_SwKNoENpVe5iTpIFhQl1B7IhNwZZgBz2U-QQ8F4Ids=.64b9014d-3121-48f2-9368-c69b0370286e@github.com>

> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
> 
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>   .appendLiteral("Date:")
>   .padNext(20, ' ')
>   .append(DateTimeFormatter.ISO_DATE)
>   .toFormatter();
> String text = dtf.format(LocalDateTime.now());

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8300818: Remove blank line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12131/files
  - new: https://git.openjdk.org/jdk/pull/12131/files/07215c1f..baa7f92e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12131&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12131&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12131/head:pull/12131

PR: https://git.openjdk.org/jdk/pull/12131

From darcy at openjdk.org  Thu Apr 20 15:37:44 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 20 Apr 2023 15:37:44 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions
In-Reply-To: <7vStHe4ivE6O9xL3fd98AJGKvvDRdkwymAqF2lNgw6A=.91eb28e0-7d9a-433c-9b47-80084e822454@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <7vStHe4ivE6O9xL3fd98AJGKvvDRdkwymAqF2lNgw6A=.91eb28e0-7d9a-433c-9b47-80084e822454@github.com>
Message-ID: <bv49AsDFSznIKNEqDZsKJXcrB-oVsmBYRj9ATS59AQI=.ed82023e-d777-4f36-ad29-b7cf81e92e6c@github.com>

On Wed, 19 Apr 2023 17:04:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> Please file a CSR for the proposed behavioral change.

> Hi @jddarcy,
> 
> I'm happy to create a CSR for this change, but I'm a little bit unsure about the details. From my understanding this qualifies as a behavioral change, right? But this behavior wasn't specified before at all. Neither did the API specification of `ObjectInputStream::readObject()` mention that it can throw a `NegativeArraySizeException` nor did the [Serialization Specification](https://docs.oracle.com/en/java/javase/20/docs/specs/serialization/index.html) mentioned the case of a negative array size.
> 
> Previously, `readObject()` could throw a `NegativeArraySizeException` which will now, with this PR, be changed into a `InvalidClassException`. Do you agree that this is an implementation detail and therefor the CSR should have "Implementation" Scope?
> 
> Thanks, Volker

Hi Volker,

Yes, the behavior wasn't specified, but that doesn't imply users haven't become reliant on it, hence the (behavioral) compatibility review via a CSR of the implementation change.

HTH

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13540#issuecomment-1516545807

From rriggs at openjdk.org  Thu Apr 20 16:06:45 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Apr 2023 16:06:45 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v6]
In-Reply-To: <_SwKNoENpVe5iTpIFhQl1B7IhNwZZgBz2U-QQ8F4Ids=.64b9014d-3121-48f2-9368-c69b0370286e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <_SwKNoENpVe5iTpIFhQl1B7IhNwZZgBz2U-QQ8F4Ids=.64b9014d-3121-48f2-9368-c69b0370286e@github.com>
Message-ID: <IlBXvO3HhMcj5bHY-AoAy-xaa2H1N8AqQ8RI9I6xcOw=.a75f0ea1-188c-4d80-a82b-7fd3fc97ef13@github.com>

On Thu, 20 Apr 2023 15:05:18 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300818: Remove blank line

LGTM;  thanks

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12131#pullrequestreview-1394327486

From lancea at openjdk.org  Thu Apr 20 16:09:46 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 20 Apr 2023 16:09:46 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v3]
In-Reply-To: <zpnk-wC0R3qZwiWhd1umWZZZQre0DhXI_52DEGQKclQ=.71067494-6bcd-431c-8b90-ab72c0b42378@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
 <zpnk-wC0R3qZwiWhd1umWZZZQre0DhXI_52DEGQKclQ=.71067494-6bcd-431c-8b90-ab72c0b42378@github.com>
Message-ID: <TAQqMtxl1EIFm7jTYz4er8OJAm0Nh3Lgqjg9Dk6dOao=.269b9406-5cda-4190-af35-93470b66cfaf@github.com>

On Thu, 20 Apr 2023 10:06:33 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Test is updated to create the binary files during test execution.
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented the review comment.

The original version of this test was validating serialization compatibility with previous releases.

The current changes seems to have removed that validation in the re-write of the test

One option is to convert the various *.ser files to a byte array and have the test write them out or read them from a stream to do the validation

-------------

Changes requested by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13537#pullrequestreview-1394332620

From phofer at openjdk.org  Thu Apr 20 16:14:54 2023
From: phofer at openjdk.org (Peter Hofer)
Date: Thu, 20 Apr 2023 16:14:54 GMT
Subject: Integrated: 8305746: InitializeEncoding should cache Charset object
 instead of charset name
In-Reply-To: <n_LC8ej_4-qM15pCWVFcirQyB6RNiH7xQtHiJBWNmI0=.c05c9ac5-5602-4f13-98b6-ec1a126c0975@github.com>
References: <n_LC8ej_4-qM15pCWVFcirQyB6RNiH7xQtHiJBWNmI0=.c05c9ac5-5602-4f13-98b6-ec1a126c0975@github.com>
Message-ID: <R8kthHNChVp-5aucp8NLXyCM8wt6-b1zDlXj27tWak8=.9736bdcd-0b84-46c4-8d60-1f6e11f22ceb@github.com>

On Mon, 17 Apr 2023 17:47:04 GMT, Peter Hofer <phofer at openjdk.org> wrote:

> Store `Charset` object in `jnuEncoding` and use `String(byte[], Charset)` and `String.getBytes(Charset)` instead of passing the charset name.

This pull request has now been integrated.

Changeset: 20b1d19d
Author:    Peter Hofer <phofer at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/20b1d19d26a039b963590ca6f806f78a4a94c25f
Stats:     51 lines in 1 file changed: 18 ins; 14 del; 19 mod

8305746: InitializeEncoding should cache Charset object instead of charset name

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/13499

From lmesnik at openjdk.org  Thu Apr 20 16:18:48 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 20 Apr 2023 16:18:48 GMT
Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using
 an OutputAnalyzer at the same time
Message-ID: <du3xsDH63bi1NGWbIDvL8FwkAyFGFo1y4KkUy88PB6o=.02e4325c-6cac-4da5-b1f1-6162cf6606ca@github.com>

ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams.

This fix preserve process streams content and allow to read it after process completion. The another possible solution would be to throw exception when user tries to read already drained streams to fail tests earlier. However it complicates usage of ProcessTools.startProcess() methods.

The regression test has been provided with issue.

-------------

Commit messages:
 - 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time

Changes: https://git.openjdk.org/jdk/pull/13560/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13560&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8233725
  Stats: 180 lines in 3 files changed: 163 ins; 2 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13560.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13560/head:pull/13560

PR: https://git.openjdk.org/jdk/pull/13560

From smarks at openjdk.org  Thu Apr 20 16:22:07 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 20 Apr 2023 16:22:07 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <XRv7PT9QdKJYYkNdzEbHmTAl317iVYZm2VUH7-fIqJk=.e5c5efb8-22fb-405c-893c-19d2641adc72@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
 <UQFv9mQcYOEgU_FMhks5VpQ5n52_eKtQ-SkVFWIJxfA=.f210d862-89a9-4da8-be7b-41edfa06fb39@github.com>
 <gFEW30ltuY4EnrgaKyeIKV3tCqUEhO7RjxoAbRx2Fg8=.dc998f69-9f51-4fde-a96c-514a38226ce8@github.com>
 <3H2vsVn6_RvIXnR2Y_02RScaLHS9LLuGkWMFqLMwYsE=.8a56e190-3777-4060-ac6c-dd2834cb035d@github.com>
 <XRv7PT9QdKJYYkNdzEbHmTAl317iVYZm2VUH7-fIqJk=.e5c5efb8-22fb-405c-893c-19d2641adc72@github.com>
Message-ID: <tJYdeImTNTe2ryron_GRIkQcZXlUvBwwUmdS0o5CwqA=.e44fab85-502a-499d-a314-4e0572cc4d23@github.com>

On Thu, 20 Apr 2023 09:03:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> @pavelrappo Arrrrggh.
>> 
>>> I guess, this PR has converged enough for us to discuss some trivial stuff; so here it goes.
>> 
>> All this "trivial" stuff is generating a lot of work! :-) Well, no big deal, Joe D still has more CSR comments coming.
>> 
>> I didn't know about the need to specify `@throws` in order to generate the throws-clauses in the docs. Ah, well, turns out it wasn't THAT bad to run through the hierarchy and check all the inherited methods. Done.
>> 
>> As an aside, I note that some methods such as ArrayList.addFirst/addLast had this javadoc:
>> 
>>     /**
>>      * @inheritDoc
>>      */
>> 
>> It didn't appear at all in the javadoc output, I guess because of `--override-methods=summary`. Not surprising in isolation, but it seemed strange because the getX and removeX methods were in the detail section but the addX methods seemed "missing". Is there a way to inherit the doc from a superclass but force a particular method to have its details included? It's kind of moot because these are also missing a `@since` tag, and adding that did cause the method detail to be included. Seems like the summary/detail stuff still needs some things to be worked out.
>
>> I didn't know about the need to specify `@throws` in order to generate the throws-clauses in the docs. 
> 
> You need to explicitly inherit `@throws` only for exceptions that aren't mentioned in the `throws` clause.
> 
>> As an aside, I note that some methods such as ArrayList.addFirst/addLast had this javadoc:
>> 
>> ```
>> /**
>>  * @inheritDoc
>>  */
>> ```
>> 
>> It didn't appear at all in the javadoc output, I guess because of `--override-methods=summary`.
> 
> Correct: it shouldn't have appeared in "Method Details" because of that option. But if it didn't appear at all (i.e. not even in the "Method Summary / Methods declared in ..." table at the top of the page), it's a bug.
> 
>> Is there a way to inherit the doc from a superclass but force a particular method to have its details included? It's kind of moot because these are also missing a `@since` tag, and adding that did cause the method detail to be included.
> 
> Other than to add to the inherited documentation? Not that I know of. Yes, adding a `@since` tag will cause the method detail to appear.

Oh, oops, I was mistaken to say "It didn't appear at all in the javadoc output." It did appear in the Method Summary, but not in the Method Details. The behavior is thus as expected. However, it still seems like there's something "off" about this situation. As a javadoc author it's hard to predict what will happen. Maybe more control is necessary. In addition, from the editorial standpoint of the specification, we also need to figure out when something should appear in the Summary and when it should appear in the Detail. Actually we should figure that out first, use it to drive the appropriate mechanisms in the javadoc tool, and then adjust the doc comments themselves as necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1172823558

From dfuchs at openjdk.org  Thu Apr 20 16:22:43 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Apr 2023 16:22:43 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v3]
In-Reply-To: <TAQqMtxl1EIFm7jTYz4er8OJAm0Nh3Lgqjg9Dk6dOao=.269b9406-5cda-4190-af35-93470b66cfaf@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
 <zpnk-wC0R3qZwiWhd1umWZZZQre0DhXI_52DEGQKclQ=.71067494-6bcd-431c-8b90-ab72c0b42378@github.com>
 <TAQqMtxl1EIFm7jTYz4er8OJAm0Nh3Lgqjg9Dk6dOao=.269b9406-5cda-4190-af35-93470b66cfaf@github.com>
Message-ID: <z3wc246IlNX0nNX-YOj6JXEmEztB1gEyQ_1ZeLJ0XSQ=.ff496828-71b7-4d3e-8dc2-4b05310d3178@github.com>

On Thu, 20 Apr 2023 16:06:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> The original version of this test was validating serialization compatibility with previous releases.
> 
> The current changes seems to have removed that validation in the re-write of the test
> 
> One option is to convert the various *.ser files to a byte array and have the test write them out or read them from a stream to do the validation

Good point. You can also base64-encode the bytes into a string - here is an example:
https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/logging/HigherResolutionTimeStamps/SerializeLogRecord.java

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13537#issuecomment-1516611679

From duke at openjdk.org  Thu Apr 20 16:29:54 2023
From: duke at openjdk.org (olivergillespie)
Date: Thu, 20 Apr 2023 16:29:54 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v6]
In-Reply-To: <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
Message-ID: <q27kl4rBPCPbfZJCOIey9rjYZZFR_nXl-uX1XAq-s6w=.d90bf0e9-6b04-4fb8-8527-01dad1184d97@github.com>

On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075). [Benchmark results and generated code analysis moved to comment]
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shuffle docs

Thanks for all the comments so far. If there are no outstanding concerns, I'll integrate this tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1516619519

From vromero at openjdk.org  Thu Apr 20 16:35:55 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 20 Apr 2023 16:35:55 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <SeEkE8PYhEdySCf8tzCopY4ilEkuUYiK-V55Zy9Aemg=.d2449ccd-aaee-4106-8757-f913aaa6160d@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com>
 <vhDVxbO8kOdrvJDQNi0M-gvqjb9qpD9EKBhGPl9YXEU=.ac1dffda-0ed4-454e-9a08-84af46380d16@github.com>
 <SeEkE8PYhEdySCf8tzCopY4ilEkuUYiK-V55Zy9Aemg=.d2449ccd-aaee-4106-8757-f913aaa6160d@github.com>
Message-ID: <GGEOWwx-Up225MmHNpFyvdOK6-dlhZE1OVUjx3wGzvA=.c6294dd0-a352-4aa0-a2cc-ab4bcb56f982@github.com>

On Thu, 20 Apr 2023 14:07:01 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> The intent here is to avoid eager initialization of enums - so, until the enum is initialized, `lazyDoEnumSwitch` will be used (which, by itself, won't compute any results, except the result for `null`), which is then replaced with `doEnumSwitch` using the enum constants directly.
>> 
>> The enum switches support patterns as well, so something like:
>> 
>> enum E {A;}
>> E e = ...;
>> switch (e) {
>>      case E ee -> {}
>> }
>> 
>> is valid, and should trigger the part with Class labels.
>
> yep I found a similar test case triggering this code

could you explain a bit more the relation between `lazyDoEnumSwitch` and `doEnumSwitch` because my understanding is that `lazyDoEnumSwitch` is invoking `doEnumSwitch` so to me whenever `lazyDoEnumSwitch` is invoked there will be an immediate invocation of `doEnumSwitch` that's why I thought they could be folded together

>> `startIndex` may be non-0 when there are guards in the switch. In the case of the `enumSwitch`, something like:
>> 
>> enum E {A, B;}
>> E e = E.B;
>> switch (e) {
>>      case E ee when ee == E.A -> {}
>>      case E ee -> {}
>> }
>> 
>> 
>> the method will be called twice, one with `startIndex == 0` and once with `startIndex == 1`, after the guard fails/returns `false`.
>
> I see, thanks

and regarding checking that `startIndex` should be `>= 0`? shouldn't we check for that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172839418
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172840817

From jlahoda at openjdk.org  Thu Apr 20 16:43:50 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 20 Apr 2023 16:43:50 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <GGEOWwx-Up225MmHNpFyvdOK6-dlhZE1OVUjx3wGzvA=.c6294dd0-a352-4aa0-a2cc-ab4bcb56f982@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com>
 <vhDVxbO8kOdrvJDQNi0M-gvqjb9qpD9EKBhGPl9YXEU=.ac1dffda-0ed4-454e-9a08-84af46380d16@github.com>
 <SeEkE8PYhEdySCf8tzCopY4ilEkuUYiK-V55Zy9Aemg=.d2449ccd-aaee-4106-8757-f913aaa6160d@github.com>
 <GGEOWwx-Up225MmHNpFyvdOK6-dlhZE1OVUjx3wGzvA=.c6294dd0-a352-4aa0-a2cc-ab4bcb56f982@github.com>
Message-ID: <-LVQqa8s0ItYV8ckL06FtOHjo5pOe-g66JNi7yPmhVI=.33d74c7e-0232-4047-9cde-4a5af12eea61@github.com>

On Thu, 20 Apr 2023 16:32:33 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> I see, thanks
>
> and regarding checking that `startIndex` should be `>= 0`? shouldn't we check for that?

That's in my upcoming update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172848770

From jlahoda at openjdk.org  Thu Apr 20 16:56:53 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 20 Apr 2023 16:56:53 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <GGEOWwx-Up225MmHNpFyvdOK6-dlhZE1OVUjx3wGzvA=.c6294dd0-a352-4aa0-a2cc-ab4bcb56f982@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com>
 <vhDVxbO8kOdrvJDQNi0M-gvqjb9qpD9EKBhGPl9YXEU=.ac1dffda-0ed4-454e-9a08-84af46380d16@github.com>
 <SeEkE8PYhEdySCf8tzCopY4ilEkuUYiK-V55Zy9Aemg=.d2449ccd-aaee-4106-8757-f913aaa6160d@github.com>
 <GGEOWwx-Up225MmHNpFyvdOK6-dlhZE1OVUjx3wGzvA=.c6294dd0-a352-4aa0-a2cc-ab4bcb56f982@github.com>
Message-ID: <DttthPwlFDMrZCqKgseRiWeqSbXblQ9g-He4xZ3f7F8=.cf5938c7-9a63-47b5-a28e-ee2b1359a2bc@github.com>

On Thu, 20 Apr 2023 16:31:33 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> yep I found a similar test case triggering this code
>
> could you explain a bit more the relation between `lazyDoEnumSwitch` and `doEnumSwitch` because my understanding is that `lazyDoEnumSwitch` is invoking `doEnumSwitch` so to me whenever `lazyDoEnumSwitch` is invoked there will be an immediate invocation of `doEnumSwitch` that's why I thought they could be folded together

So, when the `enumSwitch` bootstrap is called, the enum class may or may not be initialized. So, to avoid initialization, we only do lightweight checks, and construct a `MutableCallSite` with `lazyDoEnumSwitch` as a target.

When the `CallSite` is invoked with an actual selector value, two options may arise:
a) the selector value is null. The `lazyDoEnumSwitch` itself returns -1.
b) the selector value is not null. The enum class must already be initialized (I believe). So, we create (hopefully) better structure to do the categorization, based on `doEnumSwitch`, and set that into the `CallSite`. Further calls will use this new `doEnumSwitch` based categorization directly, without calling `lazyDoEnumSwitch`. The current call will manually delegate to the `doEnumSwitch` version, but that should only happen "once" (or a small number of times, due to running in different threads, etc.).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172863795

From kvn at openjdk.org  Thu Apr 20 16:57:03 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 20 Apr 2023 16:57:03 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v9]
In-Reply-To: <tSOY4bLeZKlucGnZHlKrhI0z9fUwSva5UyGrRAlp_4M=.ce362a15-9aa0-4f19-9f80-4a9ecb9794cd@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <tSOY4bLeZKlucGnZHlKrhI0z9fUwSva5UyGrRAlp_4M=.ce362a15-9aa0-4f19-9f80-4a9ecb9794cd@github.com>
Message-ID: <H1ZxDzjIz_001haIylzaBItB0a8Kfby8kdwJRhdvgXM=.a67ecb42-3505-44a5-833e-f7162b0fb577@github.com>

On Tue, 18 Apr 2023 07:27:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
>> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`.
>> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>>  
>> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
>> 
>>     ResolvedJavaMethod method = ...;
>>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>>     return switch (a.kind()) {
>>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The same code using the new API:
>> 
>> 
>>     ResolvedJavaMethod method = ...;
>>     ResolvedJavaType explodeLoopType = ...;
>>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>>     return switch (a.getEnum("kind").getName()) {
>>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.
>
> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - added breadcrumb in AnnotationParser about considering JVMCI should new annotation element types be added
>  - fixed javadoc comment

Filed [JDK-8306581](https://bugs.openjdk.org/browse/JDK-8306581)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12810#issuecomment-1516653533

From jvernee at openjdk.org  Thu Apr 20 17:04:55 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Apr 2023 17:04:55 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v6]
In-Reply-To: <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
Message-ID: <2hD1ID2Zz2tle_3tZ14u59tthf0gt-KctTyO9MDDD6A=.f65983fa-cb36-41e1-8142-c3179aa70e92@github.com>

On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075). [Benchmark results and generated code analysis moved to comment]
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shuffle docs

I've also started a tier 1-4 run of this patch on our CI. Will report back with the results.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1516664167

From jlahoda at openjdk.org  Thu Apr 20 17:05:15 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 20 Apr 2023 17:05:15 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v3]
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <eqjf0iV7va4wdDL_FqUEvdFWPAK4okGYfrBa5QN0wI4=.86eec8fa-c3c2-43e4-963a-50db6a0175ba@github.com>

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:

 - Reflecting review feedback.
 - Fixing infinite loop in exhaustiveness computation caused by re-adding bindings that are already in the list.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13074/files
  - new: https://git.openjdk.org/jdk/pull/13074/files/a6ba602b..bb59254e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=01-02

  Stats: 343 lines in 7 files changed: 282 ins; 42 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/13074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074

PR: https://git.openjdk.org/jdk/pull/13074

From asotona at openjdk.org  Thu Apr 20 17:07:11 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 20 Apr 2023 17:07:11 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v6]
In-Reply-To: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
Message-ID: <Xbag8I4oeZmEiQfA1akzuC3rA3iAxQm7dOcAQt4hKvw=.e2cc69a8-ee92-42ef-8d13-feb598798e58@github.com>

> Classfile API didn't handle transformations of class files version 50 and below correctly. 
> 
> Proposed fix have two parts: 
> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
> 2. StackMapTable attribute is not generated for class file versions below 50.
> 
> StackMapsTest is also extended to test this patch.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  implemented StackCounter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13478/files
  - new: https://git.openjdk.org/jdk/pull/13478/files/dfea3cde..3d74c2fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=04-05

  Stats: 544 lines in 5 files changed: 416 ins; 7 del; 121 mod
  Patch: https://git.openjdk.org/jdk/pull/13478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13478/head:pull/13478

PR: https://git.openjdk.org/jdk/pull/13478

From asotona at openjdk.org  Thu Apr 20 17:07:13 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 20 Apr 2023 17:07:13 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v2]
In-Reply-To: <wtvStAUbHzc5UkDjmKYN2me5iE2-voGFZfECGv0E2R4=.6b57848d-9276-4632-85cb-5468666d132a@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <vEoUufevgfR5pb2hZ_E3nA8m0ahl0KdOQCCbeaw9zWk=.aa89bcfb-6eaf-429e-bc80-f9142f301630@github.com>
 <wtvStAUbHzc5UkDjmKYN2me5iE2-voGFZfECGv0E2R4=.6b57848d-9276-4632-85cb-5468666d132a@github.com>
Message-ID: <2qcFQwDeZB4N0lZvhOv4Fz_E5n7PUH74I9kVkvEHp58=.a35bdfba-1402-42ed-b4ad-5d91734f5f66@github.com>

On Wed, 19 Apr 2023 13:30:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   DiscontinuedInstruction implementation + test
>
> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 343:
> 
>> 341:                 }
>> 342:                 else {
>> 343:                     maxStack = maxLocals = 255;
> 
> Will this have a negative effect, such as slowing down the vm at runtime?
> 
> Edit: sorry, didn't see your summary comment when I was reviewing the updated patch. Otherwise it looks all good!

I've implemented StackCounter as a simple alternative to StackMapGenerator

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13478#discussion_r1172871858

From jlahoda at openjdk.org  Thu Apr 20 17:11:01 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 20 Apr 2023 17:11:01 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <86wPks_z959-kxY0Kfp8nx6IK-OvI7k7GaTt9HU-tGE=.d8ace5b0-fd4f-4c25-aa38-b7fe354e1401@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <86wPks_z959-kxY0Kfp8nx6IK-OvI7k7GaTt9HU-tGE=.d8ace5b0-fd4f-4c25-aa38-b7fe354e1401@github.com>
Message-ID: <UMUYe89ROd6EV3HcwiINIrnk4YofLa0kIqgk7fUImbI=.fb98e931-2878-4d26-8e0a-93bc3ecb1b2f@github.com>

On Tue, 18 Apr 2023 20:24:33 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>>  - Reflecting review comments.
>>  - Fixing exhaustiveness for unsealed supertype pattern.
>>  - No need to enable features after error reported.
>>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>>  - A prototype of avoiding enum initialization.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 94:
> 
>> 92:      *   <li>the element is of type {@code String} or {@code Integer} and
>> 93:      *       equals to the target.</li>
>> 94:      *   <li>the element is of type {@code EnumDesc}, that describes a constant that is
> 
> I think that at ~line 76, up in this same javadoc you need to add a reference to EnumDesc in the general description. Where it says:
> 
> 
> The static arguments are an array of case labels which must be non-null and of type
> {@code String} or {@code Integer} or {@code Class}.
> 
> also around line 107, where it says:
> 
> @param labels case labels - {@code String} and {@code Integer} constants
>                and {@code Class} instances, in any combination

Should be resolved by:
https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9

Thanks for the comment!

> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 263:
> 
>> 261:     private static <E extends Enum<E>> void validateEnumLabel(Class<?> enumClassTemplate, Object label) {
>> 262:         if (label == null) {
>> 263:             throw new IllegalArgumentException("null label found");
> 
> I think that this one is not hit by any test

Should be resolved by:
https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9

Thanks for the comment!

> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 271:
> 
>> 269:                                                    ", expected the provided enum class: " + enumClassTemplate);
>> 270:             }
>> 271:         } else if (labelClass == String.class) {
> 
> I think that if the condition is changed to `labelClass != String.class` then `throw` we can drop an `else` branch

Should be resolved by:
https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9

Thanks for the comment!

> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 274:
> 
>> 272:             //OK
>> 273:         } else {
>> 274:             throw new IllegalArgumentException("label with illegal type found: " + labelClass +
> 
> I think that this code is not being tested by any test

Should be resolved by:
https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9

Thanks for the comment!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 201:
> 
>> 199:     /** Are unconditional patterns in instanceof allowed
>> 200:      */
>> 201:     private boolean allowUnconditionalPatternsInstanceOf;
> 
> so I guess this field can be made final now

Should be resolved by:
https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9

Thanks for the comment!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 909:
> 
>> 907: 
>> 908:                             Set<Symbol> permitted = allPermittedSubTypes(clazz, csym -> {
>> 909:                                 Type instantiated = infer.instantiatePatternType(selectorType, csym);
> 
> for some cases, when there are no type parameters, this invocation is a no-op, do we really need inference at this point?

Should be resolved by:
https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9

Thanks for the comment!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172877205
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172877482
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172877294
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172877401
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172878133
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172878329

From jlahoda at openjdk.org  Thu Apr 20 17:11:02 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 20 Apr 2023 17:11:02 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <-LVQqa8s0ItYV8ckL06FtOHjo5pOe-g66JNi7yPmhVI=.33d74c7e-0232-4047-9cde-4a5af12eea61@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com>
 <vhDVxbO8kOdrvJDQNi0M-gvqjb9qpD9EKBhGPl9YXEU=.ac1dffda-0ed4-454e-9a08-84af46380d16@github.com>
 <SeEkE8PYhEdySCf8tzCopY4ilEkuUYiK-V55Zy9Aemg=.d2449ccd-aaee-4106-8757-f913aaa6160d@github.com>
 <GGEOWwx-Up225MmHNpFyvdOK6-dlhZE1OVUjx3wGzvA=.c6294dd0-a352-4aa0-a2cc-ab4bcb56f982@github.com>
 <-LVQqa8s0ItYV8ckL06FtOHjo5pOe-g66JNi7yPmhVI=.33d74c7e-0232-4047-9cde-4a5af12eea61@github.com>
Message-ID: <2luQpR-ObMOKeSrv_nZ9qtdA_M1WOWqLuCBx19hR5HY=.1421ec9a-4a24-4ffe-9854-9c3a14132f83@github.com>

On Thu, 20 Apr 2023 16:40:31 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> and regarding checking that `startIndex` should be `>= 0`? shouldn't we check for that?
>
> That's in my upcoming update.

The startIndex checks are part of this change:
https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9

Thanks for the comment!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172877989

From jlahoda at openjdk.org  Thu Apr 20 17:11:04 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 20 Apr 2023 17:11:04 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <Fiin2pina341hgkOUxMQEGmSIb6yUXD6HrXFMmoWm_s=.3aca7930-a874-4904-a26a-522a5716e00b@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <NYQhH7mCsIMtfI9UsMGPyVtVYob1yqSHYWMl_i26qL8=.e261753c-ac40-417c-8404-6b1d2fa16727@github.com>
 <jKDM0ZhYxskkzMotMi4wW8f9R-2aAjxob5AxiFaS7tU=.f5fcfd7f-74c1-4078-bc89-f2992fb5a806@github.com>
 <Fiin2pina341hgkOUxMQEGmSIb6yUXD6HrXFMmoWm_s=.3aca7930-a874-4904-a26a-522a5716e00b@github.com>
Message-ID: <gw6l_woenllrFgnffVk4v6qN4diFQZhQggrtjQoC7zk=.3b45645c-7f2b-4f3a-ae49-d0b827376ac0@github.com>

On Tue, 18 Apr 2023 14:17:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I've also found an infinite loop with this:
>> 
>> 
>> class Test {
>>     sealed interface I0 permits I1, I2 { }
>>     sealed interface I00 permits I1, I2 { }
>> 
>>     sealed interface I1 extends I0, I00 permits B, C { }
>>     sealed interface I2 extends I0, I00 permits B, C { }
>> 
>>     static final class B implements I1, I2 { }
>>     static final class C implements I1, I2 { }
>> 
>>     int test(Object o) {
>>         return switch (o) {
>>             case B c -> 2;
>>             case C d -> 3;
>>         };
>>     }
>> }
>
>> I've also found an infinite loop with this:
> 
> I believe this has to do with the fact that the list of pattern is not a set - so we can end up adding the same pattern descriptions over and over.

Thanks for the testcase!

I've tried to fix this by (avoiding to add redundant binding patterns):
https://github.com/openjdk/jdk/pull/13074/commits/7e6ed619d89784c49a96984c0f74176a9e0bcf63

Sets might be a good move eventually, but so far it seemed to hide problems, which quite probably needed to be solved anyway, so I kept the list impl for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172874262

From jlahoda at openjdk.org  Thu Apr 20 17:11:09 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 20 Apr 2023 17:11:09 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <xe5wRww8xjp21Hg-_0Vt0P5NoGVtUDQdDWcTGAlkw2A=.d0675328-b7dc-4276-abe6-facd0bbfc85f@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <tIWahIj-COGg9xaz4H4MVXX4Zv8Y3wRGEQFdCLKrqJo=.d3841341-4256-4e91-a028-580c16a9a3c9@github.com>
 <xe5wRww8xjp21Hg-_0Vt0P5NoGVtUDQdDWcTGAlkw2A=.d0675328-b7dc-4276-abe6-facd0bbfc85f@github.com>
Message-ID: <WuAbJb04XI8EOtIDxY9qaxrEexVKa--a-rOPOKjKY7c=.83d58701-7f6b-4aa7-bc26-07d260e7771a@github.com>

On Tue, 18 Apr 2023 14:31:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1021:
>> 
>>> 1019:              *    on patterns in the chosen column, as described above
>>> 1020:              */
>>> 1021:             var grouppedPerRecordClass =
>> 
>> Suggestion:
>> 
>>             var groupedPerRecordClass =
>
> or `patternsByRecordClass`, or `groupByRecordClass` (the latter would be consistent with `groupByHash` which is used below)

Should be resolved by:
https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9

Thanks for the comment!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172876875

From jlahoda at openjdk.org  Thu Apr 20 17:11:07 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 20 Apr 2023 17:11:07 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <NYQhH7mCsIMtfI9UsMGPyVtVYob1yqSHYWMl_i26qL8=.e261753c-ac40-417c-8404-6b1d2fa16727@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <NYQhH7mCsIMtfI9UsMGPyVtVYob1yqSHYWMl_i26qL8=.e261753c-ac40-417c-8404-6b1d2fa16727@github.com>
Message-ID: <rlFFn5e-R_0bvNh8fa4bzH76khi_VtM1zK5oKBkVQF0=.d6095445-ae4e-4082-9988-2460252f2702@github.com>

On Tue, 18 Apr 2023 13:43:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>>  - Reflecting review comments.
>>  - Fixing exhaustiveness for unsealed supertype pattern.
>>  - No need to enable features after error reported.
>>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>>  - A prototype of avoiding enum initialization.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 915:
> 
>> 913: 
>> 914:                             for (PatternDescription pdOther : patterns) {
>> 915:                                 if (pdOther instanceof BindingPattern bpOther) {
> 
> This code redundantly checks a pattern against itself, which I think we can avoid.

Possibly, but the handling of the binding patterns is getting more complex, so I've opted to keep it uniform for now.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 927:
> 
>> 925:                                             it.remove();
>> 926:                                             reduces = true;
>> 927:                                             continue PERMITTED;
> 
> the label can be dropped here as there's no nested loop

Should be resolved by:
https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9

Thanks for the comment!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 953:
> 
>> 951:                     }
>> 952: 
>> 953:                     Set<PatternDescription> cleanedToRemove = new HashSet<>(toRemove);
> 
> Another way to do this would be to compute the intersection between `toRemove` and `toAdd` (e.g. with `retainAll`), and then remove the intersection from both sets.

The addition and removal of the same binding pattern should be completely avoided in the current version of the code.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1058:
> 
>> 1056:                                     for (int i = 0; i < rpOne.nested.length; i++) {
>> 1057:                                         if (i != mismatchingCandidate &&
>> 1058:                                             !exactlyMatches(rpOne.nested[i], rpOther.nested[i])) {
> 
> should `exactlyMatches` be the implementation of `equals` in the `PatternDescriptor` class?

Should be resolved by:
https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9

Thanks for the comment!

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 847:
> 
>> 845:     /** Skip parens and return the enclosed expression
>> 846:      */
>> 847:     //XXX: remove??
> 
> What about this?

Should be resolved by:
https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9

Thanks for the comment!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172875982
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172876837
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172875031
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172877099
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172877541

From lancea at openjdk.org  Thu Apr 20 17:11:45 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 20 Apr 2023 17:11:45 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v3]
In-Reply-To: <z3wc246IlNX0nNX-YOj6JXEmEztB1gEyQ_1ZeLJ0XSQ=.ff496828-71b7-4d3e-8dc2-4b05310d3178@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
 <zpnk-wC0R3qZwiWhd1umWZZZQre0DhXI_52DEGQKclQ=.71067494-6bcd-431c-8b90-ab72c0b42378@github.com>
 <TAQqMtxl1EIFm7jTYz4er8OJAm0Nh3Lgqjg9Dk6dOao=.269b9406-5cda-4190-af35-93470b66cfaf@github.com>
 <z3wc246IlNX0nNX-YOj6JXEmEztB1gEyQ_1ZeLJ0XSQ=.ff496828-71b7-4d3e-8dc2-4b05310d3178@github.com>
Message-ID: <BEMSpMsArRYJyKlv6Pq1f1mTRz9enG7MyB9eY5rXBr8=.29609e9e-4eec-428d-a8d8-5b57b3fc9a5a@github.com>

On Thu, 20 Apr 2023 16:20:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> > The original version of this test was validating serialization compatibility with previous releases.
> > The current changes seems to have removed that validation in the re-write of the test
> > One option is to convert the various *.ser files to a byte array and have the test write them out or read them from a stream to do the validation
> 
> Good point. You can also base64-encode the bytes into a string - here is an example: https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/logging/HigherResolutionTimeStamps/SerializeLogRecord.java

Trivial code to create a Byte array in addition to Daniel's example


    /**
     * Utility method which takes an byte array and converts to byte array
     * declaration.  For example:
     * <pre>
     *     {@code
     *        var fooJar = Files.readAllBytes(Path.of("foo.jar"));
     *        var result = createByteArray(fooJar, "FOOBYTES");
     *      }
     * </pre>
     * @param bytes A byte array used to create a byte array declaration
     * @param name Name to be used in the byte array declaration
     * @return The formatted byte array declaration
     */
    public static String createByteArray(byte[] bytes, String name) {
        StringBuilder sb = new StringBuilder(bytes.length * 5);
        Formatter fmt = new Formatter(sb);
        fmt.format("    public static byte[] %s = {", name);
        final int linelen = 8;
        for (int i = 0; i < bytes.length; i++) {
            if (i % linelen == 0) {
                fmt.format("%n        ");
            }
            fmt.format(" (byte) 0x%x,", bytes[i] & 0xff);
        }
        fmt.format("%n    };%n");
        return sb.toString();
    }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13537#issuecomment-1516672731

From naoto at openjdk.org  Thu Apr 20 17:13:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Apr 2023 17:13:50 GMT
Subject: RFR: 8306031: Update IANA Language Subtag Registry to Version
 2023-04-13 [v4]
In-Reply-To: <4-zyZv_-bDaqfjsOI6cKOq-GVRC-RTrBeDk2xDEkZzg=.8d0e7bfc-c347-4b88-b4fc-7049c958eab3@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
 <4-zyZv_-bDaqfjsOI6cKOq-GVRC-RTrBeDk2xDEkZzg=.8d0e7bfc-c347-4b88-b4fc-7049c958eab3@github.com>
Message-ID: <7LNRN900bp0xLdD5znt3XSjJeF0f1Hs-MT_PQpBvPUc=.e7bd6a6c-e821-4a90-8604-11bfcfa02012@github.com>

On Thu, 20 Apr 2023 06:36:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
>> 
>> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
>> 
>> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
>> 
>> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
>> 
>> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
>> 
>> 
>> ...
>> singleEquivMap.put("ar-ajp", "ajp");
>> singleEquivMap.put("ajp", "ar-ajp");
>> ...
>> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
>> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
>> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
>> ...
>> 
>> 
>> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
>> 
>> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
>> 
>> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
>> 
>> To address this, the build process must be adjusted so that the equivalencies are built as 
>> 
>> 
>> ...
>> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
>> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
>> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
>> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
>> ...
>> 
>> 
>> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Hash map should be initialized with numMappings

Much better. Some comments follow.

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 40:

> 38: import java.util.Locale;
> 39: import java.util.Map;
> 40: import java.util.regex.Pattern;

Nit: sort the imports

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 143:

> 141:                 // eg: ar-ajp has pref ajp which has pref apc
> 142:                 boolean foundInOther = false;
> 143:                 Pattern pattern = Pattern.compile("\\b"+preferred+"\\b");

I think we should explicitly find a pattern with `,` instead of the word boundary. Otherwise, it could match `-` in a tag.

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 289:

> 287:                 + sortedLanguageMap2.size() + ");\n"
> 288:                 + "        regionVariantEquivMap = HashMap.newHashMap("
> 289:                 + sortedRegionVariantMap.size() + ");\n\n"

It'd be nice if these messy concatenated strings be converted to a text block, but that would be for another day.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13501#pullrequestreview-1394424712
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1172870938
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1172876231
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1172878602

From asotona at openjdk.org  Thu Apr 20 17:21:49 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 20 Apr 2023 17:21:49 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v7]
In-Reply-To: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
Message-ID: <kVzHUgEgrgzBeLRxUV48jhUE03N8ax72wu4gEhYxqU4=.d5c61838-6d26-4a32-ad97-108fb2263896@github.com>

> Classfile API didn't handle transformations of class files version 50 and below correctly. 
> 
> Proposed fix have two parts: 
> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
> 2. StackMapTable attribute is not generated for class file versions below 50.
> 
> StackMapsTest is also extended to test this patch.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed stack counting of JSR instructions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13478/files
  - new: https://git.openjdk.org/jdk/pull/13478/files/3d74c2fd..c1f3e290

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=05-06

  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13478/head:pull/13478

PR: https://git.openjdk.org/jdk/pull/13478

From naoto at openjdk.org  Thu Apr 20 18:16:43 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Apr 2023 18:16:43 GMT
Subject: RFR: 8305207: Calendar.aggregateStamp(int,
 int) return value can be simplified
In-Reply-To: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>
References: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>
Message-ID: <T0XKzBJvxU-olkDrd-ZAZT8K_9VUlJRx-YF5tweSvwg=.f2fde09c-5c71-40af-b1cb-e34579214c12@github.com>

On Thu, 20 Apr 2023 06:32:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Small cleanup / tweak spotted in Calendar to improve readability.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13554#pullrequestreview-1394532604

From rriggs at openjdk.org  Thu Apr 20 18:20:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Apr 2023 18:20:44 GMT
Subject: RFR: 8305207: Calendar.aggregateStamp(int,
 int) return value can be simplified
In-Reply-To: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>
References: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>
Message-ID: <NEKB5puIc4AjPREBiOJQuPJI4uFSlmUJEG3j-tADVy4=.15d6c985-daae-4c21-a3a4-5fc7da18431e@github.com>

On Thu, 20 Apr 2023 06:32:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Small cleanup / tweak spotted in Calendar to improve readability.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13554#pullrequestreview-1394537788

From vromero at openjdk.org  Thu Apr 20 18:24:54 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 20 Apr 2023 18:24:54 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <2luQpR-ObMOKeSrv_nZ9qtdA_M1WOWqLuCBx19hR5HY=.1421ec9a-4a24-4ffe-9854-9c3a14132f83@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com>
 <vhDVxbO8kOdrvJDQNi0M-gvqjb9qpD9EKBhGPl9YXEU=.ac1dffda-0ed4-454e-9a08-84af46380d16@github.com>
 <SeEkE8PYhEdySCf8tzCopY4ilEkuUYiK-V55Zy9Aemg=.d2449ccd-aaee-4106-8757-f913aaa6160d@github.com>
 <GGEOWwx-Up225MmHNpFyvdOK6-dlhZE1OVUjx3wGzvA=.c6294dd0-a352-4aa0-a2cc-ab4bcb56f982@github.com>
 <-LVQqa8s0ItYV8ckL06FtOHjo5pOe-g66JNi7yPmhVI=.33d74c7e-0232-4047-9cde-4a5af12eea61@github.com>
 <2luQpR-ObMOKeSrv_nZ9qtdA_M1WOWqLuCBx19hR5HY=.1421ec9a-4a24-4ffe-9854-9c3a14132f83@github.com>
Message-ID: <PAj3g47irJbsLcDlIuhwVKEBuabPPcZNy9pVTHkQP5A=.5cc8c8a2-7cd5-4c07-a344-6774cfda6374@github.com>

On Thu, 20 Apr 2023 17:08:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> That's in my upcoming update.
>
> The startIndex checks are part of this change:
> https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9
> 
> Thanks for the comment!

Oh I see, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172946111

From vromero at openjdk.org  Thu Apr 20 18:27:56 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 20 Apr 2023 18:27:56 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v2]
In-Reply-To: <DttthPwlFDMrZCqKgseRiWeqSbXblQ9g-He4xZ3f7F8=.cf5938c7-9a63-47b5-a28e-ee2b1359a2bc@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <M0bYx5BBRWJoXHPVAUym9iqJ5qt4zoVn749ThZHos6Y=.83198572-6788-4018-be5c-aa65031fc1be@github.com>
 <-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com>
 <vhDVxbO8kOdrvJDQNi0M-gvqjb9qpD9EKBhGPl9YXEU=.ac1dffda-0ed4-454e-9a08-84af46380d16@github.com>
 <SeEkE8PYhEdySCf8tzCopY4ilEkuUYiK-V55Zy9Aemg=.d2449ccd-aaee-4106-8757-f913aaa6160d@github.com>
 <GGEOWwx-Up225MmHNpFyvdOK6-dlhZE1OVUjx3wGzvA=.c6294dd0-a352-4aa0-a2cc-ab4bcb56f982@github.com>
 <DttthPwlFDMrZCqKgseRiWeqSbXblQ9g-He4xZ3f7F8=.cf5938c7-9a63-47b5-a28e-ee2b1359a2bc@github.com>
Message-ID: <TFzS6N1Ggdw1_MJlgk6PUhKZMA0PDpd2PWFDLeChN4g=.ecb3d9d0-5efa-4857-94f8-244b72d09dd9@github.com>

On Thu, 20 Apr 2023 16:54:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> could you explain a bit more the relation between `lazyDoEnumSwitch` and `doEnumSwitch` because my understanding is that `lazyDoEnumSwitch` is invoking `doEnumSwitch` so to me whenever `lazyDoEnumSwitch` is invoked there will be an immediate invocation of `doEnumSwitch` that's why I thought they could be folded together
>
> So, when the `enumSwitch` bootstrap is called, the enum class may or may not be initialized. So, to avoid initialization, we only do lightweight checks, and construct a `MutableCallSite` with `lazyDoEnumSwitch` as a target.
> 
> When the `CallSite` is invoked with an actual selector value, two options may arise:
> a) the selector value is null. The `lazyDoEnumSwitch` itself returns -1.
> b) the selector value is not null. The enum class must already be initialized (I believe). So, we create (hopefully) better structure to do the categorization, based on `doEnumSwitch`, and set that into the `CallSite`. Further calls will use this new `doEnumSwitch` based categorization directly, without calling `lazyDoEnumSwitch`. The current call will manually delegate to the `doEnumSwitch` version, but that should only happen "once" (or a small number of times, due to running in different threads, etc.).

I see, thanks for the explanation, this is nice

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172949033

From lmesnik at openjdk.org  Thu Apr 20 18:40:52 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 20 Apr 2023 18:40:52 GMT
Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when
 using an OutputAnalyzer at the same time [v2]
In-Reply-To: <du3xsDH63bi1NGWbIDvL8FwkAyFGFo1y4KkUy88PB6o=.02e4325c-6cac-4da5-b1f1-6162cf6606ca@github.com>
References: <du3xsDH63bi1NGWbIDvL8FwkAyFGFo1y4KkUy88PB6o=.02e4325c-6cac-4da5-b1f1-6162cf6606ca@github.com>
Message-ID: <NKo4-mXp6trywHjwmN3unh2kxaeHy_i2r8aGMLm3ePk=.ee5cb1ed-9ea1-4587-84c7-9f48e166ab2b@github.com>

> ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams.
> 
> This fix preserve process streams content and allow to read it after process completion. The another possible solution would be to throw exception when user tries to read already drained streams to fail tests earlier. However it complicates usage of ProcessTools.startProcess() methods.
> 
> The regression test has been provided with issue.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  JStackStressTest.java updated.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13560/files
  - new: https://git.openjdk.org/jdk/pull/13560/files/c1534166..38d82fa5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13560&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13560&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13560.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13560/head:pull/13560

PR: https://git.openjdk.org/jdk/pull/13560

From naoto at openjdk.org  Thu Apr 20 18:52:37 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Apr 2023 18:52:37 GMT
Subject: RFR: 8304836: Make MALLOC_MIN4 macro more robust
Message-ID: <IyZnv9X8fFGbxKskxf6t-fDnui9npQ1B-jBGkLjqZJc=.f07d4469-f9db-4081-9ed5-6b3cba2e1795@github.com>

The current macro assumes the argument is `jint` because all locations pass `jint`. However, this would not work if a wider type such as `jlong` is passed. Removing the `unsigned` cast and make the condition explicit would make the macro more robust.

-------------

Commit messages:
 - 8304836: Make MALLOC_MIN4 macro more robust

Changes: https://git.openjdk.org/jdk/pull/13564/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13564&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304836
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13564.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13564/head:pull/13564

PR: https://git.openjdk.org/jdk/pull/13564

From rriggs at openjdk.org  Thu Apr 20 18:59:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Apr 2023 18:59:44 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions
In-Reply-To: <689URy0mqJMJ_339lBAJeTbAJgh1rzPs9ZGBBk2CK34=.c1f164ef-fc58-47ba-bd60-f95c449f31f8@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <689URy0mqJMJ_339lBAJeTbAJgh1rzPs9ZGBBk2CK34=.c1f164ef-fc58-47ba-bd60-f95c449f31f8@github.com>
Message-ID: <5OVwvKvQLrR3V9eZ8gSsH78k7G4ehnb7zxQ2srjo98w=.7bd6b372-34ac-4b4b-a2d2-d03959ec795b@github.com>

On Thu, 20 Apr 2023 10:57:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> src/java.base/share/classes/java/io/ObjectInputStream.java line 2142:
> 
>> 2140:         int len = bin.readInt();
>> 2141:         if (len < 0) {
>> 2142:             throw new InvalidClassException(desc.getName(), "Array length < 0 (" + len + ")");
> 
> Suggestion:
> 
>             throw new InvalidClassException(desc.getName(), "Array length (" + len + ") is negative");

I'd keep the exception logic simple/minimal.  Especially since this is a manual and exceptional case that is not the result of any input provided through an API.

throw new InvalidClassException(desc.getName(), "Array length is negative");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1172965774

From rriggs at openjdk.org  Thu Apr 20 18:59:45 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Apr 2023 18:59:45 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions
In-Reply-To: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
Message-ID: <5VrcYF_OlOjJMuwDhVCVZSRIoCPxyVOs-eIke7nBljE=.07263973-1880-44d4-8fe6-6e9a12d96e4d@github.com>

On Wed, 19 Apr 2023 16:47:33 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
> 
> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
> 
> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
> 
> Returns:
> the non-negative number of array elements when deserializing an array of the class, otherwise -1
> 
> but currently returns a negative value if the array length is negative.

test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 59:

> 57:             if (serializedData[i] == 0x78) {
> 58:                 firstPos = i;
> 59:                 break;

Move setting the length code (lines 64-67) here and return immediately.

test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 62:

> 60:             }
> 61:         }
> 62: 

The test should fail if it falls through without finding the BLOCKDATA. Just a double guard against the unexpected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1172973558
PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1172974579

From iris at openjdk.org  Thu Apr 20 19:01:43 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 20 Apr 2023 19:01:43 GMT
Subject: RFR: 8305207: Calendar.aggregateStamp(int,
 int) return value can be simplified
In-Reply-To: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>
References: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>
Message-ID: <Ka7AZHzAbavPByUYrqFLJ_ouFwy4KACth0DHcljBTo4=.0149ae8a-58b2-4947-9a43-63b3d4c8df1d@github.com>

On Thu, 20 Apr 2023 06:32:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Small cleanup / tweak spotted in Calendar to improve readability.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13554#pullrequestreview-1394591566

From jlu at openjdk.org  Thu Apr 20 20:18:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 20:18:30 GMT
Subject: RFR: 8306031: Update IANA Language Subtag Registry to Version
 2023-04-13 [v5]
In-Reply-To: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
Message-ID: <TuoYTf_tqxtmJeU3CWaNiGxQ6ka7UGZznMInYpGKw6A=.6e34ee8c-8cc3-4462-8443-aa4c8a1dd017@github.com>

> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
> 
> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
> 
> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
> 
> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
> 
> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
> 
> 
> ...
> singleEquivMap.put("ar-ajp", "ajp");
> singleEquivMap.put("ajp", "ar-ajp");
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
> ...
> 
> 
> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
> 
> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
> 
> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
> 
> To address this, the build process must be adjusted so that the equivalencies are built as 
> 
> 
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
> ...
> 
> 
> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Match on exact pattern

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13501/files
  - new: https://git.openjdk.org/jdk/pull/13501/files/7d3021a4..c3046627

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13501&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13501&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13501.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13501/head:pull/13501

PR: https://git.openjdk.org/jdk/pull/13501

From jlu at openjdk.org  Thu Apr 20 20:18:36 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 20:18:36 GMT
Subject: RFR: 8306031: Update IANA Language Subtag Registry to Version
 2023-04-13 [v4]
In-Reply-To: <7LNRN900bp0xLdD5znt3XSjJeF0f1Hs-MT_PQpBvPUc=.e7bd6a6c-e821-4a90-8604-11bfcfa02012@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
 <4-zyZv_-bDaqfjsOI6cKOq-GVRC-RTrBeDk2xDEkZzg=.8d0e7bfc-c347-4b88-b4fc-7049c958eab3@github.com>
 <7LNRN900bp0xLdD5znt3XSjJeF0f1Hs-MT_PQpBvPUc=.e7bd6a6c-e821-4a90-8604-11bfcfa02012@github.com>
Message-ID: <Xfpq10GV_IBIC21y2LNe2ogoozmzseDYXeUyteBGdSc=.f7e60e83-b467-4bcc-af7c-5b55a5b77acb@github.com>

On Thu, 20 Apr 2023 17:06:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Hash map should be initialized with numMappings
>
> make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 143:
> 
>> 141:                 // eg: ar-ajp has pref ajp which has pref apc
>> 142:                 boolean foundInOther = false;
>> 143:                 Pattern pattern = Pattern.compile("\\b"+preferred+"\\b");
> 
> I think we should explicitly find a pattern with `,` instead of the word boundary. Otherwise, it could match `-` in a tag.

Good point, changed it to match starting with `,` and ending with `,` or end of string boundary

> make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 289:
> 
>> 287:                 + sortedLanguageMap2.size() + ");\n"
>> 288:                 + "        regionVariantEquivMap = HashMap.newHashMap("
>> 289:                 + sortedRegionVariantMap.size() + ");\n\n"
> 
> It'd be nice if these messy concatenated strings be converted to a text block, but that would be for another day.

Will file a separate JBS issue for this

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1173046730
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1173047129

From jlu at openjdk.org  Thu Apr 20 20:22:39 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 20:22:39 GMT
Subject: RFR: 8306031: Update IANA Language Subtag Registry to Version
 2023-04-13 [v6]
In-Reply-To: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
Message-ID: <RXLecczBt_joz0R9SFMGI79wlPl2OWqA0Ca-m5qdmwk=.b3be3427-ab9c-43d3-950b-6546ebb8c363@github.com>

> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
> 
> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
> 
> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
> 
> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
> 
> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
> 
> 
> ...
> singleEquivMap.put("ar-ajp", "ajp");
> singleEquivMap.put("ajp", "ar-ajp");
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
> ...
> 
> 
> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
> 
> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
> 
> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
> 
> To address this, the build process must be adjusted so that the equivalencies are built as 
> 
> 
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
> ...
> 
> 
> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Import ordering

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13501/files
  - new: https://git.openjdk.org/jdk/pull/13501/files/c3046627..b03a51c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13501&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13501&range=04-05

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13501.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13501/head:pull/13501

PR: https://git.openjdk.org/jdk/pull/13501

From jlu at openjdk.org  Thu Apr 20 21:14:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 21:14:00 GMT
Subject: Integrated: 4737887: (cal) API: Calendar methods taking field should
 document exceptions
In-Reply-To: <y65woSohxKGbyGcuLxE9cKokT7YMJIl0uOPpeTiUT0o=.cfdee99e-067b-4139-9802-81def6b81797@github.com>
References: <y65woSohxKGbyGcuLxE9cKokT7YMJIl0uOPpeTiUT0o=.cfdee99e-067b-4139-9802-81def6b81797@github.com>
Message-ID: <YWO-Xi8H9rqmsWtrjIVxmkmFwuKhgpRArZO8RJLH190=.ee1becb7-eb50-427a-8b2e-b7a60214f292@github.com>

On Wed, 29 Mar 2023 22:04:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Many Calendar methods that take in a field parameter should document that they throw an ArrayIndexOutOfBoundsException if field is not between 0 and `Calendar.FIELD_COUNT`.
> 
> This PR adds a clause to the class description to make the above apparent.
> 
> `Calendar.Roll(int, int)`, `Calendar.roll(int, boolean)`, and `Calendar.add(int, int)` should all be documented that they throw an `IllegalArgumentException` if any calendar fields have out-of-range values in non-lenient mode or if field is
> `Calendar.ZONE_OFFSET`, `Calendar.DST_OFFSET`, or unknown.

This pull request has now been integrated.

Changeset: 174c1a6d
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/174c1a6d53d3ea95649a511f4088c7807d80b59b
Stats:     20 lines in 1 file changed: 13 ins; 5 del; 2 mod

4737887: (cal) API: Calendar methods taking field should document exceptions

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/13234

From lbourges at openjdk.org  Thu Apr 20 21:17:44 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 20 Apr 2023 21:17:44 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
Message-ID: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>

* Optimized mixed insertion sort
    * Optimized insertion sort
    * Optimized Radix sort
    * Updated microbenchmark

I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938

-------------

Commit messages:
 - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)

Changes: https://git.openjdk.org/jdk/pull/13568/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8266431
  Stats: 4022 lines in 4 files changed: 1747 ins; 1272 del; 1003 mod
  Patch: https://git.openjdk.org/jdk/pull/13568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13568/head:pull/13568

PR: https://git.openjdk.org/jdk/pull/13568

From jlu at openjdk.org  Thu Apr 20 21:22:56 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 21:22:56 GMT
Subject: Integrated: 8305207: Calendar.aggregateStamp(int,
 int) return value can be simplified
In-Reply-To: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>
References: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>
Message-ID: <qPo4XzjQrD5BQ56LJS7qjHeapq5-1uXjAII70xS_iOQ=.4c635786-a350-4c8d-b632-98d43248837a@github.com>

On Thu, 20 Apr 2023 06:32:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Small cleanup / tweak spotted in Calendar to improve readability.

This pull request has now been integrated.

Changeset: ffb2494d
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ffb2494de488b77fd017c04531b103d695909c2f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8305207: Calendar.aggregateStamp(int, int) return value can be simplified

Reviewed-by: naoto, rriggs, iris

-------------

PR: https://git.openjdk.org/jdk/pull/13554

From lbourges at openjdk.org  Thu Apr 20 21:44:44 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 20 Apr 2023 21:44:44 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
In-Reply-To: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
Message-ID: <3xbc0tfYUypMHk1Tje2FG7d_Iq_SxulkH6D0ziXRuRo=.713589b6-49d5-4855-80e1-b9650d7e61d2@github.com>

On Thu, 20 Apr 2023 21:05:55 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> * Optimized mixed insertion sort
>     * Optimized insertion sort
>     * Optimized Radix sort
>     * Updated microbenchmark
> 
> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938

Here are JMH ArraysSort benchmark results on openjdk20 (23.03.27):
https://jmh.morethan.io/?sources=https://raw.githubusercontent.com/bourgesl/bourgesl.github.io/master/jdk-jmh-arraysort/230326/openjdk20-master-230326.json,https://raw.githubusercontent.com/bourgesl/bourgesl.github.io/master/jdk-jmh-arraysort/230326/openjdk20-patched-jmh-result-230326.json

I will run again benchmarks on latest master vs PR tomorrow

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1516980296

From lbourges at openjdk.org  Thu Apr 20 22:04:42 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 20 Apr 2023 22:04:42 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v2]
In-Reply-To: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
Message-ID: <FHDv8N7EtG41hRba7g3wvamSWxTXhZIl6way7dyAKlY=.902194ba-85ac-4808-8801-82846a1ff1dd@github.com>

> * Optimized mixed insertion sort
>     * Optimized insertion sort
>     * Optimized Radix sort
>     * Updated microbenchmark
> 
> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938

Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:

  optimized radix sort heuristic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13568/files
  - new: https://git.openjdk.org/jdk/pull/13568/files/246ea875..32551f60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=00-01

  Stats: 48 lines in 1 file changed: 4 ins; 0 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/13568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13568/head:pull/13568

PR: https://git.openjdk.org/jdk/pull/13568

From cjplummer at openjdk.org  Thu Apr 20 22:35:47 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Apr 2023 22:35:47 GMT
Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when
 using an OutputAnalyzer at the same time [v2]
In-Reply-To: <NKo4-mXp6trywHjwmN3unh2kxaeHy_i2r8aGMLm3ePk=.ee5cb1ed-9ea1-4587-84c7-9f48e166ab2b@github.com>
References: <du3xsDH63bi1NGWbIDvL8FwkAyFGFo1y4KkUy88PB6o=.02e4325c-6cac-4da5-b1f1-6162cf6606ca@github.com>
 <NKo4-mXp6trywHjwmN3unh2kxaeHy_i2r8aGMLm3ePk=.ee5cb1ed-9ea1-4587-84c7-9f48e166ab2b@github.com>
Message-ID: <-G9WskHyBL-VvD-95BHoWsSn9cSiQc5mpUayH2_rUBM=.638204df-fa19-4c70-b51e-d4c7b1eb8290@github.com>

On Thu, 20 Apr 2023 18:40:52 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams.
>> 
>> This fix preserve process streams content and allow to read it after process completion. The another possible solution would be to throw exception when user tries to read already drained streams to fail tests earlier. However it complicates usage of ProcessTools.startProcess() methods.
>> 
>> The regression test has been provided with issue.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JStackStressTest.java updated.

test/jdk/sun/tools/jhsdb/JStackStressTest.java line 86:

> 84:             } catch (InterruptedException e) {
> 85:             }
> 86:             OutputAnalyzer jshellOutput = new OutputAnalyzer(jShellProcess);

It's not clear to me how moving this is fixing anything.

test/jdk/sun/tools/jstatd/JstatdTest.java line 357:

> 355:         assertEquals(stdout.size(), 1, "Output should contain one line");
> 356:         assertTrue(stdout.get(0).startsWith("jstatd started"), "List should start with 'jstatd started'");
> 357:         assertNotEquals(output.getExitValue(), 0,

Before your fix, was the "jstatd started" line being missed because of this bug.

test/lib/jdk/test/lib/process/ProcessTools.java line 750:

> 748:         public InputStream getInputStream() {
> 749:             try {
> 750:                 waitFor();

With this added `waitFor()` the assumption now is that the caller doesn't intent to do incremental reads of the output as the process generates it. For example, if the test were to send some command to the process and then want to read the resulting output, and do this repeatedly, it won't able to use the InputStream to do that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13560#discussion_r1173141642
PR Review Comment: https://git.openjdk.org/jdk/pull/13560#discussion_r1173139688
PR Review Comment: https://git.openjdk.org/jdk/pull/13560#discussion_r1173146951

From dholmes at openjdk.org  Thu Apr 20 22:57:45 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Apr 2023 22:57:45 GMT
Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when
 using an OutputAnalyzer at the same time [v2]
In-Reply-To: <-G9WskHyBL-VvD-95BHoWsSn9cSiQc5mpUayH2_rUBM=.638204df-fa19-4c70-b51e-d4c7b1eb8290@github.com>
References: <du3xsDH63bi1NGWbIDvL8FwkAyFGFo1y4KkUy88PB6o=.02e4325c-6cac-4da5-b1f1-6162cf6606ca@github.com>
 <NKo4-mXp6trywHjwmN3unh2kxaeHy_i2r8aGMLm3ePk=.ee5cb1ed-9ea1-4587-84c7-9f48e166ab2b@github.com>
 <-G9WskHyBL-VvD-95BHoWsSn9cSiQc5mpUayH2_rUBM=.638204df-fa19-4c70-b51e-d4c7b1eb8290@github.com>
Message-ID: <h3VcXVqlj5srzIc2Hv6ZlQjISds7n6dJVfy5lvgdne8=.23c9fc9a-ff09-40a2-b7a1-cc64a2866e0b@github.com>

On Thu, 20 Apr 2023 22:31:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JStackStressTest.java updated.
>
> test/lib/jdk/test/lib/process/ProcessTools.java line 750:
> 
>> 748:         public InputStream getInputStream() {
>> 749:             try {
>> 750:                 waitFor();
> 
> With this added `waitFor()` the assumption now is that the caller doesn't intent to do incremental reads of the output as the process generates it. For example, if the test were to send some command to the process and then want to read the resulting output, and do this repeatedly, it won't able to use the InputStream to do that.

I have to agree with Chris. You are changing a fundamental property of this API. We no longer just start the process, we are forced to wait for it to complete.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13560#discussion_r1173158259

From lmesnik at openjdk.org  Thu Apr 20 23:05:45 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 20 Apr 2023 23:05:45 GMT
Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when
 using an OutputAnalyzer at the same time [v2]
In-Reply-To: <-G9WskHyBL-VvD-95BHoWsSn9cSiQc5mpUayH2_rUBM=.638204df-fa19-4c70-b51e-d4c7b1eb8290@github.com>
References: <du3xsDH63bi1NGWbIDvL8FwkAyFGFo1y4KkUy88PB6o=.02e4325c-6cac-4da5-b1f1-6162cf6606ca@github.com>
 <NKo4-mXp6trywHjwmN3unh2kxaeHy_i2r8aGMLm3ePk=.ee5cb1ed-9ea1-4587-84c7-9f48e166ab2b@github.com>
 <-G9WskHyBL-VvD-95BHoWsSn9cSiQc5mpUayH2_rUBM=.638204df-fa19-4c70-b51e-d4c7b1eb8290@github.com>
Message-ID: <T9uvsw43C0eiykJJVQQcXd5zZXe9r3KsBB_VbWT7WKg=.8bed6768-3266-4883-aaf0-9455957f7091@github.com>

On Thu, 20 Apr 2023 22:22:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JStackStressTest.java updated.
>
> test/jdk/sun/tools/jhsdb/JStackStressTest.java line 86:
> 
>> 84:             } catch (InterruptedException e) {
>> 85:             }
>> 86:             OutputAnalyzer jshellOutput = new OutputAnalyzer(jShellProcess);
> 
> It's not clear to me how moving this is fixing anything.

It is the main issues with current approach. The outputanalyzer tries to read from streams which are available only when process finishes. This test interact with process so it just hangs waiting of process completion.

> test/jdk/sun/tools/jstatd/JstatdTest.java line 357:
> 
>> 355:         assertEquals(stdout.size(), 1, "Output should contain one line");
>> 356:         assertTrue(stdout.get(0).startsWith("jstatd started"), "List should start with 'jstatd started'");
>> 357:         assertNotEquals(output.getExitValue(), 0,
> 
> Before your fix, was the "jstatd started" line being missed because of this bug.

Yep. the output was "empty" before fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13560#discussion_r1173155279
PR Review Comment: https://git.openjdk.org/jdk/pull/13560#discussion_r1173155433

From lmesnik at openjdk.org  Thu Apr 20 23:05:48 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 20 Apr 2023 23:05:48 GMT
Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when
 using an OutputAnalyzer at the same time [v2]
In-Reply-To: <h3VcXVqlj5srzIc2Hv6ZlQjISds7n6dJVfy5lvgdne8=.23c9fc9a-ff09-40a2-b7a1-cc64a2866e0b@github.com>
References: <du3xsDH63bi1NGWbIDvL8FwkAyFGFo1y4KkUy88PB6o=.02e4325c-6cac-4da5-b1f1-6162cf6606ca@github.com>
 <NKo4-mXp6trywHjwmN3unh2kxaeHy_i2r8aGMLm3ePk=.ee5cb1ed-9ea1-4587-84c7-9f48e166ab2b@github.com>
 <-G9WskHyBL-VvD-95BHoWsSn9cSiQc5mpUayH2_rUBM=.638204df-fa19-4c70-b51e-d4c7b1eb8290@github.com>
 <h3VcXVqlj5srzIc2Hv6ZlQjISds7n6dJVfy5lvgdne8=.23c9fc9a-ff09-40a2-b7a1-cc64a2866e0b@github.com>
Message-ID: <_dsCvusmXp4WGZ-9RZiihf92Rqd0_lX-udKls-ZGKnE=.6c09a4d0-e5ae-4676-89c3-9206213d4628@github.com>

On Thu, 20 Apr 2023 22:54:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/lib/jdk/test/lib/process/ProcessTools.java line 750:
>> 
>>> 748:         public InputStream getInputStream() {
>>> 749:             try {
>>> 750:                 waitFor();
>> 
>> With this added `waitFor()` the assumption now is that the caller doesn't intent to do incremental reads of the output as the process generates it. For example, if the test were to send some command to the process and then want to read the resulting output, and do this repeatedly, it won't able to use the InputStream to do that.
>
> I have to agree with Chris. You are changing a fundamental property of this API. We no longer just start the process, we are forced to wait for it to complete.

Exactly. I added note about implementation in the javadoc to make it clear. I don't see any good solution for this problem.
The only other possible solution which I see is to throw Exception here, forcing user to use lineConsumer. 

However the any usage of OutputAnalyzer with startProcess() would clearly and quickly fails.

Also, the 
    public static Process startProcess(String name,
                                       ProcessBuilder processBuilder)
could be modified to allow to read process streams. The test should drain tests by itself in such case to avoid hang. 

However, it don't see any good way to implement this method correctly if already read the process streams.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13560#discussion_r1173161520

From smarks at openjdk.org  Thu Apr 20 23:37:53 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 20 Apr 2023 23:37:53 GMT
Subject: RFR: 8266571: Sequenced Collections [v9]
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: <feTjroENXtX3Ssc_2dS_qwc4qDjMULyDwLZDTzroLew=.4b9b764e-e189-4416-b010-3f07b20a8f94@github.com>

> PR for Sequenced Collections implementation.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Delegate more methods in the views of ReverseOrderSortedMapView.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7387/files
  - new: https://git.openjdk.org/jdk/pull/7387/files/79747247..b59f8dda

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=07-08

  Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/7387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/7387/head:pull/7387

PR: https://git.openjdk.org/jdk/pull/7387

From jvernee at openjdk.org  Fri Apr 21 00:25:57 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 21 Apr 2023 00:25:57 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v6]
In-Reply-To: <A0Yb6AXcRLSq69LEQLmgdimBzBBa-wYF_TP0N76-VVM=.5780da13-a414-4f2b-a754-7f3f9f2dfc73@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
 <BS09rPZXEqgvig3E1sM6foHnEzF7c56HxyhuM-ufgdM=.4d2e50df-906f-4f20-a011-9a83313344c9@github.com>
 <A0Yb6AXcRLSq69LEQLmgdimBzBBa-wYF_TP0N76-VVM=.5780da13-a414-4f2b-a754-7f3f9f2dfc73@github.com>
Message-ID: <W7vz2-qzQXY8LEdBIJm7UoPKJisw1-CcT4khUWPDocQ=.89fc3c33-3bd6-4298-ad4c-29dd758c3b83@github.com>

On Thu, 20 Apr 2023 09:27:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - restrictions -> characteristics
>>  - polish pt. 2
>>  - polish wording
>>  - review comments
>
> Looks good.
> 
> One (optional, for future?) thing that came to mind, is that if we wanted to speed up the check we could compute whether a layout is canonical or not on construction (since for structs we already have to go through all the elements and check alignment).

@mcimadamore Thanks for the review!

I've created a CSR with the finalized javadoc here: https://bugs.openjdk.org/browse/JDK-8306631 Could you review that as well? TIA

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13164#issuecomment-1517090854

From duke at openjdk.org  Fri Apr 21 00:35:44 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Fri, 21 Apr 2023 00:35:44 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v3]
In-Reply-To: <Ika8MWyIi6jGiwbn3b2c6pKQI2xWskdN9d-HeprcJKU=.88ae32bd-f559-4029-bb7e-8bcf0e941119@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <Ika8MWyIi6jGiwbn3b2c6pKQI2xWskdN9d-HeprcJKU=.88ae32bd-f559-4029-bb7e-8bcf0e941119@github.com>
Message-ID: <qWyHtYGwtZjn_9U3SMqXBwphWPqtPa9ah7b4NEAQhpY=.2b72d3ca-dbd4-4de8-85c3-8a28f0455d49@github.com>

On Thu, 20 Apr 2023 04:16:13 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

>> I fixed File.listRoots description.
>> * remove "the insertion or ejection of removable media"
>> * change "available" to "existing"
>> 
>> Please review this change.
>
> Nagata-Haruhito has 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 two new commits since the last revision:
> 
>  - 8306431: The documentation of File.listRoots should be modifid after JDK-8208077
>  - 8306431: File.listRoots method description should be re-examined

Sorry for miss operation. I changed PR title.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13526#issuecomment-1517096268

From jvernee at openjdk.org  Fri Apr 21 00:45:57 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 21 Apr 2023 00:45:57 GMT
Subject: RFR: 8305093: Linker cache should not take layout names into account
Message-ID: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>

Strip names from the function descriptors used in linkage requests. The names are not important for classification, and this will allow the cached MethodHandle/UpcallStubFactory to be shared across linkage request with the same structure, but with layouts that have different names.

I also have another implementation that avoids copying all the layouts, and instead re-implemented equals and hashCode in the LinkRequest wrapper: https://github.com/openjdk/jdk/compare/pr/13079...JornVernee:jdk:NoNameCache But, this seems too complex. Linking code is not very performance sensitive, so I instead went with a simpler approach in this patch.

-------------

Depends on: https://git.openjdk.org/jdk/pull/13079

Commit messages:
 - re-add spuriously removed blank line
 - stripNames based caching

Changes: https://git.openjdk.org/jdk/pull/13562/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13562&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305093
  Stats: 93 lines in 2 files changed: 88 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13562/head:pull/13562

PR: https://git.openjdk.org/jdk/pull/13562

From jvernee at openjdk.org  Fri Apr 21 00:45:59 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 21 Apr 2023 00:45:59 GMT
Subject: RFR: 8305093: Linker cache should not take layout names into
 account
In-Reply-To: <zzBLdw7iOKSuHLakDekGXfJTJpmPoz_0LT8Lc09Aa94=.d156283b-dc95-44c8-9618-9f68b43112f8@github.com>
References: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
 <zzBLdw7iOKSuHLakDekGXfJTJpmPoz_0LT8Lc09Aa94=.d156283b-dc95-44c8-9618-9f68b43112f8@github.com>
Message-ID: <tG82JAB0vk7LWrHcRVoE3CpxJH-CLQ8aB45tp4gZ2B4=.224c5bdf-9516-494d-bf5e-0479c95d6410@github.com>

On Thu, 20 Apr 2023 19:29:40 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Strip names from the function descriptors used in linkage requests. The names are not important for classification, and this will allow the cached MethodHandle/UpcallStubFactory to be shared across linkage request with the same structure, but with layouts that have different names.
>> 
>> I also have another implementation that avoids copying all the layouts, and instead re-implemented equals and hashCode in the LinkRequest wrapper: https://github.com/openjdk/jdk/compare/pr/13079...JornVernee:jdk:NoNameCache But, this seems too complex. Linking code is not very performance sensitive, so I instead went with a simpler approach in this patch.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 120:
> 
>> 118:         descriptor.argumentLayouts().forEach(AbstractLinker::checkHasNaturalAlignmentRecursive);
>> 119:     }
>> 120:     private static void checkHasNaturalAlignmentRecursive(MemoryLayout layout) {
> 
> **Nit:** restore?deleted?line between?methods:
> Suggestion:
> 
>     }
> 
>     private static void checkHasNaturalAlignmentRecursive(MemoryLayout layout) {

Yes, I noticed this as well. The PR is still a draft, so I'm still working on it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13562#discussion_r1173034927

From duke at openjdk.org  Fri Apr 21 00:45:58 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 21 Apr 2023 00:45:58 GMT
Subject: RFR: 8305093: Linker cache should not take layout names into
 account
In-Reply-To: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
References: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
Message-ID: <zzBLdw7iOKSuHLakDekGXfJTJpmPoz_0LT8Lc09Aa94=.d156283b-dc95-44c8-9618-9f68b43112f8@github.com>

On Thu, 20 Apr 2023 17:23:08 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Strip names from the function descriptors used in linkage requests. The names are not important for classification, and this will allow the cached MethodHandle/UpcallStubFactory to be shared across linkage request with the same structure, but with layouts that have different names.
> 
> I also have another implementation that avoids copying all the layouts, and instead re-implemented equals and hashCode in the LinkRequest wrapper: https://github.com/openjdk/jdk/compare/pr/13079...JornVernee:jdk:NoNameCache But, this seems too complex. Linking code is not very performance sensitive, so I instead went with a simpler approach in this patch.

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 120:

> 118:         descriptor.argumentLayouts().forEach(AbstractLinker::checkHasNaturalAlignmentRecursive);
> 119:     }
> 120:     private static void checkHasNaturalAlignmentRecursive(MemoryLayout layout) {

**Nit:** restore?deleted?line between?methods:
Suggestion:

    }

    private static void checkHasNaturalAlignmentRecursive(MemoryLayout layout) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13562#discussion_r1173005869

From jvernee at openjdk.org  Fri Apr 21 01:03:57 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 21 Apr 2023 01:03:57 GMT
Subject: RFR: 8305093: Linker cache should not take layout names into
 account [v2]
In-Reply-To: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
References: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
Message-ID: <7_Nk2AOcLFfPf5yfpg1aAW97junefRNAY857VrpS9xs=.9640e499-4b17-44bc-82ea-406fff99a9cf@github.com>

> Strip names from the function descriptors used in linkage requests. The names are not important for classification, and this will allow the cached MethodHandle/UpcallStubFactory to be shared across linkage request with the same structure, but with layouts that have different names.
> 
> I also have another implementation that avoids copying all the layouts, and instead re-implemented equals and hashCode in the LinkRequest wrapper: https://github.com/openjdk/jdk/compare/pr/13079...JornVernee:jdk:NoNameCache But, this seems too complex. Linking code is not very performance sensitive, so I instead went with a simpler approach in this patch.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  use al instead of ValueLayout.ADDRESS

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13562/files
  - new: https://git.openjdk.org/jdk/pull/13562/files/6ff4607e..cc7c4ebf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13562&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13562&range=00-01

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13562/head:pull/13562

PR: https://git.openjdk.org/jdk/pull/13562

From bchristi at openjdk.org  Fri Apr 21 01:44:43 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 21 Apr 2023 01:44:43 GMT
Subject: RFR: 8304836: Make MALLOC_MIN4 macro more robust
In-Reply-To: <IyZnv9X8fFGbxKskxf6t-fDnui9npQ1B-jBGkLjqZJc=.f07d4469-f9db-4081-9ed5-6b3cba2e1795@github.com>
References: <IyZnv9X8fFGbxKskxf6t-fDnui9npQ1B-jBGkLjqZJc=.f07d4469-f9db-4081-9ed5-6b3cba2e1795@github.com>
Message-ID: <gephqlrbn57b-n487ZqWP-tdQ4TVC3T9kV58w9YbgVg=.81bacf7c-a7e4-4aa0-ba82-bd0c4330b41c@github.com>

On Thu, 20 Apr 2023 18:39:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The current macro assumes the argument is `jint` because all locations pass `jint`. However, this would not work if a wider type such as `jlong` is passed. Removing the `unsigned` cast and make the condition explicit would make the macro more robust.

Looks fine.

-------------

Marked as reviewed by bchristi (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13564#pullrequestreview-1394947363

From jvernee at openjdk.org  Fri Apr 21 03:42:56 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 21 Apr 2023 03:42:56 GMT
Subject: RFR: 8306075: Micro-optimize Enum.hashCode [v6]
In-Reply-To: <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
 <VYcjxZ94n_FeXYrpyA1IsyEJZ7QkakBMuRxLKAv4cyI=.cfa88584-fe09-4492-81c8-095f6ec36962@github.com>
Message-ID: <eP2J8YET4y3P__AP8pD_kSeo5eSQDWZ6AyfbxThN4Mw=.eae0e944-04c4-4143-bcf2-9a2ee6be3764@github.com>

On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie <duke at openjdk.org> wrote:

>> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
>> 
>> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075). [Benchmark results and generated code analysis moved to comment]
>> 
>> Thanks @shipilev for help with the implementation and interpreting the generated code.
>
> olivergillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shuffle docs

> I've also started a tier 1-4 run of this patch on our CI. Will report back with the results.

All green

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13491#pullrequestreview-1395011994

From lmesnik at openjdk.org  Fri Apr 21 04:45:04 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 21 Apr 2023 04:45:04 GMT
Subject: Withdrawn: 8233725: ProcessTools.startProcess() has output issues when
 using an OutputAnalyzer at the same time
In-Reply-To: <du3xsDH63bi1NGWbIDvL8FwkAyFGFo1y4KkUy88PB6o=.02e4325c-6cac-4da5-b1f1-6162cf6606ca@github.com>
References: <du3xsDH63bi1NGWbIDvL8FwkAyFGFo1y4KkUy88PB6o=.02e4325c-6cac-4da5-b1f1-6162cf6606ca@github.com>
Message-ID: <OuZ10kiskK12zelRvE0vcM3YCsErvxRX-UIRzC67zTo=.6eb85527-0463-4f2e-a391-53c48ed83ebc@github.com>

On Thu, 20 Apr 2023 16:09:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams.
> 
> This fix preserve process streams content and allow to read it after process completion. The another possible solution would be to throw exception when user tries to read already drained streams to fail tests earlier. However it complicates usage of ProcessTools.startProcess() methods.
> 
> The regression test has been provided with issue.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/13560

From asotona at openjdk.org  Fri Apr 21 06:50:43 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 21 Apr 2023 06:50:43 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v7]
In-Reply-To: <kVzHUgEgrgzBeLRxUV48jhUE03N8ax72wu4gEhYxqU4=.d5c61838-6d26-4a32-ad97-108fb2263896@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <kVzHUgEgrgzBeLRxUV48jhUE03N8ax72wu4gEhYxqU4=.d5c61838-6d26-4a32-ad97-108fb2263896@github.com>
Message-ID: <3k2oVkZmbpIoztlw5RplnqQObz0eZwhNr6006NXNhwE=.279cac00-0baa-43ef-a7e7-efbf14405374@github.com>

On Thu, 20 Apr 2023 17:21:49 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API didn't handle transformations of class files version 50 and below correctly. 
>> 
>> Proposed fix have two parts: 
>> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
>> 2. StackMapTable attribute is not generated for class file versions below 50.
>> 
>> StackMapsTest is also extended to test this patch.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed stack counting of JSR instructions

I would like to separate this fix from follow-up enhancements, so I created new RFE [JDK-8306650](https://bugs.openjdk.org/browse/JDK-8306650).
This bug should be now fixed and the fix also covers Java 5 and older class files with JSR/RET instructions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13478#issuecomment-1517348244

From alanb at openjdk.org  Fri Apr 21 07:15:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Apr 2023 07:15:53 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v7]
In-Reply-To: <fan5ziVJc7mtPzcnywX4cW5KBTFzx4KKyqiTwZjy_8c=.5e7b639a-2698-48e6-8468-f7a001ea6fc4@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <vHGXWJN2gsfsb9F53ya4eVlsVctH8yUnsvJd9YnkBHI=.4f5983b9-1793-444d-a99e-c0572dac6436@github.com>
 <GjekBLa-Gdk31PYuoHL9fjZllVgyzQEfU8sn-YzLzXc=.e7b5e9e1-d09c-41ce-91d6-ad126236a763@github.com>
 <fan5ziVJc7mtPzcnywX4cW5KBTFzx4KKyqiTwZjy_8c=.5e7b639a-2698-48e6-8468-f7a001ea6fc4@github.com>
Message-ID: <YgQTEm_vqzO-kSnozUXfe75GENf4yhOjbS7hn1nl1VA=.ebd810ad-9540-49e8-a682-70df3d474124@github.com>

On Thu, 20 Apr 2023 08:12:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Thread.java line 1:
>> 
>>> 1: /*
>> 
>> Why doesn't `Thread.sleep(long millis)` simply call `Thread.sleep(millis, 0)` instead of duplicating most of the code?
>
> That would change the stack depth, for which some tests are sensitive. https://github.com/openjdk/jdk/pull/13225#issuecomment-1514461529. I think merging `sleep` implementations is something to do in a targeted cleanup, which would handle those test updates too.

One this change is in, I'd like to do some refactoring and have a private sleepNanos that the 3 sleep methods call with the nanos value. That will change the stack depth so it means a few tests need update, but we know what they are now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1173391987

From duke at openjdk.org  Fri Apr 21 08:28:45 2023
From: duke at openjdk.org (Madjosz)
Date: Fri, 21 Apr 2023 08:28:45 GMT
Subject: RFR: 8302983: ZoneRulesProvider.registerProvider() twice will
 remove provider [v4]
In-Reply-To: <32bmWmdJSojCpNplpArpbXwn6LD2qHIZSZfOccJKjC4=.9d60aeba-8ae5-40c6-ac78-241ef4002d1a@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
 <32bmWmdJSojCpNplpArpbXwn6LD2qHIZSZfOccJKjC4=.9d60aeba-8ae5-40c6-ac78-241ef4002d1a@github.com>
Message-ID: <7Ipeih3VcHURzvqdfnOJoueuhvn4IPjvDpV4YFILeyk=.e1284bb2-46ba-4733-a124-593111f83b8f@github.com>

On Tue, 28 Feb 2023 07:49:17 GMT, Madjosz <duke at openjdk.org> wrote:

>> Fixes JDK-8302983 (and duplicate JDK-8302898)
>
> Madjosz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace, remove stream()

Is this ready to merge now?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12690#issuecomment-1517466596

From duke at openjdk.org  Fri Apr 21 09:55:04 2023
From: duke at openjdk.org (olivergillespie)
Date: Fri, 21 Apr 2023 09:55:04 GMT
Subject: Integrated: 8306075: Micro-optimize Enum.hashCode
In-Reply-To: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
References: <jGRddAMSBaQJVIqmd-y-j-CQaXjDDiTQJ-clhQwYxts=.af1e06f9-9e57-4e32-9885-ab44085041ce@github.com>
Message-ID: <SdkGstIR82wvStgyKiRDaubEwrT2iqlKJAhV3rs3faA=.41def4d9-a8aa-43b2-b65a-9c76ef0f4581@github.com>

On Mon, 17 Apr 2023 10:59:34 GMT, olivergillespie <duke at openjdk.org> wrote:

> Improve the speed of Enum.hashCode by caching the identity hashcode on first use. I've seen an application where Enum.hashCode is a hot path, and this is fairly simple speedup. The memory overhead is low; in enums with no extra fields there is already a 4-byte space due to alignment so this new field can slot in 'for free'. In other cases, the singleton nature of enum values means that the number of total instances is typically very low, so a small per-instance overhead is not a concern.
> 
> Please see more discussion/explanation in the [original enhancement request](https://bugs.openjdk.org/browse/JDK-8306075). [Benchmark results and generated code analysis moved to comment]
> 
> Thanks @shipilev for help with the implementation and interpreting the generated code.

This pull request has now been integrated.

Changeset: 3da987ad
Author:    Oli Gillespie <ogillesp at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3da987adacc3acc120a2781ee9a2111e26356723
Stats:     73 lines in 2 files changed: 72 ins; 0 del; 1 mod

8306075: Micro-optimize Enum.hashCode

Co-authored-by: Aleksey Shipilev <shade at openjdk.org>
Reviewed-by: redestad, shade, rriggs, liach, apangin, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/13491

From jlahoda at openjdk.org  Fri Apr 21 10:56:55 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 21 Apr 2023 10:56:55 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v4]
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <PZBXViqw4vI2RK9quVrVW1WDOnM7KyNn6ZoNvLzYeY0=.5e215c1d-a229-41c1-a533-2ee839cf40c3@github.com>

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Replacing use of mutable callsite with a mutable state.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13074/files
  - new: https://git.openjdk.org/jdk/pull/13074/files/bb59254e..d3d9cc60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=02-03

  Stats: 44 lines in 1 file changed: 15 ins; 23 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074

PR: https://git.openjdk.org/jdk/pull/13074

From lbourges at openjdk.org  Fri Apr 21 11:58:42 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 21 Apr 2023 11:58:42 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v2]
In-Reply-To: <FHDv8N7EtG41hRba7g3wvamSWxTXhZIl6way7dyAKlY=.902194ba-85ac-4808-8801-82846a1ff1dd@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <FHDv8N7EtG41hRba7g3wvamSWxTXhZIl6way7dyAKlY=.902194ba-85ac-4808-8801-82846a1ff1dd@github.com>
Message-ID: <a_GyXFNi_2qL9zEJO4YVnmlI5XhxGymZfwxsDxzcMd0=.15d24327-eed1-4580-b057-51bcf6f0c170@github.com>

On Thu, 20 Apr 2023 22:04:42 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> * Optimized mixed insertion sort
>>     * Optimized insertion sort
>>     * Optimized Radix sort
>>     * Updated microbenchmark
>> 
>> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938
>
> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   optimized radix sort heuristic

Benchmark results:
https://github.com/bourgesl/bourgesl.github.io/tree/master/jdk-jmh-arraysort/230421

https://jmh.morethan.io/?sources=https://raw.githubusercontent.com/bourgesl/bourgesl.github.io/master/jdk-jmh-arraysort/230421/openjdk21-master-jmh-result-230421.json,https://raw.githubusercontent.com/bourgesl/bourgesl.github.io/master/jdk-jmh-arraysort/230421/openjdk21-patched-jmh-result-230421.json

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1517711027

From duke at openjdk.org  Fri Apr 21 12:47:44 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Fri, 21 Apr 2023 12:47:44 GMT
Subject: RFR: 8304836: Make MALLOC_MIN4 macro more robust
In-Reply-To: <IyZnv9X8fFGbxKskxf6t-fDnui9npQ1B-jBGkLjqZJc=.f07d4469-f9db-4081-9ed5-6b3cba2e1795@github.com>
References: <IyZnv9X8fFGbxKskxf6t-fDnui9npQ1B-jBGkLjqZJc=.f07d4469-f9db-4081-9ed5-6b3cba2e1795@github.com>
Message-ID: <gUQBxWAInmaffzG1wxw5LDgOz51RQyGMvNGE062sUiA=.ed85b349-7c33-406a-9244-0c56f05ff572@github.com>

On Thu, 20 Apr 2023 18:39:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The current macro assumes the argument is `jint` because all locations pass `jint`. However, this would not work if a wider type such as `jlong` is passed. Removing the `unsigned` cast and make the condition explicit would make the macro more robust.

src/java.base/share/native/libjava/jni_util.c line 42:

> 40:  * that overflows into negative value.
> 41:  */
> 42: #define MALLOC_MIN4(len) (len >= INT_MAX || len < 0 ? \

Should this keep the parentheses around `len` for explicit order of operations in case `len` is an expression?

Suggestion:

#define MALLOC_MIN4(len) ((len) >= INT_MAX || (len) < 0 ? \

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13564#discussion_r1173723228

From shade at openjdk.org  Fri Apr 21 13:21:09 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 21 Apr 2023 13:21:09 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v10]
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <wSCu12OAVkXv-ZM3ltW9vGs27ZkJGHDvRXuS-fJ2w8M=.11113269-945b-4b3f-a580-0cd78dbf2c95@github.com>

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'master' into JDK-83050920-thread-sleep-subms
 - Drop nanos_to_nanos_bounded
 - Handle overflows
 - More review comments
 - Adjust test times
 - Windows again
 - Windows fixes: align(...) is only for power-of-two alignments
 - Adjust assert
 - Replace (park|sleep)_millis back with just (park|sleep)
 - More review touchups
 - ... and 13 more: https://git.openjdk.org/jdk/compare/5a00617b...a0c35f45

-------------

Changes: https://git.openjdk.org/jdk/pull/13225/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=09
  Stats: 254 lines in 11 files changed: 226 ins; 9 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/13225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13225/head:pull/13225

PR: https://git.openjdk.org/jdk/pull/13225

From mchhipa at openjdk.org  Fri Apr 21 13:36:47 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Fri, 21 Apr 2023 13:36:47 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v3]
In-Reply-To: <zpnk-wC0R3qZwiWhd1umWZZZQre0DhXI_52DEGQKclQ=.71067494-6bcd-431c-8b90-ab72c0b42378@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
 <zpnk-wC0R3qZwiWhd1umWZZZQre0DhXI_52DEGQKclQ=.71067494-6bcd-431c-8b90-ab72c0b42378@github.com>
Message-ID: <4y-KQjPsCcPO-cHPrOZR2XL06zVnHjwqky5BIZOB-m0=.66bb6778-0f4d-4fca-b18b-f7aa12b94de0@github.com>

On Thu, 20 Apr 2023 10:06:33 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Test is updated to create the binary files during test execution.
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented the review comment.

Thanks for your review comments. I will implement them and push again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13537#issuecomment-1517843647

From info at j-kuhn.de  Fri Apr 21 13:44:11 2023
From: info at j-kuhn.de (Johannes Kuhn)
Date: Fri, 21 Apr 2023 15:44:11 +0200
Subject: Discussion: Prefer passing MethodHandles.Lookup over @CallerSensitive
Message-ID: <dbfe269b-78e2-5c85-9200-5d949dfe1ecf@j-kuhn.de>

Hi,

Instead of making new and existing methods @CallerSensitive, such 
methods could instead take a MethodHandles.Lookup as method argument.

Library authors are often told that they could ask their users to pass a 
MethodHandles.Lookup to obtain internal access instead of using things 
like AccessibleObject::setAccessible.

I hope OpenJDK would follow that advice as well, IMHO the broader use of 
MethodHandles.Lookup would make things easier for both OpenJDK 
deverlopers & library authors.

tl;dr: Have one @CallerSensitive method to rule them all: 
MethodHandles.lookup()

-----

1. Conceptually a @CallerSensitive method has a hidden parameter - the 
caller class, which does not appear in source- or bytecode. A 
MethodHandles.Lookup parameter is explicit.

2. Most @CallerSensitive methods are listed in the Secure Coding 
Guidelines for Java SE[1]. When adding new @CallerSensitive methods it 
should always be considered if those methods need to be listed in that 
document as well.
This list should also not increase indefinitely, as each use of a method 
listed there needs to be carefully checked to avoid security 
vulnerabilities.
Using a method taking a MethodHandles.Lookup needs the same scrutiny - 
but because of the explicit nature this is evident from looking at use-site.

3. Methods that take an explicit MethodHandles.Lookup compose better 
with other methods that do the same - for example, a library could pass 
the lookup it received from its client to a core API, thereby acting on 
behalf of the client.

4. When a @CallerSensitive method is looked up from 
MethodHandles.Lookup, it needs to be bound to the caller.
This binding can be expensive in the worst case (load of an hidden class 
+ erasing the signature to ([Ljava/lang/Object;)Ljava/lang/Object;)

5. Making existing methods @CallerSensitive can lead to small backwards 
compatibility issues - as the public lookup can't lookup those methods 
anymore.

-----

A @CallerSensitive method have one benefit over passing a 
MethodHandles.Lookup: It has a nicer API.
This might be fine for the restricted methods that Panama introduces.

New methods that need to take the caller into account could for example 
add instead an overload that takes an explicit MethodHandles.Lookup as 
argument. The one without that argument could work as if 
`MethodHandles.publicLookup()` was passed to the other.

-----

Closing words:
This is my personal opinion, and might be totally wrong.
For now, my goal is just to start a discussion.

I explicitly don't ask about changing existing @CallerSensitive methods.

- Johannes

[1]: https://www.oracle.com/java/technologies/javase/seccodeguide.html#9-8

From redestad at openjdk.org  Fri Apr 21 14:34:46 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 21 Apr 2023 14:34:46 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v6]
In-Reply-To: <_SwKNoENpVe5iTpIFhQl1B7IhNwZZgBz2U-QQ8F4Ids=.64b9014d-3121-48f2-9368-c69b0370286e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <_SwKNoENpVe5iTpIFhQl1B7IhNwZZgBz2U-QQ8F4Ids=.64b9014d-3121-48f2-9368-c69b0370286e@github.com>
Message-ID: <qT5hzpWVCNon0KW2ay1SyrgSN7BBQrIID-Q6X4M8zio=.7727a2f9-2522-41d3-8ee7-39c801e9bf45@github.com>

On Thu, 20 Apr 2023 15:05:18 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300818: Remove blank line

test/micro/org/openjdk/bench/java/time/format/DateTimeFormatterWithPaddingBench.java line 62:

> 60: 
> 61:     @Benchmark
> 62:     public String formatWithZeroPadding() {

Isn't this benchmark now testing a padding of 1 char?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1173847037

From mcimadamore at openjdk.org  Fri Apr 21 15:20:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Apr 2023 15:20:55 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v4]
In-Reply-To: <PZBXViqw4vI2RK9quVrVW1WDOnM7KyNn6ZoNvLzYeY0=.5e215c1d-a229-41c1-a533-2ee839cf40c3@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <PZBXViqw4vI2RK9quVrVW1WDOnM7KyNn6ZoNvLzYeY0=.5e215c1d-a229-41c1-a533-2ee839cf40c3@github.com>
Message-ID: <284vbkNQcyFoTr0o69JAdyVrWfhp7GQxXIywJMkc-hY=.b83c89e6-6f67-42ef-8d5d-e781f0f2c1aa@github.com>

On Fri, 21 Apr 2023 10:56:55 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replacing use of mutable callsite with a mutable state.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 915:

> 913:          */
> 914:         private List<PatternDescription> reduceBindingPatterns(Type selectorType, List<PatternDescription> patterns) {
> 915:             Set<Symbol> existingBindings = patterns.stream()

Playing some more - I found this example:


class Test {
    sealed interface I permits C, D { }
    non-sealed interface C extends I { }
    non-sealed interface D extends I { }

    interface F { }

    <Z extends I & F> int test(Z o) {
        return switch (o) {
            case C c -> 1;
            case D d -> 2;
        };
    }
}


Which compiles correctly, but it doesn't look exhaustive to me (because of F) ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173896399

From mcimadamore at openjdk.org  Fri Apr 21 15:20:56 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Apr 2023 15:20:56 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v4]
In-Reply-To: <284vbkNQcyFoTr0o69JAdyVrWfhp7GQxXIywJMkc-hY=.b83c89e6-6f67-42ef-8d5d-e781f0f2c1aa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <PZBXViqw4vI2RK9quVrVW1WDOnM7KyNn6ZoNvLzYeY0=.5e215c1d-a229-41c1-a533-2ee839cf40c3@github.com>
 <284vbkNQcyFoTr0o69JAdyVrWfhp7GQxXIywJMkc-hY=.b83c89e6-6f67-42ef-8d5d-e781f0f2c1aa@github.com>
Message-ID: <ifCrTG32jVZDnfrM8TlXyL5Rzga2krCsG5pUwRNGpHY=.9b8370ac-d6a6-46aa-8893-693e55e85432@github.com>

On Fri, 21 Apr 2023 15:16:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replacing use of mutable callsite with a mutable state.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 915:
> 
>> 913:          */
>> 914:         private List<PatternDescription> reduceBindingPatterns(Type selectorType, List<PatternDescription> patterns) {
>> 915:             Set<Symbol> existingBindings = patterns.stream()
> 
> Playing some more - I found this example:
> 
> 
> class Test {
>     sealed interface I permits C, D { }
>     non-sealed interface C extends I { }
>     non-sealed interface D extends I { }
> 
>     interface F { }
> 
>     <Z extends I & F> int test(Z o) {
>         return switch (o) {
>             case C c -> 1;
>             case D d -> 2;
>         };
>     }
> }
> 
> 
> Which compiles correctly, but it doesn't look exhaustive to me (because of F) ?

Also, surprisingly, if I make C and D classes (instead of interfaces):

class Test {
    sealed interface I permits C, D { }
    final class C implements I { }
    final class D implements I { }

    interface F { }

    <Z extends I & F> int test(Z o) {
        return switch (o) {
            case C c -> 1;
            case D d -> 2;
        };
    }
}

I get errors like:


Foo.java:10: error: incompatible types: Z cannot be converted to Test.C
            case C c -> 1;
                 ^
  where Z is a type-variable:
    Z extends I,F declared in method <Z>test(Z)


Which seems odd?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173898106

From mcimadamore at openjdk.org  Fri Apr 21 15:32:54 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Apr 2023 15:32:54 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v4]
In-Reply-To: <ifCrTG32jVZDnfrM8TlXyL5Rzga2krCsG5pUwRNGpHY=.9b8370ac-d6a6-46aa-8893-693e55e85432@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <PZBXViqw4vI2RK9quVrVW1WDOnM7KyNn6ZoNvLzYeY0=.5e215c1d-a229-41c1-a533-2ee839cf40c3@github.com>
 <284vbkNQcyFoTr0o69JAdyVrWfhp7GQxXIywJMkc-hY=.b83c89e6-6f67-42ef-8d5d-e781f0f2c1aa@github.com>
 <ifCrTG32jVZDnfrM8TlXyL5Rzga2krCsG5pUwRNGpHY=.9b8370ac-d6a6-46aa-8893-693e55e85432@github.com>
Message-ID: <3-HT9uluxlbN2tV0NlH7z_cBEtgpCvZi1QWl5cLamks=.0537eddc-f226-40ff-bc4f-2dcf4c5655d2@github.com>

On Fri, 21 Apr 2023 15:17:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 915:
>> 
>>> 913:          */
>>> 914:         private List<PatternDescription> reduceBindingPatterns(Type selectorType, List<PatternDescription> patterns) {
>>> 915:             Set<Symbol> existingBindings = patterns.stream()
>> 
>> Playing some more - I found this example:
>> 
>> 
>> class Test {
>>     sealed interface I permits C, D { }
>>     non-sealed interface C extends I { }
>>     non-sealed interface D extends I { }
>> 
>>     interface F { }
>> 
>>     <Z extends I & F> int test(Z o) {
>>         return switch (o) {
>>             case C c -> 1;
>>             case D d -> 2;
>>         };
>>     }
>> }
>> 
>> 
>> Which compiles correctly, but it doesn't look exhaustive to me (because of F) ?
>
> Also, surprisingly, if I make C and D classes (instead of interfaces):
> 
> class Test {
>     sealed interface I permits C, D { }
>     final class C implements I { }
>     final class D implements I { }
> 
>     interface F { }
> 
>     <Z extends I & F> int test(Z o) {
>         return switch (o) {
>             case C c -> 1;
>             case D d -> 2;
>         };
>     }
> }
> 
> I get errors like:
> 
> 
> Foo.java:10: error: incompatible types: Z cannot be converted to Test.C
>             case C c -> 1;
>                  ^
>   where Z is a type-variable:
>     Z extends I,F declared in method <Z>test(Z)
> 
> 
> Which seems odd?

Nevermind - these issues are due to a misunderstanding of the rules with intersection types - e.g. given A & B, if a pattern covers _any_ of A, B, then it covers A & B.

Similarly, the second issue I reported is in reality caused by the fact that in the snippet with `class`, I also added `final` which then makes I & F a type with no concrete witnesses (so cast will always fail from there to either C/D).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173912165

From forax at openjdk.org  Fri Apr 21 15:38:00 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 21 Apr 2023 15:38:00 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v4]
In-Reply-To: <3-HT9uluxlbN2tV0NlH7z_cBEtgpCvZi1QWl5cLamks=.0537eddc-f226-40ff-bc4f-2dcf4c5655d2@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <PZBXViqw4vI2RK9quVrVW1WDOnM7KyNn6ZoNvLzYeY0=.5e215c1d-a229-41c1-a533-2ee839cf40c3@github.com>
 <284vbkNQcyFoTr0o69JAdyVrWfhp7GQxXIywJMkc-hY=.b83c89e6-6f67-42ef-8d5d-e781f0f2c1aa@github.com>
 <ifCrTG32jVZDnfrM8TlXyL5Rzga2krCsG5pUwRNGpHY=.9b8370ac-d6a6-46aa-8893-693e55e85432@github.com>
 <3-HT9uluxlbN2tV0NlH7z_cBEtgpCvZi1QWl5cLamks=.0537eddc-f226-40ff-bc4f-2dcf4c5655d2@github.com>
Message-ID: <LuUVbD1dGTJUtMwp0aSBQfSRO3SvLwg7YTd-e9MUglc=.c3b5583b-d171-430b-8022-443fbb36de03@github.com>

On Fri, 21 Apr 2023 15:30:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Also, surprisingly, if I make C and D classes (instead of interfaces):
>> 
>> class Test {
>>     sealed interface I permits C, D { }
>>     final class C implements I { }
>>     final class D implements I { }
>> 
>>     interface F { }
>> 
>>     <Z extends I & F> int test(Z o) {
>>         return switch (o) {
>>             case C c -> 1;
>>             case D d -> 2;
>>         };
>>     }
>> }
>> 
>> I get errors like:
>> 
>> 
>> Foo.java:10: error: incompatible types: Z cannot be converted to Test.C
>>             case C c -> 1;
>>                  ^
>>   where Z is a type-variable:
>>     Z extends I,F declared in method <Z>test(Z)
>> 
>> 
>> Which seems odd?
>
> Nevermind - these issues are due to a misunderstanding of the rules with intersection types - e.g. given A & B, if a pattern covers _any_ of A, B, then it covers A & B.
> 
> Similarly, the second issue I reported is in reality caused by the fact that in the snippet with `class`, I also added `final` which then makes I & F a type with no concrete witnesses (so cast will always fail from there to either C/D).

> Which compiles correctly, but it doesn't look exhaustive to me (because of F) ?

Can you expand a little more, because for me a Z either implement C or D or both C and D.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173916081

From duke at openjdk.org  Fri Apr 21 15:44:44 2023
From: duke at openjdk.org (Andy-Tatman)
Date: Fri, 21 Apr 2023 15:44:44 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: <5OfkgMk9QSD9KVNidbMkk1xpargpO2NNIolCDOGCWQ4=.40fb9ce2-ad17-48ed-aa3e-35cabf82a146@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.

@AlanBateman I would be happy to fill out the CSR, but unfortunately I don't think I am able to currently as I'm not an author on OpenJDK and as such don't have a JBS account. (I reported the bug through the Oracle site, rather than through bugs.openjdk.org .)
Would you be able to help out with this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1518016687

From mcimadamore at openjdk.org  Fri Apr 21 16:11:58 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Apr 2023 16:11:58 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v4]
In-Reply-To: <PZBXViqw4vI2RK9quVrVW1WDOnM7KyNn6ZoNvLzYeY0=.5e215c1d-a229-41c1-a533-2ee839cf40c3@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <PZBXViqw4vI2RK9quVrVW1WDOnM7KyNn6ZoNvLzYeY0=.5e215c1d-a229-41c1-a533-2ee839cf40c3@github.com>
Message-ID: <02wmStB1KKnY10rIaGsCN6PWv_3k3ljH67zMFs1GBgQ=.0e83bd08-8160-4fa5-8c01-0dd0591ffa45@github.com>

On Fri, 21 Apr 2023 10:56:55 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replacing use of mutable callsite with a mutable state.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 971:

> 969:                                             it.remove();
> 970:                                             reduces = true;
> 971:                                             continue ;

This continue seems redundant

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173947054

From naoto at openjdk.org  Fri Apr 21 16:22:02 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Apr 2023 16:22:02 GMT
Subject: RFR: 8304836: Make MALLOC_MIN4 macro more robust [v2]
In-Reply-To: <IyZnv9X8fFGbxKskxf6t-fDnui9npQ1B-jBGkLjqZJc=.f07d4469-f9db-4081-9ed5-6b3cba2e1795@github.com>
References: <IyZnv9X8fFGbxKskxf6t-fDnui9npQ1B-jBGkLjqZJc=.f07d4469-f9db-4081-9ed5-6b3cba2e1795@github.com>
Message-ID: <1Wflmrlom7431MPdM_TC56Xs172ZaUg_dtkB7fh3KXI=.f492d92f-ed58-4d34-8cdd-05962cb442a7@github.com>

> The current macro assumes the argument is `jint` because all locations pass `jint`. However, this would not work if a wider type such as `jlong` is passed. Removing the `unsigned` cast and make the condition explicit would make the macro more robust.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/native/libjava/jni_util.c
  
  Co-authored-by: David Schlosnagle <schlosna at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13564/files
  - new: https://git.openjdk.org/jdk/pull/13564/files/1a4ff652..0c97bf66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13564&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13564&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13564.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13564/head:pull/13564

PR: https://git.openjdk.org/jdk/pull/13564

From naoto at openjdk.org  Fri Apr 21 16:22:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Apr 2023 16:22:03 GMT
Subject: RFR: 8304836: Make MALLOC_MIN4 macro more robust [v2]
In-Reply-To: <gUQBxWAInmaffzG1wxw5LDgOz51RQyGMvNGE062sUiA=.ed85b349-7c33-406a-9244-0c56f05ff572@github.com>
References: <IyZnv9X8fFGbxKskxf6t-fDnui9npQ1B-jBGkLjqZJc=.f07d4469-f9db-4081-9ed5-6b3cba2e1795@github.com>
 <gUQBxWAInmaffzG1wxw5LDgOz51RQyGMvNGE062sUiA=.ed85b349-7c33-406a-9244-0c56f05ff572@github.com>
Message-ID: <FYe8duguEnr9waMGSndLTkkLhj80ovue1yJyEss_pus=.3a098401-e9aa-44fb-b9fd-c922c26297b9@github.com>

On Fri, 21 Apr 2023 12:42:24 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/native/libjava/jni_util.c
>>   
>>   Co-authored-by: David Schlosnagle <schlosna at gmail.com>
>
> src/java.base/share/native/libjava/jni_util.c line 42:
> 
>> 40:  * that overflows into negative value.
>> 41:  */
>> 42: #define MALLOC_MIN4(len) (len >= INT_MAX || len < 0 ? \
> 
> Should this keep the parentheses around `len` for explicit order of operations in case `len` is an expression?
> 
> Suggestion:
> 
> #define MALLOC_MIN4(len) ((len) >= INT_MAX || (len) < 0 ? \

Good point. Suggestion incorporated

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13564#discussion_r1173952865

From jlahoda at openjdk.org  Fri Apr 21 16:25:04 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 21 Apr 2023 16:25:04 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v5]
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <fe5fyxgbheu8mpzTvRwUA79iIXXs6VUSpTMMyBexnuA=.546c8f7a-ea48-4f68-b812-5afea9526cfd@github.com>

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:

 - Adding test.
 - Removing redundant continue, as noted on the review.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13074/files
  - new: https://git.openjdk.org/jdk/pull/13074/files/d3d9cc60..2cc3e11d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=03-04

  Stats: 27 lines in 2 files changed: 24 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074

PR: https://git.openjdk.org/jdk/pull/13074

From mcimadamore at openjdk.org  Fri Apr 21 16:25:06 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Apr 2023 16:25:06 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v4]
In-Reply-To: <LuUVbD1dGTJUtMwp0aSBQfSRO3SvLwg7YTd-e9MUglc=.c3b5583b-d171-430b-8022-443fbb36de03@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <PZBXViqw4vI2RK9quVrVW1WDOnM7KyNn6ZoNvLzYeY0=.5e215c1d-a229-41c1-a533-2ee839cf40c3@github.com>
 <284vbkNQcyFoTr0o69JAdyVrWfhp7GQxXIywJMkc-hY=.b83c89e6-6f67-42ef-8d5d-e781f0f2c1aa@github.com>
 <ifCrTG32jVZDnfrM8TlXyL5Rzga2krCsG5pUwRNGpHY=.9b8370ac-d6a6-46aa-8893-693e55e85432@github.com>
 <3-HT9uluxlbN2tV0NlH7z_cBEtgpCvZi1QWl5cLamks=.0537eddc-f226-40ff-bc4f-2dcf4c5655d2@github.com>
 <LuUVbD1dGTJUtMwp0aSBQfSRO3SvLwg7YTd-e9MUglc=.c3b5583b-d171-430b-8022-443fbb36de03@github.com>
Message-ID: <9EqBP9NLmF-UEeArN1_NTKv6rMmpMdYaKoE2V49cAAA=.5713d036-c92a-41cd-94a9-06229ff16e04@github.com>

On Fri, 21 Apr 2023 15:34:32 GMT, R?mi Forax <forax at openjdk.org> wrote:

> > Which compiles correctly, but it doesn't look exhaustive to me (because of F) ?
> 
> Can you expand a little more, because for me a Z either implement C or D or both C and D.

Please see my latest comment above. I was confused by the rules of coverage with intersection types. F is immaterial in this example - the only thing to show is that there is at least one of the component of the intersection (in this case I) that is fully covered.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173957437

From jlahoda at openjdk.org  Fri Apr 21 16:25:08 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 21 Apr 2023 16:25:08 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v4]
In-Reply-To: <02wmStB1KKnY10rIaGsCN6PWv_3k3ljH67zMFs1GBgQ=.0e83bd08-8160-4fa5-8c01-0dd0591ffa45@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <PZBXViqw4vI2RK9quVrVW1WDOnM7KyNn6ZoNvLzYeY0=.5e215c1d-a229-41c1-a533-2ee839cf40c3@github.com>
 <02wmStB1KKnY10rIaGsCN6PWv_3k3ljH67zMFs1GBgQ=.0e83bd08-8160-4fa5-8c01-0dd0591ffa45@github.com>
Message-ID: <8fLo2qujFv8JPfTsmYOj5RXLqAFNYHsdu7oiWHma_GU=.a1468a74-e2a9-491e-baea-967e3fffc43c@github.com>

On Fri, 21 Apr 2023 16:08:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replacing use of mutable callsite with a mutable state.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 971:
> 
>> 969:                                             it.remove();
>> 970:                                             reduces = true;
>> 971:                                             continue ;
> 
> This continue seems redundant

Thanks, fixed:
https://github.com/openjdk/jdk/pull/13074/commits/8b1cfba6e4603d82836d889273855185165acd29

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173955311

From vromero at openjdk.org  Fri Apr 21 16:34:00 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 21 Apr 2023 16:34:00 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v4]
In-Reply-To: <PZBXViqw4vI2RK9quVrVW1WDOnM7KyNn6ZoNvLzYeY0=.5e215c1d-a229-41c1-a533-2ee839cf40c3@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <PZBXViqw4vI2RK9quVrVW1WDOnM7KyNn6ZoNvLzYeY0=.5e215c1d-a229-41c1-a533-2ee839cf40c3@github.com>
Message-ID: <7uCVXj5bqYXlEvCQK-ROxX_qKBd_0Agm6mtU0X60IfQ=.9413e290-fe1d-4087-a4b1-761381274662@github.com>

On Fri, 21 Apr 2023 10:56:55 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replacing use of mutable callsite with a mutable state.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 302:

> 300:                                     MethodHandles.Lookup lookup, Class<?> enumClass,
> 301:                                     ResolvedEnumLabels resolvedLabels) {
> 302:         Objects.checkIndex(startIndex, unresolvedLabels.length + 1);

I think that we should add a comment to the related API stating that IOOBE can be thrown.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173899355

From bchristi at openjdk.org  Fri Apr 21 16:43:43 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 21 Apr 2023 16:43:43 GMT
Subject: RFR: 8304836: Make MALLOC_MIN4 macro more robust [v2]
In-Reply-To: <1Wflmrlom7431MPdM_TC56Xs172ZaUg_dtkB7fh3KXI=.f492d92f-ed58-4d34-8cdd-05962cb442a7@github.com>
References: <IyZnv9X8fFGbxKskxf6t-fDnui9npQ1B-jBGkLjqZJc=.f07d4469-f9db-4081-9ed5-6b3cba2e1795@github.com>
 <1Wflmrlom7431MPdM_TC56Xs172ZaUg_dtkB7fh3KXI=.f492d92f-ed58-4d34-8cdd-05962cb442a7@github.com>
Message-ID: <q1F7gAMv3Rp6FJYLdXK5Heh2k4AcXONLowIXqxS5ZW4=.fa2d5e29-ce88-476e-9b85-55a4c6086c36@github.com>

On Fri, 21 Apr 2023 16:22:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The current macro assumes the argument is `jint` because all locations pass `jint`. However, this would not work if a wider type such as `jlong` is passed. Removing the `unsigned` cast and make the condition explicit would make the macro more robust.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/native/libjava/jni_util.c
>   
>   Co-authored-by: David Schlosnagle <schlosna at gmail.com>

Marked as reviewed by bchristi (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13564#pullrequestreview-1396087410

From rriggs at openjdk.org  Fri Apr 21 16:50:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 21 Apr 2023 16:50:48 GMT
Subject: RFR: 8306678 os version
Message-ID: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>

Create an internal Version record to hold and compare versions of the form (major, minor, micro).
Add `OperatingSystem.version()` to return the version of the running OS.
Replace uses of os.version in java.base.
Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.

-------------

Depends on: https://git.openjdk.org/jdk/pull/13357

Commit messages:
 - Simplify exception handling
 - Simplify version parsing
 - 8306678: Replace use of os.version with an internal Version record

Changes: https://git.openjdk.org/jdk/pull/13584/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13584&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306678
  Stats: 306 lines in 7 files changed: 277 ins; 22 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13584/head:pull/13584

PR: https://git.openjdk.org/jdk/pull/13584

From vromero at openjdk.org  Fri Apr 21 16:52:57 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 21 Apr 2023 16:52:57 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v5]
In-Reply-To: <fe5fyxgbheu8mpzTvRwUA79iIXXs6VUSpTMMyBexnuA=.546c8f7a-ea48-4f68-b812-5afea9526cfd@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <fe5fyxgbheu8mpzTvRwUA79iIXXs6VUSpTMMyBexnuA=.546c8f7a-ea48-4f68-b812-5afea9526cfd@github.com>
Message-ID: <TzkAOuRiuEZAp5ZhmH1CSOZwSOGvB4QTB203Ngin75w=.b1276a46-7f00-49fa-8147-2fafdb110963@github.com>

On Fri, 21 Apr 2023 16:25:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adding test.
>  - Removing redundant continue, as noted on the review.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 315:

> 313:         Object[] labels = resolvedLabels.resolvedLabels;
> 314: 
> 315:         // Dumbest possible strategy

I guess that given that we can't make any assumption about order here, this is the only possible strategy so I guess it makes sense to remove the comment

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173981785

From alanb at openjdk.org  Fri Apr 21 17:04:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Apr 2023 17:04:46 GMT
Subject: RFR: 8306678: Replace use of os.version with an internal Version
 record
In-Reply-To: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
Message-ID: <jM3npCGY4o0vlKaB4MZ515wb9FWgR5pd24J4snqnkwA=.6dabb690-a5d0-48a5-8f26-7032c702e2ef@github.com>

On Fri, 21 Apr 2023 16:44:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Create an internal Version record to hold and compare versions of the form (major, minor, micro).
> Add `OperatingSystem.version()` to return the version of the running OS.
> Replace uses of os.version in java.base.
> Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.

src/java.base/macosx/classes/jdk/internal/loader/ClassLoaderHelper.java line 39:

> 37:         // SDK 10.15 and earlier always reports 10.16 instead of 11.x.x
> 38:         hasDynamicLoaderCache = OperatingSystem.version()
> 39:                 .compareTo(new Version(10, 16)) >= 0;

I wonder if this check can be removed too as 10.11 is the oldest macOS release that seems to be getting updates.

src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java line 103:

> 101:                 // fgetxattr broken on APFS prior to 10.14
> 102:                 return OperatingSystem.version()
> 103:                         .compareTo(new Version(10, 14)) >= 0;

I don't think 10.14 has had an updated since 2021 so I suspect you can just remove this check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1173994111
PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1173992559

From naoto at openjdk.org  Fri Apr 21 17:38:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Apr 2023 17:38:45 GMT
Subject: RFR: 8306031: Update IANA Language Subtag Registry to Version
 2023-04-13 [v6]
In-Reply-To: <RXLecczBt_joz0R9SFMGI79wlPl2OWqA0Ca-m5qdmwk=.b3be3427-ab9c-43d3-950b-6546ebb8c363@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
 <RXLecczBt_joz0R9SFMGI79wlPl2OWqA0Ca-m5qdmwk=.b3be3427-ab9c-43d3-950b-6546ebb8c363@github.com>
Message-ID: <SOMFmTTQ69cndrcgzKaipdrlDpYUTVzOTNf7qpgcI24=.3e2b6cf9-d0d2-4a05-b00f-f77c7cbec24b@github.com>

On Thu, 20 Apr 2023 20:22:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
>> 
>> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
>> 
>> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
>> 
>> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
>> 
>> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
>> 
>> 
>> ...
>> singleEquivMap.put("ar-ajp", "ajp");
>> singleEquivMap.put("ajp", "ar-ajp");
>> ...
>> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
>> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
>> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
>> ...
>> 
>> 
>> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
>> 
>> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
>> 
>> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
>> 
>> To address this, the build process must be adjusted so that the equivalencies are built as 
>> 
>> 
>> ...
>> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
>> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
>> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
>> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
>> ...
>> 
>> 
>> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Import ordering

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13501#pullrequestreview-1396170956

From stsypanov at openjdk.org  Fri Apr 21 17:45:50 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 21 Apr 2023 17:45:50 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v7]
In-Reply-To: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
Message-ID: <FMW9OUs_b1Yc1MfP8va36dgEjkx0S-KufzUIw__EZ6w=.5a23562f-e87b-42ae-82d0-3cbbbd55bf26@github.com>

> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
> 
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>   .appendLiteral("Date:")
>   .padNext(20, ' ')
>   .append(DateTimeFormatter.ISO_DATE)
>   .toFormatter();
> String text = dtf.format(LocalDateTime.now());

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8300818: One more benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12131/files
  - new: https://git.openjdk.org/jdk/pull/12131/files/baa7f92e..48a0cc70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12131&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12131&range=05-06

  Stats: 14 lines in 1 file changed: 11 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12131/head:pull/12131

PR: https://git.openjdk.org/jdk/pull/12131

From naoto at openjdk.org  Fri Apr 21 18:29:47 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Apr 2023 18:29:47 GMT
Subject: RFR: 8302983: ZoneRulesProvider.registerProvider() twice will
 remove provider [v4]
In-Reply-To: <32bmWmdJSojCpNplpArpbXwn6LD2qHIZSZfOccJKjC4=.9d60aeba-8ae5-40c6-ac78-241ef4002d1a@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
 <32bmWmdJSojCpNplpArpbXwn6LD2qHIZSZfOccJKjC4=.9d60aeba-8ae5-40c6-ac78-241ef4002d1a@github.com>
Message-ID: <t9NEDp4oC17BGwH9oFQwKS1fFb5COgxQ_8uln39FnSA=.d688e79f-96e1-4312-b848-789883af7599@github.com>

On Tue, 28 Feb 2023 07:49:17 GMT, Madjosz <duke at openjdk.org> wrote:

>> Fixes JDK-8302983 (and duplicate JDK-8302898)
>
> Madjosz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace, remove stream()

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12690#pullrequestreview-1396233556

From vromero at openjdk.org  Fri Apr 21 18:41:53 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 21 Apr 2023 18:41:53 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v5]
In-Reply-To: <fe5fyxgbheu8mpzTvRwUA79iIXXs6VUSpTMMyBexnuA=.546c8f7a-ea48-4f68-b812-5afea9526cfd@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <fe5fyxgbheu8mpzTvRwUA79iIXXs6VUSpTMMyBexnuA=.546c8f7a-ea48-4f68-b812-5afea9526cfd@github.com>
Message-ID: <CAYQziwZx0xV43sIeT3UhvaPugx06hwppNP6InK3if8=.fb564fb6-31b7-4281-8900-e604edbe23c0@github.com>

On Fri, 21 Apr 2023 16:25:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adding test.
>  - Removing redundant continue, as noted on the review.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 808:

> 806:             }
> 807: 
> 808:             public static int hashCode(int excludeComponent, Type recordType, Type[] fullComponentTypes, PatternDescription... nested) {

this argument: `fullComponentTypes` is not being used in this method, could be removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1174066885

From redestad at openjdk.org  Fri Apr 21 18:45:47 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 21 Apr 2023 18:45:47 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v7]
In-Reply-To: <FMW9OUs_b1Yc1MfP8va36dgEjkx0S-KufzUIw__EZ6w=.5a23562f-e87b-42ae-82d0-3cbbbd55bf26@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <FMW9OUs_b1Yc1MfP8va36dgEjkx0S-KufzUIw__EZ6w=.5a23562f-e87b-42ae-82d0-3cbbbd55bf26@github.com>
Message-ID: <Xwl-cHIcUn5GxopbUcD-VwkKAwfiIjnfth_28yvY5Qg=.aeb2be0b-62d7-4266-90fa-2fcfb9dae03d@github.com>

On Fri, 21 Apr 2023 17:45:50 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300818: One more benchmark

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12131#pullrequestreview-1396251756

From rriggs at openjdk.org  Fri Apr 21 19:28:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 21 Apr 2023 19:28:47 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v7]
In-Reply-To: <FMW9OUs_b1Yc1MfP8va36dgEjkx0S-KufzUIw__EZ6w=.5a23562f-e87b-42ae-82d0-3cbbbd55bf26@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <FMW9OUs_b1Yc1MfP8va36dgEjkx0S-KufzUIw__EZ6w=.5a23562f-e87b-42ae-82d0-3cbbbd55bf26@github.com>
Message-ID: <NPXXwWjw6CQBGJGdu78gx82hq7B4U_43UyrIBI9_SO4=.d84dd4c5-923d-4f8d-8e5d-2523907c440b@github.com>

On Fri, 21 Apr 2023 17:45:50 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300818: One more benchmark

Marked as reviewed by rriggs (Reviewer).

I added a few more small padding cases and and re-ran on my Mac:

Baseline:

Benchmark                                                    Mode  Cnt      Score     Error   Units
DateTimeFormatterWithPaddingBench.formatWithPadding         thrpt   15   5167.611 ?  85.096  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength0  thrpt   15  22004.618 ? 536.207  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength1  thrpt   15  18041.569 ? 142.627  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength2  thrpt   15  15966.853 ? 182.284  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength3  thrpt   15  13472.887 ? 181.794  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength4  thrpt   15  12991.458 ? 402.190  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength5  thrpt   15  11464.481 ? 603.970  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength6  thrpt   15  10386.347 ? 673.596  ops/ms


Patch:

Benchmark                                                    Mode  Cnt      Score     Error   Units
DateTimeFormatterWithPaddingBench.formatWithPadding         thrpt   15   6548.853 ? 201.695  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength0  thrpt   15  22269.428 ? 737.613  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength1  thrpt   15  19086.146 ? 117.055  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength2  thrpt   15  15627.898 ? 314.890  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength3  thrpt   15  15447.997 ? 121.946  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength4  thrpt   15  15185.318 ? 198.266  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength5  thrpt   15  15243.618 ? 147.131  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength6  thrpt   15  15093.142 ? 294.421  ops/ms

The expected steps in performance match the code paths of 0, 1, 2-6.

-------------

PR Review: https://git.openjdk.org/jdk/pull/12131#pullrequestreview-1396300114
PR Comment: https://git.openjdk.org/jdk/pull/12131#issuecomment-1518248669

From mandy.chung at oracle.com  Fri Apr 21 19:30:49 2023
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Fri, 21 Apr 2023 12:30:49 -0700
Subject: Discussion: Prefer passing MethodHandles.Lookup over
 @CallerSensitive
In-Reply-To: <dbfe269b-78e2-5c85-9200-5d949dfe1ecf@j-kuhn.de>
References: <dbfe269b-78e2-5c85-9200-5d949dfe1ecf@j-kuhn.de>
Message-ID: <5ab172ba-26cf-8873-b803-fe7871c6be21@oracle.com>


On 4/21/23 6:44 AM, Johannes Kuhn wrote:
> Hi,
>
> Instead of making new and existing methods @CallerSensitive, such 
> methods could instead take a MethodHandles.Lookup as method argument.
>
> Library authors are often told that they could ask their users to pass 
> a MethodHandles.Lookup to obtain internal access instead of using 
> things like AccessibleObject::setAccessible.
>
> I hope OpenJDK would follow that advice as well, IMHO the broader use 
> of MethodHandles.Lookup would make things easier for both OpenJDK 
> deverlopers & library authors.
>
> tl;dr: Have one @CallerSensitive method to rule them all: 
> MethodHandles.lookup()
>
Short answer is: It depends.? The platform already has such an example:? 
ConstantDesc::resolveConstantDesc takes the Lookup parameter as the 
resolution and access control context.

Long answer is: caller-sensitiveness of @CS methods is used in several 
categories.? It all depends.

1. security permission check: bypass SecurityManager permission checks 
depending on the immediate caller's class loader.? Majority of @CS 
methods are in this category. ? This includes 3-arg Class::forName, 
Class::getClassLoader, ClassLoader::getSystemClassLoader, 
java.lang.reflect APIs as well as APIs that call these @CS methods on 
behalf of the caller such as 
javax.sql.rowset.serial.SerialJavaObject::getFields.

We should not introduce any new APIs in this category.

2. Access check: core reflection API e.g. Field::setInt

3. Caller's context as the default: this includes 1-arg Class::forName, 
Resource::getBundle, ClassLoader::registerAsParallelCapable, 
Package::getPackages

a) Existing APIs already take a context parameter.?? For example, non 
1-arg variants of Class::forName and Resource::getBundle already take 
the ClassLoader parameter to provide the context.?? A variant to take 
Lookup parameter for this category is unnecessary and redundant.

b) For APIs that don't provide a variant to take the context parameter, 
it may be reasonable to define a variant to take a context parameter 
(Lookup or other type more appropriate and align with the existing APIs).

For this subcategory, I agree the APIs should take the context 
parameter.?? Lookup object would be appropriate if it's for access 
control context.?? In addition, defining an API deriving the context 
from the caller should carefully be evaluated and justified.

4. Validate APIs being called by a valid caller: IllegalCallerException 
thrown if an illegal caller is detected. This includes Module::addReads, 
addExports, and java.lang.foreign APIs etc.? Making these APIs to take a 
Lookup parameter is less easier to use.

> -----
>
> 1. Conceptually a @CallerSensitive method has a hidden parameter - the 
> caller class, which does not appear in source- or bytecode. A 
> MethodHandles.Lookup parameter is explicit.
>
> 2. Most @CallerSensitive methods are listed in the Secure Coding 
> Guidelines for Java SE[1]. When adding new @CallerSensitive methods it 
> should always be considered if those methods need to be listed in that 
> document as well.
> This list should also not increase indefinitely, as each use of a 
> method listed there needs to be carefully checked to avoid security 
> vulnerabilities.
> Using a method taking a MethodHandles.Lookup needs the same scrutiny - 
> but because of the explicit nature this is evident from looking at 
> use-site.


These @CS methods are the ones that bypass SecurityManager permission 
checks depending on the immediate caller's class loader.? We should not 
add any new CS method adding to this list.

> 3. Methods that take an explicit MethodHandles.Lookup compose better 
> with other methods that do the same - for example, a library could 
> pass the lookup it received from its client to a core API, thereby 
> acting on behalf of the client.
>
> 4. When a @CallerSensitive method is looked up from 
> MethodHandles.Lookup, it needs to be bound to the caller.
> This binding can be expensive in the worst case (load of an hidden 
> class + erasing the signature to ([Ljava/lang/Object;)Ljava/lang/Object;)
>
Yes but one hidden class per each caller class.? This overhead only 
applies to MethodHandle::invokexxx and Method::invoke on a @CS method 
which does not have an CS adaptor (see @CallerSensitiveAdaptor).

This overhead is not relevant to the bytecode invocation of @CS methods 
such as Class::forName.

> 5. Making existing methods @CallerSensitive can lead to small 
> backwards compatibility issues - as the public lookup can't lookup 
> those methods anymore.
>
Can you explain what you observe about this??? Public lookup has access 
to public members of public classes in packages that are exported 
unconditionally. ?? @CS should have no impact to public lookup.


> -----
>
> A @CallerSensitive method have one benefit over passing a 
> MethodHandles.Lookup: It has a nicer API.
> This might be fine for the restricted methods that Panama introduces.
>
> New methods that need to take the caller into account could for 
> example add instead an overload that takes an explicit 
> MethodHandles.Lookup as argument. The one without that argument could 
> work as if `MethodHandles.publicLookup()` was passed to the other.
>
> -----
>
> Closing words:
> This is my personal opinion, and might be totally wrong.
> For now, my goal is just to start a discussion.
>
> I explicitly don't ask about changing existing @CallerSensitive methods.


Good.? The categories I described above hope will give more context and 
explain the considerations to have for new APIs.

Mandy

> - Johannes
>
> [1]: 
> https://www.oracle.com/java/technologies/javase/seccodeguide.html#9-8

From cstein at openjdk.org  Fri Apr 21 20:18:46 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 21 Apr 2023 20:18:46 GMT
Subject: RFR: 8306678: Replace use of os.version with an internal Version
 record
In-Reply-To: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
Message-ID: <WXRNjh57XO2Jbd7YaDHlQTa02bUdD8HJw-ZC6KxJEzA=.555a86ce-ef66-42f0-a608-c17e393ea365@github.com>

On Fri, 21 Apr 2023 16:44:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Create an internal Version record to hold and compare versions of the form (major, minor, micro).
> Add `OperatingSystem.version()` to return the version of the running OS.
> Replace uses of os.version in java.base.
> Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.

test/jdk/jdk/internal/util/VersionTest.java line 64:

> 62:         Version actual = Version.parse(verName);
> 63:         assertEquals(actual, expected, "Parsed version mismatch");
> 64:     }

Another way to declare arguments is to use `CsvSource` like:


    @ParameterizedTest
    @CsvSource(textBlock =
            """
            1, 0, 0, 1
            1, 2, 0, 1.2
            1, 2, 0, 1.2.0
            1, 2, 3, 1.2.3
            # Ignore extra trailing characters
            1, 0, 0, 1-abc
            1, 2, 0, 1.2-abc
            1, 2, 3, 1.2.3.4
            1, 2, 3, 1.2.3-abc
            """)
    void checkParse(int major, int minor, int micro, Version actual) {
        Version expected = new Version(major, minor, micro);
        assertEquals(expected, actual, "Parsed version mismatch");
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1174131270

From cstein at openjdk.org  Fri Apr 21 20:24:45 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 21 Apr 2023 20:24:45 GMT
Subject: RFR: 8306678: Replace use of os.version with an internal Version
 record
In-Reply-To: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
Message-ID: <m-yLHHOHlKlnCc4sUaRNJ7a24NVUBUK0yxHMDq0C_as=.db8f1ffb-61f2-42dd-95bc-bae771e34701@github.com>

On Fri, 21 Apr 2023 16:44:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Create an internal Version record to hold and compare versions of the form (major, minor, micro).
> Add `OperatingSystem.version()` to return the version of the running OS.
> Replace uses of os.version in java.base.
> Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.

test/jdk/jdk/internal/util/VersionTest.java line 87:

> 85:         }
> 86:         assertThrows(exception, () -> Version.parse(verName));
> 87:     }

The explicit creation of argument instances can be avoided by using something like:


    @ParameterizedTest
    @ValueSource(strings = {
            // dot without digits
            "1.", "1.2.", "1.-abc", "1.2.-abc",
            // empty
            "",
            // no an initial digit
            "xaaa", "abc.xyz"
    })
    void checkIllegalParse(String verName) {
        checkIllegalParse(verName, IllegalArgumentException.class);
    }

    void checkIllegalParse(String verName, Class<? extends Throwable> exception) {
        assertThrows(exception, () -> Version.parse(verName));
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1174134594

From rriggs at openjdk.org  Fri Apr 21 20:26:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 21 Apr 2023 20:26:12 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v17]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <vjrFk-Qfyw2CzxBi-Sh0ZgkeeMUqhWW5f72bdqyqHFE=.1e5f2fb4-6bb3-4fcb-831c-20bd0765b17b@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Correct comment on isPPC64() and refer to isLittleEndian() instead of mentioning PPC64LE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/b95a312d..accf67f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=15-16

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

PR: https://git.openjdk.org/jdk/pull/13357

From rriggs at openjdk.org  Fri Apr 21 20:27:45 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 21 Apr 2023 20:27:45 GMT
Subject: RFR: 8306678: Replace use of os.version with an internal Version
 record
In-Reply-To: <WXRNjh57XO2Jbd7YaDHlQTa02bUdD8HJw-ZC6KxJEzA=.555a86ce-ef66-42f0-a608-c17e393ea365@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
 <WXRNjh57XO2Jbd7YaDHlQTa02bUdD8HJw-ZC6KxJEzA=.555a86ce-ef66-42f0-a608-c17e393ea365@github.com>
Message-ID: <fpyklV0hK_lEPHmpzzbXGPkruHowzQSuFHUy0zHWhEw=.90ee4af6-f60a-4062-99cc-e575e2fe871e@github.com>

On Fri, 21 Apr 2023 20:15:50 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Create an internal Version record to hold and compare versions of the form (major, minor, micro).
>> Add `OperatingSystem.version()` to return the version of the running OS.
>> Replace uses of os.version in java.base.
>> Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.
>
> test/jdk/jdk/internal/util/VersionTest.java line 64:
> 
>> 62:         Version actual = Version.parse(verName);
>> 63:         assertEquals(actual, expected, "Parsed version mismatch");
>> 64:     }
> 
> Another way to declare arguments is to use `CsvSource` like:
> 
> 
>     @ParameterizedTest
>     @CsvSource(textBlock =
>             """
>             1, 0, 0, 1
>             1, 2, 0, 1.2
>             1, 2, 0, 1.2.0
>             1, 2, 3, 1.2.3
>             # Ignore extra trailing characters
>             1, 0, 0, 1-abc
>             1, 2, 0, 1.2-abc
>             1, 2, 3, 1.2.3.4
>             1, 2, 3, 1.2.3-abc
>             """)
>     void checkParse(int major, int minor, int micro, Version actual) {
>         Version expected = new Version(major, minor, micro);
>         assertEquals(expected, actual, "Parsed version mismatch");
>     }

Good to know about CsvSource.
The test is checking Version.parse(str) works. So I'd code it as:

void checkParse(int major, int minor, int micro, String verString) {
        Version expected = new Version(major, minor, micro);
        Version actual = Version.parse(verString);
        assertEquals(expected, actual, "Parsed version mismatch");
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1174136796

From rriggs at openjdk.org  Fri Apr 21 20:39:41 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 21 Apr 2023 20:39:41 GMT
Subject: RFR: 8306678: Replace use of os.version with an internal Version
 record
In-Reply-To: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
Message-ID: <wBe_MZ2oyHn6IlcOUuPJYEKaV7UbvA_OepdMkyrFwGM=.f48ac643-58c0-47fe-98d8-0c879c0a695a@github.com>

On Fri, 21 Apr 2023 16:44:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Create an internal Version record to hold and compare versions of the form (major, minor, micro).
> Add `OperatingSystem.version()` to return the version of the running OS.
> Replace uses of os.version in java.base.
> Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.

To see how Version is used see the draft PR's for jlink (https://github.com/openjdk/jdk/pull/13585) and jpackage (https://github.com/openjdk/jdk/pull/13586).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13584#issuecomment-1518310892

From rriggs at openjdk.org  Fri Apr 21 20:44:41 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 21 Apr 2023 20:44:41 GMT
Subject: RFR: 8306678: Replace use of os.version with an internal Version
 record
In-Reply-To: <m-yLHHOHlKlnCc4sUaRNJ7a24NVUBUK0yxHMDq0C_as=.db8f1ffb-61f2-42dd-95bc-bae771e34701@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
 <m-yLHHOHlKlnCc4sUaRNJ7a24NVUBUK0yxHMDq0C_as=.db8f1ffb-61f2-42dd-95bc-bae771e34701@github.com>
Message-ID: <NDOv5KVP4uyrH7Sg5EMSyv9BB6TmRbYx-ifQvA0pgxg=.807ad7f2-7d9e-4eac-8867-f9723201e20c@github.com>

On Fri, 21 Apr 2023 20:21:33 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Create an internal Version record to hold and compare versions of the form (major, minor, micro).
>> Add `OperatingSystem.version()` to return the version of the running OS.
>> Replace uses of os.version in java.base.
>> Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.
>
> test/jdk/jdk/internal/util/VersionTest.java line 87:
> 
>> 85:         }
>> 86:         assertThrows(exception, () -> Version.parse(verName));
>> 87:     }
> 
> The explicit creation of argument instances can be avoided by using something like:
> 
> 
>     @ParameterizedTest
>     @ValueSource(strings = {
>             // dot without digits
>             "1.", "1.2.", "1.-abc", "1.2.-abc",
>             // empty
>             "",
>             // no an initial digit
>             "xaaa", "abc.xyz"
>     })
>     void checkIllegalParse(String verName) {
>         checkIllegalParse(verName, IllegalArgumentException.class);
>     }
> 
>     void checkIllegalParse(String verName, Class<? extends Throwable> exception) {
>         assertThrows(exception, () -> Version.parse(verName));
>     }

When I first wrote the test, I expected to be checking for different exceptions and messages on each case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1174148657

From info at j-kuhn.de  Fri Apr 21 20:58:17 2023
From: info at j-kuhn.de (Johannes Kuhn)
Date: Fri, 21 Apr 2023 22:58:17 +0200
Subject: Discussion: Prefer passing MethodHandles.Lookup over
 @CallerSensitive
In-Reply-To: <5ab172ba-26cf-8873-b803-fe7871c6be21@oracle.com>
References: <dbfe269b-78e2-5c85-9200-5d949dfe1ecf@j-kuhn.de>
 <5ab172ba-26cf-8873-b803-fe7871c6be21@oracle.com>
Message-ID: <ae9106bc-7dce-9300-65cb-ce2de4ecb0dc@j-kuhn.de>

Hi,

to reiterate: I do not want to change existing APIs.
Instead having a discussion that can guide the introduction of new APIs 
that may want to be @CS (but don't need to be).

On 21-Apr-23 21:30, mandy.chung at oracle.com wrote:
> 
> On 4/21/23 6:44 AM, Johannes Kuhn wrote:
>> Hi,
>>
>> Instead of making new and existing methods @CallerSensitive, such 
>> methods could instead take a MethodHandles.Lookup as method argument.
>>
>> Library authors are often told that they could ask their users to pass 
>> a MethodHandles.Lookup to obtain internal access instead of using 
>> things like AccessibleObject::setAccessible.
>>
>> I hope OpenJDK would follow that advice as well, IMHO the broader use 
>> of MethodHandles.Lookup would make things easier for both OpenJDK 
>> deverlopers & library authors.
>>
>> tl;dr: Have one @CallerSensitive method to rule them all: 
>> MethodHandles.lookup()
>>
> Short answer is: It depends.? The platform already has such an example: 
> ConstantDesc::resolveConstantDesc takes the Lookup parameter as the 
> resolution and access control context.
> 
> Long answer is: caller-sensitiveness of @CS methods is used in several 
> categories.? It all depends.
> 
> 1. security permission check: bypass SecurityManager permission checks 
> depending on the immediate caller's class loader.? Majority of @CS 
> methods are in this category. ? This includes 3-arg Class::forName, 
> Class::getClassLoader, ClassLoader::getSystemClassLoader, 
> java.lang.reflect APIs as well as APIs that call these @CS methods on 
> behalf of the caller such as 
> javax.sql.rowset.serial.SerialJavaObject::getFields. >
> We should not introduce any new APIs in this category.

I agree on this.

> 
> 2. Access check: core reflection API e.g. Field::setInt
> 
> 3. Caller's context as the default: this includes 1-arg Class::forName, 
> Resource::getBundle, ClassLoader::registerAsParallelCapable, 
> Package::getPackages
> 
> a) Existing APIs already take a context parameter.?? For example, non 
> 1-arg variants of Class::forName and Resource::getBundle already take 
> the ClassLoader parameter to provide the context.?? A variant to take 
> Lookup parameter for this category is unnecessary and redundant.
> 
> b) For APIs that don't provide a variant to take the context parameter, 
> it may be reasonable to define a variant to take a context parameter 
> (Lookup or other type more appropriate and align with the existing APIs).

Again, it is not my goal to change existing behavior - instead having a 
discussion about this to guide *new* APIs if they should be @CS or take 
the context as parameter.

> 
> For this subcategory, I agree the APIs should take the context 
> parameter.?? Lookup object would be appropriate if it's for access 
> control context.?? In addition, defining an API deriving the context 
> from the caller should carefully be evaluated and justified.
> 
> 4. Validate APIs being called by a valid caller: IllegalCallerException 
> thrown if an illegal caller is detected. This includes Module::addReads, 
> addExports, and java.lang.foreign APIs etc.? Making these APIs to take a 
> Lookup parameter is less easier to use.
> 

Those are already existing APIs.

As example, John Rose suggested in his "Value type companions, 
encapsulated"[2] the addition of more @CS methods - this is where I see 
the value of a discussion beforehand.

>> -----
>>
>> 1. Conceptually a @CallerSensitive method has a hidden parameter - the 
>> caller class, which does not appear in source- or bytecode. A 
>> MethodHandles.Lookup parameter is explicit.
>>
>> 2. Most @CallerSensitive methods are listed in the Secure Coding 
>> Guidelines for Java SE[1]. When adding new @CallerSensitive methods it 
>> should always be considered if those methods need to be listed in that 
>> document as well.
>> This list should also not increase indefinitely, as each use of a 
>> method listed there needs to be carefully checked to avoid security 
>> vulnerabilities.
>> Using a method taking a MethodHandles.Lookup needs the same scrutiny - 
>> but because of the explicit nature this is evident from looking at 
>> use-site.
> 
> 
> These @CS methods are the ones that bypass SecurityManager permission 
> checks depending on the immediate caller's class loader.? We should not 
> add any new CS method adding to this list.

There are several categories, for ClassLoader, Module...
The SecurityManager is only related for a subset of them.
(Strictly speaking, restricted methods from panama may also fall under 
ACCESS-14)

> 
>> 3. Methods that take an explicit MethodHandles.Lookup compose better 
>> with other methods that do the same - for example, a library could 
>> pass the lookup it received from its client to a core API, thereby 
>> acting on behalf of the client.
>>
>> 4. When a @CallerSensitive method is looked up from 
>> MethodHandles.Lookup, it needs to be bound to the caller.
>> This binding can be expensive in the worst case (load of an hidden 
>> class + erasing the signature to ([Ljava/lang/Object;)Ljava/lang/Object;)
>>
> Yes but one hidden class per each caller class.? This overhead only 
> applies to MethodHandle::invokexxx and Method::invoke on a @CS method 
> which does not have an CS adaptor (see @CallerSensitiveAdaptor).
> 
> This overhead is not relevant to the bytecode invocation of @CS methods 
> such as Class::forName.
> 

Yes, this is all true - but there is still overhead.
It is simply an argument why @CS is more complicated (and maybe should 
be avoided for future APIs?)

>> 5. Making existing methods @CallerSensitive can lead to small 
>> backwards compatibility issues - as the public lookup can't lookup 
>> those methods anymore.
>>
> Can you explain what you observe about this??? Public lookup has access 
> to public members of public classes in packages that are exported 
> unconditionally. ?? @CS should have no impact to public lookup.
> 
> 

This line works with Java 7 - 16:

     MethodHandles.publicLookup().findStatic(System.class, 
"setSecurityManager", MethodType.methodType(void.class, 
SecurityManager.class));

In Java 17 System::setSecurityManager is now @CS - for a good reason - 
but such a change can break existing code, which should be considered.

>> -----
>>
>> A @CallerSensitive method have one benefit over passing a 
>> MethodHandles.Lookup: It has a nicer API.
>> This might be fine for the restricted methods that Panama introduces.
>>
>> New methods that need to take the caller into account could for 
>> example add instead an overload that takes an explicit 
>> MethodHandles.Lookup as argument. The one without that argument could 
>> work as if `MethodHandles.publicLookup()` was passed to the other.
>>
>> -----
>>
>> Closing words:
>> This is my personal opinion, and might be totally wrong.
>> For now, my goal is just to start a discussion.
>>
>> I explicitly don't ask about changing existing @CallerSensitive methods.
> 
> 
> Good.? The categories I described above hope will give more context and 
> explain the considerations to have for new APIs.
> 
> Mandy
> 
>> - Johannes
>>
>> [1]: 
>> https://www.oracle.com/java/technologies/javase/seccodeguide.html#9-8

[2]: https://cr.openjdk.org/~jrose/values/encapsulating-val.html

From cstein at openjdk.org  Fri Apr 21 21:07:42 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 21 Apr 2023 21:07:42 GMT
Subject: RFR: JDK-8304036: Use CommandLine class from shared module
In-Reply-To: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
References: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
Message-ID: <rl2ep36QzuzNhMhvVaiHc7yOEC5eKKQrRXeA67_Q9SQ=.93442238-2c40-46e9-a478-90ef3c0794a4@github.com>

On Mon, 13 Mar 2023 08:16:54 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
> - #11272
> 
> Changes:
> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc`
> - [x] Use shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module

Converted this PR to draft mode until boot JDK is updated to 20.

- https://bugs.openjdk.org/browse/JDK-8296153 "Bump minimum boot jdk to JDK 20"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12997#issuecomment-1465706849

From jjg at openjdk.org  Fri Apr 21 21:07:42 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 21 Apr 2023 21:07:42 GMT
Subject: RFR: JDK-8304036: Use CommandLine class from shared module
In-Reply-To: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
References: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
Message-ID: <ED0dgO6MqmEnU6ZnKjct4S5x8MMHoimg5kCVHdy0IRM=.f1ea4dde-95f7-46b1-84d7-ce856c297da9@github.com>

On Mon, 13 Mar 2023 08:16:54 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
> - #11272
> 
> Changes:
> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc`
> - [x] Use shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module

Looks good, for when un-Draft-ed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12997#issuecomment-1487214895

From cstein at openjdk.org  Fri Apr 21 21:14:00 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 21 Apr 2023 21:14:00 GMT
Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v2]
In-Reply-To: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
References: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
Message-ID: <8w871xPAhwGr0SRBhYkJKg6kpIZXHfPYaEbH4vP4hoM=.cb462f6e-d5cc-462b-8db3-898f39cd03dc@github.com>

> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
> - #11272
> 
> Changes:
> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc`
> - [x] Use shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module

Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8304036-reusable-command-line-part-2
 - Add missing import
 - JDK-8304036: Use CommandLine class from shared module

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12997/files
  - new: https://git.openjdk.org/jdk/pull/12997/files/405091f9..7e05ad8d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=00-01

  Stats: 375645 lines in 3690 files changed: 296166 ins; 52578 del; 26901 mod
  Patch: https://git.openjdk.org/jdk/pull/12997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12997/head:pull/12997

PR: https://git.openjdk.org/jdk/pull/12997

From mandy.chung at oracle.com  Fri Apr 21 21:37:07 2023
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Fri, 21 Apr 2023 14:37:07 -0700
Subject: Discussion: Prefer passing MethodHandles.Lookup over
 @CallerSensitive
In-Reply-To: <ae9106bc-7dce-9300-65cb-ce2de4ecb0dc@j-kuhn.de>
References: <dbfe269b-78e2-5c85-9200-5d949dfe1ecf@j-kuhn.de>
 <5ab172ba-26cf-8873-b803-fe7871c6be21@oracle.com>
 <ae9106bc-7dce-9300-65cb-ce2de4ecb0dc@j-kuhn.de>
Message-ID: <8c3ab8c0-752e-c3d6-6c68-4df4f7042f04@oracle.com>


On 4/21/23 1:58 PM, Johannes Kuhn wrote:
>>> 5. Making existing methods @CallerSensitive can lead to small 
>>> backwards compatibility issues - as the public lookup can't lookup 
>>> those methods anymore.
>>>
>> Can you explain what you observe about this??? Public lookup has 
>> access to public members of public classes in packages that are 
>> exported unconditionally. ?? @CS should have no impact to public lookup.
>>
>>
>
> This line works with Java 7 - 16:
>
> ??? MethodHandles.publicLookup().findStatic(System.class, 
> "setSecurityManager", MethodType.methodType(void.class, 
> SecurityManager.class));
>
> In Java 17 System::setSecurityManager is now @CS - for a good reason - 
> but such a change can break existing code, which should be considered. 


Yes, this is an unfortunate case that we didn't catch this 
incompatibility.? @CS System::setSecurityManager is another category 
which I can't think of a better term yet and so just call it 
"serviceability or reliability" - setSecurityManager uses the caller to 
emit warning with caller information to provide better guidance. ? As 
more runtime will be implemented in Java than in native, we may see more 
of this.

Mandy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230421/a8927080/attachment.htm>

From jjg at openjdk.org  Fri Apr 21 21:42:47 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 21 Apr 2023 21:42:47 GMT
Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v2]
In-Reply-To: <8w871xPAhwGr0SRBhYkJKg6kpIZXHfPYaEbH4vP4hoM=.cb462f6e-d5cc-462b-8db3-898f39cd03dc@github.com>
References: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
 <8w871xPAhwGr0SRBhYkJKg6kpIZXHfPYaEbH4vP4hoM=.cb462f6e-d5cc-462b-8db3-898f39cd03dc@github.com>
Message-ID: <UKdWepfFgaK-vTcOut4StI9wAfbELUJa2rlnLzFM_pQ=.95d5e276-7d73-4e85-901c-8e8b0254778d@github.com>

On Fri, 21 Apr 2023 21:14:00 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
>> - #11272
>> 
>> Changes:
>> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc`
>> - [x] Use shared `CommandLine.java` in `jdk.compiler` module
>> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
>> - [x] Remove `CommandLine.java` from `jdk.compiler` module
>
> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8304036-reusable-command-line-part-2
>  - Add missing import
>  - JDK-8304036: Use CommandLine class from shared module

Marked as reviewed by jjg (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12997#pullrequestreview-1396422793

From mchung at openjdk.org  Fri Apr 21 21:45:46 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 21 Apr 2023 21:45:46 GMT
Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v2]
In-Reply-To: <8w871xPAhwGr0SRBhYkJKg6kpIZXHfPYaEbH4vP4hoM=.cb462f6e-d5cc-462b-8db3-898f39cd03dc@github.com>
References: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
 <8w871xPAhwGr0SRBhYkJKg6kpIZXHfPYaEbH4vP4hoM=.cb462f6e-d5cc-462b-8db3-898f39cd03dc@github.com>
Message-ID: <aP961oUZ9q46E9OXE2WJY2vWjYtLA7sKNIdr7stJ32w=.f493f441-42d5-4111-b00f-86617ff6e28a@github.com>

On Fri, 21 Apr 2023 21:14:00 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
>> - #11272
>> 
>> Changes:
>> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc`
>> - [x] Use shared `CommandLine.java` in `jdk.compiler` module
>> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
>> - [x] Remove `CommandLine.java` from `jdk.compiler` module
>
> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8304036-reusable-command-line-part-2
>  - Add missing import
>  - JDK-8304036: Use CommandLine class from shared module

src/jdk.internal.opt/share/classes/module-info.java line 33:

> 31: module jdk.internal.opt {
> 32:     exports jdk.internal.joptsimple to jdk.jlink, jdk.jshell;
> 33:     exports jdk.internal.opt to jdk.compiler, jdk.jartool, jdk.javadoc, jdk.jlink, jdk.jpackage;

Nit: line break at each module is easier to read and avoid long line like:
   https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/module-info.java#L149

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12997#discussion_r1174181399

From smarks at openjdk.org  Fri Apr 21 22:18:11 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 21 Apr 2023 22:18:11 GMT
Subject: RFR: 8266571: Sequenced Collections [v8]
In-Reply-To: <OKv7JIh0Sw-bk4Xf1Wixv_pgSA-JKjF9SqLRYp_OMRw=.036864e8-3e65-45ef-9714-e3e0f3e0b133@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <xhWK9e-orFi_yRPH1xyUWf2ye5tP1BrysvQrLhqCLbY=.c316918e-793f-4bdc-bee6-c5267efa6c5c@github.com>
 <OKv7JIh0Sw-bk4Xf1Wixv_pgSA-JKjF9SqLRYp_OMRw=.036864e8-3e65-45ef-9714-e3e0f3e0b133@github.com>
Message-ID: <IFL795ayUetxrztQ79-ahEgJXZbejb_irs7T8UaFDBM=.c8e16b19-6452-4f04-a303-023a30471b43@github.com>

On Thu, 20 Apr 2023 12:09:52 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Add missing @throws and @since tags.
>>  - Convert code samples to snippets.
>>  - Various editorial changes.
>>  - Fix up toArray(T[]) on reverse-ordered views.
>
> src/java.base/share/classes/java/util/SequencedMap.java line 127:
> 
>> 125:      * Returns a reverse-ordered <a href="Collection.html#view">view</a> of this map.
>> 126:      * The encounter order of elements in the returned view is the inverse of the encounter
>> 127:      * order of elements in this map. The reverse ordering affects all order-sensitive operations,
> 
> Although I think this is clear as-is, you defined *encounter order* in a map with respect to mappings, not elements, and that is also the language used in the methods here, so you might want to use this language here too.

Yes, should be mappings, not elements.

> src/java.base/share/classes/java/util/SequencedMap.java line 152:
> 
>> 150:         var it = entrySet().iterator();
>> 151:         return it.hasNext() ? Map.Entry.copyOf(it.next()) : null;
>> 152:     }
> 
> Would is be better to first check `Map.isEmpty()` and only then obtain the iterator? That would eliminate also the `hasNext` check.
> 
> default Map.Entry<K,V> firstEntry() {
>     return isEmpty() ? null : Map.Entry.copyOf(entrySet().iterator().next());
> }
> 
> 
> Same question for the other methods.

Might not work if this map is concurrent. If isEmpty() returns false but then the map is emptied before the subsequent calls, next() might throw NSEE. The concurrent maps' iterators make sure to cache the element if hasNext() has returned true.

> src/java.base/share/classes/java/util/SequencedMap.java line 263:
> 
>> 261:      *
>> 262:      * @implSpec
>> 263:      * The implementation of this method in this class returns a {@code SequencedSet}
> 
> Some of the methods here use "of this method" and some skip it, noting in case you want to streamline it.

Yes my previous standard wording included "of this method" but I forgot to take it out here. Incidentally @jddarcy convinced me to change "class" to "interface" here and in all other interface default methods, so I'll do that as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1174193560
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1174194746
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1174195143

From smarks at openjdk.org  Fri Apr 21 22:24:12 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 21 Apr 2023 22:24:12 GMT
Subject: RFR: 8266571: Sequenced Collections [v8]
In-Reply-To: <OKv7JIh0Sw-bk4Xf1Wixv_pgSA-JKjF9SqLRYp_OMRw=.036864e8-3e65-45ef-9714-e3e0f3e0b133@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <xhWK9e-orFi_yRPH1xyUWf2ye5tP1BrysvQrLhqCLbY=.c316918e-793f-4bdc-bee6-c5267efa6c5c@github.com>
 <OKv7JIh0Sw-bk4Xf1Wixv_pgSA-JKjF9SqLRYp_OMRw=.036864e8-3e65-45ef-9714-e3e0f3e0b133@github.com>
Message-ID: <YfCK-eQT1jC_Qnt4Cy5ayHCPsbxeDEqnme4WrfhLubU=.ac0ead5d-aa30-4818-a7c4-a855dbf69373@github.com>

On Thu, 20 Apr 2023 12:30:52 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Add missing @throws and @since tags.
>>  - Convert code samples to snippets.
>>  - Various editorial changes.
>>  - Fix up toArray(T[]) on reverse-ordered views.
>
> src/java.base/share/classes/java/util/NavigableMap.java line 442:
> 
>> 440:      * @return a reverse-ordered view of this map, as a {@code NavigableMap}
>> 441:      * @since 21
>> 442:      */
> 
> `NavigableSet` words its `reversed` doc a bit differently.

Adjusted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1174196958

From smarks at openjdk.org  Fri Apr 21 22:33:13 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 21 Apr 2023 22:33:13 GMT
Subject: RFR: 8266571: Sequenced Collections [v10]
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: <oxK5LFwLX41vHM85KD_y1RzXqWrXjvKJmYRvUPAdlIk=.b03dc360-e7e3-41dd-ba65-27a45a2470b8@github.com>

> PR for Sequenced Collections implementation.

Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:

 - Wording tweaks to SequencedMap / NavigableMap.
 - Change "The implementation in this class" to "... interface."

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7387/files
  - new: https://git.openjdk.org/jdk/pull/7387/files/b59f8dda..dc23a48f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=08-09

  Stats: 42 lines in 8 files changed: 2 ins; 0 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/7387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/7387/head:pull/7387

PR: https://git.openjdk.org/jdk/pull/7387

From liach at openjdk.org  Sat Apr 22 01:28:44 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 22 Apr 2023 01:28:44 GMT
Subject: RFR: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: <5OfkgMk9QSD9KVNidbMkk1xpargpO2NNIolCDOGCWQ4=.40fb9ce2-ad17-48ed-aa3e-35cabf82a146@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>
 <5OfkgMk9QSD9KVNidbMkk1xpargpO2NNIolCDOGCWQ4=.40fb9ce2-ad17-48ed-aa3e-35cabf82a146@github.com>
Message-ID: <9_jQnv5QwvqtYgnrbdKZu-HMI1WvT61AmJpWWsiDbyA=.5b631013-da40-4c83-9148-afe9b489760c@github.com>

On Fri, 21 Apr 2023 15:41:55 GMT, Andy-Tatman <duke at openjdk.org> wrote:

> I would be happy to fill out the CSR, but unfortunately I don't think I am able to currently as I'm not an author on OpenJDK and as such don't have a JBS account. (I reported the bug through the Oracle site, rather than through bugs.openjdk.org .) Would you be able to help out with this?

You can provide text for the Summary, Problem, Solution, and Specification parts of the CSR in this GitHub pull request, and I can help create a CSR for you with your provided contents. See https://wiki.openjdk.org/display/csr/Fields+of+a+CSR+Request

 - The Summary describes your CSR in a few concise sentences, like "Reject interactions with Integer.MAX_VALUE bit in BitSet"
 - The Problem is what prompts the CSR, for example, it may be `BitSet.length()` may return a negative value when the `Integer.MAX_VALUE` bit is set on a non-sticky-sized bitset, created either by setting `Integer.MAX_VALUE` bit or passing in very huge buffer or arrays in `valueOf` factories.
 - The Solution is what resolves the problem described in this CSR, for example, it may be that we explicitly reject interacting with `Integer.MAX_VALUE` bit; and for array/buffer-initialized bitsets, we ignore bits higher than or equal to `Integer.MAX_VALUE `(or throw an exception if such an instance is attempted to be created), so we always have a nonnegative int length().
   - I personally recommend silently ignoring `Integer.MAX_VALUE` bit and truncating everything else beyond than throwing, since currently, all bits beyond are inaccessible due to rejection of negative indices
 - The Specification is usually the Javadoc changes that describes these behavior changes. For example, you may edit the specification of `length()` to indicate it returns nonnegative; edit the specification of `valueOf()` to indicate the bits higher than or equal to Integer.MAX_VALUE are ignored (or throw an exception to prevent such creations); and edit the specification of other methods `set` `get` etc. to reject `Integer.MAX_VALUE` as an inclusive upper-bound by throwing an `IndexOutOfRangeException`.
   - The specification changes is usually rendered as a git patch, so you can just commit your code in this pr and I can generate a patch as specification for you.

Also, you need to describe the compatibility risk: It should be "low", as existing users that access `Integer.MAX_VALUE` bit will fail in all non-sticky-sized modes. The changes to `valueOf` behavior (either silently ignore `Integer.MAX_VALUE` bit or throwing) should be mentioned as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1518458234

From jwaters at openjdk.org  Sat Apr 22 04:29:52 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 22 Apr 2023 04:29:52 GMT
Subject: RFR: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names [v3]
In-Reply-To: <ovZuL7DRkKDiciWjLvwKQeU5v7JfqJDSbVqdt4-gfeA=.ae6c5502-5578-42c0-8ffe-b71d0df1ea7a@github.com>
References: <qPi1G8HdwBIoUmQ--9u9wgpHIhNtzrezO8qqzU-KmR8=.c759c5a4-a4c5-4a68-aed3-e65884eab381@github.com>
 <ovZuL7DRkKDiciWjLvwKQeU5v7JfqJDSbVqdt4-gfeA=.ae6c5502-5578-42c0-8ffe-b71d0df1ea7a@github.com>
Message-ID: <Ad1jBXV9yc5YieMqjVnwKBeCJJy96xJfu-CopR4xnWI=.6389e14f-e758-41fd-9f4a-7d4e957cf766@github.com>

On Fri, 24 Mar 2023 06:42:30 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> After merging master into https://github.com/openjdk/jdk/pull/9862, we encountered test failures (e.g., https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). The Classfile API tries to read from constant pool index 0 if a MethodParameters attribute has an entry without name.
>> 
>> The fix is simply using `readUtf8EntryOrNull` instead of `readUtf8Entry`. The related code already correctly handles nullability.
>> 
>> I didn't find an appropriate test class so I added a new one. Let me know if there's a better place or if the test can be improved somehow.
>> 
>> As I don't have a JBS account, someone needs to create a bug report there for me. Thanks.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move and fix test comment

Keeping alive

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13167#issuecomment-1518505245

From smarks at openjdk.org  Sat Apr 22 05:25:43 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 22 Apr 2023 05:25:43 GMT
Subject: RFR: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: <9_jQnv5QwvqtYgnrbdKZu-HMI1WvT61AmJpWWsiDbyA=.5b631013-da40-4c83-9148-afe9b489760c@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>
 <5OfkgMk9QSD9KVNidbMkk1xpargpO2NNIolCDOGCWQ4=.40fb9ce2-ad17-48ed-aa3e-35cabf82a146@github.com>
 <9_jQnv5QwvqtYgnrbdKZu-HMI1WvT61AmJpWWsiDbyA=.5b631013-da40-4c83-9148-afe9b489760c@github.com>
Message-ID: <r2GvoRO-OmwKA-soJEu13TTAEU7W7eyBc77-JXAmrSw=.50eb4c53-068f-4372-9d45-ae895ad77a98@github.com>

On Sat, 22 Apr 2023 01:26:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @AlanBateman I would be happy to fill out the CSR, but unfortunately I don't think I am able to currently as I'm not an author on OpenJDK and as such don't have a JBS account. (I reported the bug through the Oracle site, rather than through bugs.openjdk.org .)
>> Would you be able to help out with this?
>
>> I would be happy to fill out the CSR, but unfortunately I don't think I am able to currently as I'm not an author on OpenJDK and as such don't have a JBS account. (I reported the bug through the Oracle site, rather than through bugs.openjdk.org .) Would you be able to help out with this?
> 
> You can provide text for the Summary, Problem, Solution, and Specification parts of the CSR in this GitHub pull request, and I can help create a CSR for you with your provided contents. See https://wiki.openjdk.org/display/csr/Fields+of+a+CSR+Request
> 
>  - The Summary describes your CSR in a few concise sentences, like "Reject interactions with Integer.MAX_VALUE bit in BitSet"
>  - The Problem is what prompts the CSR, for example, it may be `BitSet.length()` may return a negative value when the `Integer.MAX_VALUE` bit is set on a non-sticky-sized bitset, created either by setting `Integer.MAX_VALUE` bit or passing in very huge buffer or arrays in `valueOf` factories.
>  - The Solution is what resolves the problem described in this CSR, for example, it may be that we explicitly reject interacting with `Integer.MAX_VALUE` bit; and for array/buffer-initialized bitsets, we ignore bits higher than or equal to `Integer.MAX_VALUE `(or throw an exception if such an instance is attempted to be created), so we always have a nonnegative int length().
>    - I personally recommend silently ignoring `Integer.MAX_VALUE` bit and truncating everything else beyond than throwing, since currently, all bits beyond are inaccessible due to rejection of negative indices
>  - The Specification is usually the Javadoc changes that describes these behavior changes. For example, you may edit the specification of `length()` to indicate it returns nonnegative; edit the specification of `valueOf()` to indicate the bits higher than or equal to Integer.MAX_VALUE are ignored (or throw an exception to prevent such creations); and edit the specification of other methods `set` `get` etc. to reject `Integer.MAX_VALUE` as an inclusive upper-bound by throwing an `IndexOutOfRangeException`.
>    - The specification changes is usually rendered as a git patch, so you can just commit your code in this pr and I can generate a patch as specification for you.
> 
> Also, you need to describe the compatibility risk: It should be "low", as existing users that access `Integer.MAX_VALUE` bit will fail in all non-sticky-sized modes. The changes to `valueOf` behavior (either silently ignore `Integer.MAX_VALUE` bit or throwing) should be mentioned as well.

@liach Thanks for offering to help with the CSR.

Before we proceed with the CSR though, we need to decide what to do. I see the initial choice as: either (1) improve the behavior incrementally, by fixing get() for most bits other than the MAX_VALUE bit, and leaving other current misbehaviors as they are; or (2) pursue a comprehensive fix.

Note that (1) does not involve a spec change and thus doesn't require a CSR.

(2) will most likely change the spec and require a CSR. However, if we elect to pursue a comprehensive solution, there will need to be a design discussion. There are a large variety of approaches here. One is to reject setting of the MAX_VALUE bit along the lines of what @liach described above. A variation would be to have the rejection or noisy (i.e., throwing an exception). Still another possibility is to support setting and getting of all non-negative bits, with special-case behavior (e.g., returning MIN_VALUE in certain cases), and possibly also adding long-returning or -accepting APIs that provide sensible behaviors for the full range of bits.

There are also other possibilities, such as investigating sparse bitsets. That would be a big project, and would most likely involve investigating and doing something with external libraries such as [Roaring Bitmaps](https://roaringbitmap.org/). While interesting, I'd say that's out of scope for what started out as a simple bugfix.

What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1518515543

From nlisker at openjdk.org  Sat Apr 22 07:59:09 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 22 Apr 2023 07:59:09 GMT
Subject: RFR: 8266571: Sequenced Collections [v8]
In-Reply-To: <IFL795ayUetxrztQ79-ahEgJXZbejb_irs7T8UaFDBM=.c8e16b19-6452-4f04-a303-023a30471b43@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <xhWK9e-orFi_yRPH1xyUWf2ye5tP1BrysvQrLhqCLbY=.c316918e-793f-4bdc-bee6-c5267efa6c5c@github.com>
 <OKv7JIh0Sw-bk4Xf1Wixv_pgSA-JKjF9SqLRYp_OMRw=.036864e8-3e65-45ef-9714-e3e0f3e0b133@github.com>
 <IFL795ayUetxrztQ79-ahEgJXZbejb_irs7T8UaFDBM=.c8e16b19-6452-4f04-a303-023a30471b43@github.com>
Message-ID: <E658tsKckNP8NZN3GI__AEd7P8SjsBjgT1O-e0cTJww=.bc09e708-f6f0-408f-a007-7b2a17fcc9ba@github.com>

On Fri, 21 Apr 2023 22:14:58 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/SequencedMap.java line 152:
>> 
>>> 150:         var it = entrySet().iterator();
>>> 151:         return it.hasNext() ? Map.Entry.copyOf(it.next()) : null;
>>> 152:     }
>> 
>> Would is be better to first check `Map.isEmpty()` and only then obtain the iterator? That would eliminate also the `hasNext` check.
>> 
>> default Map.Entry<K,V> firstEntry() {
>>     return isEmpty() ? null : Map.Entry.copyOf(entrySet().iterator().next());
>> }
>> 
>> 
>> Same question for the other methods.
>
> Might not work if this map is concurrent. If isEmpty() returns false but then the map is emptied before the subsequent calls, next() might throw NSEE. The concurrent maps' iterators make sure to cache the element if hasNext() has returned true.

Then shouldn't `ConcurrentNavigableMap`, the only `ConcurrentMap` and `SequencedMap` supertype (there is no `ConcurrentSortedMap`), override its superinterface implementation with this thread-safe one?

I think that the question boils down to: should `SequencedMap` take into account the needs of its subtypes and give a conservative default implementation, or should it give a "minimal" implementation and let the subtypes override it according to their needs? I would choose the latter, both because `SequencedMap` specifies no guarantees on thread-safety (atomicity and synchronization), and because `Map`'s default implementation behave this way  - `compute`, `merge`... tell concurrent implementations how to override them.

Now if someone implements a `SequencedMap` that is also a `ConcurrentMap`, but is not a `NavigableMap`, say `ConcurrentLinkedHashMap`, they will override the `SequencedMap` defaults like they would the `Map` defaults.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1174327323

From alanb at openjdk.org  Sat Apr 22 09:00:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 22 Apr 2023 09:00:51 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v10]
In-Reply-To: <wSCu12OAVkXv-ZM3ltW9vGs27ZkJGHDvRXuS-fJ2w8M=.11113269-945b-4b3f-a580-0cd78dbf2c95@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <wSCu12OAVkXv-ZM3ltW9vGs27ZkJGHDvRXuS-fJ2w8M=.11113269-945b-4b3f-a580-0cd78dbf2c95@github.com>
Message-ID: <8qww81xiEqAhMY3DEwv7QL-gpWcrGq9QJnK4VuKqqhM=.54ddcbb8-eb51-467e-babe-1cba559c1b43@github.com>

On Fri, 21 Apr 2023 13:21:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
>> 
>> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
>> 
>> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
>> 
>> Additional testing:
>>   - [x] New regression test
>>   - [x] New benchmark
>>   - [x] Linux x86_64 `tier1`
>>   - [x] Linux AArch64 `tier1`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>  - Drop nanos_to_nanos_bounded
>  - Handle overflows
>  - More review comments
>  - Adjust test times
>  - Windows again
>  - Windows fixes: align(...) is only for power-of-two alignments
>  - Adjust assert
>  - Replace (park|sleep)_millis back with just (park|sleep)
>  - More review touchups
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/5a00617b...a0c35f45

I don't have any other comments on this change, looks good.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13225#pullrequestreview-1396637701

From duke at openjdk.org  Sat Apr 22 09:25:45 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 22 Apr 2023 09:25:45 GMT
Subject: RFR: 8306678: Replace use of os.version with an internal Version
 record
In-Reply-To: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
Message-ID: <nB6JI_xtOrZy8yLkt6FknYlwLdldjqdAwaBC3Aropis=.d9525798-a0f4-4fac-a051-b2d6ed332e61@github.com>

On Fri, 21 Apr 2023 16:44:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Create an internal Version record to hold and compare versions of the form (major, minor, micro).
> Add `OperatingSystem.version()` to return the version of the running OS.
> Replace uses of os.version in java.base.
> Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.

src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java line 103:

> 101:                 // fgetxattr broken on APFS prior to 10.14
> 102:                 return OperatingSystem.version()
> 103:                         .compareTo(new Version(10, 14)) >= 0;

The `Version(10,?14)` record should?probably be?stored in?a?static?constant.

src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 150:

> 148: 
> 149:     // Parse and save the current version
> 150:     private static Version osVersion = initVersion();

The?version?field should?probably be?`final`:
Suggestion:

    public static Version version() {
        return CURRENT_VERSION;
    }

    // Parse and save the current version
    private static final Version CURRENT_VERSION = initVersion();

src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 157:

> 155:             return Version.parse(osVer);
> 156:         } catch (IllegalArgumentException ile) {
> 157:             throw new AssertionError("os.version malformed: " + osVer);

This?should probably?preserve the?`IllegalArgumentException` stack?trace:
Suggestion:

        } catch (IllegalArgumentException iae) {
            throw new AssertionError("os.version malformed: " + osVer, iae);


And?maybe throw?`InternalError`?instead:
Suggestion:

        } catch (IllegalArgumentException iae) {
            throw new InternalError("os.version malformed: " + osVer, iae);

test/jdk/jdk/internal/util/VersionTest.java line 96:

> 94:                 Arguments.of(new Version(3, 3, 1), new Version(3, 3, 1), 0),
> 95:                 Arguments.of(new Version(3, 3, 1), new Version(3, 3, 0), 1),
> 96:                 Arguments.of(new Version(3, 3, 0), new Version(3, 3, 1), -1)

This?should probably include?tests for?differing `major`?versions as?well:
Suggestion:

                Arguments.of(new Version(2, 1), new Version(2, 1), 0),
                Arguments.of(new Version(2, 1), new Version(2, 0), +1),
                Arguments.of(new Version(2, 0), new Version(2, 1), -1),
                Arguments.of(new Version(3, 3, 1), new Version(3, 3, 1), 0),
                Arguments.of(new Version(3, 3, 1), new Version(3, 3, 0), +1),
                Arguments.of(new Version(3, 3, 0), new Version(3, 3, 1), -1),
                Arguments.of(new Version(2, 0), new Version(3, 0), -1),
                Arguments.of(new Version(3, 0), new Version(2, 0), +1)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1174347678
PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1174346831
PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1174345782
PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1174347449

From duke at openjdk.org  Sat Apr 22 09:44:09 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 22 Apr 2023 09:44:09 GMT
Subject: RFR: 8266571: Sequenced Collections [v10]
In-Reply-To: <oxK5LFwLX41vHM85KD_y1RzXqWrXjvKJmYRvUPAdlIk=.b03dc360-e7e3-41dd-ba65-27a45a2470b8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <oxK5LFwLX41vHM85KD_y1RzXqWrXjvKJmYRvUPAdlIk=.b03dc360-e7e3-41dd-ba65-27a45a2470b8@github.com>
Message-ID: <8GjzQjfHUceverRHKnB9oXNb5kPfWYai-Va6pc4DjM0=.fff2f752-d47d-4991-9e68-e100f8909f36@github.com>

On Fri, 21 Apr 2023 22:33:13 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Wording tweaks to SequencedMap / NavigableMap.
>  - Change "The implementation in this class" to "... interface."

src/java.base/share/classes/java/util/AbstractMap.java line 900:

> 898:      */
> 899:     /* non-public */ abstract static class ViewCollection<E> implements Collection<E> {
> 900:         UnsupportedOperationException uoe() { return new UnsupportedOperationException(); }

This?doesn?t need?to?be an?instance?method:
Suggestion:

        static UnsupportedOperationException uoe() { return new UnsupportedOperationException(); }

src/java.base/share/classes/java/util/SortedMap.java line 113:

> 111:  */
> 112: 
> 113: public interface SortedMap<K,V> extends SequencedMap<K,V> {

This?interface can?now?provide default?implementations for?the?`firstKey` and?`lastKey`?methods:

default K firstKey() {
	var entry = this.firstEntry();
	if (entry == null) {
		throw new NoSuchElementException();
	}
	return entry.getKey();
}


default K lastKey() {
	var entry = this.lastEntry();
	if (entry == null) {
		throw new NoSuchElementException();
	}
	return entry.getKey();
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1174349716
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1174351159

From duke at openjdk.org  Sat Apr 22 09:44:10 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 22 Apr 2023 09:44:10 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: <J8lIHB1anY5NocXSSpu3y3K_L-dFZ7boHlVn4BGcc9o=.0c7b702f-5710-4d7e-a588-e7a3a5c93d29@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <AVG0xaAX6FZuBx6zF9rv4HYkltv47a1-uGPJazz0avc=.b2c275f6-807b-4817-89b1-8fc3374de933@github.com>
 <QzEjdyEzPzOPJq9Z01nsIcMDAIhzamM3wkHTdX8KTl4=.eb101a67-63dc-41ea-9e1d-709cf3366c98@github.com>
 <J8lIHB1anY5NocXSSpu3y3K_L-dFZ7boHlVn4BGcc9o=.0c7b702f-5710-4d7e-a588-e7a3a5c93d29@github.com>
Message-ID: <kj2wnXzAikRhpCQSCVOry25vfd4oqU8QX1jKo1XwzbM=.40d07db5-13b4-4e5c-92dc-5ea68a69667d@github.com>

On Wed, 19 Apr 2023 02:43:53 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/LinkedHashSet.java line 297:
>> 
>>> 295:      */
>>> 296:     public SequencedSet<E> reversed() {
>>> 297:         class ReverseLinkedHashSetView extends AbstractSet<E> implements SequencedSet<E> {
>> 
>> This class should be declared `static` (and private) which means it should not be declared inside reversed.
>
> Can't be static because it uses type variable `E` and also refers to `this`.

It?can?still be?a?`private` inner?class, as?opposed to?a?method?class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1174349916

From Alan.Bateman at oracle.com  Sat Apr 22 10:03:17 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 22 Apr 2023 11:03:17 +0100
Subject: Discussion: Prefer passing MethodHandles.Lookup over
 @CallerSensitive
In-Reply-To: <8c3ab8c0-752e-c3d6-6c68-4df4f7042f04@oracle.com>
References: <dbfe269b-78e2-5c85-9200-5d949dfe1ecf@j-kuhn.de>
 <5ab172ba-26cf-8873-b803-fe7871c6be21@oracle.com>
 <ae9106bc-7dce-9300-65cb-ce2de4ecb0dc@j-kuhn.de>
 <8c3ab8c0-752e-c3d6-6c68-4df4f7042f04@oracle.com>
Message-ID: <ab028319-6553-9139-90ed-319b20fe5316@oracle.com>



On 21/04/2023 22:37, mandy.chung at oracle.com wrote:
>
> :
>
> On 4/21/23 1:58 PM, Johannes Kuhn wrote:
>>
>> This line works with Java 7 - 16:
>>
>> ??? MethodHandles.publicLookup().findStatic(System.class, 
>> "setSecurityManager", MethodType.methodType(void.class, 
>> SecurityManager.class));
>>
>> In Java 17 System::setSecurityManager is now @CS - for a good reason 
>> - but such a change can break existing code, which should be considered. 
>
>
> Yes, this is an unfortunate case that we didn't catch this 
> incompatibility.? @CS System::setSecurityManager is another category 
> which I can't think of a better term yet and so just call it 
> "serviceability or reliability" - setSecurityManager uses the caller 
> to emit warning with caller information to provide better guidance. ? 
> As more runtime will be implemented in Java than in native, we may see 
> more of this.
>
Yes, a small compatibility issue but one that I wouldn't expect many 
would run into specific issue, that is, I wouldn't expect to see real 
code wanting to set a SM using reflection code and a restricted Lookup 
object. I'm curious if you actually ran into this or it is used as an 
example? Maybe a framework or tool that is creating a MH for all public 
methods and tripping up on @CS methods?

-Alan


From cstein at openjdk.org  Sat Apr 22 11:42:52 2023
From: cstein at openjdk.org (Christian Stein)
Date: Sat, 22 Apr 2023 11:42:52 GMT
Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v3]
In-Reply-To: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
References: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
Message-ID: <ox69C37ql1-XFVuQJXjiLrteaw7mbP1lC6vIRdu9c74=.47b90b6e-a0b6-43a8-808c-a92dca0576d6@github.com>

> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
> - #11272
> 
> Changes:
> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc`
> - [x] Use shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Improve formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12997/files
  - new: https://git.openjdk.org/jdk/pull/12997/files/7e05ad8d..163fcbfe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=01-02

  Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12997/head:pull/12997

PR: https://git.openjdk.org/jdk/pull/12997

From cstein at openjdk.org  Sat Apr 22 11:42:58 2023
From: cstein at openjdk.org (Christian Stein)
Date: Sat, 22 Apr 2023 11:42:58 GMT
Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v2]
In-Reply-To: <aP961oUZ9q46E9OXE2WJY2vWjYtLA7sKNIdr7stJ32w=.f493f441-42d5-4111-b00f-86617ff6e28a@github.com>
References: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
 <8w871xPAhwGr0SRBhYkJKg6kpIZXHfPYaEbH4vP4hoM=.cb462f6e-d5cc-462b-8db3-898f39cd03dc@github.com>
 <aP961oUZ9q46E9OXE2WJY2vWjYtLA7sKNIdr7stJ32w=.f493f441-42d5-4111-b00f-86617ff6e28a@github.com>
Message-ID: <YnDq__gkVF6J_npjIBbCsG5gKXCNORvQTtGVdzLMLlA=.1fe376d2-2d40-4982-8f8d-eec037f9ffff@github.com>

On Fri, 21 Apr 2023 21:42:58 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8304036-reusable-command-line-part-2
>>  - Add missing import
>>  - JDK-8304036: Use CommandLine class from shared module
>
> src/jdk.internal.opt/share/classes/module-info.java line 33:
> 
>> 31: module jdk.internal.opt {
>> 32:     exports jdk.internal.joptsimple to jdk.jlink, jdk.jshell;
>> 33:     exports jdk.internal.opt to jdk.compiler, jdk.jartool, jdk.javadoc, jdk.jlink, jdk.jpackage;
> 
> Nit: line break at each module is easier to read and avoid long line like:
>    https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/module-info.java#L149

Yes, that's much nicer. Will reflow all other export directives as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12997#discussion_r1174387317

From cstein at openjdk.org  Sat Apr 22 11:59:32 2023
From: cstein at openjdk.org (Christian Stein)
Date: Sat, 22 Apr 2023 11:59:32 GMT
Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v4]
In-Reply-To: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
References: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
Message-ID: <xdCe-oSYYq5GfejhXSoKj2lxrsGD7McWp8zi8scyg38=.3a76c035-ffc9-47c2-bfa4-635251029527@github.com>

> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
> - #11272
> 
> Changes:
> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc`
> - [x] Use shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Update CompileInterimLangtools.gmk

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12997/files
  - new: https://git.openjdk.org/jdk/pull/12997/files/163fcbfe..39eb626c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12997/head:pull/12997

PR: https://git.openjdk.org/jdk/pull/12997

From duke at openjdk.org  Sat Apr 22 12:11:44 2023
From: duke at openjdk.org (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Sat, 22 Apr 2023 12:11:44 GMT
Subject: RFR: 8304917: Remove unused function declarations in
 check_classname.h
In-Reply-To: <Nba8lcasOnPYCR6EDc7J5h0xLZFR0Q2h89WTWvazZlY=.d2d32ff7-85a0-428c-993e-28028736e377@github.com>
References: <Nba8lcasOnPYCR6EDc7J5h0xLZFR0Q2h89WTWvazZlY=.d2d32ff7-85a0-428c-993e-28028736e377@github.com>
Message-ID: <1xzxxFINqipKbaHv_t8IllVrjxtY_gxwZ7bGFDjwzkA=.8044a53c-c104-41c7-8401-3441d8bc957f@github.com>

On Fri, 17 Mar 2023 14:17:00 GMT, Thiago Henrique H?pner <duke at openjdk.org> wrote:

> Both functions "VerifyClassname" and "VerifyFixClassname" are not used. The functions that are used in the Class.c are "verifyClassname" and "verifyFixClassname", which are declared in the "check_classname.h" header

Could someone please review it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13077#issuecomment-1518630758

From cstein at openjdk.org  Sat Apr 22 12:15:38 2023
From: cstein at openjdk.org (Christian Stein)
Date: Sat, 22 Apr 2023 12:15:38 GMT
Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v5]
In-Reply-To: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
References: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
Message-ID: <O0pgPzx4KLyyX-_yuJYd97cgTFCPOp_dY62qSEbtl7U=.000949af-d686-4e61-a2e4-980549eeed59@github.com>

> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
> - #11272
> 
> Changes:
> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc`
> - [x] Use shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Export `jdk.internal.opt` to `jdk.javadoc.interim`, too

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12997/files
  - new: https://git.openjdk.org/jdk/pull/12997/files/39eb626c..f9a94225

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=03-04

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12997/head:pull/12997

PR: https://git.openjdk.org/jdk/pull/12997

From liach at openjdk.org  Sat Apr 22 15:21:41 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 22 Apr 2023 15:21:41 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info in
 ClassDesc
Message-ID: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>

Add a method `internalName` (name subject to discussion) to `ClassDesc`, which allows easily obtaining a String for representation of a class constant in CONSTANT_Class_info.

The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.

This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.

Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html#internalName()

For the method name: `internalName` is intuitive as it is almost like an inverse operation of `ofInternalName`, but the concept of internal name only applies to classes and interfaces (as described in [JVMS 4.4.1](https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.4.1)) and doesn't apply to arrays. And internal names (binary name in internal form) is useless outside of CONSTANT_Class_info; other usages are already covered by `descriptorString`. If we stay on the naming of "internal name" (which I would prefer), we might expand it and potentially upgrade `ofInternalName` to take care of future CONSTANT_Class_info content (like Q-types)

-------------

Commit messages:
 - 8306697: Add method to obtain String for CONSTANT_Class_info in ClassDesc

Changes: https://git.openjdk.org/jdk/pull/13598/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13598&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306697
  Stats: 46 lines in 4 files changed: 39 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13598/head:pull/13598

PR: https://git.openjdk.org/jdk/pull/13598

From lbourges at openjdk.org  Sat Apr 22 16:08:49 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sat, 22 Apr 2023 16:08:49 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v3]
In-Reply-To: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
Message-ID: <XE2DIEVqoq97TQa4KRPOFNVJqbGHz6dvu1m7s3uJXg4=.d669a3a8-96fe-4c10-8b69-dc1bc4176274@github.com>

> * Optimized mixed insertion sort
>     * Optimized insertion sort
>     * Optimized Radix sort
>     * Updated microbenchmark
> 
> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938

Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:

  rewritten radix sort condition + fixed max buffer size

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13568/files
  - new: https://git.openjdk.org/jdk/pull/13568/files/32551f60..ff6b7fcf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=01-02

  Stats: 52 lines in 1 file changed: 13 ins; 8 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/13568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13568/head:pull/13568

PR: https://git.openjdk.org/jdk/pull/13568

From liach at openjdk.org  Sat Apr 22 16:17:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 22 Apr 2023 16:17:42 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc
In-Reply-To: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
Message-ID: <usB-8oLRmFzHAlS-8e3hcabfwObW3u3mTp9Ho6WLdKY=.c2c49531-53b3-477b-8b91-5d48debda204@github.com>

On Sat, 22 Apr 2023 15:12:48 GMT, Chen Liang <liach at openjdk.org> wrote:

> Add a method `internalName` (name subject to discussion) to `ClassDesc`, which allows easily obtaining a String for representation of a class constant in CONSTANT_Class_info.
> 
> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
> 
> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
> 
> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html#internalName()
> 
> For the method name: `internalName` is intuitive as it is almost like an inverse operation of `ofInternalName`, but the concept of internal name only applies to classes and interfaces (as described in [JVMS 4.4.1](https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.4.1)) and doesn't apply to arrays. And internal names (binary name in internal form) is useless outside of CONSTANT_Class_info; other usages are already covered by `descriptorString`. If we stay on the naming of "internal name" (which I would prefer), we might expand it and potentially upgrade `ofInternalName` to take care of future CONSTANT_Class_info content (like Q-types)

After taking a look at https://bugs.openjdk.org/browse/JDK-8278863 #9201, I think we should take a bold step and make `ofInternalName` handle all possible `CONSTANT_Class_info` values:
1. Internal names for classes and interfaces have no merit on their own, and has no usages besides `CONSTANT_Class_info`
2. In the current form, shall future developments like Valhalla add a new form of value to `CONSTANT_Class_info`, users won't be able to reliably convert a `CONSTANT_Class_info` structure into a `ClassDesc`, adding more maintenance burdens.

The decision for `ofInternalName` to accept only class and interface internal names was an ad-hoc decision that was questioned by CSR lead in CSR review as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1518695087

From liach at openjdk.org  Sat Apr 22 16:39:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 22 Apr 2023 16:39:53 GMT
Subject: RFR: 8306698: Add overloads to MethodTypeDesc::of
Message-ID: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>

Please review this patch adding two new convenience methods that allows easier access to MethodTypeDesc instances and its associated CSR as well. This is a necessity to allow #13186 to reduce array copies in a few scenarios; the implementation of the two methods will be updated there.

-------------

Commit messages:
 - 8306698: Add overloads to MethodTypeDesc::of

Changes: https://git.openjdk.org/jdk/pull/13599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13599&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306698
  Stats: 42 lines in 3 files changed: 41 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13599.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13599/head:pull/13599

PR: https://git.openjdk.org/jdk/pull/13599

From liach at openjdk.org  Sat Apr 22 18:40:45 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 22 Apr 2023 18:40:45 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
Message-ID: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>

> Add a method `internalName` (name subject to discussion) to `ClassDesc`, which allows easily obtaining a String for representation of a class constant in CONSTANT_Class_info.
> 
> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
> 
> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
> 
> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html#internalName()
> 
> For the method name: `internalName` is intuitive as it is almost like an inverse operation of `ofInternalName`, but the concept of internal name only applies to classes and interfaces (as described in [JVMS 4.4.1](https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.4.1)) and doesn't apply to arrays. And internal names (binary name in internal form) is useless outside of CONSTANT_Class_info; other usages are already covered by `descriptorString`. If we stay on the naming of "internal name" (which I would prefer), we might expand it and potentially upgrade `ofInternalName` to take care of future CONSTANT_Class_info content (like Q-types)

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13598/files
  - new: https://git.openjdk.org/jdk/pull/13598/files/38cf849d..4620ec2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13598&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13598&range=00-01

  Stats: 50 lines in 2 files changed: 25 ins; 14 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13598/head:pull/13598

PR: https://git.openjdk.org/jdk/pull/13598

From lbourges at openjdk.org  Sat Apr 22 18:41:44 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sat, 22 Apr 2023 18:41:44 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v3]
In-Reply-To: <XE2DIEVqoq97TQa4KRPOFNVJqbGHz6dvu1m7s3uJXg4=.d669a3a8-96fe-4c10-8b69-dc1bc4176274@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <XE2DIEVqoq97TQa4KRPOFNVJqbGHz6dvu1m7s3uJXg4=.d669a3a8-96fe-4c10-8b69-dc1bc4176274@github.com>
Message-ID: <tz8prdaMDy8SC5WE2k13WgngjlVDpgSB7jOTNHh6ptU=.70cf52b0-0f8a-4fbe-9b73-e97cde24f888@github.com>

On Sat, 22 Apr 2023 16:08:49 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> * Optimized mixed insertion sort
>>     * Optimized insertion sort
>>     * Optimized Radix sort
>>     * Updated microbenchmark
>> 
>> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938
>
> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewritten radix sort condition + fixed max buffer size

Benchmark results on macbook pro M2:
https://jmh.morethan.io/?sources=https://raw.githubusercontent.com/bourgesl/bourgesl.github.io/master/jdk-jmh-arraysort/230421/mac-arm64-openjdk21-jmh-result-master.json,https://raw.githubusercontent.com/bourgesl/bourgesl.github.io/master/jdk-jmh-arraysort/230421/mac-arm64-openjdk21-jmh-result-patched.json

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1518724666

From lbourges at openjdk.org  Sat Apr 22 18:47:45 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sat, 22 Apr 2023 18:47:45 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v4]
In-Reply-To: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
Message-ID: <MKgxRYn-GOtEc1vmYioNCRjHUdLDic6DeZL8Zma3VIQ=.83b43221-9321-49d9-9379-85157b7d2593@github.com>

> * Optimized mixed insertion sort
>     * Optimized insertion sort
>     * Optimized Radix sort
>     * Updated microbenchmark
> 
> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938

Laurent Bourg?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'openjdk:master' into dpqs23
 - rewritten radix sort condition + fixed max buffer size
 - optimized radix sort heuristic
 - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
       * Optimized mixed insertion sort
       * Optimized insertion sort
       * Optimized Radix sort
       * Updated microbenchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13568/files
  - new: https://git.openjdk.org/jdk/pull/13568/files/ff6b7fcf..1d4af827

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=02-03

  Stats: 6880 lines in 138 files changed: 3660 ins; 2487 del; 733 mod
  Patch: https://git.openjdk.org/jdk/pull/13568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13568/head:pull/13568

PR: https://git.openjdk.org/jdk/pull/13568

From duke at openjdk.org  Sun Apr 23 05:14:56 2023
From: duke at openjdk.org (duke)
Date: Sun, 23 Apr 2023 05:14:56 GMT
Subject: Withdrawn: 8302267: [jittester] Improve separation of test generation
 and execution
In-Reply-To: <yHw6Lto-nJtPP61cZLDF354osHA-ioeq7_lgpefLvog=.6de22e18-0613-4ffb-a753-b66b95e9d52b@github.com>
References: <yHw6Lto-nJtPP61cZLDF354osHA-ioeq7_lgpefLvog=.6de22e18-0613-4ffb-a753-b66b95e9d52b@github.com>
Message-ID: <ZhVbCTCi2p5XxB4UMRjfOzwlUY9XooS9aEeNS8ZWt3U=.20a30417-2f82-4cb7-bfdd-f67e78d93304@github.com>

On Mon, 13 Feb 2023 09:55:52 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

> Please review a set of improvements that should improve working with other fuzzing generators and usage of JitTesterDriver with tests generated not by the JITTester:
> 
> - Provide better separation of individual test generation from java file writing, compiling, executing, etc.;
> - Introduce distinct Phases of the generation process (Generation, Compilation, GoldRun and VerificationRun);
> - Extract JItTesterDriver headers generation so that it would be possible to provide other header generators;
> - Introduce error tolerance to not get distracted by OOMEs, intrinsics missing in the compiled code, etc.;
> - Make it possible to specify time limit for an individual test generation;
> - Give better control over temp/workdir creation and cleaning;
> - Unify external process running;
> - Introduce UTF-8 support in external processes' output and human-readable escaping of it;

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12527

From duke at openjdk.org  Sun Apr 23 13:09:43 2023
From: duke at openjdk.org (ExE Boss)
Date: Sun, 23 Apr 2023 13:09:43 GMT
Subject: RFR: 8306698: Add overloads to MethodTypeDesc::of
In-Reply-To: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
References: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
Message-ID: <2uRsk2KqDYXsDHeIJCzsvu2zRDB4IGQ9LPrvwtht6Y8=.2a21c011-98e5-4231-b57f-527a5fe72d70@github.com>

On Sat, 22 Apr 2023 16:31:31 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this patch adding two new convenience methods that allows easier access to MethodTypeDesc instances and its associated CSR as well. This is a necessity to allow #13186 to reduce array copies in a few scenarios; the implementation of the two methods will be updated there.

Changes requested by ExE-Boss at github.com (no known OpenJDK username).

src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java line 85:

> 83:      * @since 21
> 84:      */
> 85:     static MethodTypeDesc of(ClassDesc returnDesc, Collection<ClassDesc> paramDescs) {

This?needs?to?be:
Suggestion:

    static MethodTypeDesc of(ClassDesc returnDesc, List<ClassDesc> paramDescs) {


as?`Collection` doesn?t?have a?defined encounter?order.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13599#pullrequestreview-1396907204
PR Review Comment: https://git.openjdk.org/jdk/pull/13599#discussion_r1174578085

From duke at openjdk.org  Sun Apr 23 13:23:50 2023
From: duke at openjdk.org (ExE Boss)
Date: Sun, 23 Apr 2023 13:23:50 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <45Z1tJaBdth0CRuKBXITLheMc6tPm0AUqzu8sbenfKo=.7594c033-9fc7-4e9a-b415-7600b5a06b79@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 107:

> 105:      * @see ClassDesc#internalName()
> 106:      * @see <a href="#constant-class-info">The {@code CONSTANT_Class_info} Structure</a>
> 107:      * @since 20

This?should?have `@revised`, as?array?descriptors are?not?allowed as?input to?this?method in?**JDK?20**.
Suggestion:

     * @since 20
     * @revised 21

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 375:

> 373:      * {@code CONSTANT_Class_info}.
> 374:      *
> 375:      * @throws IllegalStateException if this {@linkplain ClassDesc} describes a type

This?should really?throw `UnsupportedOperationException`, as?the?instances are?immutable, same?as?[`Class::arrayType()`]. See [JDK?8268250] and?[GH?4382] for?discussion.

[`Class::arrayType()`]: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/Class.html#arrayType()
[JDK?8268250]: https://bugs.openjdk.org/browse/JDK-8268250
[GH?4382]: https://github.com/openjdk/jdk/pull/4382

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13598#discussion_r1174579298
PR Review Comment: https://git.openjdk.org/jdk/pull/13598#discussion_r1174578847

From lbourges at openjdk.org  Sun Apr 23 13:52:39 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 23 Apr 2023 13:52:39 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v5]
In-Reply-To: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
Message-ID: <Hd6kQHo7bb-kxeUut8_dzyyo7xkZCko_n4lkfXQ1dfw=.18b907b7-94ce-4a13-a85e-3f76d905557b@github.com>

> * Optimized mixed insertion sort
>     * Optimized insertion sort
>     * Optimized Radix sort
>     * Updated microbenchmark
> 
> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938

Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:

  improved and more obvious max length test to always respect max heap memory footprint

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13568/files
  - new: https://git.openjdk.org/jdk/pull/13568/files/1d4af827..07771000

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=03-04

  Stats: 8 lines in 1 file changed: 2 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13568/head:pull/13568

PR: https://git.openjdk.org/jdk/pull/13568

From liach at openjdk.org  Sun Apr 23 16:33:43 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 23 Apr 2023 16:33:43 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <45Z1tJaBdth0CRuKBXITLheMc6tPm0AUqzu8sbenfKo=.7594c033-9fc7-4e9a-b415-7600b5a06b79@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
 <45Z1tJaBdth0CRuKBXITLheMc6tPm0AUqzu8sbenfKo=.7594c033-9fc7-4e9a-b415-7600b5a06b79@github.com>
Message-ID: <so8wxPMgExIF5iMk2YZ5Em3OiFoHdqh8nj7jqiujpso=.9185ae99-c0fc-4667-bd1a-a5d5671f097f@github.com>

On Sun, 23 Apr 2023 13:13:55 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links
>
> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 107:
> 
>> 105:      * @see ClassDesc#internalName()
>> 106:      * @see <a href="#constant-class-info">The {@code CONSTANT_Class_info} Structure</a>
>> 107:      * @since 20
> 
> This?should?have `@revised`, as?array?descriptors are?not?allowed as?input to?this?method in?**JDK?20**.
> Suggestion:
> 
>      * @since 20
>      * @revised 21

There's no guideline on using revised. Also, I don't think we will declare it revised if it starts accepting Valhalla Q-types.

> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 375:
> 
>> 373:      * {@code CONSTANT_Class_info}.
>> 374:      *
>> 375:      * @throws IllegalStateException if this {@linkplain ClassDesc} describes a type
> 
> This?should really?throw `UnsupportedOperationException`, as?the?instances are?immutable, same?as?[`Class::arrayType()`]. See [JDK?8268250] and?[GH?4382] for?discussion.
> 
> [`Class::arrayType()`]: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/Class.html#arrayType()
> [JDK?8268250]: https://bugs.openjdk.org/browse/JDK-8268250
> [GH?4382]: https://github.com/openjdk/jdk/pull/4382

The choice is based on ClassDesc.nested

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13598#discussion_r1174609313
PR Review Comment: https://git.openjdk.org/jdk/pull/13598#discussion_r1174609117

From liach at openjdk.org  Sun Apr 23 16:36:41 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 23 Apr 2023 16:36:41 GMT
Subject: RFR: 8306698: Add overloads to MethodTypeDesc::of
In-Reply-To: <2uRsk2KqDYXsDHeIJCzsvu2zRDB4IGQ9LPrvwtht6Y8=.2a21c011-98e5-4231-b57f-527a5fe72d70@github.com>
References: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
 <2uRsk2KqDYXsDHeIJCzsvu2zRDB4IGQ9LPrvwtht6Y8=.2a21c011-98e5-4231-b57f-527a5fe72d70@github.com>
Message-ID: <0YnLPag9ZsgkTWObmj0ojhR4zornTHjPprSLO40hNo8=.35e6ea66-acb5-4133-9fce-36784857be96@github.com>

On Sun, 23 Apr 2023 13:06:34 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Please review this patch adding two new convenience methods that allows easier access to MethodTypeDesc instances and its associated CSR as well. This is a necessity to allow #13186 to reduce array copies in a few scenarios; the implementation of the two methods will be updated there.
>
> src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java line 85:
> 
>> 83:      * @since 21
>> 84:      */
>> 85:     static MethodTypeDesc of(ClassDesc returnDesc, Collection<ClassDesc> paramDescs) {
> 
> This?needs?to?be:
> Suggestion:
> 
>     static MethodTypeDesc of(ClassDesc returnDesc, List<ClassDesc> paramDescs) {
> 
> 
> as?`Collection` doesn?t?have a?defined encounter?order.

No, this is what List.copyOf supports.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13599#discussion_r1174609400

From liach at openjdk.org  Sun Apr 23 16:36:41 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 23 Apr 2023 16:36:41 GMT
Subject: RFR: 8306698: Add overloads to MethodTypeDesc::of
In-Reply-To: <0YnLPag9ZsgkTWObmj0ojhR4zornTHjPprSLO40hNo8=.35e6ea66-acb5-4133-9fce-36784857be96@github.com>
References: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
 <2uRsk2KqDYXsDHeIJCzsvu2zRDB4IGQ9LPrvwtht6Y8=.2a21c011-98e5-4231-b57f-527a5fe72d70@github.com>
 <0YnLPag9ZsgkTWObmj0ojhR4zornTHjPprSLO40hNo8=.35e6ea66-acb5-4133-9fce-36784857be96@github.com>
Message-ID: <Pn4pvNX3Mqg_yVRO8H3l3wbfNQVeeu2BxENidYkqaOg=.c22d30ba-db69-43a4-bee1-96d56ecfde56@github.com>

On Sun, 23 Apr 2023 16:31:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java line 85:
>> 
>>> 83:      * @since 21
>>> 84:      */
>>> 85:     static MethodTypeDesc of(ClassDesc returnDesc, Collection<ClassDesc> paramDescs) {
>> 
>> This?needs?to?be:
>> Suggestion:
>> 
>>     static MethodTypeDesc of(ClassDesc returnDesc, List<ClassDesc> paramDescs) {
>> 
>> 
>> as?`Collection` doesn?t?have a?defined encounter?order.
>
> No, this is what List.copyOf supports.

Alternatively, we can switch to SequencedCollection when it's integrated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13599#discussion_r1174609637

From lbourges at openjdk.org  Sun Apr 23 17:33:38 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 23 Apr 2023 17:33:38 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v6]
In-Reply-To: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
Message-ID: <aeZ8z-znPXfQBL0ptEcSDMpuADDtpPBxCbKRaaaMWnE=.da492fc8-39ac-43f7-8ee3-f9f002334837@github.com>

> * Optimized mixed insertion sort
>     * Optimized insertion sort
>     * Optimized Radix sort
>     * Updated microbenchmark
> 
> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938

Laurent Bourg?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'openjdk:master' into dpqs23
 - fixed javadoc and size renamed to length for clarity
 - improved and more obvious max length test to always respect max heap memory footprint
 - Merge branch 'openjdk:master' into dpqs23
 - rewritten radix sort condition + fixed max buffer size
 - optimized radix sort heuristic
 - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
       * Optimized mixed insertion sort
       * Optimized insertion sort
       * Optimized Radix sort
       * Updated microbenchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13568/files
  - new: https://git.openjdk.org/jdk/pull/13568/files/07771000..391bb3bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=04-05

  Stats: 60 lines in 9 files changed: 3 ins; 27 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/13568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13568/head:pull/13568

PR: https://git.openjdk.org/jdk/pull/13568

From duke at openjdk.org  Sun Apr 23 21:12:41 2023
From: duke at openjdk.org (ExE Boss)
Date: Sun, 23 Apr 2023 21:12:41 GMT
Subject: RFR: 8306698: Add overloads to MethodTypeDesc::of
In-Reply-To: <Pn4pvNX3Mqg_yVRO8H3l3wbfNQVeeu2BxENidYkqaOg=.c22d30ba-db69-43a4-bee1-96d56ecfde56@github.com>
References: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
 <2uRsk2KqDYXsDHeIJCzsvu2zRDB4IGQ9LPrvwtht6Y8=.2a21c011-98e5-4231-b57f-527a5fe72d70@github.com>
 <0YnLPag9ZsgkTWObmj0ojhR4zornTHjPprSLO40hNo8=.35e6ea66-acb5-4133-9fce-36784857be96@github.com>
 <Pn4pvNX3Mqg_yVRO8H3l3wbfNQVeeu2BxENidYkqaOg=.c22d30ba-db69-43a4-bee1-96d56ecfde56@github.com>
Message-ID: <1RobVV639ABKCKNmoAyaQUDFktV17cZ0zD1gNgBULV4=.c1f2d154-d0e3-43ff-b915-f368d50626d0@github.com>

On Sun, 23 Apr 2023 16:33:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> No, this is what List.copyOf supports.
>
> Alternatively, we can switch to SequencedCollection when it's integrated.

[`MethodType.methodType(?)`] also?doesn?t?allow plain?`Collection`s for?the?same?reason, even?though `List.copyOf` supports?creation from?a?`Collection`.

[`MethodType.methodType(?)`]: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/MethodType.html#methodType(java.lang.Class,java.util.List)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13599#discussion_r1174652830

From darcy at openjdk.org  Sun Apr 23 22:41:50 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 23 Apr 2023 22:41:50 GMT
Subject: RFR: JDK-8304423: Refactor FdLibm.java
Message-ID: <kkt3zVVtkAFIH4Joz82Xq8d5dhDX9VeA1p9sxNlS4XI=.7090fbc8-e059-47c0-9c12-65e56da9fc22@github.com>

Minor refactoring of FdLibm.java; will consider future refactorings with more substantive code changes in the future.

-------------

Commit messages:
 - JDK-8304423: Refactor Fdlibm.java

Changes: https://git.openjdk.org/jdk/pull/13604/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13604&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304423
  Stats: 85 lines in 1 file changed: 10 ins; 3 del; 72 mod
  Patch: https://git.openjdk.org/jdk/pull/13604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13604/head:pull/13604

PR: https://git.openjdk.org/jdk/pull/13604

From lmesnik at openjdk.org  Sun Apr 23 22:42:48 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 23 Apr 2023 22:42:48 GMT
Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using
 an OutputAnalyzer at the same time
Message-ID: <jbN1idusRU1wUiQ265HUUCyjb2eh8uSC4MDn5igYyy8=.ae64e31f-8c57-415e-8a21-ca7f0e8a6410@github.com>

ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams.

This fix preserve process streams content and allow to read reuse the date. The ByteArrayOutputStream is used as a buffer. 
It stores all process output, never trying to clean date which has been read. 

The regression test has been provided with issue.

I closed previous PR https://github.com/openjdk/jdk/pull/13560 by mistake instead of updating it.

I run all tests to ensure that no failures are introduced.

-------------

Commit messages:
 - copyrights fixed
 - typo fixed
 - fixed to use buffer.
 - JStackStressTest.java updated.
 - 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time

Changes: https://git.openjdk.org/jdk/pull/13594/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13594&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8233725
  Stats: 210 lines in 3 files changed: 198 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13594.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13594/head:pull/13594

PR: https://git.openjdk.org/jdk/pull/13594

From liach at openjdk.org  Sun Apr 23 23:10:43 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 23 Apr 2023 23:10:43 GMT
Subject: RFR: 8306698: Add overloads to MethodTypeDesc::of
In-Reply-To: <1RobVV639ABKCKNmoAyaQUDFktV17cZ0zD1gNgBULV4=.c1f2d154-d0e3-43ff-b915-f368d50626d0@github.com>
References: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
 <2uRsk2KqDYXsDHeIJCzsvu2zRDB4IGQ9LPrvwtht6Y8=.2a21c011-98e5-4231-b57f-527a5fe72d70@github.com>
 <0YnLPag9ZsgkTWObmj0ojhR4zornTHjPprSLO40hNo8=.35e6ea66-acb5-4133-9fce-36784857be96@github.com>
 <Pn4pvNX3Mqg_yVRO8H3l3wbfNQVeeu2BxENidYkqaOg=.c22d30ba-db69-43a4-bee1-96d56ecfde56@github.com>
 <1RobVV639ABKCKNmoAyaQUDFktV17cZ0zD1gNgBULV4=.c1f2d154-d0e3-43ff-b915-f368d50626d0@github.com>
Message-ID: <nuoxfwkPoQkAYXewpkcXCGUHZqCWPZozVs3vO97nG3w=.267060d7-d95d-494a-ab57-4235aaba7353@github.com>

On Sun, 23 Apr 2023 21:09:32 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Alternatively, we can switch to SequencedCollection when it's integrated.
>
> [`MethodType.methodType(?)`] also?doesn?t?allow plain?`Collection`s for?the?same?reason, even?though `List.copyOf` supports?creation from?a?`Collection`.
> 
> [`MethodType.methodType(?)`]: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/MethodType.html#methodType(java.lang.Class,java.util.List)

After thinking, users who want to pass in a `Collection` can just do `MethodTypeDesc.of(returnDesc, List.copyOf(paramDescCollection))` so using a `List` is good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13599#discussion_r1174667653

From liach at openjdk.org  Sun Apr 23 23:44:41 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 23 Apr 2023 23:44:41 GMT
Subject: RFR: 8306698: Add overloads to MethodTypeDesc::of [v2]
In-Reply-To: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
References: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
Message-ID: <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>

> Please review this patch adding two new convenience methods that allows easier access to MethodTypeDesc instances and its associated CSR as well. This is a necessity to allow #13186 to reduce array copies in a few scenarios; the implementation of the two methods will be updated there.
> 
> Javadoc: https://cr.openjdk.org/~liach/8306698/1/java.base/java/lang/constant/MethodTypeDesc.html

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update method type and specification, update tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13599/files
  - new: https://git.openjdk.org/jdk/pull/13599/files/6463da2b..dc2a5a5d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13599&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13599&range=00-01

  Stats: 55 lines in 2 files changed: 7 ins; 33 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13599.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13599/head:pull/13599

PR: https://git.openjdk.org/jdk/pull/13599

From gcao at openjdk.org  Mon Apr 24 06:18:41 2023
From: gcao at openjdk.org (Gui Cao)
Date: Mon, 24 Apr 2023 06:18:41 GMT
Subject: RFR: 8306008: Several Vector API tests fail for client VM after
 JDK-8304450
In-Reply-To: <TDcfSAbMANHhRfHfZSAoKxfHPrsVqHrbE0gz1RwUBcg=.de344a1c-8d0e-477b-b8a2-209595967254@github.com>
References: <TDcfSAbMANHhRfHfZSAoKxfHPrsVqHrbE0gz1RwUBcg=.de344a1c-8d0e-477b-b8a2-209595967254@github.com>
Message-ID: <4CS5sgoflkmiks1i1am19vm77-867XCXU7hRSezZgqw=.352c063a-12fd-4989-a886-38ce2ae6dbdd@github.com>

On Tue, 18 Apr 2023 12:21:11 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Please review this patch which fixes the errors on machines where TypeMaxVector has a length of 64 bits. I take an extra cautious approach and fall back to putting elements one by one if the length is an unexpected value.
> 
> All jdk/incubator/vector tests passed with MaxVectorSize=8, which fails without this patch.
> 
> Thanks a lot.

Hi, Thanks for this patch! 
I have tested the x86-64,aarch64,riscv client vm, and several test cases that reported errors before have passed properly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13508#issuecomment-1519448811

From jvernee at openjdk.org  Mon Apr 24 06:55:55 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 24 Apr 2023 06:55:55 GMT
Subject: RFR: 8305201: Improve error message for GroupLayouts that are too
 large on SysV
Message-ID: <DwY-xanY3TwoY2JPGLFPQg3bOqI70N1j5tAKv60AIxw=.f892d52c-a641-4275-9619-a8bffc4378b5@github.com>

Using for instance a struct layout that contains an unbounded array will produce the exception from the JBS issue.

This patch checks for the case where a GroupLayout is too large more explicitly, and reports the issue using a more informative exception.

-------------

Depends on: https://git.openjdk.org/jdk/pull/13079

Commit messages:
 - Add test. Use toIntExact
 - improve error message for too large structs

Changes: https://git.openjdk.org/jdk/pull/13581/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13581&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305201
  Stats: 27 lines in 2 files changed: 24 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13581.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13581/head:pull/13581

PR: https://git.openjdk.org/jdk/pull/13581

From jvernee at openjdk.org  Mon Apr 24 06:55:51 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 24 Apr 2023 06:55:51 GMT
Subject: RFR: 8304986: Upcall stubs should support capureCallState
Message-ID: <fpDsVP2fku1RhP_aE4xA5ikUIiK1jJevWy26YNDVo1c=.5a9a5363-1d8c-4de1-b9d7-5b3e140a948d@github.com>

Implement captureCallState support for upcall stubs.

The method handle of an upcall stub linked with this linker option has an additional leading memory segment parameter into which the capture state (e.g. errno) should be written. After returning from Java, this value is then actually written to the corresponding execution state.

-------------

Depends on: https://git.openjdk.org/jdk/pull/13079

Commit messages:
 - Use orElseGet
 - remove redundant variable
 - update stubs
 - polish naming and comments
 - Fix aarch64 impl
 - simplify names
 - update linker doc
 - implement upcall ccs in fallback linker
 - working upcall CCS
 - refactor TestCaptureCallState
 - ... and 1 more: https://git.openjdk.org/jdk/compare/91f43d13...96f3d1f3

Changes: https://git.openjdk.org/jdk/pull/13588/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13588&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304986
  Stats: 523 lines in 36 files changed: 331 ins; 23 del; 169 mod
  Patch: https://git.openjdk.org/jdk/pull/13588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13588/head:pull/13588

PR: https://git.openjdk.org/jdk/pull/13588

From jvernee at openjdk.org  Mon Apr 24 06:55:54 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 24 Apr 2023 06:55:54 GMT
Subject: RFR: 8304986: Upcall stubs should support capureCallState
In-Reply-To: <fpDsVP2fku1RhP_aE4xA5ikUIiK1jJevWy26YNDVo1c=.5a9a5363-1d8c-4de1-b9d7-5b3e140a948d@github.com>
References: <fpDsVP2fku1RhP_aE4xA5ikUIiK1jJevWy26YNDVo1c=.5a9a5363-1d8c-4de1-b9d7-5b3e140a948d@github.com>
Message-ID: <-xoJpr6nJOQJthIQwP_eswGESCA8OPEKXfIcazlL3I4=.73c833a9-bfce-4fc6-a48d-589c0b6f3f16@github.com>

On Fri, 21 Apr 2023 18:25:32 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Implement captureCallState support for upcall stubs.
> 
> The method handle of an upcall stub linked with this linker option has an additional leading memory segment parameter into which the capture state (e.g. errno) should be written. After returning from Java, this value is then actually written to the corresponding execution state.

src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 177:

> 175:             // should appear before the IMR segment parameter
> 176:             target = swapArguments(target, 0, 1);
> 177:         }

e.g. 

target = (MemorySegment, MemorySegment, ...) MemorySegment
          ^ IMR segment  ^ CCS segment


These should be swapped, since the binding recipe for the capture state segment comes before the binding recipe for the IMR segment, since the former is inserted as a leading parameter in CallingSequenceBuilder::build, after a particular CallArranger inserts the IMR segment parameter.

src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 192:

> 190:     public static UpcallStubFactory arrangeUpcallHelper(boolean isInMemoryReturn, boolean dropReturn,
> 191:                                                         ABIDescriptor abi, CallingSequence callingSequence) {
> 192:         MethodType targetType = callingSequence.calleeMethodType();

Previously this was using the a method type which was derived from the FunctionDescriptor. Since that corresponds to the native side, it didn't contain the return buffer.  But, since the return buffer isn't passed on to the user, that worked out since the type would match the type of the target method handle.

However, if we are capturing call state, we need to pass on the capture state segment to the user, so the target type has an additional leading MS parameter.

To make that work, I've switched to using the calleeMethodType here, which contains both the return buffer and capture state parameters, and then I filter out the return buffer below. 

This also avoids having to do the fake adaptation, which turned a method type returning a struct into a method type which excepts a pointer into which the return value should be written: `(...) -> MemorySegment` into `(MemorySegment, ...) -> void/MemorySegment)`. The callee method type is already in the latter form.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13588#discussion_r1174070167
PR Review Comment: https://git.openjdk.org/jdk/pull/13588#discussion_r1174060551

From duke at openjdk.org  Mon Apr 24 06:55:56 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 24 Apr 2023 06:55:56 GMT
Subject: RFR: 8304986: Upcall stubs should support capureCallState
In-Reply-To: <fpDsVP2fku1RhP_aE4xA5ikUIiK1jJevWy26YNDVo1c=.5a9a5363-1d8c-4de1-b9d7-5b3e140a948d@github.com>
References: <fpDsVP2fku1RhP_aE4xA5ikUIiK1jJevWy26YNDVo1c=.5a9a5363-1d8c-4de1-b9d7-5b3e140a948d@github.com>
Message-ID: <wuGXSFstm5IzfVrcMMuC1E2JklbGVFrvkSk3zsH4-Lo=.39d06703-a3fb-48aa-b9a4-e5b91857750a@github.com>

On Fri, 21 Apr 2023 18:25:32 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Implement captureCallState support for upcall stubs.
> 
> The method handle of an upcall stub linked with this linker option has an additional leading memory segment parameter into which the capture state (e.g. errno) should be written. After returning from Java, this value is then actually written to the corresponding execution state.

test/jdk/java/foreign/capturecallstate/TestCaptureCallState.java line 89:

> 87:         FunctionDescriptor downcallDesc = testCase.retValueLayout()
> 88:                 .map(rl -> FunctionDescriptor.of(rl, JAVA_INT, rl))
> 89:                 .orElse(FunctionDescriptor.ofVoid(JAVA_INT));

Using?[`Optional::orElseGet(?)`] avoids?allocating the?`FunctionDescriptor` corresponding?to?`(int)void` when?`testCase.retValueLayout()` is?present:
Suggestion:

                .orElseGet(() -> FunctionDescriptor.ofVoid(JAVA_INT));


[`Optional::orElseGet(?)`]: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/Optional.html#orElseGet(java.util.function.Supplier)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13588#discussion_r1174607193

From duke at openjdk.org  Mon Apr 24 06:59:44 2023
From: duke at openjdk.org (Xiaowei Lu)
Date: Mon, 24 Apr 2023 06:59:44 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide [v2]
In-Reply-To: <RmxcdUCqazQtulk5M7nAuwuwGPHcsILq_y2cYSUJliw=.0806795b-00ed-434c-beae-f301b293729b@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
 <RmxcdUCqazQtulk5M7nAuwuwGPHcsILq_y2cYSUJliw=.0806795b-00ed-434c-beae-f301b293729b@github.com>
Message-ID: <EYcGXRmGQaGHbAWEGYDJ29nZuWnE-KT4wTSLJ8XisAc=.b2e7bb40-90bf-4d57-a48a-5a2d1ad5642e@github.com>

On Fri, 17 Feb 2023 04:43:00 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.
>
> Xiaowei Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check lowest n bits instead of single one

@jddarcy Hi, could you please help me review this pr? I'm trying some optimization for java BigDecimal

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12509#issuecomment-1519490183

From duke at openjdk.org  Mon Apr 24 07:20:41 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Mon, 24 Apr 2023 07:20:41 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v4]
In-Reply-To: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
Message-ID: <MPpY2OnqaE34mDncA_ct8S5VEtiKoaxodCBer8Ph8LU=.304f586b-f940-4684-a652-d8809971e296@github.com>

> I fixed File.listRoots description.
> * remove "the insertion or ejection of removable media"
> * change "available" to "existing"
> 
> Please review this change.

Nagata-Haruhito has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'openjdk:master' into File_javadoc
 - 8306431: The documentation of File.listRoots should be modifid after JDK-8208077
 - 8306431: File.listRoots method description should be re-examined

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13526/files
  - new: https://git.openjdk.org/jdk/pull/13526/files/ef38a529..acb639e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13526&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13526&range=02-03

  Stats: 233660 lines in 1515 files changed: 217436 ins; 6745 del; 9479 mod
  Patch: https://git.openjdk.org/jdk/pull/13526.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13526/head:pull/13526

PR: https://git.openjdk.org/jdk/pull/13526

From jvernee at openjdk.org  Mon Apr 24 08:35:57 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 24 Apr 2023 08:35:57 GMT
Subject: RFR: 8304888: Add dedicated VMProps for linker and fallback linker
Message-ID: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>

This patch adds a dedicated jtreg property to check which CABI is being used by the JDK, which can be used both to check whether the foreign linker is supported, and whether the fallback linker is being used. (and, possibly it can also be use to check for a particular ABI in case we want to add ABI specific tests).

Checking whether the foreign linker is supported currently requires using an unwieldy expression that checks if we are running on a platform that has a foreign linker port. Checking for the fallback linker currently uses `vm.flavor != "zero"` which is not always correct, since the fallback linker can also be used on other platforms which are not `zero`.

To initialize the property, VMProps directly reads `jdk.internal.foreig.CABI::current()`. Since this class is in an internal package, `--add-exports` flags are added as javac flags and VM flags for the extra prop definitions class.

-------------

Depends on: https://git.openjdk.org/jdk/pull/13079

Commit messages:
 - use only jdk.CABI property
 - use extra props to check for linker
 - Add fallbackLinker vmprop

Changes: https://git.openjdk.org/jdk/pull/13429/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13429&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304888
  Stats: 99 lines in 50 files changed: 17 ins; 3 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/13429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13429/head:pull/13429

PR: https://git.openjdk.org/jdk/pull/13429

From mcimadamore at openjdk.org  Mon Apr 24 08:59:03 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 24 Apr 2023 08:59:03 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v5]
In-Reply-To: <fe5fyxgbheu8mpzTvRwUA79iIXXs6VUSpTMMyBexnuA=.546c8f7a-ea48-4f68-b812-5afea9526cfd@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <fe5fyxgbheu8mpzTvRwUA79iIXXs6VUSpTMMyBexnuA=.546c8f7a-ea48-4f68-b812-5afea9526cfd@github.com>
Message-ID: <AjPNSSIEUgbAkdqkEd2QcaSHuhGT-Q1ydCMpZl0QbOs=.00d67877-f5b3-4918-b5c8-f75cc8c99546@github.com>

On Fri, 21 Apr 2023 16:25:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adding test.
>  - Removing redundant continue, as noted on the review.

I believe the exhaustiveness algorithm needs rules for union types, both in javac and in the JLS:


class Foo extends Exception { }
    class Bar extends Exception { }

    void m() {
        try {
            g();
        } catch (Foo | Bar ex) {
            String s = switch (ex) {
                case Foo f -> "Foo";
                case Bar f -> "Bar";
            };
        }
    }

    void g() throws Foo, Bar { }


I would expect the above switch to be exhaustive, since it covers all possible components of the union type. In other words, the union type should act as a sealed hierarchy which permits Foo and Bar - and the two cases should be merged together (e.g. `case Foo` + `case Bar` should cover `Foo | Bar`).  For the records, I get same error on JDK 20.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13074#issuecomment-1519655297

From forax at openjdk.org  Mon Apr 24 09:09:06 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 24 Apr 2023 09:09:06 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v5]
In-Reply-To: <fe5fyxgbheu8mpzTvRwUA79iIXXs6VUSpTMMyBexnuA=.546c8f7a-ea48-4f68-b812-5afea9526cfd@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <fe5fyxgbheu8mpzTvRwUA79iIXXs6VUSpTMMyBexnuA=.546c8f7a-ea48-4f68-b812-5afea9526cfd@github.com>
Message-ID: <mNiwouJaJqT6SYzab7GCCf_p4MBg7sJEogc0ifXj6TQ=.c3137d33-0d98-439f-ba7c-0e7cfc1ac40e@github.com>

On Fri, 21 Apr 2023 16:25:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adding test.
>  - Removing redundant continue, as noted on the review.

> I believe the exhaustiveness algorithm needs rules for union types, both in javac and in the JLS:
> 
> ...
> I would expect the above switch to be exhaustive, since it covers all possible components of the union type. In other words, the union type should act as a sealed hierarchy which permits Foo and Bar - and the two cases should be merged together (e.g. `case Foo` + `case Bar` should cover `Foo | Bar`). For the records, I get same error on JDK 20.

Precise exception type, here, `Foo | Bar` inside a catch is not an union, it's a way to merge catches when the body of catches are the same. In term of typing, `Foo | Bar` behave as the lub of Foo and Bar, apart in a throw.

So the switch is not exhaustive here because `lub(Foo, Bar) = Exception`.

We may add a special case in JLS for supporting precise exception type in switch given that this issue have been reported several times, but this is not something that should be fixed by this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13074#issuecomment-1519675744

From duke at openjdk.org  Mon Apr 24 09:39:46 2023
From: duke at openjdk.org (Andy-Tatman)
Date: Mon, 24 Apr 2023 09:39:46 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: <mQVm9GxIatFChNrRlcQERt8vwzXKMjA2exEEVe9vSu4=.5c078cc8-0364-4846-adeb-2f5ebcde5050@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

I realise this is a bit off-topic for this specific bug, but perhaps relevant for the specification: The size() function can already start to overflow with much smaller indices being set, due to how ensureCapacity(int) currently works.

`BitSet bitSet = new BitSet(0);`
`bitSet.set(Integer.MAX_VALUE/2);`
`System.out.println("size = " + bitSet.size());`
`bitSet.set(Integer.MAX_VALUE/2 + 64);`
`System.out.println("size = " + bitSet.size());`

The second size() call has already overflown, due to the fact that ensureCapacity always grows the words array to at least twice the original size.
Furthermore, my impression is that any bit over Integer.MAX_VALUE-64 being set will always cause size() to overflow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1519733075

From mdoerr at openjdk.org  Mon Apr 24 09:55:57 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 24 Apr 2023 09:55:57 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v17]
In-Reply-To: <vjrFk-Qfyw2CzxBi-Sh0ZgkeeMUqhWW5f72bdqyqHFE=.1e5f2fb4-6bb3-4fcb-831c-20bd0765b17b@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <vjrFk-Qfyw2CzxBi-Sh0ZgkeeMUqhWW5f72bdqyqHFE=.1e5f2fb4-6bb3-4fcb-831c-20bd0765b17b@github.com>
Message-ID: <uFsylWCuJJd928I1OAvB2B5eHZQXtjb_wQo9K9JHAPQ=.7be13e5c-1636-485f-b4bd-d26b50f2cb99@github.com>

On Fri, 21 Apr 2023 20:26:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct comment on isPPC64() and refer to isLittleEndian() instead of mentioning PPC64LE

Thanks for the comment updates!

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1397600716

From simonis at openjdk.org  Mon Apr 24 11:47:46 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 24 Apr 2023 11:47:46 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions
In-Reply-To: <yBs7xJfNYmHqVBA1mekhNjuoIJjGDk3lzqz8qDQN1Vs=.c0a27536-325c-4c1d-b1ac-0c5b9cc4662a@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <yBs7xJfNYmHqVBA1mekhNjuoIJjGDk3lzqz8qDQN1Vs=.c0a27536-325c-4c1d-b1ac-0c5b9cc4662a@github.com>
Message-ID: <U9kbb29CgZfoYeBV_-FxLI00A_xKgFYRK-Y00wyr4kU=.25ee665f-94d0-4f2d-a5b0-e4c40c130611@github.com>

On Wed, 19 Apr 2023 19:05:49 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 69:
> 
>> 67:         serializedData[firstPos+5] = (byte) 0xfe;
>> 68: 
>> 69:         return  serializedData;
> 
> Suggestion:
> 
>         return serializedData;

Thanks, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1175167976

From mcimadamore at openjdk.org  Mon Apr 24 11:50:58 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 24 Apr 2023 11:50:58 GMT
Subject: RFR: 8305093: Linker cache should not take layout names into
 account [v2]
In-Reply-To: <7_Nk2AOcLFfPf5yfpg1aAW97junefRNAY857VrpS9xs=.9640e499-4b17-44bc-82ea-406fff99a9cf@github.com>
References: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
 <7_Nk2AOcLFfPf5yfpg1aAW97junefRNAY857VrpS9xs=.9640e499-4b17-44bc-82ea-406fff99a9cf@github.com>
Message-ID: <Kpqq7L9icuWNfO94Njyeb-2lhu5pnEZxpMj8vJbTGb8=.2dfe97c7-ae6d-4c71-a353-987a374eb64a@github.com>

On Fri, 21 Apr 2023 01:03:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Strip names from the function descriptors used in linkage requests. The names are not important for classification, and this will allow the cached MethodHandle/UpcallStubFactory to be shared across linkage request with the same structure, but with layouts that have different names.
>> 
>> I also have another implementation that avoids copying all the layouts, and instead re-implemented equals and hashCode in the LinkRequest wrapper: https://github.com/openjdk/jdk/compare/pr/13079...JornVernee:jdk:NoNameCache But, this seems too complex. Linking code is not very performance sensitive, so I instead went with a simpler approach in this patch.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use al instead of ValueLayout.ADDRESS

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 142:

> 140:         // since the linker already restricts those such that they will always be the same
> 141:         return switch (ml) {
> 142:             case StructLayout sl -> MemoryLayout.structLayout(stripNames(sl.memberLayouts()));

shouldn't names be also stripped from enclosing struct/union/sequence?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13562#discussion_r1175169777

From mcimadamore at openjdk.org  Mon Apr 24 11:52:54 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 24 Apr 2023 11:52:54 GMT
Subject: RFR: 8305201: Improve error message for GroupLayouts that are too
 large on SysV
In-Reply-To: <DwY-xanY3TwoY2JPGLFPQg3bOqI70N1j5tAKv60AIxw=.f892d52c-a641-4275-9619-a8bffc4378b5@github.com>
References: <DwY-xanY3TwoY2JPGLFPQg3bOqI70N1j5tAKv60AIxw=.f892d52c-a641-4275-9619-a8bffc4378b5@github.com>
Message-ID: <7hzENpkk3foIjkh5a64GT1W8VcPKTSBq5rjyj3pXyns=.12d3128d-fc56-48e9-baf0-0d716bea4b33@github.com>

On Fri, 21 Apr 2023 14:25:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Using for instance a struct layout that contains an unbounded array will produce the exception from the JBS issue.
> 
> This patch checks for the case where a GroupLayout is too large more explicitly, and reports the issue using a more informative exception.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13581#pullrequestreview-1397805193

From simonis at openjdk.org  Mon Apr 24 11:54:59 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 24 Apr 2023 11:54:59 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions
In-Reply-To: <689URy0mqJMJ_339lBAJeTbAJgh1rzPs9ZGBBk2CK34=.c1f164ef-fc58-47ba-bd60-f95c449f31f8@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <689URy0mqJMJ_339lBAJeTbAJgh1rzPs9ZGBBk2CK34=.c1f164ef-fc58-47ba-bd60-f95c449f31f8@github.com>
Message-ID: <UqKDxmBIRYIkyhZmBSfoUg_09M5vYktYYJeTpd3vtNw=.b25ec5c3-550c-4870-bb8c-f077d01ad1a7@github.com>

On Thu, 20 Apr 2023 10:57:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 43:
> 
>> 41: public class NegativeArraySizeTest {
>> 42: 
>> 43:     private static byte[] _buildPayload() throws IOException {
> 
> `_buildPayload` -> `buildPayload`.

Done.

> test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 44:
> 
>> 42: 
>> 43:     private static byte[] _buildPayload() throws IOException {
>> 44:         String[] simpleArray = new String[1];
> 
> Inline this variable?

Done.

> test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 55:
> 
>> 53:         // Find the right location to modify, looking for the first instance of TC_ENDBLOCKDATA
>> 54:         int firstPos = 0;
>> 55:         for (int i=0; i<serializedData.length-1; i++) {
> 
> Suggestion:
> 
>         for (int i = 0; i < serializedData.length - 1; i++) {

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1175171971
PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1175173884
PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1175174823

From simonis at openjdk.org  Mon Apr 24 11:54:57 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 24 Apr 2023 11:54:57 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions
In-Reply-To: <5OVwvKvQLrR3V9eZ8gSsH78k7G4ehnb7zxQ2srjo98w=.7bd6b372-34ac-4b4b-a2d2-d03959ec795b@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <689URy0mqJMJ_339lBAJeTbAJgh1rzPs9ZGBBk2CK34=.c1f164ef-fc58-47ba-bd60-f95c449f31f8@github.com>
 <5OVwvKvQLrR3V9eZ8gSsH78k7G4ehnb7zxQ2srjo98w=.7bd6b372-34ac-4b4b-a2d2-d03959ec795b@github.com>
Message-ID: <S1nadOqOCjz595UmeOUJ6Xuce7-ufKIAVHA--GgECxA=.f106c3e3-3ffa-4275-8e9f-88bb39a62356@github.com>

On Thu, 20 Apr 2023 18:44:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/ObjectInputStream.java line 2142:
>> 
>>> 2140:         int len = bin.readInt();
>>> 2141:         if (len < 0) {
>>> 2142:             throw new InvalidClassException(desc.getName(), "Array length < 0 (" + len + ")");
>> 
>> Suggestion:
>> 
>>             throw new InvalidClassException(desc.getName(), "Array length (" + len + ") is negative");
>
> I'd keep the exception logic simple/minimal.  Especially since this is a manual and exceptional case that is not the result of any input provided through an API.
> 
> throw new InvalidClassException(desc.getName(), "Array length is negative");

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1175170526

From simonis at openjdk.org  Mon Apr 24 12:01:02 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 24 Apr 2023 12:01:02 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions
In-Reply-To: <5VrcYF_OlOjJMuwDhVCVZSRIoCPxyVOs-eIke7nBljE=.07263973-1880-44d4-8fe6-6e9a12d96e4d@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <5VrcYF_OlOjJMuwDhVCVZSRIoCPxyVOs-eIke7nBljE=.07263973-1880-44d4-8fe6-6e9a12d96e4d@github.com>
Message-ID: <jt7lWBd8GaUK-PIchbMePNBYTcLzgq8HbKZ88sv2AWo=.7b79456e-a750-4f95-8ad4-e8c8ea4fbbff@github.com>

On Thu, 20 Apr 2023 18:53:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 59:
> 
>> 57:             if (serializedData[i] == 0x78) {
>> 58:                 firstPos = i;
>> 59:                 break;
> 
> Move setting the length code (lines 64-67) here and return immediately.

Fixed.

> test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 62:
> 
>> 60:             }
>> 61:         }
>> 62: 
> 
> The test should fail if it falls through without finding the BLOCKDATA. Just a double guard against the unexpected.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1175180242
PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1175180425

From rgiulietti at openjdk.org  Mon Apr 24 12:03:44 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 24 Apr 2023 12:03:44 GMT
Subject: RFR: JDK-8304423: Refactor FdLibm.java
In-Reply-To: <kkt3zVVtkAFIH4Joz82Xq8d5dhDX9VeA1p9sxNlS4XI=.7090fbc8-e059-47c0-9c12-65e56da9fc22@github.com>
References: <kkt3zVVtkAFIH4Joz82Xq8d5dhDX9VeA1p9sxNlS4XI=.7090fbc8-e059-47c0-9c12-65e56da9fc22@github.com>
Message-ID: <42w6bIexUmgF22V7k2HUk8vb6R6en82laV6_AFJ5_10=.0af0236e-6260-4f9f-8bc7-4ba86fcf1ca9@github.com>

On Sun, 23 Apr 2023 22:34:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Minor refactoring of FdLibm.java; will consider future refactorings with more substantive code changes in the future.

src/java.base/share/classes/java/lang/FdLibm.java line 76:

> 74:     private static final int SIGN_BIT        = 0x8000_0000;
> 75:     private static final int EXP_BITS        = 0x7ff0_0000;
> 76:     private static final int EXP_SIGNIF_BITS = 0x7fff_ffff;

These could be expressed in terms of the constants in `Double`. But perhaps it's not worth doing so, after all, as the reader is assumed to be quite knowledgeable.

Otherwise LGTM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13604#discussion_r1175183371

From simonis at openjdk.org  Mon Apr 24 12:06:51 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 24 Apr 2023 12:06:51 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions
In-Reply-To: <689URy0mqJMJ_339lBAJeTbAJgh1rzPs9ZGBBk2CK34=.c1f164ef-fc58-47ba-bd60-f95c449f31f8@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <689URy0mqJMJ_339lBAJeTbAJgh1rzPs9ZGBBk2CK34=.c1f164ef-fc58-47ba-bd60-f95c449f31f8@github.com>
Message-ID: <RJLP8mwl6bkwFJXpJ2SoDt68QScZxnxUt5QMOlVq0GU=.d7ae2365-d46f-4d59-9c99-8495c47cc87f@github.com>

On Thu, 20 Apr 2023 11:41:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 95:
> 
>> 93:     public static void main(String[] args) throws Exception {
>> 94:         try {
>> 95:             test_simpleArray_negative();
> 
> Inline these `test_*` methods. Move the `CustomFilter` as test class nested.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1175186828

From asotona at openjdk.org  Mon Apr 24 12:07:20 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 24 Apr 2023 12:07:20 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API
Message-ID: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>

Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.

This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 

Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 

Please review this pull request and attached CSR.

Thank you,
Adam

-------------

Commit messages:
 - 8306729: Add nominal descriptors of modules and packages to Constants API

Changes: https://git.openjdk.org/jdk/pull/13615/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306729
  Stats: 261 lines in 7 files changed: 252 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13615/head:pull/13615

PR: https://git.openjdk.org/jdk/pull/13615

From mcimadamore at openjdk.org  Mon Apr 24 12:08:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 24 Apr 2023 12:08:55 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v5]
In-Reply-To: <mNiwouJaJqT6SYzab7GCCf_p4MBg7sJEogc0ifXj6TQ=.c3137d33-0d98-439f-ba7c-0e7cfc1ac40e@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <fe5fyxgbheu8mpzTvRwUA79iIXXs6VUSpTMMyBexnuA=.546c8f7a-ea48-4f68-b812-5afea9526cfd@github.com>
 <mNiwouJaJqT6SYzab7GCCf_p4MBg7sJEogc0ifXj6TQ=.c3137d33-0d98-439f-ba7c-0e7cfc1ac40e@github.com>
Message-ID: <dVwjO6xUqNmixf02uuff4CDWM7aarFRLBdYHqyDskNg=.3662ebf4-0c82-48de-9cab-fbe7db3764b2@github.com>

On Mon, 24 Apr 2023 09:05:56 GMT, R?mi Forax <forax at openjdk.org> wrote:

> > I believe the exhaustiveness algorithm needs rules for union types, both in javac and in the JLS:
> > ...
> > I would expect the above switch to be exhaustive, since it covers all possible components of the union type. In other words, the union type should act as a sealed hierarchy which permits Foo and Bar - and the two cases should be merged together (e.g. `case Foo` + `case Bar` should cover `Foo | Bar`). For the records, I get same error on JDK 20.
> 
> Precise exception type, here, `Foo | Bar` inside a catch is not an union, it's a way to merge catches when the body of catches are the same. In term of typing, `Foo | Bar` behave as the lub of Foo and Bar, apart in a throw.
> 
> So the switch is not exhaustive here because `lub(Foo, Bar) = Exception`.
> 
> We may add a special case in JLS for supporting precise exception type in switch given that this issue have been reported several times, but this is not something that should be fixed by this PR.

I see the dance in 14.20 between:

"
 A catch clause whose exception parameter is denoted as a union of types is called a multi-catch clause. 
 "

And

"The declared type of an exception parameter that denotes its type as a union with alternatives D1 | D2 | ... | Dn is lub(D1, D2, ..., Dn). "

(Which is required to make membership (and other properties) work)

The reason I'm bringing this up in the context of the new exhaustiveness analysis is that this might add more ways to unify a pair of types in the exhaustiveness algorithm, hence leading to a more complex implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13074#issuecomment-1520030010

From simonis at openjdk.org  Mon Apr 24 12:11:47 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 24 Apr 2023 12:11:47 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions
In-Reply-To: <689URy0mqJMJ_339lBAJeTbAJgh1rzPs9ZGBBk2CK34=.c1f164ef-fc58-47ba-bd60-f95c449f31f8@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <689URy0mqJMJ_339lBAJeTbAJgh1rzPs9ZGBBk2CK34=.c1f164ef-fc58-47ba-bd60-f95c449f31f8@github.com>
Message-ID: <Y4VoEFl45eADktUx2OVU8C31OkJoQr_a8LaYLZ-fauk=.72c1c1cd-1242-45f3-8f39-66a3b3252c12@github.com>

On Thu, 20 Apr 2023 11:42:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 99:
> 
>> 97:             throw new Exception("ObjectInputStream::readObject() shouldn't throw a NegativeArraySizeException", nase);
>> 98:         } catch (ObjectStreamException ose) {
>> 99:             // OK, because a NegativeArraySizeException should be converted into a ObjectStreamException
> 
> Check the message from `ose` here?

Done. I only hope nobody will localize the exception message :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1175191844

From rgiulietti at openjdk.org  Mon Apr 24 12:18:55 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 24 Apr 2023 12:18:55 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v5]
In-Reply-To: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
Message-ID: <tjWx6Dqn8BF1BCGqLWYf8h_ox98Jol1y5NkO_UfacmU=.b6b8c2c4-29bc-4328-8cd1-629b76266e87@github.com>

> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Small optimization in private split().
  Added tests to compare String and Pattern implementations, in particular for one char regex.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13305/files
  - new: https://git.openjdk.org/jdk/pull/13305/files/178cb645..e7f0980b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13305&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13305&range=03-04

  Stats: 10 lines in 2 files changed: 7 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13305.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13305/head:pull/13305

PR: https://git.openjdk.org/jdk/pull/13305

From simonis at openjdk.org  Mon Apr 24 12:18:55 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 24 Apr 2023 12:18:55 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions
In-Reply-To: <689URy0mqJMJ_339lBAJeTbAJgh1rzPs9ZGBBk2CK34=.c1f164ef-fc58-47ba-bd60-f95c449f31f8@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <689URy0mqJMJ_339lBAJeTbAJgh1rzPs9ZGBBk2CK34=.c1f164ef-fc58-47ba-bd60-f95c449f31f8@github.com>
Message-ID: <do6DeaAbgXzcRhDWrMmm5n7Ng71HBj_UJqsCVfR_Hv4=.a33cf1a9-95c7-43d7-b995-34745233b4bc@github.com>

On Thu, 20 Apr 2023 11:58:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 109:
> 
>> 107:                 throw new Exception("ObjectInputStream::readObject() should catch NegativeArraySizeExceptions before filtering", ice);
>> 108:             }
>> 109:             // OK, because a NegativeArraySizeException should be converted into a ObjectStreamException *before* filtering
> 
> Sounds like we should really test for ICE with "Array length ... is negative" here. This would cover the case when filter rejected the class before that exception is thrown.

The test for the `InvalidClassException` created by the object input filter is just above the comment, but I added another check for the correct exception message just for the simple test without filter.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1175199339

From liach at openjdk.org  Mon Apr 24 12:32:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Apr 2023 12:32:53 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API
In-Reply-To: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
Message-ID: <Df0RMek3LMjsywtEM3LU--0C14CM202lzZsQaVib7XI=.d6ddc30a-4246-4424-b093-2d4112bc12dc@github.com>

On Mon, 24 Apr 2023 11:59:03 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
> 
> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
> 
> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
> 
> Please review this pull request and attached CSR.
> 
> Thank you,
> Adam

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 34:

> 32:  * <p>To create a {@linkplain PackageDesc} for a package, use {@link #of} or
> 33:  * {@link #ofInternalName(String)}.
> 34:  *

Needs a link to jvms 4.4.12. Same for ModuleDesc (4.4.11)

src/java.base/share/classes/java/lang/constant/PackageDescImpl.java line 37:

> 35:      * @throws IllegalArgumentException if the package name is invalid
> 36:      */
> 37:     public static String validateBinaryPackageName(String name) {

All these utility methods should be moved to ConstantUtils.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175212686
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175209163

From jlahoda at openjdk.org  Mon Apr 24 12:56:55 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 24 Apr 2023 12:56:55 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v5]
In-Reply-To: <dVwjO6xUqNmixf02uuff4CDWM7aarFRLBdYHqyDskNg=.3662ebf4-0c82-48de-9cab-fbe7db3764b2@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <fe5fyxgbheu8mpzTvRwUA79iIXXs6VUSpTMMyBexnuA=.546c8f7a-ea48-4f68-b812-5afea9526cfd@github.com>
 <mNiwouJaJqT6SYzab7GCCf_p4MBg7sJEogc0ifXj6TQ=.c3137d33-0d98-439f-ba7c-0e7cfc1ac40e@github.com>
 <dVwjO6xUqNmixf02uuff4CDWM7aarFRLBdYHqyDskNg=.3662ebf4-0c82-48de-9cab-fbe7db3764b2@github.com>
Message-ID: <7xVX0OBbNW0m6KvSLSWGMablU96uP0atzt5XtFII6Qg=.36045555-1ac8-423c-9596-8dd16185bf01@github.com>

On Mon, 24 Apr 2023 12:05:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > > I believe the exhaustiveness algorithm needs rules for union types, both in javac and in the JLS:
> > > ...
> > > I would expect the above switch to be exhaustive, since it covers all possible components of the union type. In other words, the union type should act as a sealed hierarchy which permits Foo and Bar - and the two cases should be merged together (e.g. `case Foo` + `case Bar` should cover `Foo | Bar`). For the records, I get same error on JDK 20.
> > 
> > 
> > Precise exception type, here, `Foo | Bar` inside a catch is not an union, it's a way to merge catches when the body of catches are the same. In term of typing, `Foo | Bar` behave as the lub of Foo and Bar, apart in a throw.
> > So the switch is not exhaustive here because `lub(Foo, Bar) = Exception`.
> > We may add a special case in JLS for supporting precise exception type in switch given that this issue have been reported several times, but this is not something that should be fixed by this PR.
> 
> I see the dance in 14.20 between:
> 
> " A catch clause whose exception parameter is denoted as a union of types is called a multi-catch clause. "
> 
> And
> 
> "The declared type of an exception parameter that denotes its type as a union with alternatives D1 | D2 | ... | Dn is lub(D1, D2, ..., Dn). "
> 
> (Which is required to make membership (and other properties) work)
> 
> The reason I'm bringing this up in the context of the new exhaustiveness analysis is that this might add more ways to unify a pair of types in the exhaustiveness algorithm, hence leading to a more complex implementation.

In this case, as long as the union type could only be present at the top level (as opposed to e.g. a type of a record component), we could simply require all components to be covered for union types for exhaustiveness in `checkCovered`, no? We could do something different, if we had a good reason, but enhancing `checkCovered` should be enough, and shouldn't be too difficult (as long as the spec would say so). Do I miss something?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13074#issuecomment-1520105514

From jvernee at openjdk.org  Mon Apr 24 13:11:46 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 24 Apr 2023 13:11:46 GMT
Subject: RFR: 8305093: Linker cache should not take layout names into
 account [v2]
In-Reply-To: <Kpqq7L9icuWNfO94Njyeb-2lhu5pnEZxpMj8vJbTGb8=.2dfe97c7-ae6d-4c71-a353-987a374eb64a@github.com>
References: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
 <7_Nk2AOcLFfPf5yfpg1aAW97junefRNAY857VrpS9xs=.9640e499-4b17-44bc-82ea-406fff99a9cf@github.com>
 <Kpqq7L9icuWNfO94Njyeb-2lhu5pnEZxpMj8vJbTGb8=.2dfe97c7-ae6d-4c71-a353-987a374eb64a@github.com>
Message-ID: <M9BtlkiPpGBie3G_aIY3a4ky2OjqCpTXspWzxOzZzSY=.7e14f316-b1de-463d-86db-7d533c609ef0@github.com>

On Mon, 24 Apr 2023 11:46:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use al instead of ValueLayout.ADDRESS
>
> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 142:
> 
>> 140:         // since the linker already restricts those such that they will always be the same
>> 141:         return switch (ml) {
>> 142:             case StructLayout sl -> MemoryLayout.structLayout(stripNames(sl.memberLayouts()));
> 
> shouldn't names be also stripped from enclosing struct/union/sequence?

That should already happen because we're recreating the layout here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13562#discussion_r1175260317

From asotona at openjdk.org  Mon Apr 24 13:18:09 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 24 Apr 2023 13:18:09 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v2]
In-Reply-To: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
Message-ID: <kEbO492DOLcJ1zEpbKqSqurUhQZ_TPYQNTf6iycfVGE=.b8147b3f-b76d-4ff8-9aa4-7c13ab29c55f@github.com>

> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
> 
> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
> 
> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
> 
> Please review this pull request and attached CSR.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  added links to JVMS and utility methods moved to ConstantUtils

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13615/files
  - new: https://git.openjdk.org/jdk/pull/13615/files/aede94fd..0ca0b56e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=00-01

  Stats: 123 lines in 5 files changed: 54 ins; 62 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13615/head:pull/13615

PR: https://git.openjdk.org/jdk/pull/13615

From asotona at openjdk.org  Mon Apr 24 13:18:14 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 24 Apr 2023 13:18:14 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v2]
In-Reply-To: <Df0RMek3LMjsywtEM3LU--0C14CM202lzZsQaVib7XI=.d6ddc30a-4246-4424-b093-2d4112bc12dc@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <Df0RMek3LMjsywtEM3LU--0C14CM202lzZsQaVib7XI=.d6ddc30a-4246-4424-b093-2d4112bc12dc@github.com>
Message-ID: <ZXLHpRB9BkecqEx7S6zfRotUpKKndfpFAe0gzDImEQ0=.3c6b0daf-31b2-4dda-9975-007ecaff70ff@github.com>

On Mon, 24 Apr 2023 12:28:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added links to JVMS and utility methods moved to ConstantUtils
>
> src/java.base/share/classes/java/lang/constant/PackageDesc.java line 34:
> 
>> 32:  * <p>To create a {@linkplain PackageDesc} for a package, use {@link #of} or
>> 33:  * {@link #ofInternalName(String)}.
>> 34:  *
> 
> Needs a link to jvms 4.4.12. Same for ModuleDesc (4.4.11)

fixed, thanks.

> src/java.base/share/classes/java/lang/constant/PackageDescImpl.java line 37:
> 
>> 35:      * @throws IllegalArgumentException if the package name is invalid
>> 36:      */
>> 37:     public static String validateBinaryPackageName(String name) {
> 
> All these utility methods should be moved to ConstantUtils.

fixed, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175262182
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175265741

From jvernee at openjdk.org  Mon Apr 24 13:20:05 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 24 Apr 2023 13:20:05 GMT
Subject: RFR: 8304986: Upcall stubs should support capureCallState
In-Reply-To: <fpDsVP2fku1RhP_aE4xA5ikUIiK1jJevWy26YNDVo1c=.5a9a5363-1d8c-4de1-b9d7-5b3e140a948d@github.com>
References: <fpDsVP2fku1RhP_aE4xA5ikUIiK1jJevWy26YNDVo1c=.5a9a5363-1d8c-4de1-b9d7-5b3e140a948d@github.com>
Message-ID: <_puDoD0ej-K0s8v-fmTR34AiXJWuRKW37Il4A_mWyAU=.ee7f2671-6e3b-4621-82d2-0b265013f81d@github.com>

On Fri, 21 Apr 2023 18:25:32 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Implement captureCallState support for upcall stubs.
> 
> The method handle of an upcall stub linked with this linker option has an additional leading memory segment parameter into which the capture state (e.g. errno) should be written. After returning from Java, this value is then actually written to the corresponding execution state.

There is a longer string to pull here: someone might want to receive the capture state as input to an upcall, or conversely, pass the capture state to a downcall.

Right now this seems to be not really needed, so will revisit later

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13588#issuecomment-1520143832

From jvernee at openjdk.org  Mon Apr 24 13:20:06 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 24 Apr 2023 13:20:06 GMT
Subject: Withdrawn: 8304986: Upcall stubs should support capureCallState
In-Reply-To: <fpDsVP2fku1RhP_aE4xA5ikUIiK1jJevWy26YNDVo1c=.5a9a5363-1d8c-4de1-b9d7-5b3e140a948d@github.com>
References: <fpDsVP2fku1RhP_aE4xA5ikUIiK1jJevWy26YNDVo1c=.5a9a5363-1d8c-4de1-b9d7-5b3e140a948d@github.com>
Message-ID: <ok7NuKvfwBS4YMglCttQL4ihjW52v1DuOvnvRnE73Qg=.d55245b8-c5c6-4080-bda6-d32ede042b29@github.com>

On Fri, 21 Apr 2023 18:25:32 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Implement captureCallState support for upcall stubs.
> 
> The method handle of an upcall stub linked with this linker option has an additional leading memory segment parameter into which the capture state (e.g. errno) should be written. After returning from Java, this value is then actually written to the corresponding execution state.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/13588

From mcimadamore at openjdk.org  Mon Apr 24 13:54:03 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 24 Apr 2023 13:54:03 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v5]
In-Reply-To: <7xVX0OBbNW0m6KvSLSWGMablU96uP0atzt5XtFII6Qg=.36045555-1ac8-423c-9596-8dd16185bf01@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <fe5fyxgbheu8mpzTvRwUA79iIXXs6VUSpTMMyBexnuA=.546c8f7a-ea48-4f68-b812-5afea9526cfd@github.com>
 <mNiwouJaJqT6SYzab7GCCf_p4MBg7sJEogc0ifXj6TQ=.c3137d33-0d98-439f-ba7c-0e7cfc1ac40e@github.com>
 <dVwjO6xUqNmixf02uuff4CDWM7aarFRLBdYHqyDskNg=.3662ebf4-0c82-48de-9cab-fbe7db3764b2@github.com>
 <7xVX0OBbNW0m6KvSLSWGMablU96uP0atzt5XtFII6Qg=.36045555-1ac8-423c-9596-8dd16185bf01@github.com>
Message-ID: <EyFCSGz7CN9I36xAjyZLrX647olesTph0BjkHTDFlcw=.306506be-4162-4c98-8bb4-78928f7710a0@github.com>

On Mon, 24 Apr 2023 12:53:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> In this case, as long as the union type could only be present at the top level (as opposed to e.g. a type of a record component), we could simply require all components to be covered for union types for exhaustiveness in `checkCovered`, no? We could do something different, if we had a good reason, but enhancing `checkCovered` should be enough, and shouldn't be too difficult (as long as the spec would say so). Do I miss something?

I believe that is a correct assessment. Technically speaking though, I'm not sure the JLS can be enhanced to do that - given that, as Remi reminded me, union types are not a thing. The _declaration_ of a union type parameter is a thing, but then the underlying declared type of the parameter is just the LUB. This means that the JLS can't track which expressions have union types. Note that saying stuff like `if the selector expression is a multi-catch parameter` won't work either, given that with `var` you can alias that on a different local. So, if things are not wired up a the type level (as it is currently the case), there's not much we can do I'm afraid.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13074#issuecomment-1520200078

From jlahoda at openjdk.org  Mon Apr 24 13:54:05 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 24 Apr 2023 13:54:05 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v5]
In-Reply-To: <TzkAOuRiuEZAp5ZhmH1CSOZwSOGvB4QTB203Ngin75w=.b1276a46-7f00-49fa-8147-2fafdb110963@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <fe5fyxgbheu8mpzTvRwUA79iIXXs6VUSpTMMyBexnuA=.546c8f7a-ea48-4f68-b812-5afea9526cfd@github.com>
 <TzkAOuRiuEZAp5ZhmH1CSOZwSOGvB4QTB203Ngin75w=.b1276a46-7f00-49fa-8147-2fafdb110963@github.com>
Message-ID: <O9gQu7meAzVW29AZ7JT6hN18kvE7a2BHtt9eQ2IDjxY=.893f9d6b-b1fc-476b-ab61-4d928163502e@github.com>

On Fri, 21 Apr 2023 16:49:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Adding test.
>>  - Removing redundant continue, as noted on the review.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 315:
> 
>> 313:         Object[] labels = resolvedLabels.resolvedLabels;
>> 314: 
>> 315:         // Dumbest possible strategy
> 
> I guess that given that we can't make any assumption about order here, this is the only possible strategy so I guess it makes sense to remove the comment

I certainly hope we can do better. At very least, the current implementation is checking the type of the labels on each pass through the loop. The types of the labels don't change, so checking them again and again is not necessary. In some cases, it might be possible to improve even further, like e.g. in a case where all the labels are enum constants, then we could use a e.g. mapping table.

There's a PR proposed that shows some of that:
https://github.com/openjdk/jdk/pull/9779

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1175260039

From rriggs at openjdk.org  Mon Apr 24 14:39:59 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 24 Apr 2023 14:39:59 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v2]
In-Reply-To: <kEbO492DOLcJ1zEpbKqSqurUhQZ_TPYQNTf6iycfVGE=.b8147b3f-b76d-4ff8-9aa4-7c13ab29c55f@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <kEbO492DOLcJ1zEpbKqSqurUhQZ_TPYQNTf6iycfVGE=.b8147b3f-b76d-4ff8-9aa4-7c13ab29c55f@github.com>
Message-ID: <BfFONWbKNsxLTGVNfBKyEVUPhLgDm_fx_lS3MyMsvMQ=.372fac65-e55f-4074-a63b-fcba94b6aef4@github.com>

On Mon, 24 Apr 2023 13:18:09 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
>> 
>> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
>> 
>> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
>> 
>> Please review this pull request and attached CSR.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added links to JVMS and utility methods moved to ConstantUtils

src/java.base/share/classes/java/lang/constant/ConstantUtils.java line 80:

> 78:     /**
> 79:      * Validates the correctness of a binary package name. In particular checks for the presence of
> 80:      * invalid characters in the name.

It may be useful to note that the empty string are considered valid. 
Also add @throws NPE; there's an implicit null check in checking the length.
Also in validateBinaryPackageName and validateModuleName.

src/java.base/share/classes/java/lang/constant/ConstantUtils.java line 130:

> 128:         }
> 129:         return name;
> 130:     }

If these are performance sensitive or get used a lot, should there be an array of flags indexed by the byte/char to indicate the valid cases?

src/java.base/share/classes/java/lang/constant/ModuleDescImpl.java line 27:

> 25: package java.lang.constant;
> 26: 
> 27: record ModuleDescImpl(String moduleName) implements ModuleDesc {

Given the validation is elsewhere, it might be useful to add a comment saying the moduleName must have been validated.

src/java.base/share/classes/java/lang/constant/package-info.java line 92:

> 90:  * reading and writing APIs.
> 91:  *
> 92:  * <p>Another members of this package are {@link java.lang.constant.ModuleDesc}

"Another" -> "Other"

test/jdk/java/lang/constant/ModuleDescTest.java line 37:

> 35: 
> 36: class ModuleDescTest {
> 37: 

Add tests for empty and null arguments.

test/jdk/java/lang/constant/PackageDescTest.java line 39:

> 37: 
> 38: class PackageDescTest {
> 39:     @ParameterizedTest

Add tests for empty and null arguments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175375915
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175366692
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175371637
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175382854
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175383972
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175384822

From simonis at openjdk.org  Mon Apr 24 14:41:58 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 24 Apr 2023 14:41:58 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v2]
In-Reply-To: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
Message-ID: <EcquNmlW2gNL6XeesD60LIJAUGnpZuDcegRczIGsGZ8=.6649cc69-4392-47a1-ac23-8d70b38b3fdd@github.com>

> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
> 
> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
> 
> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
> 
> Returns:
> the non-negative number of array elements when deserializing an array of the class, otherwise -1
> 
> but currently returns a negative value if the array length is negative.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Addresed review comments of @turbanoff, @shipilev and @RogerRiggs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13540/files
  - new: https://git.openjdk.org/jdk/pull/13540/files/d68ceaab..f242dca2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13540&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13540&range=00-01

  Stats: 53 lines in 2 files changed: 17 ins; 20 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/13540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13540/head:pull/13540

PR: https://git.openjdk.org/jdk/pull/13540

From simonis at openjdk.org  Mon Apr 24 14:41:59 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 24 Apr 2023 14:41:59 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions
In-Reply-To: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
Message-ID: <V6XNgEsRyQCDYEo0VNBNQTO4mRZth4ghNNOy_R9bOcM=.464aa7f7-0ff3-4727-9746-d55f55d7dd22@github.com>

On Wed, 19 Apr 2023 16:47:33 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
> 
> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
> 
> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
> 
> Returns:
> the non-negative number of array elements when deserializing an array of the class, otherwise -1
> 
> but currently returns a negative value if the array length is negative.

Hi @turbanoff, @shipilev and @RogerRiggs,

Thanks for your reviews so far. I've hopefully addressed them all. I've also created a CSR for the issue:

https://bugs.openjdk.org/browse/JDK-8306744

Please feel  free to review it :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13540#issuecomment-1520290530

From mcimadamore at openjdk.org  Mon Apr 24 14:43:52 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 24 Apr 2023 14:43:52 GMT
Subject: RFR: 8305093: Linker cache should not take layout names into
 account [v2]
In-Reply-To: <7_Nk2AOcLFfPf5yfpg1aAW97junefRNAY857VrpS9xs=.9640e499-4b17-44bc-82ea-406fff99a9cf@github.com>
References: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
 <7_Nk2AOcLFfPf5yfpg1aAW97junefRNAY857VrpS9xs=.9640e499-4b17-44bc-82ea-406fff99a9cf@github.com>
Message-ID: <t0WzVC4EuQfW4cKWNnib53bSOCFtJFPbXsk05garx00=.486f5045-66e2-4ad9-93df-899a4d3ee055@github.com>

On Fri, 21 Apr 2023 01:03:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Strip names from the function descriptors used in linkage requests. The names are not important for classification, and this will allow the cached MethodHandle/UpcallStubFactory to be shared across linkage request with the same structure, but with layouts that have different names.
>> 
>> I also have another implementation that avoids copying all the layouts, and instead re-implemented equals and hashCode in the LinkRequest wrapper: https://github.com/openjdk/jdk/compare/pr/13079...JornVernee:jdk:NoNameCache But, this seems too complex. Linking code is not very performance sensitive, so I instead went with a simpler approach in this patch.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use al instead of ValueLayout.ADDRESS

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13562#pullrequestreview-1398171041

From jlahoda at openjdk.org  Mon Apr 24 15:16:18 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 24 Apr 2023 15:16:18 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v6]
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <nBwyluZ1PKhz3xTB2LSndQjF0DjuojItWQpaHhh1JIM=.57620d8a-1fbf-4505-9157-1ca2fcae2cb9@github.com>

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review changes.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13074/files
  - new: https://git.openjdk.org/jdk/pull/13074/files/2cc3e11d..f0584725

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=04-05

  Stats: 12 lines in 2 files changed: 8 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074

PR: https://git.openjdk.org/jdk/pull/13074

From qamai at openjdk.org  Mon Apr 24 15:27:52 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 24 Apr 2023 15:27:52 GMT
Subject: RFR: 8306008: Several Vector API tests fail for client VM after
 JDK-8304450
In-Reply-To: <TDcfSAbMANHhRfHfZSAoKxfHPrsVqHrbE0gz1RwUBcg=.de344a1c-8d0e-477b-b8a2-209595967254@github.com>
References: <TDcfSAbMANHhRfHfZSAoKxfHPrsVqHrbE0gz1RwUBcg=.de344a1c-8d0e-477b-b8a2-209595967254@github.com>
Message-ID: <--mqr-SBy35gmNVh6r-gQF0Ow9o5wuVDf80hULbsbEo=.c8fbade0-e369-4ad8-bc26-4549c457ecf0@github.com>

On Tue, 18 Apr 2023 12:21:11 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Please review this patch which fixes the errors on machines where TypeMaxVector has a length of 64 bits. I take an extra cautious approach and fall back to putting elements one by one if the length is an unexpected value.
> 
> All jdk/incubator/vector tests passed with MaxVectorSize=8, which fails without this patch.
> 
> Thanks a lot.

Thanks a lot for your reviews and testings, I will integrate the patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13508#issuecomment-1520387082

From cstein at openjdk.org  Mon Apr 24 15:31:53 2023
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 24 Apr 2023 15:31:53 GMT
Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v6]
In-Reply-To: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
References: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
Message-ID: <Bt8Vdqd0Yg1N5Km4zR_zIGv-zoIoBC_4ABjka_NQnXk=.7cf915ba-6519-4abe-beea-891ca3c3eac0@github.com>

> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
> - #11272
> 
> Changes:
> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc`
> - [x] Use shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module

Christian Stein has updated the pull request incrementally with five additional commits since the last revision:

 - Fix hard-coded test
 - Clean up configuration
 - Update test
 - Fix generation of API documentation
 - Add more export directives

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12997/files
  - new: https://git.openjdk.org/jdk/pull/12997/files/f9a94225..26d14f82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=04-05

  Stats: 18 lines in 7 files changed: 13 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12997/head:pull/12997

PR: https://git.openjdk.org/jdk/pull/12997

From mchung at openjdk.org  Mon Apr 24 15:31:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 24 Apr 2023 15:31:56 GMT
Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v5]
In-Reply-To: <O0pgPzx4KLyyX-_yuJYd97cgTFCPOp_dY62qSEbtl7U=.000949af-d686-4e61-a2e4-980549eeed59@github.com>
References: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
 <O0pgPzx4KLyyX-_yuJYd97cgTFCPOp_dY62qSEbtl7U=.000949af-d686-4e61-a2e4-980549eeed59@github.com>
Message-ID: <tWdFxBdWAKPFDhaAjp3P-n2pS8SgMAerb7iUGUQV8ec=.00ced3ea-513a-4836-8cd8-2ace44665525@github.com>

On Sat, 22 Apr 2023 12:15:38 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
>> - #11272
>> 
>> Changes:
>> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc`
>> - [x] Use shared `CommandLine.java` in `jdk.compiler` module
>> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
>> - [x] Remove `CommandLine.java` from `jdk.compiler` module
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Export `jdk.internal.opt` to `jdk.javadoc.interim`, too

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12997#pullrequestreview-1396760637

From cstein at openjdk.org  Mon Apr 24 15:31:56 2023
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 24 Apr 2023 15:31:56 GMT
Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v5]
In-Reply-To: <O0pgPzx4KLyyX-_yuJYd97cgTFCPOp_dY62qSEbtl7U=.000949af-d686-4e61-a2e4-980549eeed59@github.com>
References: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
 <O0pgPzx4KLyyX-_yuJYd97cgTFCPOp_dY62qSEbtl7U=.000949af-d686-4e61-a2e4-980549eeed59@github.com>
Message-ID: <BNGUcRhDcxSBzANAMPpdmb5tfdkq8orpgN7-COJcQyE=.79dbc389-a878-4236-9fcc-1518e55b4cf7@github.com>

On Sat, 22 Apr 2023 12:15:38 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
>> - #11272
>> 
>> Changes:
>> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc`
>> - [x] Use shared `CommandLine.java` in `jdk.compiler` module
>> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
>> - [x] Remove `CommandLine.java` from `jdk.compiler` module
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Export `jdk.internal.opt` to `jdk.javadoc.interim`, too

Converted this PR to draft mode again: interim langtools are not happy, yet.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12997#issuecomment-1518633910

From cstein at openjdk.org  Mon Apr 24 15:40:04 2023
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 24 Apr 2023 15:40:04 GMT
Subject: Integrated: 8304896: Update to use jtreg 7.2
In-Reply-To: <SW7PTuDcEugo22nTk04k3aEL9Ineq5T25CRUnhDc7Vo=.0e4e96d2-f171-45c2-a4a7-5b83c3cdb548@github.com>
References: <SW7PTuDcEugo22nTk04k3aEL9Ineq5T25CRUnhDc7Vo=.0e4e96d2-f171-45c2-a4a7-5b83c3cdb548@github.com>
Message-ID: <jylUmaOUwWzO-ciKAutAzvpE1ARz7b779-xkDrkiTKs=.c25202d2-9ced-4689-99c6-346c66443005@github.com>

On Mon, 17 Apr 2023 14:56:16 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.2.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

This pull request has now been integrated.

Changeset: 2763cf14
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2763cf14e6a174511ae8af471690ef18b10b3998
Stats:     9 lines in 8 files changed: 0 ins; 0 del; 9 mod

8304896: Update to use jtreg 7.2

Reviewed-by: erikj, lmesnik, iris

-------------

PR: https://git.openjdk.org/jdk/pull/13496

From vromero at openjdk.org  Mon Apr 24 15:41:05 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 24 Apr 2023 15:41:05 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v5]
In-Reply-To: <O9gQu7meAzVW29AZ7JT6hN18kvE7a2BHtt9eQ2IDjxY=.893f9d6b-b1fc-476b-ab61-4d928163502e@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <fe5fyxgbheu8mpzTvRwUA79iIXXs6VUSpTMMyBexnuA=.546c8f7a-ea48-4f68-b812-5afea9526cfd@github.com>
 <TzkAOuRiuEZAp5ZhmH1CSOZwSOGvB4QTB203Ngin75w=.b1276a46-7f00-49fa-8147-2fafdb110963@github.com>
 <O9gQu7meAzVW29AZ7JT6hN18kvE7a2BHtt9eQ2IDjxY=.893f9d6b-b1fc-476b-ab61-4d928163502e@github.com>
Message-ID: <03FNRCkfJCn9AntylkhNxEwopYUh5xwaDgOrh9tsAoU=.24c0d388-7726-49cf-82ce-3d3168cc724b@github.com>

On Mon, 24 Apr 2023 13:08:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 315:
>> 
>>> 313:         Object[] labels = resolvedLabels.resolvedLabels;
>>> 314: 
>>> 315:         // Dumbest possible strategy
>> 
>> I guess that given that we can't make any assumption about order here, this is the only possible strategy so I guess it makes sense to remove the comment
>
> I certainly hope we can do better. At very least, the current implementation is checking the type of the labels on each pass through the loop. The types of the labels don't change, so checking them again and again is not necessary. In some cases, it might be possible to improve even further, like e.g. in a case where all the labels are enum constants, then we could use a e.g. mapping table.
> 
> There's a PR proposed that shows some of that:
> https://github.com/openjdk/jdk/pull/9779

I see, interesting

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1175471366

From naoto at openjdk.org  Mon Apr 24 15:41:06 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Apr 2023 15:41:06 GMT
Subject: Integrated: 8304836: Make MALLOC_MIN4 macro more robust
In-Reply-To: <IyZnv9X8fFGbxKskxf6t-fDnui9npQ1B-jBGkLjqZJc=.f07d4469-f9db-4081-9ed5-6b3cba2e1795@github.com>
References: <IyZnv9X8fFGbxKskxf6t-fDnui9npQ1B-jBGkLjqZJc=.f07d4469-f9db-4081-9ed5-6b3cba2e1795@github.com>
Message-ID: <38WD-kj5vUG3Dd2h2-AMt8CsWltjR_60aoUhPH8xU_c=.851f1363-c57f-4a46-a0af-d7d1569f75f6@github.com>

On Thu, 20 Apr 2023 18:39:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The current macro assumes the argument is `jint` because all locations pass `jint`. However, this would not work if a wider type such as `jlong` is passed. Removing the `unsigned` cast and make the condition explicit would make the macro more robust.

This pull request has now been integrated.

Changeset: f32adaf8
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f32adaf89fede5262db2cb5517fc649a87e0714d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8304836: Make MALLOC_MIN4 macro more robust

Reviewed-by: bchristi

-------------

PR: https://git.openjdk.org/jdk/pull/13564

From asotona at openjdk.org  Mon Apr 24 15:50:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 24 Apr 2023 15:50:57 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v2]
In-Reply-To: <BfFONWbKNsxLTGVNfBKyEVUPhLgDm_fx_lS3MyMsvMQ=.372fac65-e55f-4074-a63b-fcba94b6aef4@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <kEbO492DOLcJ1zEpbKqSqurUhQZ_TPYQNTf6iycfVGE=.b8147b3f-b76d-4ff8-9aa4-7c13ab29c55f@github.com>
 <BfFONWbKNsxLTGVNfBKyEVUPhLgDm_fx_lS3MyMsvMQ=.372fac65-e55f-4074-a63b-fcba94b6aef4@github.com>
Message-ID: <inI7pY4n_ndwtBDRjihMPceXF8b5gnYaGIuLaYirBP4=.883fe1b1-9963-4f0d-aada-98d39c52fc3b@github.com>

On Mon, 24 Apr 2023 14:30:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added links to JVMS and utility methods moved to ConstantUtils
>
> src/java.base/share/classes/java/lang/constant/ConstantUtils.java line 80:
> 
>> 78:     /**
>> 79:      * Validates the correctness of a binary package name. In particular checks for the presence of
>> 80:      * invalid characters in the name.
> 
> It may be useful to note that the empty string are considered valid. 
> Also add @throws NPE; there's an implicit null check in checking the length.
> Also in validateBinaryPackageName and validateModuleName.

I'll add that notes, thanks.

> src/java.base/share/classes/java/lang/constant/ConstantUtils.java line 130:
> 
>> 128:         }
>> 129:         return name;
>> 130:     }
> 
> If these are performance sensitive or get used a lot, should there be an array of flags indexed by the byte/char to indicate the valid cases?

It is just a range check and three escaped characters check. The range check can be implemented bit-wise and escaped check may be by a switch case, however I don't think there would be any performance benefits.

> src/java.base/share/classes/java/lang/constant/ModuleDescImpl.java line 27:
> 
>> 25: package java.lang.constant;
>> 26: 
>> 27: record ModuleDescImpl(String moduleName) implements ModuleDesc {
> 
> Given the validation is elsewhere, it might be useful to add a comment saying the moduleName must have been validated.

I'll add it, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175483446
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175482952
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175484294

From shade at openjdk.org  Mon Apr 24 16:01:56 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 24 Apr 2023 16:01:56 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v2]
In-Reply-To: <EcquNmlW2gNL6XeesD60LIJAUGnpZuDcegRczIGsGZ8=.6649cc69-4392-47a1-ac23-8d70b38b3fdd@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <EcquNmlW2gNL6XeesD60LIJAUGnpZuDcegRczIGsGZ8=.6649cc69-4392-47a1-ac23-8d70b38b3fdd@github.com>
Message-ID: <a24W0ATdimi_sDufP2ozdW66xyopfuG6Bq1z-ukuA_Y=.9879da5d-5ab1-4b9d-86d7-31690e74ce84@github.com>

On Mon, 24 Apr 2023 14:41:58 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addresed review comments of @turbanoff, @shipilev and @RogerRiggs

Test questions:

test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 88:

> 86:         } catch (ObjectStreamException ose) {
> 87:             // OK, because a NegativeArraySizeException should be converted into a ObjectStreamException
> 88:             if ("Array length is negative".equals(ose.getMessage())) {

This feels like `!equals`, i.e. throw exception when the message is *not* "Array length is negative"?

test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 104:

> 102:             }
> 103:             // OK, because a NegativeArraySizeException should be converted into a ObjectStreamException *before* filtering
> 104:             if ("Array length is negative".equals(ose.getMessage())) {

Same as above.

-------------

Changes requested by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13540#pullrequestreview-1398354018
PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1175496936
PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1175497098

From shade at openjdk.org  Mon Apr 24 16:10:55 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 24 Apr 2023 16:10:55 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v2]
In-Reply-To: <EcquNmlW2gNL6XeesD60LIJAUGnpZuDcegRczIGsGZ8=.6649cc69-4392-47a1-ac23-8d70b38b3fdd@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <EcquNmlW2gNL6XeesD60LIJAUGnpZuDcegRczIGsGZ8=.6649cc69-4392-47a1-ac23-8d70b38b3fdd@github.com>
Message-ID: <UmBGTfC3ndfU4HMBdbqZJ5vpSGWp9ORu4XIvJkr1CdQ=.9c71d4c0-5182-46ff-9b11-68f743fe3db1@github.com>

On Mon, 24 Apr 2023 14:41:58 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addresed review comments of @turbanoff, @shipilev and @RogerRiggs

Also, merge from master to get Windows GHA fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13540#issuecomment-1520454810

From vromero at openjdk.org  Mon Apr 24 16:22:09 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 24 Apr 2023 16:22:09 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v6]
In-Reply-To: <nBwyluZ1PKhz3xTB2LSndQjF0DjuojItWQpaHhh1JIM=.57620d8a-1fbf-4505-9157-1ca2fcae2cb9@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <nBwyluZ1PKhz3xTB2LSndQjF0DjuojItWQpaHhh1JIM=.57620d8a-1fbf-4505-9157-1ca2fcae2cb9@github.com>
Message-ID: <2TAN9lBNny_FQKYr0xQrlBqFrlGJshAzJj6rCaQ_irA=.86823002-b715-40f7-9b4e-793db4afcd56@github.com>

On Mon, 24 Apr 2023 15:16:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review changes.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 101:

> 99:      * <p>
> 100:      * The value of the {@code restart} index must be between {@code 0} and
> 101:      * the length of the {@code labels} array, of an {@link IndexOutOfBoundsException}

typo: `of an` -> `or an`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1175520267

From asotona at openjdk.org  Mon Apr 24 16:26:02 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 24 Apr 2023 16:26:02 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v3]
In-Reply-To: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
Message-ID: <k2_HG58fJQHb9Aif2oMk8lu3e0cpVafN-M8RXVkxABU=.6dde0370-7e25-4b2f-95d7-39121651c883@github.com>

> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
> 
> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
> 
> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
> 
> Please review this pull request and attached CSR.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Doc fixes + added null and empty tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13615/files
  - new: https://git.openjdk.org/jdk/pull/13615/files/0ca0b56e..47aa52d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=01-02

  Stats: 32 lines in 6 files changed: 26 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13615/head:pull/13615

PR: https://git.openjdk.org/jdk/pull/13615

From asotona at openjdk.org  Mon Apr 24 16:26:08 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 24 Apr 2023 16:26:08 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v2]
In-Reply-To: <BfFONWbKNsxLTGVNfBKyEVUPhLgDm_fx_lS3MyMsvMQ=.372fac65-e55f-4074-a63b-fcba94b6aef4@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <kEbO492DOLcJ1zEpbKqSqurUhQZ_TPYQNTf6iycfVGE=.b8147b3f-b76d-4ff8-9aa4-7c13ab29c55f@github.com>
 <BfFONWbKNsxLTGVNfBKyEVUPhLgDm_fx_lS3MyMsvMQ=.372fac65-e55f-4074-a63b-fcba94b6aef4@github.com>
Message-ID: <KPLQZV1It6XA8T8NyCiNGJU_wuV53O1d6YIk0mCU9BA=.6d39acea-1314-4441-afca-a2793d37a2e8@github.com>

On Mon, 24 Apr 2023 14:35:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added links to JVMS and utility methods moved to ConstantUtils
>
> src/java.base/share/classes/java/lang/constant/package-info.java line 92:
> 
>> 90:  * reading and writing APIs.
>> 91:  *
>> 92:  * <p>Another members of this package are {@link java.lang.constant.ModuleDesc}
> 
> "Another" -> "Other"

Fixed, thanks.

> test/jdk/java/lang/constant/ModuleDescTest.java line 37:
> 
>> 35: 
>> 36: class ModuleDescTest {
>> 37: 
> 
> Add tests for empty and null arguments.

added, thanks.

> test/jdk/java/lang/constant/PackageDescTest.java line 39:
> 
>> 37: 
>> 38: class PackageDescTest {
>> 39:     @ParameterizedTest
> 
> Add tests for empty and null arguments.

added, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175522533
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175521484
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175521842

From duke at openjdk.org  Mon Apr 24 16:30:55 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 24 Apr 2023 16:30:55 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v3]
In-Reply-To: <k2_HG58fJQHb9Aif2oMk8lu3e0cpVafN-M8RXVkxABU=.6dde0370-7e25-4b2f-95d7-39121651c883@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <k2_HG58fJQHb9Aif2oMk8lu3e0cpVafN-M8RXVkxABU=.6dde0370-7e25-4b2f-95d7-39121651c883@github.com>
Message-ID: <NWz6JgOyftpmZlIKMiHz7IXthK8WuJBvFbsZO1CIqEA=.834360bc-73b3-4e3f-a6d3-1a77e3531775@github.com>

On Mon, 24 Apr 2023 16:26:02 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
>> 
>> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
>> 
>> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
>> 
>> Please review this pull request and attached CSR.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doc fixes + added null and empty tests

Note?that other?`*Impl`?classes in?`java.lang.constant` perform?validation in?their?constructors and?provide?custom `toString()`?formatting and?they?also don?t?use?records.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13615#issuecomment-1520483426

From liach at openjdk.org  Mon Apr 24 16:36:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Apr 2023 16:36:53 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v3]
In-Reply-To: <NWz6JgOyftpmZlIKMiHz7IXthK8WuJBvFbsZO1CIqEA=.834360bc-73b3-4e3f-a6d3-1a77e3531775@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <k2_HG58fJQHb9Aif2oMk8lu3e0cpVafN-M8RXVkxABU=.6dde0370-7e25-4b2f-95d7-39121651c883@github.com>
 <NWz6JgOyftpmZlIKMiHz7IXthK8WuJBvFbsZO1CIqEA=.834360bc-73b3-4e3f-a6d3-1a77e3531775@github.com>
Message-ID: <22Tl6LJ4zIsFi4CGkEX-xHz80lFe-nYPHbh5Fx_Hkfk=.bcfd0c0e-f01c-4455-be4a-dbc065351dd8@github.com>

On Mon, 24 Apr 2023 16:27:28 GMT, ExE Boss <duke at openjdk.org> wrote:

> Note?that other?`*Impl`?classes in?`java.lang.constant` perform?validation in?their?constructors and?provide?custom `toString()`?formatting and?they?also don?t?use?records.

Records were only added in Java 16; the constant API was added in 12, so this is not a reason not to use records. But performing validation in constructors is better than in factory methods, to avoid code paths that potentially create invalid instances.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13615#issuecomment-1520491520

From darcy at openjdk.org  Mon Apr 24 16:42:59 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 24 Apr 2023 16:42:59 GMT
Subject: RFR: JDK-8304423: Refactor FdLibm.java
In-Reply-To: <42w6bIexUmgF22V7k2HUk8vb6R6en82laV6_AFJ5_10=.0af0236e-6260-4f9f-8bc7-4ba86fcf1ca9@github.com>
References: <kkt3zVVtkAFIH4Joz82Xq8d5dhDX9VeA1p9sxNlS4XI=.7090fbc8-e059-47c0-9c12-65e56da9fc22@github.com>
 <42w6bIexUmgF22V7k2HUk8vb6R6en82laV6_AFJ5_10=.0af0236e-6260-4f9f-8bc7-4ba86fcf1ca9@github.com>
Message-ID: <th4C51hMA7MgGhEMg9ulPfyYuAjGdmrzebanLa1T_rE=.6537dab0-84be-4195-a426-357d3e58244e@github.com>

On Mon, 24 Apr 2023 12:00:58 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Minor refactoring of FdLibm.java; will consider future refactorings with more substantive code changes in the future.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 76:
> 
>> 74:     private static final int SIGN_BIT        = 0x8000_0000;
>> 75:     private static final int EXP_BITS        = 0x7ff0_0000;
>> 76:     private static final int EXP_SIGNIF_BITS = 0x7fff_ffff;
> 
> These could be expressed in terms of the constants in `Double`. But perhaps it's not worth doing so, after all, as the reader is assumed to be quite knowledgeable.
> 
> Otherwise LGTM.

Yes, I had considered expressing these FDLIBM-internal constants in terms of constants from Double or the JDK-internal class DoubleConsts, where they could be more directly expressible based on 64-bit versions of the values. However, I thought having the constants be more directly assigned in this context would be fine.

If these assignments were to be amended, something like adding a static initializer block with asserts might be okay along the lines of

assert  SIGN_BIT == (int)(DoubleConsts.SIGN_BIT_MASK >>> 32) &&
    EXP_BITS == (int)(DoubleConsts.EXP_BIT_MASK >>> 32) ... ;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13604#discussion_r1175542650

From vromero at openjdk.org  Mon Apr 24 16:43:08 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 24 Apr 2023 16:43:08 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v6]
In-Reply-To: <nBwyluZ1PKhz3xTB2LSndQjF0DjuojItWQpaHhh1JIM=.57620d8a-1fbf-4505-9157-1ca2fcae2cb9@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <nBwyluZ1PKhz3xTB2LSndQjF0DjuojItWQpaHhh1JIM=.57620d8a-1fbf-4505-9157-1ca2fcae2cb9@github.com>
Message-ID: <eMU5jc2YYLZ4silqQMUhdKSH26dVzAxszfEngXrVqTY=.360ccc4d-e2f3-434e-9dae-e7daa405c14e@github.com>

On Mon, 24 Apr 2023 15:16:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review changes.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 220:

> 218:      * <p>
> 219:      * The value of the {@code restart} index must be between {@code 0} and
> 220:      * the length of the {@code labels} array, of an {@link IndexOutOfBoundsException}

same as above

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1175542100

From vromero at openjdk.org  Mon Apr 24 18:09:02 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 24 Apr 2023 18:09:02 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v6]
In-Reply-To: <nBwyluZ1PKhz3xTB2LSndQjF0DjuojItWQpaHhh1JIM=.57620d8a-1fbf-4505-9157-1ca2fcae2cb9@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <nBwyluZ1PKhz3xTB2LSndQjF0DjuojItWQpaHhh1JIM=.57620d8a-1fbf-4505-9157-1ca2fcae2cb9@github.com>
Message-ID: <IWfB1IA6wQJWwPq-1GPDLRUtlUEKal3aRIybCMr0fuk=.d28f2b7d-5069-4c64-82d3-bb870e794a8e@github.com>

On Mon, 24 Apr 2023 15:16:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review changes.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 3212:

> 3210:         @Override
> 3211:         public void visitCase(JCCase tree) {
> 3212:             super.visitCase(tree); // Generated from nbfs://nbhost/SystemFileSystem/Templates/Classes/Code/OverriddenMethodBody

do we need this comment?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 862:

> 860: 
> 861:     private LoadableConstant createEnumDesc(DiagnosticPosition pos, ClassSymbol enumClass, Name constant) {
> 862:         //ConstantBootstrap.invoke(..., EnumDesc.of(ConstantBootstrap.invoke(..., ClassDesc.of(enumClass)), constant))

I think this comment can be removed or probably reformatted

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1175611723
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1175615234

From vromero at openjdk.org  Mon Apr 24 18:14:40 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 24 Apr 2023 18:14:40 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v6]
In-Reply-To: <nBwyluZ1PKhz3xTB2LSndQjF0DjuojItWQpaHhh1JIM=.57620d8a-1fbf-4505-9157-1ca2fcae2cb9@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <nBwyluZ1PKhz3xTB2LSndQjF0DjuojItWQpaHhh1JIM=.57620d8a-1fbf-4505-9157-1ca2fcae2cb9@github.com>
Message-ID: <Y7qeBmTUpcLsP63YWdX0GFad23TTP9buNqxQyhNMMms=.25b87d9b-a91c-4741-b9df-c627d537cac8@github.com>

On Mon, 24 Apr 2023 15:16:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review changes.

I don't have any more comments. Great job!

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13074#pullrequestreview-1398560976

From shade at openjdk.org  Mon Apr 24 19:02:59 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 24 Apr 2023 19:02:59 GMT
Subject: RFR: 8306773: Problemlist
 jdk/incubator/vector/ShortMaxVectorTests.java on x86_32
Message-ID: <4F0VKLa0AcqKPygKp9-w6L90xBbHwAO66o5AvyaM468=.9a1d86c9-40a9-4c56-b03d-3a6bab1d7665@github.com>

There is a product bug, see the parent bug. Problemlisting to get cleaner GHA runs. 

Additional testing: 
 - [ ] GHA

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/13623/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13623&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306773
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13623.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13623/head:pull/13623

PR: https://git.openjdk.org/jdk/pull/13623

From dcubed at openjdk.org  Mon Apr 24 19:40:08 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 24 Apr 2023 19:40:08 GMT
Subject: Integrated: 8306780: ProblemList
 java/lang/Thread/virtual/HoldsLock.java#id0 in Xcomp
Message-ID: <w7zBW0O_benVxRxZDLPrhatOrtiNj2j7A5-MdRhbWfk=.9917ff4f-02a5-4545-a5a8-ea3903ef13bf@github.com>

A trivial fix to ProblemList java/lang/Thread/virtual/HoldsLock.java#id0 in Xcomp.

-------------

Commit messages:
 - 8306780: ProblemList java/lang/Thread/virtual/HoldsLock.java#id0 in Xcomp

Changes: https://git.openjdk.org/jdk/pull/13627/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13627&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306780
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13627/head:pull/13627

PR: https://git.openjdk.org/jdk/pull/13627

From darcy at openjdk.org  Mon Apr 24 19:40:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 24 Apr 2023 19:40:09 GMT
Subject: Integrated: 8306780: ProblemList
 java/lang/Thread/virtual/HoldsLock.java#id0 in Xcomp
In-Reply-To: <w7zBW0O_benVxRxZDLPrhatOrtiNj2j7A5-MdRhbWfk=.9917ff4f-02a5-4545-a5a8-ea3903ef13bf@github.com>
References: <w7zBW0O_benVxRxZDLPrhatOrtiNj2j7A5-MdRhbWfk=.9917ff4f-02a5-4545-a5a8-ea3903ef13bf@github.com>
Message-ID: <-Tyhz1370lr_9XIGZImNVHJxOCxnS8ogPqSgQLxhA00=.aadef357-1881-4332-b2e6-658ac813a30e@github.com>

On Mon, 24 Apr 2023 19:28:41 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/Thread/virtual/HoldsLock.java#id0 in Xcomp.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13627#pullrequestreview-1398673003

From dcubed at openjdk.org  Mon Apr 24 19:40:10 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 24 Apr 2023 19:40:10 GMT
Subject: Integrated: 8306780: ProblemList
 java/lang/Thread/virtual/HoldsLock.java#id0 in Xcomp
In-Reply-To: <-Tyhz1370lr_9XIGZImNVHJxOCxnS8ogPqSgQLxhA00=.aadef357-1881-4332-b2e6-658ac813a30e@github.com>
References: <w7zBW0O_benVxRxZDLPrhatOrtiNj2j7A5-MdRhbWfk=.9917ff4f-02a5-4545-a5a8-ea3903ef13bf@github.com>
 <-Tyhz1370lr_9XIGZImNVHJxOCxnS8ogPqSgQLxhA00=.aadef357-1881-4332-b2e6-658ac813a30e@github.com>
Message-ID: <3hjOrdbMbGNo6yIh0o6Ps1hKhp-9Kj1sJXQefygGUpg=.111febff-d8f8-45b6-a095-3b3a7945b41e@github.com>

On Mon, 24 Apr 2023 19:34:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A trivial fix to ProblemList java/lang/Thread/virtual/HoldsLock.java#id0 in Xcomp.
>
> Marked as reviewed by darcy (Reviewer).

@jddarcy - Thanks for the fast review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13627#issuecomment-1520719825

From dcubed at openjdk.org  Mon Apr 24 19:40:12 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 24 Apr 2023 19:40:12 GMT
Subject: Integrated: 8306780: ProblemList
 java/lang/Thread/virtual/HoldsLock.java#id0 in Xcomp
In-Reply-To: <w7zBW0O_benVxRxZDLPrhatOrtiNj2j7A5-MdRhbWfk=.9917ff4f-02a5-4545-a5a8-ea3903ef13bf@github.com>
References: <w7zBW0O_benVxRxZDLPrhatOrtiNj2j7A5-MdRhbWfk=.9917ff4f-02a5-4545-a5a8-ea3903ef13bf@github.com>
Message-ID: <OwMm5QQs_EA-TuwExyuJJrmxoUqSxquii4maeroGPmM=.3711f9da-0c08-4fd9-8d39-6378ca11e787@github.com>

On Mon, 24 Apr 2023 19:28:41 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/Thread/virtual/HoldsLock.java#id0 in Xcomp.

This pull request has now been integrated.

Changeset: 328e512d
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/328e512d12f6fd1d37cf1778ba68fa7b8ff1b8e3
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8306780: ProblemList java/lang/Thread/virtual/HoldsLock.java#id0 in Xcomp

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/13627

From rriggs at openjdk.org  Mon Apr 24 19:46:32 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 24 Apr 2023 19:46:32 GMT
Subject: RFR: 8306678: Replace use of os.version with an internal Version
 record
In-Reply-To: <jM3npCGY4o0vlKaB4MZ515wb9FWgR5pd24J4snqnkwA=.6dabb690-a5d0-48a5-8f26-7032c702e2ef@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
 <jM3npCGY4o0vlKaB4MZ515wb9FWgR5pd24J4snqnkwA=.6dabb690-a5d0-48a5-8f26-7032c702e2ef@github.com>
Message-ID: <V_rHNhE47lV6TqiVwu0yZoKkyD8MKgs9JGhJ5_hrkDE=.ba0f34d4-ddc0-4e82-b3b8-87e237dc8665@github.com>

On Fri, 21 Apr 2023 17:02:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Create an internal Version record to hold and compare versions of the form (major, minor, micro).
>> Add `OperatingSystem.version()` to return the version of the running OS.
>> Replace uses of os.version in java.base.
>> Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.
>
> src/java.base/macosx/classes/jdk/internal/loader/ClassLoaderHelper.java line 39:
> 
>> 37:         // SDK 10.15 and earlier always reports 10.16 instead of 11.x.x
>> 38:         hasDynamicLoaderCache = OperatingSystem.version()
>> 39:                 .compareTo(new Version(10, 16)) >= 0;
> 
> I wonder if this check can be removed too as 10.11 is the oldest macOS release that seems to be getting updates.

10.15 supported as of JDK 20; will keep the check until that changes.

> src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java line 103:
> 
>> 101:                 // fgetxattr broken on APFS prior to 10.14
>> 102:                 return OperatingSystem.version()
>> 103:                         .compareTo(new Version(10, 14)) >= 0;
> 
> I don't think 10.14 had had an update since 2021 so I suspect you can just remove this check.

Will be removed in PR https://github.com/openjdk/jdk/pull/13628

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1175712165
PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1175710973

From rriggs at openjdk.org  Mon Apr 24 19:46:34 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 24 Apr 2023 19:46:34 GMT
Subject: RFR: 8306678: Replace use of os.version with an internal Version
 record
In-Reply-To: <nB6JI_xtOrZy8yLkt6FknYlwLdldjqdAwaBC3Aropis=.d9525798-a0f4-4fac-a051-b2d6ed332e61@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
 <nB6JI_xtOrZy8yLkt6FknYlwLdldjqdAwaBC3Aropis=.d9525798-a0f4-4fac-a051-b2d6ed332e61@github.com>
Message-ID: <zoYlaJjnjy5BEmjzfCmW5BdMIRmBWme-16OIB5s78j0=.f81aaf1f-912b-49ae-ae68-6d5f9c3b2d85@github.com>

On Sat, 22 Apr 2023 09:21:09 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Create an internal Version record to hold and compare versions of the form (major, minor, micro).
>> Add `OperatingSystem.version()` to return the version of the running OS.
>> Replace uses of os.version in java.base.
>> Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.
>
> src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java line 103:
> 
>> 101:                 // fgetxattr broken on APFS prior to 10.14
>> 102:                 return OperatingSystem.version()
>> 103:                         .compareTo(new Version(10, 14)) >= 0;
> 
> The `Version(10,?14)` record should?probably be?stored in?a?static?constant.

Will be removed as it is no longer needed; see PR https://github.com/openjdk/jdk/pull/13628

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1175713240

From rriggs at openjdk.org  Mon Apr 24 19:56:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 24 Apr 2023 19:56:19 GMT
Subject: RFR: 8306678: Replace use of os.version with an internal Version
 record [v2]
In-Reply-To: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
Message-ID: <Dk3aCJgVOgb3gtCs_CjI4n3CII30ishIcINjFdCpOAQ=.85548965-3f6c-48ed-900c-a94700aaa660@github.com>

> Create an internal Version record to hold and compare versions of the form (major, minor, micro).
> Add `OperatingSystem.version()` to return the version of the running OS.
> Replace uses of os.version in java.base.
> Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.

Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:

 - Revert changes to MacOsX sun.nio.fs.BsdFileStore; the version check is being removed in another PR.
 - Review comment updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13584/files
  - new: https://git.openjdk.org/jdk/pull/13584/files/93d5663e..01bc9cbf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13584&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13584&range=00-01

  Stats: 43 lines in 3 files changed: 16 ins; 10 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/13584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13584/head:pull/13584

PR: https://git.openjdk.org/jdk/pull/13584

From kvn at openjdk.org  Mon Apr 24 19:58:10 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 24 Apr 2023 19:58:10 GMT
Subject: RFR: 8306773: Problemlist
 jdk/incubator/vector/ShortMaxVectorTests.java on x86_32
In-Reply-To: <4F0VKLa0AcqKPygKp9-w6L90xBbHwAO66o5AvyaM468=.9a1d86c9-40a9-4c56-b03d-3a6bab1d7665@github.com>
References: <4F0VKLa0AcqKPygKp9-w6L90xBbHwAO66o5AvyaM468=.9a1d86c9-40a9-4c56-b03d-3a6bab1d7665@github.com>
Message-ID: <wlK4qc41cVy-No8FcoiZxn0z2hQRQcpOXutUUHaYZq0=.b5de0dcf-55ff-4d5f-adc2-7e4ed0dbdf72@github.com>

On Mon, 24 Apr 2023 18:26:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There is a product bug, see the parent bug. Problemlisting to get cleaner GHA runs. 
> 
> Additional testing: 
>  - [ ] GHA

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13623#pullrequestreview-1398700578

From duke at openjdk.org  Mon Apr 24 20:43:15 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 24 Apr 2023 20:43:15 GMT
Subject: RFR: 8306678: Replace use of os.version with an internal Version
 record [v2]
In-Reply-To: <Dk3aCJgVOgb3gtCs_CjI4n3CII30ishIcINjFdCpOAQ=.85548965-3f6c-48ed-900c-a94700aaa660@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
 <Dk3aCJgVOgb3gtCs_CjI4n3CII30ishIcINjFdCpOAQ=.85548965-3f6c-48ed-900c-a94700aaa660@github.com>
Message-ID: <VFoMqUgUgR3a12l3JI8rgtljWFrapIURJ0N5lhs2KUk=.4368ed89-3234-44f2-85dd-5e2245f06501@github.com>

On Mon, 24 Apr 2023 19:56:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Create an internal Version record to hold and compare versions of the form (major, minor, micro).
>> Add `OperatingSystem.version()` to return the version of the running OS.
>> Replace uses of os.version in java.base.
>> Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.
>
> Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert changes to MacOsX sun.nio.fs.BsdFileStore; the version check is being removed in another PR.
>  - Review comment updates

Syntax?errors:

test/jdk/jdk/internal/util/VersionTest.java line 89:

> 87:                 Arguments.of(new Version(3, 3, 1), new Version(3, 3, 1), 0),
> 88:                 Arguments.of(new Version(3, 3, 1), new Version(3, 3, 0), +1),
> 89:                 Arguments.of(new Version(3, 3, 0), new Version(3, 3, 1), -1)

Missing?comma:
Suggestion:

                Arguments.of(new Version(3, 3, 0), new Version(3, 3, 1), -1),

test/jdk/jdk/internal/util/VersionTest.java line 90:

> 88:                 Arguments.of(new Version(3, 3, 1), new Version(3, 3, 0), +1),
> 89:                 Arguments.of(new Version(3, 3, 0), new Version(3, 3, 1), -1)
> 90:                 Arguments.of(new Version(2, 1), new Version(2, 1), 0),

This?line is?the?same as?line?84.

test/jdk/jdk/internal/util/VersionTest.java line 92:

> 90:                 Arguments.of(new Version(2, 1), new Version(2, 1), 0),
> 91:                 Arguments.of(new Version(2, 0), new Version(3, 0), -1),
> 92:                 Arguments.of(new Version(3, 0), new Version(2, 0), +1),

**Java** doesn?t?(currently)?allow trailing?commas in?method?parameters:
Suggestion:

                Arguments.of(new Version(3, 0), new Version(2, 0), +1)

-------------

PR Review: https://git.openjdk.org/jdk/pull/13584#pullrequestreview-1398759614
PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1175760505
PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1175759513
PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1175761011

From duke at openjdk.org  Mon Apr 24 20:49:11 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 24 Apr 2023 20:49:11 GMT
Subject: RFR: 8306678: Replace use of os.version with an internal Version
 record [v2]
In-Reply-To: <V_rHNhE47lV6TqiVwu0yZoKkyD8MKgs9JGhJ5_hrkDE=.ba0f34d4-ddc0-4e82-b3b8-87e237dc8665@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
 <jM3npCGY4o0vlKaB4MZ515wb9FWgR5pd24J4snqnkwA=.6dabb690-a5d0-48a5-8f26-7032c702e2ef@github.com>
 <V_rHNhE47lV6TqiVwu0yZoKkyD8MKgs9JGhJ5_hrkDE=.ba0f34d4-ddc0-4e82-b3b8-87e237dc8665@github.com>
Message-ID: <1YYyoK1Wt9gDGo9rySa-Gny1P13XvraBHNnAVeHhsVw=.ce8b17ce-ee65-45d2-ab14-b71847504ba2@github.com>

On Mon, 24 Apr 2023 19:43:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/macosx/classes/jdk/internal/loader/ClassLoaderHelper.java line 39:
>> 
>>> 37:         // SDK 10.15 and earlier always reports 10.16 instead of 11.x.x
>>> 38:         hasDynamicLoaderCache = OperatingSystem.version()
>>> 39:                 .compareTo(new Version(10, 16)) >= 0;
>> 
>> I wonder if this check can be removed too as 10.11 is the oldest macOS release that seems to be getting updates.
>
> 10.15 supported as of JDK 20; will keep the check until that changes.

This?assignment could?probably be?moved into?a?static field?initializer, as?it?s?now a?simple?expression:

    // SDK 10.15 and earlier always reports 10.16 instead of 11.x.x
    private static final boolean hasDynamicLoaderCache
            = OperatingSystem.version().compareTo(new Version(10, 16)) >= 0;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13584#discussion_r1175765486

From mchung at openjdk.org  Mon Apr 24 20:56:09 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 24 Apr 2023 20:56:09 GMT
Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v6]
In-Reply-To: <Bt8Vdqd0Yg1N5Km4zR_zIGv-zoIoBC_4ABjka_NQnXk=.7cf915ba-6519-4abe-beea-891ca3c3eac0@github.com>
References: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
 <Bt8Vdqd0Yg1N5Km4zR_zIGv-zoIoBC_4ABjka_NQnXk=.7cf915ba-6519-4abe-beea-891ca3c3eac0@github.com>
Message-ID: <gmGMbfJskFcWTZXvKxIVvc1T0jW_5ILY0BgXeDYxhsc=.b507e152-4cf9-44cc-af95-0bb656a2fd6d@github.com>

On Mon, 24 Apr 2023 15:31:53 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
>> - #11272
>> 
>> Changes:
>> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc`
>> - [x] Use shared `CommandLine.java` in `jdk.compiler` module
>> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
>> - [x] Remove `CommandLine.java` from `jdk.compiler` module
>
> Christian Stein has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Fix hard-coded test
>  - Clean up configuration
>  - Update test
>  - Fix generation of API documentation
>  - Add more export directives

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12997#pullrequestreview-1398777346

From cjplummer at openjdk.org  Mon Apr 24 21:00:13 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 24 Apr 2023 21:00:13 GMT
Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when
 using an OutputAnalyzer at the same time
In-Reply-To: <jbN1idusRU1wUiQ265HUUCyjb2eh8uSC4MDn5igYyy8=.ae64e31f-8c57-415e-8a21-ca7f0e8a6410@github.com>
References: <jbN1idusRU1wUiQ265HUUCyjb2eh8uSC4MDn5igYyy8=.ae64e31f-8c57-415e-8a21-ca7f0e8a6410@github.com>
Message-ID: <PyDuFEDy8NeRDHkG0FdJ6GAstIVcj4gePhhq_FkoLOg=.8144f5cb-6fda-4e2d-ac1e-b20d3110e91d@github.com>

On Fri, 21 Apr 2023 21:43:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams.
> 
> This fix preserve process streams content and allow to read reuse the date. The ByteArrayOutputStream is used as a buffer. 
> It stores all process output, never trying to clean date which has been read. 
> 
> The regression test has been provided with issue.
> 
> I closed previous PR https://github.com/openjdk/jdk/pull/13560 by mistake instead of updating it.
> 
> I run all tests to ensure that no failures are introduced.

Marked as reviewed by cjplummer (Reviewer).

test/lib/jdk/test/lib/process/ProcessTools.java line 249:

> 247:         stdout.addOutputStream(out.getOutputStream());
> 248:         stderr.addOutputStream(err.getOutputStream());
> 249: 

Overall this looks good, although I'm a bit unclear on how some of the underpinnings work, allowing the output to appear in these output streams, and also in the LineForwarder output (above), and for that matter, in the lineConsumer output (below). I guess there is some multiplexing of the output that I just don't grasp, but appears to be something that already worked.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13594#pullrequestreview-1398781718
PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1175775335

From jlu at openjdk.org  Mon Apr 24 21:09:04 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 24 Apr 2023 21:09:04 GMT
Subject: RFR: 8305853: java/text/Format/DateFormat/DateFormatRegression.java
 fails with "Uncaught exception thrown in test method Test4089106"
Message-ID: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>

This PR fixes an intermittent failure (that only occurs on Windows) in _DateFormatRegression.java_.

With the integration of [JDK-8304982](https://bugs.openjdk.org/browse/JDK-8304982), _LocaleProviderAdapter.java_ now emits a compat warning when the class is loaded. This warning calls `ZonedDateTime.now()` during formatting. This call depends on the `TimeZone.ID` of the TimeZone returned from `TimeZone.getDefault()`.

On Windows, the test class which DateFormatRegression extends will run the tests at random, (as opposed to running in the same order every time). When Test4089106() happens to be the first test ran, the static block of LocaleProviderAdapter will be executed with `TimeZone.setDefault()` set to a `SimpleTimeZone` with `id` as _FAKEZONE_. When LocaleProviderAdapter formats the compat warning ... and many calls later calls `ZoneRulesProvider getProvider(String zoneId)` with `zoneId` as _FAKEZONE_ the test fails with _java.time.zone.ZoneRulesException: Unknown time-zone ID: FAKEZONE_.

In order to still test that `SimpleDateFormat.getTimeZone()` defaults to `TimeZone.getDefault()` we can create a `SimpleTimeZone` with a custom id rather than an invalid id. This way ZoneRulesProvider will not fail on the ID, but the `SimpleTimeZone` being tested is still not a "default" `TimeZone`.

-------------

Commit messages:
 - Header and copyright year
 - Switch invalid id for custom id

Changes: https://git.openjdk.org/jdk/pull/13630/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13630&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305853
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13630.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13630/head:pull/13630

PR: https://git.openjdk.org/jdk/pull/13630

From smarks at openjdk.org  Mon Apr 24 21:35:32 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 24 Apr 2023 21:35:32 GMT
Subject: RFR: 8266571: Sequenced Collections [v11]
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: <nrAJPifN0qVcTqM__yZLGvbVKlMHo7JoAP76wT7Hs4s=.be5f3495-488c-4ee7-a701-14cacfa24188@github.com>

> PR for Sequenced Collections implementation.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Optimizations for ReverseOrderListView; check indexes in reversed domain.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7387/files
  - new: https://git.openjdk.org/jdk/pull/7387/files/dc23a48f..1a155cf5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=09-10

  Stats: 42 lines in 1 file changed: 26 ins; 2 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/7387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/7387/head:pull/7387

PR: https://git.openjdk.org/jdk/pull/7387

From smarks at openjdk.org  Mon Apr 24 21:39:43 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 24 Apr 2023 21:39:43 GMT
Subject: RFR: 8266571: Sequenced Collections [v12]
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: <BkwnYQwsK_lnfHEmAIVU4X0fkubfXd4IDL8OxJHClEQ=.6af19d63-c8a1-492c-960d-cb5735eaedcf@github.com>

> 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

-------------

Changes: https://git.openjdk.org/jdk/pull/7387/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=11
  Stats: 7067 lines in 42 files changed: 6921 ins; 11 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/7387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/7387/head:pull/7387

PR: https://git.openjdk.org/jdk/pull/7387

From liach at openjdk.org  Mon Apr 24 21:54:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Apr 2023 21:54:09 GMT
Subject: RFR: 8304918: Remove unused decl field from AnnotatedType
 implementations
In-Reply-To: <mthfNvWJWPmqLJjer7JidU-QYe9XwdcwJZDVW-5jSUo=.5056d0c3-72b3-4eae-a12c-d3af31f4e706@github.com>
References: <mthfNvWJWPmqLJjer7JidU-QYe9XwdcwJZDVW-5jSUo=.5056d0c3-72b3-4eae-a12c-d3af31f4e706@github.com>
Message-ID: <4MWtI7oTP3sWiIRhhi-VJJEZeOMjRDTsY2zzycCGRoA=.5ed757ad-6e16-458b-95cf-63b27f514ba4@github.com>

On Sat, 25 Mar 2023 05:52:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> In `AnnotatedTypeBaseImpl`, a `decl` field is declared, referring to the declaration that the AnnotatedType is from. However, this field is not used anywhere except passing to constructors of other implementations; it's not used in debug messages (unlike in `TypeAnnotation`), not involved in equality checks. Since these implementations are not serializable, we can safely remove the decl field from the implementations. All 1048 java/lang tests pass on my machine.

keep-alive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13183#issuecomment-1520877585

From smarks at openjdk.org  Mon Apr 24 21:56:08 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 24 Apr 2023 21:56:08 GMT
Subject: RFR: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
References: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
Message-ID: <9D1oWzePdISnLLVyFTbV-reDLyYounUA-9I6J0wyrH4=.7887e3a7-bb6c-4192-86d9-523529a0e3f7@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

The `size()` call is rather odd, as it's mainly about the implementation and is not considered part of the actual value of the BitSet. I note that `equals()` is specified not to include the size.  BitSet is a very old API, dating back to 1.0, so perhaps it was felt that implementation-level information would be important to users, or perhaps the notion of keeping implementation details out of the APIs hadn't been fully developed yet. (There are other 1.0-era APIs that have similar characteristics.) Note that the specs do say that the size can change with the implementation, so there's some flexibility here. That said, it's not clear to me how a user of BitSet can actually use `size()` effectively.

A comprehensive fix to the BitSet implementation and specs should probably address the proper return value of `size()`, but I think it can considered somewhat independently of other methods, which have thorny semantic issues regarding what happens at MAX_VALUE.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1520878988

From naoto at openjdk.org  Mon Apr 24 22:42:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Apr 2023 22:42:09 GMT
Subject: RFR: 8305853:
 java/text/Format/DateFormat/DateFormatRegression.java fails with
 "Uncaught exception thrown in test method Test4089106"
In-Reply-To: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>
References: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>
Message-ID: <zhKsTLyory5poVlCullZZgR89PlHJ12kMVDadPNgzVo=.a90ef28a-976a-401e-9061-49d04d1b3865@github.com>

On Mon, 24 Apr 2023 21:02:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes an intermittent failure (that only occurs on Windows) in _DateFormatRegression.java_.
> 
> With the integration of [JDK-8304982](https://bugs.openjdk.org/browse/JDK-8304982), _LocaleProviderAdapter.java_ now emits a compat warning when the class is loaded. This warning calls `ZonedDateTime.now()` during formatting. This call depends on the `TimeZone.ID` of the TimeZone returned from `TimeZone.getDefault()`.
> 
> On Windows, the test class which DateFormatRegression extends will run the tests at random, (as opposed to running in the same order every time). When Test4089106() happens to be the first test ran, the static block of LocaleProviderAdapter will be executed with `TimeZone.setDefault()` set to a `SimpleTimeZone` with `id` as _FAKEZONE_. When LocaleProviderAdapter formats the compat warning ... and many calls later calls `ZoneRulesProvider getProvider(String zoneId)` with `zoneId` as _FAKEZONE_ the test fails with _java.time.zone.ZoneRulesException: Unknown time-zone ID: FAKEZONE_.
> 
> In order to still test that `SimpleDateFormat.getTimeZone()` defaults to `TimeZone.getDefault()` we can create a `SimpleTimeZone` with a custom id rather than an invalid id. This way ZoneRulesProvider will not fail on the ID, but the `SimpleTimeZone` being tested is still not a "default" `TimeZone`.

Great to see this intermittent issue solved, Justin! A minor suggestion:

test/jdk/java/text/Format/DateFormat/DateFormatRegression.java line 360:

> 358:         TimeZone def = TimeZone.getDefault();
> 359:         try {
> 360:             TimeZone z = new SimpleTimeZone((int)(8.25 * 3600000), "GMT-08:15");

If we want a custom zone, simply `TimeZone.getTimeZone("GMT-08:15")` will do.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13630#pullrequestreview-1398894333
PR Review Comment: https://git.openjdk.org/jdk/pull/13630#discussion_r1175839321

From jlu at openjdk.org  Mon Apr 24 23:47:05 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 24 Apr 2023 23:47:05 GMT
Subject: RFR: 8305853:
 java/text/Format/DateFormat/DateFormatRegression.java fails with
 "Uncaught exception thrown in test method Test4089106" [v2]
In-Reply-To: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>
References: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>
Message-ID: <F_-vhIbxDmBc5NSTonXAP23GQc_Z4SJS7yzDXKfG2cE=.1b2618bf-d7d4-41ec-a401-834600939919@github.com>

> This PR fixes an intermittent failure (that only occurs on Windows) in _DateFormatRegression.java_.
> 
> With the integration of [JDK-8304982](https://bugs.openjdk.org/browse/JDK-8304982), _LocaleProviderAdapter.java_ now emits a compat warning when the class is loaded. This warning calls `ZonedDateTime.now()` during formatting. This call depends on the `TimeZone.ID` of the TimeZone returned from `TimeZone.getDefault()`.
> 
> On Windows, the test class which DateFormatRegression extends will run the tests at random, (as opposed to running in the same order every time). When Test4089106() happens to be the first test ran, the static block of LocaleProviderAdapter will be executed with `TimeZone.setDefault()` set to a `SimpleTimeZone` with `id` as _FAKEZONE_. When LocaleProviderAdapter formats the compat warning ... and many calls later calls `ZoneRulesProvider getProvider(String zoneId)` with `zoneId` as _FAKEZONE_ the test fails with _java.time.zone.ZoneRulesException: Unknown time-zone ID: FAKEZONE_.
> 
> In order to still test that `SimpleDateFormat.getTimeZone()` defaults to `TimeZone.getDefault()` we can create a `SimpleTimeZone` with a custom id rather than an invalid id. This way ZoneRulesProvider will not fail on the ID, but the `SimpleTimeZone` being tested is still not a "default" `TimeZone`.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Minor cleanup / alternate custom tz

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13630/files
  - new: https://git.openjdk.org/jdk/pull/13630/files/348f9691..19973c31

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13630&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13630&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13630.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13630/head:pull/13630

PR: https://git.openjdk.org/jdk/pull/13630

From smarks at openjdk.org  Tue Apr 25 00:10:32 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 25 Apr 2023 00:10:32 GMT
Subject: RFR: 8266571: Sequenced Collections [v10]
In-Reply-To: <8GjzQjfHUceverRHKnB9oXNb5kPfWYai-Va6pc4DjM0=.fff2f752-d47d-4991-9e68-e100f8909f36@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <oxK5LFwLX41vHM85KD_y1RzXqWrXjvKJmYRvUPAdlIk=.b03dc360-e7e3-41dd-ba65-27a45a2470b8@github.com>
 <8GjzQjfHUceverRHKnB9oXNb5kPfWYai-Va6pc4DjM0=.fff2f752-d47d-4991-9e68-e100f8909f36@github.com>
Message-ID: <cKBbFOtCzF7opiMsnaFW8-hevoMd-Ll0n4kh2Ji9u2g=.8e78bb2e-8dcf-4e88-91a0-db2eb7e7068e@github.com>

On Sat, 22 Apr 2023 09:33:57 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Wording tweaks to SequencedMap / NavigableMap.
>>  - Change "The implementation in this class" to "... interface."
>
> src/java.base/share/classes/java/util/SortedMap.java line 113:
> 
>> 111:  */
>> 112: 
>> 113: public interface SortedMap<K,V> extends SequencedMap<K,V> {
> 
> This?interface can?now?provide default?implementations for?the?`firstKey` and?`lastKey`?methods:
> 
> default K firstKey() {
> 	var entry = this.firstEntry();
> 	if (entry == null) {
> 		throw new NoSuchElementException();
> 	}
> 	return entry.getKey();
> }
> 
> 
> default K lastKey() {
> 	var entry = this.lastEntry();
> 	if (entry == null) {
> 		throw new NoSuchElementException();
> 	}
> 	return entry.getKey();
> }

Doesn't seem all that useful.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1175895948

From liach at openjdk.org  Tue Apr 25 00:34:17 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Apr 2023 00:34:17 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v15]
In-Reply-To: <P9kNQFArFfWOL24nIRvlBsSIZHCSMM_ILLRIuRVuxis=.59bcff96-7a7b-4789-8e1f-426d731642fe@github.com>
References: <rqqi61cKbJ8TjDVSzsjh6BVXjF1ZxL2ZFHheuXzL5E8=.bd1f1a2c-6f35-4180-a0a5-8a6e3cb93e75@github.com>
 <P9kNQFArFfWOL24nIRvlBsSIZHCSMM_ILLRIuRVuxis=.59bcff96-7a7b-4789-8e1f-426d731642fe@github.com>
Message-ID: <o3jQjpx22SIVLSfD3AeHMqN3pVDmq2ZVkv9QLHqeMUA=.da82167d-bf8c-4443-a4c4-886a40971d0a@github.com>

On Mon, 27 Mar 2023 16:43:17 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   StackMapGenerator performance improvements

Keep-alive.

I believe the changes to cache ClassDesc symbol in ClassEntry and avoid re-computing hash in Utf8Entry can be in a separate patch delivered before the current migration patch.

For the StackMapGenerator changes, I don't agree with replacing `TOP_TYPE` with `null`: currently, top type is `0, null, 0`, which can be the default null instance after valhalla drops (so filling array will no longer be required at that point). Using `null` makes the code less readable and maintainable as well.

I also question the design to move away from `MethodTypeDesc`: `ofDescriptor` is expensive, but we can check the slots of a method type with a `MethodTypeDesc` easily than tokenizing and skipping the raw descriptor string, like 

var slots = type.parameterCount()
for (var param : type.parameterList()) // when parameterList is optimized
    if (param.isPrimitive() && (param.descriptorString.charAt(0) == 'D' || param.descriptorString.charAt(0) == 'J')) slots++;


Same for processing invoke instructions: if we can reuse the `MethodTypeDesc` at `invokeInstruction` call sites, we don't need an ad-hoc type computation either.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10991#issuecomment-1520993443

From smarks at openjdk.org  Tue Apr 25 00:40:42 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 25 Apr 2023 00:40:42 GMT
Subject: RFR: 8266571: Sequenced Collections [v12]
In-Reply-To: <bjHr9kQ6PfiSzt5IqgFWisQqzk_Jiawi5jGCDOKgeXI=.44293975-edcb-42de-99dd-9b7590b86914@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <bjHr9kQ6PfiSzt5IqgFWisQqzk_Jiawi5jGCDOKgeXI=.44293975-edcb-42de-99dd-9b7590b86914@github.com>
Message-ID: <unhXQXPixAmJ0svFTXBR6vfokWUjt9jUXH-sxo25P8c=.fa6570f7-d6a6-4614-a1c0-d57747484b1f@github.com>

On Fri, 24 Mar 2023 22:06:06 GMT, Tagir F. Valeev <tvaleev 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
>
> src/java.base/share/classes/java/util/ReverseOrderListView.java line 168:
> 
>> 166:         boolean modified = false;
>> 167:         for (E e : c) {
>> 168:             base.add(0, e);
> 
> This is worrysome from performance point of view for base implementations like ArrayList where every insertion means shifting the whole array. At least, we could optimize if `c` is `SequencedCollection`, like `if (c instanceof SequencedCollection<? extends E> sc) base.addAll(0, sc.reversed())`. Otherwise, we can use `base.addAll(0, Arrays.asList(sc.toArray()).reversed())` (with a couple of unchecked casts).

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1175897522

From smarks at openjdk.org  Tue Apr 25 00:40:42 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 25 Apr 2023 00:40:42 GMT
Subject: RFR: 8266571: Sequenced Collections [v8]
In-Reply-To: <E658tsKckNP8NZN3GI__AEd7P8SjsBjgT1O-e0cTJww=.bc09e708-f6f0-408f-a007-7b2a17fcc9ba@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <xhWK9e-orFi_yRPH1xyUWf2ye5tP1BrysvQrLhqCLbY=.c316918e-793f-4bdc-bee6-c5267efa6c5c@github.com>
 <OKv7JIh0Sw-bk4Xf1Wixv_pgSA-JKjF9SqLRYp_OMRw=.036864e8-3e65-45ef-9714-e3e0f3e0b133@github.com>
 <IFL795ayUetxrztQ79-ahEgJXZbejb_irs7T8UaFDBM=.c8e16b19-6452-4f04-a303-023a30471b43@github.com>
 <E658tsKckNP8NZN3GI__AEd7P8SjsBjgT1O-e0cTJww=.bc09e708-f6f0-408f-a007-7b2a17fcc9ba@github.com>
Message-ID: <0G8lkhuNNQZQ9fWO2fiKwvubuhZPMqQH0vMDVuaT6Ug=.edc5562a-82f7-4dcc-b29f-c91a797e4455@github.com>

On Sat, 22 Apr 2023 07:56:03 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Might not work if this map is concurrent. If isEmpty() returns false but then the map is emptied before the subsequent calls, next() might throw NSEE. The concurrent maps' iterators make sure to cache the element if hasNext() has returned true.
>
> Then shouldn't `ConcurrentNavigableMap`, the only `ConcurrentMap` and `SequencedMap` supertype (there is no `ConcurrentSortedMap`), override its superinterface implementation with this thread-safe one?
> 
> I think that the question boils down to: should `SequencedMap` take into account the needs of its subtypes and give a conservative default implementation, or should it give a "minimal" implementation and let the subtypes override it according to their needs? I would choose the latter, both because `SequencedMap` specifies no guarantees on thread-safety (atomicity and synchronization), and because `Map`'s default implementation behave this way  - `compute`, `merge`... tell concurrent implementations how to override them.
> 
> Now if someone implements a `SequencedMap` that is also a `ConcurrentMap`, but is not a `NavigableMap`, say `ConcurrentLinkedHashMap`, they will override the `SequencedMap` defaults like they would the `Map` defaults.

If somebody is implementing a concurrent or thread-safe SequencedMap, they might look at the spec of the default method and determine that it's safe to inherit the default implementation (if, as I mentioned above, the map's Iterator has the right properties). Changing the default implementation to test isEmpty() first _requires_ overriding in to be thread-safe, introducing the possibility of a new kind of error. I don't see any utility in changing this default implementation or adding an overriding default implementation to another one of the interfaces.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1175907436

From smarks at openjdk.org  Tue Apr 25 00:49:30 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 25 Apr 2023 00:49:30 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <oif1FBVUUm08F5dgaDmHP5kNfP7e9-0SAH127RsZPPI=.fdb213e7-06fc-4e8a-b5ed-e815605f1a7a@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 <YkNylSy1A-OrfuTOhg_vCZrb3mDinwnTZ45kGUbtPIY=.2962cb0d-f8da-4a92-adaa-8f3fbd59ab41@github.com>
 <BngK9GlaKcznbBFge3XNucAWrzWs_qSK_1zuSNy__Y8=.e7f3a783-a983-4e29-9c03-9b2ee8a08f43@github.com>
 <oif1FBVUUm08F5dgaDmHP5kNfP7e9-0SAH127RsZPPI=.fdb213e7-06fc-4e8a-b5ed-e815605f1a7a@github.com>
Message-ID: <bdFpxe4ABCzb8KoFqWCzjTZzPwoQE4uK0Kr8Hc28Rq0=.e13c3984-0e63-4d0e-9927-4ff763c444a1@github.com>

On Thu, 30 Mar 2023 09:56:58 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> @liach 
>> 
>> I understand that you're suggesting adding various default implementations in order to make it easier for people to bring up implementations of SequencedCollections. However, adding default implementations to SequencedCollection itself is unlikely to help. I expect that most implementations will override both addFirst and addLast. Requiring overriding of only one of them will hardly help anything, because the more difficult task is implementing the reverse-ordered view. I'd prefer to concentrate on some kind of implementation assistance for doing that. For example, there could be an "AbstractSequencedCollection" that would require overriding only a couple methods, rather like `AbstractCollection`. I'm a bit reluctant to introduce new abstract classes into the public API though. An alternative might be to have some kind of static factory method that takes something like a Collection and a reverse iterator and returns a SequencedCollection.
>> 
>> It's not clear to me that such support is necessary. It's pretty easy to bring up a List using AbstractList, and a List is a SequencedCollection. But if we do add something, it should be driven by use cases, and not speculation.
>
> @stuart-marks 
> 
>> Thanks for looking! I took a quick look through the comments and they seem reasonable. Right now I'm concentrating on the specification in order to get the CSR Finalized. Do you have any comments on the specifications? I'll take a look at the implementation comments afterward. Some I'll be able to address before integration, but some I might need to postpone until later.
> 
> The specification is mostly well-written, thanks! I've added a few comments on the spec and few more comments on the implementation. Please check.

@amaembo Thanks for your excellent comments. I've believe I've either responded to or addressed all of the issues you've raised, with the exception of the issues regarding spliterators. The current spliterators are in a fairly poor state, but I'd prefer to postpone that work until after this main PR has been integrated. I've filed a bug to track this work: [JDK-8306785](https://bugs.openjdk.org/browse/JDK-8306785).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1521008864

From smarks at openjdk.org  Tue Apr 25 00:49:34 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 25 Apr 2023 00:49:34 GMT
Subject: RFR: 8266571: Sequenced Collections [v12]
In-Reply-To: <bjHr9kQ6PfiSzt5IqgFWisQqzk_Jiawi5jGCDOKgeXI=.44293975-edcb-42de-99dd-9b7590b86914@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <bjHr9kQ6PfiSzt5IqgFWisQqzk_Jiawi5jGCDOKgeXI=.44293975-edcb-42de-99dd-9b7590b86914@github.com>
Message-ID: <MO_RaK4pc8ko7ggF12Bldsk7OXu14sYh9gBqwbQmkKg=.8b9ee0da-a46b-4c92-8922-dd38d3fc5f05@github.com>

On Fri, 24 Mar 2023 22:08:18 GMT, Tagir F. Valeev <tvaleev 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
>
> src/java.base/share/classes/java/util/ReverseOrderListView.java line 316:
> 
>> 314:     public void add(int index, E element) {
>> 315:         checkModifiable();
>> 316:         base.add(base.size() - index, element);
> 
> Note that if index is out of bounds, the original collection may throw a confusing exception, as `base.size() - index` will be reported instead. Probably adding explicit bounds checking call before delegation would be better. Same applies to other index-based operations.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1175910606

From lmesnik at openjdk.org  Tue Apr 25 01:46:06 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 25 Apr 2023 01:46:06 GMT
Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when
 using an OutputAnalyzer at the same time
In-Reply-To: <PyDuFEDy8NeRDHkG0FdJ6GAstIVcj4gePhhq_FkoLOg=.8144f5cb-6fda-4e2d-ac1e-b20d3110e91d@github.com>
References: <jbN1idusRU1wUiQ265HUUCyjb2eh8uSC4MDn5igYyy8=.ae64e31f-8c57-415e-8a21-ca7f0e8a6410@github.com>
 <PyDuFEDy8NeRDHkG0FdJ6GAstIVcj4gePhhq_FkoLOg=.8144f5cb-6fda-4e2d-ac1e-b20d3110e91d@github.com>
Message-ID: <30GUv37oCfNRntrXrUJHeG8tJ1km_2QkB2lptFzNz_s=.b342898f-ecce-4f41-9869-01bf3e97d29c@github.com>

On Mon, 24 Apr 2023 20:57:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams.
>> 
>> This fix preserve process streams content and allow to read reuse the date. The ByteArrayOutputStream is used as a buffer. 
>> It stores all process output, never trying to clean date which has been read. 
>> 
>> The regression test has been provided with issue.
>> 
>> I closed previous PR https://github.com/openjdk/jdk/pull/13560 by mistake instead of updating it.
>> 
>> I run all tests to ensure that no failures are introduced.
>
> test/lib/jdk/test/lib/process/ProcessTools.java line 249:
> 
>> 247:         stdout.addOutputStream(out.getOutputStream());
>> 248:         stderr.addOutputStream(err.getOutputStream());
>> 249: 
> 
> Overall this looks good, although I'm a bit unclear on how some of the underpinnings work, allowing the output to appear in these output streams, and also in the LineForwarder output (above), and for that matter, in the lineConsumer output (below). I guess there is some multiplexing of the output that I just don't grasp, but appears to be something that already worked.

StreamPumper read process stdout, stderr streams and write read data to registered streams. So it works as multiplexer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1175930914

From bpb at openjdk.org  Tue Apr 25 01:50:23 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 25 Apr 2023 01:50:23 GMT
Subject: RFR: 8306623: (bf) CharBuffer::allocate throws unexpected exception
 type with some CharSequences
Message-ID: <0sphqHKN84N9VUm-rrBwPyDROgxB5rRJbMfb1fTZhlE=.1b9511a2-bc58-4b6a-a0be-d3e5732db941@github.com>

When appending a `CharBuffer`, perform a specific check for buffer overflow before invoking `put()`.

-------------

Commit messages:
 - 8306623: (bf) CharBuffer::allocate throws unexpected exception type with some CharSequences

Changes: https://git.openjdk.org/jdk/pull/13632/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13632&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306623
  Stats: 65 lines in 2 files changed: 39 ins; 0 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/13632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13632/head:pull/13632

PR: https://git.openjdk.org/jdk/pull/13632

From bpb at openjdk.org  Tue Apr 25 01:50:24 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 25 Apr 2023 01:50:24 GMT
Subject: RFR: 8306623: (bf) CharBuffer::allocate throws unexpected
 exception type with some CharSequences
In-Reply-To: <0sphqHKN84N9VUm-rrBwPyDROgxB5rRJbMfb1fTZhlE=.1b9511a2-bc58-4b6a-a0be-d3e5732db941@github.com>
References: <0sphqHKN84N9VUm-rrBwPyDROgxB5rRJbMfb1fTZhlE=.1b9511a2-bc58-4b6a-a0be-d3e5732db941@github.com>
Message-ID: <trN_B5Sy6TnVhBI3_i_rA7IUfZQC5og-mEFYwTv9bII=.6c24b466-2b5f-4764-ba67-f33a97582a9e@github.com>

On Tue, 25 Apr 2023 01:44:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> When appending a `CharBuffer`, perform a specific check for buffer overflow before invoking `put()`.

I'm not entirely comfortable with where I've put the test in this patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13632#issuecomment-1521039628

From sspitsyn at openjdk.org  Tue Apr 25 03:09:08 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 25 Apr 2023 03:09:08 GMT
Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when
 using an OutputAnalyzer at the same time
In-Reply-To: <jbN1idusRU1wUiQ265HUUCyjb2eh8uSC4MDn5igYyy8=.ae64e31f-8c57-415e-8a21-ca7f0e8a6410@github.com>
References: <jbN1idusRU1wUiQ265HUUCyjb2eh8uSC4MDn5igYyy8=.ae64e31f-8c57-415e-8a21-ca7f0e8a6410@github.com>
Message-ID: <4EDhpXuaKhviIcVGoDrPbVzcdze_pl4rJZu6DQvWeAw=.f5a9a485-3bb2-4f2b-8b65-e3d35eae1001@github.com>

On Fri, 21 Apr 2023 21:43:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams.
> 
> This fix preserve process streams content and allow to read reuse the date. The ByteArrayOutputStream is used as a buffer. 
> It stores all process output, never trying to clean date which has been read. 
> 
> The regression test has been provided with issue.
> 
> I closed previous PR https://github.com/openjdk/jdk/pull/13560 by mistake instead of updating it.
> 
> I run all tests to ensure that no failures are introduced.

test/lib/jdk/test/lib/process/ProcessTools.java line 792:

> 790:         @Override
> 791:         public InputStream getInputStream() {
> 792:             return out;

This is a little bit confusing that the `getInputStream()` returns `out` stream.
Just wanted to double-check if it is intentional and was not needed for `getOutputStream()` instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1175965035

From cstein at openjdk.org  Tue Apr 25 03:59:12 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 25 Apr 2023 03:59:12 GMT
Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v7]
In-Reply-To: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
References: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
Message-ID: <DLJU_jcQYGb6vofeWcJU4ysBKl2M8rMxBUvtt2GKJnk=.6e200ff1-a624-42a0-8292-9ec112323e66@github.com>

> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
> - #11272
> 
> Changes:
> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc`
> - [x] Use shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year
  [skip ci]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12997/files
  - new: https://git.openjdk.org/jdk/pull/12997/files/26d14f82..0cc3d377

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=05-06

  Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12997/head:pull/12997

PR: https://git.openjdk.org/jdk/pull/12997

From lmesnik at openjdk.org  Tue Apr 25 04:08:06 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 25 Apr 2023 04:08:06 GMT
Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when
 using an OutputAnalyzer at the same time
In-Reply-To: <4EDhpXuaKhviIcVGoDrPbVzcdze_pl4rJZu6DQvWeAw=.f5a9a485-3bb2-4f2b-8b65-e3d35eae1001@github.com>
References: <jbN1idusRU1wUiQ265HUUCyjb2eh8uSC4MDn5igYyy8=.ae64e31f-8c57-415e-8a21-ca7f0e8a6410@github.com>
 <4EDhpXuaKhviIcVGoDrPbVzcdze_pl4rJZu6DQvWeAw=.f5a9a485-3bb2-4f2b-8b65-e3d35eae1001@github.com>
Message-ID: <OjLsgMRUFYZUmjzdta-q2Zj-rKGmKfPB2WqnWjYiuHk=.aabde9bc-d5d2-43cf-9d67-8c7dec5c682a@github.com>

On Tue, 25 Apr 2023 03:06:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams.
>> 
>> This fix preserve process streams content and allow to read reuse the date. The ByteArrayOutputStream is used as a buffer. 
>> It stores all process output, never trying to clean date which has been read. 
>> 
>> The regression test has been provided with issue.
>> 
>> I closed previous PR https://github.com/openjdk/jdk/pull/13560 by mistake instead of updating it.
>> 
>> I run all tests to ensure that no failures are introduced.
>
> test/lib/jdk/test/lib/process/ProcessTools.java line 792:
> 
>> 790:         @Override
>> 791:         public InputStream getInputStream() {
>> 792:             return out;
> 
> This is a little bit confusing that the `getInputStream()` returns `out` stream.
> Just wanted to double-check if it is intentional and was not needed for `getOutputStream()` instead.

Agree, it is confusing, even in standard j.l.Process API . The `InputStream java.lang.Process.getInputStream()`" returns **output** stream of started process.  So for our implementation ProcessImpl the 'out' and 'err' mean output and error streams. However they are returned as InputStreams so users could read them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1175985058

From cstein at openjdk.org  Tue Apr 25 04:20:19 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 25 Apr 2023 04:20:19 GMT
Subject: Integrated: JDK-8304036: Use CommandLine class from shared module
In-Reply-To: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
References: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>
Message-ID: <xXju1pHFwsTHCpq0VptoC4v9QcFQoIrEoNCYOa1WANk=.6dee4d54-2bd2-4a45-9c05-0cf832d711ba@github.com>

On Mon, 13 Mar 2023 08:16:54 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
> - #11272
> 
> Changes:
> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc`
> - [x] Use shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module

This pull request has now been integrated.

Changeset: 24719190
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2471919020169aac4499ef40ed37eabd98c90da7
Stats:     345 lines in 14 files changed: 29 ins; 297 del; 19 mod

8304036: Use CommandLine class from shared module

Reviewed-by: jjg, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/12997

From ysatowse at openjdk.org  Tue Apr 25 05:23:12 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Tue, 25 Apr 2023 05:23:12 GMT
Subject: RFR: 8305505: NPE in javazic compiler
Message-ID: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>

Please review this PR.  
With this minor change, the javazic compiler (Main.java) can produce the HTML files that display given time zone data correctly.

-------------

Commit messages:
 - Remove trailing spaces
 - Fix a mistake in the change
 - 8305505: NPE in javazic compiler

Changes: https://git.openjdk.org/jdk/pull/13504/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13504&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305505
  Stats: 24 lines in 1 file changed: 9 ins; 6 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13504.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13504/head:pull/13504

PR: https://git.openjdk.org/jdk/pull/13504

From naoto at openjdk.org  Tue Apr 25 05:23:14 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Apr 2023 05:23:14 GMT
Subject: RFR: 8305505: NPE in javazic compiler
In-Reply-To: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
References: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
Message-ID: <CLqtl6RXgMh5UqXS-uQ-eY7e-jKQJKizjCfTjju17ik=.b5c8357b-a79b-491a-80ae-96b39a8eb2a2@github.com>

On Tue, 18 Apr 2023 05:08:35 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  
> With this minor change, the javazic compiler (Main.java) can produce the HTML files that display given time zone data correctly.

test/jdk/sun/util/calendar/zi/GenDoc.java line 159:

> 157:             if (mapList == null) {
> 158:                 mapList = new HashMap<String, LatitudeAndLongitude>();
> 159:                 if (Main.getMapFile() != null) {

You could retain the map file and use it in the following line

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13504#discussion_r1170502826

From ysatowse at openjdk.org  Tue Apr 25 05:23:15 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Tue, 25 Apr 2023 05:23:15 GMT
Subject: RFR: 8305505: NPE in javazic compiler
In-Reply-To: <CLqtl6RXgMh5UqXS-uQ-eY7e-jKQJKizjCfTjju17ik=.b5c8357b-a79b-491a-80ae-96b39a8eb2a2@github.com>
References: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
 <CLqtl6RXgMh5UqXS-uQ-eY7e-jKQJKizjCfTjju17ik=.b5c8357b-a79b-491a-80ae-96b39a8eb2a2@github.com>
Message-ID: <Xn2Nb3OY6fKWAPzItvw9bZT7JCJeQd6lv73QaayaVwk=.475db648-b0cd-4370-a701-74fa4d2242f5@github.com>

On Tue, 18 Apr 2023 19:50:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR.  
>> With this minor change, the javazic compiler (Main.java) can produce the HTML files that display given time zone data correctly.
>
> test/jdk/sun/util/calendar/zi/GenDoc.java line 159:
> 
>> 157:             if (mapList == null) {
>> 158:                 mapList = new HashMap<String, LatitudeAndLongitude>();
>> 159:                 if (Main.getMapFile() != null) {
> 
> You could retain the map file and use it in the following line

Correct.  Thanks for the catch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13504#discussion_r1170668064

From shade at openjdk.org  Tue Apr 25 05:59:07 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Apr 2023 05:59:07 GMT
Subject: RFR: 8306773: Problemlist
 jdk/incubator/vector/ShortMaxVectorTests.java on x86_32
In-Reply-To: <4F0VKLa0AcqKPygKp9-w6L90xBbHwAO66o5AvyaM468=.9a1d86c9-40a9-4c56-b03d-3a6bab1d7665@github.com>
References: <4F0VKLa0AcqKPygKp9-w6L90xBbHwAO66o5AvyaM468=.9a1d86c9-40a9-4c56-b03d-3a6bab1d7665@github.com>
Message-ID: <sezD6ZP0S3XJsHein8AffqXjU19_6Kkc8p_RW6SDBIQ=.76fa16ee-4409-4e1c-a4cd-bc55d9475bfa@github.com>

On Mon, 24 Apr 2023 18:26:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There is a product bug, see the parent bug. Problemlisting to get cleaner GHA runs. 
> 
> Additional testing: 
>  - [x] GHA

Thanks! I am integrating to get cleaner GHA runs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13623#issuecomment-1521191411

From shade at openjdk.org  Tue Apr 25 06:02:21 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Apr 2023 06:02:21 GMT
Subject: Integrated: 8306773: Problemlist
 jdk/incubator/vector/ShortMaxVectorTests.java on x86_32
In-Reply-To: <4F0VKLa0AcqKPygKp9-w6L90xBbHwAO66o5AvyaM468=.9a1d86c9-40a9-4c56-b03d-3a6bab1d7665@github.com>
References: <4F0VKLa0AcqKPygKp9-w6L90xBbHwAO66o5AvyaM468=.9a1d86c9-40a9-4c56-b03d-3a6bab1d7665@github.com>
Message-ID: <739mtQOKeUkvgDEYS8OqJH6j1gGlxtBxz_Q-3F_zz6s=.2a555937-f302-4eb8-b1aa-b3a26e08a4b1@github.com>

On Mon, 24 Apr 2023 18:26:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There is a product bug, see the parent bug. Problemlisting to get cleaner GHA runs. 
> 
> Additional testing: 
>  - [x] GHA

This pull request has now been integrated.

Changeset: 2985738f
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2985738f1584735fee34bbe706014f43ec369bdd
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8306773: Problemlist jdk/incubator/vector/ShortMaxVectorTests.java on x86_32

Reviewed-by: kvn

-------------

PR: https://git.openjdk.org/jdk/pull/13623

From alanb at openjdk.org  Tue Apr 25 06:30:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Apr 2023 06:30:10 GMT
Subject: RFR: 8306623: (bf) CharBuffer::allocate throws unexpected
 exception type with some CharSequences
In-Reply-To: <0sphqHKN84N9VUm-rrBwPyDROgxB5rRJbMfb1fTZhlE=.1b9511a2-bc58-4b6a-a0be-d3e5732db941@github.com>
References: <0sphqHKN84N9VUm-rrBwPyDROgxB5rRJbMfb1fTZhlE=.1b9511a2-bc58-4b6a-a0be-d3e5732db941@github.com>
Message-ID: <nO9TB7oiGaBXNtJUk_tDK4xM6My2gpB6G2ibV9F9EDk=.1b397e11-ce61-47fc-94a9-5aedfdd8431e@github.com>

On Tue, 25 Apr 2023 01:44:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> When appending a `CharBuffer`, perform a specific check for buffer overflow before invoking `put()`.

Can you add a test to test/jdk/java/nio/Buffer/Basic-X.java.template, I think this regression was missed because this tests didn't check this case.

src/java.base/share/classes/java/nio/X-Buffer.java.template line 2050:

> 2048:             //
> 2049:             // pre-emptively check for overflow as put(int,CharBuffer,int,int)
> 2050:             // would throw IndexOutOfBoundsException instead

The comment is confusing, I think you just want to say that the append method throws BufferOverflowException when there is insufficient space in the buffer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13632#issuecomment-1521217228
PR Review Comment: https://git.openjdk.org/jdk/pull/13632#discussion_r1176057894

From duke at openjdk.org  Tue Apr 25 06:36:20 2023
From: duke at openjdk.org (duke)
Date: Tue, 25 Apr 2023 06:36:20 GMT
Subject: Withdrawn: 8301042: Need methods to check null elements in an array or
 a collection
In-Reply-To: <epNUkMH0qh0P8-TGgqvCeg_FzJ23mHTeLQoH-BrNh0U=.c35f37fb-26ba-455c-b72b-1d0ba2cd920a@github.com>
References: <epNUkMH0qh0P8-TGgqvCeg_FzJ23mHTeLQoH-BrNh0U=.c35f37fb-26ba-455c-b72b-1d0ba2cd920a@github.com>
Message-ID: <ErSSM-YM5Rvs93aLwWEq3f8KZXiK1-abbhNswPm-l1M=.b975338c-20ef-4d13-906d-9f74791be6ed@github.com>

On Sat, 28 Jan 2023 23:58:28 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> Adding the following methods to check the nullity of elements of an array or a collection:
> 
> 
> java.util.Arrays:
> public static <E> E[] requireNoNulls(E[] array)
> public static <E> E[] requireNoNulls(E[] array, String message)
> public static <E> E[] requireNoNulls(E[] array, IntFunction<String> messageGenerator)
> public static <E> E[] requireNoNullsElseReplace(E[] array, IntFunction<? extends E> replaceFunction)
> public static <E> E[] requireNoNullsCopied(E[] array)
> public static <E> E[] requireNoNullsCopied(E[] array, IntFunction<String> messageGenerator)
> public static <E> E[] requireNoNullsCopied(E[] array, String message)
> public static <E> E[] requireNoNullsCopiedElseReplace(E[] array, IntFunction<? extends E> replaceFunction)
> 
> java.util.Collections:
> public static <C extends Iterable<?>> C requireNoNulls(C collection)
> public static <M extends Map<?, ?>> M requireNoNulls(M map)
> public static <C extends Iterable<?>> C requireNoNulls(C collection, String message)
> public static <M extends Map<?, ?>> M requireNoNulls(M map, String message)
> public static <C extends Iterable<?>> C requireNoNulls(C collection, Supplier<String> messageSupplier)
> public static <M extends Map<?, ?>> M requireNoNulls(M map, Supplier<String> messageSupplier)
> public static <L extends List<?>> L requireNoNulls(L list, IntFunction<String> messageGenerator)
> public static <E, L extends List<? super E>> L requireNoNullsElseReplace(L list, IntFunction<? extends E> replaceFunction)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12276

From asotona at openjdk.org  Tue Apr 25 07:41:09 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 07:41:09 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v3]
In-Reply-To: <22Tl6LJ4zIsFi4CGkEX-xHz80lFe-nYPHbh5Fx_Hkfk=.bcfd0c0e-f01c-4455-be4a-dbc065351dd8@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <k2_HG58fJQHb9Aif2oMk8lu3e0cpVafN-M8RXVkxABU=.6dde0370-7e25-4b2f-95d7-39121651c883@github.com>
 <NWz6JgOyftpmZlIKMiHz7IXthK8WuJBvFbsZO1CIqEA=.834360bc-73b3-4e3f-a6d3-1a77e3531775@github.com>
 <22Tl6LJ4zIsFi4CGkEX-xHz80lFe-nYPHbh5Fx_Hkfk=.bcfd0c0e-f01c-4455-be4a-dbc065351dd8@github.com>
Message-ID: <_Hquvo7Tc56k0UgICDRR4WNszNaCjoU4DbrAb5bbHD8=.fd2e32c1-18af-4cb1-b691-2c9df4ec8383@github.com>

On Mon, 24 Apr 2023 16:33:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> Note?that other?`*Impl`?classes in?`java.lang.constant` perform?validation in?their?constructors and?provide?custom `toString()`?formatting and?they?also don?t?use?records.

Performing validation in constructors I see as a blocker for potential performance optimisations from trusted code within the `java.lang.constant` package.

Custom `toString()` is a good point, returning for example `ModuleDescImpl[moduleName=mymodule]` is not ideal.
I'll fix it, thanks.

Records are very well designed exactly for this purpose and I'm not aware of any reason to don't use them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13615#issuecomment-1521300799

From asotona at openjdk.org  Tue Apr 25 07:55:09 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 07:55:09 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v3]
In-Reply-To: <_Hquvo7Tc56k0UgICDRR4WNszNaCjoU4DbrAb5bbHD8=.fd2e32c1-18af-4cb1-b691-2c9df4ec8383@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <k2_HG58fJQHb9Aif2oMk8lu3e0cpVafN-M8RXVkxABU=.6dde0370-7e25-4b2f-95d7-39121651c883@github.com>
 <NWz6JgOyftpmZlIKMiHz7IXthK8WuJBvFbsZO1CIqEA=.834360bc-73b3-4e3f-a6d3-1a77e3531775@github.com>
 <22Tl6LJ4zIsFi4CGkEX-xHz80lFe-nYPHbh5Fx_Hkfk=.bcfd0c0e-f01c-4455-be4a-dbc065351dd8@github.com>
 <_Hquvo7Tc56k0UgICDRR4WNszNaCjoU4DbrAb5bbHD8=.fd2e32c1-18af-4cb1-b691-2c9df4ec8383@github.com>
Message-ID: <1apvdkfiTi0RbFBY3LZa2433qzPpcLeKjCulOFleEy0=.e662d533-6a59-44b7-83ba-b76f3713b41e@github.com>

On Tue, 25 Apr 2023 07:38:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Note?that other?`*Impl`?classes in?`java.lang.constant` perform?validation in?their?constructors and?provide?custom `toString()`?formatting and?they?also don?t?use?records.

BTW: for example `ClassDesc:of(String name)` performs repeated validations and I see it as a performance bug.
`ClassDesc::of` calls `ConstantUtils::validateBinaryClassName`, then it performs conversion `binaryToInternal` and calls `ClassDesc::ofDescriptor`, which checks for `ConstantUtils::arrayDepth` and calls `ReferenceClassDescImpl::new`, which again performns validation by calling `ConstantUtils::skipOverFieldSignature` and checking the result. There is plenty of space for performance improvements here, as all the validation and conversion can be done in one pass only.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13615#issuecomment-1521326927

From asotona at openjdk.org  Tue Apr 25 08:11:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 08:11:24 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v4]
In-Reply-To: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
Message-ID: <6nCaEpvTmyPMkeBa472jKe7HWLS7RgmthxBphJp_0bg=.3838cd75-fd44-48e8-9309-694a39c20704@github.com>

> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
> 
> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
> 
> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
> 
> Please review this pull request and attached CSR.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  added custom toString() methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13615/files
  - new: https://git.openjdk.org/jdk/pull/13615/files/47aa52d1..7c45b343

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=02-03

  Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13615/head:pull/13615

PR: https://git.openjdk.org/jdk/pull/13615

From stsypanov at openjdk.org  Tue Apr 25 08:13:07 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 25 Apr 2023 08:13:07 GMT
Subject: RFR: 8304918: Remove unused decl field from AnnotatedType
 implementations
In-Reply-To: <mthfNvWJWPmqLJjer7JidU-QYe9XwdcwJZDVW-5jSUo=.5056d0c3-72b3-4eae-a12c-d3af31f4e706@github.com>
References: <mthfNvWJWPmqLJjer7JidU-QYe9XwdcwJZDVW-5jSUo=.5056d0c3-72b3-4eae-a12c-d3af31f4e706@github.com>
Message-ID: <GzIw6imLhHvVnyGaHtF-hbRGrzXutEhtB4Wq9IJPO1A=.2cb2ba37-af7e-4971-8b8d-0401efd72d92@github.com>

On Sat, 25 Mar 2023 05:52:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> In `AnnotatedTypeBaseImpl`, a `decl` field is declared, referring to the declaration that the AnnotatedType is from. However, this field is not used anywhere except passing to constructors of other implementations; it's not used in debug messages (unlike in `TypeAnnotation`), not involved in equality checks. Since these implementations are not serializable, we can safely remove the decl field from the implementations. All 1048 java/lang tests pass on my machine.

I wonder why no one is interested in this? Looks useful as lot's of Java frameworks are annotation-based

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13183#issuecomment-1521355623

From asotona at openjdk.org  Tue Apr 25 08:39:27 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 08:39:27 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v15]
In-Reply-To: <P9kNQFArFfWOL24nIRvlBsSIZHCSMM_ILLRIuRVuxis=.59bcff96-7a7b-4789-8e1f-426d731642fe@github.com>
References: <rqqi61cKbJ8TjDVSzsjh6BVXjF1ZxL2ZFHheuXzL5E8=.bd1f1a2c-6f35-4180-a0a5-8a6e3cb93e75@github.com>
 <P9kNQFArFfWOL24nIRvlBsSIZHCSMM_ILLRIuRVuxis=.59bcff96-7a7b-4789-8e1f-426d731642fe@github.com>
Message-ID: <iRuzUSHqiaBOpUWZMXRNQY6G3FEdj1kBn25Qho9HWc4=.6ab3c330-b002-495d-986f-f3fdbd9867a8@github.com>

On Mon, 27 Mar 2023 16:43:17 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   StackMapGenerator performance improvements

I agree, setting this PR back to draft.
This pull request have to take into account all actual and planned improvements in Constants API.
And then it should isolate performance improvements of Classfile API into a separate pull request.
And then it should be proposed back for review with benchmarks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10991#issuecomment-1521396913

From asotona at openjdk.org  Tue Apr 25 09:17:10 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 09:17:10 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v3]
In-Reply-To: <17g0Sr-olv2KDrNF4ZSHOtzmxiRDOPi6QYfazhyyBBs=.51559233-5e1f-4199-8082-e936a3031f6b@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <NDZsJbnOay2IPYbjJ-E_asohiAS8eJpqd0mHbh1EmsE=.7d30affe-510c-476e-8def-042ced74b017@github.com>
 <VkimOrcXslKpl6DeJGdC16MCpM7H-5lCJBZH3tDcS5c=.22ec33d2-285d-4c0c-bd8d-aacbe86405a5@github.com>
 <17g0Sr-olv2KDrNF4ZSHOtzmxiRDOPi6QYfazhyyBBs=.51559233-5e1f-4199-8082-e936a3031f6b@github.com>
Message-ID: <d0NVSLgw-2ejgy2xaFBgOBtOUx_DO8FMzUnmex0DQno=.d409e669-4548-4201-bee2-e6b4bc8745f4@github.com>

On Thu, 20 Apr 2023 08:24:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 86:
>> 
>>> 84:     }
>>> 85: 
>>> 86:     public void setMajorVersion(int majorVersion) {
>> 
>> We should ensure the version is not changed once writing has already happened, and the constant pool builder should have access to the major version as well to prevent writing of invalid entries (like condy before java 11)
>
> The class version is set into the BufWriterImpl at the last stage and user cannot affect it later.
> 
> For the invalid entries I would like to see a use case where it may happen unintentionally. Otherwise the Classfile API is not a spec-enforcing library. The library should guide to create valid classfile with minimal effort (using defaults), however it should also allow to construct whatever classfile, if it is user intention.

the version field is now final

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13478#discussion_r1176237298

From prappo at openjdk.org  Tue Apr 25 09:22:34 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 25 Apr 2023 09:22:34 GMT
Subject: RFR: 8266571: Sequenced Collections [v7]
In-Reply-To: <tJYdeImTNTe2ryron_GRIkQcZXlUvBwwUmdS0o5CwqA=.e44fab85-502a-499d-a314-4e0572cc4d23@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <MvxKICoqQ9V1cwF0TD7J5397I8AElqaqHNqv4_yeKRQ=.2c6c97e0-192d-4fb7-9f13-d6bcfeaf4e45@github.com>
 <UQFv9mQcYOEgU_FMhks5VpQ5n52_eKtQ-SkVFWIJxfA=.f210d862-89a9-4da8-be7b-41edfa06fb39@github.com>
 <gFEW30ltuY4EnrgaKyeIKV3tCqUEhO7RjxoAbRx2Fg8=.dc998f69-9f51-4fde-a96c-514a38226ce8@github.com>
 <3H2vsVn6_RvIXnR2Y_02RScaLHS9LLuGkWMFqLMwYsE=.8a56e190-3777-4060-ac6c-dd2834cb035d@github.com>
 <XRv7PT9QdKJYYkNdzEbHmTAl317iVYZm2VUH7-fIqJk=.e5c5efb8-22fb-405c-893c-19d2641adc72@github.com>
 <tJYdeImTNTe2ryron_GRIkQcZXlUvBwwUmdS0o5CwqA=.e44fab85-502a-499d-a314-4e0572cc4d23@github.com>
Message-ID: <uMzVOq7g-ta9Et6KQRVCUbYm3qaIbe8Ysee__Y7NMIQ=.562dfebc-3693-44a4-b6a1-ad5d6b545977@github.com>

On Thu, 20 Apr 2023 16:19:05 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>>> I didn't know about the need to specify `@throws` in order to generate the throws-clauses in the docs. 
>> 
>> You need to explicitly inherit `@throws` only for exceptions that aren't mentioned in the `throws` clause.
>> 
>>> As an aside, I note that some methods such as ArrayList.addFirst/addLast had this javadoc:
>>> 
>>> ```
>>> /**
>>>  * @inheritDoc
>>>  */
>>> ```
>>> 
>>> It didn't appear at all in the javadoc output, I guess because of `--override-methods=summary`.
>> 
>> Correct: it shouldn't have appeared in "Method Details" because of that option. But if it didn't appear at all (i.e. not even in the "Method Summary / Methods declared in ..." table at the top of the page), it's a bug.
>> 
>>> Is there a way to inherit the doc from a superclass but force a particular method to have its details included? It's kind of moot because these are also missing a `@since` tag, and adding that did cause the method detail to be included.
>> 
>> Other than to add to the inherited documentation? Not that I know of. Yes, adding a `@since` tag will cause the method detail to appear.
>
> Oh, oops, I was mistaken to say "It didn't appear at all in the javadoc output." It did appear in the Method Summary, but not in the Method Details. The behavior is thus as expected. However, it still seems like there's something "off" about this situation. As a javadoc author it's hard to predict what will happen. Maybe more control is necessary. In addition, from the editorial standpoint of the specification, we also need to figure out when something should appear in the Summary and when it should appear in the Detail. Actually we should figure that out first, use it to drive the appropriate mechanisms in the javadoc tool, and then adjust the doc comments themselves as necessary.

I note that other methods might have similar issues. For example, `NullPointerException` in `addFirst` and `addLast`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1176243136

From mcimadamore at openjdk.org  Tue Apr 25 09:44:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 25 Apr 2023 09:44:22 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v6]
In-Reply-To: <nBwyluZ1PKhz3xTB2LSndQjF0DjuojItWQpaHhh1JIM=.57620d8a-1fbf-4505-9157-1ca2fcae2cb9@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <nBwyluZ1PKhz3xTB2LSndQjF0DjuojItWQpaHhh1JIM=.57620d8a-1fbf-4505-9157-1ca2fcae2cb9@github.com>
Message-ID: <9CClgUB47HEkddcnlw7SSKfRHwlS4N-9QosvMgc7c-k=.c07ea842-12fb-4dbb-8ffa-31c163898cde@github.com>

On Mon, 24 Apr 2023 15:16:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review changes.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 219:

> 217:      * the method of the call site return the length of the {@code labels} array.
> 218:      * <p>
> 219:      * The value of the {@code restart} index must be between {@code 0} and

This description is a bit ambiguous - not clear whether it's `0 < x < length`, or `0 <= x < length`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1176269340

From mcimadamore at openjdk.org  Tue Apr 25 10:46:28 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 25 Apr 2023 10:46:28 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v6]
In-Reply-To: <nBwyluZ1PKhz3xTB2LSndQjF0DjuojItWQpaHhh1JIM=.57620d8a-1fbf-4505-9157-1ca2fcae2cb9@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <nBwyluZ1PKhz3xTB2LSndQjF0DjuojItWQpaHhh1JIM=.57620d8a-1fbf-4505-9157-1ca2fcae2cb9@github.com>
Message-ID: <t7ipL3U8fx5Asq4YJqEiu3nsELDLUgkWAtTqneDFM3I=.24527be9-3e31-479d-aa6d-07c4d5d8b7e9@github.com>

On Mon, 24 Apr 2023 15:16:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review changes.

Added some comments in the exhaustiveness test

test/langtools/tools/javac/patterns/Exhaustiveness.java line 1:

> 1: /*

Isn't `Isn't `testCoversType1` the same as `testExhaustiveStatement3` ?

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13074#pullrequestreview-1399606399
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1176314733

From mcimadamore at openjdk.org  Tue Apr 25 10:46:30 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 25 Apr 2023 10:46:30 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v6]
In-Reply-To: <t7ipL3U8fx5Asq4YJqEiu3nsELDLUgkWAtTqneDFM3I=.24527be9-3e31-479d-aa6d-07c4d5d8b7e9@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <nBwyluZ1PKhz3xTB2LSndQjF0DjuojItWQpaHhh1JIM=.57620d8a-1fbf-4505-9157-1ca2fcae2cb9@github.com>
 <t7ipL3U8fx5Asq4YJqEiu3nsELDLUgkWAtTqneDFM3I=.24527be9-3e31-479d-aa6d-07c4d5d8b7e9@github.com>
Message-ID: <W8RpXYcjXhTM_dNqL1nr4jOvhHF9XolN7eOQvBED0mk=.ceb35ba1-027f-486c-955d-dcf9be65f2c8@github.com>

On Tue, 25 Apr 2023 10:22:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review changes.
>
> test/langtools/tools/javac/patterns/Exhaustiveness.java line 1:
> 
>> 1: /*
> 
> Isn't `Isn't `testCoversType1` the same as `testExhaustiveStatement3` ?

Some of the tests called `testExhaustiveStatement` do not seem to test statements at all

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1176315235

From mcimadamore at openjdk.org  Tue Apr 25 10:46:30 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 25 Apr 2023 10:46:30 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v6]
In-Reply-To: <W8RpXYcjXhTM_dNqL1nr4jOvhHF9XolN7eOQvBED0mk=.ceb35ba1-027f-486c-955d-dcf9be65f2c8@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <nBwyluZ1PKhz3xTB2LSndQjF0DjuojItWQpaHhh1JIM=.57620d8a-1fbf-4505-9157-1ca2fcae2cb9@github.com>
 <t7ipL3U8fx5Asq4YJqEiu3nsELDLUgkWAtTqneDFM3I=.24527be9-3e31-479d-aa6d-07c4d5d8b7e9@github.com>
 <W8RpXYcjXhTM_dNqL1nr4jOvhHF9XolN7eOQvBED0mk=.ceb35ba1-027f-486c-955d-dcf9be65f2c8@github.com>
Message-ID: <CmEBbCnpEkfEIw1WCm_MmBbu2sx8vHwOzdjRtBCDbYU=.2725883d-b7a7-4c22-8120-9070926dcc4e@github.com>

On Tue, 25 Apr 2023 10:23:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> test/langtools/tools/javac/patterns/Exhaustiveness.java line 1:
>> 
>>> 1: /*
>> 
>> Isn't `Isn't `testCoversType1` the same as `testExhaustiveStatement3` ?
>
> Some of the tests called `testExhaustiveStatement` do not seem to test statements at all

In the two `testXYZExhaustiveIntersection` the class hierarchy seems the same - can we reuse it across multiple test cases? I see something similar done in `testOnlyApplicable`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1176325272

From mcimadamore at openjdk.org  Tue Apr 25 10:46:30 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 25 Apr 2023 10:46:30 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v6]
In-Reply-To: <CmEBbCnpEkfEIw1WCm_MmBbu2sx8vHwOzdjRtBCDbYU=.2725883d-b7a7-4c22-8120-9070926dcc4e@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <nBwyluZ1PKhz3xTB2LSndQjF0DjuojItWQpaHhh1JIM=.57620d8a-1fbf-4505-9157-1ca2fcae2cb9@github.com>
 <t7ipL3U8fx5Asq4YJqEiu3nsELDLUgkWAtTqneDFM3I=.24527be9-3e31-479d-aa6d-07c4d5d8b7e9@github.com>
 <W8RpXYcjXhTM_dNqL1nr4jOvhHF9XolN7eOQvBED0mk=.ceb35ba1-027f-486c-955d-dcf9be65f2c8@github.com>
 <CmEBbCnpEkfEIw1WCm_MmBbu2sx8vHwOzdjRtBCDbYU=.2725883d-b7a7-4c22-8120-9070926dcc4e@github.com>
Message-ID: <R4qVRpaR7jszHfST4mP2Ia1xqSIkF_nYb8_2uYlR5B0=.db15e491-f645-412b-bcc8-511ade8a8f32@github.com>

On Tue, 25 Apr 2023 10:33:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Some of the tests called `testExhaustiveStatement` do not seem to test statements at all
>
> In the two `testXYZExhaustiveIntersection` the class hierarchy seems the same - can we reuse it across multiple test cases? I see something similar done in `testOnlyApplicable`.

The name `testX` doesn't seem very expressive - maybe `testRecords` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1176326319

From shade at openjdk.org  Tue Apr 25 11:07:16 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Apr 2023 11:07:16 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v11]
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <TFhlk9h75soRUPKtbsu_9OHSwjHo5-TMteBwS7RiNXE=.127fca99-5988-4c6b-b3f2-843231cc5743@github.com>

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - Merge branch 'master' into JDK-83050920-thread-sleep-subms
 - Fix Amazon copyright
 - Merge branch 'master' into JDK-83050920-thread-sleep-subms
 - Drop nanos_to_nanos_bounded
 - Handle overflows
 - More review comments
 - Adjust test times
 - Windows again
 - Windows fixes: align(...) is only for power-of-two alignments
 - Adjust assert
 - ... and 15 more: https://git.openjdk.org/jdk/compare/f968da97...e0a36cf7

-------------

Changes: https://git.openjdk.org/jdk/pull/13225/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=10
  Stats: 254 lines in 11 files changed: 226 ins; 9 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/13225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13225/head:pull/13225

PR: https://git.openjdk.org/jdk/pull/13225

From asotona at openjdk.org  Tue Apr 25 11:12:23 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 11:12:23 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v8]
In-Reply-To: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
Message-ID: <h3ztYPV6ufNlgw_YkGTfXhxQLJg2B33Hxg57gTR618Y=.14ed620a-d31f-4ecc-8f47-2c53b6cd9e99@github.com>

> Classfile API didn't handle transformations of class files version 50 and below correctly. 
> 
> Proposed fix have two parts: 
> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
> 2. StackMapTable attribute is not generated for class file versions below 50.
> 
> StackMapsTest is also extended to test this patch.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  added comments to StackCounter about maxStack upper bounds calculation for JSR/RET instructions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13478/files
  - new: https://git.openjdk.org/jdk/pull/13478/files/c1f3e290..bd46c69c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=06-07

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13478/head:pull/13478

PR: https://git.openjdk.org/jdk/pull/13478

From jlahoda at openjdk.org  Tue Apr 25 11:47:47 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 25 Apr 2023 11:47:47 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v7]
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <beDkmUaoOEREteveHBQlD992NbhcTENFPWVTskmBBiU=.b23cc07b-fa6d-47df-b173-bcced19e1df4@github.com>

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:

 - Merge branch 'master' into JDK-8300543
 - Reflecting review changes.
 - Adding test.
 - Removing redundant continue, as noted on the review.
 - Replacing use of mutable callsite with a mutable state.
 - Reflecting review feedback.
 - Fixing infinite loop in exhaustiveness computation caused by re-adding bindings that are already in the list.
 - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
 - Reflecting review comments.
 - Fixing exhaustiveness for unsealed supertype pattern.
 - ... and 28 more: https://git.openjdk.org/jdk/compare/a4a53858...35f51562

-------------

Changes: https://git.openjdk.org/jdk/pull/13074/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=06
  Stats: 4160 lines in 158 files changed: 2033 ins; 1675 del; 452 mod
  Patch: https://git.openjdk.org/jdk/pull/13074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074

PR: https://git.openjdk.org/jdk/pull/13074

From asotona at openjdk.org  Tue Apr 25 12:10:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 12:10:25 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v9]
In-Reply-To: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
Message-ID: <6R0CCMk9Vxaw-6eDJJmDy9Q5UsE8ihVde6t7ePXriNo=.69952093-cc95-4269-835f-6cb87bc090ef@github.com>

> Classfile API didn't handle transformations of class files version 50 and below correctly. 
> 
> Proposed fix have two parts: 
> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
> 2. StackMapTable attribute is not generated for class file versions below 50.
> 
> StackMapsTest is also extended to test this patch.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update StackCounter.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13478/files
  - new: https://git.openjdk.org/jdk/pull/13478/files/bd46c69c..42b96b2c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13478/head:pull/13478

PR: https://git.openjdk.org/jdk/pull/13478

From jbhateja at openjdk.org  Tue Apr 25 12:22:20 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 25 Apr 2023 12:22:20 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v6]
In-Reply-To: <mvjXG43i2H0ULxXam6DzZR6SPrVjyth_x4Fu7CTjmE0=.04f5e64d-54bd-4556-bc46-212552526853@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <mvjXG43i2H0ULxXam6DzZR6SPrVjyth_x4Fu7CTjmE0=.04f5e64d-54bd-4556-bc46-212552526853@github.com>
Message-ID: <PAUHwGpESblYnLoyYRyy5dUyIWlxqmkJM3xE1nQ8I38=.2ec7a5ed-b72f-43d4-b1bb-3e7c72b19d7d@github.com>

On Tue, 4 Apr 2023 13:46:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
>> 
>> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
>> 
>> Please take a look and have some reviews. Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   style

src/hotspot/cpu/x86/x86.ad line 7953:

> 7951:       __ punpckldq($dst$$XMMRegister, $src$$XMMRegister);
> 7952:     }
> 7953:     __ psrldq($dst$$XMMRegister, $origin$$constant * type2aelembytes(bt));

Move it to a new macro assembly routine.

src/hotspot/cpu/x86/x86.ad line 7962:

> 7960:             !VM_Version::supports_ssse3());
> 7961:   match(Set dst (VectorSlice (Binary dst src) origin));
> 7962:   effect(TEMP xtmp);

Please also associate TEMP_DEF / TEMP with dst to avoid early source overwrite in case dst/src are allocated same register.

src/hotspot/cpu/x86/x86.ad line 7970:

> 7968:     __ movdqu($xtmp$$XMMRegister, $src$$XMMRegister);
> 7969:     __ pslldq($xtmp$$XMMRegister, 16 - shift_count);
> 7970:     __ por($dst$$XMMRegister, $xtmp$$XMMRegister);

Move to macro assembly routine.

src/hotspot/cpu/x86/x86.ad line 8007:

> 8005:       }
> 8006:       __ vpsrldq($dst$$XMMRegister, $dst$$XMMRegister, shift_count, Assembler::AVX_128bit);
> 8007:     }

Move to macro assembly routine.

src/hotspot/cpu/x86/x86.ad line 8063:

> 8061:             (type2aelembytes(Matcher::vector_element_basic_type(n)) * n->in(2)->get_int()) % 4U != 0 &&
> 8062:             (type2aelembytes(Matcher::vector_element_basic_type(n)) * n->in(2)->get_int() < 16 ||
> 8063:              type2aelembytes(Matcher::vector_element_basic_type(n)) * n->in(2)->get_int() > 48));

Move these bulky predications to source_hpp section, like done at 
https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L8786

src/hotspot/cpu/x86/x86.ad line 8082:

> 8080:             type2aelembytes(Matcher::vector_element_basic_type(n)) * n->in(2)->get_int() > 16 &&
> 8081:             type2aelembytes(Matcher::vector_element_basic_type(n)) * n->in(2)->get_int() < 48);
> 8082:   match(Set dst (VectorSlice (Binary src1 src2) origin));

Same as above.

src/hotspot/cpu/x86/x86.ad line 8099:

> 8097:             (Matcher::vector_length_in_bytes(n) == 64 ||
> 8098:              (Matcher::vector_length_in_bytes(n) == 32 &&
> 8099:               VM_Version::supports_avx512vl())));

Same as above.

src/hotspot/share/opto/vectorIntrinsics.cpp line 1914:

> 1912:   if (vector_klass->const_oop() == NULL || elem_klass->const_oop() == NULL ||
> 1913:       !vlen->is_con() || !origin_type->is_con()) {
> 1914:     if (C->print_intrinsics()) {

Hi @merykitty , your inline expander is not handling non-constant origin case, this will introduce performance regressions w.r.t to existing implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1176428922
PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1176424735
PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1176429190
PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1176429410
PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1176428080
PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1176428309
PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1176428542
PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1176407424

From jbhateja at openjdk.org  Tue Apr 25 12:22:22 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 25 Apr 2023 12:22:22 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v6]
In-Reply-To: <PAUHwGpESblYnLoyYRyy5dUyIWlxqmkJM3xE1nQ8I38=.2ec7a5ed-b72f-43d4-b1bb-3e7c72b19d7d@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <mvjXG43i2H0ULxXam6DzZR6SPrVjyth_x4Fu7CTjmE0=.04f5e64d-54bd-4556-bc46-212552526853@github.com>
 <PAUHwGpESblYnLoyYRyy5dUyIWlxqmkJM3xE1nQ8I38=.2ec7a5ed-b72f-43d4-b1bb-3e7c72b19d7d@github.com>
Message-ID: <bi-qNEB_S_qnREy0zAw_E2crQmZeEXPWOsrvC93Incg=.89660de8-6f9f-4b03-81d5-d057fe8487ec@github.com>

On Tue, 25 Apr 2023 11:57:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   style
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 1914:
> 
>> 1912:   if (vector_klass->const_oop() == NULL || elem_klass->const_oop() == NULL ||
>> 1913:       !vlen->is_con() || !origin_type->is_con()) {
>> 1914:     if (C->print_intrinsics()) {
> 
> Hi @merykitty , your inline expander is not handling non-constant origin case, this will introduce performance regressions w.r.t to existing implementation.

You can extend expander to generate IR corresponding to fallback implementation to handle non-constant origin case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1176410139

From rgiulietti at openjdk.org  Tue Apr 25 13:12:21 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 25 Apr 2023 13:12:21 GMT
Subject: RFR: 8302987: Add uniform and spatially equidistributed bounded
 double streams to RandomGenerator [v6]
In-Reply-To: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
References: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
Message-ID: <BaO5UJsDVkIEc7Ny2-kYj3mcYncYq7fnvxgA8NmxRpc=.bcf47941-b9ea-4352-a4df-ef65d5bfc4ea@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 an @implNote.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12719/files
  - new: https://git.openjdk.org/jdk/pull/12719/files/7d313c97..ef47d1a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=04-05

  Stats: 18 lines in 1 file changed: 11 ins; 2 del; 5 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 Apr 25 13:17:14 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 25 Apr 2023 13:17:14 GMT
Subject: RFR: 8302987: Add uniform and spatially equidistributed bounded
 double streams to RandomGenerator [v7]
In-Reply-To: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
References: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
Message-ID: <RNwOjeTMeHFZraXaL2mN1PjfBiJyt0HjMUlwkdKbYeY=.350d1396-edd2-4c45-b4bd-8b8b4799addd@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:

  Changed @implNote to @implSpec.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12719/files
  - new: https://git.openjdk.org/jdk/pull/12719/files/ef47d1a4..bc0021cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 rriggs at openjdk.org  Tue Apr 25 14:17:22 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 25 Apr 2023 14:17:22 GMT
Subject: RFR: 8306678: Replace use of os.version with an internal Version
 record [v3]
In-Reply-To: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
Message-ID: <KCgvKRiyQ_a-HKNulP9Ecedtct-WvxhYH9VAp2Ic5Eg=.4daee317-21fe-427d-b707-db88bb517c61@github.com>

> Create an internal Version record to hold and compare versions of the form (major, minor, micro).
> Add `OperatingSystem.version()` to return the version of the running OS.
> Replace uses of os.version in java.base.
> Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Simplify initialization in ClassLoaderHelper and fix VersionTest.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13584/files
  - new: https://git.openjdk.org/jdk/pull/13584/files/01bc9cbf..8e3d9df3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13584&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13584&range=01-02

  Stats: 9 lines in 2 files changed: 0 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13584/head:pull/13584

PR: https://git.openjdk.org/jdk/pull/13584

From alanb at openjdk.org  Tue Apr 25 14:45:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Apr 2023 14:45:40 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: <RwXDZv4TR5e8ZdyqUXSgglrUrb-rnreV0BVsWYqPkH0=.e1d9cc76-977d-4885-a17a-539d8d103de5@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

I've gone through the API docs, also went through the src changes, but only lightly through ReverseOrderXXView classes as they are. bit tedious to review. It looks ready to go.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/7387#pullrequestreview-1400087378

From smarks at openjdk.org  Tue Apr 25 15:51:20 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 25 Apr 2023 15:51:20 GMT
Subject: Integrated: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: <98EdpKkYwqS8P5YFtOOOMk-LIkUXEcoK1YkjjwAT_H4=.02da1a13-8da6-440c-bd06-284824293439@github.com>

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> PR for Sequenced Collections implementation.

This pull request has now been integrated.

Changeset: 17ce0976
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/17ce0976e442d5fabb14daed40fa9a768989f02e
Stats:     7067 lines in 42 files changed: 6921 ins; 11 del; 135 mod

8266571: Sequenced Collections

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/7387

From dcubed at openjdk.org  Tue Apr 25 15:53:00 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 25 Apr 2023 15:53:00 GMT
Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when
 using an OutputAnalyzer at the same time
In-Reply-To: <OjLsgMRUFYZUmjzdta-q2Zj-rKGmKfPB2WqnWjYiuHk=.aabde9bc-d5d2-43cf-9d67-8c7dec5c682a@github.com>
References: <jbN1idusRU1wUiQ265HUUCyjb2eh8uSC4MDn5igYyy8=.ae64e31f-8c57-415e-8a21-ca7f0e8a6410@github.com>
 <4EDhpXuaKhviIcVGoDrPbVzcdze_pl4rJZu6DQvWeAw=.f5a9a485-3bb2-4f2b-8b65-e3d35eae1001@github.com>
 <OjLsgMRUFYZUmjzdta-q2Zj-rKGmKfPB2WqnWjYiuHk=.aabde9bc-d5d2-43cf-9d67-8c7dec5c682a@github.com>
Message-ID: <6ABDu4g-9JNwmdQpdmOXIbz6WUApspGnmHlMk7BhZ6I=.d11f2bc4-c895-4162-9b35-9f2a0d7be519@github.com>

On Tue, 25 Apr 2023 04:05:05 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/lib/jdk/test/lib/process/ProcessTools.java line 792:
>> 
>>> 790:         @Override
>>> 791:         public InputStream getInputStream() {
>>> 792:             return out;
>> 
>> This is a little bit confusing that the `getInputStream()` returns `out` stream.
>> Just wanted to double-check if it is intentional and was not needed for `getOutputStream()` instead.
>
> Agree, it is confusing, even in standard j.l.Process API . The `InputStream java.lang.Process.getInputStream()`" returns **output** stream of started process.  So for our implementation ProcessImpl the 'out' and 'err' mean output and error streams. However they are returned as InputStreams so users could read them.

Right. From the API caller's POV, it is asking for InputStreams that it can use to read the process' stdout or stderr streams.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1176718448

From qamai at openjdk.org  Tue Apr 25 16:17:17 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 25 Apr 2023 16:17:17 GMT
Subject: Integrated: 8306008: Several Vector API tests fail for client VM after
 JDK-8304450
In-Reply-To: <TDcfSAbMANHhRfHfZSAoKxfHPrsVqHrbE0gz1RwUBcg=.de344a1c-8d0e-477b-b8a2-209595967254@github.com>
References: <TDcfSAbMANHhRfHfZSAoKxfHPrsVqHrbE0gz1RwUBcg=.de344a1c-8d0e-477b-b8a2-209595967254@github.com>
Message-ID: <qqr5l-yg4q1ri3h9pg2gO_ErzJYKwhPVS4W_CyPFDLk=.0bf39980-8f54-4795-b0c6-1ebec33a1443@github.com>

On Tue, 18 Apr 2023 12:21:11 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Please review this patch which fixes the errors on machines where TypeMaxVector has a length of 64 bits. I take an extra cautious approach and fall back to putting elements one by one if the length is an unexpected value.
> 
> All jdk/incubator/vector tests passed with MaxVectorSize=8, which fails without this patch.
> 
> Thanks a lot.

This pull request has now been integrated.

Changeset: 0ff3a278
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ff3a2784e06873505956ba01f153bba82d6c07a
Stats:     275 lines in 11 files changed: 205 ins; 0 del; 70 mod

8306008: Several Vector API tests fail for client VM after JDK-8304450

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/13508

From naoto at openjdk.org  Tue Apr 25 16:31:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Apr 2023 16:31:09 GMT
Subject: RFR: 8305853:
 java/text/Format/DateFormat/DateFormatRegression.java fails with
 "Uncaught exception thrown in test method Test4089106" [v2]
In-Reply-To: <F_-vhIbxDmBc5NSTonXAP23GQc_Z4SJS7yzDXKfG2cE=.1b2618bf-d7d4-41ec-a401-834600939919@github.com>
References: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>
 <F_-vhIbxDmBc5NSTonXAP23GQc_Z4SJS7yzDXKfG2cE=.1b2618bf-d7d4-41ec-a401-834600939919@github.com>
Message-ID: <9yEWlPnMGSMqG9HrEQ-3u5jcnP7PI3RDvOM589Pzdj4=.0463d83d-d546-4839-bdc4-570ebb111134@github.com>

On Mon, 24 Apr 2023 23:47:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR fixes an intermittent failure (that only occurs on Windows) in _DateFormatRegression.java_.
>> 
>> With the integration of [JDK-8304982](https://bugs.openjdk.org/browse/JDK-8304982), _LocaleProviderAdapter.java_ now emits a compat warning when the class is loaded. This warning calls `ZonedDateTime.now()` during formatting. This call depends on the `TimeZone.ID` of the TimeZone returned from `TimeZone.getDefault()`.
>> 
>> On Windows, the test class which DateFormatRegression extends will run the tests at random, (as opposed to running in the same order every time). When Test4089106() happens to be the first test ran, the static block of LocaleProviderAdapter will be executed with `TimeZone.setDefault()` set to a `SimpleTimeZone` with `id` as _FAKEZONE_. When LocaleProviderAdapter formats the compat warning ... and many calls later calls `ZoneRulesProvider getProvider(String zoneId)` with `zoneId` as _FAKEZONE_ the test fails with _java.time.zone.ZoneRulesException: Unknown time-zone ID: FAKEZONE_.
>> 
>> In order to still test that `SimpleDateFormat.getTimeZone()` defaults to `TimeZone.getDefault()` we can create a `SimpleTimeZone` with a custom id rather than an invalid id. This way ZoneRulesProvider will not fail on the ID, but the `SimpleTimeZone` being tested is still not a "default" `TimeZone`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup / alternate custom tz

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13630#pullrequestreview-1400309227

From liach at openjdk.org  Tue Apr 25 16:39:59 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Apr 2023 16:39:59 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: <qghQUcICj4VuMqA0Q9DNBc0-boDbdR-v8crdpho7rjo=.ef17ea49-ba38-47c0-aa65-e4c935f2b27a@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

In retrospect, we should have updated the https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/doc-files/coll-reference.html and https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/doc-files/coll-overview.html documentation files. This can probably belong to a new issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1522096841

From bpb at openjdk.org  Tue Apr 25 16:50:13 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 25 Apr 2023 16:50:13 GMT
Subject: RFR: 8306623: (bf) CharBuffer::allocate throws unexpected
 exception type with some CharSequences [v2]
In-Reply-To: <nO9TB7oiGaBXNtJUk_tDK4xM6My2gpB6G2ibV9F9EDk=.1b397e11-ce61-47fc-94a9-5aedfdd8431e@github.com>
References: <0sphqHKN84N9VUm-rrBwPyDROgxB5rRJbMfb1fTZhlE=.1b9511a2-bc58-4b6a-a0be-d3e5732db941@github.com>
 <nO9TB7oiGaBXNtJUk_tDK4xM6My2gpB6G2ibV9F9EDk=.1b397e11-ce61-47fc-94a9-5aedfdd8431e@github.com>
Message-ID: <eMsG-GuAv0cOuVZH50r3nwsHRck1jfG56Lroz24OBqk=.f4c0a650-95c9-407c-b285-053fb5af1fc1@github.com>

On Tue, 25 Apr 2023 06:27:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8306623: Update comment; move test code location
>
> src/java.base/share/classes/java/nio/X-Buffer.java.template line 2050:
> 
>> 2048:             //
>> 2049:             // pre-emptively check for overflow as put(int,CharBuffer,int,int)
>> 2050:             // would throw IndexOutOfBoundsException instead
> 
> The comment is confusing, I think you just want to say that the append method throws BufferOverflowException when there is insufficient space in the buffer.

Comment updated and test code moved in 118076c.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13632#discussion_r1176783538

From bpb at openjdk.org  Tue Apr 25 16:50:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 25 Apr 2023 16:50:10 GMT
Subject: RFR: 8306623: (bf) CharBuffer::allocate throws unexpected
 exception type with some CharSequences [v2]
In-Reply-To: <0sphqHKN84N9VUm-rrBwPyDROgxB5rRJbMfb1fTZhlE=.1b9511a2-bc58-4b6a-a0be-d3e5732db941@github.com>
References: <0sphqHKN84N9VUm-rrBwPyDROgxB5rRJbMfb1fTZhlE=.1b9511a2-bc58-4b6a-a0be-d3e5732db941@github.com>
Message-ID: <unvPxNCOD2b7YK_rYwi6C5Q0PnmfwwSgag9IAdygBZY=.9351c684-5ce8-4240-a557-a2bf6970d4a9@github.com>

> When appending a `CharBuffer`, perform a specific check for buffer overflow before invoking `put()`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8306623: Update comment; move test code location

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13632/files
  - new: https://git.openjdk.org/jdk/pull/13632/files/ce70e879..118076c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13632&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13632&range=00-01

  Stats: 119 lines in 4 files changed: 60 ins; 30 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/13632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13632/head:pull/13632

PR: https://git.openjdk.org/jdk/pull/13632

From bpb at openjdk.org  Tue Apr 25 16:51:09 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 25 Apr 2023 16:51:09 GMT
Subject: RFR: JDK-8304423: Refactor FdLibm.java
In-Reply-To: <kkt3zVVtkAFIH4Joz82Xq8d5dhDX9VeA1p9sxNlS4XI=.7090fbc8-e059-47c0-9c12-65e56da9fc22@github.com>
References: <kkt3zVVtkAFIH4Joz82Xq8d5dhDX9VeA1p9sxNlS4XI=.7090fbc8-e059-47c0-9c12-65e56da9fc22@github.com>
Message-ID: <YaPv-9620J-RU27ELn4QvuiJ7SuTb5t7odc8jRNO01Y=.d796c316-909c-4a90-9464-017d400c23a5@github.com>

On Sun, 23 Apr 2023 22:34:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Minor refactoring of FdLibm.java; will consider future refactorings with more substantive code changes in the future.

LGTM2

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13604#pullrequestreview-1400340351

From mchung at openjdk.org  Tue Apr 25 16:59:25 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 25 Apr 2023 16:59:25 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v4]
In-Reply-To: <6nCaEpvTmyPMkeBa472jKe7HWLS7RgmthxBphJp_0bg=.3838cd75-fd44-48e8-9309-694a39c20704@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <6nCaEpvTmyPMkeBa472jKe7HWLS7RgmthxBphJp_0bg=.3838cd75-fd44-48e8-9309-694a39c20704@github.com>
Message-ID: <vmnfwlbJKPrIDlrUbTkZZ0wzPfYGnf4gpFUyzJ7-qU4=.bd18d075-63f9-430b-aff7-727e27dd667c@github.com>

On Tue, 25 Apr 2023 08:11:24 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
>> 
>> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
>> 
>> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
>> 
>> Please review this pull request and attached CSR.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added custom toString() methods

A side note: I notice that the type names are linked with `@linkplain` in this package mixed with some `@link`.  I'm not sure if it's intentional as type names are generally used `@link` or `@code`.

src/java.base/share/classes/java/lang/constant/ModuleDesc.java line 64:

> 62:      * an at-sign in a module name.
> 63:      * </ul>
> 64:      * @param name module name

Suggestion:

     * @param name the module name

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 33:

> 31:  *
> 32:  * <p>To create a {@linkplain PackageDesc} for a package, use {@link #of} or
> 33:  * {@link #ofInternalName(String)}.

Suggestion:

 * <p>To create a {@linkplain PackageDesc} for a package, use the {@link #of} or
 * {@link #ofInternalName(String)} method.

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 44:

> 42:      * given the name of the package, such as {@code "java.lang"}.
> 43:      * <p>
> 44:      * {@jls 13.1}

Do you mean to reference JLS 6.7?

Suggest to move this reference after `throws` in the see also section.

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 46:

> 44:      * {@jls 13.1}
> 45:      *
> 46:      * @param name the fully qualified (dot-separated) binary package name

JLS 13.1 does not describe a package has a binary name.   Is it correct to say "binary package name"?

Suggestion:

     * @param name the fully qualified (dot-separated) package name

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 62:

> 60:      * such as {@code "java/lang"}.
> 61:      * <p>
> 62:      * {@jvms 4.2.1} In this internal form, the ASCII periods (.) that normally

Suggest not to copy JVMS 4.2.1 here but instead just add it to see also section.

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 65:

> 63:      * separate the identifiers
> 64:      * which make up the binary name are replaced by ASCII forward slashes (/).
> 65:      * @param name the fully qualified class name, in internal (slash-separated)

Suggestion:

     * @param name the fully qualified package name, in internal (slash-separated) form

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 82:

> 80:      *
> 81:      * @return the package name, or the empty string for the
> 82:      * default package

Suggestion:

     * unnamed package

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 91:

> 89:      *
> 90:      * @return the package name, or the empty string for the
> 91:      * default package

Suggestion:

     * unnamed package


See JLS 7.4.2

src/java.base/share/classes/java/lang/constant/package-info.java line 93:

> 91:  *
> 92:  * <p>Other members of this package are {@link java.lang.constant.ModuleDesc}
> 93:  * and  {@link java.lang.constant.PackageDesc}. They represent module and package

Suggestion:

 * <p>Other members of this package are {@link ModuleDesc}
 * and  {@link PackageDesc}. They represent module and package


same package and so no need to qualify.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13615#pullrequestreview-1398780011
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1176758742
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1176759664
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1176763362
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1176770337
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1176781861
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1176768935
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1176789226
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1176787981
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1176790549

From mchung at openjdk.org  Tue Apr 25 16:59:30 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 25 Apr 2023 16:59:30 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v3]
In-Reply-To: <k2_HG58fJQHb9Aif2oMk8lu3e0cpVafN-M8RXVkxABU=.6dde0370-7e25-4b2f-95d7-39121651c883@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <k2_HG58fJQHb9Aif2oMk8lu3e0cpVafN-M8RXVkxABU=.6dde0370-7e25-4b2f-95d7-39121651c883@github.com>
Message-ID: <imAdA9WdiwDEmNzZhD4gX_Au0SipXjTz7Y6UYk5zqjM=.3978c7fc-171c-4a3b-90e5-a6215f9089e1@github.com>

On Mon, 24 Apr 2023 16:26:02 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
>> 
>> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
>> 
>> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
>> 
>> Please review this pull request and attached CSR.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doc fixes + added null and empty tests

src/java.base/share/classes/java/lang/constant/ModuleDesc.java line 30:

> 28: 
> 29: /**
> 30:  * A nominal descriptor for a {@code Module} constant {@jvms 4.4.11}.

This inlined link looks a bit awkward in the output.

I suggest to move `{@jvms 4.4.11}` as see also section before `@since 21`. See the suggestion below

src/java.base/share/classes/java/lang/constant/ModuleDesc.java line 32:

> 30:  * A nominal descriptor for a {@code Module} constant {@jvms 4.4.11}.
> 31:  *
> 32:  * <p>To create a {@linkplain ModuleDesc} for a module, use {@link #of}.

Suggestion:

 * <p>To create a {@linkplain ModuleDesc} for a module, use the {@link #of} method.

src/java.base/share/classes/java/lang/constant/ModuleDesc.java line 34:

> 32:  * <p>To create a {@linkplain ModuleDesc} for a module, use {@link #of}.
> 33:  *
> 34:  * @since 21

Suggestion:

 * @jvms 4.4.11 The CONSTANT_Module_info Structure
 * @since 21

src/java.base/share/classes/java/lang/constant/ModuleDesc.java line 43:

> 41:      * given the name of the module.
> 42:      *
> 43:      * <p>{@jvms 4.2.3} Module names are not encoded in "internal form" like

I would avoid copying JVMS 4.2.3 into the javadoc as it might become out-of-sync.  In addition, adding `@jvms 4.2.3 Module and Package Names` in the see also section should be adequate (like the javadoc of `ClassDesc::ofInternalName`).

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 30:

> 28: 
> 29: /**
> 30:  * A nominal descriptor for a {@code Package} constant {@jvms 4.4.12}.

I suggest to move `{@jvms 4.4.12}` as see also section before `@since 21`.  See the suggestion below

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 35:

> 33:  * {@link #ofInternalName(String)}.
> 34:  *
> 35:  * @since 21

Suggestion:

 *  * @jvms 4.4.11 The CONSTANT_Module_info Structure
 * @since 21


The output javadoc will show `See Java Virtual Machine Specification:`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175818650
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175830777
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175819238
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175822059
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175774209
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1175774600

From lancea at openjdk.org  Tue Apr 25 17:00:10 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 25 Apr 2023 17:00:10 GMT
Subject: RFR: 8305853:
 java/text/Format/DateFormat/DateFormatRegression.java fails with
 "Uncaught exception thrown in test method Test4089106" [v2]
In-Reply-To: <F_-vhIbxDmBc5NSTonXAP23GQc_Z4SJS7yzDXKfG2cE=.1b2618bf-d7d4-41ec-a401-834600939919@github.com>
References: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>
 <F_-vhIbxDmBc5NSTonXAP23GQc_Z4SJS7yzDXKfG2cE=.1b2618bf-d7d4-41ec-a401-834600939919@github.com>
Message-ID: <PpUCyOMm9gZH-uOZ9_NQdYDzbMJHDdq4HUoDsvgi5tQ=.fc516862-2830-4916-ba20-a564f582c092@github.com>

On Mon, 24 Apr 2023 23:47:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR fixes an intermittent failure (that only occurs on Windows) in _DateFormatRegression.java_.
>> 
>> With the integration of [JDK-8304982](https://bugs.openjdk.org/browse/JDK-8304982), _LocaleProviderAdapter.java_ now emits a compat warning when the class is loaded. This warning calls `ZonedDateTime.now()` during formatting. This call depends on the `TimeZone.ID` of the TimeZone returned from `TimeZone.getDefault()`.
>> 
>> On Windows, the test class which DateFormatRegression extends will run the tests at random, (as opposed to running in the same order every time). When Test4089106() happens to be the first test ran, the static block of LocaleProviderAdapter will be executed with `TimeZone.setDefault()` set to a `SimpleTimeZone` with `id` as _FAKEZONE_. When LocaleProviderAdapter formats the compat warning ... and many calls later calls `ZoneRulesProvider getProvider(String zoneId)` with `zoneId` as _FAKEZONE_ the test fails with _java.time.zone.ZoneRulesException: Unknown time-zone ID: FAKEZONE_.
>> 
>> In order to still test that `SimpleDateFormat.getTimeZone()` defaults to `TimeZone.getDefault()` we can create a `SimpleTimeZone` with a custom id rather than an invalid id. This way ZoneRulesProvider will not fail on the ID, but the `SimpleTimeZone` being tested is still not a "default" `TimeZone`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup / alternate custom tz

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13630#pullrequestreview-1400354287

From mchung at openjdk.org  Tue Apr 25 17:05:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 25 Apr 2023 17:05:12 GMT
Subject: RFR: 8306678: Replace use of os.version with an internal Version
 record [v3]
In-Reply-To: <KCgvKRiyQ_a-HKNulP9Ecedtct-WvxhYH9VAp2Ic5Eg=.4daee317-21fe-427d-b707-db88bb517c61@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
 <KCgvKRiyQ_a-HKNulP9Ecedtct-WvxhYH9VAp2Ic5Eg=.4daee317-21fe-427d-b707-db88bb517c61@github.com>
Message-ID: <wBMIfsxqgB-3sxEz3f0aH2S2bzGKKO_Pkr2WW0Mu8xg=.fc209872-4f5d-49a4-b874-9e4d429db44b@github.com>

On Tue, 25 Apr 2023 14:17:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Create an internal Version record to hold and compare versions of the form (major, minor, micro).
>> Add `OperatingSystem.version()` to return the version of the running OS.
>> Replace uses of os.version in java.base.
>> Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify initialization in ClassLoaderHelper and fix VersionTest.

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13584#pullrequestreview-1400361318

From naoto at openjdk.org  Tue Apr 25 17:12:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Apr 2023 17:12:11 GMT
Subject: RFR: 8305505: NPE in javazic compiler
In-Reply-To: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
References: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
Message-ID: <apagDwvacqb0PH5j0cl4j4AacLQin60Eem5FMGgqmNg=.dee5a670-18b7-439a-9a52-1209b3fa8fff@github.com>

On Tue, 18 Apr 2023 05:08:35 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  
> With this minor change, the javazic compiler (Main.java) can produce the HTML files that display given time zone data correctly.

I revisited the code, and now think that `mapList` better be `null`, as it indicates the map option was not provided, so I think modifying the offending line as

            LatitudeAndLongitude location = (mapList != null ? mapList.get(zonename) : null);

may be cleaner.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13504#pullrequestreview-1400371061

From bpb at openjdk.org  Tue Apr 25 17:17:09 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 25 Apr 2023 17:17:09 GMT
Subject: RFR: 8306623: (bf) CharBuffer::allocate throws unexpected
 exception type with some CharSequences
In-Reply-To: <nO9TB7oiGaBXNtJUk_tDK4xM6My2gpB6G2ibV9F9EDk=.1b397e11-ce61-47fc-94a9-5aedfdd8431e@github.com>
References: <0sphqHKN84N9VUm-rrBwPyDROgxB5rRJbMfb1fTZhlE=.1b9511a2-bc58-4b6a-a0be-d3e5732db941@github.com>
 <nO9TB7oiGaBXNtJUk_tDK4xM6My2gpB6G2ibV9F9EDk=.1b397e11-ce61-47fc-94a9-5aedfdd8431e@github.com>
Message-ID: <1B_dBjseaqE-oA3tG_5LFtzmC61eK0Wu4regzPCH_Qw=.99f1ef66-ded0-4217-bee9-8450599dd5f7@github.com>

On Tue, 25 Apr 2023 06:25:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> [...] I think this regression was missed because this tests didn't check this case.

It definitely was.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13632#issuecomment-1522142226

From alanb at openjdk.org  Tue Apr 25 18:34:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Apr 2023 18:34:09 GMT
Subject: RFR: 8306623: (bf) CharBuffer::allocate throws unexpected
 exception type with some CharSequences [v2]
In-Reply-To: <unvPxNCOD2b7YK_rYwi6C5Q0PnmfwwSgag9IAdygBZY=.9351c684-5ce8-4240-a557-a2bf6970d4a9@github.com>
References: <0sphqHKN84N9VUm-rrBwPyDROgxB5rRJbMfb1fTZhlE=.1b9511a2-bc58-4b6a-a0be-d3e5732db941@github.com>
 <unvPxNCOD2b7YK_rYwi6C5Q0PnmfwwSgag9IAdygBZY=.9351c684-5ce8-4240-a557-a2bf6970d4a9@github.com>
Message-ID: <LDLi9QVnX1e_EhYrUf4YuIeEQmDqnmOC_zfv7tinOG8=.78f2ada5-523a-4948-869d-60c583ed766f@github.com>

On Tue, 25 Apr 2023 16:50:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> When appending a `CharBuffer`, perform a specific check for buffer overflow before invoking `put()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8306623: Update comment; move test code location

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13632#pullrequestreview-1400495094

From asotona at openjdk.org  Tue Apr 25 18:57:23 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 18:57:23 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v5]
In-Reply-To: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
Message-ID: <bk8GZ99qE59NGn8S-at5_4M3Q9_y5nMyQTAABOeDWz4=.26f26b1a-1480-4b01-b694-dfd10ca28916@github.com>

> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
> 
> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
> 
> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
> 
> Please review this pull request and attached CSR.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13615/files
  - new: https://git.openjdk.org/jdk/pull/13615/files/7c45b343..2c67f83a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=03-04

  Stats: 12 lines in 3 files changed: 2 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13615/head:pull/13615

PR: https://git.openjdk.org/jdk/pull/13615

From asotona at openjdk.org  Tue Apr 25 18:59:55 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 18:59:55 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v6]
In-Reply-To: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
Message-ID: <xbJSS_FTmoabR65a37eZTXrHAQSd8tGJWOe54sgK9UE=.a19ec5b5-97dd-4bf5-b939-d72a3771360d@github.com>

> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
> 
> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
> 
> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
> 
> Please review this pull request and attached CSR.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update PackageDesc.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13615/files
  - new: https://git.openjdk.org/jdk/pull/13615/files/2c67f83a..b094cb02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13615/head:pull/13615

PR: https://git.openjdk.org/jdk/pull/13615

From bpb at openjdk.org  Tue Apr 25 19:04:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 25 Apr 2023 19:04:10 GMT
Subject: RFR: 8306623: (bf) CharBuffer::allocate throws unexpected
 exception type with some CharSequences [v3]
In-Reply-To: <0sphqHKN84N9VUm-rrBwPyDROgxB5rRJbMfb1fTZhlE=.1b9511a2-bc58-4b6a-a0be-d3e5732db941@github.com>
References: <0sphqHKN84N9VUm-rrBwPyDROgxB5rRJbMfb1fTZhlE=.1b9511a2-bc58-4b6a-a0be-d3e5732db941@github.com>
Message-ID: <hx6UzIsO3qL9B4gfMrB-douUr40EavqOXsE4X8iQ_Uw=.18c12719-2812-47a0-9806-ba9bf909d86b@github.com>

> When appending a `CharBuffer`, perform a specific check for buffer overflow before invoking `put()`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8306623: Add overlooked issue ID to @bug

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13632/files
  - new: https://git.openjdk.org/jdk/pull/13632/files/118076c9..cc3acc94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13632&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13632&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13632/head:pull/13632

PR: https://git.openjdk.org/jdk/pull/13632

From asotona at openjdk.org  Tue Apr 25 19:12:20 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 19:12:20 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v7]
In-Reply-To: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
Message-ID: <6GOqH47JVahvur_1WM1qr4Vc4FZ4N1imZQ-4XR03aM0=.c0db21c2-6fa7-4393-9bf4-2a58d04a8b9d@github.com>

> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
> 
> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
> 
> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
> 
> Please review this pull request and attached CSR.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update ModuleDesc.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13615/files
  - new: https://git.openjdk.org/jdk/pull/13615/files/b094cb02..5f9664f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=05-06

  Stats: 27 lines in 1 file changed: 1 ins; 21 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13615/head:pull/13615

PR: https://git.openjdk.org/jdk/pull/13615

From asotona at openjdk.org  Tue Apr 25 19:12:23 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 19:12:23 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v3]
In-Reply-To: <imAdA9WdiwDEmNzZhD4gX_Au0SipXjTz7Y6UYk5zqjM=.3978c7fc-171c-4a3b-90e5-a6215f9089e1@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <k2_HG58fJQHb9Aif2oMk8lu3e0cpVafN-M8RXVkxABU=.6dde0370-7e25-4b2f-95d7-39121651c883@github.com>
 <imAdA9WdiwDEmNzZhD4gX_Au0SipXjTz7Y6UYk5zqjM=.3978c7fc-171c-4a3b-90e5-a6215f9089e1@github.com>
Message-ID: <Qpu_g3qzsGzLDpNWNw9MvQgOYznjek1oQqxF29jSTVY=.3654cc8c-3708-421b-93c3-fb08226f9e89@github.com>

On Mon, 24 Apr 2023 21:59:29 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Doc fixes + added null and empty tests
>
> src/java.base/share/classes/java/lang/constant/ModuleDesc.java line 30:
> 
>> 28: 
>> 29: /**
>> 30:  * A nominal descriptor for a {@code Module} constant {@jvms 4.4.11}.
> 
> This inlined link looks a bit awkward in the output.
> 
> I suggest to move `{@jvms 4.4.11}` as see also section before `@since 21`. See the suggestion below

Fixed, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1176927427

From lancea at openjdk.org  Tue Apr 25 19:16:10 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 25 Apr 2023 19:16:10 GMT
Subject: RFR: 8306623: (bf) CharBuffer::allocate throws unexpected
 exception type with some CharSequences [v3]
In-Reply-To: <hx6UzIsO3qL9B4gfMrB-douUr40EavqOXsE4X8iQ_Uw=.18c12719-2812-47a0-9806-ba9bf909d86b@github.com>
References: <0sphqHKN84N9VUm-rrBwPyDROgxB5rRJbMfb1fTZhlE=.1b9511a2-bc58-4b6a-a0be-d3e5732db941@github.com>
 <hx6UzIsO3qL9B4gfMrB-douUr40EavqOXsE4X8iQ_Uw=.18c12719-2812-47a0-9806-ba9bf909d86b@github.com>
Message-ID: <o3ZgIqGnjke9GZyerqOPfWhcYqsAtQLWoEXLQOKAE0g=.25ff44d2-90cb-4f55-a7b1-ed8161000f78@github.com>

On Tue, 25 Apr 2023 19:04:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> When appending a `CharBuffer`, perform a specific check for buffer overflow before invoking `put()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8306623: Add overlooked issue ID to @bug

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13632#pullrequestreview-1400573696

From asotona at openjdk.org  Tue Apr 25 19:25:40 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 19:25:40 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v8]
In-Reply-To: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
Message-ID: <gbmLn_YCjB50nwh4VVJaJgufm6D8Prc89HtjqhWZeMI=.1e361ff8-4ac3-4b36-a283-295b4db7cfa6@github.com>

> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
> 
> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
> 
> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
> 
> Please review this pull request and attached CSR.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update PackageDesc.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13615/files
  - new: https://git.openjdk.org/jdk/pull/13615/files/5f9664f8..ecae26cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=06-07

  Stats: 20 lines in 1 file changed: 6 ins; 5 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13615/head:pull/13615

PR: https://git.openjdk.org/jdk/pull/13615

From asotona at openjdk.org  Tue Apr 25 19:25:40 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 19:25:40 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v3]
In-Reply-To: <imAdA9WdiwDEmNzZhD4gX_Au0SipXjTz7Y6UYk5zqjM=.3978c7fc-171c-4a3b-90e5-a6215f9089e1@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <k2_HG58fJQHb9Aif2oMk8lu3e0cpVafN-M8RXVkxABU=.6dde0370-7e25-4b2f-95d7-39121651c883@github.com>
 <imAdA9WdiwDEmNzZhD4gX_Au0SipXjTz7Y6UYk5zqjM=.3978c7fc-171c-4a3b-90e5-a6215f9089e1@github.com>
Message-ID: <rEADDCRMr8HLJceYmJNMJzR7IWA0AV9RuECeq_mWwjM=.155659fe-3258-401a-87bc-5bfdd123acb0@github.com>

On Mon, 24 Apr 2023 20:56:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Doc fixes + added null and empty tests
>
> src/java.base/share/classes/java/lang/constant/PackageDesc.java line 30:
> 
>> 28: 
>> 29: /**
>> 30:  * A nominal descriptor for a {@code Package} constant {@jvms 4.4.12}.
> 
> I suggest to move `{@jvms 4.4.12}` as see also section before `@since 21`.  See the suggestion below

Fixed, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1176944315

From darcy at openjdk.org  Tue Apr 25 19:36:17 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 25 Apr 2023 19:36:17 GMT
Subject: Integrated: JDK-8304423: Refactor FdLibm.java
In-Reply-To: <kkt3zVVtkAFIH4Joz82Xq8d5dhDX9VeA1p9sxNlS4XI=.7090fbc8-e059-47c0-9c12-65e56da9fc22@github.com>
References: <kkt3zVVtkAFIH4Joz82Xq8d5dhDX9VeA1p9sxNlS4XI=.7090fbc8-e059-47c0-9c12-65e56da9fc22@github.com>
Message-ID: <AZMXBkdkX5-Am0-I_otqCuYard-hzAh4FVOREU_9abE=.41588abd-9a24-4e5b-a308-7fab767da3a3@github.com>

On Sun, 23 Apr 2023 22:34:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Minor refactoring of FdLibm.java; will consider future refactorings with more substantive code changes in the future.

This pull request has now been integrated.

Changeset: d819deba
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d819debaa5f0155e5e3990fa4f919ab420610c97
Stats:     85 lines in 1 file changed: 10 ins; 3 del; 72 mod

8304423: Refactor FdLibm.java

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/13604

From asotona at openjdk.org  Tue Apr 25 19:36:46 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 19:36:46 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v9]
In-Reply-To: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
Message-ID: <2dSP4LawxAGxyYscLiqxcy-ERTghhlB9zDFJ9MnLMxY=.901919ee-1ee7-4f5e-ab41-2147c4247459@github.com>

> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
> 
> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
> 
> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
> 
> Please review this pull request and attached CSR.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - Update ModuleDesc.java
 - Update PackageDesc.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13615/files
  - new: https://git.openjdk.org/jdk/pull/13615/files/ecae26cf..2d28353e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=07-08

  Stats: 12 lines in 2 files changed: 3 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13615/head:pull/13615

PR: https://git.openjdk.org/jdk/pull/13615

From asotona at openjdk.org  Tue Apr 25 19:36:46 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 19:36:46 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v3]
In-Reply-To: <imAdA9WdiwDEmNzZhD4gX_Au0SipXjTz7Y6UYk5zqjM=.3978c7fc-171c-4a3b-90e5-a6215f9089e1@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <k2_HG58fJQHb9Aif2oMk8lu3e0cpVafN-M8RXVkxABU=.6dde0370-7e25-4b2f-95d7-39121651c883@github.com>
 <imAdA9WdiwDEmNzZhD4gX_Au0SipXjTz7Y6UYk5zqjM=.3978c7fc-171c-4a3b-90e5-a6215f9089e1@github.com>
Message-ID: <INSblqNvoJCG-15anexijy5fmmxP19haq6eY1sEBQkk=.ed1155be-8774-41a1-a2af-eae9b37e45ec@github.com>

On Mon, 24 Apr 2023 22:05:18 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Doc fixes + added null and empty tests
>
> src/java.base/share/classes/java/lang/constant/ModuleDesc.java line 43:
> 
>> 41:      * given the name of the module.
>> 42:      *
>> 43:      * <p>{@jvms 4.2.3} Module names are not encoded in "internal form" like
> 
> I would avoid copying JVMS 4.2.3 into the javadoc as it might become out-of-sync.  In addition, adding `@jvms 4.2.3 Module and Package Names` in the see also section should be adequate (like the javadoc of `ClassDesc::ofInternalName`).

Fixed, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1176954238

From asotona at openjdk.org  Tue Apr 25 19:36:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 19:36:47 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v4]
In-Reply-To: <vmnfwlbJKPrIDlrUbTkZZ0wzPfYGnf4gpFUyzJ7-qU4=.bd18d075-63f9-430b-aff7-727e27dd667c@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <6nCaEpvTmyPMkeBa472jKe7HWLS7RgmthxBphJp_0bg=.3838cd75-fd44-48e8-9309-694a39c20704@github.com>
 <vmnfwlbJKPrIDlrUbTkZZ0wzPfYGnf4gpFUyzJ7-qU4=.bd18d075-63f9-430b-aff7-727e27dd667c@github.com>
Message-ID: <KBSgO28vL27i-XT31wbcbjxAYUy0Hl1tujaNC0azcY0=.ace05be5-9eff-4ae7-8514-b78371997b29@github.com>

On Tue, 25 Apr 2023 16:26:01 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added custom toString() methods
>
> src/java.base/share/classes/java/lang/constant/PackageDesc.java line 44:
> 
>> 42:      * given the name of the package, such as {@code "java.lang"}.
>> 43:      * <p>
>> 44:      * {@jls 13.1}
> 
> Do you mean to reference JLS 6.7?
> 
> Suggest to move this reference after `throws` in the see also section.

Fixed, thanks.

> src/java.base/share/classes/java/lang/constant/PackageDesc.java line 62:
> 
>> 60:      * such as {@code "java/lang"}.
>> 61:      * <p>
>> 62:      * {@jvms 4.2.1} In this internal form, the ASCII periods (.) that normally
> 
> Suggest not to copy JVMS 4.2.1 here but instead just add it to see also section.

Fixed, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1176954431
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1176951889

From asotona at openjdk.org  Tue Apr 25 19:43:29 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Apr 2023 19:43:29 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v10]
In-Reply-To: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
Message-ID: <IxgwT4-WrCAAAzBEfOk6inLJI8rTBQcD6jq_DGpaPVw=.eb365f86-7a92-45be-9afe-abad692e6324@github.com>

> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
> 
> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
> 
> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
> 
> Please review this pull request and attached CSR.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - Update ModuleDesc.java
 - Update PackageDesc.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13615/files
  - new: https://git.openjdk.org/jdk/pull/13615/files/2d28353e..b37a2394

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=08-09

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13615/head:pull/13615

PR: https://git.openjdk.org/jdk/pull/13615

From bpb at openjdk.org  Tue Apr 25 20:21:16 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 25 Apr 2023 20:21:16 GMT
Subject: Integrated: 8306623: (bf) CharBuffer::allocate throws unexpected
 exception type with some CharSequences
In-Reply-To: <0sphqHKN84N9VUm-rrBwPyDROgxB5rRJbMfb1fTZhlE=.1b9511a2-bc58-4b6a-a0be-d3e5732db941@github.com>
References: <0sphqHKN84N9VUm-rrBwPyDROgxB5rRJbMfb1fTZhlE=.1b9511a2-bc58-4b6a-a0be-d3e5732db941@github.com>
Message-ID: <79KgrjbKJvEJjHpQ9XtWpdT689pNmVSgfmdEiag_JlY=.7872d8af-2faf-4c1c-9a27-e1490b807fde@github.com>

On Tue, 25 Apr 2023 01:44:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> When appending a `CharBuffer`, perform a specific check for buffer overflow before invoking `put()`.

This pull request has now been integrated.

Changeset: e3ccaa65
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3ccaa6541e98aaa57b31a05cb998d48a0f7ee87
Stats:     74 lines in 4 files changed: 69 ins; 0 del; 5 mod

8306623: (bf) CharBuffer::allocate throws unexpected exception type with some CharSequences

Reviewed-by: alanb, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/13632

From jlu at openjdk.org  Tue Apr 25 20:35:22 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 25 Apr 2023 20:35:22 GMT
Subject: Integrated: 8306031: Update IANA Language Subtag Registry to Version
 2023-04-13
In-Reply-To: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
Message-ID: <qJLR2MnB-CAMxgYhwYA7UgWKVaAROjnXe64hPm3aP18=.f9c1c5e9-41f2-4c3b-bb80-68389a5d38cd@github.com>

On Mon, 17 Apr 2023 19:48:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
> 
> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
> 
> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
> 
> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
> 
> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
> 
> 
> ...
> singleEquivMap.put("ar-ajp", "ajp");
> singleEquivMap.put("ajp", "ar-ajp");
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
> ...
> 
> 
> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
> 
> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
> 
> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
> 
> To address this, the build process must be adjusted so that the equivalencies are built as 
> 
> 
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
> ...
> 
> 
> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.

This pull request has now been integrated.

Changeset: 00b1eaca
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/00b1eacad6ae2d5ea5afb1de506768e9ab960743
Stats:     37 lines in 3 files changed: 19 ins; 0 del; 18 mod

8306031: Update IANA Language Subtag Registry to Version 2023-04-13

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/13501

From jlu at openjdk.org  Tue Apr 25 20:37:08 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 25 Apr 2023 20:37:08 GMT
Subject: RFR: 8306711: Improve diagnosis of `IntlTest` framework
Message-ID: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>

Please review changes to the IntlTest (test framework) class. 

These changes include
- Logging the actual exception + stack trace. Previously, the test framework would throw `InvocationTargetException` but hide the actual underlying exception of the failing test unless the test class was ran with -nothrow.
- Sorting the tests, ensuring for any given run, the tests are ran in the same order. (In [JDK-8305853](https://bugs.openjdk.org/browse/JDK-8305853) it was discovered that on Windows, the test framework would execute tests in a random order each time).
- Removing unused methods + improving output.

-------------

Commit messages:
 - Exc changes, sort tests, general cleanup

Changes: https://git.openjdk.org/jdk/pull/13655/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13655&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306711
  Stats: 118 lines in 1 file changed: 44 ins; 59 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13655/head:pull/13655

PR: https://git.openjdk.org/jdk/pull/13655

From rriggs at openjdk.org  Tue Apr 25 21:04:08 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 25 Apr 2023 21:04:08 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v2]
In-Reply-To: <a24W0ATdimi_sDufP2ozdW66xyopfuG6Bq1z-ukuA_Y=.9879da5d-5ab1-4b9d-86d7-31690e74ce84@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <EcquNmlW2gNL6XeesD60LIJAUGnpZuDcegRczIGsGZ8=.6649cc69-4392-47a1-ac23-8d70b38b3fdd@github.com>
 <a24W0ATdimi_sDufP2ozdW66xyopfuG6Bq1z-ukuA_Y=.9879da5d-5ab1-4b9d-86d7-31690e74ce84@github.com>
Message-ID: <1yryY7OILSrnZbzlAUddYNA1s7XgnJRpZqt6abZqKzw=.599138e6-e002-404d-a534-0d017ba0c86c@github.com>

On Mon, 24 Apr 2023 15:58:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addresed review comments of @turbanoff, @shipilev and @RogerRiggs
>
> test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 88:
> 
>> 86:         } catch (ObjectStreamException ose) {
>> 87:             // OK, because a NegativeArraySizeException should be converted into a ObjectStreamException
>> 88:             if ("Array length is negative".equals(ose.getMessage())) {
> 
> This feels like `!equals`, i.e. throw exception when the message is *not* "Array length is negative"?

The complete `getMessage()` is `[Ljava.lang.String;; Array length is negative`.
Perhaps: 

ose.getMessage().contains("Array length is negative") ...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1177050269

From psandoz at openjdk.org  Tue Apr 25 21:10:20 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 25 Apr 2023 21:10:20 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v24]
In-Reply-To: <znkZ0Yg1tP8eBeZuIer1NWrySNSJOM7EgZyIvIXsx3w=.fc4362ca-8148-4454-a7f0-7659c1f28d31@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <znkZ0Yg1tP8eBeZuIer1NWrySNSJOM7EgZyIvIXsx3w=.fc4362ca-8148-4454-a7f0-7659c1f28d31@github.com>
Message-ID: <NwOSd0cOkMzsGvtw0Wu14NiTWXb20gH40EQdg4H75fQ=.6639537a-012f-4fde-8fd4-6c84f15db02c@github.com>

On Wed, 19 Apr 2023 13:37:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> ### Specdiff
>> https://cr.openjdk.org/~pminborg/panama/21/v2/specdiff/overview-summary.html
>> 
>> ### Javadoc
>> https://cr.openjdk.org/~pminborg/panama/21/v2/javadoc/api/java.base/java/lang/foreign/package-summary.html
>> 
>> ### Tests
>> 
>> Testing excludes tests on the "zero" platform. 
>> 
>> - [X] Tier1
>> - [X] Tier2
>> - [X] Tier3
>> - [X] Tier4
>> - [X] Tier5
>> - [X] Tier6 (Except one test applications/jcstress/init.java as per below)
>> 
>> 
>> Exception in thread "main" java.lang.IllegalStateException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
>> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:66)
>> 	at org.openjdk.jcstress.vm.ContendedTestMain.main(ContendedTestMain.java:43)
>> Caused by: java.lang.ClassNotFoundException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
>> 	at java.base/java.lang.Class.forName0(Native Method)
>> 	at java.base/java.lang.Class.forName(Class.java:497)
>> 	at java.base/java.lang.Class.forName(Class.java:476)
>> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:64)
>> 	... 1 more
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
> 
>  - Merge branch 'master' into PR_21_V2
>  - Update test/jdk/java/foreign/TestByteBuffer.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
>    
>    rename has_port
>  - rename has_port
>  - Merge pull request #2 from JornVernee/WSL_BB
>    
>    account for missing functional in WSL in TestByteBuffer
>  - account for missing mincore on WSL in TestByteBuffer
>  - Merge branch 'master' into PR_21_V2
>  - 8305369: Issues in zero-length memory segment javadoc section
>  - 8305087: MemoryLayout API checks should be more eager
>  - Merge master
>  - ... and 32 more: https://git.openjdk.org/jdk/compare/9fb53adf...ba04f5cc

src/java.base/share/classes/java/lang/foreign/Linker.java line 327:

> 325:  * MemorySegment allocateMemory(long byteSize, Arena arena) {
> 326:  *     MemorySegment segment = (MemorySegment)malloc.invokeExact(byteSize);   // size = 0, scope = always alive
> 327:  *     return segment.reinterpret(size, arena, s -> free.invokeExact(s));     // size = byteSize, scope = arena.scope()

Suggestion:

 *     MemorySegment segment = (MemorySegment)malloc.invokeExact(byteSize);    // size = 0, scope = always alive
 *     return segment.reinterpret(byteSize, arena, s -> free.invokeExact(s));  // size = byteSize, scope = arena.scope()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1177057372

From rriggs at openjdk.org  Tue Apr 25 21:51:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 25 Apr 2023 21:51:19 GMT
Subject: RFR: 8298993: (process) java/lang/ProcessBuilder/UnblockSignals.java
 fails
Message-ID: <iWHiW4JJiCHgJERISrctccBOnAZgAfsemSDjfZJEQzI=.b60ab5fa-82f5-4e77-9d8d-1fb02ec162d2@github.com>

It appears that -Xcomp causes the relative timing of the commands to be disturbed enough to prevent the correct operation of the test. The test should not be run with -Xcomp

-------------

Commit messages:
 - 8298993: (process) java/lang/ProcessBuilder/UnblockSignals.java fails

Changes: https://git.openjdk.org/jdk/pull/13660/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13660&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298993
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13660.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13660/head:pull/13660

PR: https://git.openjdk.org/jdk/pull/13660

From mchung at openjdk.org  Tue Apr 25 21:56:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 25 Apr 2023 21:56:16 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v10]
In-Reply-To: <IxgwT4-WrCAAAzBEfOk6inLJI8rTBQcD6jq_DGpaPVw=.eb365f86-7a92-45be-9afe-abad692e6324@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <IxgwT4-WrCAAAzBEfOk6inLJI8rTBQcD6jq_DGpaPVw=.eb365f86-7a92-45be-9afe-abad692e6324@github.com>
Message-ID: <INN62jwHvhzl4v11FXFNGYJH0n7aHw89LxHjkcqt2xQ=.75b5771c-1d13-4c65-80d5-aa3106447030@github.com>

On Tue, 25 Apr 2023 19:43:29 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
>> 
>> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
>> 
>> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
>> 
>> Please review this pull request and attached CSR.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update ModuleDesc.java
>  - Update PackageDesc.java

I wonder if `packageName()` and `packageInternalName()` methods can simply be `name()` and `internalName()` as the type name  is `PackageDesc` and `package` prefix seems to be unnecessary.   Similarly, `moduleName()` can be `name()`.   Have this be discussed and rejected?

src/java.base/share/classes/java/lang/constant/ModuleDesc.java line 32:

> 30:  * A nominal descriptor for a {@code Module} constant.
> 31:  *
> 32:  * @apiNote

can drop `@apiNote` as it's not needed to be.  `<p>` if you want to a new paragraph.

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 32:

> 30:  * A nominal descriptor for a {@code Package} constant.
> 31:  *
> 32:  * @apiNote

can drop `@apiNote` as it's not needed to be. `<p>` if you want to a new paragraph.

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 51:

> 49:      * @throws IllegalArgumentException if the name string is not in the
> 50:      * correct format
> 51:      * @jls 6.7 Fully Qualified Names and Canonical Names

Suggestion:

     * @jls 6.5.3 Module Names and Package Names

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 70:

> 68:      * @throws IllegalArgumentException if the name string is not in the
> 69:      * correct format
> 70:      * @jvms 4.2.1 Binary Class and Interface Names

Worth adding `@jvm 4.2.3 Module and Package Names`

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 79:

> 77: 
> 78:     /**
> 79:      * Returns the fully qualified (slash-separated) internal package name

Suggestion:

     * Returns the fully qualified (slash-separated) package name in internal form

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 82:

> 80:      * of this {@link PackageDesc}.
> 81:      *
> 82:      * @return the package name, or the empty string for the

Suggestion:

     * @return the package name in internal form, or the empty string for the

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 89:

> 87: 
> 88:     /**
> 89:      * Returns the fully qualified (dot-separated) binary package name

Suggestion:

     * Returns the fully qualified (dot-separated) package name

-------------

PR Review: https://git.openjdk.org/jdk/pull/13615#pullrequestreview-1400784174
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1177094576
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1177084404
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1177085890
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1177088336
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1177088970
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1177089545
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1177097732

From jlu at openjdk.org  Tue Apr 25 22:08:09 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 25 Apr 2023 22:08:09 GMT
Subject: RFR: 8306711: Improve diagnosis of `IntlTest` framework [v2]
In-Reply-To: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
Message-ID: <s5kZwYFz26u9Bwn9ykKCXDu_tLaQinwW2go4uSLCG-E=.e2154929-bbda-4104-b3f9-5517a831aa75@github.com>

> Please review changes to the IntlTest (test framework) class. 
> 
> These changes include
> - Logging the actual exception + stack trace. Previously, the test framework would throw `InvocationTargetException` but hide the actual underlying exception of the failing test unless the test class was ran with -nothrow.
> - Sorting the tests, ensuring for any given run, the tests are ran in the same order. (In [JDK-8305853](https://bugs.openjdk.org/browse/JDK-8305853) it was discovered that on Windows, the test framework would execute tests in a random order each time).
> - Improving output.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Revert changes that may affect extending test classes
 - Add back toHexString (used by some tests)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13655/files
  - new: https://git.openjdk.org/jdk/pull/13655/files/9ef1cc4f..e89740cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13655&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13655&range=00-01

  Stats: 22 lines in 1 file changed: 18 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13655/head:pull/13655

PR: https://git.openjdk.org/jdk/pull/13655

From psandoz at openjdk.org  Tue Apr 25 22:19:21 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 25 Apr 2023 22:19:21 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v24]
In-Reply-To: <znkZ0Yg1tP8eBeZuIer1NWrySNSJOM7EgZyIvIXsx3w=.fc4362ca-8148-4454-a7f0-7659c1f28d31@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <znkZ0Yg1tP8eBeZuIer1NWrySNSJOM7EgZyIvIXsx3w=.fc4362ca-8148-4454-a7f0-7659c1f28d31@github.com>
Message-ID: <WV95uunC4hU220NfOP2Jixh5Vb-Dm8a9l7vkYhukpqs=.252715e5-d55a-46d0-89d0-66ec8920a769@github.com>

On Wed, 19 Apr 2023 13:37:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> ### Specdiff
>> https://cr.openjdk.org/~pminborg/panama/21/v2/specdiff/overview-summary.html
>> 
>> ### Javadoc
>> https://cr.openjdk.org/~pminborg/panama/21/v2/javadoc/api/java.base/java/lang/foreign/package-summary.html
>> 
>> ### Tests
>> 
>> Testing excludes tests on the "zero" platform. 
>> 
>> - [X] Tier1
>> - [X] Tier2
>> - [X] Tier3
>> - [X] Tier4
>> - [X] Tier5
>> - [X] Tier6 (Except one test applications/jcstress/init.java as per below)
>> 
>> 
>> Exception in thread "main" java.lang.IllegalStateException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
>> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:66)
>> 	at org.openjdk.jcstress.vm.ContendedTestMain.main(ContendedTestMain.java:43)
>> Caused by: java.lang.ClassNotFoundException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
>> 	at java.base/java.lang.Class.forName0(Native Method)
>> 	at java.base/java.lang.Class.forName(Class.java:497)
>> 	at java.base/java.lang.Class.forName(Class.java:476)
>> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:64)
>> 	... 1 more
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
> 
>  - Merge branch 'master' into PR_21_V2
>  - Update test/jdk/java/foreign/TestByteBuffer.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
>    
>    rename has_port
>  - rename has_port
>  - Merge pull request #2 from JornVernee/WSL_BB
>    
>    account for missing functional in WSL in TestByteBuffer
>  - account for missing mincore on WSL in TestByteBuffer
>  - Merge branch 'master' into PR_21_V2
>  - 8305369: Issues in zero-length memory segment javadoc section
>  - 8305087: MemoryLayout API checks should be more eager
>  - Merge master
>  - ... and 32 more: https://git.openjdk.org/jdk/compare/9fb53adf...ba04f5cc

src/java.base/share/classes/jdk/internal/foreign/SlicingAllocator.java line 53:

> 51:     @Override
> 52:     public MemorySegment allocate(long byteSize, long byteAlignment) {
> 53:         Utils.checkAllocationSizeAndAlign(byteSize, byteAlignment);

`maxAlign` is no longer used

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1177117787

From darcy at openjdk.org  Tue Apr 25 22:49:36 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 25 Apr 2023 22:49:36 GMT
Subject: RFR: 8304918: Remove unused decl field from AnnotatedType
 implementations
In-Reply-To: <mthfNvWJWPmqLJjer7JidU-QYe9XwdcwJZDVW-5jSUo=.5056d0c3-72b3-4eae-a12c-d3af31f4e706@github.com>
References: <mthfNvWJWPmqLJjer7JidU-QYe9XwdcwJZDVW-5jSUo=.5056d0c3-72b3-4eae-a12c-d3af31f4e706@github.com>
Message-ID: <UdCSteeYv2WpzmNAyrPij_eHsV2Zu10iNXRPITGj-1Q=.75694a4a-9a53-47cf-8a4c-0472d6014358@github.com>

On Sat, 25 Mar 2023 05:52:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> In `AnnotatedTypeBaseImpl`, a `decl` field is declared, referring to the declaration that the AnnotatedType is from. However, this field is not used anywhere except passing to constructors of other implementations; it's not used in debug messages (unlike in `TypeAnnotation`), not involved in equality checks. Since these implementations are not serializable, we can safely remove the decl field from the implementations. All 1048 java/lang tests pass on my machine.

Marked as reviewed by darcy (Reviewer).

Catching up on reviews, doing a quick skim over the history, lack of use of the field seems to be present from the original work done under JDK-8004698 in JDK 8.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13183#pullrequestreview-1400856774
PR Comment: https://git.openjdk.org/jdk/pull/13183#issuecomment-1522504694

From psandoz at openjdk.org  Tue Apr 25 22:50:16 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 25 Apr 2023 22:50:16 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v24]
In-Reply-To: <znkZ0Yg1tP8eBeZuIer1NWrySNSJOM7EgZyIvIXsx3w=.fc4362ca-8148-4454-a7f0-7659c1f28d31@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <znkZ0Yg1tP8eBeZuIer1NWrySNSJOM7EgZyIvIXsx3w=.fc4362ca-8148-4454-a7f0-7659c1f28d31@github.com>
Message-ID: <trXO2_phDk4qIl9uzBPXbq7YnvOV8yc5HBnDrWlID9s=.e092cc48-df75-4371-a4a3-3c27d4d3cb7a@github.com>

On Wed, 19 Apr 2023 13:37:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> ### Specdiff
>> https://cr.openjdk.org/~pminborg/panama/21/v2/specdiff/overview-summary.html
>> 
>> ### Javadoc
>> https://cr.openjdk.org/~pminborg/panama/21/v2/javadoc/api/java.base/java/lang/foreign/package-summary.html
>> 
>> ### Tests
>> 
>> Testing excludes tests on the "zero" platform. 
>> 
>> - [X] Tier1
>> - [X] Tier2
>> - [X] Tier3
>> - [X] Tier4
>> - [X] Tier5
>> - [X] Tier6 (Except one test applications/jcstress/init.java as per below)
>> 
>> 
>> Exception in thread "main" java.lang.IllegalStateException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
>> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:66)
>> 	at org.openjdk.jcstress.vm.ContendedTestMain.main(ContendedTestMain.java:43)
>> Caused by: java.lang.ClassNotFoundException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
>> 	at java.base/java.lang.Class.forName0(Native Method)
>> 	at java.base/java.lang.Class.forName(Class.java:497)
>> 	at java.base/java.lang.Class.forName(Class.java:476)
>> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:64)
>> 	... 1 more
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
> 
>  - Merge branch 'master' into PR_21_V2
>  - Update test/jdk/java/foreign/TestByteBuffer.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
>    
>    rename has_port
>  - rename has_port
>  - Merge pull request #2 from JornVernee/WSL_BB
>    
>    account for missing functional in WSL in TestByteBuffer
>  - account for missing mincore on WSL in TestByteBuffer
>  - Merge branch 'master' into PR_21_V2
>  - 8305369: Issues in zero-length memory segment javadoc section
>  - 8305087: MemoryLayout API checks should be more eager
>  - Merge master
>  - ... and 32 more: https://git.openjdk.org/jdk/compare/9fb53adf...ba04f5cc

test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreBytes.java line 92:

> 90:       long byteAlignment = SPECIES.vectorByteSize();
> 91:       Arena scope = Arena.ofAuto();
> 92:       dstSegment = scope.allocate(size, byteAlignment);

Suggestion:

    srcSegment = Arena.ofAuto().allocate(size, SPECIES.vectorByteSize());
    dstSegment = Arena.ofAuto().allocate(size, SPECIES.vectorByteSize());

test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreShorts.java line 97:

> 95:       long byteAlignment = SPECIES.vectorByteSize();
> 96:       Arena scope = Arena.ofAuto();
> 97:       dstSegment = scope.allocate(size, byteAlignment);

Suggestion:

    srcSegment = Arena.ofAuto().allocate(size, SPECIES.vectorByteSize());
    dstSegment = Arena.ofAuto().allocate(size, SPECIES.vectorByteSize());

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1177131218
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1177131738

From naoto at openjdk.org  Tue Apr 25 23:01:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Apr 2023 23:01:15 GMT
Subject: RFR: 8306711: Improve diagnosis of `IntlTest` framework [v2]
In-Reply-To: <s5kZwYFz26u9Bwn9ykKCXDu_tLaQinwW2go4uSLCG-E=.e2154929-bbda-4104-b3f9-5517a831aa75@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
 <s5kZwYFz26u9Bwn9ykKCXDu_tLaQinwW2go4uSLCG-E=.e2154929-bbda-4104-b3f9-5517a831aa75@github.com>
Message-ID: <t-clxih2jqK_KQyxMlRha9NmC26cVJ02x_bcEzVH-Xo=.30babba9-a659-424b-a0ae-e8345514d6dd@github.com>

On Tue, 25 Apr 2023 22:08:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review changes to the IntlTest (test framework) class. 
>> 
>> These changes include
>> - Logging the actual exception + stack trace. Previously, the test framework would throw `InvocationTargetException` but hide the actual underlying exception of the failing test unless the test class was ran with -nothrow.
>> - Sorting the tests, ensuring for any given run, the tests are ran in the same order. (In [JDK-8305853](https://bugs.openjdk.org/browse/JDK-8305853) it was discovered that on Windows, the test framework would execute tests in a random order each time).
>> - Improving output.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert changes that may affect extending test classes
>  - Add back toHexString (used by some tests)

Looks good, with minor nits:

test/jdk/java/text/testlib/IntlTest.java line 84:

> 82:         for (Method testMethod : testsToRun) {
> 83:             int oldCount = errorCount;
> 84:             writeTestName(testMethod.getName());

Could cache the method name for later uses

test/jdk/java/text/testlib/IntlTest.java line 134:

> 132:         indentLevel--;
> 133:         writeTestResult(errorCount);
> 134: 

Would this mean the final result is only written with `nothrow` option?

test/jdk/java/text/testlib/IntlTest.java line 228:

> 226:     protected int getErrorCount() {
> 227:         return errorCount;
> 228:     }

No need to move the method

-------------

PR Review: https://git.openjdk.org/jdk/pull/13655#pullrequestreview-1400872160
PR Review Comment: https://git.openjdk.org/jdk/pull/13655#discussion_r1177142651
PR Review Comment: https://git.openjdk.org/jdk/pull/13655#discussion_r1177141497
PR Review Comment: https://git.openjdk.org/jdk/pull/13655#discussion_r1177142257

From liach at openjdk.org  Tue Apr 25 23:11:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Apr 2023 23:11:54 GMT
Subject: RFR: 8304918: Remove unused decl field from AnnotatedType
 implementations
In-Reply-To: <mthfNvWJWPmqLJjer7JidU-QYe9XwdcwJZDVW-5jSUo=.5056d0c3-72b3-4eae-a12c-d3af31f4e706@github.com>
References: <mthfNvWJWPmqLJjer7JidU-QYe9XwdcwJZDVW-5jSUo=.5056d0c3-72b3-4eae-a12c-d3af31f4e706@github.com>
Message-ID: <qs5coWw59D5E80xXPeBfQmUNb9-KmkzGfkKC1sorptI=.19c3280f-9e08-4967-9015-f671a1e8c0b2@github.com>

On Sat, 25 Mar 2023 05:52:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> In `AnnotatedTypeBaseImpl`, a `decl` field is declared, referring to the declaration that the AnnotatedType is from. However, this field is not used anywhere except passing to constructors of other implementations; it's not used in debug messages (unlike in `TypeAnnotation`), not involved in equality checks. Since these implementations are not serializable, we can safely remove the decl field from the implementations. All 1048 java/lang tests pass on my machine.

Thanks Joe Darcy. This will simplify another patch I am working on to fix some annotation mismatches within reflection.

In addition, `TypeAnnotation` has a `baseDecl` field that only serves for a momentary appearance in `toString`. Should that be removed as well?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13183#issuecomment-1522529351

From liach at openjdk.org  Tue Apr 25 23:26:48 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Apr 2023 23:26:48 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <TkQeA3b8WSjqMIuvew_kAIt-0MA1Ej0-11qLjVL4UkY=.7df7091c-6679-439d-a9ad-4989f700489c@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

@mlchung Sorry to bother, but since you are frequently working on the Constant API and the caching allowed by this patch allows the Classfile API to speed up significantly, can you review this patch and its associated CSR?

In particular, I wish that you can review in these perspectives:
1. Whether I should add a `boolean hasInternalName()` to check if the given class can be encoded in a `CONSTANT_Class_info`; currently it's equivalent to `!isPrimitive()`, but it might change when, for example, valhalla arrives.
2. Whether I should use a `@revised` tag on `ofInternalName`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1522538610

From liach at openjdk.org  Tue Apr 25 23:26:58 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Apr 2023 23:26:58 GMT
Subject: Integrated: 8304918: Remove unused decl field from AnnotatedType
 implementations
In-Reply-To: <mthfNvWJWPmqLJjer7JidU-QYe9XwdcwJZDVW-5jSUo=.5056d0c3-72b3-4eae-a12c-d3af31f4e706@github.com>
References: <mthfNvWJWPmqLJjer7JidU-QYe9XwdcwJZDVW-5jSUo=.5056d0c3-72b3-4eae-a12c-d3af31f4e706@github.com>
Message-ID: <rNo-JEfCRm9mUggDWn8TR2ccUKBO9Khlh34V0y_W9V8=.4d666d82-e8b9-4373-8623-95ddf6be80d2@github.com>

On Sat, 25 Mar 2023 05:52:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> In `AnnotatedTypeBaseImpl`, a `decl` field is declared, referring to the declaration that the AnnotatedType is from. However, this field is not used anywhere except passing to constructors of other implementations; it's not used in debug messages (unlike in `TypeAnnotation`), not involved in equality checks. Since these implementations are not serializable, we can safely remove the decl field from the implementations. All 1048 java/lang tests pass on my machine.

This pull request has now been integrated.

Changeset: adf62feb
Author:    Chen Liang <liach at openjdk.org>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/adf62febe6ccfd0b433588fe93fb6903848effbb
Stats:     52 lines in 2 files changed: 0 ins; 25 del; 27 mod

8304918: Remove unused decl field from AnnotatedType implementations

Reviewed-by: stsypanov, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/13183

From weijun at openjdk.org  Tue Apr 25 23:47:38 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Apr 2023 23:47:38 GMT
Subject: RFR: 8302182: Update Public Suffix List to 88467c9
Message-ID: <ltatey3heycqYvUR9eU0RI69QVATls7H-NwX7MWpi20=.478b64b2-3454-4815-9e84-35ec70727fe4@github.com>

Update PSL for JDK 21.

-------------

Commit messages:
 - the upgrade

Changes: https://git.openjdk.org/jdk/pull/13662/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13662&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302182
  Stats: 1479 lines in 5 files changed: 647 ins; 697 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/13662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13662/head:pull/13662

PR: https://git.openjdk.org/jdk/pull/13662

From mchung at openjdk.org  Tue Apr 25 23:49:32 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 25 Apr 2023 23:49:32 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <hB3oSnvi4SKz1FBoSaMnilBEsESWu0B4MzdRhpRHmI8=.bd53d0f4-f6c9-4b71-8aae-fd834caf43cc@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

You don't have to use `@revised` on the spec change.   `@revised` was used in 9 as it was useful to generate special pages for all the API changes by Project Jigsaw.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1522551740

From jlu at openjdk.org  Tue Apr 25 23:58:59 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 25 Apr 2023 23:58:59 GMT
Subject: RFR: 8306711: Improve diagnosis of `IntlTest` framework [v3]
In-Reply-To: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
Message-ID: <1jgAl-t9wzGNi3vuG9zDxsjAK3xyei8Chqrzt7DvRYg=.8f49fb5f-afdd-423f-9e22-078584b00433@github.com>

> Please review changes to the IntlTest (test framework) class. 
> 
> These changes include
> - Logging the actual exception + stack trace. Previously, the test framework would throw `InvocationTargetException` but hide the actual underlying exception of the failing test unless the test class was ran with -nothrow.
> - Sorting the tests, ensuring for any given run, the tests are ran in the same order. (In [JDK-8305853](https://bugs.openjdk.org/browse/JDK-8305853) it was discovered that on Windows, the test framework would execute tests in a random order each time).
> - Improving output.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Move getErrorCount() back to original spot
 - Regardles of nothrow, final result should be logged, cache, move method back

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13655/files
  - new: https://git.openjdk.org/jdk/pull/13655/files/e89740cc..a395ba67

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13655&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13655&range=01-02

  Stats: 22 lines in 1 file changed: 5 ins; 6 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13655/head:pull/13655

PR: https://git.openjdk.org/jdk/pull/13655

From jlu at openjdk.org  Wed Apr 26 00:09:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Apr 2023 00:09:54 GMT
Subject: RFR: 8306711: Improve diagnosis of `IntlTest` framework [v3]
In-Reply-To: <1jgAl-t9wzGNi3vuG9zDxsjAK3xyei8Chqrzt7DvRYg=.8f49fb5f-afdd-423f-9e22-078584b00433@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
 <1jgAl-t9wzGNi3vuG9zDxsjAK3xyei8Chqrzt7DvRYg=.8f49fb5f-afdd-423f-9e22-078584b00433@github.com>
Message-ID: <mfHN8qW2O-geCbegq8hR79LyVNYgyvREqLsWQ_fmheE=.7749e884-fe6f-45c5-99e8-805965ef5938@github.com>

On Tue, 25 Apr 2023 23:58:59 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review changes to the IntlTest (test framework) class. 
>> 
>> These changes include
>> - Logging the actual exception + stack trace. Previously, the test framework would throw `InvocationTargetException` but hide the actual underlying exception of the failing test unless the test class was ran with -nothrow.
>> - Sorting the tests, ensuring for any given run, the tests are ran in the same order. (In [JDK-8305853](https://bugs.openjdk.org/browse/JDK-8305853) it was discovered that on Windows, the test framework would execute tests in a random order each time).
>> - Improving output.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move getErrorCount() back to original spot
>  - Regardles of nothrow, final result should be logged, cache, move method back

test/jdk/java/text/testlib/IntlTest.java line 108:

> 106:             }
> 107:         }
> 108:         if (exitCode) {

@naotoj Since I got rid of `writeTestResult(errorCount);`

I will just have this block execute regardless of `nothrow`. All tests should now write the final result.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13655#discussion_r1177171469

From darcy at openjdk.org  Wed Apr 26 01:55:54 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 26 Apr 2023 01:55:54 GMT
Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow
In-Reply-To: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
References: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
Message-ID: <rsynWzA2MZRyUAuiPsnpwSTQV32u7NbQHd4jT8H_NrU=.987c8f96-f642-4426-bab3-6ec5c2d70257@github.com>

On Thu, 7 Jul 2022 15:20:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path.

src/java.base/share/classes/java/math/BigDecimal.java line 308:

> 306:     /*
> 307:      * Let l = log_2(10).
> 308:      * Then, L < l < L + ulp(L) / 2, that is, L = roundTiesToEven(l).

It doesn't matter in terms of the code, but shouldn't this be something like:

L - (ulp(L)) < l < L  ulp(L)

In other words, without further checking, it isn't clear that L is the lower-bound of the two double value bracketing l.

(If the ulp function being discussed were the real-valued version than L +/- ulp(l) would also be a reasonable formulation.)

src/java.base/share/classes/java/math/BigDecimal.java line 3749:

> 3747:      */
> 3748:     @Override
> 3749:     public float floatValue() {

If the total size of code were a concern, I wouldn't be adverse to floatValue() being implemented as

return (float)doubleValue();

Given the 2p+2 property between the float and double formats, BigDecimal -> double -> float and BigDecimal -> float round the same way.

src/java.base/share/classes/java/math/BigDecimal.java line 3777:

> 3775:             return 0.0f;
> 3776:         }
> 3777:         BigInteger d = unscaledValue().abs();

I'd prefer a name other than "d" be used for the BigInteger significand's magnitude.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/9410#discussion_r1177225652
PR Review Comment: https://git.openjdk.org/jdk/pull/9410#discussion_r1177230119
PR Review Comment: https://git.openjdk.org/jdk/pull/9410#discussion_r1177228393

From darcy at openjdk.org  Wed Apr 26 02:04:53 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 26 Apr 2023 02:04:53 GMT
Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow
In-Reply-To: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
References: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
Message-ID: <ZS4u28MV91FZqrdcEpThx6JEEN3xUewgmfFhP1Cvgto=.d1ef1a70-9b8f-4b13-b63f-bdd7e0ea0703@github.com>

On Thu, 7 Jul 2022 15:20:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/9410#pullrequestreview-1401024773

From liach at openjdk.org  Wed Apr 26 02:27:24 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Apr 2023 02:27:24 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v6]
In-Reply-To: <mymIMELoWKjb1QOQVTuiqnk6UnffOSDAJQh0gZwEbiI=.9fa59085-5491-4407-b769-eb85f1d164cc@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
 <t4rDpFxOgOT9g3bszBFIgwhVckcnYOOM1WH28tiz4o0=.63a24e17-922c-4ec4-ba61-afd3bcdbbbf1@github.com>
 <mymIMELoWKjb1QOQVTuiqnk6UnffOSDAJQh0gZwEbiI=.9fa59085-5491-4407-b769-eb85f1d164cc@github.com>
Message-ID: <XlHMqRU7TKEZf1qYCX8Uay08jCvqCbkNrXm1ZJNVSrI=.016f53ee-b254-4ad6-a176-7c4a284c2748@github.com>

On Mon, 20 Mar 2023 15:21:57 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Marked as reviewed by asotona (Committer).
>
>> @asotona So should I simply throw an `IllegalAccessError` when the Lookup encounters a `IllegalAccessException`, or should I return null? I favor throwing an `IllegalAccessError` as the lookup represents bytecode accessibility, and shall it fail to access, the generated bytecode will fail to access the specified superclass as well.
> 
> Yes, I also prefer throwing `IllegalAccessError` to directly indicate what is wrong instead of later indirect exceptions. I think `IllegalAccessError` is not a case for fallback resolver, so it should not be masked.

@asotona Just curious, what's the current state of our new API model of caching class hierarchy info in a Classfile context object as we've discussed on the mailing list? Will you create a patch, or should I update this patch to that model?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13082#issuecomment-1522664914

From ysatowse at openjdk.org  Wed Apr 26 03:03:58 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Wed, 26 Apr 2023 03:03:58 GMT
Subject: RFR: 8305505: NPE in javazic compiler [v2]
In-Reply-To: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
References: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
Message-ID: <plN7RPgpzoYMsyadgCTl6jBDKCuCuFmD4FxqWIWfm2U=.1786e964-5250-48a6-b4d3-e584752d7b88@github.com>

> Please review this PR.  
> With this minor change, the javazic compiler (Main.java) can produce the HTML files that display given time zone data correctly.

Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:

  Insert null check for mapList at its usage instead of initializing mapList

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13504/files
  - new: https://git.openjdk.org/jdk/pull/13504/files/2864658d..3d726b3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13504&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13504&range=00-01

  Stats: 23 lines in 1 file changed: 6 ins; 9 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13504.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13504/head:pull/13504

PR: https://git.openjdk.org/jdk/pull/13504

From amitkumar at openjdk.org  Wed Apr 26 03:11:24 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 26 Apr 2023 03:11:24 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2]
In-Reply-To: <gQh3oPGnoTNwchlzGmIfIiNpKCdHm8gi0TvGhdZuboA=.fbf1954e-61c7-4154-a434-49144f17c58b@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com>
 <-wkW0TuI0kpzf9WxyUjqcVWZ8Q1mHMCwrWpCcCvGIwM=.b2eb9493-d0d3-408b-aa7b-26bbae671914@github.com>
 <gQh3oPGnoTNwchlzGmIfIiNpKCdHm8gi0TvGhdZuboA=.fbf1954e-61c7-4154-a434-49144f17c58b@github.com>
Message-ID: <8swVOreS5lzKiXNVru2EjRYapJKazSLtKQUdLWFydFM=.45031878-402d-4b29-96aa-98a017c5ba5c@github.com>

On Tue, 7 Mar 2023 05:57:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> Finally, are you or someone in your team, in contact with the author(s) of the custom zlib implementation [iii-i/zlib at 1132034](https://github.com/iii-i/zlib/commit/113203437eda67261848b14b6c80a33ff7e33d34)? Would you be able to ask for their inputs on whether this (large?) difference in the deflated content size expected and are there any specific input (sizes) that this shows up or is it for all inputs?
>> 
>> This can happen for any poorly compressible inputs, regardless of their size. Here is the calculation for the worst case: https://github.com/iii-i/zlib/blob/dfltcc-20230109/contrib/s390/dfltcc.h#L17 (TL;DR: the size can double), but, of course, we don't expect this to be happening often.
>> 
>> Here are some benchmarking results: https://github.com/iii-i/zlib-ng/wiki/Performance-with-dfltcc-patch-applied-and-dfltcc-support-built-on-dfltcc-enabled-machine. The interesting data is in column `compressed_size` where `level` is 1. This is the hardware compressed size divided by the software compressed size. Most of the time it's +5-20%, in a few cases it compresses better than software, and only in one case (kennedy.xls) we see a big difference of +44%.
>> 
>> P.S. Here we are compressing random data, if I read the testcase correctly (`rnd.nextBytes(dataIn);`), so poor results are expected. Ideally we should emit stored blocks, but the hardware engine does not support this at the moment.
>
>> Here are some benchmarking results: https://github.com/iii-i/zlib-ng/wiki/Performance-with-dfltcc-patch-applied-and-dfltcc-support-built-on-dfltcc-enabled-machine. The interesting data is in column `compressed_size` where `level` is 1. This is the hardware compressed size divided by the software compressed size. Most of the time it's +5-20%, in a few cases it compresses better than software, and only in one case (kennedy.xls) we see a big difference of +44%.
>> 
>> P.S. Here we are compressing random data, if I read the testcase correctly (`rnd.nextBytes(dataIn);`), so poor results are expected. Ideally we should emit stored blocks, but the hardware engine does not support this at the moment.
> 
> Thank you Ilya, that was helpful in understanding the current behaviour of this custom zlib implementation.

Hi @jaikiran @AlanBateman 

please review it..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12283#issuecomment-1522702761

From liach at openjdk.org  Wed Apr 26 04:56:23 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Apr 2023 04:56:23 GMT
Subject: RFR: 8180892: Correct handling of annotations on parameters
Message-ID: <A5gWbMb6WLzQW2wbgC5USyPITDoslCEJKWCEO1IGOgs=.d89a8805-8e74-4e2f-8fcd-a4768c95ef7e@github.com>

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.

-------------

Commit messages:
 - copyright years
 - Complete ParameterMappingTest to take care of interested scenarios
 - Merge branch 'master' into param-implicit-mapping
 - test wip
 - Introduce base for annotated types if signature is absent but method parameters is present
 - simplify code with further contracts
 - Try map parameter content with modifier info

Changes: https://git.openjdk.org/jdk/pull/13664/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13664&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8180892
  Stats: 636 lines in 7 files changed: 548 ins; 57 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/13664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13664/head:pull/13664

PR: https://git.openjdk.org/jdk/pull/13664

From pminborg at openjdk.org  Wed Apr 26 06:29:53 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 26 Apr 2023 06:29:53 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v10]
In-Reply-To: <IxgwT4-WrCAAAzBEfOk6inLJI8rTBQcD6jq_DGpaPVw=.eb365f86-7a92-45be-9afe-abad692e6324@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <IxgwT4-WrCAAAzBEfOk6inLJI8rTBQcD6jq_DGpaPVw=.eb365f86-7a92-45be-9afe-abad692e6324@github.com>
Message-ID: <A2tmdroOslAavnDJA73dRP3gaBlWU1b_vv801f-KRPE=.9159a865-3d3c-4eb2-82ec-6e01da941c5e@github.com>

On Tue, 25 Apr 2023 19:43:29 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
>> 
>> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
>> 
>> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
>> 
>> Please review this pull request and attached CSR.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update ModuleDesc.java
>  - Update PackageDesc.java

Have we considered moving the Impl classes into a non-public area such as `jdk.internal` to improve encapsulation and reduce perceived footprint?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13615#issuecomment-1522847163

From pminborg at openjdk.org  Wed Apr 26 08:13:23 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 26 Apr 2023 08:13:23 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v25]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <SJec73ArMCjMLiRz8PtuyVxmFQ_wuLajLnsBKfXzogY=.1fe06142-f6a4-4916-8d7b-c51ebf985007@github.com>

> API changes for the FFM API (third preview)
> 
> ### Specdiff
> https://cr.openjdk.org/~pminborg/panama/21/v2/specdiff/overview-summary.html
> 
> ### Javadoc
> https://cr.openjdk.org/~pminborg/panama/21/v2/javadoc/api/java.base/java/lang/foreign/package-summary.html
> 
> ### Tests
> 
> Testing excludes tests on the "zero" platform. 
> 
> - [X] Tier1
> - [X] Tier2
> - [X] Tier3
> - [X] Tier4
> - [X] Tier5
> - [X] Tier6 (Except one test applications/jcstress/init.java as per below)
> 
> 
> Exception in thread "main" java.lang.IllegalStateException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:66)
> 	at org.openjdk.jcstress.vm.ContendedTestMain.main(ContendedTestMain.java:43)
> Caused by: java.lang.ClassNotFoundException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
> 	at java.base/java.lang.Class.forName0(Native Method)
> 	at java.base/java.lang.Class.forName(Class.java:497)
> 	at java.base/java.lang.Class.forName(Class.java:476)
> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:64)
> 	... 1 more

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  8306668: Some foreign tests fail on x86

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/ba04f5cc..fbd3520d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=23-24

  Stats: 9 lines in 3 files changed: 4 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From psandoz at openjdk.org  Wed Apr 26 08:14:23 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 26 Apr 2023 08:14:23 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v24]
In-Reply-To: <znkZ0Yg1tP8eBeZuIer1NWrySNSJOM7EgZyIvIXsx3w=.fc4362ca-8148-4454-a7f0-7659c1f28d31@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <znkZ0Yg1tP8eBeZuIer1NWrySNSJOM7EgZyIvIXsx3w=.fc4362ca-8148-4454-a7f0-7659c1f28d31@github.com>
Message-ID: <IRFRnnlzcIWVwJFhE0T7kIGix6gLMf3pVuzR_Hxy8us=.bedd421a-8eff-4ed3-bfe0-c8e575ad695c@github.com>

On Wed, 19 Apr 2023 13:37:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> ### Specdiff
>> https://cr.openjdk.org/~pminborg/panama/21/v2/specdiff/overview-summary.html
>> 
>> ### Javadoc
>> https://cr.openjdk.org/~pminborg/panama/21/v2/javadoc/api/java.base/java/lang/foreign/package-summary.html
>> 
>> ### Tests
>> 
>> Testing excludes tests on the "zero" platform. 
>> 
>> - [X] Tier1
>> - [X] Tier2
>> - [X] Tier3
>> - [X] Tier4
>> - [X] Tier5
>> - [X] Tier6 (Except one test applications/jcstress/init.java as per below)
>> 
>> 
>> Exception in thread "main" java.lang.IllegalStateException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
>> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:66)
>> 	at org.openjdk.jcstress.vm.ContendedTestMain.main(ContendedTestMain.java:43)
>> Caused by: java.lang.ClassNotFoundException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
>> 	at java.base/java.lang.Class.forName0(Native Method)
>> 	at java.base/java.lang.Class.forName(Class.java:497)
>> 	at java.base/java.lang.Class.forName(Class.java:476)
>> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:64)
>> 	... 1 more
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
> 
>  - Merge branch 'master' into PR_21_V2
>  - Update test/jdk/java/foreign/TestByteBuffer.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
>    
>    rename has_port
>  - rename has_port
>  - Merge pull request #2 from JornVernee/WSL_BB
>    
>    account for missing functional in WSL in TestByteBuffer
>  - account for missing mincore on WSL in TestByteBuffer
>  - Merge branch 'master' into PR_21_V2
>  - 8305369: Issues in zero-length memory segment javadoc section
>  - 8305087: MemoryLayout API checks should be more eager
>  - Merge master
>  - ... and 32 more: https://git.openjdk.org/jdk/compare/9fb53adf...ba04f5cc

Overall it looks very good. (Like for previous integration PRs feedback has been ongoing hence the lack of substantial comments here.)

I recommend before pushing to run through IntelliJ's problem list for all the source, as it will easily catch things like unused stuff that can be removed (its easier to suggest that rather than me adding as comments)

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13079#pullrequestreview-1400862474

From rgiulietti at openjdk.org  Wed Apr 26 08:16:53 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 26 Apr 2023 08:16:53 GMT
Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow
In-Reply-To: <rsynWzA2MZRyUAuiPsnpwSTQV32u7NbQHd4jT8H_NrU=.987c8f96-f642-4426-bab3-6ec5c2d70257@github.com>
References: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
 <rsynWzA2MZRyUAuiPsnpwSTQV32u7NbQHd4jT8H_NrU=.987c8f96-f642-4426-bab3-6ec5c2d70257@github.com>
Message-ID: <FLO7yzLmmLihUbeQRy2NSLeLjcy3L12tqN2l2nEmBg0=.d8b197e7-f10d-4aaf-8b88-6597e143794b@github.com>

On Wed, 26 Apr 2023 01:41:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path.
>
> src/java.base/share/classes/java/math/BigDecimal.java line 308:
> 
>> 306:     /*
>> 307:      * Let l = log_2(10).
>> 308:      * Then, L < l < L + ulp(L) / 2, that is, L = roundTiesToEven(l).
> 
> It doesn't matter in terms of the code, but shouldn't this be something like:
> 
> L - (ulp(L)) < l < L  ulp(L)
> 
> In other words, without further checking, it isn't clear that L is the lower-bound of the two double value bracketing l.
> 
> (If the ulp function being discussed were the real-valued version than L +/- ulp(l) would also be a reasonable formulation.)

While it isn't obvious from the definition, high precision computations reveal that the inequalities `L < l < L + ulp(L) / 2` do indeed hold.
But as noted, this is not really relevant for the rest of the analysis.

> src/java.base/share/classes/java/math/BigDecimal.java line 3777:
> 
>> 3775:             return 0.0f;
>> 3776:         }
>> 3777:         BigInteger d = unscaledValue().abs();
> 
> I'd prefer a name other than "d" be used for the BigInteger significand's magnitude.

I have no objections as long as it is a 1 letter name that does not conflict with others.
Have you a preferred one?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/9410#discussion_r1177496610
PR Review Comment: https://git.openjdk.org/jdk/pull/9410#discussion_r1177500421

From pminborg at openjdk.org  Wed Apr 26 08:36:54 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 26 Apr 2023 08:36:54 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v26]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <-2b0YArLgBN3m5koQm5-irDhQkMPTm618hYadF7AjnQ=.09cfa772-05a6-49cf-9106-ea8698aa452b@github.com>

> API changes for the FFM API (third preview)
> 
> ### Specdiff
> https://cr.openjdk.org/~pminborg/panama/21/v2/specdiff/overview-summary.html
> 
> ### Javadoc
> https://cr.openjdk.org/~pminborg/panama/21/v2/javadoc/api/java.base/java/lang/foreign/package-summary.html
> 
> ### Tests
> 
> Testing excludes tests on the "zero" platform. 
> 
> - [X] Tier1
> - [X] Tier2
> - [X] Tier3
> - [X] Tier4
> - [X] Tier5
> - [X] Tier6 (Except one test applications/jcstress/init.java as per below)
> 
> 
> Exception in thread "main" java.lang.IllegalStateException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:66)
> 	at org.openjdk.jcstress.vm.ContendedTestMain.main(ContendedTestMain.java:43)
> Caused by: java.lang.ClassNotFoundException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
> 	at java.base/java.lang.Class.forName0(Native Method)
> 	at java.base/java.lang.Class.forName(Class.java:497)
> 	at java.base/java.lang.Class.forName(Class.java:476)
> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:64)
> 	... 1 more

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/foreign/Linker.java
  
  Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/fbd3520d..b18d44c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=24-25

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From rgiulietti at openjdk.org  Wed Apr 26 08:41:26 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 26 Apr 2023 08:41:26 GMT
Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow
In-Reply-To: <rsynWzA2MZRyUAuiPsnpwSTQV32u7NbQHd4jT8H_NrU=.987c8f96-f642-4426-bab3-6ec5c2d70257@github.com>
References: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
 <rsynWzA2MZRyUAuiPsnpwSTQV32u7NbQHd4jT8H_NrU=.987c8f96-f642-4426-bab3-6ec5c2d70257@github.com>
Message-ID: <-Ka50CkYea3uaNa6zD0ib8vOhQsb2iua034WP76-m8A=.9fecfae8-a00f-4ae1-94e2-8c8ea19c8474@github.com>

On Wed, 26 Apr 2023 01:47:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path.
>
> src/java.base/share/classes/java/math/BigDecimal.java line 3749:
> 
>> 3747:      */
>> 3748:     @Override
>> 3749:     public float floatValue() {
> 
> If the total size of code were a concern, I wouldn't be adverse to floatValue() being implemented as
> 
> return (float)doubleValue();
> 
> Given the 2p+2 property between the float and double formats, BigDecimal -> double -> float and BigDecimal -> float round the same way.

No, that would not be correct. It would be subject to [double rounding](https://en.wikipedia.org/wiki/Rounding#Double_rounding), against the spec.

For example, `BigDecimal` 1.000000059604644775390626 should round to `float` `1.0000001f`.
When going to the closest `double` and then to the closest `float`, however, it first rounds to `double` `1.0000000596046448` and the to `float` `1.0f`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/9410#discussion_r1177530816

From pminborg at openjdk.org  Wed Apr 26 08:53:53 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 26 Apr 2023 08:53:53 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v27]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <OsXNhgapNFiMsrZK4pbldkcC6AD6cKZ4Y3FrTwPtcR8=.426bda28-465b-4f79-be7d-00f5129d67d5@github.com>

> API changes for the FFM API (third preview)
> 
> ### Specdiff
> https://cr.openjdk.org/~pminborg/panama/21/v2/specdiff/overview-summary.html
> 
> ### Javadoc
> https://cr.openjdk.org/~pminborg/panama/21/v2/javadoc/api/java.base/java/lang/foreign/package-summary.html
> 
> ### Tests
> 
> Testing excludes tests on the "zero" platform. 
> 
> - [X] Tier1
> - [X] Tier2
> - [X] Tier3
> - [X] Tier4
> - [X] Tier5
> - [X] Tier6 (Except one test applications/jcstress/init.java as per below)
> 
> 
> Exception in thread "main" java.lang.IllegalStateException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:66)
> 	at org.openjdk.jcstress.vm.ContendedTestMain.main(ContendedTestMain.java:43)
> Caused by: java.lang.ClassNotFoundException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
> 	at java.base/java.lang.Class.forName0(Native Method)
> 	at java.base/java.lang.Class.forName(Class.java:497)
> 	at java.base/java.lang.Class.forName(Class.java:476)
> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:64)
> 	... 1 more

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Update test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreShorts.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreBytes.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/b18d44c7..228d4c68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=25-26

  Stats: 12 lines in 2 files changed: 0 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Wed Apr 26 09:46:53 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 26 Apr 2023 09:46:53 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v28]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <IuYuSdA3MJiGq3qkhyzJfy7-I80_yxlCql0aw97XTrE=.2d85b113-b728-46ed-b686-b10e6dbfb6fa@github.com>

> API changes for the FFM API (third preview)
> 
> ### Specdiff
> https://cr.openjdk.org/~pminborg/panama/21/v2/specdiff/overview-summary.html
> 
> ### Javadoc
> https://cr.openjdk.org/~pminborg/panama/21/v2/javadoc/api/java.base/java/lang/foreign/package-summary.html
> 
> ### Tests
> 
> Testing excludes tests on the "zero" platform. 
> 
> - [X] Tier1
> - [X] Tier2
> - [X] Tier3
> - [X] Tier4
> - [X] Tier5
> - [X] Tier6 (Except one test applications/jcstress/init.java as per below)
> 
> 
> Exception in thread "main" java.lang.IllegalStateException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:66)
> 	at org.openjdk.jcstress.vm.ContendedTestMain.main(ContendedTestMain.java:43)
> Caused by: java.lang.ClassNotFoundException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
> 	at java.base/java.lang.Class.forName0(Native Method)
> 	at java.base/java.lang.Class.forName(Class.java:497)
> 	at java.base/java.lang.Class.forName(Class.java:476)
> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:64)
> 	... 1 more

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Use pattern maching in for-loop

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/228d4c68..8393218c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=26-27

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From sspitsyn at openjdk.org  Wed Apr 26 09:49:54 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 26 Apr 2023 09:49:54 GMT
Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when
 using an OutputAnalyzer at the same time
In-Reply-To: <jbN1idusRU1wUiQ265HUUCyjb2eh8uSC4MDn5igYyy8=.ae64e31f-8c57-415e-8a21-ca7f0e8a6410@github.com>
References: <jbN1idusRU1wUiQ265HUUCyjb2eh8uSC4MDn5igYyy8=.ae64e31f-8c57-415e-8a21-ca7f0e8a6410@github.com>
Message-ID: <e87ZoaVketLxv_y0lsqUNCQOp6AookUK57m1yZW3dwc=.929bb1c0-dc82-45de-b41a-4f3b4989f697@github.com>

On Fri, 21 Apr 2023 21:43:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams.
> 
> This fix preserve process streams content and allow to read reuse the date. The ByteArrayOutputStream is used as a buffer. 
> It stores all process output, never trying to clean date which has been read. 
> 
> The regression test has been provided with issue.
> 
> I closed previous PR https://github.com/openjdk/jdk/pull/13560 by mistake instead of updating it.
> 
> I run all tests to ensure that no failures are introduced.

Looks good. Posted a few minor comments.
Thanks,
Serguei

test/lib/jdk/test/lib/process/ProcessTools.java line 170:

> 168:         }
> 169: 
> 170:         synchronized  int readNext() {

An extra space after synchronized keyword.

test/lib/jdk/test/lib/process/ProcessTools.java line 172:

> 170:         synchronized  int readNext() {
> 171:             if (current > count) {
> 172:                 throw new RuntimeException("Shouldn't ever happen.  start: " + current + " count: " + count + " buffer: " + this);

This line is too long.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13594#pullrequestreview-1401596190
PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1177621994
PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1177622644

From sspitsyn at openjdk.org  Wed Apr 26 09:50:54 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 26 Apr 2023 09:50:54 GMT
Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when
 using an OutputAnalyzer at the same time
In-Reply-To: <6ABDu4g-9JNwmdQpdmOXIbz6WUApspGnmHlMk7BhZ6I=.d11f2bc4-c895-4162-9b35-9f2a0d7be519@github.com>
References: <jbN1idusRU1wUiQ265HUUCyjb2eh8uSC4MDn5igYyy8=.ae64e31f-8c57-415e-8a21-ca7f0e8a6410@github.com>
 <4EDhpXuaKhviIcVGoDrPbVzcdze_pl4rJZu6DQvWeAw=.f5a9a485-3bb2-4f2b-8b65-e3d35eae1001@github.com>
 <OjLsgMRUFYZUmjzdta-q2Zj-rKGmKfPB2WqnWjYiuHk=.aabde9bc-d5d2-43cf-9d67-8c7dec5c682a@github.com>
 <6ABDu4g-9JNwmdQpdmOXIbz6WUApspGnmHlMk7BhZ6I=.d11f2bc4-c895-4162-9b35-9f2a0d7be519@github.com>
Message-ID: <7uK1GxdtnB1b_D1bA6Kq8dwnMZw3x3xLKkYDmGibWzc=.7006d521-7b82-4f1e-bdc9-cb23edde89b7@github.com>

On Tue, 25 Apr 2023 15:50:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Agree, it is confusing, even in standard j.l.Process API . The `InputStream java.lang.Process.getInputStream()`" returns **output** stream of started process.  So for our implementation ProcessImpl the 'out' and 'err' mean output and error streams. However they are returned as InputStreams so users could read them.
>
> Right. From the API caller's POV, it is asking for InputStreams that it can use to read the process' stdout or stderr streams.

Okay, thanks.
I'm thinking about simple/short comments on this to make it clear this naming mismatch is intentional.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1177619710

From fyang at openjdk.org  Wed Apr 26 09:51:56 2023
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 26 Apr 2023 09:51:56 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <hw0KAH255Qgpaf9TWe72S7DBFDPLju7BjAZo6Cnh7q0=.e4ce764d-37db-40c4-83bf-96705c0c80a1@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
 <hw0KAH255Qgpaf9TWe72S7DBFDPLju7BjAZo6Cnh7q0=.e4ce764d-37db-40c4-83bf-96705c0c80a1@github.com>
Message-ID: <Qn9Hre_KMctMgNkLBWe5Zzc4lKN2vN1mknxh3Bc07nM=.798970d3-4c31-4944-b569-11c42e1b020a@github.com>

On Tue, 21 Mar 2023 13:35:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> A review of all the copyright years shall be made in this PR.

@minborg : Hello, I think you should list Feilong Jiang (OpenJDK ID: fjiang) as co-author instead. It is him who added code for the riscv port.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13079#issuecomment-1523097913

From asotona at openjdk.org  Wed Apr 26 10:00:23 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 26 Apr 2023 10:00:23 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v6]
In-Reply-To: <mymIMELoWKjb1QOQVTuiqnk6UnffOSDAJQh0gZwEbiI=.9fa59085-5491-4407-b769-eb85f1d164cc@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
 <t4rDpFxOgOT9g3bszBFIgwhVckcnYOOM1WH28tiz4o0=.63a24e17-922c-4ec4-ba61-afd3bcdbbbf1@github.com>
 <mymIMELoWKjb1QOQVTuiqnk6UnffOSDAJQh0gZwEbiI=.9fa59085-5491-4407-b769-eb85f1d164cc@github.com>
Message-ID: <SEhvgO08a8oYqgBOdzJKuYMe4z_0oWsM-VqYy_9x-80=.110e6a6f-c52b-4851-ae5f-f6ecb93828c0@github.com>

On Mon, 20 Mar 2023 15:21:57 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Marked as reviewed by asotona (Committer).
>
>> @asotona So should I simply throw an `IllegalAccessError` when the Lookup encounters a `IllegalAccessException`, or should I return null? I favor throwing an `IllegalAccessError` as the lookup represents bytecode accessibility, and shall it fail to access, the generated bytecode will fail to access the specified superclass as well.
> 
> Yes, I also prefer throwing `IllegalAccessError` to directly indicate what is wrong instead of later indirect exceptions. I think `IllegalAccessError` is not a case for fallback resolver, so it should not be masked.

> @asotona Just curious, what's the current state of our new API model of caching class hierarchy info in a Classfile context object as we've discussed on the mailing list? Will you create a patch, or should I update this patch to that model?

In the discussion I tried to fine-tune exact naming of the factory methods and the default. Mainly to differentiate when the class is parsed as a resource `ofResourceParsing(ClassLoader loader)` and  when it is loaded `ofClassLoading(ClassLoader loader)`

Otherwise this patch looks good.

The other part of the discussion with proposed `ClassfileReaderWriter` model is out of the scope of this topic, it has much bigger impact on all existing code and I would deferred it at least until this and other open PRs are merged.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13082#issuecomment-1523118391

From asotona at openjdk.org  Wed Apr 26 10:10:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 26 Apr 2023 10:10:59 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v10]
In-Reply-To: <INN62jwHvhzl4v11FXFNGYJH0n7aHw89LxHjkcqt2xQ=.75b5771c-1d13-4c65-80d5-aa3106447030@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <IxgwT4-WrCAAAzBEfOk6inLJI8rTBQcD6jq_DGpaPVw=.eb365f86-7a92-45be-9afe-abad692e6324@github.com>
 <INN62jwHvhzl4v11FXFNGYJH0n7aHw89LxHjkcqt2xQ=.75b5771c-1d13-4c65-80d5-aa3106447030@github.com>
Message-ID: <4DB4q6gWf9UfjCDlCU_CEKEaGtd9DLts_TiQpConTIU=.0f584ec2-b078-4222-986e-737d5225ffd8@github.com>

On Tue, 25 Apr 2023 21:45:57 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update ModuleDesc.java
>>  - Update PackageDesc.java
>
> src/java.base/share/classes/java/lang/constant/ModuleDesc.java line 32:
> 
>> 30:  * A nominal descriptor for a {@code Module} constant.
>> 31:  *
>> 32:  * @apiNote
> 
> can drop `@apiNote` as it's not needed to be.  `<p>` if you want to a new paragraph.

Set back to `<p>` as suggested, thanks.

> src/java.base/share/classes/java/lang/constant/PackageDesc.java line 32:
> 
>> 30:  * A nominal descriptor for a {@code Package} constant.
>> 31:  *
>> 32:  * @apiNote
> 
> can drop `@apiNote` as it's not needed to be. `<p>` if you want to a new paragraph.

Set back to `<p>` as suggested, thanks.

> src/java.base/share/classes/java/lang/constant/PackageDesc.java line 70:
> 
>> 68:      * @throws IllegalArgumentException if the name string is not in the
>> 69:      * correct format
>> 70:      * @jvms 4.2.1 Binary Class and Interface Names
> 
> Worth adding `@jvm 4.2.3 Module and Package Names`

Added, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1177640205
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1177639109
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1177639506

From asotona at openjdk.org  Wed Apr 26 10:09:53 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 26 Apr 2023 10:09:53 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v11]
In-Reply-To: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
Message-ID: <3zs0YuZVRhP97FzHxnvj8GcU5xy-y3DhWZIfSrjjVXQ=.4bbce6c9-4318-4e56-9d38-dfad085c6f05@github.com>

> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
> 
> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
> 
> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
> 
> Please review this pull request and attached CSR.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - Update ModuleDesc.java
 - Apply suggestions from code review
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13615/files
  - new: https://git.openjdk.org/jdk/pull/13615/files/b37a2394..11c054b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=09-10

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13615/head:pull/13615

PR: https://git.openjdk.org/jdk/pull/13615

From pminborg at openjdk.org  Wed Apr 26 10:20:53 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 26 Apr 2023 10:20:53 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v29]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <jwIS6GDiaOnjyKj8-_zAzRoZo1F_XpNjd7-56EaPTRk=.543cc12b-785d-4b12-bc06-e5ec9b70e207@github.com>

> API changes for the FFM API (third preview)
> 
> ### Specdiff
> https://cr.openjdk.org/~pminborg/panama/21/v2/specdiff/overview-summary.html
> 
> ### Javadoc
> https://cr.openjdk.org/~pminborg/panama/21/v2/javadoc/api/java.base/java/lang/foreign/package-summary.html
> 
> ### Tests
> 
> Testing excludes tests on the "zero" platform. 
> 
> - [X] Tier1
> - [X] Tier2
> - [X] Tier3
> - [X] Tier4
> - [X] Tier5
> - [X] Tier6 (Except one test applications/jcstress/init.java as per below)
> 
> 
> Exception in thread "main" java.lang.IllegalStateException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:66)
> 	at org.openjdk.jcstress.vm.ContendedTestMain.main(ContendedTestMain.java:43)
> Caused by: java.lang.ClassNotFoundException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
> 	at java.base/java.lang.Class.forName0(Native Method)
> 	at java.base/java.lang.Class.forName(Class.java:497)
> 	at java.base/java.lang.Class.forName(Class.java:476)
> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:64)
> 	... 1 more

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:

 - Merge branch 'master' into PR_21_V2
 - Use pattern maching in for-loop
 - Update test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreShorts.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreBytes.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update src/java.base/share/classes/java/lang/foreign/Linker.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - 8306668: Some foreign tests fail on x86
 - Merge branch 'master' into PR_21_V2
 - Update test/jdk/java/foreign/TestByteBuffer.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
   
   rename has_port
 - rename has_port
 - ... and 38 more: https://git.openjdk.org/jdk/compare/d7476982...0365fcf2

-------------

Changes: https://git.openjdk.org/jdk/pull/13079/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=28
  Stats: 13420 lines in 270 files changed: 5100 ins; 6182 del; 2138 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From asotona at openjdk.org  Wed Apr 26 10:23:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 26 Apr 2023 10:23:58 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v12]
In-Reply-To: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
Message-ID: <SyXCe07ITekbqx2QitCyn12kmF_Y6wUQ8E9gUyokZXo=.710b028b-a994-4520-84e7-a293f0ea3ae7@github.com>

> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
> 
> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
> 
> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
> 
> Please review this pull request and attached CSR.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update PackageDesc.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13615/files
  - new: https://git.openjdk.org/jdk/pull/13615/files/11c054b3..ca91db48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=10-11

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13615/head:pull/13615

PR: https://git.openjdk.org/jdk/pull/13615

From asotona at openjdk.org  Wed Apr 26 10:28:02 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 26 Apr 2023 10:28:02 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v10]
In-Reply-To: <INN62jwHvhzl4v11FXFNGYJH0n7aHw89LxHjkcqt2xQ=.75b5771c-1d13-4c65-80d5-aa3106447030@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <IxgwT4-WrCAAAzBEfOk6inLJI8rTBQcD6jq_DGpaPVw=.eb365f86-7a92-45be-9afe-abad692e6324@github.com>
 <INN62jwHvhzl4v11FXFNGYJH0n7aHw89LxHjkcqt2xQ=.75b5771c-1d13-4c65-80d5-aa3106447030@github.com>
Message-ID: <b2edwnj07raSD90nv85e1ctszoZU1yDdblWTg4sO3wU=.a3614c28-0f6d-4316-8642-97e690c30ebf@github.com>

On Tue, 25 Apr 2023 21:53:44 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I wonder if `packageName()` and `packageInternalName()` methods can simply be `name()` and `internalName()` as the type name is `PackageDesc` and `package` prefix seems to be unnecessary. Similarly, `moduleName()` can be `name()`. Have this be discussed and rejected?

I've searched the history of Classfile API discussions and it actually wasn't discussed.
I agree the prefix is unnecessary. 
Thanks for pointing it out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13615#issuecomment-1523166326

From asotona at openjdk.org  Wed Apr 26 10:46:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 26 Apr 2023 10:46:24 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v13]
In-Reply-To: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
Message-ID: <5nw09YhnRegFOv-IqMqQIyz1CTNRQ4EKKdDQcDGx_zg=.0a148355-4968-468a-af01-e97fe5884782@github.com>

> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
> 
> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
> 
> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
> 
> Please review this pull request and attached CSR.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  removed prefixes from name methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13615/files
  - new: https://git.openjdk.org/jdk/pull/13615/files/ca91db48..efab745b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=11-12

  Stats: 12 lines in 4 files changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/13615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13615/head:pull/13615

PR: https://git.openjdk.org/jdk/pull/13615

From jpai at openjdk.org  Wed Apr 26 11:12:23 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Apr 2023 11:12:23 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v3]
In-Reply-To: <1VOiJqfV7MR0h3qtLDOK6JjmSAiWP8cTOcXP9ZW0nTY=.79b86cdb-ad4f-4c0b-9010-43d385427a28@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <1VOiJqfV7MR0h3qtLDOK6JjmSAiWP8cTOcXP9ZW0nTY=.79b86cdb-ad4f-4c0b-9010-43d385427a28@github.com>
Message-ID: <x6e65H3xyf0zWV2kNumNAzVqkj6vjIx0aZjVENf41lw=.ab13aaee-cb71-4089-96e3-870c5de56c05@github.com>

On Thu, 30 Mar 2023 03:06:51 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390).
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removes out1,out2 parameters

Marked as reviewed by jpai (Reviewer).

Hello Amit, I had a look at the latest state of this PR, commit `bce8989275`. 

What this change does is that it updates the `check` method in the `DeInflate` test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying `zlib` implementations. The updated `check` method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. The final inflated data is then compared against the original input and asserted that it's the same (this part hasn't changed in this PR). These changes look fine to me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/12283#pullrequestreview-1401722800
PR Comment: https://git.openjdk.org/jdk/pull/12283#issuecomment-1523218435

From amitkumar at openjdk.org  Wed Apr 26 11:13:23 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 26 Apr 2023 11:13:23 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v3]
In-Reply-To: <x6e65H3xyf0zWV2kNumNAzVqkj6vjIx0aZjVENf41lw=.ab13aaee-cb71-4089-96e3-870c5de56c05@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <1VOiJqfV7MR0h3qtLDOK6JjmSAiWP8cTOcXP9ZW0nTY=.79b86cdb-ad4f-4c0b-9010-43d385427a28@github.com>
 <x6e65H3xyf0zWV2kNumNAzVqkj6vjIx0aZjVENf41lw=.ab13aaee-cb71-4089-96e3-870c5de56c05@github.com>
Message-ID: <gUQIca1xTbWTOTM2E5REIrIlFI2UVxX4h4IlZ_9xCFA=.7bdee763-13ce-40dc-862d-ac32bc2faf86@github.com>

On Wed, 26 Apr 2023 10:53:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> These changes look fine to me.

Thanks @jaikiran for review and explanation. I'll update the PR description ?. 

BTW these are not hotspot changes, So do we need 2 Reviewer for these as well ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12283#issuecomment-1523226887

From jpai at openjdk.org  Wed Apr 26 11:22:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Apr 2023 11:22:54 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v3]
In-Reply-To: <1VOiJqfV7MR0h3qtLDOK6JjmSAiWP8cTOcXP9ZW0nTY=.79b86cdb-ad4f-4c0b-9010-43d385427a28@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <1VOiJqfV7MR0h3qtLDOK6JjmSAiWP8cTOcXP9ZW0nTY=.79b86cdb-ad4f-4c0b-9010-43d385427a28@github.com>
Message-ID: <FLoxo9Dn3CEGnktAYlSIlqfcGX6kSAGm0XFroYxn3O8=.58f2f0b0-5217-412d-be48-4dbf6eba0772@github.com>

On Thu, 30 Mar 2023 03:06:51 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
>> 
>> Thanks to @jaikiran for amazing PR description.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removes out1,out2 parameters

It's my understanding that this area doesn't have a 2 reviewer rule. I understand that you have waited several weeks for inputs, thank you for that. If you could wait for one more day for Lance or Alan, who are more knowledgable in this area, to have a look at this, then that would be wonderful. If I see no objections by then, I can sponsor this for you tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12283#issuecomment-1523241586

From simonis at openjdk.org  Wed Apr 26 11:55:23 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 26 Apr 2023 11:55:23 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v3]
In-Reply-To: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
Message-ID: <oJ8ZXUlfXgCGsf2GUdqu9lqihPWAP9-L1JslWzGmc0s=.cbf6ded7-1c9e-4425-a570-ff3be20c8eda@github.com>

> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
> 
> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
> 
> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
> 
> Returns:
> the non-negative number of array elements when deserializing an array of the class, otherwise -1
> 
> but currently returns a negative value if the array length is negative.

Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into JDK-8306461
 - Simplified exception message and fixed test to check the correct message
 - Addresed review comments of @turbanoff, @shipilev and @RogerRiggs
 - 8306461: ObjectInputStream::readObject() should handle negative array sizes without throwing NegativeArraySizeExceptions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13540/files
  - new: https://git.openjdk.org/jdk/pull/13540/files/f242dca2..4bc579e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13540&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13540&range=01-02

  Stats: 32136 lines in 503 files changed: 25989 ins; 4332 del; 1815 mod
  Patch: https://git.openjdk.org/jdk/pull/13540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13540/head:pull/13540

PR: https://git.openjdk.org/jdk/pull/13540

From shade at openjdk.org  Wed Apr 26 11:55:24 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Apr 2023 11:55:24 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v3]
In-Reply-To: <oJ8ZXUlfXgCGsf2GUdqu9lqihPWAP9-L1JslWzGmc0s=.cbf6ded7-1c9e-4425-a570-ff3be20c8eda@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <oJ8ZXUlfXgCGsf2GUdqu9lqihPWAP9-L1JslWzGmc0s=.cbf6ded7-1c9e-4425-a570-ff3be20c8eda@github.com>
Message-ID: <2c2RiAC0de3mfc50r_NAvIwbQzqgMi-W2qMmd6rQzss=.11b1dfd5-1274-4755-b287-3c5a1a420c1c@github.com>

On Wed, 26 Apr 2023 11:37:23 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8306461
>  - Simplified exception message and fixed test to check the correct message
>  - Addresed review comments of @turbanoff, @shipilev and @RogerRiggs
>  - 8306461: ObjectInputStream::readObject() should handle negative array sizes without throwing NegativeArraySizeExceptions

Looks fine to me.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13540#pullrequestreview-1401786764

From simonis at openjdk.org  Wed Apr 26 11:56:24 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 26 Apr 2023 11:56:24 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v2]
In-Reply-To: <1yryY7OILSrnZbzlAUddYNA1s7XgnJRpZqt6abZqKzw=.599138e6-e002-404d-a534-0d017ba0c86c@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <EcquNmlW2gNL6XeesD60LIJAUGnpZuDcegRczIGsGZ8=.6649cc69-4392-47a1-ac23-8d70b38b3fdd@github.com>
 <a24W0ATdimi_sDufP2ozdW66xyopfuG6Bq1z-ukuA_Y=.9879da5d-5ab1-4b9d-86d7-31690e74ce84@github.com>
 <1yryY7OILSrnZbzlAUddYNA1s7XgnJRpZqt6abZqKzw=.599138e6-e002-404d-a534-0d017ba0c86c@github.com>
Message-ID: <Cml0H8BLicoDrZEHwL3tcWGc_vUOXOTZZHE4cQIB6y4=.4f8ec390-f153-4e2a-bba8-447dfa62b434@github.com>

On Tue, 25 Apr 2023 21:01:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 88:
>> 
>>> 86:         } catch (ObjectStreamException ose) {
>>> 87:             // OK, because a NegativeArraySizeException should be converted into a ObjectStreamException
>>> 88:             if ("Array length is negative".equals(ose.getMessage())) {
>> 
>> This feels like `!equals`, i.e. throw exception when the message is *not* "Array length is negative"?
>
> The complete `getMessage()` is `[Ljava.lang.String;; Array length is negative`.
> Perhaps: 
> 
> ose.getMessage().contains("Array length is negative") ...

Your right. @RogerRiggs  I've further simplified the exception message to only contain the message "Array length is negative". I hope that's fine for you and in line with your previous comment to "*keep the exception logic simple/minimal*".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1177751891

From simonis at openjdk.org  Wed Apr 26 11:56:55 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 26 Apr 2023 11:56:55 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v2]
In-Reply-To: <a24W0ATdimi_sDufP2ozdW66xyopfuG6Bq1z-ukuA_Y=.9879da5d-5ab1-4b9d-86d7-31690e74ce84@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <EcquNmlW2gNL6XeesD60LIJAUGnpZuDcegRczIGsGZ8=.6649cc69-4392-47a1-ac23-8d70b38b3fdd@github.com>
 <a24W0ATdimi_sDufP2ozdW66xyopfuG6Bq1z-ukuA_Y=.9879da5d-5ab1-4b9d-86d7-31690e74ce84@github.com>
Message-ID: <WyaRAjUUuIy64E0V0K70FcEcmyXqRxj-dUhVyTtgm70=.959e29b4-9d2e-47ec-9554-896eab3d0cdb@github.com>

On Mon, 24 Apr 2023 15:58:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addresed review comments of @turbanoff, @shipilev and @RogerRiggs
>
> test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 104:
> 
>> 102:             }
>> 103:             // OK, because a NegativeArraySizeException should be converted into a ObjectStreamException *before* filtering
>> 104:             if ("Array length is negative".equals(ose.getMessage())) {
> 
> Same as above.

Obviously!

Good catch. The problem was that the exception message also contained the name of the array class that's why *it worked*. I've now simplified to only contain the message "Array length is negative" which I think is in line with Roger'S previous comment to "*keep the exception logic simple/minimal*".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1177749681

From rriggs at openjdk.org  Wed Apr 26 13:03:23 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 26 Apr 2023 13:03:23 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v3]
In-Reply-To: <oJ8ZXUlfXgCGsf2GUdqu9lqihPWAP9-L1JslWzGmc0s=.cbf6ded7-1c9e-4425-a570-ff3be20c8eda@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <oJ8ZXUlfXgCGsf2GUdqu9lqihPWAP9-L1JslWzGmc0s=.cbf6ded7-1c9e-4425-a570-ff3be20c8eda@github.com>
Message-ID: <uR_pQqxD1LklDBWG8214aqtUmCyVscGPXfSOMTusLOs=.9e6a99d2-a094-443c-b78c-18dbc98f4842@github.com>

On Wed, 26 Apr 2023 11:55:23 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8306461
>  - Simplified exception message and fixed test to check the correct message
>  - Addresed review comments of @turbanoff, @shipilev and @RogerRiggs
>  - 8306461: ObjectInputStream::readObject() should handle negative array sizes without throwing NegativeArraySizeExceptions

A bit more investigation is needed.   
I noticed that ObjectInputStream.checkArray throws NegativeArraySizeException if length is < 0 before calling filterCheck.
The checkArray method is called via SharedSecrets to check array sizes on some of the collection classes during deserialization.
Likely, the change should be extended to cover negative lengths in those cases too.

-------------

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13540#pullrequestreview-1401913022

From lmesnik at openjdk.org  Wed Apr 26 14:38:23 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 26 Apr 2023 14:38:23 GMT
Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when
 using an OutputAnalyzer at the same time [v2]
In-Reply-To: <jbN1idusRU1wUiQ265HUUCyjb2eh8uSC4MDn5igYyy8=.ae64e31f-8c57-415e-8a21-ca7f0e8a6410@github.com>
References: <jbN1idusRU1wUiQ265HUUCyjb2eh8uSC4MDn5igYyy8=.ae64e31f-8c57-415e-8a21-ca7f0e8a6410@github.com>
Message-ID: <kSRlfeTz1fcx4SUN2EIdW58_W3qsYOLydIN0uVIEQtU=.5de62d29-f514-44d5-b79c-897a8faa712a@github.com>

> ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams.
> 
> This fix preserve process streams content and allow to read reuse the date. The ByteArrayOutputStream is used as a buffer. 
> It stores all process output, never trying to clean date which has been read. 
> 
> The regression test has been provided with issue.
> 
> I closed previous PR https://github.com/openjdk/jdk/pull/13560 by mistake instead of updating it.
> 
> I run all tests to ensure that no failures are introduced.

Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:

 - fixed
 - renamed out to stdOut

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13594/files
  - new: https://git.openjdk.org/jdk/pull/13594/files/782e9cd6..b8bb6cb9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13594&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13594&range=00-01

  Stats: 15 lines in 1 file changed: 1 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/13594.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13594/head:pull/13594

PR: https://git.openjdk.org/jdk/pull/13594

From lmesnik at openjdk.org  Wed Apr 26 14:40:24 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 26 Apr 2023 14:40:24 GMT
Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when
 using an OutputAnalyzer at the same time [v2]
In-Reply-To: <7uK1GxdtnB1b_D1bA6Kq8dwnMZw3x3xLKkYDmGibWzc=.7006d521-7b82-4f1e-bdc9-cb23edde89b7@github.com>
References: <jbN1idusRU1wUiQ265HUUCyjb2eh8uSC4MDn5igYyy8=.ae64e31f-8c57-415e-8a21-ca7f0e8a6410@github.com>
 <4EDhpXuaKhviIcVGoDrPbVzcdze_pl4rJZu6DQvWeAw=.f5a9a485-3bb2-4f2b-8b65-e3d35eae1001@github.com>
 <OjLsgMRUFYZUmjzdta-q2Zj-rKGmKfPB2WqnWjYiuHk=.aabde9bc-d5d2-43cf-9d67-8c7dec5c682a@github.com>
 <6ABDu4g-9JNwmdQpdmOXIbz6WUApspGnmHlMk7BhZ6I=.d11f2bc4-c895-4162-9b35-9f2a0d7be519@github.com>
 <7uK1GxdtnB1b_D1bA6Kq8dwnMZw3x3xLKkYDmGibWzc=.7006d521-7b82-4f1e-bdc9-cb23edde89b7@github.com>
Message-ID: <gdzL__eUW9ETKVgPy8j-Bd-lsAWqWy5c5I3dbMJuFVc=.4d86bf33-7a04-411c-bdd1-55386fc71c09@github.com>

On Wed, 26 Apr 2023 09:38:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Right. From the API caller's POV, it is asking for InputStreams that it can use to read the process' stdout or stderr streams.
>
> Okay, thanks.
> I'm thinking about simple/short comments on this to make it clear this naming mismatch is intentional.

There is a comment in line 156 explaining the purpose of these streams.
Also, I renamed out/err names to stdOut/stdErr to make it clearer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1177949748

From liach at openjdk.org  Wed Apr 26 14:46:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Apr 2023 14:46:53 GMT
Subject: RFR: 8180892: Correct handling of annotations on parameters [v2]
In-Reply-To: <A5gWbMb6WLzQW2wbgC5USyPITDoslCEJKWCEO1IGOgs=.d89a8805-8e74-4e2f-8fcd-a4768c95ef7e@github.com>
References: <A5gWbMb6WLzQW2wbgC5USyPITDoslCEJKWCEO1IGOgs=.d89a8805-8e74-4e2f-8fcd-a4768c95ef7e@github.com>
Message-ID: <TwuU-R1pNpx9rCfyEEehPaO72LmCMtPF6MZqWSDWksI=.f70a4aaf-6c09-4e02-ae05-dbafb69ae3fe@github.com>

> 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

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13664/files
  - new: https://git.openjdk.org/jdk/pull/13664/files/7b3646db..2332faad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13664&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13664&range=00-01

  Stats: 136 lines in 1 file changed: 57 ins; 57 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/13664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13664/head:pull/13664

PR: https://git.openjdk.org/jdk/pull/13664

From lmesnik at openjdk.org  Wed Apr 26 15:05:57 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 26 Apr 2023 15:05:57 GMT
Subject: Integrated: 8233725: ProcessTools.startProcess() has output issues
 when using an OutputAnalyzer at the same time
In-Reply-To: <jbN1idusRU1wUiQ265HUUCyjb2eh8uSC4MDn5igYyy8=.ae64e31f-8c57-415e-8a21-ca7f0e8a6410@github.com>
References: <jbN1idusRU1wUiQ265HUUCyjb2eh8uSC4MDn5igYyy8=.ae64e31f-8c57-415e-8a21-ca7f0e8a6410@github.com>
Message-ID: <bz5TvxDegbMPVPI45dBZ5fcbsvkllOVg-xNFaVHc2OI=.f8c42f8b-a969-47c4-b90c-fc3725b5511c@github.com>

On Fri, 21 Apr 2023 21:43:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams.
> 
> This fix preserve process streams content and allow to read reuse the date. The ByteArrayOutputStream is used as a buffer. 
> It stores all process output, never trying to clean date which has been read. 
> 
> The regression test has been provided with issue.
> 
> I closed previous PR https://github.com/openjdk/jdk/pull/13560 by mistake instead of updating it.
> 
> I run all tests to ensure that no failures are introduced.

This pull request has now been integrated.

Changeset: 2e340e85
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e340e855b760e381793107f2a4d74095bd40199
Stats:     211 lines in 3 files changed: 199 ins; 2 del; 10 mod

8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time

Reviewed-by: cjplummer, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/13594

From naoto at openjdk.org  Wed Apr 26 16:02:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Apr 2023 16:02:33 GMT
Subject: RFR: 8305505: NPE in javazic compiler [v2]
In-Reply-To: <plN7RPgpzoYMsyadgCTl6jBDKCuCuFmD4FxqWIWfm2U=.1786e964-5250-48a6-b4d3-e584752d7b88@github.com>
References: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
 <plN7RPgpzoYMsyadgCTl6jBDKCuCuFmD4FxqWIWfm2U=.1786e964-5250-48a6-b4d3-e584752d7b88@github.com>
Message-ID: <gNrT0850NnZ4JHATDpI26_hWuuhw8ByFiBQ03jp2bc4=.9ec52ffc-be99-4ae2-b4e5-b3167db52fb7@github.com>

On Wed, 26 Apr 2023 03:03:58 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> Please review this PR.  
>> With this minor change, the javazic compiler (Main.java) can produce the HTML files that display given time zone data correctly.
>
> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Insert null check for mapList at its usage instead of initializing mapList

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13504#pullrequestreview-1402301927

From mchung at openjdk.org  Wed Apr 26 16:20:01 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 26 Apr 2023 16:20:01 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v10]
In-Reply-To: <A2tmdroOslAavnDJA73dRP3gaBlWU1b_vv801f-KRPE=.9159a865-3d3c-4eb2-82ec-6e01da941c5e@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <IxgwT4-WrCAAAzBEfOk6inLJI8rTBQcD6jq_DGpaPVw=.eb365f86-7a92-45be-9afe-abad692e6324@github.com>
 <A2tmdroOslAavnDJA73dRP3gaBlWU1b_vv801f-KRPE=.9159a865-3d3c-4eb2-82ec-6e01da941c5e@github.com>
Message-ID: <qV1f_aCcfisRrFqdJJVaP0nqvCUlRZR6fmx4KcyNy7U=.e45443d7-ba6c-4c9f-983a-c63331d24852@github.com>

On Wed, 26 Apr 2023 06:18:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Have we considered moving the Impl classes into a non-public area such as `jdk.internal` to improve encapsulation and reduce perceived footprint?

I don't see much of a problem to keep the non-public classes in `java.lang.constant` since it's not open and no reflective access.   Not sure what perceived footprint you referred to as the JDK footprint won't change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13615#issuecomment-1523695438

From jlu at openjdk.org  Wed Apr 26 17:08:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Apr 2023 17:08:25 GMT
Subject: Integrated: 8305853:
 java/text/Format/DateFormat/DateFormatRegression.java fails with
 "Uncaught exception thrown in test method Test4089106"
In-Reply-To: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>
References: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>
Message-ID: <AMx6iql95VOJb3DnZ3foWbJaIyiDmqoD_uPUkcN-bJg=.798af880-a306-4fb7-b239-407b049a28d7@github.com>

On Mon, 24 Apr 2023 21:02:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes an intermittent failure (that only occurs on Windows) in _DateFormatRegression.java_.
> 
> With the integration of [JDK-8304982](https://bugs.openjdk.org/browse/JDK-8304982), _LocaleProviderAdapter.java_ now emits a compat warning when the class is loaded. This warning calls `ZonedDateTime.now()` during formatting. This call depends on the `TimeZone.ID` of the TimeZone returned from `TimeZone.getDefault()`.
> 
> On Windows, the test class which DateFormatRegression extends will run the tests at random, (as opposed to running in the same order every time). When Test4089106() happens to be the first test ran, the static block of LocaleProviderAdapter will be executed with `TimeZone.setDefault()` set to a `SimpleTimeZone` with `id` as _FAKEZONE_. When LocaleProviderAdapter formats the compat warning ... and many calls later calls `ZoneRulesProvider getProvider(String zoneId)` with `zoneId` as _FAKEZONE_ the test fails with _java.time.zone.ZoneRulesException: Unknown time-zone ID: FAKEZONE_.
> 
> In order to still test that `SimpleDateFormat.getTimeZone()` defaults to `TimeZone.getDefault()` we can create a `SimpleTimeZone` with a custom id rather than an invalid id. This way ZoneRulesProvider will not fail on the ID, but the `SimpleTimeZone` being tested is still not a "default" `TimeZone`.

This pull request has now been integrated.

Changeset: 8e36c05d
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e36c05d6c80f6bdcd8a7530a382810f500885ad
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8305853: java/text/Format/DateFormat/DateFormatRegression.java fails with "Uncaught exception thrown in test method Test4089106"

Reviewed-by: naoto, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/13630

From mchung at openjdk.org  Wed Apr 26 17:54:24 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 26 Apr 2023 17:54:24 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v13]
In-Reply-To: <5nw09YhnRegFOv-IqMqQIyz1CTNRQ4EKKdDQcDGx_zg=.0a148355-4968-468a-af01-e97fe5884782@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <5nw09YhnRegFOv-IqMqQIyz1CTNRQ4EKKdDQcDGx_zg=.0a148355-4968-468a-af01-e97fe5884782@github.com>
Message-ID: <Ynd3gZ2b0PaoSgoe5dO3lSwWCgc3bZGUzWeue1-8YPg=.db6d6537-8967-4871-bc8f-b9a236e9b949@github.com>

On Wed, 26 Apr 2023 10:46:24 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
>> 
>> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
>> 
>> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
>> 
>> Please review this pull request and attached CSR.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed prefixes from name methods

Thanks for the update.   Two typos.  please do `make docs` to verify the output.

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 71:

> 69:      * correct format
> 70:      * @jvms 4.2.1 Binary Class and Interface Names
> 71:      * @jvm 4.2.3 Module and Package Names

Suggestion:

     * @jvms 4.2.3 Module and Package Names

src/java.base/share/classes/java/lang/constant/PackageDesc.java line 104:

> 102:      * Compare the specified object with this descriptor for equality.
> 103:      * Returns {@code true} if and only if the specified object is
> 104:      * also a {@linkp PackageDesc} and both describe the same package.

Suggestion:

     * also a {@link PackageDesc} and both describe the same package.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13615#pullrequestreview-1402503600
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1178204923
PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1178205091

From naoto at openjdk.org  Wed Apr 26 18:28:24 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Apr 2023 18:28:24 GMT
Subject: RFR: 8306711: Improve diagnosis of `IntlTest` framework [v3]
In-Reply-To: <1jgAl-t9wzGNi3vuG9zDxsjAK3xyei8Chqrzt7DvRYg=.8f49fb5f-afdd-423f-9e22-078584b00433@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
 <1jgAl-t9wzGNi3vuG9zDxsjAK3xyei8Chqrzt7DvRYg=.8f49fb5f-afdd-423f-9e22-078584b00433@github.com>
Message-ID: <3Niq8CgII4c7bK_CO1PdVbm5gMLJKlPvwI0yv-a0dbE=.61cee516-f80e-4239-b025-add9aac17f98@github.com>

On Tue, 25 Apr 2023 23:58:59 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review changes to the IntlTest (test framework) class. 
>> 
>> These changes include
>> - Logging the actual exception + stack trace. Previously, the test framework would throw `InvocationTargetException` but hide the actual underlying exception of the failing test unless the test class was ran with -nothrow.
>> - Sorting the tests, ensuring for any given run, the tests are ran in the same order. (In [JDK-8305853](https://bugs.openjdk.org/browse/JDK-8305853) it was discovered that on Windows, the test framework would execute tests in a random order each time).
>> - Improving output.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move getErrorCount() back to original spot
>  - Regardles of nothrow, final result should be logged, cache, move method back

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13655#pullrequestreview-1402547220

From alanb at openjdk.org  Wed Apr 26 18:28:24 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Apr 2023 18:28:24 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v13]
In-Reply-To: <5nw09YhnRegFOv-IqMqQIyz1CTNRQ4EKKdDQcDGx_zg=.0a148355-4968-468a-af01-e97fe5884782@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <5nw09YhnRegFOv-IqMqQIyz1CTNRQ4EKKdDQcDGx_zg=.0a148355-4968-468a-af01-e97fe5884782@github.com>
Message-ID: <Epehp39BU_sP5TVgtCA4dSNprM-swmdUK3SkApXQRzY=.e5e284b8-e1e2-4695-bd1c-61eac27068fe@github.com>

On Wed, 26 Apr 2023 10:46:24 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
>> 
>> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
>> 
>> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
>> 
>> Please review this pull request and attached CSR.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed prefixes from name methods

src/java.base/share/classes/java/lang/constant/ConstantUtils.java line 133:

> 131:             if ((ch >= '\u0000' && ch <= '\u001F')
> 132:             || ((ch == '\\' || ch == ':' || ch =='@') && (i == 0 || name.charAt(--i) != '\\')))
> 133:                 throw new IllegalArgumentException("Invalid module name: " + name);

test/jdk/java/lang/module/ModuleNames.java has tables of legal and illegal module names, including tests that escape backslash, @, and :. It might be useful to run these tests on this method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1178237361

From mchung at openjdk.org  Wed Apr 26 19:23:55 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 26 Apr 2023 19:23:55 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v13]
In-Reply-To: <5nw09YhnRegFOv-IqMqQIyz1CTNRQ4EKKdDQcDGx_zg=.0a148355-4968-468a-af01-e97fe5884782@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <5nw09YhnRegFOv-IqMqQIyz1CTNRQ4EKKdDQcDGx_zg=.0a148355-4968-468a-af01-e97fe5884782@github.com>
Message-ID: <EwPf1_uiOAh-j4PzNoa0lwaaf-5VZ02SHGJ5a_4LBQw=.5d836757-8b45-44fd-82c5-5ad43c344112@github.com>

On Wed, 26 Apr 2023 10:46:24 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
>> 
>> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
>> 
>> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
>> 
>> Please review this pull request and attached CSR.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed prefixes from name methods

I keep pondering if this API should allow creating `ModuleDesc` and `PackageDesc` with an empty name.  

JLS 6.5.3. Meaning of Module Names and Package Names
> The module name M, whether simple or qualified, denotes the module (if any) with that name.

The module system will reject a `CONSTANT_Module_info` of zero-length name while JVMS does not prohibit it.

The module system rejects the unnamed package in a named module.    `CONSTANT_Package_info` represents a package exported or opened by a module.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13615#issuecomment-1523914987

From jlahoda at openjdk.org  Wed Apr 26 20:12:23 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 26 Apr 2023 20:12:23 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v8]
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <PZ7jVxm34CgLOnDulreSMFzg64w0Hm7WRGWtnaYDbgk=.531164b4-4a98-4950-8630-eff6b7f10478@github.com>

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup: reflecting review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13074/files
  - new: https://git.openjdk.org/jdk/pull/13074/files/35f51562..3b3bcbcc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=06-07

  Stats: 135 lines in 4 files changed: 0 ins; 65 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/13074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074

PR: https://git.openjdk.org/jdk/pull/13074

From lancea at openjdk.org  Wed Apr 26 20:21:53 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 26 Apr 2023 20:21:53 GMT
Subject: RFR: 8306711: Improve diagnosis of `IntlTest` framework [v3]
In-Reply-To: <1jgAl-t9wzGNi3vuG9zDxsjAK3xyei8Chqrzt7DvRYg=.8f49fb5f-afdd-423f-9e22-078584b00433@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
 <1jgAl-t9wzGNi3vuG9zDxsjAK3xyei8Chqrzt7DvRYg=.8f49fb5f-afdd-423f-9e22-078584b00433@github.com>
Message-ID: <BR4HE-aBeNqd1ddhrKd65MrLB098p30EzNAjdRXwOBM=.ffc0bb0c-39d4-4c1e-b651-4de8c6b25442@github.com>

On Tue, 25 Apr 2023 23:58:59 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review changes to the IntlTest (test framework) class. 
>> 
>> These changes include
>> - Logging the actual exception + stack trace. Previously, the test framework would throw `InvocationTargetException` but hide the actual underlying exception of the failing test unless the test class was ran with -nothrow.
>> - Sorting the tests, ensuring for any given run, the tests are ran in the same order. (In [JDK-8305853](https://bugs.openjdk.org/browse/JDK-8305853) it was discovered that on Windows, the test framework would execute tests in a random order each time).
>> - Improving output.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move getErrorCount() back to original spot
>  - Regardles of nothrow, final result should be logged, cache, move method back

Looks good overall perhaps consider using `HexFormat` instead of the private method `toHexString`

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13655#pullrequestreview-1402735283

From shade at openjdk.org  Wed Apr 26 20:22:54 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Apr 2023 20:22:54 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v12]
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <PVpzrnUNYUw9j-v5-l6-V_10Que9IXNlsXhcEuiXP-A=.22b21bed-b619-4a84-b737-9ac46d34374c@github.com>

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Aleksey Shipilev 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 branch 'master' into JDK-83050920-thread-sleep-subms
 - Merge branch 'master' into JDK-83050920-thread-sleep-subms
 - Fix Amazon copyright
 - Merge branch 'master' into JDK-83050920-thread-sleep-subms
 - Drop nanos_to_nanos_bounded
 - Handle overflows
 - More review comments
 - Adjust test times
 - Windows again
 - Windows fixes: align(...) is only for power-of-two alignments
 - ... and 16 more: https://git.openjdk.org/jdk/compare/35e7bc21...da8f0f8c

-------------

Changes: https://git.openjdk.org/jdk/pull/13225/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=11
  Stats: 254 lines in 11 files changed: 226 ins; 9 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/13225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13225/head:pull/13225

PR: https://git.openjdk.org/jdk/pull/13225

From bchristi at openjdk.org  Wed Apr 26 20:31:52 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 26 Apr 2023 20:31:52 GMT
Subject: RFR: 8298993: (process)
 java/lang/ProcessBuilder/UnblockSignals.java fails
In-Reply-To: <iWHiW4JJiCHgJERISrctccBOnAZgAfsemSDjfZJEQzI=.b60ab5fa-82f5-4e77-9d8d-1fb02ec162d2@github.com>
References: <iWHiW4JJiCHgJERISrctccBOnAZgAfsemSDjfZJEQzI=.b60ab5fa-82f5-4e77-9d8d-1fb02ec162d2@github.com>
Message-ID: <xkWNDplSxWa9tBXPTvQyQlUZ0h5Ii7ckVYhvhO-8A8k=.581bf88d-8199-4256-8bf9-bb3b4ac0f6a3@github.com>

On Tue, 25 Apr 2023 21:43:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> It appears that -Xcomp causes the relative timing of the commands to be disturbed enough to prevent the correct operation of the test. The test should not be run with -Xcomp

Changes requested by bchristi (Reviewer).

test/jdk/java/lang/ProcessBuilder/UnblockSignals.java line 32:

> 30:  * @requires (os.family == "linux" | os.family == "mac")
> 31:  * @comment Don't allow -Xcomp, it disturbs the relative timing of the sleep and kill commands
> 32:  * @requires (vm.compMode == "Xmixed")

How about `vm.compMode != "Xcomp"` ?

-------------

PR Review: https://git.openjdk.org/jdk/pull/13660#pullrequestreview-1402740951
PR Review Comment: https://git.openjdk.org/jdk/pull/13660#discussion_r1178349433

From lancea at openjdk.org  Wed Apr 26 20:44:26 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 26 Apr 2023 20:44:26 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v3]
In-Reply-To: <1VOiJqfV7MR0h3qtLDOK6JjmSAiWP8cTOcXP9ZW0nTY=.79b86cdb-ad4f-4c0b-9010-43d385427a28@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <1VOiJqfV7MR0h3qtLDOK6JjmSAiWP8cTOcXP9ZW0nTY=.79b86cdb-ad4f-4c0b-9010-43d385427a28@github.com>
Message-ID: <50WXvkMN5F6Nkhob1s2v1k4aEWawumoF0JFH3ukyIlQ=.c228a678-66c3-4eeb-837a-a8fcb100b1a4@github.com>

On Thu, 30 Mar 2023 03:06:51 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
>> 
>> Thanks to @jaikiran for amazing PR description.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removes out1,out2 parameters

The changes look OK.  I think this would be a good opportunity to add some comments to this test especially to the check method

Jai,  have you run this acrossed all of our Mach5 platforms?

test/jdk/java/util/zip/DeInflate.java line 129:

> 127:         int m = 0;
> 128: 
> 129:         ByteArrayOutputStream baos = new ByteArrayOutputStream(len);

Is there a reason a try-with-resources is not being used?

-------------

PR Review: https://git.openjdk.org/jdk/pull/12283#pullrequestreview-1402766747
PR Review Comment: https://git.openjdk.org/jdk/pull/12283#discussion_r1178363485

From naoto at openjdk.org  Wed Apr 26 20:55:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Apr 2023 20:55:54 GMT
Subject: RFR: 8306927: Collator treats "v" and "w" as the same letter for
 Swedish language locale.
Message-ID: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>

Updating the collation rules for Swedish to the modern one, which is aligned with the CLDR's default collation rules. Since it is changing the existing behavior, a release note has also been drafted: https://bugs.openjdk.org/browse/JDK-8306948

-------------

Commit messages:
 - Added a test, copyright year
 - 8306927: Collator treats "v" and "w" as the same letter for Swedish language locale.

Changes: https://git.openjdk.org/jdk/pull/13677/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13677&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306927
  Stats: 50 lines in 2 files changed: 45 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13677/head:pull/13677

PR: https://git.openjdk.org/jdk/pull/13677

From mchung at openjdk.org  Wed Apr 26 22:21:52 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 26 Apr 2023 22:21:52 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <uLslHv8uOIIXEB6uZQfVmoftErMwO3jwQxkFDEc0BVU=.5a2073d9-2a55-4b71-b6a7-5ba47db14b01@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

I'm not working on the Constant API area while I'm happy to help.  FYI I'll be on vacation for 3 weeks from May 1.

An array does not have an internal name.   Changing `ofInternalName` to accept arrays seems not right.   What is the issue of calling `ClassDesc.ofDescriptor`  for arrays?

Have you considered `internalName` to return an `Optional`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1524102955
PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1524105274

From jlu at openjdk.org  Wed Apr 26 22:31:53 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Apr 2023 22:31:53 GMT
Subject: RFR: 8306927: Collator treats "v" and "w" as the same letter for
 Swedish language locale.
In-Reply-To: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
References: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
Message-ID: <7CYXigGbDi0cdS37EA30gH6qbnxacqDOTaYToHMUCcg=.4c78f4d3-1bae-4f21-936c-01d872b706c4@github.com>

On Wed, 26 Apr 2023 20:42:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updating the collation rules for Swedish to the modern one, which is aligned with the CLDR's default collation rules. Since it is changing the existing behavior, a release note has also been drafted: https://bugs.openjdk.org/browse/JDK-8306948

Marked as reviewed by jlu (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13677#pullrequestreview-1402905133

From jlu at openjdk.org  Wed Apr 26 22:34:56 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Apr 2023 22:34:56 GMT
Subject: RFR: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention
Message-ID: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>

Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.

This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.


In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
- Will not case fold variant subtags
- Will not case fold private use subtags prefixed by "lvariant"

As an example, `caseFoldLanguageTag("JA-JPAN-JP-U-CA-JAPANESE-x-RANDOM-lvariant-JP")` returns _"ja-Jpan-JP-u-ca-japanese-x-random-lvariant-JP"_. Further examples can be seen in the test file.

-------------

Commit messages:
 - Copyright year for LangTag
 - Space
 - Add PR example to tests
 - Add case for grandfathered tag in specification
 - Consider private use variant prefix (JDK special cases)
 - Cache the potential legacy tag
 - Remove leftover comments in LanguageTag
 - Adjust imports in LanguageTag.java
 - Add implementation to LanguageTag.java
 - Add specification to Locale
 - ... and 1 more: https://git.openjdk.org/jdk/compare/d063b896...25be34d9

Changes: https://git.openjdk.org/jdk/pull/13679/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13679&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8159337
  Stats: 251 lines in 3 files changed: 247 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13679/head:pull/13679

PR: https://git.openjdk.org/jdk/pull/13679

From jlu at openjdk.org  Wed Apr 26 23:40:23 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Apr 2023 23:40:23 GMT
Subject: RFR: 8306711: Improve diagnosis of `IntlTest` framework [v4]
In-Reply-To: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
Message-ID: <OCUg1H7MfpamF6cDz24fHWKyc3L3ZZNhXFeV_pX1mp8=.879d7c07-40bc-4645-983f-bbfe26e0063f@github.com>

> Please review changes to the IntlTest (test framework) class. 
> 
> These changes include
> - Logging the actual exception + stack trace. Previously, the test framework would throw `InvocationTargetException` but hide the actual underlying exception of the failing test unless the test class was ran with -nothrow.
> - Sorting the tests, ensuring for any given run, the tests are ran in the same order. (In [JDK-8305853](https://bugs.openjdk.org/browse/JDK-8305853) it was discovered that on Windows, the test framework would execute tests in a random order each time).
> - Improving output.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Replace toHexString() with HexFormat

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13655/files
  - new: https://git.openjdk.org/jdk/pull/13655/files/a395ba67..773da120

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13655&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13655&range=02-03

  Stats: 70 lines in 2 files changed: 26 ins; 14 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/13655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13655/head:pull/13655

PR: https://git.openjdk.org/jdk/pull/13655

From jlu at openjdk.org  Wed Apr 26 23:42:52 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Apr 2023 23:42:52 GMT
Subject: RFR: 8306711: Improve diagnosis of `IntlTest` framework [v3]
In-Reply-To: <BR4HE-aBeNqd1ddhrKd65MrLB098p30EzNAjdRXwOBM=.ffc0bb0c-39d4-4c1e-b651-4de8c6b25442@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
 <1jgAl-t9wzGNi3vuG9zDxsjAK3xyei8Chqrzt7DvRYg=.8f49fb5f-afdd-423f-9e22-078584b00433@github.com>
 <BR4HE-aBeNqd1ddhrKd65MrLB098p30EzNAjdRXwOBM=.ffc0bb0c-39d4-4c1e-b651-4de8c6b25442@github.com>
Message-ID: <cfAoW7z8xm9k5krmirT1jqwMTCkVHd3xd9pfaHvYpSM=.44b53e99-af85-48fe-82a5-ca0ae389c146@github.com>

On Wed, 26 Apr 2023 20:08:51 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Move getErrorCount() back to original spot
>>  - Regardles of nothrow, final result should be logged, cache, move method back
>
> Looks good overall perhaps consider using `HexFormat` instead of the private method `toHexString`

@LanceAndersen Thanks for the review. Changed it so that `HexFormat` methods are used, luckily only one subclass used `toHexString`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13655#issuecomment-1524179840

From liach at openjdk.org  Wed Apr 26 23:44:24 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Apr 2023 23:44:24 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <uLslHv8uOIIXEB6uZQfVmoftErMwO3jwQxkFDEc0BVU=.5a2073d9-2a55-4b71-b6a7-5ba47db14b01@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
 <uLslHv8uOIIXEB6uZQfVmoftErMwO3jwQxkFDEc0BVU=.5a2073d9-2a55-4b71-b6a7-5ba47db14b01@github.com>
Message-ID: <-i4oz__dlTn2hMzZ--RDogQW8uDTEtJMiwZ1hBP5vNw=.e8a940fd-5961-4d27-afab-975ce2ce15c1@github.com>

On Wed, 26 Apr 2023 22:10:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> What is the issue of calling `ClassDesc.ofDescriptor` for arrays?

Users would have to check the obtained string from a `CONSTANT_Class_info` and call different factory methods, which feels a bit... weird to me, like calling `a == null ? Optional.empty() : Optional.of(a)` instead of `Optional.ofNullable(a)`, and `CONSTANT_Class_info` can be seen as an API provided by the class file as it's defined in the JVMS.

> Have you considered `internalName` to return an `Optional`?

That might be feasible. I initially fear that this may hurt performance-sensitive operations, but now I think as long as we can make `isArray()` or `isClassOrInterface()` constant-foldable (I don't think `String::startsWith` is optimized that far, so might need to check `charAt(0)`), we can still make obtaining the internal name fast.


public Optional<String> internalName() {
    if (!isClassOrInterface()) // assuming constant-foldable
        return Optional.of(descriptorString);
    var internalName = this.internalName; // caching
    if (internalName != null)
        return Optional.of(internalName);
    return Optional.of(this.internalName = descriptorString.substring(1, descriptorString.length() - 1));
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1524187441

From mchung at openjdk.org  Thu Apr 27 01:10:57 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 27 Apr 2023 01:10:57 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <beAGtH1lpeGW7EAqU1NdinpsyArw9sJ8cGqH4IXEGig=.25f4f01f-189a-49d3-8a2f-c13564c72875@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

Only the class name of a class or interface is encoded in the internal form.  I expect the `internalName` method should do like this:


public Optional<String> internalName() {
    if (!isClassOrInterface())
        return Optional.empty();
    return Optional.of(internalName);  // it can be stored as a final field assigned during instantiation
}


What you are thinking is a method to return some string for any ClassDesc.  If that's desirable, that should be a different method name.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1524343004

From iris at openjdk.org  Thu Apr 27 01:13:23 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 27 Apr 2023 01:13:23 GMT
Subject: RFR: 8306927: Collator treats "v" and "w" as the same letter for
 Swedish language locale.
In-Reply-To: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
References: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
Message-ID: <sCRan2XV_GNo_g_ETudGP2kCW6QH993xWQy2IHSf2Bg=.1c3fcdb2-86e8-4544-97b2-82737d8f48bc@github.com>

On Wed, 26 Apr 2023 20:42:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updating the collation rules for Swedish to the modern one, which is aligned with the CLDR's default collation rules. Since it is changing the existing behavior, a release note has also been drafted: https://bugs.openjdk.org/browse/JDK-8306948

Release note also looks good.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13677#pullrequestreview-1403026602

From jpai at openjdk.org  Thu Apr 27 01:24:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Apr 2023 01:24:54 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v3]
In-Reply-To: <1VOiJqfV7MR0h3qtLDOK6JjmSAiWP8cTOcXP9ZW0nTY=.79b86cdb-ad4f-4c0b-9010-43d385427a28@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <1VOiJqfV7MR0h3qtLDOK6JjmSAiWP8cTOcXP9ZW0nTY=.79b86cdb-ad4f-4c0b-9010-43d385427a28@github.com>
Message-ID: <8CWwPUezmxog5jKIR1zUBL94ptWuNGdXdRNR9fpvXno=.de92db33-481c-4090-96e1-3ea2b012a58c@github.com>

On Thu, 30 Mar 2023 03:06:51 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
>> 
>> Thanks to @jaikiran for amazing PR description.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removes out1,out2 parameters

Hello Lance,

> Jai, have you run this acrossed all of our Mach5 platforms?

Yes I did that yesterday and the tests were successful.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12283#issuecomment-1524346331

From lmesnik at openjdk.org  Thu Apr 27 01:25:27 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 27 Apr 2023 01:25:27 GMT
Subject: RFR: 8306946: jdk/test/lib/process/ProcessToolsStartProcessTest.java
 fails with "wrong number of lines in OutputAnalyzer output"
Message-ID: <ISIK6xDSGNSO7Usnt3OXUMae1vVH0RnRjvIz4m3hVts=.1770f58f-1a6a-4dfe-8f27-99d8fa5d1018@github.com>

The ProcessTools.startProcess (...) has been updated to completely read streams after process has been completed.
The test was updated to run 5 times with different number of lines and line sizes.

-------------

Commit messages:
 - fixed num of iters
 - fix

Changes: https://git.openjdk.org/jdk/pull/13683/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13683&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306946
  Stats: 63 lines in 2 files changed: 26 ins; 21 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/13683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13683/head:pull/13683

PR: https://git.openjdk.org/jdk/pull/13683

From liach at openjdk.org  Thu Apr 27 01:34:23 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Apr 2023 01:34:23 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <0ilzHuCl9IFEH15Q6b45Is8oIygOtvFZa-OctyNlyQg=.c7b8dbed-f6cf-45c3-aed4-09c402087f7f@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

I am aiming for an API to interact with the string in `CONSTANT_Class_info` than internal names, as I fail to see how internal names have any usage besides being a part of `CONSTANT_Class_info` when descriptors are present.

Should I use the `ofClassInfoString` `toClassInfoString` names instead, since everyone is confused on internal names? And this will avoid touching the preexisting `ofInternalName`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1524368369

From mchung at openjdk.org  Thu Apr 27 01:55:24 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 27 Apr 2023 01:55:24 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <ifz54s3C9st1zDUrZA8ptM_HaOoP8pCK4v0JONE4Q7k=.00fbb7fe-e5e3-456d-91c6-7bfb38d1934c@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

I want to see what @asotona thinks.   I also want to see some examples how ClassFile API implementation uses this new API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1524411693

From dholmes at openjdk.org  Thu Apr 27 01:56:54 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 27 Apr 2023 01:56:54 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v12]
In-Reply-To: <PVpzrnUNYUw9j-v5-l6-V_10Que9IXNlsXhcEuiXP-A=.22b21bed-b619-4a84-b737-9ac46d34374c@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <PVpzrnUNYUw9j-v5-l6-V_10Que9IXNlsXhcEuiXP-A=.22b21bed-b619-4a84-b737-9ac46d34374c@github.com>
Message-ID: <GsX_I7DSqimEwahXZSNQhpdq535V99mKUaCgVhQ8YXE=.68b7a369-3b7c-45ed-ac39-b70d5416c0c9@github.com>

On Wed, 26 Apr 2023 20:22:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
>> 
>> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
>> 
>> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
>> 
>> Additional testing:
>>   - [x] New regression test
>>   - [x] New benchmark
>>   - [x] Linux x86_64 `tier1`
>>   - [x] Linux AArch64 `tier1`
>
> Aleksey Shipilev 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 branch 'master' into JDK-83050920-thread-sleep-subms
>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>  - Fix Amazon copyright
>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>  - Drop nanos_to_nanos_bounded
>  - Handle overflows
>  - More review comments
>  - Adjust test times
>  - Windows again
>  - Windows fixes: align(...) is only for power-of-two alignments
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/35e7bc21...da8f0f8c

Nothing further from me. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13225#pullrequestreview-1403054308

From amitkumar at openjdk.org  Thu Apr 27 03:25:53 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 27 Apr 2023 03:25:53 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v4]
In-Reply-To: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
Message-ID: <xRc1eO6PXAnqkxbGdg2dwgy7xHEh2ti-ZVhEBG_11dU=.53ddf005-13ab-4783-81c9-6b6f03f514c3@github.com>

> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
> 
> Thanks to @jaikiran for amazing PR description.

Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:

  comments from Lance

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12283/files
  - new: https://git.openjdk.org/jdk/pull/12283/files/bce89892..625ad4bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=02-03

  Stats: 44 lines in 1 file changed: 18 ins; 13 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/12283.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12283/head:pull/12283

PR: https://git.openjdk.org/jdk/pull/12283

From amitkumar at openjdk.org  Thu Apr 27 03:30:53 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 27 Apr 2023 03:30:53 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v3]
In-Reply-To: <50WXvkMN5F6Nkhob1s2v1k4aEWawumoF0JFH3ukyIlQ=.c228a678-66c3-4eeb-837a-a8fcb100b1a4@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <1VOiJqfV7MR0h3qtLDOK6JjmSAiWP8cTOcXP9ZW0nTY=.79b86cdb-ad4f-4c0b-9010-43d385427a28@github.com>
 <50WXvkMN5F6Nkhob1s2v1k4aEWawumoF0JFH3ukyIlQ=.c228a678-66c3-4eeb-837a-a8fcb100b1a4@github.com>
Message-ID: <5BhQ2Ft1ouUHe8_EAQ2_kNp4g9xpSXM5--hqqzzp7Hg=.1558b182-00ca-4e0d-bd16-a1bcc9a84575@github.com>

On Wed, 26 Apr 2023 20:29:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removes out1,out2 parameters
>
> test/jdk/java/util/zip/DeInflate.java line 129:
> 
>> 127:         int m = 0;
>> 128: 
>> 129:         ByteArrayOutputStream baos = new ByteArrayOutputStream(len);
> 
> Is there a reason a try-with-resources is not being used?

Thanks for pointing it out. Please take a look at the latest modifications.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12283#discussion_r1178583085

From amitkumar at openjdk.org  Thu Apr 27 03:35:54 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 27 Apr 2023 03:35:54 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v3]
In-Reply-To: <8CWwPUezmxog5jKIR1zUBL94ptWuNGdXdRNR9fpvXno=.de92db33-481c-4090-96e1-3ea2b012a58c@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <1VOiJqfV7MR0h3qtLDOK6JjmSAiWP8cTOcXP9ZW0nTY=.79b86cdb-ad4f-4c0b-9010-43d385427a28@github.com>
 <8CWwPUezmxog5jKIR1zUBL94ptWuNGdXdRNR9fpvXno=.de92db33-481c-4090-96e1-3ea2b012a58c@github.com>
Message-ID: <ZML3QHJspJxzx01VRUKPTJloZAyB1s5r1Fze6YOOSpQ=.aa271834-450e-412e-aaf4-bc5f3844c70f@github.com>

On Thu, 27 Apr 2023 01:04:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removes out1,out2 parameters
>
> Hello Lance,
> 
>> Jai, have you run this acrossed all of our Mach5 platforms?
> 
> Yes I did that yesterday and the tests were successful.

Build failure for aarch64 & x64 is unrelated, but still @jaikiran would you like to take a look at latest modification.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12283#issuecomment-1524585345

From joehw at openjdk.org  Thu Apr 27 04:47:26 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 27 Apr 2023 04:47:26 GMT
Subject: RFR: 8306927: Collator treats "v" and "w" as the same letter for
 Swedish language locale.
In-Reply-To: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
References: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
Message-ID: <x8j-huGlphor_LDELRncZ2hwghZhBpli5S96RYQmy98=.04857585-5b8f-4e34-89c9-76a7aff1a120@github.com>

On Wed, 26 Apr 2023 20:42:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updating the collation rules for Swedish to the modern one, which is aligned with the CLDR's default collation rules. Since it is changing the existing behavior, a release note has also been drafted: https://bugs.openjdk.org/browse/JDK-8306948

The rule was changed in 2006, the year Jave SE 6 was released. Though it looks like very much a corner case, it goes all the way back. I wonder if a CSR is needed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13677#issuecomment-1524687089

From dholmes at openjdk.org  Thu Apr 27 05:23:23 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 27 Apr 2023 05:23:23 GMT
Subject: RFR: 8306946:
 jdk/test/lib/process/ProcessToolsStartProcessTest.java fails with
 "wrong number of lines in OutputAnalyzer output"
In-Reply-To: <ISIK6xDSGNSO7Usnt3OXUMae1vVH0RnRjvIz4m3hVts=.1770f58f-1a6a-4dfe-8f27-99d8fa5d1018@github.com>
References: <ISIK6xDSGNSO7Usnt3OXUMae1vVH0RnRjvIz4m3hVts=.1770f58f-1a6a-4dfe-8f27-99d8fa5d1018@github.com>
Message-ID: <rjbYoZb-uHk3_xEbmUPnEHPdBJgDLIckBC5PhxbaDaU=.138b9b8e-9b89-411a-b213-d76dff00a9df@github.com>

On Thu, 27 Apr 2023 01:06:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The ProcessTools.startProcess (...) has been updated to completely read streams after process has been completed.
> The test was updated to run 5 times with different number of lines and line sizes.

I missed the previous changes to ProcessTools as I was away. This code is so complicated that I find it impossible to discern if it is actually doing the right thing. But I'm concerned by the added FutureTask usage.

test/lib-test/jdk/test/lib/process/ProcessToolsStartProcessTest.java line 79:

> 77:                 System.out.print("FAILED: wrong number of lines in Consumer output\n");
> 78:                 success = false;
> 79:                 System.out.print(out.getStdout());

Why isn't this printing output?

test/lib-test/jdk/test/lib/process/ProcessToolsStartProcessTest.java line 95:

> 93:     public static void main(String[] args) throws Exception {
> 94:         if (args.length > 0) {
> 95:             for (int i = 0; i < Integer.parseInt(args[0]); i++) {

This will call parseInt on each iteration of the loop.

test/lib/jdk/test/lib/process/ProcessTools.java line 183:

> 181:                         // It is needed to wait until stream is flushed after
> 182:                         // process is completed.
> 183:                         task.get();

This looks problematic - if you block here you are holding the object monitor as this is a synchronized method.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13683#pullrequestreview-1403178899
PR Review Comment: https://git.openjdk.org/jdk/pull/13683#discussion_r1178625211
PR Review Comment: https://git.openjdk.org/jdk/pull/13683#discussion_r1178627264
PR Review Comment: https://git.openjdk.org/jdk/pull/13683#discussion_r1178629324

From jpai at openjdk.org  Thu Apr 27 06:52:22 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Apr 2023 06:52:22 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v4]
In-Reply-To: <xRc1eO6PXAnqkxbGdg2dwgy7xHEh2ti-ZVhEBG_11dU=.53ddf005-13ab-4783-81c9-6b6f03f514c3@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <xRc1eO6PXAnqkxbGdg2dwgy7xHEh2ti-ZVhEBG_11dU=.53ddf005-13ab-4783-81c9-6b6f03f514c3@github.com>
Message-ID: <KzXAg6GzPkZYjVnePYX5IBrgxs2NMGhzRFYME7i2j3Y=.55dfdcc9-0154-4af0-834f-2b6e916e41a1@github.com>

On Thu, 27 Apr 2023 03:25:53 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
>> 
>> Thanks to @jaikiran for amazing PR description.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments from Lance

test/jdk/java/util/zip/DeInflate.java line 124:

> 122:      * This method checks if a given Deflater and Inflater pair can correctly compress and decompress data.
> 123:      * checks were performed for this functionality using various input scenarios and ByteBuffer instances.
> 124:      */

Would you consider updating this comment to something like:


/**
 * Uses the {@code def} deflater to deflate the input data {@code in} of length {@code len}.
 * A new {@link Inflater} is then created within this method to inflate the deflated data. The
 * inflated data is then compared with the {@code in} to assert that it matches the original
 * input data.
 * This method repeats these checks for the different overloaded methods of
 * {@code Deflater.deflate(...)} and {@code Inflater.inflate(...)}
 *
 * @param def    the deflater to use for deflating the contents in {@code in}
 * @param in     the input content
 * @param len    the length of the input content to use
 * @param nowrap will be passed to the constructor of the {@code Inflater} used in this
 *               method
 * @throws Throwable if any error occurs during the check
 */

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12283#discussion_r1178690586

From jpai at openjdk.org  Thu Apr 27 06:52:25 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Apr 2023 06:52:25 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v3]
In-Reply-To: <5BhQ2Ft1ouUHe8_EAQ2_kNp4g9xpSXM5--hqqzzp7Hg=.1558b182-00ca-4e0d-bd16-a1bcc9a84575@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <1VOiJqfV7MR0h3qtLDOK6JjmSAiWP8cTOcXP9ZW0nTY=.79b86cdb-ad4f-4c0b-9010-43d385427a28@github.com>
 <50WXvkMN5F6Nkhob1s2v1k4aEWawumoF0JFH3ukyIlQ=.c228a678-66c3-4eeb-837a-a8fcb100b1a4@github.com>
 <5BhQ2Ft1ouUHe8_EAQ2_kNp4g9xpSXM5--hqqzzp7Hg=.1558b182-00ca-4e0d-bd16-a1bcc9a84575@github.com>
Message-ID: <D9MvQ_DYV4F_dnQeSZUX3QvefhIqSkmLyO2h72KYK1w=.8adcdf2c-f72f-4b45-a5dc-e82c4eaa571a@github.com>

On Thu, 27 Apr 2023 03:17:25 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> test/jdk/java/util/zip/DeInflate.java line 129:
>> 
>>> 127:         int m = 0;
>>> 128: 
>>> 129:         ByteArrayOutputStream baos = new ByteArrayOutputStream(len);
>> 
>> Is there a reason a try-with-resources is not being used?
>
> Thanks for pointing it out. Please take a look at the latest modifications.

The latest code changes look OK to me. I've added a comment about the test method comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12283#discussion_r1178691247

From asotona at openjdk.org  Thu Apr 27 06:59:53 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Apr 2023 06:59:53 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v14]
In-Reply-To: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
Message-ID: <Ym72hcfDPDjpq0KNErjRaGj3YJxTXAeGwoFIrqYW7z8=.73921a40-4cd3-4c08-b04e-159d1cc99e72@github.com>

> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
> 
> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
> 
> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
> 
> Please review this pull request and attached CSR.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13615/files
  - new: https://git.openjdk.org/jdk/pull/13615/files/efab745b..39980e02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=12-13

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13615/head:pull/13615

PR: https://git.openjdk.org/jdk/pull/13615

From stsypanov at openjdk.org  Thu Apr 27 07:01:23 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 27 Apr 2023 07:01:23 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v3]
In-Reply-To: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
Message-ID: <3KTd3Uwc0ld5LXC3td_XBQ83vEPHtctjJB-ldcFM3-k=.bcd137e2-b931-47ec-9dda-72f190f6f9f3@github.com>

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

Keep alive

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12328#issuecomment-1524890379

From jpai at openjdk.org  Thu Apr 27 07:02:53 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Apr 2023 07:02:53 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v4]
In-Reply-To: <xRc1eO6PXAnqkxbGdg2dwgy7xHEh2ti-ZVhEBG_11dU=.53ddf005-13ab-4783-81c9-6b6f03f514c3@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <xRc1eO6PXAnqkxbGdg2dwgy7xHEh2ti-ZVhEBG_11dU=.53ddf005-13ab-4783-81c9-6b6f03f514c3@github.com>
Message-ID: <EpXUmexTQXacnHmvxkUTEZpALEO-U0C9aR0YVdnwc54=.ff2ab555-ba4e-4381-9d52-a1eb0fb99e09@github.com>

On Thu, 27 Apr 2023 03:25:53 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
>> 
>> Thanks to @jaikiran for amazing PR description.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments from Lance

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12283#pullrequestreview-1403321728

From amitkumar at openjdk.org  Thu Apr 27 07:03:57 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 27 Apr 2023 07:03:57 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v4]
In-Reply-To: <KzXAg6GzPkZYjVnePYX5IBrgxs2NMGhzRFYME7i2j3Y=.55dfdcc9-0154-4af0-834f-2b6e916e41a1@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <xRc1eO6PXAnqkxbGdg2dwgy7xHEh2ti-ZVhEBG_11dU=.53ddf005-13ab-4783-81c9-6b6f03f514c3@github.com>
 <KzXAg6GzPkZYjVnePYX5IBrgxs2NMGhzRFYME7i2j3Y=.55dfdcc9-0154-4af0-834f-2b6e916e41a1@github.com>
Message-ID: <NYDQCcoC3BDOlTi8PS0zsYBe3bCE_Ahc9raCW0GOgP0=.f068997a-bfa8-4740-9e73-4a02c1f326a3@github.com>

On Thu, 27 Apr 2023 06:42:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments from Lance
>
> test/jdk/java/util/zip/DeInflate.java line 124:
> 
>> 122:      * This method checks if a given Deflater and Inflater pair can correctly compress and decompress data.
>> 123:      * checks were performed for this functionality using various input scenarios and ByteBuffer instances.
>> 124:      */
> 
> Would you consider updating this comment to something like:
> 
> 
> /**
>  * Uses the {@code def} deflater to deflate the input data {@code in} of length {@code len}.
>  * A new {@link Inflater} is then created within this method to inflate the deflated data. The
>  * inflated data is then compared with the {@code in} to assert that it matches the original
>  * input data.
>  * This method repeats these checks for the different overloaded methods of
>  * {@code Deflater.deflate(...)} and {@code Inflater.inflate(...)}
>  *
>  * @param def    the deflater to use for deflating the contents in {@code in}
>  * @param in     the input content
>  * @param len    the length of the input content to use
>  * @param nowrap will be passed to the constructor of the {@code Inflater} used in this
>  *               method
>  * @throws Throwable if any error occurs during the check
>  */

fixed :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12283#discussion_r1178705442

From lmesnik at openjdk.org  Thu Apr 27 07:18:23 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 27 Apr 2023 07:18:23 GMT
Subject: RFR: 8306946:
 jdk/test/lib/process/ProcessToolsStartProcessTest.java fails with
 "wrong number of lines in OutputAnalyzer output" [v2]
In-Reply-To: <ISIK6xDSGNSO7Usnt3OXUMae1vVH0RnRjvIz4m3hVts=.1770f58f-1a6a-4dfe-8f27-99d8fa5d1018@github.com>
References: <ISIK6xDSGNSO7Usnt3OXUMae1vVH0RnRjvIz4m3hVts=.1770f58f-1a6a-4dfe-8f27-99d8fa5d1018@github.com>
Message-ID: <AuhLxvUpN1NU7CxSfl0Z2TdEDKlvnKjIYs7_uWozjyY=.e6e5a378-5d43-4c86-908c-857fdc01a93d@github.com>

> The ProcessTools.startProcess (...) has been updated to completely read streams after process has been completed.
> The test was updated to run 5 times with different number of lines and line sizes.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13683/files
  - new: https://git.openjdk.org/jdk/pull/13683/files/c16d33f8..10f1c5c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13683&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13683&range=00-01

  Stats: 9 lines in 2 files changed: 4 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13683/head:pull/13683

PR: https://git.openjdk.org/jdk/pull/13683

From lmesnik at openjdk.org  Thu Apr 27 07:18:28 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 27 Apr 2023 07:18:28 GMT
Subject: RFR: 8306946:
 jdk/test/lib/process/ProcessToolsStartProcessTest.java fails with
 "wrong number of lines in OutputAnalyzer output" [v2]
In-Reply-To: <rjbYoZb-uHk3_xEbmUPnEHPdBJgDLIckBC5PhxbaDaU=.138b9b8e-9b89-411a-b213-d76dff00a9df@github.com>
References: <ISIK6xDSGNSO7Usnt3OXUMae1vVH0RnRjvIz4m3hVts=.1770f58f-1a6a-4dfe-8f27-99d8fa5d1018@github.com>
 <rjbYoZb-uHk3_xEbmUPnEHPdBJgDLIckBC5PhxbaDaU=.138b9b8e-9b89-411a-b213-d76dff00a9df@github.com>
Message-ID: <vTr6aO3DudfCfxtLEBD2RwUUmKvjYtnqni6S64_yybI=.88518ae7-2bb6-40c1-9221-638f693b23ed@github.com>

On Thu, 27 Apr 2023 04:59:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix
>
> test/lib-test/jdk/test/lib/process/ProcessToolsStartProcessTest.java line 79:
> 
>> 77:                 System.out.print("FAILED: wrong number of lines in Consumer output\n");
>> 78:                 success = false;
>> 79:                 System.out.print(out.getStdout());
> 
> Why isn't this printing output?

fixed.

> test/lib-test/jdk/test/lib/process/ProcessToolsStartProcessTest.java line 95:
> 
>> 93:     public static void main(String[] args) throws Exception {
>> 94:         if (args.length > 0) {
>> 95:             for (int i = 0; i < Integer.parseInt(args[0]); i++) {
> 
> This will call parseInt on each iteration of the loop.

fixed.

> test/lib/jdk/test/lib/process/ProcessTools.java line 183:
> 
>> 181:                         // It is needed to wait until stream is flushed after
>> 182:                         // process is completed.
>> 183:                         task.get();
> 
> This looks problematic - if you block here you are holding the object monitor as this is a synchronized method.

You are right. It is needed to give a chance to write to this buffer. fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13683#discussion_r1178707275
PR Review Comment: https://git.openjdk.org/jdk/pull/13683#discussion_r1178707373
PR Review Comment: https://git.openjdk.org/jdk/pull/13683#discussion_r1178708269

From amitkumar at openjdk.org  Thu Apr 27 07:24:24 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 27 Apr 2023 07:24:24 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v5]
In-Reply-To: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
Message-ID: <1AbpMMRE59qHHzfUvJEAsrLjrpcoQ_Fs6wmtfePx5tY=.e4fef466-53f9-497f-908c-ad3db07f4e35@github.com>

> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
> 
> Thanks to @jaikiran for amazing PR description.

Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:

  comment suggestion from @jaikiran

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12283/files
  - new: https://git.openjdk.org/jdk/pull/12283/files/625ad4bb..543d136a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=03-04

  Stats: 14 lines in 1 file changed: 11 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12283.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12283/head:pull/12283

PR: https://git.openjdk.org/jdk/pull/12283

From asotona at openjdk.org  Thu Apr 27 07:42:29 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Apr 2023 07:42:29 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v15]
In-Reply-To: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
Message-ID: <HkXAif0uM5JGMeSLez9vHX8Qj26qqs5VwnEBbUTUHhc=.295f6996-24db-4d37-b762-84e5ece6c55f@github.com>

> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
> 
> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
> 
> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
> 
> Please review this pull request and attached CSR.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  tests update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13615/files
  - new: https://git.openjdk.org/jdk/pull/13615/files/39980e02..0456f775

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13615&range=13-14

  Stats: 26 lines in 2 files changed: 17 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13615/head:pull/13615

PR: https://git.openjdk.org/jdk/pull/13615

From asotona at openjdk.org  Thu Apr 27 07:42:31 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Apr 2023 07:42:31 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v13]
In-Reply-To: <Epehp39BU_sP5TVgtCA4dSNprM-swmdUK3SkApXQRzY=.e5e284b8-e1e2-4695-bd1c-61eac27068fe@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <5nw09YhnRegFOv-IqMqQIyz1CTNRQ4EKKdDQcDGx_zg=.0a148355-4968-468a-af01-e97fe5884782@github.com>
 <Epehp39BU_sP5TVgtCA4dSNprM-swmdUK3SkApXQRzY=.e5e284b8-e1e2-4695-bd1c-61eac27068fe@github.com>
Message-ID: <EhpDXnmaC9pxib0cHd2wUQOUKA5eRzsOmXFprV-wC7M=.691b6b1e-0b33-4dff-9002-dadd34f83f08@github.com>

On Wed, 26 Apr 2023 18:15:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed prefixes from name methods
>
> src/java.base/share/classes/java/lang/constant/ConstantUtils.java line 133:
> 
>> 131:             if ((ch >= '\u0000' && ch <= '\u001F')
>> 132:             || ((ch == '\\' || ch == ':' || ch =='@') && (i == 0 || name.charAt(--i) != '\\')))
>> 133:                 throw new IllegalArgumentException("Invalid module name: " + name);
> 
> test/jdk/java/lang/module/ModuleNames.java has tables of legal and illegal module names, including tests that escape backslash, @, and :. It might be useful to run these tests on this method.

I've updated `ModuleDescTest` with all the positive and negative cases from `test/jdk/java/lang/module/ModuleNames.java`, except for the empty name.
Thanks for the review.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13615#discussion_r1178736304

From asotona at openjdk.org  Thu Apr 27 09:10:00 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Apr 2023 09:10:00 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <0RSPNALx-4ZQAUmXyWGfqegHWlVLu_gM1ZFtpxSXAHA=.6843677f-d9da-4ec2-94b1-a5c3ebee0922@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

I support this addition. Classfile API contains utility method obtaining internal name from `ClassDesc` and it is one of the core pieces.
I don't have any exact measured numbers in my hands now, however `String` conversions are significant CPU consumers in our benchmarks.
In #13671 we are targeting to support conversion-less paths for class building and transformations (by passing the original `ClassDesc` instances through the process). External utility for conversions from `ClassDesc` to internal name does not allow to effectively cache the names and so every repeated need of internal name of the same `ClassDesc` instance will produce a new substring.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1525168031

From pminborg at openjdk.org  Thu Apr 27 09:13:33 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 27 Apr 2023 09:13:33 GMT
Subject: Integrated: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <v6NHtpqSXY2M1fTJ48Z3PX1UK8o3IWCk_NkCgo9MckA=.9fa66033-e7b3-4306-aabf-50d577204ee5@github.com>

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> API changes for the FFM API (third preview)
> 
> ### Specdiff
> https://cr.openjdk.org/~pminborg/panama/21/v2/specdiff/overview-summary.html
> 
> ### Javadoc
> https://cr.openjdk.org/~pminborg/panama/21/v2/javadoc/api/java.base/java/lang/foreign/package-summary.html
> 
> ### Tests
> 
> Testing excludes tests on the "zero" platform. 
> 
> - [X] Tier1
> - [X] Tier2
> - [X] Tier3
> - [X] Tier4
> - [X] Tier5
> - [X] Tier6 (Except one test applications/jcstress/init.java as per below)
> 
> 
> Exception in thread "main" java.lang.IllegalStateException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:66)
> 	at org.openjdk.jcstress.vm.ContendedTestMain.main(ContendedTestMain.java:43)
> Caused by: java.lang.ClassNotFoundException: /opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63432/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b895db82-df34-4e71-9b59-8e23465e55c1/runs/777d38e3-4dd3-42b6-95ca-97f1167b417c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_jcstress_part3/classes/2/applications/jcstress/causality/d/applications/jcstress/JcstressRunner
> 	at java.base/java.lang.Class.forName0(Native Method)
> 	at java.base/java.lang.Class.forName(Class.java:497)
> 	at java.base/java.lang.Class.forName(Class.java:476)
> 	at org.openjdk.jcstress.util.Reflections.getClasses(Reflections.java:64)
> 	... 1 more

This pull request has now been integrated.

Changeset: cbccc4c8
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cbccc4c8172797ea2f1b7c301d00add3f517546d
Stats:     13420 lines in 270 files changed: 5100 ins; 6182 del; 2138 mod

8304265: Implementation of Foreign Function and Memory API (Third Preview)

Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Co-authored-by: Paul Sandoz <psandoz at openjdk.org>
Co-authored-by: Feilong Jiang <fjiang at openjdk.org>
Co-authored-by: Per Minborg <pminborg at openjdk.org>
Reviewed-by: erikj, jvernee, vlivanov, psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/13079

From asotona at openjdk.org  Thu Apr 27 09:23:23 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Apr 2023 09:23:23 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <Q1zwClcVBwwerdZKa9j96ZPdxRWu9pz23WzEJtMn51o=.c035251e-a822-4078-9cc5-866d0a46e4fd@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

src/java.base/share/classes/java/lang/constant/ReferenceClassDescImpl.java line 60:

> 58:     @Override
> 59:     public String internalName() {
> 60:         return isArray() ? descriptorString() : descriptorString().substring(1, descriptorString().length() - 1);

I suggest to cache the internal name to avoid repeated substring-ing with each call.
`ClassDesc` instances are frequently used as static constants serving for generations or transformations of many classes, methods, instructions. 
It is highly expected that if this method is invoked at least once on the particular instance, it will be invoked many times on the same instance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13598#discussion_r1178855034

From jvernee at openjdk.org  Thu Apr 27 09:28:23 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Apr 2023 09:28:23 GMT
Subject: RFR: 8305201: Improve error message for GroupLayouts that are too
 large on SysV [v2]
In-Reply-To: <DwY-xanY3TwoY2JPGLFPQg3bOqI70N1j5tAKv60AIxw=.f892d52c-a641-4275-9619-a8bffc4378b5@github.com>
References: <DwY-xanY3TwoY2JPGLFPQg3bOqI70N1j5tAKv60AIxw=.f892d52c-a641-4275-9619-a8bffc4378b5@github.com>
Message-ID: <PDvb3UieTy7g7HIbTKIn222NhpksxZC-0EIfEEN925Q=.cec5f902-7ef0-4a5c-8646-87e1a5e46e7b@github.com>

> Using for instance a struct layout that contains an unbounded array will produce the exception from the JBS issue.
> 
> This patch checks for the case where a GroupLayout is too large more explicitly, and reports the issue using a more informative exception.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:

 - Add test. Use toIntExact
 - improve error message for too large structs
 - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
   
   rename has_port
 - rename has_port
 - Merge pull request #2 from JornVernee/WSL_BB
   
   account for missing functional in WSL in TestByteBuffer
 - account for missing mincore on WSL in TestByteBuffer
 - Merge branch 'master' into PR_21_V2
 - 8305369: Issues in zero-length memory segment javadoc section
 - 8305087: MemoryLayout API checks should be more eager
 - Merge master
 - ... and 32 more: https://git.openjdk.org/jdk/compare/d8af7a60...8b1dbd31

-------------

Changes: https://git.openjdk.org/jdk/pull/13581/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13581&range=01
  Stats: 13448 lines in 271 files changed: 5126 ins; 6182 del; 2140 mod
  Patch: https://git.openjdk.org/jdk/pull/13581.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13581/head:pull/13581

PR: https://git.openjdk.org/jdk/pull/13581

From jvernee at openjdk.org  Thu Apr 27 09:28:26 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Apr 2023 09:28:26 GMT
Subject: RFR: 8304888: Add dedicated VMProps for linker and fallback linker
 [v2]
In-Reply-To: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
References: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
Message-ID: <8YFcrJ0L8GtOXNi9fS6ZjKCXbBdMtBz-jZe3UxSs_UY=.5c50a6c3-94f8-4bd1-8355-2fe8fec9b0c5@github.com>

> This patch adds a dedicated jtreg property to check which CABI is being used by the JDK, which can be used both to check whether the foreign linker is supported, and whether the fallback linker is being used. (and, possibly it can also be use to check for a particular ABI in case we want to add ABI specific tests).
> 
> Checking whether the foreign linker is supported currently requires using an unwieldy expression that checks if we are running on a platform that has a foreign linker port. Checking for the fallback linker currently uses `vm.flavor != "zero"` which is not always correct, since the fallback linker can also be used on other platforms which are not `zero`.
> 
> To initialize the property, VMProps directly reads `jdk.internal.foreig.CABI::current()`. Since this class is in an internal package, `--add-exports` flags are added as javac flags and VM flags for the extra prop definitions class.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits:

 - use only jdk.CABI property
 - use extra props to check for linker
 - Add fallbackLinker vmprop
 - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
   
   rename has_port
 - rename has_port
 - Merge pull request #2 from JornVernee/WSL_BB
   
   account for missing functional in WSL in TestByteBuffer
 - account for missing mincore on WSL in TestByteBuffer
 - Merge branch 'master' into PR_21_V2
 - 8305369: Issues in zero-length memory segment javadoc section
 - 8305087: MemoryLayout API checks should be more eager
 - ... and 33 more: https://git.openjdk.org/jdk/compare/d8af7a60...aa90690c

-------------

Changes: https://git.openjdk.org/jdk/pull/13429/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13429&range=01
  Stats: 13516 lines in 285 files changed: 5119 ins; 6185 del; 2212 mod
  Patch: https://git.openjdk.org/jdk/pull/13429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13429/head:pull/13429

PR: https://git.openjdk.org/jdk/pull/13429

From asotona at openjdk.org  Thu Apr 27 09:47:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Apr 2023 09:47:54 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <bMTN7Nqn5L2eabRqjHXhovq-XWUXaxHvfW53p_JIGgc=.02ac5e20-c05b-40f0-ba6b-0737d4c33937@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

One comment to the topic of if internal name should include array descriptors.

It should not include array descriptors if it is called internal name, however even with excluded arrays the method will help a lot by caching the internal names and avoiding repeated substringing.

Or it can include also array descriptors if it is  named differently ;)

Classfile API will benefit from both ways.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1525266128

From shade at openjdk.org  Thu Apr 27 09:50:26 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 27 Apr 2023 09:50:26 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v12]
In-Reply-To: <PVpzrnUNYUw9j-v5-l6-V_10Que9IXNlsXhcEuiXP-A=.22b21bed-b619-4a84-b737-9ac46d34374c@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <PVpzrnUNYUw9j-v5-l6-V_10Que9IXNlsXhcEuiXP-A=.22b21bed-b619-4a84-b737-9ac46d34374c@github.com>
Message-ID: <8Ak5D6_aeb2o7uOQKF3TZMQsgcA-gCDniHnI-7ZWnMs=.371ccce9-902e-4a03-a7c7-efe4907693fe@github.com>

On Wed, 26 Apr 2023 20:22:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
>> 
>> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
>> 
>> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
>> 
>> Additional testing:
>>   - [x] New regression test
>>   - [x] New benchmark
>>   - [x] Linux x86_64 `tier1`
>>   - [x] Linux AArch64 `tier1`
>
> Aleksey Shipilev 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 branch 'master' into JDK-83050920-thread-sleep-subms
>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>  - Fix Amazon copyright
>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>  - Drop nanos_to_nanos_bounded
>  - Handle overflows
>  - More review comments
>  - Adjust test times
>  - Windows again
>  - Windows fixes: align(...) is only for power-of-two alignments
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/35e7bc21...da8f0f8c

All right, thank you all! 
I plan to integrate this some time today/tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1525286399

From mdoerr at openjdk.org  Thu Apr 27 12:13:29 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 27 Apr 2023 12:13:29 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v23]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <iHXddOp_wcU1T0OMAAx0jSH2_c9P3W0uCsvjFFFaqm8=.644c7eb8-56fb-4f74-85d3-87f4c83dde8d@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - Enable remaining foreign tests.
 - Adaptations for JDK-8304265.
 - Merge remote-tracking branch 'origin' into PPC64_Panama
 - Adaptation for JDK-8305668
 - Merge remote-tracking branch 'origin' into PPC64_Panama
 - Move ABIv2CallArranger out of linux subdirectory. ABIv1/2 does match the AIX/linux separation.
 - Adaptation for JDK-8303022.
 - Adaptation for JDK-8303684.
 - Merge branch 'openjdk:master' into PPC64_Panama
 - Merge branch 'master' into PPC64_Panama
 - ... and 17 more: https://git.openjdk.org/jdk/compare/1be80a44...84e9dd2f

-------------

Changes: https://git.openjdk.org/jdk/pull/12708/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=22
  Stats: 2556 lines in 70 files changed: 2393 ins; 6 del; 157 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From aturbanov at openjdk.org  Thu Apr 27 12:15:23 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 27 Apr 2023 12:15:23 GMT
Subject: RFR: 8305201: Improve error message for GroupLayouts that are too
 large on SysV [v2]
In-Reply-To: <PDvb3UieTy7g7HIbTKIn222NhpksxZC-0EIfEEN925Q=.cec5f902-7ef0-4a5c-8646-87e1a5e46e7b@github.com>
References: <DwY-xanY3TwoY2JPGLFPQg3bOqI70N1j5tAKv60AIxw=.f892d52c-a641-4275-9619-a8bffc4378b5@github.com>
 <PDvb3UieTy7g7HIbTKIn222NhpksxZC-0EIfEEN925Q=.cec5f902-7ef0-4a5c-8646-87e1a5e46e7b@github.com>
Message-ID: <wFB6EZt7bma0OFFGbxJBApeHcYdoLunPFqhSOdQ66PM=.5a29f17c-b607-4f28-a20e-deacd3536a9f@github.com>

On Thu, 27 Apr 2023 09:28:23 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Using for instance a struct layout that contains an unbounded array will produce the exception from the JBS issue.
>> 
>> This patch checks for the case where a GroupLayout is too large more explicitly, and reports the issue using a more informative exception.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
> 
>  - Add test. Use toIntExact
>  - improve error message for too large structs
>  - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
>    
>    rename has_port
>  - rename has_port
>  - Merge pull request #2 from JornVernee/WSL_BB
>    
>    account for missing functional in WSL in TestByteBuffer
>  - account for missing mincore on WSL in TestByteBuffer
>  - Merge branch 'master' into PR_21_V2
>  - 8305369: Issues in zero-length memory segment javadoc section
>  - 8305087: MemoryLayout API checks should be more eager
>  - Merge master
>  - ... and 32 more: https://git.openjdk.org/jdk/compare/d8af7a60...8b1dbd31

test/jdk/java/foreign/TestByteBuffer.java line 335:

> 333:                     assertEquals(byteBuffer.isReadOnly(), segment.isReadOnly());
> 334:                     assertTrue(byteBuffer.isDirect());
> 335:                 } catch(IOException e) {

nit
Suggestion:

                } catch (IOException e) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13581#discussion_r1179051702

From aturbanov at openjdk.org  Thu Apr 27 12:28:53 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 27 Apr 2023 12:28:53 GMT
Subject: RFR: 8305093: Linker cache should not take layout names into
 account [v2]
In-Reply-To: <7_Nk2AOcLFfPf5yfpg1aAW97junefRNAY857VrpS9xs=.9640e499-4b17-44bc-82ea-406fff99a9cf@github.com>
References: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
 <7_Nk2AOcLFfPf5yfpg1aAW97junefRNAY857VrpS9xs=.9640e499-4b17-44bc-82ea-406fff99a9cf@github.com>
Message-ID: <27L5H7zM9__za6Emqlma2EOdL_yGQFu1gOZyod3bQVk=.f4ddaa25-789f-4fae-b9dc-0c9015309328@github.com>

On Fri, 21 Apr 2023 01:03:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Strip names from the function descriptors used in linkage requests. The names are not important for classification, and this will allow the cached MethodHandle/UpcallStubFactory to be shared across linkage request with the same structure, but with layouts that have different names.
>> 
>> I also have another implementation that avoids copying all the layouts, and instead re-implemented equals and hashCode in the LinkRequest wrapper: https://github.com/openjdk/jdk/compare/pr/13079...JornVernee:jdk:NoNameCache But, this seems too complex. Linking code is not very performance sensitive, so I instead went with a simpler approach in this patch.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use al instead of ValueLayout.ADDRESS

test/jdk/java/foreign/TestByteBuffer.java line 335:

> 333:                     assertEquals(byteBuffer.isReadOnly(), segment.isReadOnly());
> 334:                     assertTrue(byteBuffer.isDirect());
> 335:                 } catch(IOException e) {

nit
Suggestion:

                } catch (IOException e) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13562#discussion_r1179059493

From naoto at openjdk.org  Thu Apr 27 12:49:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 27 Apr 2023 12:49:03 GMT
Subject: RFR: 8306927: Collator treats "v" and "w" as the same letter for
 Swedish language locale.
In-Reply-To: <x8j-huGlphor_LDELRncZ2hwghZhBpli5S96RYQmy98=.04857585-5b8f-4e34-89c9-76a7aff1a120@github.com>
References: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
 <x8j-huGlphor_LDELRncZ2hwghZhBpli5S96RYQmy98=.04857585-5b8f-4e34-89c9-76a7aff1a120@github.com>
Message-ID: <sIYV7T_b2c09kkNhHYWB6x_gAGpCFQi6KXl4VddE0zk=.5e5cae16-4c4c-4cde-99e6-9580fd641db1@github.com>

On Thu, 27 Apr 2023 04:37:08 GMT, Joe Wang <joehw at openjdk.org> wrote:

> The rule was changed in 2006, the year Jave SE 6 was released. Though it looks like very much a corner case, it goes all the way back. I wonder if a CSR is needed?

We don't file a CSR for such a locale data change. These sorts of changes happen in the CLDR upgrade all the time, as well as other i18n-related data changes (currency, timezone, etc.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13677#issuecomment-1525616806

From mdoerr at openjdk.org  Thu Apr 27 12:54:55 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 27 Apr 2023 12:54:55 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v24]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <Vr9eU-MocRqojzzn5eDc29rLeIHY8vDHHrJClAQUGNc=.f8a666a5-7722-4d51-bba2-6abefde3d711@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Revert unintended formatting changes. Fix comment.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/84e9dd2f..7b85fca9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=22-23

  Stats: 189 lines in 6 files changed: 5 ins; 51 del; 133 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From jlaskey at openjdk.org  Thu Apr 27 13:04:54 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 27 Apr 2023 13:04:54 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and
 Anonymous Main Classes (Preview)
Message-ID: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>

Add flexible main methods and anonymous main classes to the Java language.

-------------

Commit messages:
 - Clean up isPreview
 - Missing exception
 - Corrections
 - Update VM.java
 - Clean up testing
 - Update TestJavacTaskScanner.java
 - Merge branch 'master' into 8306112
 - Clean up
 - remnant import
 - Revised main method lookup
 - ... and 2 more: https://git.openjdk.org/jdk/compare/98e8616a...cfe08f33

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306112
  Stats: 1265 lines in 29 files changed: 1111 ins; 62 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From mdoerr at openjdk.org  Thu Apr 27 13:16:22 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 27 Apr 2023 13:16:22 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v24]
In-Reply-To: <Vr9eU-MocRqojzzn5eDc29rLeIHY8vDHHrJClAQUGNc=.f8a666a5-7722-4d51-bba2-6abefde3d711@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <Vr9eU-MocRqojzzn5eDc29rLeIHY8vDHHrJClAQUGNc=.f8a666a5-7722-4d51-bba2-6abefde3d711@github.com>
Message-ID: <f7PQLu5FhSRrfOSJcxm6CjglKWEWm49qXQhLpgDxQm0=.6221dde9-e21f-4a74-9a7d-a1bb331dc3ff@github.com>

On Thu, 27 Apr 2023 12:54:55 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert unintended formatting changes. Fix comment.

Adapted for JDK21, now. All tests have passed. My IDE had changed the formatting which is reverted, now. (I've kept the minor formatting changes in TestDontRelease.java because it looks better.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12708#issuecomment-1525655158

From jlaskey at openjdk.org  Thu Apr 27 13:17:58 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 27 Apr 2023 13:17:58 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v2]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <osNSUyEj1mUrULK9eKwnO1SQqg1OLygKUKCFfoS_lwc=.f8c3e61b-6200-42f3-80cc-51334e4e7502@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  PreviewFeatures.isEnabled()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/cfe08f33..a55af76c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=00-01

  Stats: 32 lines in 3 files changed: 2 ins; 27 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From jpai at openjdk.org  Thu Apr 27 13:26:56 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Apr 2023 13:26:56 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v3]
In-Reply-To: <D9MvQ_DYV4F_dnQeSZUX3QvefhIqSkmLyO2h72KYK1w=.8adcdf2c-f72f-4b45-a5dc-e82c4eaa571a@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <1VOiJqfV7MR0h3qtLDOK6JjmSAiWP8cTOcXP9ZW0nTY=.79b86cdb-ad4f-4c0b-9010-43d385427a28@github.com>
 <50WXvkMN5F6Nkhob1s2v1k4aEWawumoF0JFH3ukyIlQ=.c228a678-66c3-4eeb-837a-a8fcb100b1a4@github.com>
 <5BhQ2Ft1ouUHe8_EAQ2_kNp4g9xpSXM5--hqqzzp7Hg=.1558b182-00ca-4e0d-bd16-a1bcc9a84575@github.com>
 <D9MvQ_DYV4F_dnQeSZUX3QvefhIqSkmLyO2h72KYK1w=.8adcdf2c-f72f-4b45-a5dc-e82c4eaa571a@github.com>
Message-ID: <u3pkL25LzUXufn245dN2L0ze9C3zxqkD8NVaH0rlAy0=.8050cb03-b114-4607-bb29-8d064f034847@github.com>

On Thu, 27 Apr 2023 06:43:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Thanks for pointing it out. Please take a look at the latest modifications.
>
> The latest code changes look OK to me. I've added a comment about the test method comment.

Tests continue to pass on mach5 with these latest changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12283#discussion_r1179130159

From alanb at openjdk.org  Thu Apr 27 13:49:54 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Apr 2023 13:49:54 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v2]
In-Reply-To: <osNSUyEj1mUrULK9eKwnO1SQqg1OLygKUKCFfoS_lwc=.f8c3e61b-6200-42f3-80cc-51334e4e7502@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <osNSUyEj1mUrULK9eKwnO1SQqg1OLygKUKCFfoS_lwc=.f8c3e61b-6200-42f3-80cc-51334e4e7502@github.com>
Message-ID: <FPr8Cf00YVgejbm80QLSH1qAmPHoM-RCJcS4IxXPAC4=.8eada591-9902-4c1d-9260-a0637c2407db@github.com>

On Thu, 27 Apr 2023 13:17:58 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PreviewFeatures.isEnabled()

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 45:

> 43: import java.lang.invoke.MethodHandles;
> 44: import java.lang.invoke.MethodHandles.Lookup;
> 45: import java.lang.invoke.MethodType;

Left over from an earlier version?

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 240:

> 238:      Caused by: {1}: {2}
> 239: java.launcher.cls.error8=\
> 240:     Error: no non-private no argument constructor found in class {0}

Since this feature is for new developers then the error messages will need to be understand, maybe it should be "zero argument" and give an example to help.

src/java.base/share/native/libjli/java.c line 590:

> 588:         CHECK_EXCEPTION_NULL_LEAVE(mainID);
> 589:         (*env)->CallVoidMethod(env, mainObject, mainID);
> 590:         break;

This calls into LauncherHelper to get the "main type", then calls the static or new/instance method. I'm wondering if you tried have a single entry point in LauncherHelper instead. I think the only downside might be that the trampoline would show up in stack traces but @Hidden could hide that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179174808
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179183719
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179172679

From rriggs at openjdk.org  Thu Apr 27 13:54:53 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 27 Apr 2023 13:54:53 GMT
Subject: RFR: 8298993: (process)
 java/lang/ProcessBuilder/UnblockSignals.java fails [v2]
In-Reply-To: <iWHiW4JJiCHgJERISrctccBOnAZgAfsemSDjfZJEQzI=.b60ab5fa-82f5-4e77-9d8d-1fb02ec162d2@github.com>
References: <iWHiW4JJiCHgJERISrctccBOnAZgAfsemSDjfZJEQzI=.b60ab5fa-82f5-4e77-9d8d-1fb02ec162d2@github.com>
Message-ID: <V1nksya8dvzoff7e7mGx8WtnJRF38mrYEhVVQcl3LOw=.512f7f19-7620-4f86-891e-d68b4d874f3f@github.com>

> It appears that -Xcomp causes the relative timing of the commands to be disturbed enough to prevent the correct operation of the test. The test should not be run with -Xcomp

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Change reuqires to use @requires (vm.compMode != "Xcomp")

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13660/files
  - new: https://git.openjdk.org/jdk/pull/13660/files/e66b4970..ad2d13ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13660&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13660&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13660.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13660/head:pull/13660

PR: https://git.openjdk.org/jdk/pull/13660

From jlaskey at openjdk.org  Thu Apr 27 14:11:30 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 27 Apr 2023 14:11:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v64]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <fVWfTck67lnBJ5lbxifBwKLQe4fq4wJ5vtNHN3Vb7uE=.4c8007b7-4a31-4979-869f-9c673a8f56d8@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 83 commits:

 - Merge branch 'master' into 8285932
 - Spacing
 - Tidy up
 - Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from non-public classes
 - Typo
 - HexDigits -> OctalDigits
 - Remove preview feature on package private java.util.Digits
 - Recommended changes
 - Merge branch 'master' into 8285932
 - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
 - ... and 73 more: https://git.openjdk.org/jdk/compare/96cdf93b...5c182232

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=63
  Stats: 9276 lines in 73 files changed: 9179 ins; 23 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From mcimadamore at openjdk.org  Thu Apr 27 15:10:23 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 27 Apr 2023 15:10:23 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v2]
In-Reply-To: <osNSUyEj1mUrULK9eKwnO1SQqg1OLygKUKCFfoS_lwc=.f8c3e61b-6200-42f3-80cc-51334e4e7502@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <osNSUyEj1mUrULK9eKwnO1SQqg1OLygKUKCFfoS_lwc=.f8c3e61b-6200-42f3-80cc-51334e4e7502@github.com>
Message-ID: <NZ5sMaBOg79-lhBtMm44HjHXVL_WAcedBDNGllRgp3Q=.e934db5b-d6c8-4e44-82f5-a92ff2972c56@github.com>

On Thu, 27 Apr 2023 13:17:58 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PreviewFeatures.isEnabled()

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 432:

> 430: 
> 431:     // Restructure top level to be an top level anonymous class.
> 432:     public static void constructAnonymousMainClass(JCCompilationUnit tree,

Question: any reason as to why this is done here and not in the parser? Typically we don't want to do tree transformation at parse time, as that messes up clients that want to access the "non-desugared" tree (such as IDE) and expect some mapping between source to AST. But if you do the rewriting in Enter, not much changes, that is, clients such as IDEs would still see something that doesn't resemble the source.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 2433:

> 2431:         if (kind.contains(KindSelector.TYP)) {
> 2432:             sym = findType(env, name);
> 2433:             if ((sym.flags() & ANONYMOUS_MAIN_CLASS) != 0) {

If `sym` is also `SYNTHTIC` (which it is) - do you need this? In what case? E.g. if there's a legitimate case for this I'm wondering if we should just test for `SYNTHETIC` rather than `ANONYMOUS_MAIN_CLASS`.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/VirtualParser.java line 191:

> 189:      * @param <E> return type of parserAction
> 190:      */
> 191:     public static <E> Optional<E> speculativeParse(JavacParser parser,

Since this is never use, and because of the TODO - should we just drop it for the time being?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179286118
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179288860
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179292509

From joehw at openjdk.org  Thu Apr 27 15:30:29 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 27 Apr 2023 15:30:29 GMT
Subject: RFR: 8306927: Collator treats "v" and "w" as the same letter for
 Swedish language locale.
In-Reply-To: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
References: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
Message-ID: <OB5IdTtYCR4vH1dMCdNiuj__3aNFWmAH6RPWkmNKjTs=.8da87038-a970-45e5-b997-29ec85d88e20@github.com>

On Wed, 26 Apr 2023 20:42:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updating the collation rules for Swedish to the modern one, which is aligned with the CLDR's default collation rules. Since it is changing the existing behavior, a release note has also been drafted: https://bugs.openjdk.org/browse/JDK-8306948

I see. Thanks.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13677#pullrequestreview-1404319290

From darcy at openjdk.org  Thu Apr 27 16:08:55 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 27 Apr 2023 16:08:55 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v2]
In-Reply-To: <osNSUyEj1mUrULK9eKwnO1SQqg1OLygKUKCFfoS_lwc=.f8c3e61b-6200-42f3-80cc-51334e4e7502@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <osNSUyEj1mUrULK9eKwnO1SQqg1OLygKUKCFfoS_lwc=.f8c3e61b-6200-42f3-80cc-51334e4e7502@github.com>
Message-ID: <4Hor93HmsHBhXAvvBBJhqg0fnhw7AxoP2sIcT-WHfZI=.4622066f-8b6f-4350-a5cc-872ee2fc23a9@github.com>

On Thu, 27 Apr 2023 13:17:58 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PreviewFeatures.isEnabled()

I assume future iterations of the PR will include handling and tests for the main class attribute of jar files.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13689#issuecomment-1525943897

From aturbanov at openjdk.org  Thu Apr 27 16:22:24 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 27 Apr 2023 16:22:24 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v5]
In-Reply-To: <1AbpMMRE59qHHzfUvJEAsrLjrpcoQ_Fs6wmtfePx5tY=.e4fef466-53f9-497f-908c-ad3db07f4e35@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <1AbpMMRE59qHHzfUvJEAsrLjrpcoQ_Fs6wmtfePx5tY=.e4fef466-53f9-497f-908c-ad3db07f4e35@github.com>
Message-ID: <415tlj_tmqTIHcOt5mbSrh5deygrbmm0EyhAgg6n-3c=.7f81e6a2-73eb-4e9d-b691-c6b303150899@github.com>

On Thu, 27 Apr 2023 07:24:24 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
>> 
>> Thanks to @jaikiran for amazing PR description.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment suggestion from @jaikiran

test/jdk/java/util/zip/DeInflate.java line 146:

> 144:         def.finish();
> 145: 
> 146:         try(ByteArrayOutputStream baos = new ByteArrayOutputStream(len)) {

Suggestion:

        try (ByteArrayOutputStream baos = new ByteArrayOutputStream(len)) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12283#discussion_r1179401992

From mark.yagnatinsky at barclays.com  Thu Apr 27 16:28:26 2023
From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com)
Date: Thu, 27 Apr 2023 16:28:26 +0000
Subject: blocking peek for blocking queues
In-Reply-To: <MN2PR12MB3616272231DFC69FCCD838D7F96A9@MN2PR12MB3616.namprd12.prod.outlook.com>
References: <MN2PR12MB3616452CA59705B1129E4922F96A9@MN2PR12MB3616.namprd12.prod.outlook.com>
 <MN2PR12MB3616272231DFC69FCCD838D7F96A9@MN2PR12MB3616.namprd12.prod.outlook.com>
Message-ID: <MN2PR12MB36160BCBE7CD59CA75C4D578F96A9@MN2PR12MB3616.namprd12.prod.outlook.com>

Someone said this is the right list for this, so forwarding from jdk-dev with a small tweak

I'd like to make a case for adding a blocking variant of peek() to BlockingQueue.
This has apparently been suggested before:
https://bugs.openjdk.org/browse/JDK-6653412
At the time, the verdict was that the proposed use case for a blocking peek was not very compelling, but " If a compelling use case is available, we may reconsider and reopen this RFE"
For one thing, that use case was inherently racy, and ideally the standard library should not be encouraging races.
And for another thing, this was before the invention of default methods, so a new interface would be needed.
I'd like to present what might be a more sympathetic use case, where a blocking peek actually makes it easier to avoid races.
(This is not hypothetical; I've spent all day trying to cope with the lack of a blocking peek.  I think I succeeded, but it was tough.)

Let's start at the beginning.  The game known as "multithreaded programming" can be played on 3 difficulty levels: easy, medium, and hard.
Easy mode is when the JDK happens to have a high-level tool (e.g., a Collection or an Executor or something) such as DelayQueue that does exactly what you want.
Sadly, the JDK is finite, and even Maven Central is finite, so this not guaranteed to happen, though it's nice when it does.
At the other extreme is hard mode, when every nanosecond counts and you must resort to the sorts of mental gymnastics that were involved when String.hashCode was re-worked to avoid re-computing hash codes equal to zero.

This email is about the medium difficulty level.  In this mode, you must glue together two or three collections to get what you want.
To be concrete, suppose we want to glue a map together with a blocking queue, since that's a simplified version of what I was doing.  (In particular I was using a DelayQueue and a HashMap.)
Since we're not playing on hard mode, we're going to allow ourselves to guard the entire data structure by one giant lock whenever it seems convenient, without worrying about performance.
In fact, let's give a name to this lock.  Since I'm not feeling very creative right now, let's call it LOCK.  Similarly, let's call our compound data structure STRUCT.
My usual heuristic to "win" (that is, to make sure my code is correct, or at least non-racy) on medium difficulty goes something like this.
First, figure out whether there is any way for STRUCT to be "invalid".
For instance, maybe "it's valid if and only if every entry in the queue has a corresponding entry in the map".
One could then write a brief comment in the code explaining what "valid" means, or perhaps even write an "isValid()" method for testing purposes.
Once we've decided what it means for STRUCT to be "valid" (aka, non-corrupt), we can try to maintain the following invariant:
EITHER some thread holds the LOCK, and no other thread is using STRUCT right now,
OR ELSE the LOCK  is not held by any thread, and thus STRUCT is currently in a valid state.
Sometimes the invariant above is a bit too strong, and it's convenient to weaken it slightly.  So we can instead consider the following rule:
RULE: we must never mutate STRUCT unless we hold the LOCK.
If we uphold the invariant, then we must be following the rule, but not vice versa.
(The rule doesn't forbid queries without the lock; it only forbids writes.)

Finally, we come to the point.  The lack of a blocking peek in BlockingQueue has forced me to break the above "weakened" rule.
I had to invent a new much weaker rule, something like "please carefully think through all possible interleaved executions; if they all work, great!".
What went wrong?  Well, one of the methods I wanted on STRUCT was basically "call take() on the queue, and then do things with the result".
The trouble is that you can't usually afford to hold a lock while calling take(), since it can block forever, and in the meantime you've "locked out" anyone who could have added something and thus unblocked you.
Thus, I split my method into two pieces: In PART_ONE we call take() without the LOCK, and once take() returns I grab the lock right away and run PART_TWO.
But notice that this breaks the RULE from the previous paragraph: I mutated the STRUCT without holding the LOCK.
This means my method is not atomic: it's possible for some other thread to observe that PART_ONE is done but PART_TWO is not started.
Typically this means that other threads can now observe the STRUCT in an invalid (aka corrupt/broken) state.

Now, suppose we had a blocking peek.  How does that help?  In that case, we would still break our method into two pieces.
To avoid confusion, let's call them PART_A and PART_B.  In PART_A we call blockingPeek() without holding the LOCK.
Note that we completely ignore the return value from peek; for all we care, the return type is "void" instead of "T".
This breaks the "invariant" from a few paragraphs ago since we're technically "using" the STRUCT but it respects the "rule" since we're not mutating it.
Once peek returns, PART_B begins.  Here, we grab the lock, and do a non-blocking poll() on the queue.
It's might return "null" if someone raced us to get the lock.  But from our perspective that's okay: it's just like a spurious wakeup from a raw wait() call.
The reason it's okay is that we haven't done anything yet, so we can just call blockingPeek() again and hope for better luck next time.
Similarly we don't care if poll() returns a different item than blockingPeek() originally did, since we never looked at what peek() returned.
The rest of PART_B is basically PART_TWO from the "peek-less" world.
Note that this way, our method appears atomic to other threads, since PART_A doesn't actually do anything; all the work happens in PART_B, which is guarded by the LOCK.

Thoughts?

This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com.
__________________________________________________________________________________ 
If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. 
__________________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230427/987ed267/attachment-0001.htm>

From lmesnik at openjdk.org  Thu Apr 27 16:35:59 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 27 Apr 2023 16:35:59 GMT
Subject: RFR: 8306946:
 jdk/test/lib/process/ProcessToolsStartProcessTest.java fails with
 "wrong number of lines in OutputAnalyzer output" [v3]
In-Reply-To: <ISIK6xDSGNSO7Usnt3OXUMae1vVH0RnRjvIz4m3hVts=.1770f58f-1a6a-4dfe-8f27-99d8fa5d1018@github.com>
References: <ISIK6xDSGNSO7Usnt3OXUMae1vVH0RnRjvIz4m3hVts=.1770f58f-1a6a-4dfe-8f27-99d8fa5d1018@github.com>
Message-ID: <tNl8lFnAbvB4l5jQ4k4578XXedv8ZJy8_1_0yukTA5U=.5367ccb5-3f9e-4ab5-b4a0-2f6f69325048@github.com>

> The ProcessTools.startProcess (...) has been updated to completely read streams after process has been completed.
> The test was updated to run 5 times with different number of lines and line sizes.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  move buffers registration before pumping start point

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13683/files
  - new: https://git.openjdk.org/jdk/pull/13683/files/10f1c5c2..d02b889a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13683&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13683&range=01-02

  Stats: 28 lines in 1 file changed: 10 ins; 9 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13683/head:pull/13683

PR: https://git.openjdk.org/jdk/pull/13683

From darcy at openjdk.org  Thu Apr 27 16:44:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 27 Apr 2023 16:44:23 GMT
Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow
In-Reply-To: <-Ka50CkYea3uaNa6zD0ib8vOhQsb2iua034WP76-m8A=.9fecfae8-a00f-4ae1-94e2-8c8ea19c8474@github.com>
References: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
 <rsynWzA2MZRyUAuiPsnpwSTQV32u7NbQHd4jT8H_NrU=.987c8f96-f642-4426-bab3-6ec5c2d70257@github.com>
 <-Ka50CkYea3uaNa6zD0ib8vOhQsb2iua034WP76-m8A=.9fecfae8-a00f-4ae1-94e2-8c8ea19c8474@github.com>
Message-ID: <hJuD_3fLz3jiLh8uP8MnUFzodStUkevYynbtpTDhkPE=.eb3f5eaf-86e4-4a6e-86cc-af0531d79ddb@github.com>

On Wed, 26 Apr 2023 08:30:07 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> No, that would not be correct. It would be subject to [double rounding](https://en.wikipedia.org/wiki/Rounding#Double_rounding), against the spec.
> 
> For example, `BigDecimal` 1.000000059604644775390626 should round to `float` `1.0000001f`. When going to the closest `double` and then to the closest `float`, however, it first rounds to `double` `1.0000000596046448` and the to `float` `1.0f`.

Ah right; thanks for the correction -- since the set of possible inputs in this case isn't constrained by operations on float values, the 2p+2 property that hold for {+, -, *, /, sqrt} doesn't hold here.

> I have no objections as long as it is a 1 letter name that does not conflict with others. Have you a preferred one?

I usually use "bd" or "bi" for such BigDecima/BigInteger variables myself and use "d" for double; "v" or "w" have integer-ish feel to me so perhaps one of those?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/9410#discussion_r1179424759
PR Review Comment: https://git.openjdk.org/jdk/pull/9410#discussion_r1179432887

From simonis at openjdk.org  Thu Apr 27 16:44:54 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 27 Apr 2023 16:44:54 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v3]
In-Reply-To: <uR_pQqxD1LklDBWG8214aqtUmCyVscGPXfSOMTusLOs=.9e6a99d2-a094-443c-b78c-18dbc98f4842@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <oJ8ZXUlfXgCGsf2GUdqu9lqihPWAP9-L1JslWzGmc0s=.cbf6ded7-1c9e-4425-a570-ff3be20c8eda@github.com>
 <uR_pQqxD1LklDBWG8214aqtUmCyVscGPXfSOMTusLOs=.9e6a99d2-a094-443c-b78c-18dbc98f4842@github.com>
Message-ID: <FqNUX5jK5ZXj9IZ3GEaMIohqNpMi3LaUyvx7gAAuC0I=.4e44943d-c4d0-4144-b467-6b30233a6cc1@github.com>

On Wed, 26 Apr 2023 12:47:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8306461
>>  - Simplified exception message and fixed test to check the correct message
>>  - Addresed review comments of @turbanoff, @shipilev and @RogerRiggs
>>  - 8306461: ObjectInputStream::readObject() should handle negative array sizes without throwing NegativeArraySizeExceptions
>
> A bit more investigation is needed.   
> I noticed that ObjectInputStream.checkArray throws NegativeArraySizeException if length is < 0 before calling filterCheck.
> The checkArray method is called via SharedSecrets to check array sizes on some of the collection classes during deserialization.
> Likely, the change should be extended to cover negative lengths in those cases too.

Hi @RogerRiggs ,

I've checked the callers of `checkArray()` and found 13, all of them in the corresponding `readObject()` methods:

| class | NASE | exception |
|:----- |:----:|:--------- |
| `j.u.IdentityHashMap` | + | StreamCorruptedException("Illegal mappings count: " + size) |
| `j.u.HashMap` | + | InvalidObjectException("Illegal mappings count: " + mappings) |
| `j.u.Properties` | + | StreamCorruptedException("Illegal # of Elements: " + elements) |
| `j.u.ArrayList` | + | InvalidObjectException("Invalid size: " + size) |
| `j.u.ImmutableCollections` | + | InvalidObjectException("negative length " + len) |
| `j.u.Hashtable` | + | StreamCorruptedException("Illegal # of Elements: " + elements) |
| `j.u.HashSet` | + | InvalidObjectException("Illegal capacity: " + capacity) |
| `jx.m.o.TabularDataSupport` | (+) | (depends on ArrayList) |
| `j.u.concurrent/PriorityBlockingQueue` | (-) | (depends on PriorityQueue) |
| `j.u.PriorityQueue` | - | |
| `j.u.ArrayDeque` | - | |
| `j.u.concurrent/CopyOnWriteArrayList` | - | |
| `j.u.Collections` | - | |

The occurrences with a "+" int he "NASE" column all already handle the negative array size case **before** calling `ObjectInputStream.checkArray()` and throw the exceptions listed in the "exception" column if the array size is negative.

So instead of changing `ObjectInputStream.checkArray()` maybe it makes sense to fix the remaining four classes (i.e. `PriorityQueue`, `ArrayDeque`, `CopyOnWriteArrayList` and `Collections`) to handle negative array sizes in their corresponding  `readObject()` methods as well? This somehow feels more natural to me, because, other then within the initial issue, this is not a problem of the deserialization protocol, but rather  an issue with custom deserialization code in the the `readObject()` methods. Therefor I also think it would make sense to handle that as a different issue. What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13540#issuecomment-1525999475

From dcubed at openjdk.org  Thu Apr 27 17:05:59 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 27 Apr 2023 17:05:59 GMT
Subject: RFR: 8306946:
 jdk/test/lib/process/ProcessToolsStartProcessTest.java fails with
 "wrong number of lines in OutputAnalyzer output" [v3]
In-Reply-To: <tNl8lFnAbvB4l5jQ4k4578XXedv8ZJy8_1_0yukTA5U=.5367ccb5-3f9e-4ab5-b4a0-2f6f69325048@github.com>
References: <ISIK6xDSGNSO7Usnt3OXUMae1vVH0RnRjvIz4m3hVts=.1770f58f-1a6a-4dfe-8f27-99d8fa5d1018@github.com>
 <tNl8lFnAbvB4l5jQ4k4578XXedv8ZJy8_1_0yukTA5U=.5367ccb5-3f9e-4ab5-b4a0-2f6f69325048@github.com>
Message-ID: <ijrmbPlqI8XyTjSeB4X2MZ3i63GGxaHT9rlkhF4CoBU=.fbe69c2f-f602-4b4c-b689-2bc26420846a@github.com>

On Thu, 27 Apr 2023 16:35:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The ProcessTools.startProcess (...) has been updated to completely read streams after process has been completed.
>> The test was updated to run 5 times with different number of lines and line sizes.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move buffers registration before pumping start point

What Mach5 testing has been done with this fix?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13683#issuecomment-1526034233

From amitkumar at openjdk.org  Thu Apr 27 17:05:24 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 27 Apr 2023 17:05:24 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v6]
In-Reply-To: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
Message-ID: <-EO2E5Juy8oYDmqHcd5420Ot3FUTWuDVcKrMQGvkAHM=.cabe3e0d-f204-4f60-80c2-ad75a8424b9b@github.com>

> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
> 
> Thanks to @jaikiran for amazing PR description.

Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:

  changes request by @turbanoff

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12283/files
  - new: https://git.openjdk.org/jdk/pull/12283/files/543d136a..bbeb8b27

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12283.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12283/head:pull/12283

PR: https://git.openjdk.org/jdk/pull/12283

From amitkumar at openjdk.org  Thu Apr 27 17:06:00 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 27 Apr 2023 17:06:00 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v5]
In-Reply-To: <415tlj_tmqTIHcOt5mbSrh5deygrbmm0EyhAgg6n-3c=.7f81e6a2-73eb-4e9d-b691-c6b303150899@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <1AbpMMRE59qHHzfUvJEAsrLjrpcoQ_Fs6wmtfePx5tY=.e4fef466-53f9-497f-908c-ad3db07f4e35@github.com>
 <415tlj_tmqTIHcOt5mbSrh5deygrbmm0EyhAgg6n-3c=.7f81e6a2-73eb-4e9d-b691-c6b303150899@github.com>
Message-ID: <pD9afiPSat3bDTx7vApr2RvgAVgrQU-brW8hMG1gJu4=.da5ed011-7911-4249-a0a9-64ac52aba3bf@github.com>

On Thu, 27 Apr 2023 16:08:10 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment suggestion from @jaikiran
>
> test/jdk/java/util/zip/DeInflate.java line 146:
> 
>> 144:         def.finish();
>> 145: 
>> 146:         try(ByteArrayOutputStream baos = new ByteArrayOutputStream(len)) {
> 
> Suggestion:
> 
>         try (ByteArrayOutputStream baos = new ByteArrayOutputStream(len)) {

fixed :-) 

Thanks for review.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12283#discussion_r1179437598

From rgiulietti at openjdk.org  Thu Apr 27 17:11:04 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 27 Apr 2023 17:11:04 GMT
Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow [v2]
In-Reply-To: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
References: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
Message-ID: <87PMgvD2Izc2UarLpNIwbjuFcCcv3Tb7-kX42vwiWCE=.f9d218ea-84b6-45e9-a62d-dcedcbdc1bc2@github.com>

> A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Renamed local variable b to w in full[Float|Double]Value().

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9410/files
  - new: https://git.openjdk.org/jdk/pull/9410/files/75fde901..f679fb2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9410&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9410&range=00-01

  Stats: 25 lines in 1 file changed: 0 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/9410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/9410/head:pull/9410

PR: https://git.openjdk.org/jdk/pull/9410

From jlaskey at openjdk.org  Thu Apr 27 17:21:23 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 27 Apr 2023 17:21:23 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v65]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  CSR recommendations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/5c182232..fb406d23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=64
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=63-64

  Stats: 115 lines in 3 files changed: 71 ins; 27 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From rgiulietti at openjdk.org  Thu Apr 27 17:21:59 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 27 Apr 2023 17:21:59 GMT
Subject: Integrated: 8205592: BigDecimal.doubleValue() is depressingly slow
In-Reply-To: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
References: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
Message-ID: <uNB90j9EjtsvTukDIiy4L3RlYk5-WTdxaTphqDkqwrE=.79429560-1ce1-4261-bb7f-ffb1700aff13@github.com>

On Thu, 7 Jul 2022 15:20:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path.

This pull request has now been integrated.

Changeset: eb358619
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb358619dfc344348d72cfe29d50829ba7ca1aea
Stats:     585 lines in 2 files changed: 545 ins; 8 del; 32 mod

8205592: BigDecimal.doubleValue() is depressingly slow

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/9410

From lmesnik at openjdk.org  Thu Apr 27 17:31:23 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 27 Apr 2023 17:31:23 GMT
Subject: RFR: 8306946:
 jdk/test/lib/process/ProcessToolsStartProcessTest.java fails with
 "wrong number of lines in OutputAnalyzer output" [v3]
In-Reply-To: <tNl8lFnAbvB4l5jQ4k4578XXedv8ZJy8_1_0yukTA5U=.5367ccb5-3f9e-4ab5-b4a0-2f6f69325048@github.com>
References: <ISIK6xDSGNSO7Usnt3OXUMae1vVH0RnRjvIz4m3hVts=.1770f58f-1a6a-4dfe-8f27-99d8fa5d1018@github.com>
 <tNl8lFnAbvB4l5jQ4k4578XXedv8ZJy8_1_0yukTA5U=.5367ccb5-3f9e-4ab5-b4a0-2f6f69325048@github.com>
Message-ID: <iq6XxLFhWl4fNuDjCzT4Qaqh7EDTtm9xFESgtaTjQM0=.5208f06e-3bff-4ae2-b27a-057872d7d90f@github.com>

On Thu, 27 Apr 2023 16:35:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The ProcessTools.startProcess (...) has been updated to completely read streams after process has been completed.
>> The test was updated to run 5 times with different number of lines and line sizes.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move buffers registration before pumping start point

The testing: 
 - tier1 - tier5 to verify that nothing is brokens,
 - run  jdk/test/lib/process/ProcessToolsStartProcessTest.java with 50 iterations instead of 5 on each platform 100 times
 - manually added some thread.sleep into startProcess and verify that not failures still appear

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13683#issuecomment-1526061664

From liach at openjdk.org  Thu Apr 27 17:31:23 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Apr 2023 17:31:23 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <H-SHnod5sAqUwO6VmbawYwmvKaWExBzCg43tJxSARa0=.a2cbf7b1-3438-4be4-bd31-c8d41e20df95@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

For API design, I have 3 choices for the accessor method:
1. Return Optional<String> only for internal names for classes or interfaces; Optional.empty() for primitives and arrays
2. Return Optional<String> suitable for CONSTANT_Class_info; Optional.empty() for primitives
3. Return String suitable for CONSTANT_Class_info; throw for primitives

Which route should I take? I personally reject 1 as internal names are meaningless if they are used alone without being part of CONSTANT_Class_info. For 2 and 3, the main problem is the overhead of Optional vs whether there are better ways to detect if a class cannot be encoded in CONSTANT_Class_info (for now it's only primitives, but valhalla might change that if non-null types are loadable but cannot be in CONSTANT_Class_info)

On second thought, I think I will go option 2; it will be in line with `Class.describeConstable()`; though the current check is based on `Class.isHidden()`, criteria may change when Valhalla is out, and `describeConstable()` is better suited for future API evolutions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1526055365

From mchung at openjdk.org  Thu Apr 27 17:31:53 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 27 Apr 2023 17:31:53 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <FW7aQFUWxGiZARnpzynHvxHnZX9HAHvKHeTL_2z0VpA=.d27712c6-2269-4a5e-adb6-3b2586c76e24@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

4. Return a string representation of internal name for a class or interface and a descriptor string for a primitive type and array.  The method could be called `classDescString`.  The caller can test if this `ClassDesc` is not a primitive if it wants the string for a class or interface or an array.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1526066216

From mchhipa at openjdk.org  Thu Apr 27 17:35:12 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 27 Apr 2023 17:35:12 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v4]
In-Reply-To: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
Message-ID: <pC4U4hXLT4yWyOrZ3uSxaGBlnEfcBP2uJl1g95SoNkg=.fcdb924f-5639-42ce-bb6d-b636a905e6de@github.com>

> Test is updated to create the binary files during test execution.

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Implemented the review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13537/files
  - new: https://git.openjdk.org/jdk/pull/13537/files/45567f28..f867ba2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=02-03

  Stats: 837 lines in 6 files changed: 764 ins; 19 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/13537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13537/head:pull/13537

PR: https://git.openjdk.org/jdk/pull/13537

From mchung at openjdk.org  Thu Apr 27 17:56:25 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 27 Apr 2023 17:56:25 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <TS357affytdyod7oVIkGDIK2FX7zEiujfDzZV2R9cyo=.551fd8b6-d71c-4335-b50e-a3d63ac5451b@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

With option 4, `ConstantPoolBuilder::classEntry` can simply become:


    default ClassEntry classEntry(ClassDesc classDesc) {
        return classEntry(utf8Entry(classDesc.classDescString()));
    }

vs option 2:


    default ClassEntry classEntry(ClassDesc classDesc) {
        return classEntry(utf8Entry(classDesc.isPrimitive()
                    ? classDesc.descriptorString()
                    : classDesc.internalName().get()));
    }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1526089568

From liach at openjdk.org  Thu Apr 27 17:56:58 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Apr 2023 17:56:58 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <FW7aQFUWxGiZARnpzynHvxHnZX9HAHvKHeTL_2z0VpA=.d27712c6-2269-4a5e-adb6-3b2586c76e24@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
 <FW7aQFUWxGiZARnpzynHvxHnZX9HAHvKHeTL_2z0VpA=.d27712c6-2269-4a5e-adb6-3b2586c76e24@github.com>
Message-ID: <7GIbFg2T_bREw3c9lSbVU9WrCYlmRuGRFh5Fe02VfYg=.ddb3e348-eb5b-499c-88ca-e9cbd76c1449@github.com>

On Thu, 27 Apr 2023 17:23:58 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> 4. Return a string representation of internal name for a class or interface and a descriptor string for a primitive type and array.  The method could be called `classDescString`.  The caller can test if this `ClassDesc` is not a primitive if it wants the string for a class or interface or an array.

I think I will still resort to an `Optional`.

Pros of Optional:
1. Clearly indicates to users that some ClassDesc cannot be converted to a CONSTANT_Class_info string, than failing at primitive classes at runtime (#12996)
2. Anticipates valhalla changes; if non-null types in Valhalla has descriptors but cannot be encoded in CONSTANT_Class_info, then users that check Optional will not break, as opposed to checking isPrimitive (similar story with `Lookup::hasPrivateAccess`)

Cons of Optional:
1. Needs wrap and unwrap, not beautiful in code and has no pattern matching
   - The unwrap performance overhead will be gone in Valhalla with value classes

So, I most likely will add `ClassDesc.ofClassDescString()` and `ClassDesc.classDescString()` returning `Optional<String>` to interact with `CONSTANT_Class_info`.

With this new model, we will have:

    default ClassEntry classEntry(ClassDesc classDesc) {
        return classEntry(utf8Entry(classDesc.classDescString().orElseThrow(() -> new IllegalArgumentException(classDesc + " cannot be encoded as ClassEntry"))));
    }


which will take care of non-primitive cases from valhalla.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1526093150

From mchung at openjdk.org  Thu Apr 27 18:05:53 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 27 Apr 2023 18:05:53 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <xQ6mnoGo2kChepMjkTKUPkGb8LBjNuS4G5tJuDUD0XE=.f8f521d6-b4ff-4b3b-b17a-78fa0175bf6d@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

`ClassDesc.ofClassDescString("I")` can't differentiate if it's a primitive or an internal name of class `I`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1526105072

From liach at openjdk.org  Thu Apr 27 18:18:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Apr 2023 18:18:53 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <xQ6mnoGo2kChepMjkTKUPkGb8LBjNuS4G5tJuDUD0XE=.f8f521d6-b4ff-4b3b-b17a-78fa0175bf6d@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
 <xQ6mnoGo2kChepMjkTKUPkGb8LBjNuS4G5tJuDUD0XE=.f8f521d6-b4ff-4b3b-b17a-78fa0175bf6d@github.com>
Message-ID: <ut5M2gEXvPeM5rMFaNDJLPmz5YsPGlOEMDiHtuW4ecU=.72c3fc02-05c4-4b14-bfda-0a12d3ad2530@github.com>

On Thu, 27 Apr 2023 17:58:02 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `ClassDesc.ofClassDescString("I")` can't differentiate if it's a primitive or an internal name of class `I`.

It is always treated as an internal name when it is without a `[` prefix. if class `I` in the unnamed package is stored in a `CONSTANT_Class_info`, then it is class(utf8("I")) in the constant pool, or `LI;` as a descriptor. I will add an API note informing users not to pass non-CONSTANT_Class_info strings into this factory.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1526114117

From tonyp at openjdk.org  Thu Apr 27 18:21:25 2023
From: tonyp at openjdk.org (Antonios Printezis)
Date: Thu, 27 Apr 2023 18:21:25 GMT
Subject: RFR: JDK-8307063: When cross-compiling with hsdis/binutils,
 buildjdk creation fails
Message-ID: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>

Fix is to exclude hsdis when building the buildjdk.

-------------

Commit messages:
 - JDK-8307063: When cross-compiling with hsdis/binutils, buildjdk creation fails

Changes: https://git.openjdk.org/jdk/pull/13697/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13697&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307063
  Stats: 27 lines in 2 files changed: 6 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/13697.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13697/head:pull/13697

PR: https://git.openjdk.org/jdk/pull/13697

From jlaskey at openjdk.org  Thu Apr 27 18:21:56 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 27 Apr 2023 18:21:56 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v3]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into 8306112
 - PreviewFeatures.isEnabled()
 - Clean up isPreview
 - Missing exception
 - Corrections
 - Update VM.java
 - Clean up testing
 - Update TestJavacTaskScanner.java
 - Merge branch 'master' into 8306112
 - Clean up
 - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d

-------------

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=02
  Stats: 1240 lines in 29 files changed: 1086 ins; 62 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From jlaskey at openjdk.org  Thu Apr 27 18:22:23 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 27 Apr 2023 18:22:23 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v2]
In-Reply-To: <FPr8Cf00YVgejbm80QLSH1qAmPHoM-RCJcS4IxXPAC4=.8eada591-9902-4c1d-9260-a0637c2407db@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <osNSUyEj1mUrULK9eKwnO1SQqg1OLygKUKCFfoS_lwc=.f8c3e61b-6200-42f3-80cc-51334e4e7502@github.com>
 <FPr8Cf00YVgejbm80QLSH1qAmPHoM-RCJcS4IxXPAC4=.8eada591-9902-4c1d-9260-a0637c2407db@github.com>
Message-ID: <5Gfuey8swtt5kH7aGU7aQNwU80KcoCFJ2hZxxGO2tnk=.75eb7117-299b-449a-b3a2-6ef27de44ac0@github.com>

On Thu, 27 Apr 2023 13:39:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   PreviewFeatures.isEnabled()
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 45:
> 
>> 43: import java.lang.invoke.MethodHandles;
>> 44: import java.lang.invoke.MethodHandles.Lookup;
>> 45: import java.lang.invoke.MethodType;
> 
> Left over from an earlier version?

Yep.

> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 240:
> 
>> 238:      Caused by: {1}: {2}
>> 239: java.launcher.cls.error8=\
>> 240:     Error: no non-private no argument constructor found in class {0}
> 
> Since this feature is for new developers then the error messages will need to be understand, maybe it should be "zero argument" and give an example to help.

java.launcher.cls.error8=\
    Error: no non-private zero argument constructor found in class {0}\n\
    remove private from existing constructor or define as:\n\
\   public {0}() {}

> src/java.base/share/native/libjli/java.c line 590:
> 
>> 588:         CHECK_EXCEPTION_NULL_LEAVE(mainID);
>> 589:         (*env)->CallVoidMethod(env, mainObject, mainID);
>> 590:         break;
> 
> This calls into LauncherHelper to get the "main type", then calls the static or new/instance method. I'm wondering if you tried have a single entry point in LauncherHelper instead. I think the only downside might be that the trampoline would show up in stack traces but @Hidden could hide that.

Good idea. If @hidden doesn't work then we can eat the trace entries.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179518999
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179528956
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179517981

From jlaskey at openjdk.org  Thu Apr 27 18:22:26 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 27 Apr 2023 18:22:26 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v2]
In-Reply-To: <NZ5sMaBOg79-lhBtMm44HjHXVL_WAcedBDNGllRgp3Q=.e934db5b-d6c8-4e44-82f5-a92ff2972c56@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <osNSUyEj1mUrULK9eKwnO1SQqg1OLygKUKCFfoS_lwc=.f8c3e61b-6200-42f3-80cc-51334e4e7502@github.com>
 <NZ5sMaBOg79-lhBtMm44HjHXVL_WAcedBDNGllRgp3Q=.e934db5b-d6c8-4e44-82f5-a92ff2972c56@github.com>
Message-ID: <JsW0BPXwm7LqXDuU2jooiHkTzcgAPq0xXMi0bkUul-M=.54c83444-2f55-4d0c-906a-78f35890f284@github.com>

On Thu, 27 Apr 2023 14:55:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   PreviewFeatures.isEnabled()
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 2433:
> 
>> 2431:         if (kind.contains(KindSelector.TYP)) {
>> 2432:             sym = findType(env, name);
>> 2433:             if ((sym.flags() & ANONYMOUS_MAIN_CLASS) != 0) {
> 
> If `sym` is also `SYNTHTIC` (which it is) - do you need this? In what case? E.g. if there's a legitimate case for this I'm wondering if we should just test for `SYNTHETIC` rather than `ANONYMOUS_MAIN_CLASS`.

Yes, this is a remnant from earlier work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179530497

From bchristi at openjdk.org  Thu Apr 27 18:30:30 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 27 Apr 2023 18:30:30 GMT
Subject: RFR: 8298993: (process)
 java/lang/ProcessBuilder/UnblockSignals.java fails [v2]
In-Reply-To: <V1nksya8dvzoff7e7mGx8WtnJRF38mrYEhVVQcl3LOw=.512f7f19-7620-4f86-891e-d68b4d874f3f@github.com>
References: <iWHiW4JJiCHgJERISrctccBOnAZgAfsemSDjfZJEQzI=.b60ab5fa-82f5-4e77-9d8d-1fb02ec162d2@github.com>
 <V1nksya8dvzoff7e7mGx8WtnJRF38mrYEhVVQcl3LOw=.512f7f19-7620-4f86-891e-d68b4d874f3f@github.com>
Message-ID: <r6BoQ9U9Sw3Mkq0Oe9b5pXPupT7LuO-5hubcqFjRcd0=.e7c99620-9834-4ccf-a7ce-3a937427425c@github.com>

On Thu, 27 Apr 2023 13:54:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> It appears that -Xcomp causes the relative timing of the commands to be disturbed enough to prevent the correct operation of the test. The test should not be run with -Xcomp
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change reuqires to use @requires (vm.compMode != "Xcomp")

Marked as reviewed by bchristi (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13660#pullrequestreview-1404626660

From erikj at openjdk.org  Thu Apr 27 18:30:26 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 27 Apr 2023 18:30:26 GMT
Subject: RFR: JDK-8307063: When cross-compiling with hsdis/binutils,
 buildjdk creation fails
In-Reply-To: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>
References: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>
Message-ID: <YABjBrZtnONUjyGDZAMayjEelhuGTUCoHKb5cWCcf94=.6cb9f845-9a1c-46ea-8c08-2c1d847afa31@github.com>

On Thu, 27 Apr 2023 17:57:05 GMT, Antonios Printezis <tonyp at openjdk.org> wrote:

> Fix is to exclude hsdis when building the buildjdk.

This looks like it should work, but I would like to avoid sprinkling any more CREATING_BUILDJDK conditionals throughout the build than absolutely necessary. I think it would be better to just override `HSDIS_BACKEND` and `ENABLE_HSDIS_BUNDLING` in `buildjdk-spec.gmk.in` with a comment that hsdis should never be enabled in the buildjdk. I haven't tested it though so I may be missing something.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13697#pullrequestreview-1404637087

From naoto at openjdk.org  Thu Apr 27 18:34:23 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 27 Apr 2023 18:34:23 GMT
Subject: Integrated: 8306927: Collator treats "v" and "w" as the same letter
 for Swedish language locale.
In-Reply-To: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
References: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
Message-ID: <g6vRExS-qEe5UeT6IwNwVGpAQzxfbVb59C9uMCgL0-o=.9b865134-649c-4603-a611-d469fbe7d652@github.com>

On Wed, 26 Apr 2023 20:42:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updating the collation rules for Swedish to the modern one, which is aligned with the CLDR's default collation rules. Since it is changing the existing behavior, a release note has also been drafted: https://bugs.openjdk.org/browse/JDK-8306948

This pull request has now been integrated.

Changeset: 6983d05b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6983d05b73258f11dcb35bc3961b724ba58d9667
Stats:     50 lines in 2 files changed: 45 ins; 4 del; 1 mod

8306927: Collator treats "v" and "w" as the same letter for Swedish language locale.

Reviewed-by: jlu, iris, joehw

-------------

PR: https://git.openjdk.org/jdk/pull/13677

From tonyp at openjdk.org  Thu Apr 27 18:41:59 2023
From: tonyp at openjdk.org (Antonios Printezis)
Date: Thu, 27 Apr 2023 18:41:59 GMT
Subject: RFR: JDK-8307063: When cross-compiling with hsdis/binutils,
 buildjdk creation fails
In-Reply-To: <YABjBrZtnONUjyGDZAMayjEelhuGTUCoHKb5cWCcf94=.6cb9f845-9a1c-46ea-8c08-2c1d847afa31@github.com>
References: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>
 <YABjBrZtnONUjyGDZAMayjEelhuGTUCoHKb5cWCcf94=.6cb9f845-9a1c-46ea-8c08-2c1d847afa31@github.com>
Message-ID: <hokRx_RZZG0J3VfFYpy5nQd8DhOQjVZ0w6n8kc3xbmk=.2b73903d-a8c7-45d3-b1f5-580d26cf65bb@github.com>

On Thu, 27 Apr 2023 18:19:49 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This looks like it should work, but I would like to avoid sprinkling any more CREATING_BUILDJDK conditionals throughout the build than absolutely necessary. I think it would be better to just override `HSDIS_BACKEND` and `ENABLE_HSDIS_BUNDLING` in `buildjdk-spec.gmk.in` with a comment that hsdis should never be enabled in the buildjdk. I haven't tested it though so I may be missing something.

I haven't looked at the build scripts for quite a while! Let me try what you suggested and see if it works. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13697#issuecomment-1526144046

From jlaskey at openjdk.org  Thu Apr 27 18:44:53 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 27 Apr 2023 18:44:53 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v2]
In-Reply-To: <NZ5sMaBOg79-lhBtMm44HjHXVL_WAcedBDNGllRgp3Q=.e934db5b-d6c8-4e44-82f5-a92ff2972c56@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <osNSUyEj1mUrULK9eKwnO1SQqg1OLygKUKCFfoS_lwc=.f8c3e61b-6200-42f3-80cc-51334e4e7502@github.com>
 <NZ5sMaBOg79-lhBtMm44HjHXVL_WAcedBDNGllRgp3Q=.e934db5b-d6c8-4e44-82f5-a92ff2972c56@github.com>
Message-ID: <YopNQ7jjAg7Z64IZkD_2as39dBcUj0hHWKB8S17VlDc=.9168990a-2444-4c0a-afac-bc8640742f76@github.com>

On Thu, 27 Apr 2023 14:53:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   PreviewFeatures.isEnabled()
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 432:
> 
>> 430: 
>> 431:     // Restructure top level to be an top level anonymous class.
>> 432:     public static void constructAnonymousMainClass(JCCompilationUnit tree,
> 
> Question: any reason as to why this is done here and not in the parser? Typically we don't want to do tree transformation at parse time, as that messes up clients that want to access the "non-desugared" tree (such as IDE) and expect some mapping between source to AST. But if you do the rewriting in Enter, not much changes, that is, clients such as IDEs would still see something that doesn't resemble the source.

The source file name is not available until after parsing.

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/VirtualParser.java line 191:
> 
>> 189:      * @param <E> return type of parserAction
>> 190:      */
>> 191:     public static <E> Optional<E> speculativeParse(JavacParser parser,
> 
> Since this is never use, and because of the TODO - should we just drop it for the time being?

dropping

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179543180
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179534229

From mchung at openjdk.org  Thu Apr 27 18:55:22 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 27 Apr 2023 18:55:22 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <iIc0Knd8hPQ252YvRMb-RHHqRWI7k6-ZzrPnhyjo9dk=.ab1d9d02-fdb9-46d2-b324-01992441bd62@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

I consulted with @briangoetz.  The internal name should probably be cached in the ClassFile API implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1526151053

From smarks at openjdk.org  Thu Apr 27 18:57:23 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 27 Apr 2023 18:57:23 GMT
Subject: RFR: 8296935: Arrays.asList() can return a List that throws
 undocumented ArrayStoreException
Message-ID: <pgp8ceubOPPxYan0QoWmM4QSByWwlenrFGIvtpF61pc=.1f8f0180-6f0f-4110-9921-7864dd3eecaf@github.com>

?

-------------

Commit messages:
 - 8296935: Arrays.asList() can return a List that throws undocumented ArrayStoreException

Changes: https://git.openjdk.org/jdk/pull/13698/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13698&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296935
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13698.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13698/head:pull/13698

PR: https://git.openjdk.org/jdk/pull/13698

From smarks at openjdk.org  Thu Apr 27 18:57:24 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 27 Apr 2023 18:57:24 GMT
Subject: RFR: 8296935: Arrays.asList() can return a List that throws
 undocumented ArrayStoreException
In-Reply-To: <pgp8ceubOPPxYan0QoWmM4QSByWwlenrFGIvtpF61pc=.1f8f0180-6f0f-4110-9921-7864dd3eecaf@github.com>
References: <pgp8ceubOPPxYan0QoWmM4QSByWwlenrFGIvtpF61pc=.1f8f0180-6f0f-4110-9921-7864dd3eecaf@github.com>
Message-ID: <jnzKxZgH7ppEfMf6NxqjWcTYVj5n1guuMr8DbB04UZE=.1cbc5aa8-b54a-429c-b996-c7856aba0847@github.com>

On Thu, 27 Apr 2023 18:36:53 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> ?

Please review CSR [JDK-8307074](https://bugs.openjdk.org/browse/JDK-8307074).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13698#issuecomment-1526154278

From mchung at openjdk.org  Thu Apr 27 19:06:53 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 27 Apr 2023 19:06:53 GMT
Subject: RFR: 8306729: Add nominal descriptors of modules and packages to
 Constants API [v15]
In-Reply-To: <HkXAif0uM5JGMeSLez9vHX8Qj26qqs5VwnEBbUTUHhc=.295f6996-24db-4d37-b762-84e5ece6c55f@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
 <HkXAif0uM5JGMeSLez9vHX8Qj26qqs5VwnEBbUTUHhc=.295f6996-24db-4d37-b762-84e5ece6c55f@github.com>
Message-ID: <YDecWASMQDm97iwqE6MneJj9esc9SLX4Cu8jRaTT8gs=.317046f9-3f84-4230-9e44-3b46a42d374c@github.com>

On Thu, 27 Apr 2023 07:42:29 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
>> 
>> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
>> 
>> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
>> 
>> Please review this pull request and attached CSR.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tests update

Discussed with @briangoetz offline.   We can let `PackageDesc` and `ModuleDesc` model unnamed package/module but the ClassFile API should check to make sure their names are not empty before using them to write to a classfile.

For example, if we had a constructor in `ClassDesc(PackageDesc package, String name)`, it could be tolerant of empty packages and treat it as just `new ClassDesc(name)`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13615#issuecomment-1526167033

From briangoetz at openjdk.org  Thu Apr 27 19:06:24 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 27 Apr 2023 19:06:24 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <3vo2eYH7fWvzAdDgHPFMvc_ZVt1IEYwVM15PH7rcsig=.691b1cbb-56c3-4811-bcf1-1af8e408faf6@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

With the upcoming refactor to make parse/build instance methods, there 
is a logical place and lifetime for caches.

On 4/27/2023 2:37 PM, Mandy Chung wrote:
>
> I consulted with @briangoetz <https://github.com/briangoetz>. The 
> internal name should probably be cached in the ClassFile API 
> implementation.
>
> ?
> Reply to this email directly, view it on GitHub 
> <https://github.com/openjdk/jdk/pull/13598#issuecomment-1526151053>, 
> or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/AABJ4RD2Q5PVEPGAYIHRKZLXDK4GRANCNFSM6AAAAAAXH4TPLU>.
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1526164638

From duke at openjdk.org  Thu Apr 27 19:07:23 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 27 Apr 2023 19:07:23 GMT
Subject: RFR: 8305093: Linker cache should not take layout names into
 account [v2]
In-Reply-To: <7_Nk2AOcLFfPf5yfpg1aAW97junefRNAY857VrpS9xs=.9640e499-4b17-44bc-82ea-406fff99a9cf@github.com>
References: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
 <7_Nk2AOcLFfPf5yfpg1aAW97junefRNAY857VrpS9xs=.9640e499-4b17-44bc-82ea-406fff99a9cf@github.com>
Message-ID: <jpoqvQOaaGpjwj4uNSOR3CdSnq2VNU9cK-yhj8Nw8Eo=.ab3b2e40-8411-47e5-92aa-a057405b06c2@github.com>

On Fri, 21 Apr 2023 01:03:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Strip names from the function descriptors used in linkage requests. The names are not important for classification, and this will allow the cached MethodHandle/UpcallStubFactory to be shared across linkage request with the same structure, but with layouts that have different names.
>> 
>> I also have another implementation that avoids copying all the layouts, and instead re-implemented equals and hashCode in the LinkRequest wrapper: https://github.com/openjdk/jdk/compare/pr/13079...JornVernee:jdk:NoNameCache But, this seems too complex. Linking code is not very performance sensitive, so I instead went with a simpler approach in this patch.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use al instead of ValueLayout.ADDRESS

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 147:

> 145:             case AddressLayout al -> al.targetLayout()
> 146:                     .map(tl -> al.withoutName().withTargetLayout(stripNames(tl)))
> 147:                     .orElse(al.withoutName());

This?can?use [`Optional::orElseGet`]:
Suggestion:

                    .orElseGet(al::withoutName);


[`Optional::orElseGet`]: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/Optional.html#orElseGet%28java.util.function.Supplier%29

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13562#discussion_r1179526882

From liach at openjdk.org  Thu Apr 27 19:44:52 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Apr 2023 19:44:52 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <qEMGaMPHtVkI1sbAH4c_ozR9Qy1ckqsS0Tj_GYzycVU=.de53b3d6-1e75-482b-8d05-f0600404c1e1@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

Sounds good. I will close the pull request and the JBS issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1526248747

From liach at openjdk.org  Thu Apr 27 19:44:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Apr 2023 19:44:54 GMT
Subject: Withdrawn: 8306697: Add method to obtain String for
 CONSTANT_Class_info in ClassDesc
In-Reply-To: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
Message-ID: <tchrmOfEp2xLLL1nLk-cUEguK4mRR3zMqgkVax3Wyvw=.2fa4dc66-0181-4d3e-97e1-e5d0f2f5bc82@github.com>

On Sat, 22 Apr 2023 15:12:48 GMT, Chen Liang <liach at openjdk.org> wrote:

> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
> 
> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
> 
> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
> 
> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/13598

From tonyp at openjdk.org  Thu Apr 27 20:08:29 2023
From: tonyp at openjdk.org (Antonios Printezis)
Date: Thu, 27 Apr 2023 20:08:29 GMT
Subject: RFR: JDK-8307063: When cross-compiling with hsdis/binutils,
 buildjdk creation fails [v2]
In-Reply-To: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>
References: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>
Message-ID: <33BGkhKCy3n5_pAl-hxHAiXBLfXHCa6FaNqFHn2z-DY=.bf1a8b3f-4d09-4f9b-b0b5-ded2183afb34@github.com>

> Fix is to exclude hsdis when building the buildjdk.

Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision:

  changes based on Erik's feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13697/files
  - new: https://git.openjdk.org/jdk/pull/13697/files/a788df2c..bf62e57d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13697&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13697&range=00-01

  Stats: 37 lines in 3 files changed: 10 ins; 12 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13697.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13697/head:pull/13697

PR: https://git.openjdk.org/jdk/pull/13697

From tonyp at openjdk.org  Thu Apr 27 20:08:31 2023
From: tonyp at openjdk.org (Antonios Printezis)
Date: Thu, 27 Apr 2023 20:08:31 GMT
Subject: RFR: JDK-8307063: When cross-compiling with hsdis/binutils,
 buildjdk creation fails [v2]
In-Reply-To: <YABjBrZtnONUjyGDZAMayjEelhuGTUCoHKb5cWCcf94=.6cb9f845-9a1c-46ea-8c08-2c1d847afa31@github.com>
References: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>
 <YABjBrZtnONUjyGDZAMayjEelhuGTUCoHKb5cWCcf94=.6cb9f845-9a1c-46ea-8c08-2c1d847afa31@github.com>
Message-ID: <0PoHH-kxLo5Neo_fgiHUZhnhkkvpdnfL2P02T2m1tE0=.5c45fb9e-730d-4be6-aaeb-52833c75a6b9@github.com>

On Thu, 27 Apr 2023 18:19:49 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changes based on Erik's feedback
>
> This looks like it should work, but I would like to avoid sprinkling any more CREATING_BUILDJDK conditionals throughout the build than absolutely necessary. I think it would be better to just override `HSDIS_BACKEND` and `ENABLE_HSDIS_BUNDLING` in `buildjdk-spec.gmk.in` with a comment that hsdis should never be enabled in the buildjdk. I haven't tested it though so I may be missing something.

@erikj79 See updated patch. This is indeed cleaner and seems to work (I tried building x64/riscv binaries with/without hsdis).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13697#issuecomment-1526299188

From mcimadamore at openjdk.org  Thu Apr 27 20:49:54 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 27 Apr 2023 20:49:54 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v2]
In-Reply-To: <YopNQ7jjAg7Z64IZkD_2as39dBcUj0hHWKB8S17VlDc=.9168990a-2444-4c0a-afac-bc8640742f76@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <osNSUyEj1mUrULK9eKwnO1SQqg1OLygKUKCFfoS_lwc=.f8c3e61b-6200-42f3-80cc-51334e4e7502@github.com>
 <NZ5sMaBOg79-lhBtMm44HjHXVL_WAcedBDNGllRgp3Q=.e934db5b-d6c8-4e44-82f5-a92ff2972c56@github.com>
 <YopNQ7jjAg7Z64IZkD_2as39dBcUj0hHWKB8S17VlDc=.9168990a-2444-4c0a-afac-bc8640742f76@github.com>
Message-ID: <BOXMmQgrlZClYv2leL5C52nwYTnTZ00oLL-Y87rdC0g=.722edbbc-1160-458d-b621-09af904d9c2c@github.com>

On Thu, 27 Apr 2023 18:28:41 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 432:
>> 
>>> 430: 
>>> 431:     // Restructure top level to be an top level anonymous class.
>>> 432:     public static void constructAnonymousMainClass(JCCompilationUnit tree,
>> 
>> Question: any reason as to why this is done here and not in the parser? Typically we don't want to do tree transformation at parse time, as that messes up clients that want to access the "non-desugared" tree (such as IDE) and expect some mapping between source to AST. But if you do the rewriting in Enter, not much changes, that is, clients such as IDEs would still see something that doesn't resemble the source.
>
> The source file name is not available until after parsing.

I see that logic in JavaCompiler - I wonder if that's just the way it is, or if there's a deeper reason as to why the sourcefile is set on the toplevel unit *after* parsing (I don't think I can see any, in which case that might be changed if that makes the rest of the code simpler). @lahodaj what do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179650628

From rriggs at openjdk.org  Thu Apr 27 20:52:23 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 27 Apr 2023 20:52:23 GMT
Subject: Integrated: 8298993: (process)
 java/lang/ProcessBuilder/UnblockSignals.java fails
In-Reply-To: <iWHiW4JJiCHgJERISrctccBOnAZgAfsemSDjfZJEQzI=.b60ab5fa-82f5-4e77-9d8d-1fb02ec162d2@github.com>
References: <iWHiW4JJiCHgJERISrctccBOnAZgAfsemSDjfZJEQzI=.b60ab5fa-82f5-4e77-9d8d-1fb02ec162d2@github.com>
Message-ID: <_L_Ep7riNIx0_HWZR1iRbu4KWFPQR4laJWHB2LPQAEE=.0b56366b-e4cc-4601-a220-c0140174a549@github.com>

On Tue, 25 Apr 2023 21:43:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> It appears that -Xcomp causes the relative timing of the commands to be disturbed enough to prevent the correct operation of the test. The test should not be run with -Xcomp

This pull request has now been integrated.

Changeset: b827ce83
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b827ce8334c568d72990985ff6077db8334e2754
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8298993: (process) java/lang/ProcessBuilder/UnblockSignals.java fails

Reviewed-by: bchristi

-------------

PR: https://git.openjdk.org/jdk/pull/13660

From tonyp at openjdk.org  Thu Apr 27 20:53:25 2023
From: tonyp at openjdk.org (Antonios Printezis)
Date: Thu, 27 Apr 2023 20:53:25 GMT
Subject: RFR: JDK-8307063: When cross-compiling with hsdis/binutils,
 buildjdk creation fails [v3]
In-Reply-To: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>
References: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>
Message-ID: <42egl-6Z39iw6aXBLn0GwNZ3-qRdfKMsgvvCgIckvNw=.3f0e3d79-2554-4faa-8f8d-c6c787890a51@github.com>

> Fix is to exclude hsdis when building the buildjdk.

Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision:

  updated

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13697/files
  - new: https://git.openjdk.org/jdk/pull/13697/files/bf62e57d..6dc12590

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13697&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13697&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13697.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13697/head:pull/13697

PR: https://git.openjdk.org/jdk/pull/13697

From erikj at openjdk.org  Thu Apr 27 20:53:28 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 27 Apr 2023 20:53:28 GMT
Subject: RFR: JDK-8307063: When cross-compiling with hsdis/binutils,
 buildjdk creation fails [v2]
In-Reply-To: <33BGkhKCy3n5_pAl-hxHAiXBLfXHCa6FaNqFHn2z-DY=.bf1a8b3f-4d09-4f9b-b0b5-ded2183afb34@github.com>
References: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>
 <33BGkhKCy3n5_pAl-hxHAiXBLfXHCa6FaNqFHn2z-DY=.bf1a8b3f-4d09-4f9b-b0b5-ded2183afb34@github.com>
Message-ID: <xuORm02TJE7qzeMY3bMi5wYjvR5tfShQ_WCMJ_PwMQU=.5ca1d61a-f148-4df3-b611-61ed8df3d1fd@github.com>

On Thu, 27 Apr 2023 20:08:29 GMT, Antonios Printezis <tonyp at openjdk.org> wrote:

>> Fix is to exclude hsdis when building the buildjdk.
>
> Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes based on Erik's feedback

make/autoconf/buildjdk-spec.gmk.in line 109:

> 107: # hsdis is not needed
> 108: override HSDIS_BACKEND := none
> 109: override ENABLE_HSDIS_BUNDLING := false

You shouldn't need the `override` keyword. That is only needed when the value of the variables is set on the make command line. In this case we are simply overriding the values from the main `spec.gmk`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13697#discussion_r1179652542

From tonyp at openjdk.org  Thu Apr 27 20:53:29 2023
From: tonyp at openjdk.org (Antonios Printezis)
Date: Thu, 27 Apr 2023 20:53:29 GMT
Subject: RFR: JDK-8307063: When cross-compiling with hsdis/binutils,
 buildjdk creation fails [v2]
In-Reply-To: <xuORm02TJE7qzeMY3bMi5wYjvR5tfShQ_WCMJ_PwMQU=.5ca1d61a-f148-4df3-b611-61ed8df3d1fd@github.com>
References: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>
 <33BGkhKCy3n5_pAl-hxHAiXBLfXHCa6FaNqFHn2z-DY=.bf1a8b3f-4d09-4f9b-b0b5-ded2183afb34@github.com>
 <xuORm02TJE7qzeMY3bMi5wYjvR5tfShQ_WCMJ_PwMQU=.5ca1d61a-f148-4df3-b611-61ed8df3d1fd@github.com>
Message-ID: <3NJLMN9_DSFvqnd7KQdGCQBssFcc47vK5e0XNFFSBiY=.1c69e891-0cc8-40ba-bfd1-2533830e29fe@github.com>

On Thu, 27 Apr 2023 20:37:11 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changes based on Erik's feedback
>
> make/autoconf/buildjdk-spec.gmk.in line 109:
> 
>> 107: # hsdis is not needed
>> 108: override HSDIS_BACKEND := none
>> 109: override ENABLE_HSDIS_BUNDLING := false
> 
> You shouldn't need the `override` keyword. That is only needed when the value of the variables is set on the make command line. In this case we are simply overriding the values from the main `spec.gmk`.

updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13697#discussion_r1179656243

From mcimadamore at openjdk.org  Thu Apr 27 21:01:54 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 27 Apr 2023 21:01:54 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v3]
In-Reply-To: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com>
Message-ID: <aXXmw3MI3RKxzdvKBAgRPBfnEiQJWodtbizzX9k9m9I=.18eb38ed-3591-4b65-bd33-1eb7df7d982a@github.com>

On Thu, 27 Apr 2023 18:21:56 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into 8306112
>  - PreviewFeatures.isEnabled()
>  - Clean up isPreview
>  - Missing exception
>  - Corrections
>  - Update VM.java
>  - Clean up testing
>  - Update TestJavacTaskScanner.java
>  - Merge branch 'master' into 8306112
>  - Clean up
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d

test/jdk/tools/launcher/OnrampMainTest.java line 31:

> 29:  * @run main OnrampMainTest
> 30:  */
> 31: public class OnrampMainTest extends TestHelper {

Should more tests be added for inherited methods?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179666410

From erikj at openjdk.org  Thu Apr 27 21:12:54 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 27 Apr 2023 21:12:54 GMT
Subject: RFR: JDK-8307063: When cross-compiling with hsdis/binutils,
 buildjdk creation fails [v3]
In-Reply-To: <42egl-6Z39iw6aXBLn0GwNZ3-qRdfKMsgvvCgIckvNw=.3f0e3d79-2554-4faa-8f8d-c6c787890a51@github.com>
References: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>
 <42egl-6Z39iw6aXBLn0GwNZ3-qRdfKMsgvvCgIckvNw=.3f0e3d79-2554-4faa-8f8d-c6c787890a51@github.com>
Message-ID: <whYSb3d8ZgzxXmKnQRyKjchZ_vusljf2JE7PX8qSML8=.5eeb2dae-f6be-41df-955b-5e455a315fd0@github.com>

On Thu, 27 Apr 2023 20:53:25 GMT, Antonios Printezis <tonyp at openjdk.org> wrote:

>> Fix is to exclude hsdis when building the buildjdk.
>
> Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13697#pullrequestreview-1404881482

From tonyp at openjdk.org  Thu Apr 27 21:23:26 2023
From: tonyp at openjdk.org (Antonios Printezis)
Date: Thu, 27 Apr 2023 21:23:26 GMT
Subject: RFR: JDK-8307063: When cross-compiling with hsdis/binutils,
 buildjdk creation fails [v3]
In-Reply-To: <whYSb3d8ZgzxXmKnQRyKjchZ_vusljf2JE7PX8qSML8=.5eeb2dae-f6be-41df-955b-5e455a315fd0@github.com>
References: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>
 <42egl-6Z39iw6aXBLn0GwNZ3-qRdfKMsgvvCgIckvNw=.3f0e3d79-2554-4faa-8f8d-c6c787890a51@github.com>
 <whYSb3d8ZgzxXmKnQRyKjchZ_vusljf2JE7PX8qSML8=.5eeb2dae-f6be-41df-955b-5e455a315fd0@github.com>
Message-ID: <vJeNoMw_rCw2hdXm-QIpWElly4N3pXorhK8f8y-il-0=.3945d0b5-6cc4-46bb-b0b9-077d56fac613@github.com>

On Thu, 27 Apr 2023 21:04:42 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated
>
> Marked as reviewed by erikj (Reviewer).

@erikj79 Thanks! I assume the integrate command will actually squash the three commits and rebase it on top of master as one commit?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13697#issuecomment-1526491980

From rriggs at openjdk.org  Thu Apr 27 21:36:53 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 27 Apr 2023 21:36:53 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v3]
In-Reply-To: <oJ8ZXUlfXgCGsf2GUdqu9lqihPWAP9-L1JslWzGmc0s=.cbf6ded7-1c9e-4425-a570-ff3be20c8eda@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <oJ8ZXUlfXgCGsf2GUdqu9lqihPWAP9-L1JslWzGmc0s=.cbf6ded7-1c9e-4425-a570-ff3be20c8eda@github.com>
Message-ID: <V0VBjNN703US-CGtwAM0wIeUaLlibviunbdmTu_5Gwg=.3dd83c8a-7b19-4794-bc72-9fcc8f66e9e0@github.com>

On Wed, 26 Apr 2023 11:55:23 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8306461
>  - Simplified exception message and fixed test to check the correct message
>  - Addresed review comments of @turbanoff, @shipilev and @RogerRiggs
>  - 8306461: ObjectInputStream::readObject() should handle negative array sizes without throwing NegativeArraySizeExceptions

Thanks for the investigation.

On the question of the exception thrown IllegalObjectException vs StreamCorruptedExeception, I'd lean toward StreamCorruptedException, including for the current PR; as that is more indicative of the issue raised.

As for addressing the existing uses of checkArray that would throw NAE, I would rather see a single fix in checkArray than adding code in multiple other places.  A fix in checkArray would cover future uses as well as current uses. The existing code that is checking len < 0 before calling checkArray can continue to do so to maintain compatibility on the exception thrown. Though a change would be unlikely to break user code it is better to avoid that. (It might cause changes existing tests).

Handling it in a separate PR may be reasonable but it too will require a CSR (change in behavior from throwning NAE to SCE) and the cause and behavior change are generally the same as the current PR.  If handled in a single PR/CSR and release note will have a more coherent and singular explanation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13540#issuecomment-1526506534

From erikj at openjdk.org  Thu Apr 27 21:46:24 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 27 Apr 2023 21:46:24 GMT
Subject: RFR: JDK-8307063: When cross-compiling with hsdis/binutils,
 buildjdk creation fails [v3]
In-Reply-To: <whYSb3d8ZgzxXmKnQRyKjchZ_vusljf2JE7PX8qSML8=.5eeb2dae-f6be-41df-955b-5e455a315fd0@github.com>
References: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>
 <42egl-6Z39iw6aXBLn0GwNZ3-qRdfKMsgvvCgIckvNw=.3f0e3d79-2554-4faa-8f8d-c6c787890a51@github.com>
 <whYSb3d8ZgzxXmKnQRyKjchZ_vusljf2JE7PX8qSML8=.5eeb2dae-f6be-41df-955b-5e455a315fd0@github.com>
Message-ID: <uEFgpkJBPFecYgvs-bm7KDV_Zt6u0CPGb_11OU5a6kc=.bb8c7d8b-c6b1-4e51-b169-fad2615caf26@github.com>

On Thu, 27 Apr 2023 21:04:42 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated
>
> Marked as reviewed by erikj (Reviewer).

> @erikj79 Thanks! I assume the integrate command will actually squash the three commits and rebase them on top of master as one commit?

Yes, all you need to do is to issue the integrate command, just like the bot instructed [here](https://github.com/openjdk/jdk/pull/13697#issuecomment-1526469383).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13697#issuecomment-1526520513

From smarks at openjdk.org  Thu Apr 27 23:29:26 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 27 Apr 2023 23:29:26 GMT
Subject: RFR: 8302496: Runtime.exit incorrectly says it never throws an
 exception
Message-ID: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>

Textual specification clarifications.

-------------

Commit messages:
 - 8302496: Runtime.exit incorrectly says it never throws an exception

Changes: https://git.openjdk.org/jdk/pull/13706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13706&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302496
  Stats: 29 lines in 2 files changed: 5 ins; 2 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/13706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13706/head:pull/13706

PR: https://git.openjdk.org/jdk/pull/13706

From smarks at openjdk.org  Thu Apr 27 23:29:27 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 27 Apr 2023 23:29:27 GMT
Subject: RFR: 8302496: Runtime.exit incorrectly says it never throws an
 exception
In-Reply-To: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
References: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
Message-ID: <3pW4C-vQ5uCol84nGwbzc-7-t6R9ufdxBycLB7OYZzU=.034d6dd7-dc9a-4b77-a14c-067b3a535291@github.com>

On Thu, 27 Apr 2023 23:06:42 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Textual specification clarifications.

Please review CSR [JDK-8307081](https://bugs.openjdk.org/browse/JDK-8307081).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13706#issuecomment-1526712106

From darcy at openjdk.org  Fri Apr 28 00:00:53 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 28 Apr 2023 00:00:53 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: <rRdI2PnvUgor7U_8xMKe5e2PnbHMj1N25kwcccLBj7E=.cffa2e21-47b9-4d8e-82c5-6a8ff45e352e@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

@liach , thank you for working on this fix. I've given the changes an initial skim, but will need to do a more thorough review before approving or offering suggestions for changes. My top priority for the next few weeks will be JDK 21 CSRs so it may take a while for me to circle back to this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13664#issuecomment-1526777907

From jvernee at openjdk.org  Fri Apr 28 00:02:53 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 28 Apr 2023 00:02:53 GMT
Subject: RFR: 8305093: Linker cache should not take layout names into
 account [v3]
In-Reply-To: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
References: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
Message-ID: <K7JCRneePY_5H3_NwwVAVW6DWOi1ujowhhbJfOn8mE0=.9579d98b-e0c2-4d7e-b6e8-9fef994ff6e0@github.com>

> Strip names from the function descriptors used in linkage requests. The names are not important for classification, and this will allow the cached MethodHandle/UpcallStubFactory to be shared across linkage request with the same structure, but with layouts that have different names.
> 
> I also have another implementation that avoids copying all the layouts, and instead re-implemented equals and hashCode in the LinkRequest wrapper: https://github.com/openjdk/jdk/compare/pr/13079...JornVernee:jdk:NoNameCache But, this seems too complex. Linking code is not very performance sensitive, so I instead went with a simpler approach in this patch.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:

 - Undo changes to MemberDeleted.java
 - Merge branch 'master' into NoNameCache2
 - use al instead of ValueLayout.ADDRESS
 - re-add spuriously removed blank line
 - stripNames based caching
 - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
   
   rename has_port
 - rename has_port
 - Merge pull request #2 from JornVernee/WSL_BB
   
   account for missing functional in WSL in TestByteBuffer
 - account for missing mincore on WSL in TestByteBuffer
 - Merge branch 'master' into PR_21_V2
 - ... and 35 more: https://git.openjdk.org/jdk/compare/b827ce83...a8103f67

-------------

Changes: https://git.openjdk.org/jdk/pull/13562/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13562&range=02
  Stats: 95 lines in 2 files changed: 90 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13562/head:pull/13562

PR: https://git.openjdk.org/jdk/pull/13562

From jvernee at openjdk.org  Fri Apr 28 00:14:00 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 28 Apr 2023 00:14:00 GMT
Subject: RFR: 8305201: Improve error message for GroupLayouts that are too
 large on SysV [v3]
In-Reply-To: <DwY-xanY3TwoY2JPGLFPQg3bOqI70N1j5tAKv60AIxw=.f892d52c-a641-4275-9619-a8bffc4378b5@github.com>
References: <DwY-xanY3TwoY2JPGLFPQg3bOqI70N1j5tAKv60AIxw=.f892d52c-a641-4275-9619-a8bffc4378b5@github.com>
Message-ID: <rM-gWFmSQBrmigMnb_TJzoeASFpkUptKFnFzY85l4EM=.a32db71c-9a5f-4ced-a952-d4f13ae7c6a1@github.com>

> Using for instance a struct layout that contains an unbounded array will produce the exception from the JBS issue.
> 
> This patch checks for the case where a GroupLayout is too large more explicitly, and reports the issue using a more informative exception.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:

 - Undo changes to MemberDeleted.java
 - Merge branch 'master' into GroupLayoutTooLarge
 - Add test. Use toIntExact
 - improve error message for too large structs
 - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
   
   rename has_port
 - rename has_port
 - Merge pull request #2 from JornVernee/WSL_BB
   
   account for missing functional in WSL in TestByteBuffer
 - account for missing mincore on WSL in TestByteBuffer
 - Merge branch 'master' into PR_21_V2
 - 8305369: Issues in zero-length memory segment javadoc section
 - ... and 34 more: https://git.openjdk.org/jdk/compare/b827ce83...8fe34306

-------------

Changes: https://git.openjdk.org/jdk/pull/13581/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13581&range=02
  Stats: 27 lines in 2 files changed: 24 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13581.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13581/head:pull/13581

PR: https://git.openjdk.org/jdk/pull/13581

From jvernee at openjdk.org  Fri Apr 28 00:24:59 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 28 Apr 2023 00:24:59 GMT
Subject: RFR: 8305093: Linker cache should not take layout names into
 account [v4]
In-Reply-To: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
References: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
Message-ID: <aj_4D2FhcBP9uVc8dfw5N976uV50TzfXw6BBBVsgmOc=.bd882001-ef6c-46d0-9333-1264f5dd9396@github.com>

> Strip names from the function descriptors used in linkage requests. The names are not important for classification, and this will allow the cached MethodHandle/UpcallStubFactory to be shared across linkage request with the same structure, but with layouts that have different names.
> 
> I also have another implementation that avoids copying all the layouts, and instead re-implemented equals and hashCode in the LinkRequest wrapper: https://github.com/openjdk/jdk/compare/pr/13079...JornVernee:jdk:NoNameCache But, this seems too complex. Linking code is not very performance sensitive, so I instead went with a simpler approach in this patch.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Use orElseGet
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13562/files
  - new: https://git.openjdk.org/jdk/pull/13562/files/a8103f67..49b8f536

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13562&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13562&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13562/head:pull/13562

PR: https://git.openjdk.org/jdk/pull/13562

From liach at openjdk.org  Fri Apr 28 00:32:02 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Apr 2023 00:32:02 GMT
Subject: RFR: 8306698: Add overloads to MethodTypeDesc::of [v2]
In-Reply-To: <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
References: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
 <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
Message-ID: <LJx1jHxf4GWEl2MdT5bTJW22iyXx-az3ktBqv3SyXDo=.27da0793-df5e-4f23-954b-8eaf13dbd468@github.com>

On Sun, 23 Apr 2023 23:44:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch adding two new convenience methods that allows easier access to MethodTypeDesc instances and its associated CSR as well. This is a necessity to allow #13186 to reduce array copies in a few scenarios; the implementation of the two methods will be updated there.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306698/1/java.base/java/lang/constant/MethodTypeDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update method type and specification, update tests

Please review this patch, adding two factory methods for MethodTypeDesc for convenience. Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13599#issuecomment-1526806780

From jlu at openjdk.org  Fri Apr 28 00:35:26 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 28 Apr 2023 00:35:26 GMT
Subject: Integrated: 8306711: Improve diagnosis of `IntlTest` framework
In-Reply-To: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
Message-ID: <ej0C_wha2hoQ7VDUkLDzLwoXTcoXPCCshJ61OCRi9TM=.f53ce08b-7e54-4e09-9159-db0e075b4224@github.com>

On Tue, 25 Apr 2023 20:28:33 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review changes to the IntlTest (test framework) class. 
> 
> These changes include
> - Logging the actual exception + stack trace. Previously, the test framework would throw `InvocationTargetException` but hide the actual underlying exception of the failing test unless the test class was ran with -nothrow.
> - Sorting the tests, ensuring for any given run, the tests are ran in the same order. (In [JDK-8305853](https://bugs.openjdk.org/browse/JDK-8305853) it was discovered that on Windows, the test framework would execute tests in a random order each time).
> - Improving output.

This pull request has now been integrated.

Changeset: f3c90f04
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f3c90f0445df359a8bc03630fc5cde2843bbfef1
Stats:     171 lines in 2 files changed: 68 ins; 54 del; 49 mod

8306711: Improve diagnosis of `IntlTest` framework

Reviewed-by: naoto, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/13655

From jvernee at openjdk.org  Fri Apr 28 01:01:23 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 28 Apr 2023 01:01:23 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v7]
In-Reply-To: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
Message-ID: <_I1QpOj1-NzmfBXtlwmNt7BU05XCPhhR_opoRmwBIr0=.816ebaa6-e35b-414c-8216-bb2b8daa507b@github.com>

> This patch adds checks in AbstractLinker to reject packed structs and structs with excess padding (e.g. unnamed bitfields), since both of those are currently not supported, and the ABI/spec seems too vague to base support on.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 52 commits:

 - Merge branch 'master' into RejectPacked
 - restrictions -> characteristics
 - polish pt. 2
 - polish wording
 - review comments
 - fix TestIllegalLink
 - Merge branch 'PR_21' into RejectPacked
 - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
   
   rename has_port
 - rename has_port
 - Merge pull request #2 from JornVernee/WSL_BB
   
   account for missing functional in WSL in TestByteBuffer
 - ... and 42 more: https://git.openjdk.org/jdk/compare/b827ce83...df9f2eb2

-------------

Changes: https://git.openjdk.org/jdk/pull/13164/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13164&range=06
  Stats: 161 lines in 11 files changed: 146 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13164/head:pull/13164

PR: https://git.openjdk.org/jdk/pull/13164

From jvernee at openjdk.org  Fri Apr 28 01:26:53 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 28 Apr 2023 01:26:53 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v4]
In-Reply-To: <BmO-X6PnCnCN17VYHwgLxBtDS0ztCjsbUylkyGCnwwI=.0950f5df-c91e-49d1-a9d8-3df18640f2cb@github.com>
References: <BmO-X6PnCnCN17VYHwgLxBtDS0ztCjsbUylkyGCnwwI=.0950f5df-c91e-49d1-a9d8-3df18640f2cb@github.com>
Message-ID: <ZMhpVJIb-uHYP74phYLgp_PMDOJ_vAAPhPsMId4dokA=.07371058-99bf-44c9-afcd-ac75ac086c9a@github.com>

> Rewrite BindingSpecializer to use the new class file API.
> 
> Note: There is a big try/catch/finally block generated in the `specialize` method that currently uses labels. I looked at replacing this with a call to `CodeBuilder::trying` but it would require threading the nested code builders through all the `emit*` methods, which currently access the 'global' CodeBuilder instance attached to the BindingSpecializer instance. Since there didn't really seem to be a big benefit to this, I've kept that try/catch/finally block as is, using labels.
> 
> The current implementation could also use `CheckClassAdapter` to do additional verification on the generated bytecode (ahead of the VM's verifier). I'm not sure if the new API has a replacement for that?

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:

 - Merge branch 'master' into CFA_JDK
 - Re-add PERFORM_VERIFICATION flag
 - use existing MTD_void constant
 - use ifThen to release scopes
 - use TypeKind.from
 - Translate BindingSpecializer to new classfile API
 - Merge with master
 - Make fallbacklinker.c consistent with downcallLinker.cpp
 - Add bug number
 - Use @return
 - ... and 18 more: https://git.openjdk.org/jdk/compare/b827ce83...851739a2

-------------

Changes: https://git.openjdk.org/jdk/pull/13247/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13247&range=03
  Stats: 406 lines in 1 file changed: 23 ins; 146 del; 237 mod
  Patch: https://git.openjdk.org/jdk/pull/13247.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13247/head:pull/13247

PR: https://git.openjdk.org/jdk/pull/13247

From jiangli at openjdk.org  Fri Apr 28 01:41:27 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 28 Apr 2023 01:41:27 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
Message-ID: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>

Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.

In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.

To build the statically linked executable:

1. Configure the JDK build with --with-static-java=yes
2. Build static-java-image, e.g. 'make jdk-image static-java-image'

 The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.

Following is a summary of the changes in this PR:

- Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.

- Changes in make/Main.gmk
? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.

- Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.

- Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.

- Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.

- When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk.

- In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well.

- In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk.

Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk.

-------------

Commit messages:
 - Update copyright headers.
 - Fix jcheck whitespace error with make/autoconf/lib-bundled.m4.
 - Merge branch 'master' into JDK-8303796
 - - Update make/StaticLink.gmk:
 - Merge branch 'master' into JDK-8303796
 - Add make/StaticLink.gmk and make/autoconf/static-java.m4.
 - 8303796: Optionally build fully statically linked JDK image

Changes: https://git.openjdk.org/jdk/pull/13709/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13709&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303796
  Stats: 301 lines in 12 files changed: 258 ins; 34 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13709.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13709/head:pull/13709

PR: https://git.openjdk.org/jdk/pull/13709

From duke at openjdk.org  Fri Apr 28 04:22:53 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 28 Apr 2023 04:22:53 GMT
Subject: RFR: 8302496: Runtime.exit incorrectly says it never throws an
 exception
In-Reply-To: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
References: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
Message-ID: <PltBScr2EGR3iGXF_PRiMHQozG3PxN-fquthGCaOzyw=.0c80b13d-9ec3-4211-a835-841b90e81353@github.com>

On Thu, 27 Apr 2023 23:06:42 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Textual specification clarifications.

These?can?use the?new?generalised `@linkplain`?tags available?since **JDK?20**:

src/java.base/share/classes/java/lang/Runtime.java line 143:

> 141: 
> 142:     /**
> 143:      * Initiates the <a href="#shutdown">shutdown sequence</a> of the Java Virtual Machine.

Suggestion:

     * Initiates the {@linkplain ##shutdown shutdown sequence} of the Java Virtual Machine.

src/java.base/share/classes/java/lang/Runtime.java line 284:

> 282: 
> 283:     /**
> 284:      * Immediately <a href="#termination">terminates</a> the Java Virtual Machine.

Suggestion:

     * Immediately {@linkplain ##termination terminates} the Java Virtual Machine.

src/java.base/share/classes/java/lang/System.java line 1889:

> 1887: 
> 1888:     /**
> 1889:      * Initiates the <a href="#shutdown">shutdown sequence</a> of the Java Virtual Machine.

Suggestion:

     * Initiates the {@linkplain Runtime##shutdown shutdown sequence} of the Java Virtual Machine.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13706#pullrequestreview-1405194629
PR Review Comment: https://git.openjdk.org/jdk/pull/13706#discussion_r1179907421
PR Review Comment: https://git.openjdk.org/jdk/pull/13706#discussion_r1179907506
PR Review Comment: https://git.openjdk.org/jdk/pull/13706#discussion_r1179907723

From dholmes at openjdk.org  Fri Apr 28 04:32:24 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Apr 2023 04:32:24 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v3]
In-Reply-To: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com>
Message-ID: <_3okiv8d0MwpgpPDMA243D__1j6F89gd-aKF3fdu9Bo=.253bffb8-5b0f-443a-bbed-23677b0a160d@github.com>

On Thu, 27 Apr 2023 18:21:56 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into 8306112
>  - PreviewFeatures.isEnabled()
>  - Clean up isPreview
>  - Missing exception
>  - Corrections
>  - Update VM.java
>  - Clean up testing
>  - Update TestJavacTaskScanner.java
>  - Merge branch 'master' into 8306112
>  - Clean up
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d

I don't see anything hotspot related here (no idea why the auto-mapping added it) so can we remove hotspot-runtime please.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13689#issuecomment-1526968745

From dholmes at openjdk.org  Fri Apr 28 05:16:54 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Apr 2023 05:16:54 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
Message-ID: <R5uvOG4uZQy7Licu6iZArbWYnfmjvqRu9QN8JjR-GF0=.62f82b60-e6f2-4af3-ad50-b8f1a861f0ab@github.com>

On Fri, 28 Apr 2023 01:03:28 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.
> 
> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.
> 
> To build the statically linked executable:
> 
> 1. Configure the JDK build with --with-static-java=yes
> 2. Build static-java-image, e.g. 'make jdk-image static-java-image'
> 
>  The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.
> 
> Following is a summary of the changes in this PR:
> 
> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.
> 
> - Changes in make/Main.gmk
> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.
> 
> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.
> 
> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.
> 
> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.
> 
> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk.
> 
> - In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well.
> 
> - In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk.
> 
> Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk.

@jianglizhou  I thought this work was proposed to be done under the Project Leyden umbrella? The other static-build tweaks have been fine but this seems to be part of a bigger, yet unspecified, project that may need to be covered by a JEP.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1526991027

From joehw at openjdk.org  Fri Apr 28 05:47:24 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 28 Apr 2023 05:47:24 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v9]
In-Reply-To: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
Message-ID: <w_VQMDXdJScfmyacC0Mxsq4ZshVvw8vLNEcw62YbH1I=.4296584d-da35-4b67-8914-ac26aeef1873@github.com>

> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8303531
> 
> Tests: XML SQE and JCK tests passed.

Joe Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:

 - Merge branch 'master' into JDK-8303530
 - Update based on the review meeting on 4/5. Added (duplicated) definitions in jaxp.properties; Rewrote Property Precedence with samples; Other updates.
 - update javadoc as discussed in the review meeting; add a sample configuration file jaxp.properties; update impl and tests accordingly.
 - continue support stax.properties at the impl level, though dropped from the spec
 - change prefix from jdk to java
 - change prefix from jdk to java; rm zip file that accidentally checked in
 - update config file description; add a general scope and order section; move value definition for external properties to class description
 - clean up tests; fix copy&paste error.
 - 8303530: Add system property for custom JAXP configuration file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12985/files
  - new: https://git.openjdk.org/jdk/pull/12985/files/98a312cd..5f889bb9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=07-08

  Stats: 417343 lines in 4246 files changed: 324482 ins; 62120 del; 30741 mod
  Patch: https://git.openjdk.org/jdk/pull/12985.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12985/head:pull/12985

PR: https://git.openjdk.org/jdk/pull/12985

From koo.taejin at gmail.com  Fri Apr 28 06:04:37 2023
From: koo.taejin at gmail.com (=?UTF-8?B?6rWs7YOc7KeE?=)
Date: Fri, 28 Apr 2023 15:04:37 +0900
Subject: There is unnecessary resource consumption in
 `SecureRandom.getInstance()`.
Message-ID: <CACzBzePNaPDm_JQhAdT9sRKeRKE8WuRi9yLSbfxcyi=HMjacYA@mail.gmail.com>

Hello, this is my first e-mail  at this mailng-list.

It is an honor for me to write an e-mail here. :)
If I misunderstood and wrote an email, please forgive me.

- reproduction code
  tested on oracle-openjdk-20.0.1 and temurin-17.0.3
```
SecureRandom.getInstance("SHA1PRNG")
```

The reason it's slow is because exception is created during this operation.
(result is ok.)

```
java.lang.NoSuchMethodException.<init>()
        at java.lang.Class.getConstructor0(Class.java:3585)
        at java.lang.Class.getConstructor(Class.java:2271)
        at
java.security.Provider$Service.newInstanceUtil(Provider.java:1896)
        at java.security.Provider$Service.newInstance(Provider.java:1861)
        at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
        at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)

        at java.security.SecureRandom.getInstance(SecureRandom.java:387
```

I looked up why the exception was being created.
https://github.com/openjdk/jdk/blob/0deb648985b018653ccdaf193dc13b3cf21c088a/src/java.base/share/classes/java/security/Provider.java#L1587
// addEngine("SecureRandom", false, "java.security.SecureRandomParameters");

It looks that is specifying a constructor for SecureRandom at this point.
But SecureRandom looks it doesn't have that constructor (It looks like
SecureRandomSpi has that constructor .).

For this reason, the initial creation fails and an exception is created.
As an alternative, it seems that created using a constructor without
arguments.
```
// java.security.Provider.Service#newInstanceUtil
private Object newInstanceUtil(Class<?> ctrParamClz, Object ctorParamObj)
                throws Exception
        {
            if (ctrParamClz == null) {
                return newInstanceOf();
            } else {
                // Looking for the constructor with a params first and
fallback
                // to one without if not found. This is to support the
enhanced
                // SecureRandom where both styles of constructors are
supported.
                // Before jdk9, there was no params support (only
getInstance(alg))
                // and an impl only had the params-less constructor. Since
jdk9,
                // there is getInstance(alg,params) and an impl can contain
                // an Impl(params) constructor.
                try {
                    Constructor<?> con =
getImplClass().getConstructor(ctrParamClz);
                    return con.newInstance(ctorParamObj);
                } catch (NoSuchMethodException nsme) {
                    // For pre-jdk9 SecureRandom implementations, they only
                    // have params-less constructors which still works when
                    // the input ctorParamObj is null.
                    //
                    // For other primitives using params, ctorParamObj
should not
                    // be null and nsme is thrown, just like before.
                    if (ctorParamObj == null) {
                        try {
                            return newInstanceOf();
                        } catch (NoSuchMethodException nsme2) {
                            nsme.addSuppressed(nsme2);
                            throw nsme;
                        }
                    } else {
                        throw nsme;
                    }
                }
            }
        }
```

There are two solutions I think.

1. Create a constructor for SecureRandom.
2. Compare using getConstructors instead of getConstrctor.

Thanks for reading. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230428/b968209d/attachment.htm>

From asotona at openjdk.org  Fri Apr 28 06:14:55 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 28 Apr 2023 06:14:55 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <3vo2eYH7fWvzAdDgHPFMvc_ZVt1IEYwVM15PH7rcsig=.691b1cbb-56c3-4811-bcf1-1af8e408faf6@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
 <3vo2eYH7fWvzAdDgHPFMvc_ZVt1IEYwVM15PH7rcsig=.691b1cbb-56c3-4811-bcf1-1af8e408faf6@github.com>
Message-ID: <djTxkuWk-7_USCFE-0c4xq6HwFsmv1SQzaUTe3MALnk=.574fe636-f41d-4270-830d-43ab75343e0a@github.com>

On Thu, 27 Apr 2023 18:49:03 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

> With the upcoming refactor to make parse/build instance methods, there is a logical place and lifetime for caches.
> [?](#)

@briangoetz 
This is a different level of caches than the discussed ClassHierarchyResolver cache. 

Most of the class generation code starts with static ClassDesc constants (or references to ConstantDescs).
Internal caching of class internal name within each single ClassDesc (instead of repeated sub-stringing by an external utility method) has visible performance impact. From each of the static ClassDesc instances there are thousands of calls of their conversions to internal class names and the conversion always create a new sub-string instance. 
I don't agree with closing this PR, its function is complementary to the other performance improvements.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1527028304

From amitkumar at openjdk.org  Fri Apr 28 06:36:24 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 28 Apr 2023 06:36:24 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v3]
In-Reply-To: <8CWwPUezmxog5jKIR1zUBL94ptWuNGdXdRNR9fpvXno=.de92db33-481c-4090-96e1-3ea2b012a58c@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <1VOiJqfV7MR0h3qtLDOK6JjmSAiWP8cTOcXP9ZW0nTY=.79b86cdb-ad4f-4c0b-9010-43d385427a28@github.com>
 <8CWwPUezmxog5jKIR1zUBL94ptWuNGdXdRNR9fpvXno=.de92db33-481c-4090-96e1-3ea2b012a58c@github.com>
Message-ID: <iCJo8p73iis9xiXPBCKKXSlNNHanqlHGSxTTKMSKiM0=.a71d59f9-d2c2-446d-aca1-5eec2c801e82@github.com>

On Thu, 27 Apr 2023 01:04:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removes out1,out2 parameters
>
> Hello Lance,
> 
>> Jai, have you run this acrossed all of our Mach5 platforms?
> 
> Yes I did that yesterday and the tests were successful.

Hi @jaikiran, 
Would you like to integrate it today ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12283#issuecomment-1527049497

From alanb at openjdk.org  Fri Apr 28 06:56:54 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Apr 2023 06:56:54 GMT
Subject: RFR: 8302496: Runtime.exit incorrectly says it never throws an
 exception
In-Reply-To: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
References: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
Message-ID: <eVY0HhKjkKGrMMfVlfQLWvmbesi3l9ENunDAjEx9eJ8=.f2b97ad1-5cde-4b68-936f-64250e765a59@github.com>

On Thu, 27 Apr 2023 23:06:42 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Textual specification clarifications.

src/java.base/share/classes/java/lang/Runtime.java line 146:

> 144:      * If a security manager is present and its {@link SecurityManager#checkExit checkExit}
> 145:      * method disallows exiting with the specified status, throws {@link SecurityException}.
> 146:      * Otherwise, this method blocks indefinitely; it neither returns nor throws an exception

The SM is not long for this world.  So I'm in two minds about it making a farewell appearance in the first paragraph of the method description when we know we will have to remove this text very soon.  If we really need to change this now then maybe it could be reduced to "When a security manager is not set, this method never returns ..." so that the distraction of checkExit is not in the first paragraph.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13706#discussion_r1179989339

From jpai at openjdk.org  Fri Apr 28 08:08:24 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 28 Apr 2023 08:08:24 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v6]
In-Reply-To: <-EO2E5Juy8oYDmqHcd5420Ot3FUTWuDVcKrMQGvkAHM=.cabe3e0d-f204-4f60-80c2-ad75a8424b9b@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <-EO2E5Juy8oYDmqHcd5420Ot3FUTWuDVcKrMQGvkAHM=.cabe3e0d-f204-4f60-80c2-ad75a8424b9b@github.com>
Message-ID: <XANxg8qCtdGyHNgw8ONbP8PaVqJPUCn4E77ssLWEIik=.9b6f6a3b-84a9-4a09-8dde-43f1ada91d0d@github.com>

On Thu, 27 Apr 2023 17:05:24 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
>> 
>> Thanks to @jaikiran for amazing PR description.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes request by @turbanoff

Please go ahead and I can sponsor it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12283#issuecomment-1527136950

From simonis at openjdk.org  Fri Apr 28 08:48:53 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 28 Apr 2023 08:48:53 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v6]
In-Reply-To: <-EO2E5Juy8oYDmqHcd5420Ot3FUTWuDVcKrMQGvkAHM=.cabe3e0d-f204-4f60-80c2-ad75a8424b9b@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <-EO2E5Juy8oYDmqHcd5420Ot3FUTWuDVcKrMQGvkAHM=.cabe3e0d-f204-4f60-80c2-ad75a8424b9b@github.com>
Message-ID: <KKWxCPJ7UDl0HD9TfrbKC65Lx1wEkVcySSHO0Gsd0Qo=.672e31cf-eba0-4059-9706-2dcfe48491ba@github.com>

On Thu, 27 Apr 2023 17:05:24 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
>> 
>> Thanks to @jaikiran for amazing PR description.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes request by @turbanoff

This change looks good except for the small improvement I suggested for `Arrays.equals(..)`.

Sorry for not having seen this earlier. I'm somehow proficient with issues due to different zlib implementations and could have probably helped to push this trough a litter quicker :)

I can sponsor your change once you've made the changes.

test/jdk/java/util/zip/DeInflate.java line 164:

> 162:             out2 = baos.toByteArray();
> 163:             if (n != len ||
> 164:                 !Arrays.equals(Arrays.copyOf(in, len), Arrays.copyOf(out2, len)) ||

Instead of copying the arrays you can use `Arrays.equals(in, 0, len, out2, 0 len)`

-------------

Changes requested by simonis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12283#pullrequestreview-1405477007
PR Review Comment: https://git.openjdk.org/jdk/pull/12283#discussion_r1180095155

From amitkumar at openjdk.org  Fri Apr 28 09:23:59 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 28 Apr 2023 09:23:59 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v7]
In-Reply-To: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
Message-ID: <A4BPQIEz3oJbaAD6vcJc2L6-8NmoVCIV11tCudsA3XE=.308ba4c7-959f-4da8-8541-9e7d0c8d6562@github.com>

> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
> 
> Thanks to @jaikiran for amazing PR description.

Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:

  suggestion from @simonis

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12283/files
  - new: https://git.openjdk.org/jdk/pull/12283/files/bbeb8b27..6327033e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12283.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12283/head:pull/12283

PR: https://git.openjdk.org/jdk/pull/12283

From amitkumar at openjdk.org  Fri Apr 28 09:24:06 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 28 Apr 2023 09:24:06 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v6]
In-Reply-To: <KKWxCPJ7UDl0HD9TfrbKC65Lx1wEkVcySSHO0Gsd0Qo=.672e31cf-eba0-4059-9706-2dcfe48491ba@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <-EO2E5Juy8oYDmqHcd5420Ot3FUTWuDVcKrMQGvkAHM=.cabe3e0d-f204-4f60-80c2-ad75a8424b9b@github.com>
 <KKWxCPJ7UDl0HD9TfrbKC65Lx1wEkVcySSHO0Gsd0Qo=.672e31cf-eba0-4059-9706-2dcfe48491ba@github.com>
Message-ID: <dTrWXiupyt6M1hCqd-h4vWiNocTvVcd-w4z5B2lhT2A=.8c1225b3-e73c-4f08-a697-b5fa67a8022b@github.com>

On Fri, 28 Apr 2023 08:31:05 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changes request by @turbanoff
>
> test/jdk/java/util/zip/DeInflate.java line 164:
> 
>> 162:             out2 = baos.toByteArray();
>> 163:             if (n != len ||
>> 164:                 !Arrays.equals(Arrays.copyOf(in, len), Arrays.copyOf(out2, len)) ||
> 
> Instead of copying the arrays you can use `Arrays.equals(in, 0, len, out2, 0 len)`

>Sorry for not having seen this earlier. I'm somehow proficient with issues due to different zlib implementations and could have probably helped to push this trough a litter quicker :)

No issues, Next time I'll start by pinging you. ?

Thanks for review & suggestion

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12283#discussion_r1180139453

From simonis at openjdk.org  Fri Apr 28 09:24:00 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 28 Apr 2023 09:24:00 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v7]
In-Reply-To: <A4BPQIEz3oJbaAD6vcJc2L6-8NmoVCIV11tCudsA3XE=.308ba4c7-959f-4da8-8541-9e7d0c8d6562@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <A4BPQIEz3oJbaAD6vcJc2L6-8NmoVCIV11tCudsA3XE=.308ba4c7-959f-4da8-8541-9e7d0c8d6562@github.com>
Message-ID: <OIk-8zMQh56ovCjcfivbBCnkmw1AbI-e7KDToUIlEOk=.14a53e17-31dc-4ca2-bee7-ad9275ad0c1c@github.com>

On Fri, 28 Apr 2023 09:08:18 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
>> 
>> Thanks to @jaikiran for amazing PR description.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @simonis

Thanks, looks good now!

-------------

Marked as reviewed by simonis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12283#pullrequestreview-1405559661

From amitkumar at openjdk.org  Fri Apr 28 09:58:59 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 28 Apr 2023 09:58:59 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v8]
In-Reply-To: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
Message-ID: <w0vLxlVTIUpC5rjd0l4C_zBwc6NdzAMY8cc-rXXevoA=.210fbfa4-eeba-4a31-9ffd-0a0c4b37aa31@github.com>

> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
> 
> Thanks to @jaikiran for amazing PR description.

Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:

  removes extra closing paren.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12283/files
  - new: https://git.openjdk.org/jdk/pull/12283/files/6327033e..a1e2ace8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12283.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12283/head:pull/12283

PR: https://git.openjdk.org/jdk/pull/12283

From simonis at openjdk.org  Fri Apr 28 09:59:02 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 28 Apr 2023 09:59:02 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v7]
In-Reply-To: <A4BPQIEz3oJbaAD6vcJc2L6-8NmoVCIV11tCudsA3XE=.308ba4c7-959f-4da8-8541-9e7d0c8d6562@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <A4BPQIEz3oJbaAD6vcJc2L6-8NmoVCIV11tCudsA3XE=.308ba4c7-959f-4da8-8541-9e7d0c8d6562@github.com>
Message-ID: <Azt-r335K52-5l98JSZfuydsi4wmwTlYRJZiZP4Pymc=.04cdd9c1-77b4-49f3-9ef0-cf9e2cdc5bd8@github.com>

On Fri, 28 Apr 2023 09:23:59 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
>> 
>> Thanks to @jaikiran for amazing PR description.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @simonis

Changes requested by simonis (Reviewer).

test/jdk/java/util/zip/DeInflate.java line 164:

> 162:             out2 = baos.toByteArray();
> 163:             if (n != len ||
> 164:                 !Arrays.equals(in, 0, len, out2, 0, len)) ||

There's a `)` too much. you should at least run it a single time before pushing :)

-------------

PR Review: https://git.openjdk.org/jdk/pull/12283#pullrequestreview-1405576535
PR Review Comment: https://git.openjdk.org/jdk/pull/12283#discussion_r1180166033

From simonis at openjdk.org  Fri Apr 28 09:59:02 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 28 Apr 2023 09:59:02 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v7]
In-Reply-To: <Azt-r335K52-5l98JSZfuydsi4wmwTlYRJZiZP4Pymc=.04cdd9c1-77b4-49f3-9ef0-cf9e2cdc5bd8@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <A4BPQIEz3oJbaAD6vcJc2L6-8NmoVCIV11tCudsA3XE=.308ba4c7-959f-4da8-8541-9e7d0c8d6562@github.com>
 <Azt-r335K52-5l98JSZfuydsi4wmwTlYRJZiZP4Pymc=.04cdd9c1-77b4-49f3-9ef0-cf9e2cdc5bd8@github.com>
Message-ID: <EJH415BimAX-nwIyL0dVdXs2ZBXfhbS1hUzC04paW-E=.bfdaf7d7-b0d4-4275-8ef4-466581cfcd52@github.com>

On Fri, 28 Apr 2023 09:26:52 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   suggestion from @simonis
>
> test/jdk/java/util/zip/DeInflate.java line 164:
> 
>> 162:             out2 = baos.toByteArray();
>> 163:             if (n != len ||
>> 164:                 !Arrays.equals(in, 0, len, out2, 0, len)) ||
> 
> There's a `)` too much. you should at least run it a single time before pushing :)

And while your on it, can you please also fix the other occurences of `Arrays.equals()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12283#discussion_r1180173841

From amitkumar at openjdk.org  Fri Apr 28 09:59:03 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 28 Apr 2023 09:59:03 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v7]
In-Reply-To: <EJH415BimAX-nwIyL0dVdXs2ZBXfhbS1hUzC04paW-E=.bfdaf7d7-b0d4-4275-8ef4-466581cfcd52@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <A4BPQIEz3oJbaAD6vcJc2L6-8NmoVCIV11tCudsA3XE=.308ba4c7-959f-4da8-8541-9e7d0c8d6562@github.com>
 <Azt-r335K52-5l98JSZfuydsi4wmwTlYRJZiZP4Pymc=.04cdd9c1-77b4-49f3-9ef0-cf9e2cdc5bd8@github.com>
 <EJH415BimAX-nwIyL0dVdXs2ZBXfhbS1hUzC04paW-E=.bfdaf7d7-b0d4-4275-8ef4-466581cfcd52@github.com>
Message-ID: <BerPGHsM-27KjLgSR1CqfdMetGQZsMq5cufRdo7dJ8I=.826b2540-2b71-4bbb-9d12-a64f4b0b01ba@github.com>

On Fri, 28 Apr 2023 09:33:03 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> test/jdk/java/util/zip/DeInflate.java line 164:
>> 
>>> 162:             out2 = baos.toByteArray();
>>> 163:             if (n != len ||
>>> 164:                 !Arrays.equals(in, 0, len, out2, 0, len)) ||
>> 
>> There's a `)` too much. you should at least run it a single time before pushing :)
>
> And while your on it, can you please also fix the other occurences of `Arrays.equals()`.

oops, I made these change on Lpar and tested there & pushed the changes from local machine.

current changes are working fine.

really sorry.. :-(

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12283#discussion_r1180184731

From asotona at openjdk.org  Fri Apr 28 10:30:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 28 Apr 2023 10:30:59 GMT
Subject: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info
 in ClassDesc [v2]
In-Reply-To: <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
References: <U4MsSxspl7_AFPakrU1JQeojfpbm8jAqjX7b2t0FBwI=.b199077a-9039-4b3b-956e-83a870fce2f9@github.com>
 <WuBUIYV_q4kTTwm9XO3MhLF4SFvJ4zjhpWT4_h9q0Ew=.4fb8f6ed-bf57-483d-ab4e-e87d597a3b94@github.com>
Message-ID: <vF4pDE6Omw7wE3PyxHCx5uwZNmGaVgXRQutwtiY21ng=.bdf0d88f-0ca1-446e-a4c4-8741d7a116d9@github.com>

On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add a method `internalName` to `ClassDesc`, and unifies handling of string representation of a class constant in CONSTANT_Class_info via `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. In particular, `ofInternalName` now accepts arrays.
>> 
>> The motivation of this API is that avoiding frequent String creations via caching (enabled by this new API, will be in a separate patch) would speed up Classfile API's [writing of simple class files](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/classfile/Write.java) by 1/3. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000296.html for more context.
>> 
>> This API is futureproof: for Valhalla's Q-types, it will return their string representation in CONSTANT_Class_info, which is most likely their full descriptor string.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306697/java.base/java/lang/constant/ClassDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify ofInternalName and internalName, document about CONSTANT_Class_info, remove misleading JVMS 4.4.1 links

I benchmarked merged this PR with #13671 and benefits of internal names caching in ClassDesc are insignificant (~2% performance boost).
So I'm taking back my disagreement with closing this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13598#issuecomment-1527330005

From lancea at openjdk.org  Fri Apr 28 10:42:01 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 28 Apr 2023 10:42:01 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v8]
In-Reply-To: <w0vLxlVTIUpC5rjd0l4C_zBwc6NdzAMY8cc-rXXevoA=.210fbfa4-eeba-4a31-9ffd-0a0c4b37aa31@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <w0vLxlVTIUpC5rjd0l4C_zBwc6NdzAMY8cc-rXXevoA=.210fbfa4-eeba-4a31-9ffd-0a0c4b37aa31@github.com>
Message-ID: <Nce5UkOot2qQ10goVz-omoksduMAGlHVlEs0HGD41Wg=.2eb5b40a-0a1e-4f4b-8e2b-8de61de49347@github.com>

On Fri, 28 Apr 2023 09:58:59 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
>> 
>> Thanks to @jaikiran for amazing PR description.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removes extra closing paren.

I think this looks better.  The ByteArrayOutputStream on line 50 could also be wrapped in a try-with-resources and it would be nice to do that as part of this PR if possible

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12283#pullrequestreview-1405677627

From amitkumar at openjdk.org  Fri Apr 28 11:00:53 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 28 Apr 2023 11:00:53 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v9]
In-Reply-To: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
Message-ID: <9WYI4WY1QfbADb84yTZt1R7T7aCXt-HcCBbEtVpEhZc=.5c127372-0c76-4259-9275-388f44cb833c@github.com>

> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
> 
> Thanks to @jaikiran for amazing PR description.

Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:

  changes from @LanceAndersen

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12283/files
  - new: https://git.openjdk.org/jdk/pull/12283/files/a1e2ace8..368be8e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=07-08

  Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12283.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12283/head:pull/12283

PR: https://git.openjdk.org/jdk/pull/12283

From aturbanov at openjdk.org  Fri Apr 28 11:01:23 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 28 Apr 2023 11:01:23 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v9]
In-Reply-To: <9WYI4WY1QfbADb84yTZt1R7T7aCXt-HcCBbEtVpEhZc=.5c127372-0c76-4259-9275-388f44cb833c@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <9WYI4WY1QfbADb84yTZt1R7T7aCXt-HcCBbEtVpEhZc=.5c127372-0c76-4259-9275-388f44cb833c@github.com>
Message-ID: <WGbpI3QThQLoT6SvVvLnwL7UQlp-EYn1rh1D50g6tOo=.cb540c9f-bbb4-4d0b-9622-1f43c247dc8c@github.com>

On Fri, 28 Apr 2023 10:42:32 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
>> 
>> Thanks to @jaikiran for amazing PR description.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes from @LanceAndersen

test/jdk/java/util/zip/DeInflate.java line 50:

> 48:         Arrays.fill(out2, (byte)0);
> 49: 
> 50:         try(ByteArrayOutputStream baos = new ByteArrayOutputStream()) {

Suggestion:

        try (ByteArrayOutputStream baos = new ByteArrayOutputStream()) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12283#discussion_r1180260278

From amitkumar at openjdk.org  Fri Apr 28 11:18:56 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 28 Apr 2023 11:18:56 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v10]
In-Reply-To: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
Message-ID: <R1Py5RLvQSnJqWtaYtFA4zMgg3HjQkpksMBEtytPG5U=.c78ae795-44f9-46ae-8931-f7aee5fd3ec6@github.com>

> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
> 
> Thanks to @jaikiran for amazing PR description.

Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:

  added space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12283/files
  - new: https://git.openjdk.org/jdk/pull/12283/files/368be8e4..d50f5cbb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12283.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12283/head:pull/12283

PR: https://git.openjdk.org/jdk/pull/12283

From aturbanov at openjdk.org  Fri Apr 28 11:34:22 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 28 Apr 2023 11:34:22 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v10]
In-Reply-To: <R1Py5RLvQSnJqWtaYtFA4zMgg3HjQkpksMBEtytPG5U=.c78ae795-44f9-46ae-8931-f7aee5fd3ec6@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <R1Py5RLvQSnJqWtaYtFA4zMgg3HjQkpksMBEtytPG5U=.c78ae795-44f9-46ae-8931-f7aee5fd3ec6@github.com>
Message-ID: <nwqEgPlse1fAZX05xrBDlShWCeJBY5F7EA_FOSrNAAw=.ff471d91-c015-43c2-a52c-87d6f56da995@github.com>

On Fri, 28 Apr 2023 11:18:56 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
>> 
>> Thanks to @jaikiran for amazing PR description.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added space

Marked as reviewed by aturbanov (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12283#pullrequestreview-1405758295

From simonis at openjdk.org  Fri Apr 28 11:34:23 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 28 Apr 2023 11:34:23 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v10]
In-Reply-To: <R1Py5RLvQSnJqWtaYtFA4zMgg3HjQkpksMBEtytPG5U=.c78ae795-44f9-46ae-8931-f7aee5fd3ec6@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <R1Py5RLvQSnJqWtaYtFA4zMgg3HjQkpksMBEtytPG5U=.c78ae795-44f9-46ae-8931-f7aee5fd3ec6@github.com>
Message-ID: <mMLzr9kgiZCMMKL_fiYNFTIvTQ18-Xg11vM3uETw7KU=.4a64cfe6-30fd-42a0-a300-853523483e55@github.com>

On Fri, 28 Apr 2023 11:18:56 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
>> 
>> Thanks to @jaikiran for amazing PR description.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added space

Marked as reviewed by simonis (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12283#pullrequestreview-1405758651

From ecki at zusammenkunft.net  Fri Apr 28 11:40:03 2023
From: ecki at zusammenkunft.net (Bernd)
Date: Fri, 28 Apr 2023 13:40:03 +0200
Subject: There is unnecessary resource consumption in
 `SecureRandom.getInstance()`.
In-Reply-To: <CACzBzePNaPDm_JQhAdT9sRKeRKE8WuRi9yLSbfxcyi=HMjacYA@mail.gmail.com>
References: <CACzBzePNaPDm_JQhAdT9sRKeRKE8WuRi9yLSbfxcyi=HMjacYA@mail.gmail.com>
Message-ID: <7BB18D5E-8F27-4545-8C70-621CF2D8FC47@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230428/e08d0f81/attachment-0001.htm>

From amitkumar at openjdk.org  Fri Apr 28 11:49:23 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 28 Apr 2023 11:49:23 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v10]
In-Reply-To: <R1Py5RLvQSnJqWtaYtFA4zMgg3HjQkpksMBEtytPG5U=.c78ae795-44f9-46ae-8931-f7aee5fd3ec6@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <R1Py5RLvQSnJqWtaYtFA4zMgg3HjQkpksMBEtytPG5U=.c78ae795-44f9-46ae-8931-f7aee5fd3ec6@github.com>
Message-ID: <I9amtFg9vRCVL5rtf3Tav68xaYQUNo8SEmcxR3yl6bQ=.8011296b-582a-4d35-9d61-6644cd304c27@github.com>

On Fri, 28 Apr 2023 11:18:56 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
>> 
>> Thanks to @jaikiran for amazing PR description.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added space

Thanks to all for review & suggestions,

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12283#issuecomment-1527426368

From alanb at openjdk.org  Fri Apr 28 12:09:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Apr 2023 12:09:57 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
Message-ID: <yk-I2N6h2l7wEgkcHeBAt46OSbDrDxt-P8QgC7pTO_o=.8fa9c1ee-604d-4b97-bcd4-c70355c9564f@github.com>

On Fri, 28 Apr 2023 01:03:28 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.
> 
> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.
> 
> To build the statically linked executable:
> 
> 1. Configure the JDK build with --with-static-java=yes
> 2. Build static-java-image, e.g. 'make jdk-image static-java-image'
> 
>  The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.
> 
> Following is a summary of the changes in this PR:
> 
> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.
> 
> - Changes in make/Main.gmk
> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.
> 
> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.
> 
> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.
> 
> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.
> 
> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk.
> 
> - In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well.
> 
> - In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk.
> 
> Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk.

The JDK moved to modular run-time images in JDK 9 ([JEP 220](https://openjdk.org/jeps/220) that are created with the jlink tool. The eventual goal here is to make it possible to produce a statically linked image and I suspect there will need to be some figuring out as to where jlink fits. It might be that the JDK produces a set of packaged modules containing the .a files and jlink involves the native linker. I think some future JEP will need describe all this.

If I understand the make file changes proposed here, it runs the native linker to create "javastatic" with the launcher, libjvm and other JNI libs linked into one executable, this is generated and copied into the run-time image created by jlink. I think this will need discussion as its more like an overlay. I think it is useful to have the build create the .a files as that's the first step towards putting them into packaged modules for producing static images.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1527460643

From amitkumar at openjdk.org  Fri Apr 28 12:13:55 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 28 Apr 2023 12:13:55 GMT
Subject: Integrated: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
Message-ID: <6Mteeaz7hM4D4gZGao4eRe89wVpYmMfC6kBSF1PYhZ0=.4245ff9c-9dbd-4c92-bc18-298798efbfe7@github.com>

On Mon, 30 Jan 2023 08:03:38 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. This PR updates the check method in the DeInflate test to no longer rely on pre-defined lengths/sizes to determine whether deflate followed by an inflate of data worked correctly. These sizes can vary depending on the underlying zlib implementations. The updated check method now uses a `ByteArrayOutputStream` to deflate into and then inflate from. 
> 
> Thanks to @jaikiran for amazing PR description.

This pull request has now been integrated.

Changeset: fee02f06
Author:    Amit Kumar <amitkumar at openjdk.org>
Committer: Volker Simonis <simonis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fee02f066879e77e55e217660daa46607778b6e8
Stats:     52 lines in 1 file changed: 31 ins; 2 del; 19 mod

8299748: java/util/zip/Deinflate.java failing on s390x

Reviewed-by: jpai, lancea, simonis, aturbanov

-------------

PR: https://git.openjdk.org/jdk/pull/12283

From tonyp at openjdk.org  Fri Apr 28 12:47:28 2023
From: tonyp at openjdk.org (Antonios Printezis)
Date: Fri, 28 Apr 2023 12:47:28 GMT
Subject: RFR: JDK-8307063: When cross-compiling with hsdis/binutils,
 buildjdk creation fails [v3]
In-Reply-To: <uEFgpkJBPFecYgvs-bm7KDV_Zt6u0CPGb_11OU5a6kc=.bb8c7d8b-c6b1-4e51-b169-fad2615caf26@github.com>
References: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>
 <42egl-6Z39iw6aXBLn0GwNZ3-qRdfKMsgvvCgIckvNw=.3f0e3d79-2554-4faa-8f8d-c6c787890a51@github.com>
 <whYSb3d8ZgzxXmKnQRyKjchZ_vusljf2JE7PX8qSML8=.5eeb2dae-f6be-41df-955b-5e455a315fd0@github.com>
 <uEFgpkJBPFecYgvs-bm7KDV_Zt6u0CPGb_11OU5a6kc=.bb8c7d8b-c6b1-4e51-b169-fad2615caf26@github.com>
Message-ID: <IKICOxKBpdtaVQs_HHPocH1jHJfUr8VSUcchxgF6NTg=.cd50abe3-6fea-463c-92ca-2f816562566d@github.com>

On Thu, 27 Apr 2023 21:31:09 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Marked as reviewed by erikj (Reviewer).
>
>> @erikj79 Thanks! I assume the integrate command will actually squash the three commits and rebase them on top of master as one commit?
> 
> Yes, all you need to do is to issue the integrate command, just like the bot instructed [here](https://github.com/openjdk/jdk/pull/13697#issuecomment-1526469383).

All set! Thanks for your help @erikj79 !!!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13697#issuecomment-1527498108

From tonyp at openjdk.org  Fri Apr 28 12:47:28 2023
From: tonyp at openjdk.org (Antonios Printezis)
Date: Fri, 28 Apr 2023 12:47:28 GMT
Subject: Integrated: JDK-8307063: When cross-compiling with hsdis/binutils,
 buildjdk creation fails
In-Reply-To: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>
References: <V-bvq--deJKdboPksO3yCMKJDTVVcBeZf4uOK1bbDL4=.6e567ef5-07d7-44e9-a31e-84d116756a51@github.com>
Message-ID: <2qa7iCqE94hfxY_ZWGR8j16Ipe0FkKeev8BOzAIB2ok=.8cd174ff-6b60-4e51-9032-38be9a536f63@github.com>

On Thu, 27 Apr 2023 17:57:05 GMT, Antonios Printezis <tonyp at openjdk.org> wrote:

> Fix is to exclude hsdis when building the buildjdk.

This pull request has now been integrated.

Changeset: 83a98c66
Author:    Antonios Printezis <tonyp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83a98c66f1747fec3da77578b646498c4cb5637d
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8307063: When cross-compiling with hsdis/binutils, buildjdk creation fails

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/13697

From jvernee at openjdk.org  Fri Apr 28 12:59:26 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 28 Apr 2023 12:59:26 GMT
Subject: RFR: 8304888: Add dedicated VMProps for linker and fallback linker
 [v3]
In-Reply-To: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
References: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
Message-ID: <V5QWHauI0ClkgkAR7z_ggUUk4_m3S3XD8JaFsISWrao=.d3ec8b03-b0ea-4dc8-baa8-d5136e7298ff@github.com>

> This patch adds a dedicated jtreg property to check which CABI is being used by the JDK, which can be used both to check whether the foreign linker is supported, and whether the fallback linker is being used. (and, possibly it can also be use to check for a particular ABI in case we want to add ABI specific tests).
> 
> Checking whether the foreign linker is supported currently requires using an unwieldy expression that checks if we are running on a platform that has a foreign linker port. Checking for the fallback linker currently uses `vm.flavor != "zero"` which is not always correct, since the fallback linker can also be used on other platforms which are not `zero`.
> 
> To initialize the property, VMProps directly reads `jdk.internal.foreig.CABI::current()`. Since this class is in an internal package, `--add-exports` flags are added as javac flags and VM flags for the extra prop definitions class.

Jorn Vernee 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 VMProps
 - use only jdk.CABI property
 - use extra props to check for linker
 - Add fallbackLinker vmprop
 - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
   
   rename has_port
 - rename has_port
 - Merge pull request #2 from JornVernee/WSL_BB
   
   account for missing functional in WSL in TestByteBuffer
 - account for missing mincore on WSL in TestByteBuffer
 - Merge branch 'master' into PR_21_V2
 - 8305369: Issues in zero-length memory segment javadoc section
 - ... and 34 more: https://git.openjdk.org/jdk/compare/b827ce83...8a6df30e

-------------

Changes: https://git.openjdk.org/jdk/pull/13429/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13429&range=02
  Stats: 99 lines in 50 files changed: 17 ins; 3 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/13429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13429/head:pull/13429

PR: https://git.openjdk.org/jdk/pull/13429

From alanb at openjdk.org  Fri Apr 28 13:20:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Apr 2023 13:20:53 GMT
Subject: RFR: 8304888: Add dedicated VMProps for linker and fallback linker
 [v3]
In-Reply-To: <V5QWHauI0ClkgkAR7z_ggUUk4_m3S3XD8JaFsISWrao=.d3ec8b03-b0ea-4dc8-baa8-d5136e7298ff@github.com>
References: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
 <V5QWHauI0ClkgkAR7z_ggUUk4_m3S3XD8JaFsISWrao=.d3ec8b03-b0ea-4dc8-baa8-d5136e7298ff@github.com>
Message-ID: <CjkahkYcB6cdyGZSg9F82SG-fnmv8Qk2zxu5rgX2T24=.3be5e620-9367-47eb-bb92-5921c567af20@github.com>

On Fri, 28 Apr 2023 12:59:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch adds a dedicated jtreg property to check which CABI is being used by the JDK, which can be used both to check whether the foreign linker is supported, and whether the fallback linker is being used. (and, possibly it can also be use to check for a particular ABI in case we want to add ABI specific tests).
>> 
>> Checking whether the foreign linker is supported currently requires using an unwieldy expression that checks if we are running on a platform that has a foreign linker port. Checking for the fallback linker currently uses `vm.flavor != "zero"` which is not always correct, since the fallback linker can also be used on other platforms which are not `zero`.
>> 
>> To initialize the property, VMProps directly reads `jdk.internal.foreig.CABI::current()`. Since this class is in an internal package, `--add-exports` flags are added as javac flags and VM flags for the extra prop definitions class.
>
> Jorn Vernee 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 VMProps
>  - use only jdk.CABI property
>  - use extra props to check for linker
>  - Add fallbackLinker vmprop
>  - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
>    
>    rename has_port
>  - rename has_port
>  - Merge pull request #2 from JornVernee/WSL_BB
>    
>    account for missing functional in WSL in TestByteBuffer
>  - account for missing mincore on WSL in TestByteBuffer
>  - Merge branch 'master' into PR_21_V2
>  - 8305369: Issues in zero-length memory segment javadoc section
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/b827ce83...8a6df30e

Marked as reviewed by alanb (Reviewer).

test/jtreg-ext/requires/VMProps.java line 657:

> 655:         return "" + result;
> 656:     }
> 657: 

It might be useful to add a comment on `cabi()` as it may not be obvious that this is C ABI.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13429#pullrequestreview-1405909218
PR Review Comment: https://git.openjdk.org/jdk/pull/13429#discussion_r1180380624

From jlahoda at openjdk.org  Fri Apr 28 13:33:25 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 28 Apr 2023 13:33:25 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v3]
In-Reply-To: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com>
Message-ID: <YdoBBdeBm-cyAmDLth2Hwz4x21D6cvlkwFCJ6mcNIqU=.2a6b62aa-a9cf-477e-90e5-d27bdd20e82c@github.com>

On Thu, 27 Apr 2023 18:21:56 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into 8306112
>  - PreviewFeatures.isEnabled()
>  - Clean up isPreview
>  - Missing exception
>  - Corrections
>  - Update VM.java
>  - Clean up testing
>  - Update TestJavacTaskScanner.java
>  - Merge branch 'master' into 8306112
>  - Clean up
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 64:

> 62: 
> 63:             for (Method method : refc.getDeclaredMethods()) {
> 64:                 int argc = method.getParameterCount();

Nit: unused variable?

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 147:

> 145:             }
> 146: 
> 147:             return mainClass.getMethod("main", String[].class);

Nit: could return `mainMethod` here, correct?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 453:

> 451:         }
> 452:         if (!SourceVersion.isIdentifier(simplename) || SourceVersion.isKeyword(simplename)) {
> 453:             log.error(null, Errors.BadFileName(simplename));

Suggestion:

            log.error(tree.pos(), Errors.BadFileName(simplename));

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 462:

> 460:         for (JCTree def : tree.defs) {
> 461:             if (def.hasTag(Tag.PACKAGEDEF)) {
> 462:                 log.error(null, Errors.AnonymousMainClassShouldNotHavePackageDeclaration);

Suggestion:

                log.error(def.pos(), Errors.AnonymousMainClassShouldNotHavePackageDeclaration);

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 438:

> 436:             Class<?> appClass = Class.forName(mainClassName, true, cl);
> 437:             Method main = MainMethodFinder.findMainMethod(appClass);
> 438:             if (!PreviewFeatures.isEnabled() && (!isStatic(main) || !isPublic(main))) {

It seems one can run a main method without parameters without `--enable-preview` using this codepath. That is presumably not intended.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 627:

> 625:         }
> 626: 
> 627:         public boolean isAnonymousMainClass() {

This method seems a bit confusing to me. I believe the fields and methods will be stripped from `defs` if/when the wrapping class is created, which will mean this method will start to return `false`, no? It overall does not seem like a generally useful predicate.

(If I understand this correctly, if we created the wrapping class in parser neither of these two methods would be needed.)

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 640:

> 638:             // Find anonymous main class.
> 639:             for (JCTree def : defs) {
> 640:                 if (def.hasTag(CLASSDEF)) {

Nit, in cases like this, we lately tend to write `def instanceof JCClassDecl cls`, although we understand this way to check the AST is only safe inside javac.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180360702
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180360546
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180378753
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180378611
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180375691
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180389813
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180392123

From jlahoda at openjdk.org  Fri Apr 28 13:33:28 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 28 Apr 2023 13:33:28 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v2]
In-Reply-To: <BOXMmQgrlZClYv2leL5C52nwYTnTZ00oLL-Y87rdC0g=.722edbbc-1160-458d-b621-09af904d9c2c@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <osNSUyEj1mUrULK9eKwnO1SQqg1OLygKUKCFfoS_lwc=.f8c3e61b-6200-42f3-80cc-51334e4e7502@github.com>
 <NZ5sMaBOg79-lhBtMm44HjHXVL_WAcedBDNGllRgp3Q=.e934db5b-d6c8-4e44-82f5-a92ff2972c56@github.com>
 <YopNQ7jjAg7Z64IZkD_2as39dBcUj0hHWKB8S17VlDc=.9168990a-2444-4c0a-afac-bc8640742f76@github.com>
 <BOXMmQgrlZClYv2leL5C52nwYTnTZ00oLL-Y87rdC0g=.722edbbc-1160-458d-b621-09af904d9c2c@github.com>
Message-ID: <pGrlaRCkvCS6wlF6rxw6y8ewTdTUjv5li0C2LXkcJIY=.68d04589-beb1-480d-830d-f1d19756bfc9@github.com>

On Thu, 27 Apr 2023 20:34:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The source file name is not available until after parsing.
>
> I see that logic in JavaCompiler - I wonder if that's just the way it is, or if there's a deeper reason as to why the sourcefile is set on the toplevel unit *after* parsing (I don't think I can see any, in which case that might be changed if that makes the rest of the code simpler). @lahodaj what do you think?

I believe we were discussing this some time ago, and there were some problems. I don't recall the exact details, but I'll try to look into this later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180377062

From rriggs at openjdk.org  Fri Apr 28 14:16:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 28 Apr 2023 14:16:56 GMT
Subject: RFR: 8296935: Arrays.asList() can return a List that throws
 undocumented ArrayStoreException
In-Reply-To: <pgp8ceubOPPxYan0QoWmM4QSByWwlenrFGIvtpF61pc=.1f8f0180-6f0f-4110-9921-7864dd3eecaf@github.com>
References: <pgp8ceubOPPxYan0QoWmM4QSByWwlenrFGIvtpF61pc=.1f8f0180-6f0f-4110-9921-7864dd3eecaf@github.com>
Message-ID: <Q9pIEYkLNihqtfj11DRfg1ameL3iYBCnSg65hJH-C1U=.330e0a5b-2194-43a3-b785-eb0846bd0512@github.com>

On Thu, 27 Apr 2023 18:36:53 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> ?

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13698#pullrequestreview-1406036844

From jlaskey at openjdk.org  Fri Apr 28 14:34:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Apr 2023 14:34:24 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v3]
In-Reply-To: <YdoBBdeBm-cyAmDLth2Hwz4x21D6cvlkwFCJ6mcNIqU=.2a6b62aa-a9cf-477e-90e5-d27bdd20e82c@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com>
 <YdoBBdeBm-cyAmDLth2Hwz4x21D6cvlkwFCJ6mcNIqU=.2a6b62aa-a9cf-477e-90e5-d27bdd20e82c@github.com>
Message-ID: <vFIyeMfBk6kDPwUVa5oUDI0JDPyJR76u2UODOmdGcWQ=.068db972-064e-4ae4-ac40-0bd57efebb69@github.com>

On Fri, 28 Apr 2023 12:45:35 GMT, Jan Lahoda <jlahoda 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 14 commits:
>> 
>>  - Merge branch 'master' into 8306112
>>  - PreviewFeatures.isEnabled()
>>  - Clean up isPreview
>>  - Missing exception
>>  - Corrections
>>  - Update VM.java
>>  - Clean up testing
>>  - Update TestJavacTaskScanner.java
>>  - Merge branch 'master' into 8306112
>>  - Clean up
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 64:
> 
>> 62: 
>> 63:             for (Method method : refc.getDeclaredMethods()) {
>> 64:                 int argc = method.getParameterCount();
> 
> Nit: unused variable?

Remnant.

> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 147:
> 
>> 145:             }
>> 146: 
>> 147:             return mainClass.getMethod("main", String[].class);
> 
> Nit: could return `mainMethod` here, correct?

Yes

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 453:
> 
>> 451:         }
>> 452:         if (!SourceVersion.isIdentifier(simplename) || SourceVersion.isKeyword(simplename)) {
>> 453:             log.error(null, Errors.BadFileName(simplename));
> 
> Suggestion:
> 
>             log.error(tree.pos(), Errors.BadFileName(simplename));

Changing

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 462:
> 
>> 460:         for (JCTree def : tree.defs) {
>> 461:             if (def.hasTag(Tag.PACKAGEDEF)) {
>> 462:                 log.error(null, Errors.AnonymousMainClassShouldNotHavePackageDeclaration);
> 
> Suggestion:
> 
>                 log.error(def.pos(), Errors.AnonymousMainClassShouldNotHavePackageDeclaration);

Changing

> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 438:
> 
>> 436:             Class<?> appClass = Class.forName(mainClassName, true, cl);
>> 437:             Method main = MainMethodFinder.findMainMethod(appClass);
>> 438:             if (!PreviewFeatures.isEnabled() && (!isStatic(main) || !isPublic(main))) {
> 
> It seems one can run a main method without parameters without `--enable-preview` using this codepath. That is presumably not intended.

MainMethodFinder won't return a no arg method is without --enable-preview. The local testing here is to specialize the error massages.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180477997
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180477664
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180482962
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180482213
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180479992

From jlahoda at openjdk.org  Fri Apr 28 14:35:53 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 28 Apr 2023 14:35:53 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v3]
In-Reply-To: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com>
Message-ID: <tBptI_ztcnM2K-S151JevBii232magf3-R3OJbUlHcg=.2599f264-2c09-4fce-b6c0-0be430d6b98d@github.com>

On Thu, 27 Apr 2023 18:21:56 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into 8306112
>  - PreviewFeatures.isEnabled()
>  - Clean up isPreview
>  - Missing exception
>  - Corrections
>  - Update VM.java
>  - Clean up testing
>  - Update TestJavacTaskScanner.java
>  - Merge branch 'master' into 8306112
>  - Clean up
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3933:

> 3931:                 if (Feature.ANONYMOUS_MAIN_CLASSES.allowedInSource(source) &&
> 3932:                         !isDeclaration() &&
> 3933:                         (token.kind == VOID || token.kind == IDENTIFIER)) {

These checks (`token.kind == VOID || token.kind == IDENTIFIER`) for token kind will fail to parse fields of primitive types (or methods with primitive types as a return type)? Either the tests must include the primitive types, or (maybe) just this test can be avoided completely?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180481474

From jlaskey at openjdk.org  Fri Apr 28 14:50:52 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Apr 2023 14:50:52 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v3]
In-Reply-To: <YdoBBdeBm-cyAmDLth2Hwz4x21D6cvlkwFCJ6mcNIqU=.2a6b62aa-a9cf-477e-90e5-d27bdd20e82c@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com>
 <YdoBBdeBm-cyAmDLth2Hwz4x21D6cvlkwFCJ6mcNIqU=.2a6b62aa-a9cf-477e-90e5-d27bdd20e82c@github.com>
Message-ID: <83q-SFDWKgp-HNpYY63y7P9WDkYOUuMtXequYaRj4DY=.5295acd1-7c05-4fbd-9f7c-8f8ac6e7804d@github.com>

On Fri, 28 Apr 2023 13:13:57 GMT, Jan Lahoda <jlahoda 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 14 commits:
>> 
>>  - Merge branch 'master' into 8306112
>>  - PreviewFeatures.isEnabled()
>>  - Clean up isPreview
>>  - Missing exception
>>  - Corrections
>>  - Update VM.java
>>  - Clean up testing
>>  - Update TestJavacTaskScanner.java
>>  - Merge branch 'master' into 8306112
>>  - Clean up
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 627:
> 
>> 625:         }
>> 626: 
>> 627:         public boolean isAnonymousMainClass() {
> 
> This method seems a bit confusing to me. I believe the fields and methods will be stripped from `defs` if/when the wrapping class is created, which will mean this method will start to return `false`, no? It overall does not seem like a generally useful predicate.
> 
> (If I understand this correctly, if we created the wrapping class in parser neither of these two methods would be needed.)

Inlining

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 640:
> 
>> 638:             // Find anonymous main class.
>> 639:             for (JCTree def : defs) {
>> 640:                 if (def.hasTag(CLASSDEF)) {
> 
> Nit, in cases like this, we lately tend to write `def instanceof JCClassDecl cls`, although we understand this way to check the AST is only safe inside javac.

Changing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180491264
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180491108

From jlaskey at openjdk.org  Fri Apr 28 15:30:29 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Apr 2023 15:30:29 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v4]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <jk-xh0-_62j-REBStiofDN8jkKwhGSgNbcB7kMi2HNM=.daa7945d-db76-4c64-a8bb-6d0253ee7bf4@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Recommended changes #1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/53a5321d..f66f6e49

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=02-03

  Stats: 222 lines in 11 files changed: 58 ins; 126 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From jlaskey at openjdk.org  Fri Apr 28 15:30:55 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Apr 2023 15:30:55 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v3]
In-Reply-To: <tBptI_ztcnM2K-S151JevBii232magf3-R3OJbUlHcg=.2599f264-2c09-4fce-b6c0-0be430d6b98d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com>
 <tBptI_ztcnM2K-S151JevBii232magf3-R3OJbUlHcg=.2599f264-2c09-4fce-b6c0-0be430d6b98d@github.com>
Message-ID: <WxN74RDMgPo08u1YejuxXlZbUyQ7wZejfhmjihq0gNE=.5563d1f7-116b-47fc-9364-f1e5c412381c@github.com>

On Fri, 28 Apr 2023 14:26:10 GMT, Jan Lahoda <jlahoda 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 14 commits:
>> 
>>  - Merge branch 'master' into 8306112
>>  - PreviewFeatures.isEnabled()
>>  - Clean up isPreview
>>  - Missing exception
>>  - Corrections
>>  - Update VM.java
>>  - Clean up testing
>>  - Update TestJavacTaskScanner.java
>>  - Merge branch 'master' into 8306112
>>  - Clean up
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3933:
> 
>> 3931:                 if (Feature.ANONYMOUS_MAIN_CLASSES.allowedInSource(source) &&
>> 3932:                         !isDeclaration() &&
>> 3933:                         (token.kind == VOID || token.kind == IDENTIFIER)) {
> 
> These checks (`token.kind == VOID || token.kind == IDENTIFIER`) for token kind will fail to parse fields of primitive types (or methods with primitive types as a return type)? Either the tests must include the primitive types, or (maybe) just this test can be avoided completely?

Things have moved on since.  Changing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180512100

From jlaskey at openjdk.org  Fri Apr 28 15:55:29 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Apr 2023 15:55:29 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v5]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <OFJq7g-em5nzEdPjg3AAxAoeq_s_5aseuQszO_93vBg=.b808b106-c26e-45f0-957c-4b2b26d46c3f@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Can't be invokeExact for instance main

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/f66f6e49..e5ca303a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From lancea at openjdk.org  Fri Apr 28 16:16:23 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 28 Apr 2023 16:16:23 GMT
Subject: RFR: 8296935: Arrays.asList() can return a List that throws
 undocumented ArrayStoreException
In-Reply-To: <pgp8ceubOPPxYan0QoWmM4QSByWwlenrFGIvtpF61pc=.1f8f0180-6f0f-4110-9921-7864dd3eecaf@github.com>
References: <pgp8ceubOPPxYan0QoWmM4QSByWwlenrFGIvtpF61pc=.1f8f0180-6f0f-4110-9921-7864dd3eecaf@github.com>
Message-ID: <LeiBu3QTjB53XBl8wA8EXX__LNGL0J3HFit3CWSSkEk=.b87e14b8-b814-4f40-a4ae-d70887f88b96@github.com>

On Thu, 27 Apr 2023 18:36:53 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> ?

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13698#pullrequestreview-1406240035

From duke at openjdk.org  Fri Apr 28 16:36:57 2023
From: duke at openjdk.org (Madjosz)
Date: Fri, 28 Apr 2023 16:36:57 GMT
Subject: Integrated: 8302983: ZoneRulesProvider.registerProvider() twice will
 remove provider
In-Reply-To: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
Message-ID: <nEVQOx5QSQJhl2y6h3i6qT4RocoBjdPlkGvvyCLily4=.4d21c348-6ac8-4c8a-9c3a-13dd9bdf0946@github.com>

On Tue, 21 Feb 2023 13:44:52 GMT, Madjosz <duke at openjdk.org> wrote:

> Fixes JDK-8302983 (and duplicate JDK-8302898)

This pull request has now been integrated.

Changeset: f83e7302
Author:    Madjosz <28844868+Madjosz at users.noreply.github.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f83e7302c1660c128f866daa7317bc1dce156686
Stats:     87 lines in 2 files changed: 63 ins; 17 del; 7 mod

8302983: ZoneRulesProvider.registerProvider() twice will remove provider

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/12690

From sean.mullan at oracle.com  Fri Apr 28 13:02:02 2023
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 28 Apr 2023 09:02:02 -0400
Subject: There is unnecessary resource consumption in
 `SecureRandom.getInstance()`.
In-Reply-To: <7BB18D5E-8F27-4545-8C70-621CF2D8FC47@hxcore.ol>
References: <CACzBzePNaPDm_JQhAdT9sRKeRKE8WuRi9yLSbfxcyi=HMjacYA@mail.gmail.com>
 <7BB18D5E-8F27-4545-8C70-621CF2D8FC47@hxcore.ol>
Message-ID: <5b97ea90-c5ec-bf8e-5e8b-1e7aafc5dedb@oracle.com>

[This should be discussed on the security alias so I am copying 
security-dev and -bcc-ing core-libs-dev]

As Bernd noted, use of SHA1PRNG should ideally be replaced with a 
stronger secure random algorithm, so the impact of this issue is 
probably not that significant. That said, I think this is still worthy 
of fixing.

On 4/28/23 7:40 AM, Bernd wrote:
> There are two solutions I think.
> 
> 1. Create a constructor for SecureRandom.

#1 seems easy enough. We can add a SecureRandom(SecureRandomParameters) 
to sun.security.provider.SecureRandom. (The ctor can ignore the 
parameter and just call SecureRandom()).

I can file an issue on your behalf.

> 2. Compare using getConstructors instead of getConstrctor.

--Sean

From joehw at openjdk.org  Fri Apr 28 17:22:56 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 28 Apr 2023 17:22:56 GMT
Subject: RFR: 8298087: XML Schema Validation reports an required attribute
 twice via ErrorHandler
Message-ID: <FTLJmbYCPPkZvFFFNZcRZGiDdc6osG9HZ3TRB024XZc=.745f57ce-fd72-4572-9aa0-d78036eb9dfa@github.com>

Fix a copy n paste error in XMLSchemaValidator. When the patch was applied while updating to Xerces 2.12.2, the original code was not removed, resulting in reporting validation error twice.

-------------

Commit messages:
 - 8298087: XML Schema Validation reports an required attribute twice via ErrorHandler

Changes: https://git.openjdk.org/jdk/pull/13722/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13722&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298087
  Stats: 132 lines in 2 files changed: 126 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13722.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13722/head:pull/13722

PR: https://git.openjdk.org/jdk/pull/13722

From lancea at openjdk.org  Fri Apr 28 17:45:23 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 28 Apr 2023 17:45:23 GMT
Subject: RFR: 8307088: Allow the jdbc.drivers system property to be searchable
Message-ID: <LDu-K1BZJ37HVTgDeN85Z_XDy9w2trTgRMy4DYVfb9g=.7f1bccb2-d2a7-4c12-9f26-b25e6977926f@github.com>

Hi all,

Please review this trivial change which allows the` jdbc.drivers` system property to be searchable.

Best.
Lance

-------------

Commit messages:
 - Update copyright year
 - Update copyright year
 - Allow the jdbc.drivers system property to be searchable

Changes: https://git.openjdk.org/jdk/pull/13724/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13724&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307088
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13724.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13724/head:pull/13724

PR: https://git.openjdk.org/jdk/pull/13724

From jlahoda at openjdk.org  Fri Apr 28 18:05:54 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 28 Apr 2023 18:05:54 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v2]
In-Reply-To: <pGrlaRCkvCS6wlF6rxw6y8ewTdTUjv5li0C2LXkcJIY=.68d04589-beb1-480d-830d-f1d19756bfc9@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <osNSUyEj1mUrULK9eKwnO1SQqg1OLygKUKCFfoS_lwc=.f8c3e61b-6200-42f3-80cc-51334e4e7502@github.com>
 <NZ5sMaBOg79-lhBtMm44HjHXVL_WAcedBDNGllRgp3Q=.e934db5b-d6c8-4e44-82f5-a92ff2972c56@github.com>
 <YopNQ7jjAg7Z64IZkD_2as39dBcUj0hHWKB8S17VlDc=.9168990a-2444-4c0a-afac-bc8640742f76@github.com>
 <BOXMmQgrlZClYv2leL5C52nwYTnTZ00oLL-Y87rdC0g=.722edbbc-1160-458d-b621-09af904d9c2c@github.com>
 <pGrlaRCkvCS6wlF6rxw6y8ewTdTUjv5li0C2LXkcJIY=.68d04589-beb1-480d-830d-f1d19756bfc9@github.com>
Message-ID: <MC2sAunf2p48ZuBa50X9YmrRcS-cFnaDJS7dKp2R70Y=.301bedea-ad01-432f-80a0-4195a6b92b2e@github.com>

On Fri, 28 Apr 2023 13:01:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> I see that logic in JavaCompiler - I wonder if that's just the way it is, or if there's a deeper reason as to why the sourcefile is set on the toplevel unit *after* parsing (I don't think I can see any, in which case that might be changed if that makes the rest of the code simpler). @lahodaj what do you think?
>
> I believe we were discussing this some time ago, and there were some problems. I don't recall the exact details, but I'll try to look into this later.

I've sketched this:
https://github.com/lahodaj/jdk/commit/efe55f7d354ed7bbf91077d058823d682db501b9

I don't have too strong opinion here, there might be more cleanup possible after a change like this, and might be a bit cleaner outside of the parser; but forces the parser to work with files which is somewhat less clean.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180673509

From naoto at openjdk.org  Fri Apr 28 18:16:23 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 28 Apr 2023 18:16:23 GMT
Subject: RFR: 8307088: Allow the jdbc.drivers system property to be
 searchable
In-Reply-To: <LDu-K1BZJ37HVTgDeN85Z_XDy9w2trTgRMy4DYVfb9g=.7f1bccb2-d2a7-4c12-9f26-b25e6977926f@github.com>
References: <LDu-K1BZJ37HVTgDeN85Z_XDy9w2trTgRMy4DYVfb9g=.7f1bccb2-d2a7-4c12-9f26-b25e6977926f@github.com>
Message-ID: <AiYcObM6OSxdir92ZSXuEr-cVicqgmhl9ZmIi0EF1Eo=.fbd26b20-1994-4264-9fb6-7d940e929dc0@github.com>

On Fri, 28 Apr 2023 17:28:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial change which allows the` jdbc.drivers` system property to be searchable.
> 
> Best.
> Lance

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13724#pullrequestreview-1406388529

From erikj at openjdk.org  Fri Apr 28 18:26:27 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 28 Apr 2023 18:26:27 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <yk-I2N6h2l7wEgkcHeBAt46OSbDrDxt-P8QgC7pTO_o=.8fa9c1ee-604d-4b97-bcd4-c70355c9564f@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <yk-I2N6h2l7wEgkcHeBAt46OSbDrDxt-P8QgC7pTO_o=.8fa9c1ee-604d-4b97-bcd4-c70355c9564f@github.com>
Message-ID: <eoIorjwEtpPHUF-IYyAToOMQAeQ6HZNvccYvCT0zCwI=.61a939e7-089e-410b-8361-c3eea99969fd@github.com>

On Fri, 28 Apr 2023 11:59:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If I understand the make file changes proposed here, it runs the native linker to create "javastatic" with the launcher, libjvm and other JNI libs linked into one executable, this is generated and copied into the run-time image created by jlink. I think this will need discussion as its more like an overlay. I think it is useful to have the build create the .a files as that's the first step towards putting them into packaged modules for producing static images.

The build is already capable of producing .a files and this patch is building on top of that build feature. The current .a file creation is used by the downstream graal build which needs it for nativeimage.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1527925075

From erikj at openjdk.org  Fri Apr 28 18:26:52 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 28 Apr 2023 18:26:52 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
Message-ID: <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com>

On Fri, 28 Apr 2023 01:03:28 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.
> 
> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.
> 
> To build the statically linked executable:
> 
> 1. Configure the JDK build with --with-static-java=yes
> 2. Build static-java-image, e.g. 'make jdk-image static-java-image'
> 
>  The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.
> 
> Following is a summary of the changes in this PR:
> 
> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.
> 
> - Changes in make/Main.gmk
> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.
> 
> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.
> 
> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.
> 
> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.
> 
> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk.
> 
> - In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well.
> 
> - In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk.
> 
> Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk.

I pulled this PR and had a go at building it. For me it failed with errors like this:

/home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::Linux::fast_thread_clock_init(): error: undefined reference to 'clock_getres'
/home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::Linux::fast_thread_cpu_time(int): error: undefined reference to 'clock_gettime'
/home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::current_thread_cpu_time(): error: undefined reference to 'clock_gettime'
/home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::thread_cpu_time(Thread*): error: undefined reference to 'clock_gettime'
/home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::current_thread_cpu_time(bool): error: undefined reference to 'clock_gettime'
/home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::init_2(): error: undefined reference to 'clock_getres'


I haven't dug any deeper to try to figure this out. Is this something you recognize?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1527926323

From prr at openjdk.org  Fri Apr 28 18:38:23 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Apr 2023 18:38:23 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
Message-ID: <_e_12IxPPJcn-OlnVrDUHekCrPhY7LhMJDtdmIViSjw=.b7b9f5f1-716f-46ab-96d5-ce240ee36c59@github.com>

On Fri, 28 Apr 2023 01:03:28 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.
> 
> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.
> 
> To build the statically linked executable:
> 
> 1. Configure the JDK build with --with-static-java=yes
> 2. Build static-java-image, e.g. 'make jdk-image static-java-image'
> 
>  The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.
> 
> Following is a summary of the changes in this PR:
> 
> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.
> 
> - Changes in make/Main.gmk
> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.
> 
> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.
> 
> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.
> 
> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.
> 
> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk.
> 
> - In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well.
> 
> - In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk.
> 
> Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk.

make/autoconf/lib-freetype.m4 line 118:

> 116:       if test "x${STATIC_JAVA}" = "xtrue"; then
> 117:         AC_MSG_ERROR([--with-freetype=system does not work with --with-static-java=yes])
> 118:       fi

Why not ? Surely you aren't statically linking every library you find on the platform that's referenced by JDK  ?
I mean its fine to say that I'd prefer to statically link this library, but I don't understand the claim that this is the only thing that can work ?

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 229:

> 227:     LIBAWT_XAWT_STATIC_EXCLUDE_OBJS := \
> 228:       debug_assert.o debug_util.o debug_trace.o debug_mem.o systemScale.o
> 229: 

Umm. Does this mean you are linking both headless and xawt into the same image ?
You are on your own with that. Sounds like a mistake to me and I don't want to see any
proposed source code changes to fix up any issues you see later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180701495
PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180704385

From joehw at openjdk.org  Fri Apr 28 18:51:24 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 28 Apr 2023 18:51:24 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v4]
In-Reply-To: <pC4U4hXLT4yWyOrZ3uSxaGBlnEfcBP2uJl1g95SoNkg=.fcdb924f-5639-42ce-bb6d-b636a905e6de@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
 <pC4U4hXLT4yWyOrZ3uSxaGBlnEfcBP2uJl1g95SoNkg=.fcdb924f-5639-42ce-bb6d-b636a905e6de@github.com>
Message-ID: <_E56xvqH_R4JnPX6PyDs1FrPOwDRYpmuWxpJuhtDza4=.b210bfb2-fbec-4cb5-b606-0585076943c1@github.com>

On Thu, 27 Apr 2023 17:35:12 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Test is updated to create the binary files during test execution.
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented the review comments.

Looks ok. Probably note in the relevant data classes the origin of the data (the .ser file generated with the JDK version).

test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

missed the original copyright year, e.g. 2014, 2023,

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13537#pullrequestreview-1406427199
PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1180715378

From duke at openjdk.org  Fri Apr 28 19:00:02 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 28 Apr 2023 19:00:02 GMT
Subject: RFR: 8307088: Allow the jdbc.drivers system property to be
 searchable
In-Reply-To: <LDu-K1BZJ37HVTgDeN85Z_XDy9w2trTgRMy4DYVfb9g=.7f1bccb2-d2a7-4c12-9f26-b25e6977926f@github.com>
References: <LDu-K1BZJ37HVTgDeN85Z_XDy9w2trTgRMy4DYVfb9g=.7f1bccb2-d2a7-4c12-9f26-b25e6977926f@github.com>
Message-ID: <agqTVF_oyglyg0VXDpJUkKyDnS4Q97c-Uh2JVlknmzY=.315e10b2-2d74-4915-b84c-cbf1c818291e@github.com>

On Fri, 28 Apr 2023 17:28:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial change which allows the` jdbc.drivers` system property to be searchable.
> 
> Best.
> Lance

Somewhat unrelated perhaps, but I found the example value given for `jdbc.drivers` in `DriverManager` javadocs to be a bit funky. 

`jdbc.drivers=foo.bah.Driver:wombat.sql.Driver:bad.taste.ourDriver`

I know, I know, coming up with examples is hard, but perhaps we could find something more boring, realistic, package- and database-looking example drivers?

Something like:

`jdbc.drivers=com.company.jdbc.Driver:org.somedb.Driver:org.otherdb.JbdcDriver`

I know this is very subjective, and not really related to the issue. But I thought I'd mention it now that this code is updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13724#issuecomment-1527952909

From jlaskey at openjdk.org  Fri Apr 28 19:04:28 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Apr 2023 19:04:28 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v6]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <kzQZ_YLPMKFDSvzL3PnIgMNPGbNprEh0_fTmHE-GxPU=.c9decdba-99d6-4658-b271-1613c026afc0@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Leave exception alone
 - Unused variables

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/e5ca303a..2c321834

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=04-05

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From jlaskey at openjdk.org  Fri Apr 28 19:04:30 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Apr 2023 19:04:30 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v2]
In-Reply-To: <MC2sAunf2p48ZuBa50X9YmrRcS-cFnaDJS7dKp2R70Y=.301bedea-ad01-432f-80a0-4195a6b92b2e@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <osNSUyEj1mUrULK9eKwnO1SQqg1OLygKUKCFfoS_lwc=.f8c3e61b-6200-42f3-80cc-51334e4e7502@github.com>
 <NZ5sMaBOg79-lhBtMm44HjHXVL_WAcedBDNGllRgp3Q=.e934db5b-d6c8-4e44-82f5-a92ff2972c56@github.com>
 <YopNQ7jjAg7Z64IZkD_2as39dBcUj0hHWKB8S17VlDc=.9168990a-2444-4c0a-afac-bc8640742f76@github.com>
 <BOXMmQgrlZClYv2leL5C52nwYTnTZ00oLL-Y87rdC0g=.722edbbc-1160-458d-b621-09af904d9c2c@github.com>
 <pGrlaRCkvCS6wlF6rxw6y8ewTdTUjv5li0C2LXkcJIY=.68d04589-beb1-480d-830d-f1d19756bfc9@github.com>
 <MC2sAunf2p48ZuBa50X9YmrRcS-cFnaDJS7dKp2R70Y=.301bedea-ad01-432f-80a0-4195a6b92b2e@github.com>
Message-ID: <r26_kY0VW6CT58BR1R_eCGjVg32yVkX94qNzLJIbED8=.3ed166b4-cd4e-4f62-aa0d-d12613afdf83@github.com>

On Fri, 28 Apr 2023 17:51:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> I believe we were discussing this some time ago, and there were some problems. I don't recall the exact details, but I'll try to look into this later.
>
> I've sketched this:
> https://github.com/lahodaj/jdk/commit/efe55f7d354ed7bbf91077d058823d682db501b9
> 
> I don't have too strong opinion here, there might be more cleanup possible after a change like this, and might be a bit cleaner outside of the parser; but forces the parser to work with files which is somewhat less clean.

This is basically what I did originally until I decided that I needed a distinct class name. `log.currentSourceFile()` is the magic in this code. I'm willing to move this way if we all agree.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180715358

From joehw at openjdk.org  Fri Apr 28 19:23:24 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 28 Apr 2023 19:23:24 GMT
Subject: RFR: 8307088: Allow the jdbc.drivers system property to be
 searchable
In-Reply-To: <LDu-K1BZJ37HVTgDeN85Z_XDy9w2trTgRMy4DYVfb9g=.7f1bccb2-d2a7-4c12-9f26-b25e6977926f@github.com>
References: <LDu-K1BZJ37HVTgDeN85Z_XDy9w2trTgRMy4DYVfb9g=.7f1bccb2-d2a7-4c12-9f26-b25e6977926f@github.com>
Message-ID: <kUnL25-0iLJeaUbFSYzZvIYeZEjrniFNMTHUOZR0yWU=.e4225909-da42-4441-b73d-cd82e4277856@github.com>

On Fri, 28 Apr 2023 17:28:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial change which allows the` jdbc.drivers` system property to be searchable.
> 
> Best.
> Lance

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13724#pullrequestreview-1406468156

From lancea at openjdk.org  Fri Apr 28 19:36:58 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 28 Apr 2023 19:36:58 GMT
Subject: RFR: 8307088: Allow the jdbc.drivers system property to be
 searchable
In-Reply-To: <agqTVF_oyglyg0VXDpJUkKyDnS4Q97c-Uh2JVlknmzY=.315e10b2-2d74-4915-b84c-cbf1c818291e@github.com>
References: <LDu-K1BZJ37HVTgDeN85Z_XDy9w2trTgRMy4DYVfb9g=.7f1bccb2-d2a7-4c12-9f26-b25e6977926f@github.com>
 <agqTVF_oyglyg0VXDpJUkKyDnS4Q97c-Uh2JVlknmzY=.315e10b2-2d74-4915-b84c-cbf1c818291e@github.com>
Message-ID: <em7ruQarziDCbkC7Cn2-Oius7mRrWoLsZleZkWOVz5U=.7911993b-7d62-42d7-92b3-2104d2699bc2@github.com>

On Fri, 28 Apr 2023 18:43:01 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Somewhat unrelated perhaps, but I found the example value given for `jdbc.drivers` in `DriverManager` javadocs to be a bit funky.
> 
> `jdbc.drivers=foo.bah.Driver:wombat.sql.Driver:bad.taste.ourDriver`
> 
> I know, I know, coming up with examples is hard, but perhaps we could find something more boring, realistic, package- and database-looking example drivers?
> 
> Something like:
> 
> `jdbc.drivers=com.company.jdbc.Driver:org.somedb.Driver:org.otherdb.JbdcDriver`
> 
> I know this is very subjective, and not really related to the issue. But I thought I'd mention it now that this code is updated.

This dates back to the first release of JDBC in JDK 1.1.  I will add it to my todo list as there is more work to be done in the javadocs, but will leave it as its for now.  Even with when its is updated, wombat.sql.driver will stay to honor Rick Cattell and Graham Hamilton :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13724#issuecomment-1527994558

From erikj at openjdk.org  Fri Apr 28 19:52:54 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 28 Apr 2023 19:52:54 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
Message-ID: <WJrg2ht4gDlj8g3hH8pyGgd5iS7RvVnr26RxZCCm5ds=.d531092e-227e-4e3f-8a5c-834e9b70530e@github.com>

On Fri, 28 Apr 2023 01:03:28 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.
> 
> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.
> 
> To build the statically linked executable:
> 
> 1. Configure the JDK build with --with-static-java=yes
> 2. Build static-java-image, e.g. 'make jdk-image static-java-image'
> 
>  The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.
> 
> Following is a summary of the changes in this PR:
> 
> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.
> 
> - Changes in make/Main.gmk
> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.
> 
> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.
> 
> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.
> 
> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.
> 
> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk.
> 
> - In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well.
> 
> - In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk.
> 
> Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk.

I agree with the other comments here saying that this looks like something that would need a JEP. Especially since this isn't the full feature, but just the first step, and is essentially putting in dead code. It also seems like a higher level discussion about the solution may be needed.

Independent of the above, I have done a brief review of the code as it is.

make/Main.gmk line 1067:

> 1065:   static-libs-image: $(STATIC_LIBS_TARGETS)
> 1066: 
> 1067:   static-java-image: jdk-image hotspot-server-static-libs static-libs-image

You shouldn't need to repeat this. The DEPS parameter to SetupTarget should have handled it.

make/StaticLink.gmk line 83:

> 81:         else
> 82: 	  $(error Not supported on non-linux platform currently)
> 83:         endif

I think it would be rather beneficial if this linking step could be performed by some variant of SetupNativeCompilation. We don't want to have to maintain logic for dealing with different platforms and linkers outside of the common files if it can be helped. SetupNativeCompilation would need to be tweaked to run without SRC and just a set of `.a` files. 

The error about platform support should be handled in configure. We shouldn't be able to get here unless the configuration is expected to be supported.

make/autoconf/static-java.m4 line 31:

> 29: AC_DEFUN_ONCE([STATIC_JAVA_SETUP],
> 30: [
> 31:   AC_ARG_WITH(static-java, [AS_HELP_STRING([--with-static-java],

If this is all the setup for static-java in configure, I don't think it warrants having its own file. I would put this in jdk-options.m4 for now.

make/modules/java.base/lib/CoreLibraries.gmk line 172:

> 170:   # errors due to duplicate symbols.
> 171:   LIBJLI_STATIC_EXCLUDE_OBJS := \
> 172:       inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o

This is the same list as the LIBJLI_EXTRA_FILES above. Would be good to avoid the duplication.

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 228:

> 226:     # static libraries cause linking errors due to duplicate symbols.
> 227:     LIBAWT_XAWT_STATIC_EXCLUDE_OBJS := \
> 228:       debug_assert.o debug_util.o debug_trace.o debug_mem.o systemScale.o

Can this list be derived dynamically in some way? If they are all in the same directory, maybe we could base it on that instead of having to maintain an explicit list?

-------------

PR Review: https://git.openjdk.org/jdk/pull/13709#pullrequestreview-1406410191
PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180697547
PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180755742
PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180747567
PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180750185
PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180751543

From jiangli at openjdk.org  Fri Apr 28 19:52:57 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 28 Apr 2023 19:52:57 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <R5uvOG4uZQy7Licu6iZArbWYnfmjvqRu9QN8JjR-GF0=.62f82b60-e6f2-4af3-ad50-b8f1a861f0ab@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <R5uvOG4uZQy7Licu6iZArbWYnfmjvqRu9QN8JjR-GF0=.62f82b60-e6f2-4af3-ad50-b8f1a861f0ab@github.com>
Message-ID: <tsnkSf4MXYmSpl1aK2WVgXsFMS_VtQvDUzYav4zc-vU=.fddd73ad-f56f-4375-bde3-74536af304dd@github.com>

On Fri, 28 Apr 2023 04:57:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> @jianglizhou I thought this work was proposed to be done under the Project Leyden umbrella? The other static-build tweaks have been fine but this seems to be part of a bigger, yet unspecified, project that may need to be covered by a JEP.

Hi David, indeed the hermetic project was proposed under Project Leyden umbrella. The makefile changes are related to the static linking only, e.g.:

- make the existing static build support more complete for demonstrating static linking capability
- produce a needed libjvm.a 
- producing a testable statically linked launcher binary

That gives us a base for exposing/resolving needed runtime work for supporting static linking fully in JDK. Either covering the makefile work by a JEP or handling it as an incremental change without JEP sounds good. The later might fit the current purpose better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1528007520

From smarks at openjdk.org  Fri Apr 28 20:04:52 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 28 Apr 2023 20:04:52 GMT
Subject: Integrated: 8296935: Arrays.asList() can return a List that throws
 undocumented ArrayStoreException
In-Reply-To: <pgp8ceubOPPxYan0QoWmM4QSByWwlenrFGIvtpF61pc=.1f8f0180-6f0f-4110-9921-7864dd3eecaf@github.com>
References: <pgp8ceubOPPxYan0QoWmM4QSByWwlenrFGIvtpF61pc=.1f8f0180-6f0f-4110-9921-7864dd3eecaf@github.com>
Message-ID: <ElowtwXmFteld38iPa8TgmP4QF7ZiF5sVdhR0UEbmMM=.6a73bf4d-2fc8-406c-9f6b-a70c3b74e40e@github.com>

On Thu, 27 Apr 2023 18:36:53 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> ?

This pull request has now been integrated.

Changeset: da9efee1
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da9efee1c25f76f80fee9065680e7d75d03c7178
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8296935: Arrays.asList() can return a List that throws undocumented ArrayStoreException

Reviewed-by: rriggs, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/13698

From smarks at openjdk.org  Fri Apr 28 21:48:23 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 28 Apr 2023 21:48:23 GMT
Subject: RFR: 8302496: Runtime.exit incorrectly says it never throws an
 exception
In-Reply-To: <PltBScr2EGR3iGXF_PRiMHQozG3PxN-fquthGCaOzyw=.0c80b13d-9ec3-4211-a835-841b90e81353@github.com>
References: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
 <PltBScr2EGR3iGXF_PRiMHQozG3PxN-fquthGCaOzyw=.0c80b13d-9ec3-4211-a835-841b90e81353@github.com>
Message-ID: <cOlhZFldR-Thg7FoIDpIJrIIfX1er_6f02J5B5C-AI8=.01394cb9-52e7-45f7-a811-a0f29731a823@github.com>

On Fri, 28 Apr 2023 04:05:21 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Textual specification clarifications.
>
> src/java.base/share/classes/java/lang/Runtime.java line 143:
> 
>> 141: 
>> 142:     /**
>> 143:      * Initiates the <a href="#shutdown">shutdown sequence</a> of the Java Virtual Machine.
> 
> Suggestion:
> 
>      * Initiates the {@linkplain ##shutdown shutdown sequence} of the Java Virtual Machine.

Good idea. I've updated these and a couple more relating to the shutdown sequence and termination. (There are lots more but in unrelated areas, so I left them for now.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13706#discussion_r1180836375

From smarks at openjdk.org  Fri Apr 28 21:49:54 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 28 Apr 2023 21:49:54 GMT
Subject: RFR: 8302496: Runtime.exit incorrectly says it never throws an
 exception
In-Reply-To: <eVY0HhKjkKGrMMfVlfQLWvmbesi3l9ENunDAjEx9eJ8=.f2b97ad1-5cde-4b68-936f-64250e765a59@github.com>
References: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
 <eVY0HhKjkKGrMMfVlfQLWvmbesi3l9ENunDAjEx9eJ8=.f2b97ad1-5cde-4b68-936f-64250e765a59@github.com>
Message-ID: <v08MOHlrPawxX2WKpwTYQH7aKtYRlNY7DG9zT1JRVR0=.afab9388-7cc5-40b0-aabe-5eee5cfb3ce7@github.com>

On Fri, 28 Apr 2023 06:40:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Textual specification clarifications.
>
> src/java.base/share/classes/java/lang/Runtime.java line 146:
> 
>> 144:      * If a security manager is present and its {@link SecurityManager#checkExit checkExit}
>> 145:      * method disallows exiting with the specified status, throws {@link SecurityException}.
>> 146:      * Otherwise, this method blocks indefinitely; it neither returns nor throws an exception
> 
> The SM is not long for this world.  So I'm in two minds about it making a farewell appearance in the first paragraph of the method description when we know we will have to remove this text very soon.  If we really need to change this now then maybe it could be reduced to "When a security manager is not set, this method never returns ..." so that the distraction of checkExit is not in the first paragraph.

Yeah I had some misgivings mentioning the SM first, but if it's not mentioned, then the assertions in the rest of the text become hedged and uncertain. The SM, checkExit, and whether the exit value is allowed all have to be mentioned somewhere anyway. It would be awkward to try to wedge all of this into a subordinate or parenthetical clause of some other sentence.

Even though we know the SM is on the way out, it's still part of Java SE 21, and it ought to be specified correctly. When the SM is actually removed, we'll have to revisit these specs anyway. Choosing different wording now won't make the future change any easier or harder.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13706#discussion_r1180839803

From mchung at openjdk.org  Fri Apr 28 22:23:23 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 28 Apr 2023 22:23:23 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v10]
In-Reply-To: <OfxL6Odm5c304zI2CefUBX4tR_zO3x2QEl8Vi13l2S8=.2e1ed129-1523-4081-88cb-0781e65f1cdf@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <OfxL6Odm5c304zI2CefUBX4tR_zO3x2QEl8Vi13l2S8=.2e1ed129-1523-4081-88cb-0781e65f1cdf@github.com>
Message-ID: <5M1ExNsFpKZh36xw_s6n-SlBTZKnT2fuHxqBKEeD1HY=.6ff422c4-cad4-47e9-8dcf-6ce2bb7302fe@github.com>

On Fri, 7 Apr 2023 14:35:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with a check to the class data. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 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 generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test that depend on WrapperInstance

I considered more on the membership of the MH proxy class and also about the boot loader being the defining class loader.  I would propose to fully encapsulate the MH proxy class as all other JDK internal classes.  

For each interface I and target MH, define a hidden MH proxy class in a dynamic module (similar to java.lang.reflect.Proxy).  The MH proxy class is fully encapsulated, i.e. its package is not exported and not open.  It has only access to the types in the package of the interface as well as the types referenced by the interface.   The types  accessible by the dynamic module are minimized even if it's defined by the boot loader.

This way, I think we can use the class loader of the given interface to define the hidden class.     The class file is generated once for each interface.  For each invocation of MethodHandleProxies::asInterfaceInstance(I, MH), a hidden class is defined with MH as the class data from the bytes of the generated class file for `I`.  So each dynamic module has one or more hidden classes defined.

This is my patch to implement this change and also include a few comments to your patch (e.g. rename the dumper's property name and also the proxy class should not be a nested class of the interface).
    https://github.com/liachmodded/jdk/compare/explore/mhp-iface...mlchung:mh-proxies

This should add tests to cover the interface in a module that references types in another module.  

I won't be able to review this PR until end of May.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1528138719

From vromero at openjdk.org  Fri Apr 28 22:33:24 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 28 Apr 2023 22:33:24 GMT
Subject: RFR: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names [v3]
In-Reply-To: <ovZuL7DRkKDiciWjLvwKQeU5v7JfqJDSbVqdt4-gfeA=.ae6c5502-5578-42c0-8ffe-b71d0df1ea7a@github.com>
References: <qPi1G8HdwBIoUmQ--9u9wgpHIhNtzrezO8qqzU-KmR8=.c759c5a4-a4c5-4a68-aed3-e65884eab381@github.com>
 <ovZuL7DRkKDiciWjLvwKQeU5v7JfqJDSbVqdt4-gfeA=.ae6c5502-5578-42c0-8ffe-b71d0df1ea7a@github.com>
Message-ID: <_QvepJApGGe7r4pF_JTuz7FkUXTuZwDhBmuHHFh1MZY=.a9037f1b-a2f5-43a7-b35f-d24f14ffba69@github.com>

On Fri, 24 Mar 2023 06:42:30 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> After merging master into https://github.com/openjdk/jdk/pull/9862, we encountered test failures (e.g., https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). The Classfile API tries to read from constant pool index 0 if a MethodParameters attribute has an entry without name.
>> 
>> The fix is simply using `readUtf8EntryOrNull` instead of `readUtf8Entry`. The related code already correctly handles nullability.
>> 
>> I didn't find an appropriate test class so I added a new one. Let me know if there's a better place or if the test can be improved somehow.
>> 
>> As I don't have a JBS account, someone needs to create a bug report there for me. Thanks.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move and fix test comment

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13167#pullrequestreview-1406652944

From jiangli at openjdk.org  Fri Apr 28 22:43:26 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 28 Apr 2023 22:43:26 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com>
Message-ID: <fswwIoriIC-x9zeS5I9FU_fZ74upHRtagKJhjyM8P6E=.2993cede-0fe1-4f1b-859b-c1a9d2cacc4e@github.com>

On Fri, 28 Apr 2023 18:16:07 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I pulled this PR and had a go at building it. For me it failed with errors like this:
> 
> ```
> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::Linux::fast_thread_clock_init(): error: undefined reference to 'clock_getres'
> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::Linux::fast_thread_cpu_time(int): error: undefined reference to 'clock_gettime'
> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::current_thread_cpu_time(): error: undefined reference to 'clock_gettime'
> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::thread_cpu_time(Thread*): error: undefined reference to 'clock_gettime'
> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::current_thread_cpu_time(bool): error: undefined reference to 'clock_gettime'
> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::init_2(): error: undefined reference to 'clock_getres'
> ```
> 
> I haven't dug any deeper to try to figure this out. Is this something you recognize?

Erik, could you please share your `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`? This generated .cmdline file contains the static linking command. Here is the linking command from my build:


/usr/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,--hash-style=gnu -m64 -static-libstdc++ -static-libgcc -Wl,-rpath,$ORIGIN/. -Wl,--export-dynamic -o /.../build/linux-x86_64-server-slowdebug/jdk/bin/javastatic /.../linux-x86_64-server-slowdebug/support/native/java.base/java/main.o  -Wl,--whole-archive /.../linux-x86_64-server-slowdebug/images/static-libs/lib/libattach.a ... /.../linux-x86_64-server-slowdebug/images/static-libs/lib/libjvm.a -Wl,--no-whole-archive -lpthread -ldl -lm -l:libstdc++.a


`clock_getres` and the other related symbols are provided by `libc`. For `libc`, we don't static link with. We still use `libc.so`.


$ ldd jdk/bin/javastatic
	linux-vdso.so.1 (0x00007fff8b17a000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0845321000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0845140000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f084888d000)



$ objdump -Tw /lib/x86_64-linux-gnu/libc.so.6 | grep clock_getres
00000000000cf260 g    DF .text	0000000000000069  GLIBC_2.17  clock_getres
00000000000cf260 g    DF .text	0000000000000069 (GLIBC_2.2.5) clock_getres

$ nm jdk/bin/javastatic | grep clock_gettime
                 U clock_gettime at GLIBC_2.17
$ nm jdk/bin/javastatic | grep clock_getres
                 U clock_getres at GLIBC_2.17

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1528158982

From erikj at openjdk.org  Fri Apr 28 23:40:52 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 28 Apr 2023 23:40:52 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <fswwIoriIC-x9zeS5I9FU_fZ74upHRtagKJhjyM8P6E=.2993cede-0fe1-4f1b-859b-c1a9d2cacc4e@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com>
 <fswwIoriIC-x9zeS5I9FU_fZ74upHRtagKJhjyM8P6E=.2993cede-0fe1-4f1b-859b-c1a9d2cacc4e@github.com>
Message-ID: <qoIFJlMJYKqo5Mrd_NONJ-lwV3pENmRrSJ0cmzzEDEw=.2e5141ab-0f4d-40ca-b35c-f207df87e533@github.com>

On Fri, 28 Apr 2023 22:32:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Erik, could you please share your `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`? This generated .cmdline file contains the static linking command. Here is the linking command from my build:

I can't see any significant difference. I'm using a devkit created using the devkit makefiles. 


.../devkit-linux_x64-gcc11.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,--hash-style=gnu -m64 -static-libstdc++ -static-libgcc -Wl,-rpath,$ORIGIN/. -Wl,--export-dynamic -o .../build/linux-x64/jdk/bin/javastatic /home/erik/git/jdk/build/linux-x64/support/native/java.base/java/main.o -Wl,--whole-archive .../build/linux-x64/images/static-libs/lib/libattach.a ... .../build/linux-x64/images/static-libs/lib/libjvm.a -Wl,--no-whole-archive -lpthread -ldl -lm -l:libstdc++.a

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1528188361

From jiangli at openjdk.org  Sat Apr 29 00:11:53 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 29 Apr 2023 00:11:53 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <eoIorjwEtpPHUF-IYyAToOMQAeQ6HZNvccYvCT0zCwI=.61a939e7-089e-410b-8361-c3eea99969fd@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <yk-I2N6h2l7wEgkcHeBAt46OSbDrDxt-P8QgC7pTO_o=.8fa9c1ee-604d-4b97-bcd4-c70355c9564f@github.com>
 <eoIorjwEtpPHUF-IYyAToOMQAeQ6HZNvccYvCT0zCwI=.61a939e7-089e-410b-8361-c3eea99969fd@github.com>
Message-ID: <rKa31Zl0W-a6fsxlwlH7bDuzAxNkQ1J7NMVY2y9jVmU=.7fc5de16-b500-47ed-93d0-6553181538be@github.com>

On Fri, 28 Apr 2023 18:14:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> 
> If I understand the make file changes proposed here, it runs the native linker to create "javastatic" with the launcher, libjvm and other JNI libs linked into one executable, this is generated and copied into the run-time image created by jlink.

For the testing/demo purpose (on static linking part) with this PR, the makefile changes in the PR only run the native linker step to perform static linking. The 'javastatic' is simply copied into the (regular) jlink'ed JDK image 'bin/' directory.  In our experiments/prototyping work, the 'javastatic' launcher binary is used along with the other artifacts from the regular JDK image (e.g. lib/modules)  for basic sanitary testing (running some of the jtreg tier 1 tests). The 'javastatic' is not used for creating the hermetic Java image. The post process building the hermetic image takes the .a files, lib/modules and other resources files as input.

>  I think this will need discussion as its more like an overlay. I think it is useful to have the build create the .a files as that's the first step towards putting them into packaged modules for producing static images.

Agreed. 

Based the initial feedback from you and other reviewers in the thread, I'll repurpose this PR for handling the .a part only. I'll split the 'javastatic' static linking part into a separate branch for needed discussions (including the potential JEP part). That branch can be on the sideline and it can be to verify/test the other static linking related changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1528259605

From naoto at openjdk.org  Sat Apr 29 00:22:22 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 29 Apr 2023 00:22:22 GMT
Subject: RFR: 8298087: XML Schema Validation reports an required attribute
 twice via ErrorHandler
In-Reply-To: <FTLJmbYCPPkZvFFFNZcRZGiDdc6osG9HZ3TRB024XZc=.745f57ce-fd72-4572-9aa0-d78036eb9dfa@github.com>
References: <FTLJmbYCPPkZvFFFNZcRZGiDdc6osG9HZ3TRB024XZc=.745f57ce-fd72-4572-9aa0-d78036eb9dfa@github.com>
Message-ID: <_vkgPtANWar4HztPCNGT7BLopct9SqYIptL2kSnNq7U=.840ad44c-c65f-4ad9-8e6f-2c5a2a2c566e@github.com>

On Fri, 28 Apr 2023 17:08:10 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix a copy n paste error in XMLSchemaValidator. When the patch was applied while updating to Xerces 2.12.2, the original code was not removed, resulting in reporting validation error twice.

test/jaxp/javax/xml/jaxp/unittest/validation/ErrorHandlingTest.java line 86:

> 84:     @Test
> 85:     public void test() throws Exception {
> 86:         Locale.setDefault(ENGLISH);

I believe this test is run in `othervm` mode, but still, it would be preferred to restore the default locale after the test

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13722#discussion_r1180889595

From jiangli at openjdk.org  Sat Apr 29 00:33:54 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 29 Apr 2023 00:33:54 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <rKa31Zl0W-a6fsxlwlH7bDuzAxNkQ1J7NMVY2y9jVmU=.7fc5de16-b500-47ed-93d0-6553181538be@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <yk-I2N6h2l7wEgkcHeBAt46OSbDrDxt-P8QgC7pTO_o=.8fa9c1ee-604d-4b97-bcd4-c70355c9564f@github.com>
 <eoIorjwEtpPHUF-IYyAToOMQAeQ6HZNvccYvCT0zCwI=.61a939e7-089e-410b-8361-c3eea99969fd@github.com>
 <rKa31Zl0W-a6fsxlwlH7bDuzAxNkQ1J7NMVY2y9jVmU=.7fc5de16-b500-47ed-93d0-6553181538be@github.com>
Message-ID: <LZQ9wEi-kFNfiRkJv-mY2NWm5x0rMJc54Z-o-mmb1MA=.198067e3-d9a3-449b-a748-70e49fa0962c@github.com>

On Sat, 29 Apr 2023 00:03:24 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Based the initial feedback from you and other reviewers in the thread, I'll repurpose this PR for handling the .a part only. I'll split the 'javastatic' static linking part into a separate branch for needed discussions (including the potential JEP part). That branch can be on the sideline and it can be to verify/test the other static linking related changes.

On the second thought, it might be cleaner to withdraw the current PR first and extract the .a part into a new PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1528275134

From jiangli at openjdk.org  Sat Apr 29 00:35:23 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 29 Apr 2023 00:35:23 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <WJrg2ht4gDlj8g3hH8pyGgd5iS7RvVnr26RxZCCm5ds=.d531092e-227e-4e3f-8a5c-834e9b70530e@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <WJrg2ht4gDlj8g3hH8pyGgd5iS7RvVnr26RxZCCm5ds=.d531092e-227e-4e3f-8a5c-834e9b70530e@github.com>
Message-ID: <QROzLHb4osGh3Fi8wM74Yb1QfFIN-kV9KxYNHKXWI6c=.b39c7440-fd05-4a9b-966b-a6884533b969@github.com>

On Fri, 28 Apr 2023 19:40:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I think it would be rather beneficial if this linking step could be performed by some variant of SetupNativeCompilation. We don't want to have to maintain logic for dealing with different platforms and linkers outside of the common files if it can be helped. SetupNativeCompilation would need to be tweaked to run without SRC and just a set of .a files.
>
> The error about platform support should be handled in configure. We shouldn't be able to get here unless the configuration is expected to be supported.

All sounds good, thanks. I plan to withdraw this PR and extract the .a handling part into a new PR for now (as mentioned in response to @AlanBateman's comments). For the linking part, it would be good to have your close/direct involvement and collaboration in branch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180891458

From jiangli at openjdk.org  Sat Apr 29 00:57:23 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 29 Apr 2023 00:57:23 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <_e_12IxPPJcn-OlnVrDUHekCrPhY7LhMJDtdmIViSjw=.b7b9f5f1-716f-46ab-96d5-ce240ee36c59@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <_e_12IxPPJcn-OlnVrDUHekCrPhY7LhMJDtdmIViSjw=.b7b9f5f1-716f-46ab-96d5-ce240ee36c59@github.com>
Message-ID: <CWhHDSitCkW1LIYi4ymEeje3IlScDJy_ym5gN7cgF8M=.f89c75d3-a80d-4317-9fa3-8768f64d00aa@github.com>

On Fri, 28 Apr 2023 18:25:14 GMT, Phil Race <prr at openjdk.org> wrote:

> Why not ? Surely you aren't statically linking every library you find on the platform that's referenced by JDK ?
> I mean its fine to say that I'd prefer to statically link this library, but I don't understand the claim that this is the only thing that can work ?

It's for providing libzip.a and libfreetype.a as part of the JDK 'static-libs' image. In our usages, I've learned that static linking is preferred whenever possible. We don't statically link libc.

Mine main reasoning/motivation for building and including the libzip.a and libfreetype.a in JDK 'static-libs' image is for ease of use. It reduces complications during the post hermetic image build process, if those libraries are need.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180895872

From jiangli at openjdk.org  Sat Apr 29 01:29:53 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 29 Apr 2023 01:29:53 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <_e_12IxPPJcn-OlnVrDUHekCrPhY7LhMJDtdmIViSjw=.b7b9f5f1-716f-46ab-96d5-ce240ee36c59@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <_e_12IxPPJcn-OlnVrDUHekCrPhY7LhMJDtdmIViSjw=.b7b9f5f1-716f-46ab-96d5-ce240ee36c59@github.com>
Message-ID: <10RC9v_ITMbLATGX8LJhg3WRQwZ-JNkxRCEuryBR1zM=.594db8fe-7264-4f84-b50f-3b09e4c3b6af@github.com>

On Fri, 28 Apr 2023 18:28:51 GMT, Phil Race <prr at openjdk.org> wrote:

> Umm. Does this mean you are linking both headless and xawt into the same image ?

For the xawt case, we statically link with libawt.a and libawt_xawt.a in our early prototype. For headless case, we statically link with libawt.a and libawt_headless.a. We have been focusing on testing with the headless usages.

The libawt provides `AWT_OnLoad`, which handles the 'loading' of libawt_xawt or libawt_headless. By filtering out the duplicate .o files in the static linking case, it can work without larger refactoring the sources in the those libraries.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180900245

From joehw at openjdk.org  Sat Apr 29 01:32:23 2023
From: joehw at openjdk.org (Joe Wang)
Date: Sat, 29 Apr 2023 01:32:23 GMT
Subject: RFR: 8298087: XML Schema Validation reports an required attribute
 twice via ErrorHandler [v2]
In-Reply-To: <FTLJmbYCPPkZvFFFNZcRZGiDdc6osG9HZ3TRB024XZc=.745f57ce-fd72-4572-9aa0-d78036eb9dfa@github.com>
References: <FTLJmbYCPPkZvFFFNZcRZGiDdc6osG9HZ3TRB024XZc=.745f57ce-fd72-4572-9aa0-d78036eb9dfa@github.com>
Message-ID: <Jhzib_IGDFmp8vo_qyCCQuGsabPnROYa8_Nfff9LulA=.eba8df2e-124e-4640-971c-2f9c7bab7e74@github.com>

> Fix a copy n paste error in XMLSchemaValidator. When the patch was applied while updating to Xerces 2.12.2, the original code was not removed, resulting in reporting validation error twice.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  removing the line that changed locale. It's not necessary as the concern was the number of errors reported

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13722/files
  - new: https://git.openjdk.org/jdk/pull/13722/files/7c4ba795..71609b1f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13722&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13722&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13722.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13722/head:pull/13722

PR: https://git.openjdk.org/jdk/pull/13722

From joehw at openjdk.org  Sat Apr 29 01:34:52 2023
From: joehw at openjdk.org (Joe Wang)
Date: Sat, 29 Apr 2023 01:34:52 GMT
Subject: RFR: 8298087: XML Schema Validation reports an required attribute
 twice via ErrorHandler [v2]
In-Reply-To: <_vkgPtANWar4HztPCNGT7BLopct9SqYIptL2kSnNq7U=.840ad44c-c65f-4ad9-8e6f-2c5a2a2c566e@github.com>
References: <FTLJmbYCPPkZvFFFNZcRZGiDdc6osG9HZ3TRB024XZc=.745f57ce-fd72-4572-9aa0-d78036eb9dfa@github.com>
 <_vkgPtANWar4HztPCNGT7BLopct9SqYIptL2kSnNq7U=.840ad44c-c65f-4ad9-8e6f-2c5a2a2c566e@github.com>
Message-ID: <cCHJxYVWB1akP7LWL7zkHgT7fm8d6_3lUBv6-Y5cpjM=.e48f1390-546d-4eb9-98ac-1ef86f25aa8d@github.com>

On Sat, 29 Apr 2023 00:09:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removing the line that changed locale. It's not necessary as the concern was the number of errors reported
>
> test/jaxp/javax/xml/jaxp/unittest/validation/ErrorHandlingTest.java line 86:
> 
>> 84:     @Test
>> 85:     public void test() throws Exception {
>> 86:         Locale.setDefault(ENGLISH);
> 
> I believe this test is run in `othervm` mode, but still, it would be preferred to restore the default locale after the test

Thanks!  The line is removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13722#discussion_r1180900119

From jiangli at openjdk.org  Sat Apr 29 02:01:24 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 29 Apr 2023 02:01:24 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <qoIFJlMJYKqo5Mrd_NONJ-lwV3pENmRrSJ0cmzzEDEw=.2e5141ab-0f4d-40ca-b35c-f207df87e533@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com>
 <fswwIoriIC-x9zeS5I9FU_fZ74upHRtagKJhjyM8P6E=.2993cede-0fe1-4f1b-859b-c1a9d2cacc4e@github.com>
 <qoIFJlMJYKqo5Mrd_NONJ-lwV3pENmRrSJ0cmzzEDEw=.2e5141ab-0f4d-40ca-b35c-f207df87e533@github.com>
Message-ID: <cHoSfMjHAHP6ju9S-RDkATMulY5tDBBvyWNM8T6LTfg=.8f01ce5a-97d3-4d41-adcb-0cf342786fe0@github.com>

On Fri, 28 Apr 2023 23:25:17 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > Erik, could you please share your `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`? This generated .cmdline file contains the static linking command. Here is the linking command from my build:
> 
> I can't see any significant difference. I'm using a devkit created using the devkit makefiles.
> 
> ```
> .../devkit-linux_x64-gcc11.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,--hash-style=gnu -m64 -static-libstdc++ -static-libgcc -Wl,-rpath,$ORIGIN/. -Wl,--export-dynamic -o .../build/linux-x64/jdk/bin/javastatic /home/erik/git/jdk/build/linux-x64/support/native/java.base/java/main.o -Wl,--whole-archive .../build/linux-x64/images/static-libs/lib/libattach.a ... .../build/linux-x64/images/static-libs/lib/libjvm.a -Wl,--no-whole-archive -lpthread -ldl -lm -l:libstdc++.a
> ```

I did some search and found https://stackoverflow.com/questions/2418157/c-error-undefined-reference-to-clock-gettime-and-clock-settime/32649327#32649327. The clock_* functions moved from librt to libc (starting from glibc 2.17). That finding led me to the following in libraries.m4:


  # librt for legacy clock_gettime
  if test "x$OPENJDK_TARGET_OS" = xlinux; then
    # Hotspot needs to link librt to get the clock_* functions.
    # But once our supported minimum build and runtime platform
    # has glibc 2.17, this can be removed as the functions are
    # in libc.
    BASIC_JVM_LIBS="$BASIC_JVM_LIBS -lrt"
  fi


Since I use `ldd (Debian GLIBC 2.36-8+gl1) 2.36`, I didn't notice that until now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1528445381

From jiangli at openjdk.org  Sat Apr 29 03:57:53 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 29 Apr 2023 03:57:53 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
 [v2]
In-Reply-To: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
Message-ID: <VwR0TLPzfG4luNZFUlvEzvlmMxgUEhp2rHnqvv2ad0A=.a617fcd6-4cc9-4c7c-9f2d-389ea05a62b3@github.com>

> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.
> 
> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.
> 
> To build the statically linked executable:
> 
> 1. Configure the JDK build with --with-static-java=yes
> 2. Build static-java-image, e.g. 'make jdk-image static-java-image'
> 
>  The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.
> 
> Following is a summary of the changes in this PR:
> 
> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.
> 
> - Changes in make/Main.gmk
> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.
> 
> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.
> 
> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.
> 
> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.
> 
> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk.
> 
> - In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well.
> 
> - In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk.
> 
> Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Use $(JVM_LIBS), which includes -lrt on Linux currently.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13709/files
  - new: https://git.openjdk.org/jdk/pull/13709/files/85523095..4728b380

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13709&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13709&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13709.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13709/head:pull/13709

PR: https://git.openjdk.org/jdk/pull/13709

From jiangli at openjdk.org  Sat Apr 29 04:03:58 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 29 Apr 2023 04:03:58 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <cHoSfMjHAHP6ju9S-RDkATMulY5tDBBvyWNM8T6LTfg=.8f01ce5a-97d3-4d41-adcb-0cf342786fe0@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com>
 <fswwIoriIC-x9zeS5I9FU_fZ74upHRtagKJhjyM8P6E=.2993cede-0fe1-4f1b-859b-c1a9d2cacc4e@github.com>
 <qoIFJlMJYKqo5Mrd_NONJ-lwV3pENmRrSJ0cmzzEDEw=.2e5141ab-0f4d-40ca-b35c-f207df87e533@github.com>
 <cHoSfMjHAHP6ju9S-RDkATMulY5tDBBvyWNM8T6LTfg=.8f01ce5a-97d3-4d41-adcb-0cf342786fe0@github.com>
Message-ID: <I-RZnBJsuozJqepXHanQGaGCD5pVcSxq82INwW9-jYo=.02742fc4-fd96-4d00-b766-b9c0f5dff6ec@github.com>

On Sat, 29 Apr 2023 01:44:07 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > > Erik, could you please share your `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`? This generated .cmdline file contains the static linking command. Here is the linking command from my build:
> > 
> > 
> > I can't see any significant difference. I'm using a devkit created using the devkit makefiles.
> > ```
> > .../devkit-linux_x64-gcc11.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,--hash-style=gnu -m64 -static-libstdc++ -static-libgcc -Wl,-rpath,$ORIGIN/. -Wl,--export-dynamic -o .../build/linux-x64/jdk/bin/javastatic /home/erik/git/jdk/build/linux-x64/support/native/java.base/java/main.o -Wl,--whole-archive .../build/linux-x64/images/static-libs/lib/libattach.a ... .../build/linux-x64/images/static-libs/lib/libjvm.a -Wl,--no-whole-archive -lpthread -ldl -lm -l:libstdc++.a
> > ```
> 
> I did some search and found https://stackoverflow.com/questions/2418157/c-error-undefined-reference-to-clock-gettime-and-clock-settime/32649327#32649327. The clock_* functions moved from librt to libc (starting from glibc 2.17). That finding led me to the following in libraries.m4:
> 
> ```
>   # librt for legacy clock_gettime
>   if test "x$OPENJDK_TARGET_OS" = xlinux; then
>     # Hotspot needs to link librt to get the clock_* functions.
>     # But once our supported minimum build and runtime platform
>     # has glibc 2.17, this can be removed as the functions are
>     # in libc.
>     BASIC_JVM_LIBS="$BASIC_JVM_LIBS -lrt"
>   fi
> ```
> 
> Since I use `ldd (Debian GLIBC 2.36-8+gl1) 2.36`, I didn't notice that until now.

Based on the above finding, I pushed a change to use $(JVM_LIBS) for the linking command. @erikj79 could you please see if that resolves the clock_* symbol issues in your environment?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1528637453

From duke at openjdk.org  Sat Apr 29 04:56:24 2023
From: duke at openjdk.org (Hannes Greule)
Date: Sat, 29 Apr 2023 04:56:24 GMT
Subject: RFR: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names [v3]
In-Reply-To: <_QvepJApGGe7r4pF_JTuz7FkUXTuZwDhBmuHHFh1MZY=.a9037f1b-a2f5-43a7-b35f-d24f14ffba69@github.com>
References: <qPi1G8HdwBIoUmQ--9u9wgpHIhNtzrezO8qqzU-KmR8=.c759c5a4-a4c5-4a68-aed3-e65884eab381@github.com>
 <ovZuL7DRkKDiciWjLvwKQeU5v7JfqJDSbVqdt4-gfeA=.ae6c5502-5578-42c0-8ffe-b71d0df1ea7a@github.com>
 <_QvepJApGGe7r4pF_JTuz7FkUXTuZwDhBmuHHFh1MZY=.a9037f1b-a2f5-43a7-b35f-d24f14ffba69@github.com>
Message-ID: <i1pHECKQ3Wzs72_cDvj-aEfYlkjxdElkgQcVrj9Ksdg=.c3aa2636-43bd-4efb-8b9f-ff8d8d7db6fa@github.com>

On Fri, 28 Apr 2023 22:16:09 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move and fix test comment
>
> looks good

Thank you for your review, @vicente-romero-oracle.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13167#issuecomment-1528649509

From jwaters at openjdk.org  Sat Apr 29 08:05:54 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 29 Apr 2023 08:05:54 GMT
Subject: RFR: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names [v3]
In-Reply-To: <ovZuL7DRkKDiciWjLvwKQeU5v7JfqJDSbVqdt4-gfeA=.ae6c5502-5578-42c0-8ffe-b71d0df1ea7a@github.com>
References: <qPi1G8HdwBIoUmQ--9u9wgpHIhNtzrezO8qqzU-KmR8=.c759c5a4-a4c5-4a68-aed3-e65884eab381@github.com>
 <ovZuL7DRkKDiciWjLvwKQeU5v7JfqJDSbVqdt4-gfeA=.ae6c5502-5578-42c0-8ffe-b71d0df1ea7a@github.com>
Message-ID: <7cV5DD9lmC4a7kIVjM14dXz-yHJJAVpcji8OQ9whC1g=.e82898fe-f5c5-4f8c-a842-fb974821ee64@github.com>

On Fri, 24 Mar 2023 06:42:30 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> After merging master into https://github.com/openjdk/jdk/pull/9862, we encountered test failures (e.g., https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). The Classfile API tries to read from constant pool index 0 if a MethodParameters attribute has an entry without name.
>> 
>> The fix is simply using `readUtf8EntryOrNull` instead of `readUtf8Entry`. The related code already correctly handles nullability.
>> 
>> I didn't find an appropriate test class so I added a new one. Let me know if there's a better place or if the test can be improved somehow.
>> 
>> As I don't have a JBS account, someone needs to create a bug report there for me. Thanks.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move and fix test comment

Nice! :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13167#issuecomment-1528706162

From duke at openjdk.org  Sat Apr 29 08:05:56 2023
From: duke at openjdk.org (Hannes Greule)
Date: Sat, 29 Apr 2023 08:05:56 GMT
Subject: Integrated: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names
In-Reply-To: <qPi1G8HdwBIoUmQ--9u9wgpHIhNtzrezO8qqzU-KmR8=.c759c5a4-a4c5-4a68-aed3-e65884eab381@github.com>
References: <qPi1G8HdwBIoUmQ--9u9wgpHIhNtzrezO8qqzU-KmR8=.c759c5a4-a4c5-4a68-aed3-e65884eab381@github.com>
Message-ID: <S3Q4K6EcAXF8bn9ml5d3kxklWABjCg1UOMGM3q2QyKs=.347fa745-522a-4ba6-8682-9d1aa3605587@github.com>

On Thu, 23 Mar 2023 19:45:21 GMT, Hannes Greule <duke at openjdk.org> wrote:

> After merging master into https://github.com/openjdk/jdk/pull/9862, we encountered test failures (e.g., https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). The Classfile API tries to read from constant pool index 0 if a MethodParameters attribute has an entry without name.
> 
> The fix is simply using `readUtf8EntryOrNull` instead of `readUtf8Entry`. The related code already correctly handles nullability.
> 
> I didn't find an appropriate test class so I added a new one. Let me know if there's a better place or if the test can be improved somehow.
> 
> As I don't have a JBS account, someone needs to create a bug report there for me. Thanks.

This pull request has now been integrated.

Changeset: a2d3fc83
Author:    SirYwell <hannesgreule at outlook.de>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a2d3fc83b0dd7eea38e1dd5898a97d6d7ff60194
Stats:     73 lines in 2 files changed: 71 ins; 0 del; 2 mod

8304837: Classfile API throws IOOBE for MethodParameters attribute without parameter names

Reviewed-by: asotona, jwaters, vromero

-------------

PR: https://git.openjdk.org/jdk/pull/13167

From forax at univ-mlv.fr  Sat Apr 29 10:46:21 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 29 Apr 2023 12:46:21 +0200 (CEST)
Subject: The introduction of Sequenced collections is not a source
 compatible change
Message-ID: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>

I've several repositories that now fails to compile with the latest jdk21, which introduces sequence collections.

The introduction of a common supertype to existing collections is *not* a source compatible change because of type inference.

Here is a simplified example:

  public static void m(List<Supplier<? extends Map<String, String>>> factories) {
  }

  public static void main(String[] args) {
    Supplier<LinkedHashMap<String,String>> supplier1 = LinkedHashMap::new;
    Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
    var factories = List.of(supplier1, supplier2);
    m(factories);
  }


This example compiles fine with Java 20 but report an error with Java 21:
  SequencedCollectionBug.java:28: error: method m in class SequencedCollectionBug cannot be applied to given types;
    m(factories);
    ^
  required: List<Supplier<? extends Map<String,String>>>
  found:    List<Supplier<? extends SequencedMap<String,String>>>
  reason: argument mismatch; List<Supplier<? extends SequencedMap<String,String>>> cannot be converted to List<Supplier<? extends Map<String,String>>>



Apart from the example above, most of the failures I see are in the unit tests provided to the students, because we are using a lot of 'var' in them so they work whatever the name of the types chosen by the students. 

Discussing with a colleague, we also believe that this bug is not limited to Java, existing Kotlin codes will also fail to compile due to this bug.

Regards,
R?mi

From lancea at openjdk.org  Sat Apr 29 14:55:26 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 29 Apr 2023 14:55:26 GMT
Subject: Integrated: 8307088: Allow the jdbc.drivers system property to be
 searchable
In-Reply-To: <LDu-K1BZJ37HVTgDeN85Z_XDy9w2trTgRMy4DYVfb9g=.7f1bccb2-d2a7-4c12-9f26-b25e6977926f@github.com>
References: <LDu-K1BZJ37HVTgDeN85Z_XDy9w2trTgRMy4DYVfb9g=.7f1bccb2-d2a7-4c12-9f26-b25e6977926f@github.com>
Message-ID: <Pn1_66WBQoP21u-2KdArhkZ5OS8_nh3OvK6mWxcAtXE=.ab638a6a-cbe8-4b81-92a9-53af1d6f901f@github.com>

On Fri, 28 Apr 2023 17:28:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial change which allows the` jdbc.drivers` system property to be searchable.
> 
> Best.
> Lance

This pull request has now been integrated.

Changeset: bb7608ba
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb7608bacc605b2aa9a291f4e23dab49815ce932
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8307088: Allow the jdbc.drivers system property to be searchable

Reviewed-by: naoto, joehw

-------------

PR: https://git.openjdk.org/jdk/pull/13724

From lancea at openjdk.org  Sat Apr 29 16:32:22 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 29 Apr 2023 16:32:22 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v4]
In-Reply-To: <pC4U4hXLT4yWyOrZ3uSxaGBlnEfcBP2uJl1g95SoNkg=.fcdb924f-5639-42ce-bb6d-b636a905e6de@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
 <pC4U4hXLT4yWyOrZ3uSxaGBlnEfcBP2uJl1g95SoNkg=.fcdb924f-5639-42ce-bb6d-b636a905e6de@github.com>
Message-ID: <jjAm97rPEHzRGIeP7e3HVt8N6AzWu4Z39mofx3UPMO4=.dbb2f64b-a035-460f-a2cb-acd0ae97de13@github.com>

On Thu, 27 Apr 2023 17:35:12 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Test is updated to create the binary files during test execution.
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented the review comments.

test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 85:

> 83: 
> 84:         // Generates the Java Pseudo code for base64 encoded string that can be cut & pasted into the test
> 85:         final StringBuilder sb = new StringBuilder();

Can you please explain the purpose of the following code in the `setup` method?.  This appears to be what you used to generate the _JDK**X**GregorianCalendarAndDurationSerData.java_ files.  I don't see why this would be needed in a setup method. 

Providing a method, along with comments of how to use it, to create byte arrays make sense, just not in a setup method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1181098153

From duke at openjdk.org  Sat Apr 29 18:38:52 2023
From: duke at openjdk.org (iaroslavski)
Date: Sat, 29 Apr 2023 18:38:52 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v6]
In-Reply-To: <aeZ8z-znPXfQBL0ptEcSDMpuADDtpPBxCbKRaaaMWnE=.da492fc8-39ac-43f7-8ee3-f9f002334837@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <aeZ8z-znPXfQBL0ptEcSDMpuADDtpPBxCbKRaaaMWnE=.da492fc8-39ac-43f7-8ee3-f9f002334837@github.com>
Message-ID: <w8nJBkZnoQryVz4WvC5HfZGpbbHF1lusw1-zh79j7n4=.8a699113-cc95-46fd-94d2-cc2123ff3626@github.com>

On Sun, 23 Apr 2023 17:33:38 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> * Optimized mixed insertion sort
>>     * Optimized insertion sort
>>     * Optimized Radix sort
>>     * Updated microbenchmark
>> 
>> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938
>
> Laurent Bourg?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into dpqs23
>  - fixed javadoc and size renamed to length for clarity
>  - improved and more obvious max length test to always respect max heap memory footprint
>  - Merge branch 'openjdk:master' into dpqs23
>  - rewritten radix sort condition + fixed max buffer size
>  - optimized radix sort heuristic
>  - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>        * Optimized mixed insertion sort
>        * Optimized insertion sort
>        * Optimized Radix sort
>        * Updated microbenchmark

The changes look fine for me, approve this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1528845135

From jlaskey at openjdk.org  Sun Apr 30 00:59:58 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Sun, 30 Apr 2023 00:59:58 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v7]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <YLHUj7YZPcl37Ymn44IX2wGiTe7lDbnyWgNcTOHc9Lc=.93004ba7-3a8e-4d24-a420-c43dc3be179a@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Move AnonymousMainClass to parser
 - Revert java launch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/2c321834..a09a0a1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=05-06

  Stats: 231 lines in 4 files changed: 111 ins; 108 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From liach at openjdk.org  Sun Apr 30 06:38:24 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 30 Apr 2023 06:38:24 GMT
Subject: RFR: 8156916: intrinsify MethodHandles.arrayConstructor()
Message-ID: <Y3vQNof2nwMwjM2w7G15h3oMf745ceWqQcIXHW0Jgi0=.0b50ab3f-9629-40ca-8a6b-d90def8d3e24@github.com>

Try to intrinsify MethodHandles.arrayConstructor for java.lang, java.lang.invoke, and java.util types, which InvokerBytecodeGenerator can refer to directly in a class constant.

In fact, the performance difference of Array.newInstance and anewarray is quite negligible per benchmark:

Benchmark                                                            Mode  Cnt     Score     Error  Units
MethodHandlesArrayConstructorCall.baselineConstruct                  avgt    5     3.467 ?   0.163  ns/op
MethodHandlesArrayConstructorCall.constantFoldConstruct              avgt    5     3.403 ?   0.070  ns/op
MethodHandlesArrayConstructorCall.constantFoldNonInvocableConstruct  avgt    5     3.445 ?   0.231  ns/op
MethodHandlesArrayConstructorCall.instanceConstruct                  avgt    5     4.034 ?   0.168  ns/op
MethodHandlesArrayConstructorCall.instanceNonInvocableConstruct      avgt    5     4.038 ?   0.104  ns/op
MethodHandlesArrayConstructorColdStart.testCreateInvocable             ss   10  1425.991 ? 308.216  us/op
MethodHandlesArrayConstructorColdStart.testCreateNonInvocable          ss   10  1401.480 ? 258.402  us/op
MethodHandlesArrayConstructorColdStart.testCreateObject                ss   10  1213.018 ? 166.522  us/op
MethodHandlesArrayConstructorColdStart.testCreatePrimitive             ss   10  1163.461 ? 178.549  us/op

-------------

Commit messages:
 - message
 - fix wrong types
 - micro problems
 - Add partial intrinsic for array constructors

Changes: https://git.openjdk.org/jdk/pull/13735/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13735&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8156916
  Stats: 241 lines in 6 files changed: 221 ins; 5 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13735.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13735/head:pull/13735

PR: https://git.openjdk.org/jdk/pull/13735

From alanb at openjdk.org  Sun Apr 30 07:58:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 30 Apr 2023 07:58:22 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v9]
In-Reply-To: <w_VQMDXdJScfmyacC0Mxsq4ZshVvw8vLNEcw62YbH1I=.4296584d-da35-4b67-8914-ac26aeef1873@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <w_VQMDXdJScfmyacC0Mxsq4ZshVvw8vLNEcw62YbH1I=.4296584d-da35-4b67-8914-ac26aeef1873@github.com>
Message-ID: <tii6-GGgEZTZiTOmh83uN4qrUaK1WXvmJJTfxD5oHvA=.e3048ff2-e0e6-4f3f-b1fd-8533ce5264ab@github.com>

On Fri, 28 Apr 2023 05:47:24 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
>> 
>> CSR: https://bugs.openjdk.org/browse/JDK-8303531
>> 
>> Tests: XML SQE and JCK tests passed.
>
> Joe Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8303530
>  - Update based on the review meeting on 4/5. Added (duplicated) definitions in jaxp.properties; Rewrote Property Precedence with samples; Other updates.
>  - update javadoc as discussed in the review meeting; add a sample configuration file jaxp.properties; update impl and tests accordingly.
>  - continue support stax.properties at the impl level, though dropped from the spec
>  - change prefix from jdk to java
>  - change prefix from jdk to java; rm zip file that accidentally checked in
>  - update config file description; add a general scope and order section; move value definition for external properties to class description
>  - clean up tests; fix copy&paste error.
>  - 8303530: Add system property for custom JAXP configuration file

src/java.xml/share/classes/module-info.java line 33:

> 31:  * JAXP supports the use of a configuration file for the
> 32:  * <a href="#LookupMechanism">Factory Lookup Mechanism</a> and
> 33:  * setting properties that have defined corresponding system properties.

The first sentence of the module description lists the 4 XML APIs and their acronyms. It is immediately followed by a section with title "JAXP Configuration File" which suggests that this is a configuration file for the first API that is listed (JAXP). As I understand it, properties for the streaming API can also be defined in this file. So it might be that a bit more setup is needed in the opening text to make it clearer that this is the configuration file for all of the APIs.

src/java.xml/share/classes/module-info.java line 61:

> 59:  * By default, the <a href="#Factories">JAXP Factories</a> will look for a
> 60:  * configuration file called {@code jaxp.properties} in the {@code conf} directory
> 61:  * of the Java installation and use the entries if any to customize the behavior

"of the Java installation" should probably say the run-time image, or maybe just change this to use ${java.home}/conf as it is used in other API docs.

src/java.xml/share/classes/module-info.java line 74:

> 72:  * <h3 id="CF_SP">User-defined Configuration File</h3>
> 73:  * A user-defined configuration file can be set outside of the JDK by using the
> 74:  * system property {@code java.xml.config.file}.

"can be set out of the JDK" needs to be re-phrased. Maybe this sentence can be restructured to say that a system property can be set on the command line to specify the location of a configuration file on the file system. Adding "command line" would be helpful because "system property" is too overloaded in these docs.

src/java.xml/share/classes/module-info.java line 257:

> 255:  * the {@link javax.xml.XMLConstants#FEATURE_SECURE_PROCESSING FEATURE_SECURE_PROCESSING}
> 256:  * (hereafter referred to FSP), and the default values. The order of precedence
> 257:  * for the configuration sources is defined as follows, with earlier ones overriding the later:

"using the API properties" is bit confusing. I think you mean that properties can be set via the APIs. 

".. and the default values". I think it would be clearer to say that properties have default values when not set by previous four ways.

src/java.xml/share/classes/module-info.java line 264:

> 262:  * </li>
> 263:  * <li><p>
> 264:  *      Properties set using the corresponding System properties;

Can you confirm that this means system properties set on the command line with -Dkey=value or System.setProperty(key, value)?  

(I understand that the catalog feature "RESOLVE" property helps to explain it but I'm concerned that "system property" is ambiguous throughout).

src/java.xml/share/classes/module-info.java line 332:

> 330:  * @implNote
> 331:  *
> 332:  * <h2 id="ConfigurationFile">JAXP Configuration File</h2>

I thin this means there are two anchors with the same name and two sections in the module description with the same title. I understand this is SE vs. JDK specific properties but this could easily go over the headers of someone reading this. I think it would be better if "Implementation Specific Features and Properties" were the first section of the implNote. It can start by saying that the JAXP Configuration file (link to the description at the top) can also be used for JDK/implementation specific properties.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1181179391
PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1181179908
PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1181180282
PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1181181311
PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1181181811
PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1181183010

From alanb at openjdk.org  Sun Apr 30 07:58:24 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 30 Apr 2023 07:58:24 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v9]
In-Reply-To: <tii6-GGgEZTZiTOmh83uN4qrUaK1WXvmJJTfxD5oHvA=.e3048ff2-e0e6-4f3f-b1fd-8533ce5264ab@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <w_VQMDXdJScfmyacC0Mxsq4ZshVvw8vLNEcw62YbH1I=.4296584d-da35-4b67-8914-ac26aeef1873@github.com>
 <tii6-GGgEZTZiTOmh83uN4qrUaK1WXvmJJTfxD5oHvA=.e3048ff2-e0e6-4f3f-b1fd-8533ce5264ab@github.com>
Message-ID: <fnyLl2iOgGVDKb12U9zrej7-SEjK2_RxYAdW2jeucA8=.4b8ea8d9-a305-40a5-8c1b-4fbf2429aa7b@github.com>

On Sun, 30 Apr 2023 07:23:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8303530
>>  - Update based on the review meeting on 4/5. Added (duplicated) definitions in jaxp.properties; Rewrote Property Precedence with samples; Other updates.
>>  - update javadoc as discussed in the review meeting; add a sample configuration file jaxp.properties; update impl and tests accordingly.
>>  - continue support stax.properties at the impl level, though dropped from the spec
>>  - change prefix from jdk to java
>>  - change prefix from jdk to java; rm zip file that accidentally checked in
>>  - update config file description; add a general scope and order section; move value definition for external properties to class description
>>  - clean up tests; fix copy&paste error.
>>  - 8303530: Add system property for custom JAXP configuration file
>
> src/java.xml/share/classes/module-info.java line 33:
> 
>> 31:  * JAXP supports the use of a configuration file for the
>> 32:  * <a href="#LookupMechanism">Factory Lookup Mechanism</a> and
>> 33:  * setting properties that have defined corresponding system properties.
> 
> The first sentence of the module description lists the 4 XML APIs and their acronyms. It is immediately followed by a section with title "JAXP Configuration File" which suggests that this is a configuration file for the first API that is listed (JAXP). As I understand it, properties for the streaming API can also be defined in this file. So it might be that a bit more setup is needed in the opening text to make it clearer that this is the configuration file for all of the APIs.

One other thing to say on this is that jaxp.properties has "XML Library (java.xml) Configuration File" at the top of the file, maybe that could be used in the module description instead of "JAXP Configuration File".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1181183595

From duke at openjdk.org  Sun Apr 30 18:03:54 2023
From: duke at openjdk.org (Neal Gafter)
Date: Sun, 30 Apr 2023 18:03:54 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v2]
In-Reply-To: <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
Message-ID: <2i5j2tzClvDQt_beMcwfEp3wzhWx0KYz-6WKUUERwVY=.2d9def45-999a-4be4-8b6f-d69302da35cb@github.com>

On Tue, 17 Jan 2023 15:55:40 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> The pattern matching switches are using a bootstrap method `SwitchBootstrap.typeSwitch` to implement the jumps in the switch. Basically, for a switch like:
>> 
>> switch (obj) {
>>     case String s when s.isEmpty() -> {}
>>     case String s -> {}
>>     case CharSequence cs -> {}
>>     ...
>> }
>> 
>> 
>> this method will produce a MethodHandle that will be analyze the provided selector value (`obj` in the example), and will return the case index to which the switch should jump. This method also accepts a (re)start index for the search, which is used to handle guards. For example, if the `s.isEmpty()` guard in the above sample returns false, the matching is restarted on the next case.
>> 
>> The current implementation is fairly slow, it basically goes through the labels in a loop. The proposal here is to replace that with a MethodHandle structure like this:
>> 
>> obj == null ? -1
>>                   : switch (restartIndex) {
>>                         case 0 -> obj instanceof String ? 0 : obj instanceof CharSequence ? 2 : ... ;
>>                         case 1 -> obj instanceof String ? 1 : obj instanceof CharSequence ? 2 : ... ;
>>                         case 2 -> obj instanceof CharSequence ? 2 : ... ;
>>                         ...
>>                         default -> <labels-count>;
>>                     }
>> 
>> 
>> This appear to run faster than the current implementation, using testcase similar to the one used for https://github.com/openjdk/jdk/pull/9746 , these are the results
>> 
>> PatternsOptimizationTest.testLegacyIndyLongSwitch   thrpt   25   1515989.562 ? 32047.918  ops/s
>> PatternsOptimizationTest.testHandleIndyLongSwitch   thrpt   25   2630707.585 ? 37202.210  ops/s
>> 
>> PatternsOptimizationTest.testLegacyIndyShortSwitch  thrpt   25   6789310.900 ? 61921.636  ops/s
>> PatternsOptimizationTest.testHandleIndyShortSwitch  thrpt   25  10771729.464 ? 69607.467  ops/s
>> 
>> 
>> The "LegacyIndy" is the current implementation, "HandleIndy" is the one proposed here. The translation in javac used is the one from #9746 in all cases.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Adding comments
>  - Improving performance
>  - Merge branch 'master' into JDK-8291966
>  - 8291966: SwitchBootstrap.typeSwitch could be faster

Building a map or hash table will be faster than sequential search.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9779#issuecomment-1528000461

From alanb at openjdk.org  Sun Apr 30 18:39:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 30 Apr 2023 18:39:00 GMT
Subject: RFR: 8305919: java/lang/Thread/virtual/HoldsLock.java#id0 failed,
 ThreadInfo.getLockInfo() return null
Message-ID: <MtBAN1ez9E7I6qLsShNHUgiiGZGx852oyNgSosTNhPE=.4d5ab352-6503-433c-aee0-d711e3fe4918@github.com>

HoldsLock.java#id0 has been failing intermittently recently due to threads left over from previous tests terminating. HoldsLock.java#id1 doesn't fail as it runs in /othervm mode. The test uses ThreadMXBean::getAllThreadIds to get the ID of all threads and calls ThreadMXBean::getThreadInfo on each thread. If a thread from a previous test terminates then getThreadInfo returns null and the test fails.

The test can be trivially fixed to check for null but looking at it afresh, the test can be simplified to use existing test infrastructure and to just call ThreadMXBean::getThreadInfo on the carrier. The test can also be renamed to make it clearer that it is testing a carrier threads wait for a virtual thread. The old test includes a disabled test for Thread.holdsLock but there is further VM work required before that is useful and it would be better to develop new tests at part of that work.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/13738/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13738&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305919
  Stats: 292 lines in 4 files changed: 96 ins; 194 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13738.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13738/head:pull/13738

PR: https://git.openjdk.org/jdk/pull/13738

From alanb at openjdk.org  Sun Apr 30 18:47:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 30 Apr 2023 18:47:53 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <eoIorjwEtpPHUF-IYyAToOMQAeQ6HZNvccYvCT0zCwI=.61a939e7-089e-410b-8361-c3eea99969fd@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <yk-I2N6h2l7wEgkcHeBAt46OSbDrDxt-P8QgC7pTO_o=.8fa9c1ee-604d-4b97-bcd4-c70355c9564f@github.com>
 <eoIorjwEtpPHUF-IYyAToOMQAeQ6HZNvccYvCT0zCwI=.61a939e7-089e-410b-8361-c3eea99969fd@github.com>
Message-ID: <Fo_R8bXjDqPZslPylTg16uSKoFPM_iwU83wEoZRPkqA=.2106178e-4a13-4598-a67d-04ebd77a1d8c@github.com>

On Fri, 28 Apr 2023 18:14:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The build is already capable of producing .a files and this patch is building on top of that build feature. The current .a file creation is used by the downstream graal build which needs it for nativeimage.

Also builds on recent changes to remove duplicate symbol names. It's good that the PR demonstrates that these can be linked to create "javastatic" but having it copy into the run-time image created by jlink is probably not the eventual outcome.

A possible direction on this is for the build to create a set of packaged modules with the .a files, then have an alternative image builder in jlink that integrates with the native linker. Combined with other parts in Jiangli's slides/proposal, it would mean that jlink could produce a single executable that would work for both the JDK or any set of modules.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1529110628

From jvernee at openjdk.org  Sun Apr 30 19:09:23 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sun, 30 Apr 2023 19:09:23 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <Fo_R8bXjDqPZslPylTg16uSKoFPM_iwU83wEoZRPkqA=.2106178e-4a13-4598-a67d-04ebd77a1d8c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <yk-I2N6h2l7wEgkcHeBAt46OSbDrDxt-P8QgC7pTO_o=.8fa9c1ee-604d-4b97-bcd4-c70355c9564f@github.com>
 <eoIorjwEtpPHUF-IYyAToOMQAeQ6HZNvccYvCT0zCwI=.61a939e7-089e-410b-8361-c3eea99969fd@github.com>
 <Fo_R8bXjDqPZslPylTg16uSKoFPM_iwU83wEoZRPkqA=.2106178e-4a13-4598-a67d-04ebd77a1d8c@github.com>
Message-ID: <-LR0qy8lzfy0N6sksIJNnVxAIesh0yQmRNYrG5pvG2I=.52637aed-bbc2-4ea8-a134-d148c91f2953@github.com>

On Sun, 30 Apr 2023 18:34:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A possible direction on this is for the build to create a set of packaged modules with the .a files, then have an alternative image builder in jlink that integrates with the native linker. Combined with other parts in Jiangli's slides/proposal, it would mean that jlink could produce a single executable that would work for both the JDK or any set of modules.

It seems that letting jlink do the linking is also a requirement for user provided modules (.jmods) that contain native libraries (as is the case for instance with jextract). We don't know about those libraries when building the JDK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1529114550

From forax at openjdk.org  Sun Apr 30 21:04:54 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sun, 30 Apr 2023 21:04:54 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v2]
In-Reply-To: <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
Message-ID: <D1hWi-s9eKUKEKLOZyLpjmzRQgc52DtE_5C4Z_cstos=.5958beae-f1c5-49cb-8119-dc70be962e35@github.com>

On Tue, 17 Jan 2023 15:55:40 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> The pattern matching switches are using a bootstrap method `SwitchBootstrap.typeSwitch` to implement the jumps in the switch. Basically, for a switch like:
>> 
>> switch (obj) {
>>     case String s when s.isEmpty() -> {}
>>     case String s -> {}
>>     case CharSequence cs -> {}
>>     ...
>> }
>> 
>> 
>> this method will produce a MethodHandle that will be analyze the provided selector value (`obj` in the example), and will return the case index to which the switch should jump. This method also accepts a (re)start index for the search, which is used to handle guards. For example, if the `s.isEmpty()` guard in the above sample returns false, the matching is restarted on the next case.
>> 
>> The current implementation is fairly slow, it basically goes through the labels in a loop. The proposal here is to replace that with a MethodHandle structure like this:
>> 
>> obj == null ? -1
>>                   : switch (restartIndex) {
>>                         case 0 -> obj instanceof String ? 0 : obj instanceof CharSequence ? 2 : ... ;
>>                         case 1 -> obj instanceof String ? 1 : obj instanceof CharSequence ? 2 : ... ;
>>                         case 2 -> obj instanceof CharSequence ? 2 : ... ;
>>                         ...
>>                         default -> <labels-count>;
>>                     }
>> 
>> 
>> This appear to run faster than the current implementation, using testcase similar to the one used for https://github.com/openjdk/jdk/pull/9746 , these are the results
>> 
>> PatternsOptimizationTest.testLegacyIndyLongSwitch   thrpt   25   1515989.562 ? 32047.918  ops/s
>> PatternsOptimizationTest.testHandleIndyLongSwitch   thrpt   25   2630707.585 ? 37202.210  ops/s
>> 
>> PatternsOptimizationTest.testLegacyIndyShortSwitch  thrpt   25   6789310.900 ? 61921.636  ops/s
>> PatternsOptimizationTest.testHandleIndyShortSwitch  thrpt   25  10771729.464 ? 69607.467  ops/s
>> 
>> 
>> The "LegacyIndy" is the current implementation, "HandleIndy" is the one proposed here. The translation in javac used is the one from #9746 in all cases.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Adding comments
>  - Improving performance
>  - Merge branch 'master' into JDK-8291966
>  - 8291966: SwitchBootstrap.typeSwitch could be faster

Sequential search can be faster, the array length is known by the JIT so the loop can be unrolled and subtype checks are usually fast.

A hash table is more complex to build because it needs to store the actual classes of the objects switched upon (those classes may not have been loaded yet), so it's a data structure that need to be dynamically updated by several threads. While it's possible to write this kind of data structures, it will require quite a lot of engineering to get it right.
So yes, it's planned.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9779#issuecomment-1529136366

From liach at openjdk.org  Sun Apr 30 21:16:27 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 30 Apr 2023 21:16:27 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v2]
In-Reply-To: <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
Message-ID: <u01Bw0bmaZnBijlpiZGK3cova1E0aHINaT857iPQnZE=.185775fe-af53-42ae-aee9-84565461d303@github.com>

On Tue, 17 Jan 2023 15:55:40 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> The pattern matching switches are using a bootstrap method `SwitchBootstrap.typeSwitch` to implement the jumps in the switch. Basically, for a switch like:
>> 
>> switch (obj) {
>>     case String s when s.isEmpty() -> {}
>>     case String s -> {}
>>     case CharSequence cs -> {}
>>     ...
>> }
>> 
>> 
>> this method will produce a MethodHandle that will be analyze the provided selector value (`obj` in the example), and will return the case index to which the switch should jump. This method also accepts a (re)start index for the search, which is used to handle guards. For example, if the `s.isEmpty()` guard in the above sample returns false, the matching is restarted on the next case.
>> 
>> The current implementation is fairly slow, it basically goes through the labels in a loop. The proposal here is to replace that with a MethodHandle structure like this:
>> 
>> obj == null ? -1
>>                   : switch (restartIndex) {
>>                         case 0 -> obj instanceof String ? 0 : obj instanceof CharSequence ? 2 : ... ;
>>                         case 1 -> obj instanceof String ? 1 : obj instanceof CharSequence ? 2 : ... ;
>>                         case 2 -> obj instanceof CharSequence ? 2 : ... ;
>>                         ...
>>                         default -> <labels-count>;
>>                     }
>> 
>> 
>> This appear to run faster than the current implementation, using testcase similar to the one used for https://github.com/openjdk/jdk/pull/9746 , these are the results
>> 
>> PatternsOptimizationTest.testLegacyIndyLongSwitch   thrpt   25   1515989.562 ? 32047.918  ops/s
>> PatternsOptimizationTest.testHandleIndyLongSwitch   thrpt   25   2630707.585 ? 37202.210  ops/s
>> 
>> PatternsOptimizationTest.testLegacyIndyShortSwitch  thrpt   25   6789310.900 ? 61921.636  ops/s
>> PatternsOptimizationTest.testHandleIndyShortSwitch  thrpt   25  10771729.464 ? 69607.467  ops/s
>> 
>> 
>> The "LegacyIndy" is the current implementation, "HandleIndy" is the one proposed here. The translation in javac used is the one from #9746 in all cases.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Adding comments
>  - Improving performance
>  - Merge branch 'master' into JDK-8291966
>  - 8291966: SwitchBootstrap.typeSwitch could be faster

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 70:

> 68:         try {
> 69:             INSTANCEOF_CHECK = LOOKUP.findStatic(SwitchBootstraps.class, "instanceofCheck",
> 70:                                            MethodType.methodType(boolean.class, Object.class, Class.class));

I am tempted to have
Suggestion:

            INSTANCEOF_CHECK = MethodHandles.permuteArguments(LOOKUP.findVirtual(Class.class, "isInstance",
                                           MethodType.methodType(boolean.class, Object.class)), MethodType.methodType(boolean.class, Object.class, Class.class), 1, 0);

to reduce the implementation methods in SwitchBootstraps

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 75:

> 73:             OBJECT_EQ_CHECK = LOOKUP.findStatic(Objects.class, "equals",
> 74:                                            MethodType.methodType(boolean.class, Object.class, Object.class));
> 75:             NULL_CHECK = LOOKUP.findStatic(SwitchBootstraps.class, "nullCheck",

Suggestion:

            NULL_CHECK = LOOKUP.findStatic(Objects.class, "isNull",

Can remove the `nullCheck` method.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 79:

> 77:             IS_ZERO = LOOKUP.findStatic(SwitchBootstraps.class, "isZero",
> 78:                                            MethodType.methodType(boolean.class, int.class));
> 79:             ENUM_LOOKUP = LOOKUP.findStatic(SwitchBootstraps.class, "enumLookup",

Appears unused and should be removed.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 175:

> 173:         MethodHandle def = MethodHandles.dropArguments(MethodHandles.constant(int.class, labels.length), 0, Object.class);
> 174:         MethodHandle[] testChains = new MethodHandle[labels.length];
> 175:         List<Object> labelsList = new ArrayList<>(Arrays.asList(labels));

Suggestion:

        List<Object> labelsList = Arrays.asList(labels).reversed();

Requires you to update to latest JDK with the SequencedCollection patch; labels is already sanitized upon bootstrap method call, no need to copy again since you don't modify it

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 177:

> 175:         List<Object> labelsList = new ArrayList<>(Arrays.asList(labels));
> 176: 
> 177:         Collections.reverse(labelsList);

Suggestion:

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 321:

> 319:         if (constantsOnly) {
> 320:             long nonNullValues = Stream.of(labels).filter(l -> l != null).count();
> 321:             long distinctNonNullValues = Stream.of(labels).filter(l -> l != null).distinct().count();

Suggestion:

            long nonNullValues = Stream.of(labels).filter(Objects::nonNull).count();
            long distinctNonNullValues = Stream.of(labels).filter(Objects::nonNull).distinct().count();

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 337:

> 335:             //                          };
> 336:             //else return "createRepeatIndexSwitch(labels)"
> 337:             MethodHandle[] map = new MethodHandle[enumClass.getEnumConstants().length];

Can use JavaLangAccess.getEnumConstantsShared() to get the shared array to avoid copying; same below in the for loop.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/9779#discussion_r1181294780
PR Review Comment: https://git.openjdk.org/jdk/pull/9779#discussion_r1181294053
PR Review Comment: https://git.openjdk.org/jdk/pull/9779#discussion_r1181294384
PR Review Comment: https://git.openjdk.org/jdk/pull/9779#discussion_r1181293988
PR Review Comment: https://git.openjdk.org/jdk/pull/9779#discussion_r1181293296
PR Review Comment: https://git.openjdk.org/jdk/pull/9779#discussion_r1181293602
PR Review Comment: https://git.openjdk.org/jdk/pull/9779#discussion_r1181278511

From jvernee at openjdk.org  Sun Apr 30 21:43:22 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sun, 30 Apr 2023 21:43:22 GMT
Subject: RFR: 8156916: intrinsify MethodHandles.arrayConstructor()
In-Reply-To: <Y3vQNof2nwMwjM2w7G15h3oMf745ceWqQcIXHW0Jgi0=.0b50ab3f-9629-40ca-8a6b-d90def8d3e24@github.com>
References: <Y3vQNof2nwMwjM2w7G15h3oMf745ceWqQcIXHW0Jgi0=.0b50ab3f-9629-40ca-8a6b-d90def8d3e24@github.com>
Message-ID: <8qkFom3exu2TxvMR-GnfMnkTphkJhNunNO2CfAeyNQk=.838a4804-5f32-4ef1-8a7e-3f7f898f7c5d@github.com>

On Sun, 30 Apr 2023 06:14:28 GMT, Chen Liang <liach at openjdk.org> wrote:

> Try to intrinsify MethodHandles.arrayConstructor for java.lang, java.lang.invoke, and java.util types, which InvokerBytecodeGenerator can refer to directly in a class constant.
> 
> In fact, the performance difference of Array.newInstance and anewarray is quite negligible per benchmark:
> 
> Benchmark                                                            Mode  Cnt     Score     Error  Units
> MethodHandlesArrayConstructorCall.baselineConstruct                  avgt    5     3.467 ?   0.163  ns/op
> MethodHandlesArrayConstructorCall.constantFoldConstruct              avgt    5     3.403 ?   0.070  ns/op
> MethodHandlesArrayConstructorCall.constantFoldNonInvocableConstruct  avgt    5     3.445 ?   0.231  ns/op
> MethodHandlesArrayConstructorCall.instanceConstruct                  avgt    5     4.034 ?   0.168  ns/op
> MethodHandlesArrayConstructorCall.instanceNonInvocableConstruct      avgt    5     4.038 ?   0.104  ns/op
> MethodHandlesArrayConstructorColdStart.testCreateInvocable             ss   10  1425.991 ? 308.216  us/op
> MethodHandlesArrayConstructorColdStart.testCreateNonInvocable          ss   10  1401.480 ? 258.402  us/op
> MethodHandlesArrayConstructorColdStart.testCreateObject                ss   10  1213.018 ? 166.522  us/op
> MethodHandlesArrayConstructorColdStart.testCreatePrimitive             ss   10  1163.461 ? 178.549  us/op

`Array::newInstance` is already intrinsified. It behaves pretty much the same as `anewarray` if the array type is constant ([1], [2]). So, I'm not sure I see how intrinsifying this could improve performance.

What kind of performance improvement are you seeing? Could you add a comparison with a method handle that calls `Array::newInstance` bound to the array type? (that should have the same performance as the current implementation).

[1]: https://github.com/openjdk/jdk/blob/b3dbf28bc0614bee2f7137af95389134155c9511/src/hotspot/share/opto/library_call.cpp#L4051
[2]: https://github.com/openjdk/jdk/blob/b3dbf28bc0614bee2f7137af95389134155c9511/src/hotspot/share/opto/parse3.cpp#L282

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13735#issuecomment-1529144414

From liach at openjdk.org  Sun Apr 30 22:04:25 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 30 Apr 2023 22:04:25 GMT
Subject: RFR: 8156916: intrinsify MethodHandles.arrayConstructor()
In-Reply-To: <8qkFom3exu2TxvMR-GnfMnkTphkJhNunNO2CfAeyNQk=.838a4804-5f32-4ef1-8a7e-3f7f898f7c5d@github.com>
References: <Y3vQNof2nwMwjM2w7G15h3oMf745ceWqQcIXHW0Jgi0=.0b50ab3f-9629-40ca-8a6b-d90def8d3e24@github.com>
 <8qkFom3exu2TxvMR-GnfMnkTphkJhNunNO2CfAeyNQk=.838a4804-5f32-4ef1-8a7e-3f7f898f7c5d@github.com>
Message-ID: <GcPXqJaySPfTyRsO0rQ1-gRJRFzXWJB_FuHhqxpO2e4=.ca3c930b-9df9-43fb-a2d9-fe020277553b@github.com>

On Sun, 30 Apr 2023 21:34:46 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> What kind of performance improvement are you seeing? Could you add a comparison with a method handle that calls `Array::newInstance` bound to the array type? (that should have the same performance as the current implementation).

That explains why `NonInvocable` (delegates to Array.newInstance) isn't slower than `anewarray` opcode (`Invocable`) in the benchmark results above. I will drop this patch and close the related JBS issue as no longer applicable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13735#issuecomment-1529146338

From liach at openjdk.org  Sun Apr 30 22:04:27 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 30 Apr 2023 22:04:27 GMT
Subject: RFR: 8156916: intrinsify MethodHandles.arrayConstructor()
In-Reply-To: <Y3vQNof2nwMwjM2w7G15h3oMf745ceWqQcIXHW0Jgi0=.0b50ab3f-9629-40ca-8a6b-d90def8d3e24@github.com>
References: <Y3vQNof2nwMwjM2w7G15h3oMf745ceWqQcIXHW0Jgi0=.0b50ab3f-9629-40ca-8a6b-d90def8d3e24@github.com>
Message-ID: <Z5gG_ddEb075ufg_VfYMHTkM3c5f_DzMfLU1-ElJOrE=.acefe072-629e-4cc5-baa1-99b828e11014@github.com>

On Sun, 30 Apr 2023 06:14:28 GMT, Chen Liang <liach at openjdk.org> wrote:

> Try to intrinsify MethodHandles.arrayConstructor for java.lang, java.lang.invoke, and java.util types, which InvokerBytecodeGenerator can refer to directly in a class constant.
> 
> In fact, the performance difference of Array.newInstance and anewarray is quite negligible per benchmark:
> 
> Benchmark                                                            Mode  Cnt     Score     Error  Units
> MethodHandlesArrayConstructorCall.baselineConstruct                  avgt    5     3.467 ?   0.163  ns/op
> MethodHandlesArrayConstructorCall.constantFoldConstruct              avgt    5     3.403 ?   0.070  ns/op
> MethodHandlesArrayConstructorCall.constantFoldNonInvocableConstruct  avgt    5     3.445 ?   0.231  ns/op
> MethodHandlesArrayConstructorCall.instanceConstruct                  avgt    5     4.034 ?   0.168  ns/op
> MethodHandlesArrayConstructorCall.instanceNonInvocableConstruct      avgt    5     4.038 ?   0.104  ns/op
> MethodHandlesArrayConstructorColdStart.testCreateInvocable             ss   10  1425.991 ? 308.216  us/op
> MethodHandlesArrayConstructorColdStart.testCreateNonInvocable          ss   10  1401.480 ? 258.402  us/op
> MethodHandlesArrayConstructorColdStart.testCreateObject                ss   10  1213.018 ? 166.522  us/op
> MethodHandlesArrayConstructorColdStart.testCreatePrimitive             ss   10  1163.461 ? 178.549  us/op

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4334:

> 4332:         MethodHandle ani = MethodHandleImpl.getConstantHandle(MethodHandleImpl.MH_Array_newInstance).
> 4333:                 bindTo(arrayClass.getComponentType());
> 4334:         return ani.asType(ani.type().changeReturnType(arrayClass));

Since `Array.newInstance` is already intrinsified, this patch should probably dropped and the issue be no longer valid. However, one nit I have is that we can convert this `asType` to `viewAsType(..., false)` since `Array.newInstance`'s return type is trusted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13735#discussion_r1181301403

From liach at openjdk.org  Sun Apr 30 22:04:28 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 30 Apr 2023 22:04:28 GMT
Subject: Withdrawn: 8156916: intrinsify MethodHandles.arrayConstructor()
In-Reply-To: <Y3vQNof2nwMwjM2w7G15h3oMf745ceWqQcIXHW0Jgi0=.0b50ab3f-9629-40ca-8a6b-d90def8d3e24@github.com>
References: <Y3vQNof2nwMwjM2w7G15h3oMf745ceWqQcIXHW0Jgi0=.0b50ab3f-9629-40ca-8a6b-d90def8d3e24@github.com>
Message-ID: <wt6q62JfGZ78bfTkvbI5jNez8iTlo9h5aJCZuFIUQec=.78e58990-49af-4d01-9ca7-51d354374b16@github.com>

On Sun, 30 Apr 2023 06:14:28 GMT, Chen Liang <liach at openjdk.org> wrote:

> Try to intrinsify MethodHandles.arrayConstructor for java.lang, java.lang.invoke, and java.util types, which InvokerBytecodeGenerator can refer to directly in a class constant.
> 
> In fact, the performance difference of Array.newInstance and anewarray is quite negligible per benchmark:
> 
> Benchmark                                                            Mode  Cnt     Score     Error  Units
> MethodHandlesArrayConstructorCall.baselineConstruct                  avgt    5     3.467 ?   0.163  ns/op
> MethodHandlesArrayConstructorCall.constantFoldConstruct              avgt    5     3.403 ?   0.070  ns/op
> MethodHandlesArrayConstructorCall.constantFoldNonInvocableConstruct  avgt    5     3.445 ?   0.231  ns/op
> MethodHandlesArrayConstructorCall.instanceConstruct                  avgt    5     4.034 ?   0.168  ns/op
> MethodHandlesArrayConstructorCall.instanceNonInvocableConstruct      avgt    5     4.038 ?   0.104  ns/op
> MethodHandlesArrayConstructorColdStart.testCreateInvocable             ss   10  1425.991 ? 308.216  us/op
> MethodHandlesArrayConstructorColdStart.testCreateNonInvocable          ss   10  1401.480 ? 258.402  us/op
> MethodHandlesArrayConstructorColdStart.testCreateObject                ss   10  1213.018 ? 166.522  us/op
> MethodHandlesArrayConstructorColdStart.testCreatePrimitive             ss   10  1163.461 ? 178.549  us/op

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/13735