Integrated: 8348324: The failure handler cannot be build by JDK 24 due to restricted warning

On Wed, 22 Jan 2025 21:59:40 GMT, Magnus Ihse Bursie wrote: > GatherProcessInfoTimeoutHandler calls System.loadLibrary, which will trigger > a `restricted` warning when building with JDK 24 or newer, and failing the > build. > > This should be fixed by adding a @SuppressWarnings("restricted").

Re: RFR: 8348324: The failure handler cannot be build by JDK 24 due to restricted warning

On Wed, 22 Jan 2025 21:59:40 GMT, Magnus Ihse Bursie wrote: > GatherProcessInfoTimeoutHandler calls System.loadLibrary, which will trigger > a `restricted` warning when building with JDK 24 or newer, and failing the > build. > > This should be fixed by adding a @SuppressWarnings("restricted").

Re: RFR: 8287788: Implement a better allocator for downcalls [v15]

> 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

RFR: 8348283: java.lang.classfile.components.snippets.PackageSnippets shipped in java.base.jmod

JDK-8345486 moved java.lang.classfile.components.snippet-files.PackageSnippets to jdk.internal.classfile.components.snippet-files folder. However change of the package name declared in the snippet file was omitted. Please review. Thank you, Adam - Commit messages: - 8348283: jav

RFR: 8348365: Bad format string in CLDRDisplayNamesTest

This change fixes an incorrect call to `printf` for a failure message in `CLDRDisplayNamesTest`. - Commit messages: - 8348365: Bad format string in CLDRDisplayNamesTest Changes: https://git.openjdk.org/jdk/pull/23252/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23252&ra

Proposal to extend Math.min and Math.max to support multiple parameters

Dear Core-Libs Dev Team, I hope this message finds you well. I would like to propose an enhancement to the Math class to extend the Math.min and Math.max methods to support multiple parameters using varargs. This enhancement aims to improve code readability and provide a more intuitive way to fin

Re: RFR: 8348324: The failure handler cannot be build by JDK 24 due to restricted warning

On Wed, 22 Jan 2025 21:59:40 GMT, Magnus Ihse Bursie wrote: > GatherProcessInfoTimeoutHandler calls System.loadLibrary, which will trigger > a `restricted` warning when building with JDK 24 or newer, and failing the > build. > > This should be fixed by adding a @SuppressWarnings("restricted").

Re: RFR: 8347965: (tz) Update Timezone Data to 2025a

On Tue, 21 Jan 2025 13:03:45 GMT, Johny Jose wrote: > Changes to Update Timezone Data to 2025a @johnyjose30 Your change (at version 20715329faf466ba6f7fb748f35fb2a4ff22c53e) is now ready to be sponsored by a Committer. - PR Comment: https://git.openjdk.org/jdk/pull/23212#issuecom

RFR: 8347955: TimeZone methods to stream the available timezone IDs

Please review this PR and CSR which add a pair of methods to _java.util.TimeZone_ that return a stream of the available IDs. See the CSR for the motivation. A number of existing tests are modified to use the new methods. See _test/jdk/java/util/TimeZone/AvailableIDsTest.java_ which tests the ne

Re: RFR: 8347949: Currency method to stream available Currencies [v5]

On Wed, 22 Jan 2025 18:37:32 GMT, Justin Lu wrote: >> I'm not sure how useful it is to optimize the performance of >> `availableCurrencies` access to "available", but adding volatile will slow >> every access down. >> The computation of the available currencies is stable, so a race computing >

Re: RFR: 8347949: Currency method to stream available Currencies [v7]

> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes

Re: RFR: 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class() [v2]

On Thu, 23 Jan 2025 01:04:05 GMT, Calvin Cheung wrote: >> Ioi Lam 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 three additional commits >> si

RFR: 8348348: Remove unnecessary #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c

Please review this trivial cleanup that removes the #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c. Thanks. - Commit messages: - 8348348: Remove unnecessary #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c Changes: https://git.openjdk.org/jdk/pull

Re: RFR: 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class() [v2]

