Re: RFR: 8339120: Use more fine-granular gcc unused warnings

On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie wrote: > Currently, we issue -Wno-unused for all files in gcc, which is a rather big > sledgehammer to get rid of some warnings that proliferate in a few areas of > the build. > > We should instead leave -Wunused turned on (as done by -Wall)

Re: RFR: 8338716: Re-visit "interrupt handling" in jdk.internal.loader.Resource

On Tue, 27 Aug 2024 21:57:16 GMT, Brent Christian wrote: > Vestiges of it remain in jdk.internal.loader.Resource.getBytes(), and should > be removed. Yes, but aside from cleanup, this also fixes a bug where it clears the interrupt status and doesn't restore it. Good to get this fixed. src/jav

Re: RFR: 8338526: Don't store abstract and interface Klasses in class metaspace [v3]

On Tue, 27 Aug 2024 17:27:19 GMT, Coleen Phillimore wrote: >> This change stores InstanceKlass for interface and abstract classes in the >> non-class metaspace, since class metaspace will have limits on number of >> classes that can be represented when Lilliput changes go in. Classes that >>

Re: RFR: 8339126: JNI exception pending in Inflater.c

On Tue, 27 Aug 2024 21:26:52 GMT, Justin Lu wrote: > This PR addresses the JNI pending exception in Inflater.c, under > `Java_java_util_zip_Inflater_initIDs`. Looks OK to me. - Marked as reviewed by vtewari (Committer). PR Review: https://git.openjdk.org/jdk/pull/20735#pullreques

Re: RFR: 8339120: Use more fine-granular gcc unused warnings

On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie wrote: > Currently, we issue -Wno-unused for all files in gcc, which is a rather big > sledgehammer to get rid of some warnings that proliferate in a few areas of > the build. > > We should instead leave -Wunused turned on (as done by -Wall)

RFR: 8339132: Make DirectCodeBuilder write through without allocating instruction objects

Make `DirectCodeBuilder` write instructions actually directly without allocating extra objects. This speed up a lot of simple Class-File building cases that never go through intermediate transforms. - Commit messages: - Moar fixes - More direct code builder Changes: https://git.o

Re: Namespace Prefix Issue in XML to XSL Transformation

Hi Hempushpa, What you describe appears to be this issue: JDK-8168664 . -Archie On Tue, Aug 27, 2024 at 12:29 AM Hempushpa Sahu wrote: > Problem Description : > > XSLT transformation creating unique namespace prefixes. > > > > Analysis & Observation

Re: RFR: 8339126: JNI exception pending in Inflater.c

