Re: Reg: Proposal: Generalized Number.parseNumber(String) Method for Java

Hi Kevin and Joseph, Thank you both for your detailed insights. I really appreciate the perspective you’ve shared on the limitations of Number and the challenges in evolving it. I agree that modifying core classes may not be the ri

Re: RFR: 8352971: Increase maximum number of hold counts for ReentrantReadWriteLock

On Wed, 26 Mar 2025 16:19:16 GMT, Viktor Klang wrote: > I'm breaking this change out as a separate improvement, since it will not be > generally possible to adjust these limits on the j.u.c primitives since they > might already use a backing `long` to pack in information which needs to be > up

Re: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM [v6]

On Fri, 28 Mar 2025 21:02:21 GMT, Chris Plummer wrote: >> Calling ThreadGroupReference.groups() from an event handler can cause a >> deadlock. Details in first comment. Tested with :jdk_lang on all supported >> platforms and tier1, tier2, tier3, and tier5 svc testing. > > Chris Plummer has upda

Re: RFR: 8353118: Deprecate the use of `java.locale.useOldISOCodes` system property

On Fri, 28 Mar 2025 20:17:30 GMT, Naoto Sato wrote: > Proposing to remove the `java.locale.useOldISOCodes` system property. This > property is for backward compatibility introduced back in JDK17 and I believe > it is now fine to remove it. In this PR targeting JDK25, it emits a > deprecate-for

Re: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM [v6]

On Fri, 28 Mar 2025 21:02:21 GMT, Chris Plummer wrote: >> Calling ThreadGroupReference.groups() from an event handler can cause a >> deadlock. Details in first comment. Tested with :jdk_lang on all supported >> platforms and tier1, tier2, tier3, and tier5 svc testing. > > Chris Plummer has upda

Re: RFR: 8351233: [ASAN] avx2-emu-funcs.hpp:151:20: error: ‘D.82188’ is used uninitialized

On Thu, 6 Mar 2025 03:35:20 GMT, SendaoYan wrote: > Hi all, > > The return type of function `const __m256i &perm` is `__m256i`, so `const > __m256i &perm` should be replaced as 'const __m256i perm'. > > The function implementation in gcc/clang compiler header: > > 1. gcc: lib/gcc/x86_64-pc-li

Re: RFR: 8351233: [ASAN] avx2-emu-funcs.hpp:151:20: error: ‘D.82188’ is used uninitialized

On Thu, 6 Mar 2025 03:35:20 GMT, SendaoYan wrote: > Hi all, > > The return type of function `const __m256i &perm` is `__m256i`, so `const > __m256i &perm` should be replaced as 'const __m256i perm'. > > The function implementation in gcc/clang compiler header: > > 1. gcc: lib/gcc/x86_64-pc-li

Re: RFR: 8346230: [perf] scalability issue for the specjvm2008::xml.transform workload [v5]

> The HashMap for caching was deleted. Now it use only ThreadLocal variable > without synchronization. > According to the specjvm2008::xml.transform workload the performance for low > threads counts was not affected and improved for high threads counts. > For the 2 socket server based on Xeon 67

Re: RFR: 8346230: [perf] scalability issue for the specjvm2008::xml.transform workload [v4]

On Fri, 14 Mar 2025 01:28:34 GMT, Vladimir Ivanov wrote: >> The HashMap for caching was deleted. Now it use only ThreadLocal variable >> without synchronization. >> According to the specjvm2008::xml.transform workload the performance for low >> threads counts was not affected and improved for h

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

Hi Scott, ByteBuffer can wrap and write into a byte[] array, but it doesn't know how to grow a new, larger array if the original array runs out of room. Also, ByteBuffer.array() provides "public" access to the underlying bytes, so the only way to make them read-only is to copy. FWIW here's

Re: RFR: 8352536: Add overloads to parse and build class files from/to MemorySegment [v5]

On Thu, 27 Mar 2025 17:38:49 GMT, David M. Lloyd wrote: >> Provide method overloads to the ClassFile interface of the >> java.lang.classfile API which allow parsing of classes found in memory >> segments, as well as allowing built class files to be output to them. > > David M. Lloyd has updated

RFR: 8353118: Deprecate the use of `java.locale.useOldISOCodes` system property

Proposing to remove the `java.locale.useOldISOCodes` system property. This property is for backward compatibility introduced back in JDK17 and I believe it is now fine to remove it. In this PR targeting JDK25, it emits a deprecate-for-removal warning on startup if the system property is set to t

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

This is just a drive-by, opinion-saturated comment, so feel free to ignore... I think the missing puzzle piece here is slightly different/more general than "OutputStream into memory". IMHO what's really missing from the standard toolbox provided by the JDK is the byte equivalent of StringBuilder+S

Re: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM [v6]

> Calling ThreadGroupReference.groups() from an event handler can cause a > deadlock. Details in first comment. Tested with :jdk_lang on all supported > platforms and tier1, tier2, tier3, and tier5 svc testing. Chris Plummer has updated the pull request incrementally with one additional commit

Re: RFR: 8352971: Increase maximum number of hold counts for ReentrantReadWriteLock