> I reimplemented > `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java > code. This removes hacks in > `SystemDictionary::resolve_with_circularity_detection()` to facilitate future > clean-ups there that are planned by @coleenp. Please see the [JBS > issue](https://bugs.

Re: RFR: 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class()

On Wed, 22 Jan 2025 03:28:00 GMT, Ioi Lam wrote: > I reimplemented > `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java > code. This removes hacks in > `SystemDictionary::resolve_with_circularity_detection()` to facilitate future > clean-ups there that are planned by @c

Re: RFR: 8343609: Broken links in java.xml [v2]

On Thu, 23 Jan 2025 00:35:25 GMT, Joe Wang wrote: >> Fix broken links in java.xml: >> >> Catalog: contacted Oasis. The standard page >> (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF >> version. That is what I'm using now, replacing the html pages. Not ideal, >> but a

Re: RFR: 8343609: Broken links in java.xml [v3]

> Fix broken links in java.xml: > > Catalog: contacted Oasis. The standard page > (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF > version. That is what I'm using now, replacing the html pages. Not ideal, but > at least it's displayed within the browser rather than down

Re: RFR: 8343609: Broken links in java.xml [v2]

> Fix broken links in java.xml: > > Catalog: contacted Oasis. The standard page > (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF > version. That is what I'm using now, replacing the html pages. Not ideal, but > at least it's displayed within the browser rather than down

Re: RFR: 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class()

On Wed, 22 Jan 2025 03:28:00 GMT, Ioi Lam wrote: > I reimplemented > `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java > code. This removes hacks in > `SystemDictionary::resolve_with_circularity_detection()` to facilitate future > clean-ups there that are planned by @c

Re: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v8]

On Wed, 22 Jan 2025 17:50:52 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

Re: RFR: 8343609: Broken links in java.xml

On Wed, 22 Jan 2025 18:55:10 GMT, Joe Wang wrote: > Fix broken links in java.xml: > > Catalog: contacted Oasis. The standard page > (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF > version. That is what I'm using now, replacing the html pages. Not ideal, but > at leas

Re: RFR: 8343609: Broken links in java.xml

On Wed, 22 Jan 2025 18:55:10 GMT, Joe Wang wrote: > Fix broken links in java.xml: > > Catalog: contacted Oasis. The standard page > (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF > version. That is what I'm using now, replacing the html pages. Not ideal, but > at leas

RFR: 8348324: The failure handler cannot be build by JDK 24 due to restricted warning

GatherProcessInfoTimeoutHandler calls System.loadLibrary, which will trigger a `restricted` warning when building with JDK 24 or newer, and failing the build. This should be fixed by adding a @SuppressWarnings("restricted"). - Commit messages: - 8348324: The failure handler cannot

Re: New candidate JEP: 502: Stable Values (Preview)

The JEP describes StableValue as a step towards deferred immutability, defined as: "What we are missing is a way to promise that a field will be initialized by the time it is used, with a value that is computed at most once and, furthermore, safely with respect to concurrency. In other words, w

Re: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with Unable to deduce type of thread from address [v2]

On Wed, 22 Jan 2025 08:49:52 GMT, Matthias Baesken wrote: >> test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java line 104: >> >>> 102: if (!res) { // try once more >>> 103: launch(expectedMessage, Arrays.asList(toolArgs), false); >>> 104: } >> >> `launch()` should take

Re: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v8]

On Wed, 22 Jan 2025 17:50:52 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

Re: RFR: 8347123: Add missing @serial tags to other modules

On Wed, 22 Jan 2025 09:23:10 GMT, Hannes Wallnöfer wrote: >> src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java >> line 1288: >> >>> 1286: >>> 1287: /** >>> 1288: * Serializes this {@code DataFlavor}. >> >> This most definitely changes the serialisation spec. S

Re: RFR: 8287788: Implement a better allocator for downcalls [v13]

On Wed, 22 Jan 2025 15:01:03 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

Re: RFR: 8287788: Implement a better allocator for downcalls [v14]

On Wed, 22 Jan 2025 18:18:47 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

RFR: 8343609: Broken links in java.xml

Fix broken links in java.xml: Catalog: contacted Oasis. The standard page (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF version. That is what I'm using now, replacing the html pages. Not ideal, but at least it's displayed within the browser rather than downloaded as th

Re: RFR: 8347498: JDK 24 RDP2 L10n resource files update [v2]

On Wed, 22 Jan 2025 17:09:40 GMT, Severin Gehwolf wrote: >> Justin Lu has updated the pull request incrementally with one additional >> commit since the last revision: >> >> reflect jlink review > > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties > line 78: > >> 76

Re: RFR: 8347949: Currency method to stream available Currencies [v5]

On Wed, 22 Jan 2025 17:09:54 GMT, Roger Riggs wrote: >> Thanks Chen, made `available` volatile and implemented DCL in >> https://github.com/openjdk/jdk/pull/23165/commits/96e86c800f1d1af1c20bfee944c298f17b7e8860. >> Also added a duplicate elements test as you suggested. > > I'm not sure how usef

Re: RFR: 8347498: JDK 24 RDP2 L10n resource files update [v2]

> Please review this PR which contains the l10n translations for between RDP1 > and RDP2 for the JDK24 stabilization branch. > > Note that these translations are only associated with changes made to the > stabilization branch. This PR will not include any translations for changes > since RDP1,

Re: RFR: 8347498: JDK 24 RDP2 L10n resource files update [v2]

On Wed, 22 Jan 2025 18:34:46 GMT, Justin Lu wrote: >> Please review this PR which contains the l10n translations for between RDP1 >> and RDP2 for the JDK24 stabilization branch. >> >> Note that these translations are only associated with changes made to the >> stabilization branch. This PR wil

Re: RFR: 8287788: Implement a better allocator for downcalls [v14]

> 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

Re: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v8]

> 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

Re: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v7]

On Wed, 22 Jan 2025 17:23:53 GMT, Alan Bateman wrote: >> Aleksey Shipilev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove vestigial reference to waitForReferenceProcessing in tests > > src/java.base/share/classes/java/nio/Bits.jav

Re: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v7]

On Wed, 22 Jan 2025 15:58:14 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

Re: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v7]

On Wed, 22 Jan 2025 15:58:14 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

Re: RFR: 8347498: JDK 24 RDP2 L10n resource files update

On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote: > Please review this PR which contains the l10n translations for between RDP1 > and RDP2 for the JDK24 stabilization branch. > > Note that these translations are only associated with changes made to the > stabilization branch. This PR will not

Re: RFR: 8347949: Currency method to stream available Currencies [v5]

On Tue, 21 Jan 2025 18:44:39 GMT, Justin Lu wrote: >> src/java.base/share/classes/java/util/Currency.java line 469: >> >>> 467: >>> 468: // Initialize the set of available currencies if needed >>> 469: private static synchronized void initAvailableCurrencies() { >> >> Should we make `a

Re: RFR: 8347965: (tz) Update Timezone Data to 2025a

On Tue, 21 Jan 2025 13:03:45 GMT, Johny Jose wrote: > Changes to Update Timezone Data to 2025a LGTM - Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23212#pullrequestreview-2567779568

Re: RFR: 8287788: Implement a better allocator for downcalls. [v13]

On Wed, 22 Jan 2025 15:01:03 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

Re: RFR: 8345687: Improve the implementation of SegmentFactories::allocateSegment [v3]

On Mon, 16 Dec 2024 11:01:11 GMT, Maurizio Cimadamore wrote: >> Quan Anh Mai has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - wrong init >> - move segment instance creation to SegmentFactories > > test/micro/org/openjdk/bench/java/lan

Re: RFR: 8345687: Improve the implementation of SegmentFactories::allocateSegment [v4]

> Hi, > > This patch improves the performance of a typical `Arena::allocate` in several > ways: > > - Delay the creation of the NativeMemorySegmentImpl. This avoids the merge of > the instance with the one obtained from the call in the uncommon path, > increasing the chance the object being sc

Re: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v7]

> 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

New candidate JEP: 502: Stable Values (Preview)

https://openjdk.org/jeps/502 Summary: Introduce an API for stable values, which are objects that hold immutable data. Stable values are treated as constants by the JVM, enabling the same performance optimizations that are enabled by declaring a field final. Compared to final fields, howe

Re: RFR: 8341184: Clean up the interaction between the launcher native code and the LauncherHelper [v14]

> Can I please get a review of this change, which simplifies the interaction > between the `java` launcher's native code with the > `sun.launcher.LauncherHelper`? > > As noted in https://bugs.openjdk.org/browse/JDK-8341184, this proposed change > reduces the back and forth between the launcher

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v12]

> 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

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v11]