On Tue, 27 Aug 2024 21:26:52 GMT, Justin Lu wrote: > This PR addresses the JNI pending exception in Inflater.c, under > `Java_java_util_zip_Inflater_initIDs`. Marked as reviewed by lancea (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/20735#pullrequestreview-2264674014

Re: RFR: 8338021: Support saturating vector operators in VectorAPI [v2]

On Thu, 15 Aug 2024 06:59:53 GMT, Jatin Bhateja wrote: >>> its usage in existing patch is limited to [type >>> comparison.](https://github.com/openjdk/jdk/pull/20507/files#diff-3559dcf23b719805be5fd06fd5c1851dbd8f53e47afe6d99cba13a3de0ebc6b2R1542) >> >> Ah, that makes sense to me. I took a clos

Re: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory [v2]

On Tue, 27 Aug 2024 20:45:50 GMT, David M. Lloyd wrote: >> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added >> support for functionality required to continue to support IIOP and custom >> serializers in light of additional module-based restrictions on reflection. >> It wa

Re: RFR: 8337279: Optimize format instant [v7]

> By removing the redundant code logic in > DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be > reduced and the performance can be improved. Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the

Re: RFR: 8338023: Support two vector selectFrom API [v5]

On 23 Aug 2024, at 15:33, Paul Sandoz wrote: > The float/double conversion bothers me, not suggesting we do something about > it here, noting down for any future conversation on shuffles. Yes, it’s a pain which is noticeable in the vector/shuffle conversions. In the worst case it adds dynamic re

Re: RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

On Tue, 27 Aug 2024 13:55:51 GMT, Magnus Ihse Bursie wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Also update build to link properly > > And the discussion whether the checks are made "dynamically" or "sta

Re: RFR: 8338694: x86_64 intrinsic for tanh using libm

On Tue, 27 Aug 2024 21:22:26 GMT, Srinivas Vamsi Parasa wrote: > > This PR doesn't include any additional tests. It is often appropriate to > > add more regression testing when introducing a new implementation of a > > method. > > Thank You Joe for the suggestion. Will add more tests. (This P

Re: RFR: 8339115: Rename TypeKind enum constants to follow code style

On Tue, 27 Aug 2024 22:15:17 GMT, Chen Liang wrote: > `TypeKind` enum constants are named in wrong code style; correct them before > finalization. > > Also improved `TypeKind` specification to talk about not mentioned > `returnType`, `void`, and subword types being erased to int (and how). See

Re: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong [v4]

On Tue, 23 Jul 2024 02:48:56 GMT, Shaojin Wen wrote: >> Currently, about 25% of the time spent by the Integer.parseInt and >> Long.parseLong methods is spent on the Character.digit method. >> >> The Character.digit method is common to all radixes. We can use a digit >> method optimized for Lat

RFR: 8339120: Use more fine-granular gcc unused warnings

Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnin

Re: RFR: 8339120: Use more fine-granular gcc unused warnings

On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie wrote: > Currently, we issue -Wno-unused for all files in gcc, which is a rather big > sledgehammer to get rid of some warnings that proliferate in a few areas of > the build. > > We should instead leave -Wunused turned on (as done by -Wall)

Re: RFR: 8338021: Support saturating vector operators in VectorAPI [v4]

On Mon, 19 Aug 2024 07:19:30 GMT, Jatin Bhateja wrote: >> Hi All, >> >> As per the discussion on panama-dev mailing list[1], patch adds the support >> following new vector operators. >> >> >> . SUADD : Saturating unsigned addition. >> . SADD: Saturating signed addition. >>

Re: RFR: 8338694: x86_64 intrinsic for tanh using libm

On Tue, 27 Aug 2024 10:54:11 GMT, Andrew Haley wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp line 437: >> >>> 435: __ mulpd(xmm1, xmm1); >>> 436: __ movdqu(xmm4, ExternalAddress(pv + 32), r11 /*rscratch*/); >>> 437: __ mulpd(xmm2, xmm1); >> >> I would encourage either you ad

RFR: 8339115: Rename TypeKind enum constants to follow code style

`TypeKind` enum constants are named in wrong code style; correct them before finalization. Also improved `TypeKind` specification to talk about not mentioned `returnType`, `void`, and subword types being erased to int (and how). See the associated CSR too. - Commit messages: - 83

Integrated: 8337832: Optimize datetime toString

On Sat, 27 Jul 2024 13:45:11 GMT, Shaojin Wen wrote: > Similar to PR #20321, this improves performance by providing a method that > passes in a StringBuilder to avoid unnecessary object allocation. This pull request has now been integrated. Changeset: 449ca2c3 Author:Shaojin Wen Committer

Re: RFR: 8337832: Optimize datetime toString

On Sat, 27 Jul 2024 13:45:11 GMT, Shaojin Wen wrote: > Similar to PR #20321, this improves performance by providing a method that > passes in a StringBuilder to avoid unnecessary object allocation. @wenshao Your change (at version 9d7cc54c449d4e12d0eb30c103e8aa3aaf206b6d) is now ready to be s

Re: RFR: 8325679: Optimize ArrayList subList sort [v4]

On Tue, 9 Jul 2024 18:53:44 GMT, Attila Szegedi wrote: >> Attila Szegedi has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove test > > Keep it open, please. @szegedi Hi Attila, sorry for the long delay on this. If you update the PR p

RFR: 8338716: Re-visit "interrupt handling" in jdk.internal.loader.Resource

The InterruptibleIO feature (which was only on Solaris) was removed some time ago. See [JDK-4385444](https://bugs.openjdk.org/browse/JDK-4385444). Vestiges of it remain in jdk.internal.loader.Resource.getBytes(), and should be removed. - Commit messages: - remove handling for defu

Re: RFR: 8338716: Re-visit "interrupt handling" in jdk.internal.loader.Resource

On Tue, 27 Aug 2024 21:57:16 GMT, Brent Christian wrote: > The InterruptibleIO feature (which was only on Solaris) was removed some time > ago. See [JDK-4385444](https://bugs.openjdk.org/browse/JDK-4385444). > > Vestiges of it remain in jdk.internal.loader.Resource.getBytes(), and should > be

RFR: 8339126: JNI exception pending in Inflater.c

This PR addresses the JNI pending exception in Inflater.c, under `Java_java_util_zip_Inflater_initIDs`. - Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/20735/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20735&range=00 Issue: https://bugs.openjdk.or

Re: RFR: 8338694: x86_64 intrinsic for tanh using libm

On Mon, 26 Aug 2024 15:47:13 GMT, Joe Darcy wrote: > This PR doesn't include any additional tests. It is often appropriate to add > more regression testing when introducing a new implementation of a method. Thank You Joe for the suggestion. Will add more tests. (This PR passes the tier-1 tanh

Re: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory [v2]

> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added > support for functionality required to continue to support IIOP and custom > serializers in light of additional module-based restrictions on reflection. > It was expected that these libraries would use `sun.misc.Unsafe` in

Re: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v2]

On Tue, 27 Aug 2024 19:49:01 GMT, Eirik Bjørsnøs wrote: > > The javadoc should be focused on the current JDK release, not the prior > > history of this Class > > Makes sense, let's focus on the current release. > > > ``` > > * @deprecated ZipError is deprecated and subject to removal in a > >

Re: RFR: 8338967: Improve performance for MemorySegment::fill [v5]

On Tue, 27 Aug 2024 10:38:46 GMT, Per Minborg wrote: >> The performance of the `MemorySegment::fil` can be improved by replacing the >> `checkAccess()` method call with calling `checkReadOnly()` instead (as the >> bounds of the segment itself do not need to be checked). >> >> Also, smaller seg

Re: RFR: 8338023: Support two vector selectFrom API [v6]

On Tue, 27 Aug 2024 09:58:44 GMT, Jatin Bhateja wrote: >> Hi All, >> >> As per the discussion on panama-dev mailing list[1], patch adds the support >> for following new two vector permutation APIs. >> >> >> Declaration:- >> Vector.selectFrom(Vector v1, Vector v2) >> >> >> Semantics:- >>

Re: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v2]

On Tue, 27 Aug 2024 17:24:42 GMT, Lance Andersen wrote: > The javadoc should be focused on the current JDK release, not the prior > history of this Class Makes sense, let's focus on the current release. > ``` > * @deprecated ZipError is deprecated and subject to removal in a > * future rele

Re: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v2]

On Tue, 27 Aug 2024 15:51:24 GMT, Eirik Bjørsnøs wrote: >> Please review this PR which suggests to deprecate the unused class >> `java.util.zip.ZipError` for removal. >> >> The class has been unsed by OpenJDK since the ZIP API was rewritten from >> native to Java in JDK 9. >> >> I opted to n

Re: RFR: 8338021: Support saturating vector operators in VectorAPI [v4]

On Mon, 19 Aug 2024 07:19:30 GMT, Jatin Bhateja wrote: >> Hi All, >> >> As per the discussion on panama-dev mailing list[1], patch adds the support >> following new vector operators. >> >> >> . SUADD : Saturating unsigned addition. >> . SADD: Saturating signed addition. >>

Re: RFR: 8338694: x86_64 intrinsic for tanh using libm

On 8/27/24 12:13, Jatin Bhateja wrote: Hi @vamsi-parasa , Kindly also add a JMH micro benchmark, I did a first run and see around 4% performance drop with attached micro on Sapphire Rapids. [test.txt](https://github.com/user-attachments/files/16761142/test.txt) If I had to guess, that's beca

Re: RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

On Tue, 27 Aug 2024 13:55:51 GMT, Magnus Ihse Bursie wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Also update build to link properly > > And the discussion whether the checks are made "dynamically" or "sta

Re: RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote: >> As a preparation for Hermetic Java, we need to have a way to look up during >> runtime if we are using a statically linked library or not. >> >> This change will be the first step needed towards compiling the object files >> only o

Re: RFR: 8338897: Small startup regression remains after JDK-8309622 and JDK-8331932 [v2]

On Mon, 26 Aug 2024 14:00:22 GMT, Claes Redestad wrote: >> #14404 caused some startup regressions, where the main cause of startup >> increase in that change was due the use of - and the not very optimized >> state of - runtime bootstrapped switches. This was remedied by a series of >> optimiz

Re: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v2]

On Tue, 27 Aug 2024 15:51:24 GMT, Eirik Bjørsnøs wrote: >> Please review this PR which suggests to deprecate the unused class >> `java.util.zip.ZipError` for removal. >> >> The class has been unsed by OpenJDK since the ZIP API was rewritten from >> native to Java in JDK 9. >> >> I opted to n

Re: RFR: 8338526: Don't store abstract and interface Klasses in class metaspace [v3]

> This change stores InstanceKlass for interface and abstract classes in the > non-class metaspace, since class metaspace will have limits on number of > classes that can be represented when Lilliput changes go in. Classes that > have no instances created for them don't require compressed class

Re: RFR: 8338526: Don't store abstract and interface Klasses in class metaspace [v3]

On Fri, 23 Aug 2024 06:13:29 GMT, Thomas Stuefe wrote: >> Coleen Phillimore has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now contains four commits: >> >> - With JDK-8338929 we don't need is_in_class_space(). >> - Merge branch 'master' int

Re: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long)

