Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]

> Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the original file's changes in UTF-8 > native. Those

Re: RFR: 8285368: Overhaul doc-comment inheritance [v9]

On Wed, 14 Jun 2023 10:07:05 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line >> 1534: >> >>> 1532: >>> 1533: /** >>> 1534: * {@inheritDoc ConcurrentMap} >> >> This clarifies the authors' intent, so is clear progress. >> >>

Re: RFR: 8310157: Allow void-returning filters for MethodHandles::collectCoordinates [v2]

> This patch changes the implementation of `MethodHandles::collectCoordinates` > to allow using filters that return `void`. This brings the behavior in line > with the previously existing `MethodHandles::collectArgument` which operates > on MethodHandles rather than VarHandles. > > Testing:

Re: RFR: 8310157: Allow void-returning filters for MethodHandles::collectCoordinates

On Thu, 15 Jun 2023 15:44:04 GMT, Jorn Vernee wrote: > This patch changes the implementation of `MethodHandles::collectCoordinates` > to allow using filters that return `void`. This brings the behavior in line > with the previously existing `MethodHandles::collectArgument` which operates > on

Re: RFR: 8308780: Fix the Java Integer types on Windows [v4]

On Thu, 15 Jun 2023 23:22:48 GMT, Phil Race wrote: >> Julian Waters has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix the code that is actually warning > > src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1089: >

Re: RFR: 8310157: Allow void-returning filters for MethodHandles::collectCoordinates

On Thu, 15 Jun 2023 15:44:04 GMT, Jorn Vernee wrote: > This patch changes the implementation of `MethodHandles::collectCoordinates` > to allow using filters that return `void`. This brings the behavior in line > with the previously existing `MethodHandles::collectArgument` which operates > on

RFR: 8310157: Allow void-returning filters for MethodHandles::collectCoordinates

This patch changes the implementation of `MethodHandles::collectCoordinates` to allow using filters that return `void`. This brings the behavior in line with the previously existing `MethodHandles::collectArgument` which operates on MethodHandles rather than VarHandles. Testing: jdk-tier1,2,3

Re: RFR: 8308694: Clarify reversed() default methods' implementation requirements

On Thu, 15 Jun 2023 22:54:09 GMT, Brian Burkhalter wrote: >> Can I get a preliminary review of the wording for Deque.reversed()? If the >> text is good, I'll make corresponding changes to the implSpecs of the other >> reversed() default methods, namely those in List, SortedMap, and SortedSet

Re: RFR: 8309819: Clarify API note in Class::getName and MethodType::toMethodDescriptorString [v5]

On Thu, 15 Jun 2023 16:32:27 GMT, Mandy Chung wrote: >> src/java.base/share/classes/java/lang/Class.java line 933: >> >>> 931: * classes whose element type is a hidden class or interface >>> cannot be >>> 932: * discovered by {@code forName}. >>> 933: * >> >> This is an API

Re: RFR: 8308780: Fix the Java Integer types on Windows [v4]

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters wrote: >> On Windows, the basic Java Integer types are defined as long and __int64 >> respectively. In particular, the former is rather problematic since it >> breaks compilation as the Visual C++ becomes stricter and more compliant >> with every

Re: RFR: 8308694: Clarify reversed() default methods' implementation requirements

On Thu, 15 Jun 2023 22:38:43 GMT, Stuart Marks wrote: > Can I get a preliminary review of the wording for Deque.reversed()? If the > text is good, I'll make corresponding changes to the implSpecs of the other > reversed() default methods, namely those in List, SortedMap, and SortedSet > and

RFR: 8308694: Clarify reversed() default methods' implementation requirements

Can I get a preliminary review of the wording for Deque.reversed()? If the text is good, I'll make corresponding changes to the implSpecs of the other reversed() default methods, namely those in List, SortedMap, and SortedSet and then file the CSR. - Commit messages: - 8308694:

Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update

On Thu, 15 Jun 2023 21:06:32 GMT, Kevin Rushforth wrote: > Is the patch expected to be the same as in jdk mainline? I see some > differences between the two patches (which is why Skara didn't mark it as > "clean") Hi Kevin, yes it is. I still need to grab the changes from mainline and include

Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the

Re: RFR: 8309688: Data race on java.io.ClassCache$CacheRef.strongReferent [v6]

On Thu, 15 Jun 2023 18:22:46 GMT, Man Cao wrote: >> Hi all, >> >> Could anyone review this small fix for a data race in >> java.io.ClassCache$CacheRef? This fix makes the code safer by making the >> code data-race-free. > > Man Cao has updated the pull request incrementally with one

Integrated: 8309688: Data race on java.io.ClassCache$CacheRef.strongReferent

On Thu, 8 Jun 2023 22:06:56 GMT, Man Cao wrote: > Hi all, > > Could anyone review this small fix for a data race in > java.io.ClassCache$CacheRef? This fix makes the code safer by making the code > data-race-free. This pull request has now been integrated. Changeset: 5c705166 Author:Man

Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the

Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the

Integrated: 8309632: JDK 21 RDP1 L10n resource files update

On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the

Re: RFR: 8309688: Data race on java.io.ClassCache$CacheRef.strongReferent [v6]

On Thu, 15 Jun 2023 18:22:46 GMT, Man Cao wrote: >> Hi all, >> >> Could anyone review this small fix for a data race in >> java.io.ClassCache$CacheRef? This fix makes the code safer by making the >> code data-race-free. > > Man Cao has updated the pull request incrementally with one

Re: RFR: 8309688: Data race on java.io.ClassCache$CacheRef.strongReferent [v5]

On Thu, 15 Jun 2023 08:23:58 GMT, Aleksey Shipilev wrote: >> Man Cao has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes the unrelated changes brought >> in by the merge/rebase. The pull request contains five additional commits >>

Re: RFR: 8309688: Data race on java.io.ClassCache$CacheRef.strongReferent [v6]

On Thu, 15 Jun 2023 18:17:17 GMT, Man Cao wrote: >> Hi all, >> >> Could anyone review this small fix for a data race in >> java.io.ClassCache$CacheRef? This fix makes the code safer by making the >> code data-race-free. > > Man Cao has updated the pull request incrementally with one

Re: RFR: 8309688: Data race on java.io.ClassCache$CacheRef.strongReferent [v6]

> Hi all, > > Could anyone review this small fix for a data race in > java.io.ClassCache$CacheRef? This fix makes the code safer by making the code > data-race-free. Man Cao has updated the pull request incrementally with one additional commit since the last revision: Update comment

Re: OpenJDK fails to build on mips and mips64el after JDK-8304913

Hi Vladimir, Can you confirm that the requested changes in PR 14471 address the issue with mips and mips64el. Thanks, Roger On 6/14/23 5:36 AM, Vladimir Petko wrote: Dear Maintainers, After JDK-8304913, OpenJDK fails to build on mips[1] and

Re: RFR: 8310105: LoongArch64 builds are broken after JDK-8304913

On Thu, 15 Jun 2023 08:12:45 GMT, Aleksey Shipilev wrote: >> LoongArch64 Zero builds are broken after >> [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913): >> >> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum >> constant

Re: RFR: 8310105: LoongArch64 builds are broken after JDK-8304913

On Thu, 15 Jun 2023 04:40:59 GMT, Ao Qi wrote: > LoongArch64 Zero builds are broken after > [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913): > > jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum > constant jdk.internal.util.Architecture.LOONGARCH64 > at >

Integrated: 8285368: Overhaul doc-comment inheritance

On Wed, 7 Jun 2023 14:19:16 GMT, Pavel Rappo wrote: > Please review this long-awaited change to documentation inheritance. > > This change improves "methods comment algorithm" and introduces directed > documentation inheritance. While "methods comment algorithm" -- automatic > search for

Re: RFR: 8310019: MIPS builds are broken after JDK-8304913 [v3]

On Thu, 15 Jun 2023 17:44:01 GMT, Roger Riggs wrote: >> Add mipsel and mips64el to the Architecture enum. >> (Later to be backported to JDK 21) > > Roger Riggs has updated the pull request incrementally with one additional > commit since the last revision: > > Correct mps64el test case

Re: RFR: 8310019: MIPS builds are broken after JDK-8304913 [v3]

> Add mipsel and mips64el to the Architecture enum. > (Later to be backported to JDK 21) Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Correct mps64el test case - Changes: - all:

Re: RFR: 8308899: Introduce Classfile.Context and improve Classfile.Option(s) [v21]

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

Re: RFR: 8309819: Clarify API note in Class::getName and MethodType::toMethodDescriptorString [v5]

On Thu, 15 Jun 2023 10:04:38 GMT, Alan Bateman wrote: >> Chen Liang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update the note for getName > > src/java.base/share/classes/java/lang/Class.java line 933: > >> 931: * classes

Re: RFR: 8308899: Introduce Classfile.Context and improve Classfile.Option(s) [v20]

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

Re: RFR: 8308899: Introduce Classfile.Context and improve Classfile.Option(s) [v19]

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

Re: RFR: 8284493: Improve computeNextExponential tail performance and accuracy [v21]

On Mon, 15 May 2023 15:51:02 GMT, Chris Hennick wrote: >> This PR improves both the worst-case performance of `nextExponential` and >> `nextGaussian` and the distribution of output at the tails. It fixes the >> following imperfections: >> >> * Repeatedly adding

Re: RFR: 8310053: VarHandle and slice handle derived from layout are lacking alignment check [v5]

On Thu, 15 Jun 2023 13:08:45 GMT, Jorn Vernee wrote: >> Add missing alignment checks for the alignment constraint of the root layout >> of a VarHandle created through `MemoryLayout::varHandle` and a MethodHandle >> `MemoryLayout::sliceHandle`. >> >> Testing: `jdk_foreign` test suite > > Jorn

Re: RFR: 8310053: VarHandle and slice handle derived from layout are lacking alignment check [v4]

On Wed, 14 Jun 2023 23:38:01 GMT, Jorn Vernee wrote: >> Add missing alignment checks for the alignment constraint of the root layout >> of a VarHandle created through `MemoryLayout::varHandle` and a MethodHandle >> `MemoryLayout::sliceHandle`. >> >> Testing: `jdk_foreign` test suite > > Jorn

Re: RFR: 8310053: VarHandle and slice handle derived from layout are lacking alignment check [v5]

> Add missing alignment checks for the alignment constraint of the root layout > of a VarHandle created through `MemoryLayout::varHandle` and a MethodHandle > `MemoryLayout::sliceHandle`. > > Testing: `jdk_foreign` test suite Jorn Vernee has updated the pull request incrementally with one

Re: RFR: 8310019: MIPS builds are broken after JDK-8304913 [v2]

On Wed, 14 Jun 2023 15:50:19 GMT, Roger Riggs wrote: >> Add mipsel and mips64el to the Architecture enum. >> (Later to be backported to JDK 21) > > Roger Riggs has updated the pull request incrementally with one additional > commit since the last revision: > > Add tests for MIPSEL and

Re: RFR: 8310019: MIPS builds are broken after JDK-8304913 [v2]

On Wed, 14 Jun 2023 15:56:49 GMT, Aleksey Shipilev wrote: > Looks fine. We want/need the original reporter to confirm it works now? Native build `linux-mips64el-zero-release` passed after the fix. I'm not the original reporter. - PR Comment:

Re: RFR: 8310053: VarHandle and slice handle derived from layout are lacking alignment check [v4]

On Thu, 15 Jun 2023 00:22:09 GMT, Maurizio Cimadamore wrote: > only the first var handle in the dereference chain gets the proper alignment > adaptation on the input segment That would be easy enough to do, we just check for `derefAdapters.length == 0`. I'll add this too. - PR

Re: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails with "-XX:-VMContinuations" [v8]

> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`. > > `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM > error occurs it can not recover scoped values. > > Moving `runWith()` into the common subclass of both `VirtualThread` and > `BoundVirtualThread`

Re: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails with "-XX:-VMContinuations" [v7]

On Thu, 15 Jun 2023 11:11:18 GMT, Andrew Haley wrote: >> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`. >> >> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM >> error occurs it can not recover scoped values. >> >> Moving `runWith()` into the common

Re: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails with "-XX:-VMContinuations" [v7]

> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`. > > `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM > error occurs it can not recover scoped values. > > Moving `runWith()` into the common subclass of both `VirtualThread` and > `BoundVirtualThread`

Re: RFR: 8309408: Thread.sleep cleanup [v2]

> Thread.sleep has had quite a bit of churn recently to support virtual > threads, add sleep(Duration), a JFR event, and the change the underlying > implementation to support sub-millis precision. I think the changes have > settled down now so we can do some small cleanups that came up in PR >

Re: RFR: 8309819: Clarify API note in Class::getName and MethodType::toMethodDescriptorString [v5]

On Thu, 15 Jun 2023 02:38:08 GMT, Chen Liang wrote: >> The API specification for descriptorString not being a strict inverse of >> Class::forName and MethodType::fromDescriptorString are not entirely correct. >> >> 1. Class::descriptorString was never an inverse of Class::forName, which >>

Re: RFR: 8309819: Clarify API note in Class::getName and MethodType::toMethodDescriptorString [v5]

On Thu, 15 Jun 2023 02:38:08 GMT, Chen Liang wrote: >> The API specification for descriptorString not being a strict inverse of >> Class::forName and MethodType::fromDescriptorString are not entirely correct. >> >> 1. Class::descriptorString was never an inverse of Class::forName, which >>

Re: RFR: 8285368: Overhaul doc-comment inheritance [v10]

> Please review this long-awaited change to documentation inheritance. > > This change improves "methods comment algorithm" and introduces directed > documentation inheritance. While "methods comment algorithm" -- automatic > search for inheritable documentation -- has been improved, it still

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v7]

> * improved mixed insertion sort (makes whole sorting faster) > * introduced Radix which sort shows several times boost of performance and > has linear complexity instead of n*ln(n) > * improved merging sort for almost sorted data > * optimized parallel sorting > * improved step for pivot

Re: RFR: 8309688: Data race on java.io.ClassCache$CacheRef.strongReferent [v5]

On Thu, 15 Jun 2023 00:16:15 GMT, Man Cao wrote: >> Hi all, >> >> Could anyone review this small fix for a data race in >> java.io.ClassCache$CacheRef? This fix makes the code safer by making the >> code data-race-free. > > Man Cao has updated the pull request with a new target base due to a

Re: RFR: 8310105: LoongArch64 builds are broken after JDK-8304913

On Thu, 15 Jun 2023 04:40:59 GMT, Ao Qi wrote: > LoongArch64 Zero builds are broken after > [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913): > > jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum > constant jdk.internal.util.Architecture.LOONGARCH64 > at >

Re: RFR: 8281658: Add a security category to the java -XshowSettings option [v3]

On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information >> about JDK security configuration > > Sean Coffey has updated the pull request incrementally with one additional > commit since the last revision: > >

Re: RFR: 8309408: Thread.sleep cleanup

On Mon, 5 Jun 2023 19:44:35 GMT, Alan Bateman wrote: > > I think we need to delay this until > > [JDK-8309361](https://bugs.openjdk.org/browse/JDK-8309361) is resolved, in > > case we would like to revert > > [JDK-8305092](https://bugs.openjdk.org/browse/JDK-8305092). > > Okay, I won't

Re: RFR: 8281658: Add a security category to the java -XshowSettings option [v3]

On Thu, 15 Jun 2023 06:29:09 GMT, Alan Bateman wrote: >> Sean Coffey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Incorporate review comments from Roger and tweak some code > >

Re: RFR: 8281658: Add a security category to the java -XshowSettings option [v3]

On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information >> about JDK security configuration > > Sean Coffey has updated the pull request incrementally with one additional > commit since the last revision: > >

Re: RFR: 8308780: Fix the Java Integer types on Windows [v4]

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters wrote: >> On Windows, the basic Java Integer types are defined as long and __int64 >> respectively. In particular, the former is rather problematic since it >> breaks compilation as the Visual C++ becomes stricter and more compliant >> with every