> 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

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9]

On Wed, 22 Jan 2025 12:36:17 GMT, Matthias Ernst wrote: >> On another note: in principle if a Frame is not the latest returned in a >> given thread, it is not safe to allow its allocation method (and probably >> close too) to succeed. Consider this case: >> >> >> Arena arenaOuter = bufferStac

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9]

On Wed, 22 Jan 2025 11:05:14 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line >> 38: >> >>> 36: @SuppressWarnings("restricted") >>> 37: public MemorySegment allocate(long byteSize, long >>> byteAlignment) { >>> 38:

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9]

On Wed, 22 Jan 2025 10:40:07 GMT, Maurizio Cimadamore wrote: >> Matthias Ernst has updated the pull request incrementally with one >> additional commit since the last revision: >> >> --unnecessary annotations > > src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 17:

Re: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v11]

On Mon, 16 Dec 2024 14:19:49 GMT, Jatin Bhateja wrote: >>> > Can you quickly summarize what tests you have, and what they test? >>> >>> Patch includes functional and performance tests, as per your suggestions IR >>> framework-based tests now cover various special cases for constant folding >>>

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v8]

On Wed, 22 Jan 2025 11:50:10 GMT, Jorn Vernee wrote: >> I'm told that TerminatingThreadLocal runs the "terminate" action for an >> object T from the same thread T refers to. So, in principle, using a >> TerminatingThreadLocal + confined arena should be ok. >> >> If that works, I'd suggest to c

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v10]