On Tue, 9 Jul 2024 12:07:37 GMT, Galder Zamarreño wrote: > This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in > order to help improve vectorization performance. > > Currently vectorization does not kick in for loops containing either of these > calls because of the fo

Re: New candidate JEP: 484: Class-File API

Question... would it be appropriate for this JEP to mention that support for older-than-current classfile versions is an explicit non-goal? Otherwise I think there could be many repeats of this discussion from the other day

Re: RFR: 8337832: Optimize datetime toString

On Sat, 27 Jul 2024 13:45:11 GMT, Shaojin Wen wrote: > Similar to PR #20321, this improves performance by providing a method that > passes in a StringBuilder to avoid unnecessary object allocation. LGTM. Thanks for the changes. - Marked as reviewed by naoto (Reviewer). PR Review:

Integrated: 8338489: Typo in MemorySegment doc

On Tue, 27 Aug 2024 10:42:08 GMT, Per Minborg wrote: > This trivial PR proposes to fix a typo in the `MemorySegment` docs. This pull request has now been integrated. Changeset: 2e96f159 Author:Per Minborg URL: https://git.openjdk.org/jdk/commit/2e96f159aaee782a627902c04dbd51daa3406a

Re: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v2]

On Tue, 27 Aug 2024 15:51:24 GMT, Eirik Bjørsnøs wrote: >> Please review this PR which suggests to deprecate the unused class >> `java.util.zip.ZipError` for removal. >> >> The class has been unsed by OpenJDK since the ZIP API was rewritten from >> native to Java in JDK 9. >> >> I opted to n

