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
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
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
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
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`.
-
> 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
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
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
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
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.
>>
>>
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-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
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
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
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
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
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.
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.
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.
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
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
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
> 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
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
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
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
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
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
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
>>
>
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:
>
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
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
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
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
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
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
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
37 matches
Mail list logo