> 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

Re: [jdk24] RFR: 8347817: Timeouts running test/jdk/java/lang/String/concat/HiddenClassUnloading.java with fastdebug builds

On Wed, 22 Jan 2025 08:30:16 GMT, Richard Reingruber wrote: > Hi all, > > I would like to backport the test-fix from commit > [15d6469e](https://github.com/openjdk/jdk/commit/15d6469e8da635364c0ba83e425fd149c2d69495) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > The back

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v8]

On Wed, 22 Jan 2025 10:52:57 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line >> 389: >> >>> 387: @Override >>> 388: protected BufferStack initialValue() { >>> 389: return new BufferStack(Arena.ofAuto().al

[jdk24] Integrated: Merge 93ea8e708d5fc3dfe01de8d5b6d1061fef91b5d4

On Wed, 22 Jan 2025 11:22:53 GMT, Jaikiran Pai wrote: > This brings in CPU25_01 changes into jdk24 branch. This pull request has now been integrated. Changeset: 4ce95c95 Author:Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/4ce95c95efd1587003e91c9d18d94d5b3134aeac Stats: 1

Re: Integrated: Merge 5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7

On Wed, 22 Jan 2025 11:22:49 GMT, Jaikiran Pai wrote: > This brings in CPU25_01 changes into master branch. Marked as reviewed by dfuchs (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/23231#pullrequestreview-2566935776

Re: [jdk24] Integrated: Merge 93ea8e708d5fc3dfe01de8d5b6d1061fef91b5d4

On Wed, 22 Jan 2025 11:22:53 GMT, Jaikiran Pai wrote: > This brings in CPU25_01 changes into jdk24 branch. Marked as reviewed by dfuchs (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/23232#pullrequestreview-2566937917

Integrated: Merge 5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7

On Wed, 22 Jan 2025 11:22:49 GMT, Jaikiran Pai wrote: > This brings in CPU25_01 changes into master branch. This pull request has now been integrated. Changeset: 61873564 Author:Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/61873564a44d448feb2ae6e5dae93ab33a0aa719 Stats:

[jdk24] Integrated: Merge 93ea8e708d5fc3dfe01de8d5b6d1061fef91b5d4

This brings in CPU25_01 changes into jdk24 branch. - Commit messages: The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/23232/files Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod P

Integrated: Merge 5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7

This brings in CPU25_01 changes into master branch. - Commit messages: The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/23231/files Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9]

On Wed, 22 Jan 2025 10:43:27 GMT, Maurizio Cimadamore wrote: >> Matthias Ernst has updated the pull request incrementally with one >> additional commit since the last revision: >> >> --unnecessary annotations > > src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 38:

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v8]

On Wed, 22 Jan 2025 10:05:31 GMT, Matthias Ernst wrote: >> Matthias Ernst has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Back buffer allocation with a single carrier-local segment. > > src/java.base/share/classes/jdk/internal/foreign/ab

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9]

On Wed, 22 Jan 2025 10:12:13 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

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9]