Re: RFR: 8338489: Typo in MemorySegment doc

On Tue, 27 Aug 2024 10:42:08 GMT, Per Minborg wrote: > This trivial PR proposes to fix a typo in the `MemorySegment` docs. Marked as reviewed by abdelhak-za...@github.com (no known OpenJDK username). - PR Review: https://git.openjdk.org/jdk/pull/20727#pullrequestreview-2263831754

Re: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v2]

> Please review this PR which suggests to deprecate the unused class > `java.util.zip.ZipError` for removal. > > The class has been unsed by OpenJDK since the ZIP API was rewritten from > native to Java in JDK 9. > > I opted to not explain the reason for the deprecation in detail, but instead

Re: RFR: 8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer [v3]

On Fri, 26 Jul 2024 22:32:40 GMT, Brian Burkhalter wrote: >> Add some verbiage stating that two buffered readers or input streams should >> not be used to read from the same reader or input stream, respectively. > > Brian Burkhalter has updated the pull request incrementally with one > addition

Re: RFR: 8338526: Don't store abstract and interface Klasses in class metaspace

On Mon, 26 Aug 2024 13:57:16 GMT, Coleen Phillimore wrote: > > I don't think the costs for two address comparisons matter, not with the > > comparatively few deallocations that happen (few hundreds or few thousand). > > If deallocate is hot, we are using metaspace wrong. > > MethodData does a

