Re: RFR: 8358768: [vectorapi] Make VectorOperators.SUADD an Associative [v2]

2025-07-10 Thread Xiaohong Gong
On Wed, 9 Jul 2025 22:52:58 GMT, Ian Graves wrote: >> Adding SUADD an associative operation in the Vector API. Saturated addition >> on fixed-width unsigned integers is provably associative. > > Ian Graves has updated the pull request incrementally with one additional > commit since the last re

RFR: 8361533: Apply java.io.Serial annotations in java.logging

2025-07-10 Thread Sergey Bylokhov
Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.logging module to enable stricter compile-time checking of serialization-related declarations. Only one class remains to be covered; all other relevant fie

Re: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3]

2025-07-10 Thread Xiaohong Gong
On Fri, 4 Jul 2025 09:11:40 GMT, Andrew Haley wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Refine the comment in ad file > > This looks good. Thanks. Hi @theRealAph , would you mind taking another look at the

Re: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v4]

2025-07-10 Thread Xiaohong Gong
On Thu, 10 Jul 2025 01:40:06 GMT, Xiaohong Gong wrote: >> Thanks for making the changes. Looks good to me. > >> Thanks for making the changes. Looks good to me. > > Thanks a lot for your review! > @XiaohongGong The code changes look sane, although, for the record, I'm not > that familiar with

RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms

2025-07-10 Thread Chen Liang
On 32 bit platforms, when an access to long/double is aligned, it is supported but not atomic. The original wording in `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at all. We can fix that by borrowing the improved specification from `MemoryLayout::varHandle`. -

Re: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled [v5]

2025-07-10 Thread Brian Burkhalter
> Changes to address `File.listFiles` invoked on an empty path. This fixes an > oversight in #22821. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8361587: Modify mkdirs() testing - Changes: - all: https://git.o

RFR: 8361909: ConstantPoolBuilder::loadableConstantEntry and constantValueEntry should throw NPE

2025-07-10 Thread Chen Liang
Currently, the aforementioned two methods do not throw NPE upon null input, but throw IAE. This behavior is bad for composition: `bsmEntry` actually throws IAE for nested null in the argument list/array, and other APIs are similarly affected. Given this domino effect, I think the best way is to

RFR: 8361908: Mix and match of dead and valid exception handler leads to malformed class file

2025-07-10 Thread Chen Liang
Noticed this error when I was verifying all sizes are u2 compatible and verified with a test that fails on mainline with ConstantPoolException (because we write a size of 2 with 1-length list content) and works in this patch. Problem wasn't discovered before because we use the `handlersSize < h

Re: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2]

2025-07-10 Thread Alexander Matveev
On Tue, 8 Jul 2025 00:15:29 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request with a new target base 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 >> c

Re: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v3]

2025-07-10 Thread Alexander Matveev
On Thu, 10 Jul 2025 21:44:32 GMT, Alexander Matveev wrote: >> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge >> conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so >> it is like new fix. >> >>

Re: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v3]

2025-07-10 Thread Alexander Matveev
On Tue, 8 Jul 2025 01:13:20 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] > > src/jdk.jpackage/macosx/classes/jdk

Re: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v3]

2025-07-10 Thread Alexander Matveev
> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge > conflict was resolved. Old PR will be closed. > > All comments are addressed from old PR. Merge conflict was significant, so it > is like new fix. > > Fixed jpackage to produce valid Java runtimes based on description be

Re: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms

2025-07-10 Thread Joe Darcy
On Thu, 10 Jul 2025 14:31:02 GMT, Mohamed Issa wrote: > > What is the accuracy of the algorithm in ulps (units the last place)? > > The java.lang.Math specification has max error and various other accuracy > > requirements any implementation must meet. > > 0.51 ulps Please add that as a commen

RFR: 8361635: Missing List length validation in the Class-File API

2025-07-10 Thread Chen Liang
The `class` file format often only stores lists up to 65535 in size because size is encoded as a u2. Currently, we truncate the list size and write all contents, creating malformed `class` files. Almost all scenarios where such oversized lists are created can be considered an error; we should ea

