On Tue, 2 Sep 2025 09:43:23 GMT, Amit Kumar wrote:
>> Originally Reported in OpenJ9, fix by @AditiS11 present here:
>> https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/32
>>
>> These test failure were reported in OpenJ9 (x86), I can't reproduce on my
>> system (s390x):
>>
>> java/for
On Thu, 28 Aug 2025 15:02:57 GMT, Darragh Clarke wrote:
>> Darragh Clarke has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 12 additional
>> commi
On Mon, 1 Sep 2025 19:22:50 GMT, Philippe Marschall wrote:
>> Use `JavaLangAccess::uncheckedNewStringNoRepl` in `MemorySegment::getString`
>> to avoid byte[] allocation in the String constructor.
>>
>> Fall back to the old code in the case of malformed input to get replacement
>> characters as
On Mon, 1 Sep 2025 05:31:43 GMT, Amit Kumar wrote:
> Originally Reported in OpenJ9, fix by @AditiS11 present here:
> https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/32
>
> These test failure were reported in OpenJ9 (x86), I can't reproduce on my
> system (s390x):
>
> java/foreign/Te
On Thu, 28 Aug 2025 13:24:30 GMT, Alan Bateman wrote:
>> Darragh Clarke has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 12 additional
>> commits
On Thu, 28 Aug 2025 08:51:14 GMT, Darragh Clarke wrote:
>> This PR aims to Panamize the Java Kqueue implementation, This is based on
>> the work that was previously shared in
>> https://github.com/openjdk/jdk/pull/22307 , The main change since then is
>> that this branch takes advantage of the
On Mon, 11 Aug 2025 11:33:19 GMT, Per Minborg wrote:
> ### Description
> This PR proposes to update the `ClassLoader` implementation to properly guard
> access to the provided `ByteBuffer` when defining a class using
> `defineClass(String, ByteBuffer, ...)`. Specifical
On Wed, 27 Aug 2025 06:49:39 GMT, Jaikiran Pai wrote:
> It would be good to run this change and the test in our CI once to be sure
> nothing unexpected fails.
Thanks for the heads up on CI. It passes tier1-3. Thanks for the reviews!
-
PR Comment: https://git.openjdk.org/jdk/pull/2
On Tue, 26 Aug 2025 16:04:56 GMT, Darragh Clarke wrote:
>> This PR aims to Panamize the Java Kqueue implementation, This is based on
>> the work that was previously shared in
>> https://github.com/openjdk/jdk/pull/22307 , The main change since then is
>> that this branch takes advantage of the
n is internal to the `ClassLoader` implementation and does
> not affect the public API.
> Improves the robustness and security of class loading from buffers.
>
> ### Testing
> Tier 1, 2, and 3 JDK tests pass on multiple platforms.
Per Minborg has updated the pull request with a new target b
On Wed, 18 Jun 2025 15:41:38 GMT, Per Minborg wrote:
> This PR proposes to release the underlying function if a stable function or
> collection has invoked its underlying supplier exhaustively so that it can be
> collected.
>
> This PR passes tier1, tier2, and tier3 test
On Wed, 13 Aug 2025 11:51:29 GMT, Per Minborg wrote:
>> This PR proposes to release the underlying function if a stable function or
>> collection has invoked its underlying supplier exhaustively so that it can
>> be collected.
>>
>> This PR passes tier1, tier2,
On Wed, 6 Aug 2025 16:22:30 GMT, Per Minborg wrote:
>> This PR builds on a concept John Rose told me about some time ago. Instead
>> of combining memory operations of various sizes, a single large and skewed
>> memory operation can be made to clean up the tail of remaining
On Thu, 22 May 2025 07:34:08 GMT, Per Minborg wrote:
> This PR builds on a concept John Rose told me about some time ago. Instead of
> combining memory operations of various sizes, a single large and skewed
> memory operation can be made to clean up the tail of remaining bytes.
>
On Wed, 20 Aug 2025 08:51:24 GMT, Per Minborg wrote:
>> This PR proposes to use overlapping memory areas in
>> `SegmentBulkOperations::copy`, similar to what is proposed for
>> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>>
>>
On Thu, 7 Aug 2025 10:05:42 GMT, Per Minborg wrote:
> This PR proposes to use overlapping memory areas in
> `SegmentBulkOperations::copy`, similar to what is proposed for
> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>
> This PR passes `tier1
On Wed, 20 Aug 2025 08:51:24 GMT, Per Minborg wrote:
>> This PR proposes to use overlapping memory areas in
>> `SegmentBulkOperations::copy`, similar to what is proposed for
>> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>>
>>
On Wed, 20 Aug 2025 08:51:24 GMT, Per Minborg wrote:
>> This PR proposes to use overlapping memory areas in
>> `SegmentBulkOperations::copy`, similar to what is proposed for
>> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>>
>>
> This PR proposes to use overlapping memory areas in
> `SegmentBulkOperations::copy`, similar to what is proposed for
> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>
> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
On Wed, 13 Aug 2025 14:18:42 GMT, Emanuel Peter wrote:
> > We have discussed the possibility of threads seeing different values, like
> > in the above example by @eme64. We think this is ok because there are no
> > guarantees of inter-thread visibility for memory segments. This has to be
> > p
On Wed, 13 Aug 2025 14:14:30 GMT, Per Minborg wrote:
>> This PR proposes to use overlapping memory areas in
>> `SegmentBulkOperations::copy`, similar to what is proposed for
>> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>>
>>
> This PR proposes to use overlapping memory areas in
> `SegmentBulkOperations::copy`, similar to what is proposed for
> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>
> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
On Wed, 13 Aug 2025 12:29:28 GMT, Emanuel Peter wrote:
>> Per Minborg has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 12 addi
> This PR proposes to release the underlying function if a stable function or
> collection has invoked its underlying supplier exhaustively so that it can be
> collected.
>
> This PR passes tier1, tier2, and tier3 testing on multiple platforms.
Per Minborg has updated t
On Wed, 13 Aug 2025 10:08:33 GMT, Per Minborg wrote:
>> This PR proposes to use overlapping memory areas in
>> `SegmentBulkOperations::copy`, similar to what is proposed for
>> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>>
>>
On Mon, 11 Aug 2025 16:31:17 GMT, Per Minborg wrote:
>> This PR proposes to use overlapping memory areas in
>> `SegmentBulkOperations::copy`, similar to what is proposed for
>> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>>
>>
> This PR proposes to use overlapping memory areas in
> `SegmentBulkOperations::copy`, similar to what is proposed for
> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>
> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
On Tue, 12 Aug 2025 13:23:32 GMT, Viktor Klang wrote:
>> The underlying function will be retained until all values are computed (non
>> exceptionally). It is as simple as that.
>>
>> I was not able to come up with something better than that, but I am open to
>> other suggestions.
>
> Would it
On Tue, 12 Aug 2025 09:09:17 GMT, Viktor Klang wrote:
>> No, because the stable value doesn’t get set in that case, so the
>> supplier/function will be called again.
>
> @ExE-Boss That seems to presume that 1) it will be called again, and 2) it
> will eventually produce a non-exception
The und
> This PR proposes to release the underlying function if a stable function or
> collection has invoked its underlying supplier exhaustively so that it can be
> collected.
>
> This PR passes tier1, tier2, and tier3 testing on multiple platforms.
Per Minborg has updated the pull
> This PR proposes to use overlapping memory areas in
> `SegmentBulkOperations::copy`, similar to what is proposed for
> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>
> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
> This PR proposes to use overlapping memory areas in
> `SegmentBulkOperations::copy`, similar to what is proposed for
> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>
> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
On Mon, 11 Aug 2025 11:33:19 GMT, Per Minborg wrote:
> ### Description
> This PR proposes to update the `ClassLoader` implementation to properly guard
> access to the provided `ByteBuffer` when defining a class using
> `defineClass(String, ByteBuffer, ...)`. Specifical
### Description
This PR proposes to update the `ClassLoader` implementation to properly guard
access to the provided `ByteBuffer` when defining a class using
`defineClass(String, ByteBuffer, ...)`. Specifically, calls to
`SharedSecrets.getJavaNioAccess().acquireSession(ByteBuffer)` and
`release
On Fri, 8 Aug 2025 13:25:27 GMT, Per Minborg wrote:
>> This PR proposes to use overlapping memory areas in
>> `SegmentBulkOperations::copy`, similar to what is proposed for
>> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>>
>>
On Fri, 8 Aug 2025 16:04:44 GMT, Roger Riggs wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright year
>
> src/java.base/share/classes/jdk/internal/foreign/AbstractMemo
> This PR proposes to use overlapping memory areas in
> `SegmentBulkOperations::copy`, similar to what is proposed for
> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>
> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
> This PR proposes to use overlapping memory areas in
> `SegmentBulkOperations::copy`, similar to what is proposed for
> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>
> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
On Fri, 8 Aug 2025 09:36:14 GMT, Per Minborg wrote:
>> This PR proposes to use overlapping memory areas in
>> `SegmentBulkOperations::copy`, similar to what is proposed for
>> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>>
>>
> This PR proposes to use overlapping memory areas in
> `SegmentBulkOperations::copy`, similar to what is proposed for
> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>
> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
On Sun, 3 Aug 2025 13:42:41 GMT, Tagir F. Valeev wrote:
>> Implementation of Comparator.min and Comparator.max methods. Preliminary
>> discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max an
On Thu, 7 Aug 2025 10:05:42 GMT, Per Minborg wrote:
> This PR proposes to use overlapping memory areas in
> `SegmentBulkOperations::copy`similar ', similar to what is proposed for
> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
https://github.com/us
On Thu, 7 Aug 2025 10:05:42 GMT, Per Minborg wrote:
> This PR proposes to use overlapping memory areas in
> `SegmentBulkOperations::copy`similar ', similar to what is proposed for
> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
Copy-overlap
Ba
This PR proposes to use overlapping memory areas in
`SegmentBulkOperations::copy`similar ', similar to what is proposed for
`SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
-
Commit messages:
- Add methods to ScopedMemoryAccess
- remove file
- Use overl
g the code. The number of
> branches to evaluate is reduced.
>
> It should be noted that the performance of the fill operation affects the
> allocation of new segments (as they are zeroed out before being returned to
> the client code).
>
> This PR passes tier1, tier2, a
On Mon, 28 Jul 2025 17:10:13 GMT, Philippe Marschall wrote:
>> Use `JavaLangAccess::uncheckedNewStringNoRepl` in `MemorySegment::getString`
>> to avoid byte[] allocation in the String constructor.
>>
>> Fall back to the old code in the case of malformed input to get replacement
>> characters a
On Mon, 4 Aug 2025 17:21:22 GMT, Per Minborg wrote:
> This PR proposes to update the `SharedSecrets` class in `jdk.internal.access`
> to annotate all but one static field with the `@Stable` annotation.
>
> The `@Stable` annotation was added to all static fields except for
> `ja
g the code. The number of
> branches to evaluate is reduced.
>
> It should be noted that the performance of the fill operation affects the
> allocation of new segments (as they are zeroed out before being returned to
> the client code).
>
> This PR passes tier1, tier2, a
g the code. The number of
> branches to evaluate is reduced.
>
> It should be noted that the performance of the fill operation affects the
> allocation of new segments (as they are zeroed out before being returned to
> the client code).
>
> This PR passes tier1, tier2, a
g the code. The number of
> branches to evaluate is reduced.
>
> It should be noted that the performance of the fill operation affects the
> allocation of new segments (as they are zeroed out before being returned to
> the client code).
>
> This PR passes tier1, tier2, a
On Tue, 5 Aug 2025 14:04:26 GMT, Per Minborg wrote:
>> This PR builds on a concept John Rose told me about some time ago. Instead
>> of combining memory operations of various sizes, a single large and skewed
>> memory operation can be made to clean up the tail of remaining
g the code. The number of
> branches to evaluate is reduced.
>
> It should be noted that the performance of the fill operation affects the
> allocation of new segments (as they are zeroed out before being returned to
> the client code).
>
> This PR passes tier1, tier2, a
g the code. The number of
> branches to evaluate is reduced.
>
> It should be noted that the performance of the fill operation affects the
> allocation of new segments (as they are zeroed out before being returned to
> the client code).
>
> This PR passes tier1, tier2, a
On Mon, 16 Jun 2025 16:58:09 GMT, Per Minborg wrote:
>> This PR proposes to improve the 'MemorySegment.getString(long offset,
>> Charset charset)` method documentation with respect to multi-octet concerns.
>
> Per Minborg has updated the pull request incrementally with tw
> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset
> charset)` method documentation with respect to multi-octet concerns.
Per Minborg has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes th
This PR proposes to update the `SharedSecrets` class in `jdk.internal.access`
to annotate all but one static field with the `@Stable` annotation.
The `@Stable` annotation was added to all static fields except for
`javaAWTFontAccess`, which remains unannotated. This is because it can be set
usin
On Mon, 28 Jul 2025 05:02:45 GMT, Shaojin Wen wrote:
> This optimization is not only needed within the JDK core library, but also by
> developers of basic class libraries and applications. This should be done by
> the C2 optimizer.
I suggest that we file a separate PR for C2 to fix all issues
On Tue, 10 Jun 2025 17:31:20 GMT, Per Minborg wrote:
>> This PR builds on a concept John Rose told me about some time ago. Instead
>> of combining memory operations of various sizes, a single large and skewed
>> memory operation can be made to clean up the tail of remaining
On Mon, 16 Jun 2025 16:58:09 GMT, Per Minborg wrote:
>> This PR proposes to improve the 'MemorySegment.getString(long offset,
>> Charset charset)` method documentation with respect to multi-octet concerns.
>
> Per Minborg has updated the pull request incrementally with tw
> This PR proposes to release the underlying function if a stable function or
> collection has invoked its underlying supplier exhaustively so that it can be
> collected.
>
> This PR passes tier1, tier2, and tier3 testing on multiple platforms.
Per Minborg has updated t
On Mon, 21 Jul 2025 06:54:46 GMT, Shaojin Wen wrote:
> I will integrate it in 24 hours, @minberg do you have any other questions?
No further comments from me. Please go ahead and integrate.
-
PR Comment: https://git.openjdk.org/jdk/pull/25437#issuecomment-3095820477
On Sat, 31 May 2025 02:07:40 GMT, Chen Liang wrote:
>> This PR aims to Panamize the Java Kqueue implementation, This is based on
>> the work that was previously shared in
>> https://github.com/openjdk/jdk/pull/22307 , The main change since then is
>> that this branch takes advantage of the cha
On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke wrote:
> This PR aims to Panamize the Java Kqueue implementation, This is based on the
> work that was previously shared in https://github.com/openjdk/jdk/pull/22307
> , The main change since then is that this branch takes advantage of the
> cha
On Thu, 3 Jul 2025 18:41:27 GMT, Chen Liang wrote:
>> Unsafe throws IAE for misusing static vs instance fields, and it's revealed
>> that AtomicXxxFieldUpdaters are using this mechanism to reject static
>> fields. This is not a good practice, but we can at least document this so we
>> don't ac
On Thu, 19 Jun 2025 11:01:28 GMT, ExE Boss wrote:
>> Per Minborg 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 addi
On Thu, 19 Jun 2025 09:59:41 GMT, Per Minborg wrote:
>> This PR proposes to release the underlying function if a stable function or
>> collection has invoked its underlying supplier exhaustively so that it can
>> be collected.
>>
>> This PR passes tier1, tier2,
> This PR proposes to release the underlying function if a stable function or
> collection has invoked its underlying supplier exhaustively so that it can be
> collected.
>
> This PR passes tier1, tier2, and tier3 testing on multiple platforms.
Per Minborg has updated the pull
On Thu, 19 Jun 2025 08:57:44 GMT, Viktor Klang wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix performance regression
>
> src/java.base/share/classes/jdk/internal/lang/stable/St
> This PR proposes to release the underlying function if a stable function or
> collection has invoked its underlying supplier exhaustively so that it can be
> collected.
>
> This PR passes tier1, tier2, and tier3 testing on multiple platforms.
Per Minborg has updated t
This PR proposes to release the underlying function if a stable function or
collection has invoked its underlying supplier exhaustively so that it can be
collected.
-
Commit messages:
- Clean up
- Fix bug
- Simplify
- Revert to records
- Make code more like the old one
- Add r
> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset
> charset)` method documentation with respect to multi-octet concerns.
Per Minborg has updated the pull request incrementally with two additional
commits since the last revision:
- Remove imp note
- Ad
> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset
> charset)` method documentation with respect to multi-octet concerns.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
Impr
> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset
> charset)` method documentation with respect to multi-octet concerns.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
Update src/java.base/sh
g the code. The number of
> branches to evaluate is reduced.
>
> It should be noted that the performance of the fill operation affects the
> allocation of new segments (as they are zeroed out before being returned to
> the client code).
>
> This PR passes tier1, tier2, a
On Tue, 10 Jun 2025 16:37:26 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use a fixed threashold for fill
>
> src/java.base/share/classes/jdk/internal/fore
On Tue, 10 Jun 2025 15:50:08 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update after comments
>
> src/java.base/share/classes/java/lang/foreig
> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset
> charset)` method documentation with respect to multi-octet concerns.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
Update aft
This PR proposes to improve the 'MemorySegment.getString(long offset, Charset
charset)` method documentation with respect to multi-octet concerns.
-
Commit messages:
- Add info for multi-octet Charsets
Changes: https://git.openjdk.org/jdk/pull/25715/files
Webrev: https://webrevs.
On Tue, 3 Jun 2025 20:14:31 GMT, Per Minborg wrote:
> This PR proposes to simplify lazy computation related to resource bundles.
> Previously, some objects were computed lazily using a double-checked locking
> algorithm. StableValues offers a more robust and succinct solution.
>
g the code. The number of
> branches to evaluate is reduced.
>
> It should be noted that the performance of the fill operation affects the
> allocation of new segments (as they are zeroed out before being returned to
> the client code).
>
> This PR passes tier1, tier2, a
This PR proposes to simplify lazy computation related to resource bundles.
Previously, some objects were computed lazily using a double-checked locking
algorithm. StableValues offers a more robust and succinct solution.
This PR passes tier1, tier2, and tier3 on multiple platforms.
-
On Thu, 5 Jun 2025 06:04:49 GMT, Volkan Yazici wrote:
>> Reverts certain [JDK-8353197](https://bugs.openjdk.org/browse/JDK-8353197)
>> (which implements JavaDoc improvement and precautionary naming for certain
>> unsafe methods in `jdk.internal.access.JavaLangAccess`) changes that are
>> found
On Thu, 5 Jun 2025 00:18:34 GMT, Chen Liang wrote:
>> Please review this PR which improves occurrences of lazy computation in
>> `Locale` and `BaseLocale`.
>>
>> Existing lazy initialization strategies such as CHM, static nested class,
>> and local inner class are replaced with Stable Values.
g the code. The number of
> branches to evaluate is reduced.
>
> It should be noted that the performance of the fill operation affects the
> allocation of new segments (as they are zeroed out before being returned to
> the client code).
>
> This PR passes tier1, tier2, a
On Fri, 30 May 2025 22:07:06 GMT, Shaojin Wen wrote:
>> Some static final arrays of BigInteger and BigDecimal are stable and
>> immutable. We should add `@Stable` to give the optimizer more information
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since
On Tue, 3 Jun 2025 09:10:04 GMT, Volkan Yazici wrote:
> > I wonder if we should add that implementations of the affected method
> > _shall_ do bounds checking to reduce the likelihood of a new/updated native
> > implementation miss that?
>
> @minborg, would you mind elaborating on this a bit,
On Mon, 2 Jun 2025 13:26:36 GMT, Aleksey Shipilev wrote:
>> SonarCloud complains that since
>> [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using
>> `Boolean` boxes in `ReverseOrderListView`. This change `boolean` ->
>> `Boolean` was made in
>> [JDK-8356080](https://bugs.
On Fri, 30 May 2025 22:07:06 GMT, Shaojin Wen wrote:
>> Some static final arrays of BigInteger and BigDecimal are stable and
>> immutable. We should add `@Stable` to give the optimizer more information
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since
On Thu, 29 May 2025 09:52:34 GMT, Andrew Haley wrote:
>> Per Minborg 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 contain
On Fri, 30 May 2025 11:57:39 GMT, Volkan Yazici wrote:
> Reverts certain [JDK-8353197](https://bugs.openjdk.org/browse/JDK-8353197)
> (which implements JavaDoc improvement and precautionary naming for certain
> unsafe methods in `jdk.internal.access.JavaLangAccess`) changes that are
> found to
On Fri, 30 May 2025 14:01:04 GMT, Roger Riggs wrote:
> Comment out assertions added in JDK-8351443 from
> AbstractStringBuilder.ensureCapacityNewCoder that increase the codesize,
> preventing some inlining, and reducing performance
>
>assert coder == newCoder || newCoder == UTF16 : "ba
On Sun, 25 May 2025 22:35:56 GMT, Shaojin Wen wrote:
> Some static final arrays of BigInteger and BigDecimal are stable and
> immutable. We should add `@Stable` to give the optimizer more information
src/java.base/share/classes/java/math/BigDecimal.java line 4317:
> 4315: };
> 4316:
> 431
On Wed, 28 May 2025 09:06:57 GMT, Per Minborg wrote:
> After https://bugs.openjdk.org/browse/JDK-8345687 was integrated, zero-length
> segments always have an address of zero. This may cause problems in certain
> native methods that can receive segments and/or buffers derived from
After https://bugs.openjdk.org/browse/JDK-8345687 was integrated, zero-length
segments always have an address of zero. This may cause problems in certain
native methods that can receive segments and/or buffers derived from segments.
This PR also guards for overflow for extremely large allocation
On Tue, 20 May 2025 07:37:34 GMT, Per Minborg wrote:
> This PR proposes to use ` JavaNioAccess::getBufferAdress` rather than
> `DirectBuffer::address` in the package `java.util.zip` so that `Buffer`
> instances backed by `MemorySegment` instances can be used.
>
> This PR pass
On Tue, 20 May 2025 07:37:34 GMT, Per Minborg wrote:
> This PR proposes to use ` JavaNioAccess::getBufferAdress` rather than
> `DirectBuffer::address` in the package `java.util.zip` so that `Buffer`
> instances backed by `MemorySegment` instances can be used.
>
> This PR pass
On Thu, 15 May 2025 09:49:10 GMT, Per Minborg wrote:
> This PR improves the robustness of tests on slow machines such as "zero"
> variants. The timeout was increased to 10 minutes for both tests. There are
> many combinations in `TestAccessModes`, so the test takes some tim
On Mon, 26 May 2025 15:06:02 GMT, Per Minborg wrote:
> > Can we remove all meaningless `!Architecture.isLittleEndian()` calls and
> > use the platform-specific endianness unsafe primitives instead? For
> > compensation, we can add a check in each of fill2/fill3/fill4 that
On Thu, 15 May 2025 09:49:10 GMT, Per Minborg wrote:
> This PR improves the robustness of tests on slow machines such as "zero"
> variants. The timeout was increased to 10 minutes for both tests. There are
> many combinations in `TestAccessModes`, so the test takes some tim
g the code. The number of
> branches to evaluate is reduced.
>
> It should be noted that the performance of the fill operation affects the
> allocation of new segments (as they are zeroed out before being returned to
> the client code).
>
> This PR passes tier1, tier2, a
1 - 100 of 1315 matches
Mail list logo