Integrated: 8338690: CompactNumberInstance.format incorrectly formats some numbers (few vs many)

On Thu, 22 Aug 2024 16:14:08 GMT, Naoto Sato wrote: > Fixing an issue wrt wrong plural suffix with compact format for some locales. > It was retrieving the suffix based on the value before the rounding, which > ended up in wrong plural expression. This pull request has now been integrated. Ch

Re: RFR: 8338690: CompactNumberInstance.format incorrectly formats some numbers (few vs many)

On Thu, 22 Aug 2024 16:14:08 GMT, Naoto Sato wrote: > Fixing an issue wrt wrong plural suffix with compact format for some locales. > It was retrieving the suffix based on the value before the rounding, which > ended up in wrong plural expression. Thanks for the reviews! - PR Com

Re: RFR: 8334714: Implement JEP 484: Class-File API [v3]

> Class-File API is leaving preview. > This is a removal of all `@PreviewFeature` annotations from Class-File API. > It also bumps all `@since` tags and removes > `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull re

Re: RFR: 8333446: Add tests for hierarchical container support [v5]

On Tue, 27 Aug 2024 14:24:18 GMT, Matthias Baesken wrote: > I added the PR to our internal build/test queue . Thanks, Matthias! - PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2312813813

Re: RFR: 8333446: Add tests for hierarchical container support [v5]

On Tue, 27 Aug 2024 14:12:40 GMT, Zdenek Zambersky wrote: > If I am not mistaken, new test requires, that testsuite is ran as superuser > (root). (Because it writes `/etc/systemd/system`, runs certain systemd > commands). Should test be skipped for non-root? Thanks! I can add that. FWIW, conta

Re: RFR: 8338731: MemoryLayout::offsetHandle can return a negative offset [v2]

> When working on startup improvements, I noticed that the method handle > returned by `MemoryLayout::offsetHandle` can overflow if the client calls the > handle with a base offset that is too big. > > In other similar situations, the layout API always fails with > `ArithmeticException` (see `M

Re: RFR: 8338931: ZipEntry.flag could be made internal to ZipOutputStream [v2]

> Please review this refactoring PR which moves the `ZipEntry.flag` field to > `ZipOutputStream.XEntry`. > > Moving this field will save four bytes from the `ZipEntry` object size and > also saves an unneccessary read in `ZipFile.getZipEntry`. > > Testing: > > This PR is a refactoring of exist

Integrated: 8338728: Misc issues in memory layout javadoc