Re: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics

2025-07-10 Thread John R Rose
On Thu, 26 Jun 2025 10:48:37 GMT, Volkan Yazici wrote: > Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve > their documentation, enhance the checks in the associated C++ methods, and > adapt them to cause VM crash on invalid input. > > ## Implementation notes > > Th

Re: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v4]

2025-07-10 Thread Daniel Lundén
On Wed, 9 Jul 2025 01:23:43 GMT, Xiaohong Gong wrote: >> ### Background >> On AArch64, the minimum vector length supported is 64-bit for basic types, >> except for `byte` and `boolean` (32-bit and 16-bit respectively to match >> special Vector API features). This limitation prevents intrinsific

Re: RFR: 8077587: BigInteger Roots [v15]

2025-07-10 Thread fabioromano1
On Thu, 10 Jul 2025 15:21:10 GMT, Raffaello Giulietti wrote: >> @rgiulietti Regarding the tests for _n_-th root, the tests for `sqrt()` >> could be extended in order to test also `nthRoot()`. > > @fabioromano1 IIUC, the bulk of the code in the PR is aimed at finding a good > starting estimate.

Re: RFR: 8361717: Refactor Collections.emptyList() in Locale related classes

2025-07-10 Thread Naoto Sato
On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote: > Replaced Collections.emptyList() with List.of() as part of refactoring. This > was discussed in the context of investigating a CDS-related issue > (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.

Integrated: 8361717: Refactor Collections.emptyList() in Locale related classes

2025-07-10 Thread Naoto Sato
On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote: > Replaced Collections.emptyList() with List.of() as part of refactoring. This > was discussed in the context of investigating a CDS-related issue > (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.

Re: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled [v4]

2025-07-10 Thread Alan Bateman
On Thu, 10 Jul 2025 15:26:20 GMT, Brian Burkhalter wrote: >> Changes to address `File.listFiles` invoked on an empty path. This fixes an >> oversight in #22821. > > Brian Burkhalter has updated the pull request incrementally with two > additional commits since the last revision: > > - 8361587

Re: RFR: 8361497: Scoped Values: orElse and orElseThrow do not access the cache

2025-07-10 Thread Alan Bateman
On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley wrote: > Neither `ScopedValue.orElse` nor `ScopedValue.orElseThrow` consult the cache > when searching for a binding. Neither do they update the cache when a binding > is found. > While this issue does not affect spec compliance, it is surprising to

Re: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled [v3]

2025-07-10 Thread Brian Burkhalter
On Thu, 10 Jul 2025 14:18:31 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8361587: Expand test coverage of File methods > > test/jdk/java/io/File/EmptyPath.java line 112: > >> 110: @Te

Re: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled [v4]

2025-07-10 Thread Brian Burkhalter
> Changes to address `File.listFiles` invoked on an empty path. This fixes an > oversight in #22821. Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision: - 8361587: Fix omission in previous commit - 8361587: Address reviewer comments

Re: RFR: 8077587: BigInteger Roots [v15]

2025-07-10 Thread Raffaello Giulietti
On Sat, 17 May 2025 11:25:58 GMT, fabioromano1 wrote: >> The [Rampdown Phase One](https://openjdk.org/projects/jdk/25/) for JDK 25 is >> about 3 weeks from now. >> >> I think it's a bit too late for API additions to be approved in due time. >> And even if we could rush this work for 25, it mak

Re: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms

2025-07-10 Thread Mohamed Issa
On Thu, 10 Jul 2025 04:52:01 GMT, Joe Darcy wrote: > What is the accuracy of the algorithm in ulps (units the last place)? > > The java.lang.Math specification has max error and various other accuracy > requirements any implementation must meet. 0.51 ulps - PR Comment: https://gi

Re: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled [v3]

2025-07-10 Thread Alan Bateman
On Wed, 9 Jul 2025 21:57:56 GMT, Brian Burkhalter wrote: >> Changes to address `File.listFiles` invoked on an empty path. This fixes an >> oversight in #22821. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit since the last revision: > > 8361587: E

Re: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics

2025-07-10 Thread Chen Liang
On Fri, 27 Jun 2025 07:22:48 GMT, Tobias Hartmann wrote: >> src/java.base/share/classes/java/lang/StringCoding.java line 93: >> >>> 91: public static int countPositives(byte[] ba, int off, int len) { >>> 92: Objects.requireNonNull(ba, "ba"); >>> 93: Objects.checkFromIndexSize

Re: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics

2025-07-10 Thread Volkan Yazici
On Thu, 26 Jun 2025 10:48:37 GMT, Volkan Yazici wrote: > Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve > their documentation, enhance the checks in the associated C++ methods, and > adapt them to cause VM crash on invalid input. > > ## Implementation notes > > Th

Re: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics

2025-07-10 Thread Tobias Hartmann
On Thu, 26 Jun 2025 17:26:02 GMT, Chen Liang wrote: >> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve >> their documentation, enhance the checks in the associated C++ methods, and >> adapt them to cause VM crash on invalid input. >> >> ## Implementation notes >> >

Re: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics

2025-07-10 Thread Volkan Yazici
On Fri, 27 Jun 2025 20:21:31 GMT, ExE Boss wrote: >> My point is this is a performance-sensitive API. We are using a known-slow >> check method `checkFromIndexSize` which may introduce a performance >> regression. > > Maybe use `jdk.internal.util.Preconditions` directly instead? > Suggestion: >

Re: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics

2025-07-10 Thread Volkan Yazici
On Fri, 27 Jun 2025 13:24:52 GMT, Chen Liang wrote: >> But the original code already checks for `len >= 0`, right? See >> `LibraryCallKit::inline_countPositives` -> `generate_string_range_check` -> >> `// Offset and count must not be negative` >> >> This PR is about moving the range checks fro

Re: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics

2025-07-10 Thread Volkan Yazici
On Fri, 4 Jul 2025 15:03:33 GMT, Volkan Yazici wrote: >> Maybe use `jdk.internal.util.Preconditions` directly instead? >> Suggestion: >> >> Preconditions.checkFromIndexSize(off, len, ba.length, null); > > @ExE-Boss, I consulted this internally and decided to stick to using public > APIs

RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics

2025-07-10 Thread Volkan Yazici
Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated C++ methods, and adapt them to cause VM crash on invalid input. ## Implementation notes The goal of the associated umbrella issue [JDK-8156534](https://bugs.ope

Re: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics

2025-07-10 Thread ExE Boss
On Fri, 27 Jun 2025 13:24:52 GMT, Chen Liang wrote: >> But the original code already checks for `len >= 0`, right? See >> `LibraryCallKit::inline_countPositives` -> `generate_string_range_check` -> >> `// Offset and count must not be negative` >> >> This PR is about moving the range checks fro

Re: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics

2025-07-10 Thread Chen Liang
On Thu, 26 Jun 2025 10:48:37 GMT, Volkan Yazici wrote: > Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve > their documentation, enhance the checks in the associated C++ methods, and > adapt them to cause VM crash on invalid input. > > ## Implementation notes > > Th

Re: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms

2025-07-10 Thread Florian Weimer
On Mon, 7 Jul 2025 23:53:14 GMT, Mohamed Issa wrote: > I'm not sure which libm version you're referring to. The only current sinh > benchmark I'm aware of is in MathBench.java, and the benchmarks in > SinhPerf.java didn't exist until now. Could you clarify? I didn't notice the code you ported

Re: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v2]

2025-07-10 Thread David Holmes
On Thu, 10 Jul 2025 03:12:27 GMT, Serguei Spitsyn wrote: >> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as >> a temporary backward compatibility flag under JDK-8192936 and was >> immediately marked as Deprecate. The fix is to obsolete this option in JDK >> 26 and