On Fri, 28 Mar 2025 16:27:28 GMT, Roger Riggs wrote: >> I'm breaking this change out as a separate improvement, since it will not be >> generally possible to adjust these limits on the j.u.c primitives since they >> might already use a backing `long` to pack in information which needs to be >>

Re: RFR: 8341402: BigDecimal's square root optimization [v32]

> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed > up `BigDecimal.sqrt()` implementation. Here is how I made it. > > The main steps of the algorithm are as follows: > first argument reduce the value to an integer using the following relations: > > x = y * 10 ^ exp >

Reg: Proposal: Generalized Number.parseNumber(String) Method for Java

Dear Core-Libs Dev Team, *Note:* I have now subscribed to the mailing list and am resending this message as advised. I would like to propose an improvement to the JDK: a *generalized Number.parseNumber(String) method*. Motivation Java provides multiple number types (byte, short, int, long, etc.)

Re: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher ExecutionEnvironment.java for AIX and Linux/musl is brittle [v6]

> The test `testEcoFriendly()` checks if the launcher pollutes the > `LD_LIBRARY_PATH` environment variable. > Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not > make sense to make this test somehow passing with crude workarounds, which > even do not work in any case

Re: RFR: 8319447: Improve performance of delayed task handling [v15]

On Thu, 27 Mar 2025 23:20:56 GMT, Doug Lea wrote: >> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) >> >> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is >> both ill-suited for many (if not most) of its applications, and is a >> performance bottleneck (a

Re: RFR: 8352971: Increase maximum number of hold counts for ReentrantReadWriteLock

On Wed, 26 Mar 2025 16:19:16 GMT, Viktor Klang wrote: > I'm breaking this change out as a separate improvement, since it will not be > generally possible to adjust these limits on the j.u.c primitives since they > might already use a backing `long` to pack in information which needs to be > up

Integrated: 8352906: stdout/err.encoding on Windows set by incorrect Win32 call

On Wed, 26 Mar 2025 18:57:37 GMT, Naoto Sato wrote: > Those system property values on Windows were derived from Windows' > `GetConsoleCP()` call, but they should have been taken from > `GetConsoleOutputCP()`. Replacing the incorrect call with the correct one > won't change any behavior, as bot

Re: RFR: 8352906: stdout/err.encoding on Windows set by incorrect Win32 call [v3]

On Thu, 27 Mar 2025 16:03:08 GMT, Naoto Sato wrote: >> Those system property values on Windows were derived from Windows' >> `GetConsoleCP()` call, but they should have been taken from >> `GetConsoleOutputCP()`. Replacing the incorrect call with the correct one >> won't change any behavior, as

Re: RFR: 8351996: Behavioral updates for ClassValue::remove [v5]

On Fri, 21 Mar 2025 19:44:48 GMT, Chen Liang wrote: >> The recent patch #23866 makes calling `ClassValue::remove()` from >> `ClassValue::computeValue()` end up in infinite loops while fixing the stale >> value risk from the method. >> >> The proposed fix is to preserve the stale value risk fix

Re: RFR: 8352971: Increase maximum number of hold counts for ReentrantReadWriteLock

On Thu, 27 Mar 2025 11:30:11 GMT, Alan Bateman wrote: >> I'm breaking this change out as a separate improvement, since it will not be >> generally possible to adjust these limits on the j.u.c primitives since they >> might already use a backing `long` to pack in information which needs to be >

Re: RFR: 8352971: Increase maximum number of hold counts for ReentrantReadWriteLock

On Thu, 27 Mar 2025 11:30:11 GMT, Alan Bateman wrote: >> I'm breaking this change out as a separate improvement, since it will not be >> generally possible to adjust these limits on the j.u.c primitives since they >> might already use a backing `long` to pack in information which needs to be >

Re: RFR: 8352536: Add overloads to parse and build class files from/to MemorySegment [v5]

On Thu, 27 Mar 2025 17:38:49 GMT, David M. Lloyd wrote: >> Provide method overloads to the ClassFile interface of the >> java.lang.classfile API which allow parsing of classes found in memory >> segments, as well as allowing built class files to be output to them. > > David M. Lloyd has updated

Re: RFR: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

Hello, On Fri, Mar 28, 2025 at 12:56 AM Jason Zaugg wrote: > A GitHub code search reveals this idea is also pursued in [Eclipse JDT]( > https://github.com/eclipse-jdtls/eclipse-jdt-core-incubator/blob/e3fd9a0c74374951d4c91663a6fd52f16f6ee9c6/org.eclipse.jdt.core.javac/src/org/eclipse/jdt/interna

Re: RFR: 8352171: Arrays.hashCode for sub-range of byte array API addition

On Thu, 20 Mar 2025 21:50:59 GMT, Chen Liang wrote: >> Add the java.util.Arrays.hashCode(byte[], int start, int end). >> >> Hi team, I am new here, please give me some guidance. Thank you. > > src/java.base/share/classes/java/util/Arrays.java line 4454: > >> 4452: */ >> 4453: public st

Re: RFR: 8352689: Allow for hash sum overrides when linking from the run-time image [v3]

On Wed, 26 Mar 2025 17:09:06 GMT, Severin Gehwolf wrote: >> Please review this enhancement which adds a hidden `jlink` option >> `--sha-overrides` that can be used to provide alternative hash sums for >> files in an image. Please see the bug for use-cases as to why this is >> needed. This patc

Re: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v3]

On Wed, 26 Mar 2025 17:31:47 GMT, Aleksey Shipilev wrote: >> When jspawnhelper fails for whatever reason, but more prominently due to >> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report >> the errors into stdout, but not to the relevant `IOException`. So, if the >> ap

JDK-8352891 Performance improvements to ByteArrayOutputStream

Hi all! This message is to discuss the proposal for a public class that is faster/cheaper than ByteArrayOutputStream. Details are on the ticket [1] so I will only summarize here: - ByteArrayOutputStream is slower than the provided alternative, and wastes memory bandwidth and allocation. - The

Re: RFR: 8352536: Add overloads to parse and build class files from/to MemorySegment [v5]

On Thu, 27 Mar 2025 22:21:00 GMT, Adam Sotona wrote: > I have two problems with the numbers you measured: > > 1. The benchmarked transformation runs on pre-parsed class and does nothing, > so technically it measures mainly the memory copy process. > 2. In the discussions there were mentioned me

Re: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message [v3]

On Sun, 2 Mar 2025 06:55:09 GMT, He-Pin(kerr) wrote: >> Motivation: >> When a user passes a wrong parameter, the current implementation throws an >> IllegalArgumentException with an error message `null`, which is not helpful. >> >> Modification: >> Add detail error messages. >> >> Result: >> H

Re: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed with "RuntimeException: MyObject is not found in test output" [v4]

On Fri, 28 Mar 2025 01:08:42 GMT, Brent Christian wrote: >> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear >> up the intermittent failures: >> >> * run with `othervm`: this test blocks the (global) finalizer thread, and >> also requires the (global) finalizer threa

Re: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher ExecutionEnvironment.java for AIX and Linux/musl is brittle [v4]

On Fri, 28 Mar 2025 10:52:55 GMT, Christoph Langer wrote: > I think it is wrong to completely remove point 4. You should rather remove > the term "on Solaris". The thing itself is still tested in testNoSymLink(). Yes just remove Solaris not the whole comment (on the other hand, is the symlink

Re: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher ExecutionEnvironment.java for AIX and Linux/musl is brittle [v4]

On Fri, 28 Mar 2025 09:55:25 GMT, Matthias Baesken wrote: >> Joachim Kern has updated the pull request incrementally with one additional >> commit since the last revision: >> >> add !windows again and remove @compile > > test/jdk/tools/launcher/ExecutionEnvironment.java line 42: > >> 40: *

Re: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher ExecutionEnvironment.java for AIX and Linux/musl is brittle [v4]

On Thu, 27 Mar 2025 14:15:12 GMT, Joachim Kern wrote: >> The test `testEcoFriendly()` checks if the launcher pollutes the >> `LD_LIBRARY_PATH` environment variable. >> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does >> not make sense to make this test somehow passing w

Re: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher ExecutionEnvironment.java for AIX and Linux/musl is brittle [v5]

> The test `testEcoFriendly()` checks if the launcher pollutes the > `LD_LIBRARY_PATH` environment variable. > Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not > make sense to make this test somehow passing with crude workarounds, which > even do not work in any case

Re: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v6]

On Thu, 27 Mar 2025 22:37:57 GMT, Chen Liang wrote: >> Jaikiran Pai 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 sin

Re: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v2]