On Wed, 21 Aug 2024 09:41:14 GMT, Maurizio Cimadamore wrote: > This PR fixes two minor issues in the `MemoryLayout` javadoc: > * the section describing dereference path talks about `P` and `P'` but then > only uses `P` in the code; > * the `ceilDiv` math on the `PathElement::sequenceElement(lon

Re: RFR: 8333446: Add tests for hierarchical container support [v5]

On Tue, 20 Aug 2024 17:34:46 GMT, Severin Gehwolf wrote: >> Please review this PR which adds test support for systemd slices so that >> bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be >> verified. The added test, `SystemdMemoryAwarenessTest` currently passes on >> c

Re: RFR: 8338489: Typo in MemorySegment doc

On Tue, 27 Aug 2024 10:42:08 GMT, Per Minborg wrote: > This trivial PR proposes to fix a typo in the `MemorySegment` docs. Marked as reviewed by iris (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/20727#pullrequestreview-2263509002

Re: RFR: 8333446: Add tests for hierarchical container support [v5]

On Tue, 20 Aug 2024 17:34:46 GMT, Severin Gehwolf wrote: >> Please review this PR which adds test support for systemd slices so that >> bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be >> verified. The added test, `SystemdMemoryAwarenessTest` currently passes on >> c

Re: RFR: 8338489: Typo in MemorySegment doc

On Tue, 27 Aug 2024 10:42:08 GMT, Per Minborg wrote: > This trivial PR proposes to fix a typo in the `MemorySegment` docs. lgtm - Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20727#pullrequestreview-2263488201

Re: RFR: 8338489: Typo in MemorySegment doc

On Tue, 27 Aug 2024 10:42:08 GMT, Per Minborg wrote: > This trivial PR proposes to fix a typo in the `MemorySegment` docs. Marked as reviewed by mcimadamore (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/20727#pullrequestreview-2263492007

Re: New candidate JEP: 484: Class-File API

Thank you! Adam From: Mark Reinhold Date: Tuesday, 27 August 2024 at 15:57 To: Adam Sotona Cc: core-libs-dev@openjdk.org , jdk-...@openjdk.org Subject: New candidate JEP: 484: Class-File API https://openjdk.org/jeps/484 Summary: Provide a standard API for parsing, generating, and transfo

Re: RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote: >> As a preparation for Hermetic Java, we need to have a way to look up during >> runtime if we are using a statically linked library or not. >> >> This change will be the first step needed towards compiling the object files >> only o

New candidate JEP: 484: Class-File API

https://openjdk.org/jeps/484 Summary: Provide a standard API for parsing, generating, and transforming Java class files. - Mark

Re: RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

On Mon, 26 Aug 2024 09:39:28 GMT, Magnus Ihse Bursie wrote: >> I understand the cost overhead experienced by any individual Java run may be >> lost in the noise, but it still impacts every single Java run just to save >> some time/resources for the handful of builders of statically linked VMs.

Integrated: 8338765: ScheduledThreadPoolExecutor struggles with extremely long delays

On Tue, 20 Aug 2024 18:52:23 GMT, Viktor Klang wrote: > Unfortunately there is no good, deterministic reproducer which can be used as > a regression test at this point in time. This pull request has now been integrated. Changeset: 414d23cb Author:Viktor Klang URL: https://git.openj

Re: RFR: 8338967: Improve performance for MemorySegment::fill [v4]

On Tue, 27 Aug 2024 09:47:20 GMT, Per Minborg wrote: >> As discussed offline, can't we use a stable array of functions or something >> like that which can be populated lazily? That way you can access the >> function you want in a single array access, and we could put all these >> helper method

Re: RFR: 8338765: ScheduledThreadPoolExecutor struggles with extremely long delays

On Tue, 27 Aug 2024 11:18:43 GMT, Andrey Turbanov wrote: >> Unfortunately there is no good, deterministic reproducer which can be used >> as a regression test at this point in time. > > There is now typo in interface name. `ScheuledThreadPoolExecutor` -> > `ScheduledThreadPoolExecutor` Thanks,

Re: RFR: 8338937: Optimize the string concatenation of ClassDesc [v2]

On Sun, 25 Aug 2024 21:41:11 GMT, Shaojin Wen wrote: >> Well, `Class​::descriptorString()` is referenced from the  >> `ReferenceClassDescImpl` creation code in `ConstantUtils`: >> https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/java.base/share/classes/jdk/internal

Re: RFR: 8338937: Optimize the string concatenation of ClassDesc [v2]

> The string concatenation of java.base module is implemented based on > StringBuilder, which will result in extra object allocation and slow > performance. We can solve this problem by using String.concat method and > StringConcatHelper to provide concat method. > > for example, > > * use "+

Re: RFR: 8338765: ScheuledThreadPoolExecutor struggles with extremely long delays

On Tue, 20 Aug 2024 18:52:23 GMT, Viktor Klang wrote: > Unfortunately there is no good, deterministic reproducer which can be used as > a regression test at this point in time. There is now typo in interface name. `ScheuledThreadPoolExecutor` -> `ScheduledThreadPoolExecutor` - PR

Re: RFR: 8338694: x86_64 intrinsic for tanh using libm

On Wed, 21 Aug 2024 00:25:03 GMT, Srinivas Vamsi Parasa wrote: > The goal of this PR is to implement an x86_64 intrinsic for > java.lang.Math.tanh() using libm > > Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup > -- | -- | -- | -- > MathBench.tanhDouble | 70900 | 95618 | 1.35x Hi @

Re: RFR: 8338694: x86_64 intrinsic for tanh using libm

On Tue, 27 Aug 2024 05:24:34 GMT, Jatin Bhateja wrote: >> The goal of this PR is to implement an x86_64 intrinsic for >> java.lang.Math.tanh() using libm >> >> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup >> -- | -- | -- | -- >> MathBench.tanhDouble | 70900 | 95618 | 1.35x > > src/

RFR: 8338489: Typo in MemorySegment doc

This trivial PR proposes to fix a typo in the `MemorySegment` docs. - Commit messages: - Fix typo in MemorySegment docs Changes: https://git.openjdk.org/jdk/pull/20727/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20727&range=00 Issue: https://bugs.openjdk.org/browse/JD

Re: RFR: 8338967: Improve performance for MemorySegment::fill [v5]

> The performance of the `MemorySegment::fil` can be improved by replacing the > `checkAccess()` method call with calling `checkReadOnly()` instead (as the > bounds of the segment itself do not need to be checked). > > Also, smaller segments can be handled directly by Java code rather than > tr

Re: RFR: 8338023: Support two vector selectFrom API [v5]

On Fri, 23 Aug 2024 22:29:46 GMT, Paul Sandoz wrote: > API changes look good. (Note at the moment we are not proposing to change how > shuffles works - as you point out the two vector `selectFrom` and `rearrange` > differ in the index representation.) > > IIUC if the more direct two-table inst

Re: RFR: 8338023: Support two vector selectFrom API [v6]

> Hi All, > > As per the discussion on panama-dev mailing list[1], patch adds the support > for following new two vector permutation APIs. > > > Declaration:- > Vector.selectFrom(Vector v1, Vector v2) > > > Semantics:- > Using index values stored in the lanes of "this" vector, assembl

Re: RFR: 8338967: Improve performance for MemorySegment::fill [v4]

On Mon, 26 Aug 2024 21:38:37 GMT, Maurizio Cimadamore wrote: >> Here is a benchmark that fills segments of various random sizes: >> >> >> >> @BenchmarkMode(Mode.AverageTime) >> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @Measurement(iterations = 10, time = 500, t

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v35]

> Please review this patch which adds a jlink mode to the JDK which doesn't > need the packaged modules being present. A.k.a run-time image based jlink. > Fundamentally this patch adds an option to use `jlink` even though your JDK > install might not come with the packaged modules (directory `jm