On Wed, 22 Jan 2025 10:12:13 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

Re: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v8]

On Tue, 14 Jan 2025 04:08:28 GMT, Claes Redestad wrote: >> Shaojin Wen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix comment > > Always good to see some methods removed from `JavaLangAccess` - but it > appears these are already un

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9]

On Wed, 22 Jan 2025 10:12:13 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

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9]

On Wed, 22 Jan 2025 10:12:13 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

Re: ScopedValue API

Hello Peter, Thanks so much for the feedback. AFAIK, that work is delivered by the Loom crew and they use the `loom-dev` mailing list for discussions. I think they would really appreciate hearing your feedback: What is the real-world use case yo

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9]

On Wed, 22 Jan 2025 10:12:13 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

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9]

> 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

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v8]

On Wed, 22 Jan 2025 09:57: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

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v8]

On Wed, 22 Jan 2025 09:57: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

Re: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v8]

> 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

Re: RFR: 8347123: Add missing @serial tags to other modules

On Tue, 21 Jan 2025 19:41:39 GMT, Phil Race wrote: >> Please review a doc-only change to mostly add missing `@serial` javadoc >> tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the >> javadoc `-serialwarn` option in the JDK doc build, which has been disabled >> since JDK 19.

Re: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with Unable to deduce type of thread from address [v2]

> We were running into this error : > sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25 > > stderr: [java.lang.RuntimeException: Unable to deduce type of thread from > address 0x34144e30 (expected type JavaThread, CompilerThread, > MonitorDeflationThread, AttachL

Re: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v6]

On Tue, 21 Jan 2025 14:31:33 GMT, Aleksey Shipilev wrote: > No stress test failures so far... I ran a large matrix of `DirectBufferAllocTest` configs on my 5950X overnight, and it did not fail once. Several GHA re-runs also came back clean. This gives me confidence current version works well.

Re: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with Unable to deduce type of thread from address

On Tue, 21 Jan 2025 19:06:40 GMT, Chris Plummer wrote: > launch() should take an allowRetry argument and only retry if true. Are you talking about `public static void launch(String expectedMessage, String... toolArgs)` ? - PR Review Comment: https://git.openjdk.org/jdk/pull/2321

[jdk24] RFR: 8347817: Timeouts running test/jdk/java/lang/String/concat/HiddenClassUnloading.java with fastdebug builds

Hi all, I would like to backport the test-fix from commit [15d6469e](https://github.com/openjdk/jdk/commit/15d6469e8da635364c0ba83e425fd149c2d69495) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The backport will help prevent frequent tier1 test timeouts in our CI testing. Th

Re: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v11]

On Mon, 16 Dec 2024 14:19:49 GMT, Jatin Bhateja wrote: >>> > Can you quickly summarize what tests you have, and what they test? >>> >>> Patch includes functional and performance tests, as per your suggestions IR >>> framework-based tests now cover various special cases for constant folding >>>