On Fri, 21 Feb 2025 07:10:16 GMT, Alan Bateman wrote: >> Nicole Xu has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - 8349944: [JMH] sun.misc.UnsafeOps cannot access class >> jdk.internal.misc.Unsafe >> >>The UnsafeOps JMH benchm

Re: RFR: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

On Fri, 28 Mar 2025 09:02:38 GMT, Alan Bateman wrote: > Now that it is being looked at again I think we will need to come up with a > better name for it and also review the semantics and decide if skipping the > extended timestamp fields is okay or whether all timestamps should just > report t

Re: RFR: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

On Sun, 23 Mar 2025 12:38:04 GMT, Jason Zaugg wrote: > 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in > com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better > performance > I agree that passing zipinfo-time to an unknown provider is likely quite safe. R

Re: RFR: 8352171: Arrays.hashCode for sub-range of byte array API addition

On Thu, 20 Mar 2025 11:59:58 GMT, Zihao Lin wrote: > Add the java.util.Arrays.hashCode(byte[], int start, int end). > > Hi team, I am new here, please give me some guidance. Thank you. src/java.base/share/classes/java/util/Arrays.java line 4454: > 4452: */ > 4453: public static int ha

Withdrawn: 8352171: Arrays.hashCode for sub-range of byte array API addition

On Thu, 20 Mar 2025 11:59:58 GMT, Zihao Lin wrote: > Add the java.util.Arrays.hashCode(byte[], int start, int end). > > Hi team, I am new here, please give me some guidance. Thank you. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pu