RFR: 8333843: Provide methods on MemorySegment to read strings with known lengths

This PR proposes to add a new overload to `MemorySegment::getString` whereby it is possible to pass in a known byte length of the content in a segment that should be converted to a String. This is useful in case one already knows the byte length and thereby does not need to scan for a null termi

Re: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile instance when dealing with unexpected Class-Path entry in manifest [v2]

On Mon, 26 Aug 2024 03:47:49 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the issue >> noted in https://bugs.openjdk.org/browse/JDK-8338445? >> >> The JDK internal class `jdk.internal.loader.URLClassPath` is used by >> classloader implementations i

Re: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile instance when dealing with unexpected Class-Path entry in manifest [v3]

> Can I please get a review of this change which proposes to fix the issue > noted in https://bugs.openjdk.org/browse/JDK-8338445? > > The JDK internal class `jdk.internal.loader.URLClassPath` is used by > classloader implementations in the JDK (for example by the > `java.net.URLClassLoader` an

Re: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile instance when dealing with unexpected Class-Path entry in manifest [v2]

On Tue, 27 Aug 2024 04:14:03 GMT, Jaikiran Pai wrote: > The current specification of this attribute at > https://docs.oracle.com/en/java/javase/21/docs/specs/jar/jar.html#class-path-attribute > is very extensive and I think very clear (and that's a good thing). However, > I think that page isn

