On Wed, 15 Jan 2025 14:14:37 GMT, Richard Reingruber wrote:
> This PR reverts the fix from
> [JDK-8339166](https://bugs.openjdk.org/browse/JDK-8339166) because it
> increases the runtime of the test a lot.
> Instead a full gc is requested via the whitebox api. This solves the issues
> (see bug
On Mon, 20 Jan 2025 19:34:53 GMT, Thomas Stuefe wrote:
>> In ProcessImpl_md.c, we have adopted the Posix APIs and semantics for
>> process handling.
>> I suggest removing the "unofficial" link, it does not include useful
>> information at this point and is fragile.
>>
>> The current behavior a
On Mon, 20 Jan 2025 17:28:40 GMT, Raffaello Giulietti
wrote:
>> Shaojin Wen 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 29 additional
>> co
On Thu, 16 Jan 2025 18:37:36 GMT, Tom Rodriguez wrote:
>> Deoptimization with escape analysis can fail when trying to rematerialize
>> objects as described in JDK-8227309. In this test this can happen in Xcomp
>> mode in the framework of the test resulting in a test failure. Making the
>> nu
On Mon, 28 Oct 2024 18:45:59 GMT, Tom Rodriguez wrote:
> Deoptimization with escape analysis can fail when trying to rematerialize
> objects as described in JDK-8227309. In this test this can happen in Xcomp
> mode in the framework of the test resulting in a test failure. Making the
> number
On Mon, 20 Jan 2025 17:01:10 GMT, Daniel Fuchs wrote:
> > > The problem is, that such IBM links do not work very long. In one or a
> > > view years this link again might point to nirvana.
> >
> >
> > Should we remove it instead then?
>
> I would be OK with just dropping the link.
I would kee
On Mon, 20 Jan 2025 19:34:53 GMT, Thomas Stuefe wrote:
>> In ProcessImpl_md.c, we have adopted the Posix APIs and semantics for
>> process handling.
>> I suggest removing the "unofficial" link, it does not include useful
>> information at this point and is fragile.
>>
>> The current behavior a
On Mon, 20 Jan 2025 17:13:19 GMT, Roger Riggs wrote:
> In ProcessImpl_md.c, we have adopted the Posix APIs and semantics for process
> handling. I suggest removing the "unofficial" link, it does not include
> useful information at this point and is fragile.
>
> The current behavior always sett
On Mon, 20 Jan 2025 17:37:19 GMT, Alan Bateman wrote:
> Note that the long standing recommendation has always been to cache/reuse
> direct buffers rather than discard like the reproducer does
The reproducer is likely overly simplistic. The performance problem we are
solving is non-parallelism
> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
> implementation. That implementation carries a doubly-linked list, and so
> makes DBB suffer from the same issue fixed for generic
> `java.lang.ref.Cleaner` users with
> [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704
On Mon, 20 Jan 2025 18:39:06 GMT, Jorn Vernee wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> whitespace :scream:
>
> test/jdk/java/foreign/CallBufferCacheTest.java line 95:
>
>> 93: assertTrue(CallBuffe
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Mon, 20 Jan 2025 18:33:55 GMT, Jorn Vernee wrote:
>> test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadByValue.java line
>> 54:
>>
>>> 52: @State(org.openjdk.jmh.annotations.Scope.Thread)
>>> 53: @OutputTimeUnit(TimeUnit.NANOSECONDS)
>>> 54: @Fork(value = 1, jvmArgs = {"--enable-nat
On Mon, 20 Jan 2025 18:13:53 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Thu, 19 Dec 2024 19:16:55 GMT, Erik Gahlin wrote:
>> I'm not sure if one or two events are most suitable. If possible, I would
>> like to discuss it with Markus to get some more input. He will back in
>> January.
>
> Regarding one or two events. I'm fine with integrating as-is and then revis
On Mon, 20 Jan 2025 18:32:55 GMT, Jorn Vernee wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> whitespace :scream:
>
> test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadByValue.java line
> 54:
>
>> 52:
On Mon, 20 Jan 2025 18:13:53 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Mon, 20 Jan 2025 18:15:11 GMT, Jorn Vernee wrote:
>> That was my original version, but this proved to be faster (albeit very
>> little, O(.5ns)). I can't really explain why, that's above my paygrade, but
>> one thing that comes to mind when storing references is that there's might
>> be a G
On Mon, 20 Jan 2025 18:09:56 GMT, Matthias Ernst wrote:
> Footprint reduction would be 8 bytes * #carrier threads, and with scalar
> replacement, ofAddress should become a noop, right?
Yes.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922741985
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Mon, 20 Jan 2025 17:27:40 GMT, Jorn Vernee wrote:
>> Matthias Ernst has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - shift api boundary
>> - move bench
>> - revert formatting
>
> src/java.base/share/classes/jdk/internal/foreign/a
On Mon, 20 Jan 2025 17:34:45 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/jdk/internal/foreign/abi/CallBufferCache.java
>> line 112:
>>
>>> 110:
>>> 111: @SuppressWarnings("restricted")
>>> 112: public static MemorySegment acquireOrAllocate(long requestedSize) {
>>
On Mon, 20 Jan 2025 16:48:49 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
On Mon, 20 Jan 2025 17:22:09 GMT, Jorn Vernee wrote:
>> Matthias Ernst has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - shift api boundary
>> - move bench
>> - revert formatting
>
> test/micro/org/openjdk/bench/java/lang/foreign/Cal
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Mon, 20 Jan 2025 16:48:49 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
On Mon, 20 Jan 2025 16:34:15 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Mon, 20 Jan 2025 17:33:01 GMT, Maurizio Cimadamore
wrote:
> An even higher-level alternative here would be for this method to return a
> custom arena, whose `close` implementation does the `release`. This way, no
> cleanup action is needed. The arena could use a slicing allocator on a
> pr
On Mon, 20 Jan 2025 14:32:22 GMT, Shaojin Wen wrote:
>> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
>> offset overflow issue has been fixed.
>>
>> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
>> reduce duplication.
>>
>> 2) HexDigi
On Mon, 20 Jan 2025 16:20:20 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Mon, 20 Jan 2025 16:20:20 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Mon, 20 Jan 2025 14:32:22 GMT, Shaojin Wen wrote:
>> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
>> offset overflow issue has been fixed.
>>
>> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
>> reduce duplication.
>>
>> 2) HexDigi
On Fri, 17 Jan 2025 18:38:25 GMT, Eirik Bjørsnøs wrote:
>> Please review this cleanup PR which updates a total of 12 links to external
>> documentation or references in `java.base` to use https instead of plain
>> text http.
>>
>> Links in `java.security` and `share/data/tzdata` are excluded f
On Mon, 20 Jan 2025 16:55:10 GMT, Magnus Ihse Bursie wrote:
> > The problem is, that such IBM links do not work very long. In one or a view
> > years this link again might point to nirvana.
>
> Should we remove it instead then?
I would be OK with just dropping the link.
-
PR Comm
On Mon, 20 Jan 2025 16:50:29 GMT, Joachim Kern wrote:
> The problem is, that such IBM links do not work very long. In one or a view
> years this link again might point to nirvana.
Should we remove it instead then?
-
PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2
On Fri, 17 Jan 2025 18:38:25 GMT, Eirik Bjørsnøs wrote:
>> Please review this cleanup PR which updates a total of 12 links to external
>> documentation or references in `java.base` to use https instead of plain
>> text http.
>>
>> Links in `java.security` and `share/data/tzdata` are excluded f
> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
> implementation. That implementation carries a doubly-linked list, and so
> makes DBB suffer from the same issue fixed for generic
> `java.lang.ref.Cleaner` users with
> [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704
On Mon, 20 Jan 2025 15:03:37 GMT, Maurizio Cimadamore
wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Implementation notes.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/CallBufferCache.java
> line 9
> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
> implementation. That implementation carries a doubly-linked list, and so
> makes DBB suffer from the same issue fixed for generic
> `java.lang.ref.Cleaner` users with
> [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704
On Fri, 15 Nov 2024 20:54:56 GMT, Aleksey Shipilev wrote:
> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
> implementation. That implementation carries a doubly-linked list, and so
> makes DBB suffer from the same issue fixed for generic
> `java.lang.ref.Cleaner` users with
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Mon, 20 Jan 2025 15:00:55 GMT, Maurizio Cimadamore
wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Implementation notes.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/CallBufferCache.java
> line 7
On Fri, 17 Jan 2025 18:38:25 GMT, Eirik Bjørsnøs wrote:
>> Please review this cleanup PR which updates a total of 12 links to external
>> documentation or references in `java.base` to use https instead of plain
>> text http.
>>
>> Links in `java.security` and `share/data/tzdata` are excluded f
On Fri, 17 Jan 2025 18:38:25 GMT, Eirik Bjørsnøs wrote:
>> Please review this cleanup PR which updates a total of 12 links to external
>> documentation or references in `java.base` to use https instead of plain
>> text http.
>>
>> Links in `java.security` and `share/data/tzdata` are excluded f
On Mon, 20 Jan 2025 14:06:33 GMT, Jorn Vernee wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Implementation notes.
>
> test/micro/org/openjdk/bench/java/lang/foreign/points/PointsAlloc.java line
> 81:
>
>> 79:
On Mon, 20 Jan 2025 15:00:14 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line
>> 396:
>>
>>> 394: long address = fromCache != 0 ? fromCache :
>>> CallBufferCache.allocate(bufferSize);
>>> 395: return new
>>> Bounded
On Mon, 20 Jan 2025 14:32:22 GMT, Shaojin Wen wrote:
>> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
>> offset overflow issue has been fixed.
>>
>> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
>> reduce duplication.
>>
>> 2) HexDigi
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Mon, 20 Jan 2025 14:32:22 GMT, Shaojin Wen wrote:
>> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
>> offset overflow issue has been fixed.
>>
>> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
>> reduce duplication.
>>
>> 2) HexDigi
On Sat, 18 Jan 2025 00:58:36 GMT, Shaojin Wen wrote:
>> Sorry, I was just reading the comment and not how DIGITS is initialized and
>> used.
>>
>> The _correct_ comment should be something like
>>
>> * 97 -> '9' | ('7' << 8) -> 0x3739
>>
>> so the `short` value was correct before, b
On Mon, 20 Jan 2025 07:56:49 GMT, Axel Boldt-Christmas
wrote:
> The proposed change here is the following:
> 1. Move the `vmdependencies` list head from the `Context` to the `CallSite`
> object
> 2. Remove the Context object and its corresponding cleaner
>
> (1.) fixes the crash. (2.) is bec
On Mon, 20 Jan 2025 13:43:35 GMT, Jorn Vernee wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Implementation notes.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line
> 396:
>
>> 394
On Mon, 20 Jan 2025 07:30:17 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
> offset overflow issue has been fixed.
>
> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
> reduce duplication.
>
> 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF
On Mon, 20 Jan 2025 07:30:17 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Mon, 20 Jan 2025 13:25:26 GMT, Viktor Klang wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users with
> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
> offset overflow issue has been fixed.
>
> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
> reduce duplication.
>
> 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF
On Fri, 17 Jan 2025 23:08:20 GMT, Vladimir Ivanov wrote:
> The synchronized scope was reduced from whole methods to sections that need
> hash map access control. The tier1 and jaxp tests are OK. The score of the
> specjvm2008:xml.transform improved a little bit. On the Xeon 8480+ reported
> sc
On Mon, 20 Jan 2025 12:12:36 GMT, Alan Bateman wrote:
>> Changes for [JEP draft: Structured Concurrency (Fifth
>> Preview)](https://openjdk.org/jeps/8340343). The JEP isn't on the technical
>> roadmap yet. The proposal is to re-preview the API with some changes,
>> specifically:
>>
>> - A
>>
On Fri, 15 Nov 2024 20:54:56 GMT, Aleksey Shipilev wrote:
> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
> implementation. That implementation carries a doubly-linked list, and so
> makes DBB suffer from the same issue fixed for generic
> `java.lang.ref.Cleaner` users with
DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
implementation. That implementation carries a doubly-linked list, and so makes
DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users
with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the
On Mon, 20 Jan 2025 11:43:13 GMT, Aviad Zer wrote:
>> This change extends the Math.min function to support multiple parameters,
>> improving its usability and code readability.
>>
>> Previously, finding the minimum value among multiple variables required
>> using nested Math.min calls or conve
On Mon, 20 Jan 2025 11:43:13 GMT, Aviad Zer wrote:
>> This change extends the Math.min function to support multiple parameters,
>> improving its usability and code readability.
>>
>> Previously, finding the minimum value among multiple variables required
>> using nested Math.min calls or conve
> Changes for [JEP draft: Structured Concurrency (Fifth
> Preview)](https://openjdk.org/jeps/8340343). The JEP isn't on the technical
> roadmap yet. The proposal is to re-preview the API with some changes,
> specifically:
>
> - A
> [StructuredTaskScope](https://download.java.net/java/early_acc
> Extend the support for optional dependences to allow for a service to be
> optional. The post-resolution consistency check specified by
> `Configuration.resolve` is relaxed to allow for the possibility that the
> service from a module in the module graph at compile-time but the module is
> no
On Mon, 20 Jan 2025 11:48:20 GMT, Martin Desruisseaux wrote:
>> Aviad Zer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update Math.java by adding extended max function
>
> Aren't `Math.min(values)` methods duplicating `Arrays.stream(v
On Mon, 20 Jan 2025 11:43:13 GMT, Aviad Zer wrote:
>> This change extends the Math.min function to support multiple parameters,
>> improving its usability and code readability.
>>
>> Previously, finding the minimum value among multiple variables required
>> using nested Math.min calls or conve
On Wed, 15 Jan 2025 14:26:32 GMT, Aviad Zer wrote:
> This change extends the Math.min function to support multiple parameters,
> improving its usability and code readability.
>
> Previously, finding the minimum value among multiple variables required using
> nested Math.min calls or converting
> This change extends the Math.min function to support multiple parameters,
> improving its usability and code readability.
>
> Previously, finding the minimum value among multiple variables required using
> nested Math.min calls or converting the variables into an array and iterating
> through
On Wed, 15 Jan 2025 14:26:32 GMT, Aviad Zer wrote:
> This change extends the Math.min function to support multiple parameters,
> improving its usability and code readability.
>
> Previously, finding the minimum value among multiple variables required using
> nested Math.min calls or converting
On Thu, 16 Jan 2025 13:46:16 GMT, Viktor Klang wrote:
> Removes ThreadPoolExecutor javadoc which mentions RuntimePermission.
Hello Viktor, this change looks fine to me. On a related note, the
`ForkJoinPool` class has this unused field:
static volatile RuntimePermission modifyThreadPermission;
On Mon, 20 Jan 2025 07:56:49 GMT, Axel Boldt-Christmas
wrote:
> The proposed change here is the following:
> 1. Move the `vmdependencies` list head from the `Context` to the `CallSite`
> object
> 2. Remove the Context object and its corresponding cleaner
>
> (1.) fixes the crash. (2.) is bec
On Fri, 17 Jan 2025 23:33:50 GMT, Justin Lu wrote:
>> Please review this PR and CSR which adds a method to _java.util.Currency_
>> which returns a stream of the available Currencies.
>>
>> The motivation can be found in the CSR.
>
> Justin Lu has updated the pull request incrementally with one
On Sat, 18 Jan 2025 00:58:36 GMT, Shaojin Wen wrote:
>> Sorry, I was just reading the comment and not how DIGITS is initialized and
>> used.
>>
>> The _correct_ comment should be something like
>>
>> * 97 -> '9' | ('7' << 8) -> 0x3739
>>
>> so the `short` value was correct before, b
On Wed, 15 Jan 2025 14:26:32 GMT, Aviad Zer wrote:
> This change extends the Math.min function to support multiple parameters,
> improving its usability and code readability.
>
> Previously, finding the minimum value among multiple variables required using
> nested Math.min calls or converting
On Fri, 17 Jan 2025 17:41:47 GMT, Galder Zamarreño wrote:
>> @galderz I ran some testing on our side, feel free to ping me in 1-2 days
>> for the results.
>
> @eme64 I've addressed all the comments. I've not run the `VectorReduction2`
> for the reasons explained in the previous comment. Happy t
The proposed change here is the following:
1. Move the `vmdependencies` list head from the `Context` to the `CallSite`
object
2. Remove the Context object and its corresponding cleaner
(1.) fixes the crash. (2.) is because without `vmdependencies` the Context and
its cleaner serves no purpose.
77 matches
Mail list logo