Re: RFR: 8338765: ScheuledThreadPoolExecutor struggles with extremely long delays

On Tue, 20 Aug 2024 18:52:23 GMT, Viktor Klang wrote: > Unfortunately there is no good, deterministic reproducer which can be used as > a regression test at this point in time. Marked as reviewed by alanb (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/20653#pullrequestr

Re: RFR: 8338765: ScheuledThreadPoolExecutor struggles with extremely long delays

On Tue, 20 Aug 2024 18:52:23 GMT, Viktor Klang wrote: > Unfortunately there is no good, deterministic reproducer which can be used as > a regression test at this point in time. src/java.base/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java line 533: > 531: */ > 532:

Re: RFR: 8338765: ScheuledThreadPoolExecutor struggles with extremely long delays

On Wed, 21 Aug 2024 11:10:22 GMT, Alan Bateman wrote: >> Unfortunately there is no good, deterministic reproducer which can be used >> as a regression test at this point in time. > > src/java.base/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java > line 533: > >> 531: */

Re: RFR: 8338765: ScheuledThreadPoolExecutor struggles with extremely long delays

On Tue, 20 Aug 2024 18:52:23 GMT, Viktor Klang wrote: > Unfortunately there is no good, deterministic reproducer which can be used as > a regression test at this point in time. I think this is the most straightforward way to address. It doesn't need doc change -- there are other cases where b

Re: RFR: 8338765: ScheuledThreadPoolExecutor struggles with extremely long delays

On Thu, 22 Aug 2024 09:01:43 GMT, Viktor Klang wrote: > Possible duplicates: Yes, a long standing issue. Cap the value at 146 years seems fine, and avoids us needing to put in workarounds at use-sites. - PR Comment: https://git.openjdk.org/jdk/pull/20653#issuecomment-2304192165

RFR: 8338765: ScheuledThreadPoolExecutor struggles with extremely long delays

Unfortunately there is no good, deterministic reproducer which can be used as a regression test at this point in time. - Commit messages: - Addressing 8323703 by capping max STPE delay to 146 years Changes: https://git.openjdk.org/jdk/pull/20653/files Webrev: https://webrevs.open

Re: RFR: 8338765: ScheuledThreadPoolExecutor struggles with extremely long delays

On Tue, 20 Aug 2024 18:52:23 GMT, Viktor Klang wrote: > Unfortunately there is no good, deterministic reproducer which can be used as > a regression test at this point in time. @AlanBateman Do you think we could use the https://bugs.openjdk.org/browse/JDK-8338104 reproducer? 🤔 @DougLea Any t