Re: RFR: 8320360: ClassFile.parse: Some defect class files cause unexpected exceptions to be thrown [v2]

2023-12-06 Thread Adam Sotona
> ClassFile API throws `IndexOutOfBoundsException` when classfile structure is > corrupted so the parser attempts to read beyond the classfile bounds. > General contract is that only `IllegalArgumentException` or its subclasses is > expected when parser fails. > This patch wraps

Re: RFR: 8321467: MemorySegment.setString(long, String, Charset) throws IAE(Misaligned access) [v2]

2023-12-06 Thread Per Minborg
On Wed, 6 Dec 2023 17:03:08 GMT, Maurizio Cimadamore wrote: >> This PR fixes a couple of aligned accesses when reading/writing strings. >> Such aligned accesses crept in when we optimized string read/write >> operations to work in bulk. As a result, depending on the maximum alignment >>

Re: RFR: JDK-8320538: Obsolete CSS styles in collection framework doc-file

2023-12-06 Thread Alan Bateman
On Wed, 6 Dec 2023 16:22:24 GMT, Hannes Wallnöfer wrote: > Please review a simple change to remove a stray inline CSS element from the > Collection Framework index doc file. The only thing the `a {font-weight: > bold;}` rule did was to make all links in the header and footer bold as [can > be

RFR: 8311218: fatal error: stuck in JvmtiVTMSTransitionDisabler::VTMS_transition_disable

2023-12-06 Thread Serguei Spitsyn
This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame. It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`),

Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v8]

2023-12-06 Thread Xiaohong Gong
> Currently the vector floating-point math APIs like > `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, > which causes large performance gap on AArch64. Note that those APIs are > optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. > To close

Re: RFR: JDK-8319413: Start of release updates for JDK 23 [v8]

2023-12-06 Thread Joe Darcy
> Time to start making preparations for JDK 23. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update copyright year. - Changes: - all: https://git.openjdk.org/jdk/pull/16505/files - new:

Re: RFR: JDK-8319413: Start of release updates for JDK 23 [v7]

2023-12-06 Thread Joe Darcy
> Time to start making preparations for JDK 23. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into

Re: RFR: 8321409: Console read line with zero out should zero out underlying buffer in JLine (redux)

2023-12-06 Thread Alan Bateman
On Wed, 6 Dec 2023 21:12:40 GMT, Naoto Sato wrote: > This is an additional fix to JDK-8321131, where more clearing is required in > JLine. Marked as reviewed by alanb (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/17004#pullrequestreview-1769310866

Re: RFR: 8320198: some reference processing tests don't wait long enough for reference processing to complete

2023-12-06 Thread Jaikiran Pai
On Mon, 4 Dec 2023 17:46:18 GMT, Tom Rodriguez wrote: > This slightly increases the wait for reference processing to complete to > accommodate long Xcomp compile times. Testing is underway. test/jdk/java/lang/Object/FinalizationOption.java line 89: > 87: static boolean

Re: RFR: 8321470: ThreadLocal.nextHashCode can be static final [v2]

2023-12-06 Thread Jaikiran Pai
On Wed, 6 Dec 2023 17:42:47 GMT, Brett Okken wrote: >> The static AtomicInteger used for the nextHashCode should be final. > > Brett Okken has updated the pull request incrementally with one additional > commit since the last revision: > > Update full name The change looks fine to me.

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v12]

2023-12-06 Thread Srinivas Vamsi Parasa
On Wed, 6 Dec 2023 23:09:01 GMT, Srinivas Vamsi Parasa wrote: >>> LGTM, thanks! >> >> Thanks Jatin! > >> @vamsi-parasa, sorry, I was wrong. I missed that you need to check type >> `bt`. Latest change is more complicated than it was before. Please revert it >> back (undo last change). I will

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v12]

2023-12-06 Thread Vladimir Kozlov
On Wed, 6 Dec 2023 23:09:01 GMT, Srinivas Vamsi Parasa wrote: >>> LGTM, thanks! >> >> Thanks Jatin! > >> @vamsi-parasa, sorry, I was wrong. I missed that you need to check type >> `bt`. Latest change is more complicated than it was before. Please revert it >> back (undo last change). I will

RFR: 8321180: Condition for non-latin1 string size too large exception is off by one

2023-12-06 Thread Roger Riggs
In the compact string implementation of non-latin1 (UTF16) strings the length is constrained by VM implementation limit on the size a byte array that can be allocated. To produce a useful exception the implementation checks the string size against the maximum byte array size. The exception

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v12]

2023-12-06 Thread Vladimir Kozlov
On Wed, 6 Dec 2023 23:12:13 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX2 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays. >>

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v12]

2023-12-06 Thread Srinivas Vamsi Parasa
On Wed, 6 Dec 2023 17:44:24 GMT, Srinivas Vamsi Parasa wrote: >> LGTM, thanks! > >> LGTM, thanks! > > Thanks Jatin! > @vamsi-parasa, sorry, I was wrong. I missed that you need to check type `bt`. > Latest change is more complicated than it was before. Please revert it back > (undo last

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v12]

2023-12-06 Thread Srinivas Vamsi Parasa
> The goal is to develop faster sort routines for x86_64 CPUs by taking > advantage of AVX2 instructions. This enhancement provides an order of > magnitude speedup for Arrays.sort() using int, long, float and double arrays. > > For serial sort on random data, this PR shows upto ~7.5x

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v10]

2023-12-06 Thread Vladimir Kozlov
On Wed, 6 Dec 2023 17:44:24 GMT, Srinivas Vamsi Parasa wrote: >> LGTM, thanks! > >> LGTM, thanks! > > Thanks Jatin! @vamsi-parasa, sorry, I was wrong. I missed that you need to check type `bt`. Latest change is more complicated than it was before. Please revert it back (undo last change). I

Re: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v3]

2023-12-06 Thread Scott Gibbons
> Re-write the IndexOf code without the use of the pcmpestri instruction, only > using AVX2 instructions. This change accelerates String.IndexOf on average > 1.3x for AVX2. The benchmark numbers: > > > BenchmarkScore > Latest

Re: RFR: 8321206: Make Locale related system properties `StaticProperty` [v2]

2023-12-06 Thread Roger Riggs
On Wed, 6 Dec 2023 20:55:48 GMT, Naoto Sato wrote: >> Currently, Locale-related system properties, such as `user.language` or >> `user.country`, are initialized when the `Locale` class is loaded. Making >> them static properties is safer than relying on the `Locale` class loading >> timing,

Integrated: JDK-8320570 NegativeArraySizeException decoding >1G UTF8 bytes with non-ascii characters

2023-12-06 Thread Jim Laskey
On Tue, 5 Dec 2023 14:57:09 GMT, Jim Laskey wrote: > A regression is found in Java9+ creating String instance from UTF8 bytes, a > side effect of string compactation https://openjdk.org/jeps/254 that changed > the decoding logic. Specifically, when constructing a string from bytes: > > ```

RFR: 8321409: Console read line with zero out should zero out underlying buffer in JLine (redux)

2023-12-06 Thread Naoto Sato
This is an additional fix to JDK-8321131, where more clearing is required in JLine. - Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/17004/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17004=00 Issue:

Re: RFR: 8321206: Make Locale related system properties `StaticProperty` [v2]

2023-12-06 Thread Naoto Sato
> Currently, Locale-related system properties, such as `user.language` or > `user.country`, are initialized when the `Locale` class is loaded. Making > them static properties is safer than relying on the `Locale` class loading > timing, which could potentially be changed depending on the

Re: RFR: 8321206: Make Locale related system properties `StaticProperty` [v2]

2023-12-06 Thread Naoto Sato
On Wed, 6 Dec 2023 18:10:05 GMT, Naoto Sato wrote: >> src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 415: >> >>> 413: public static String userRegion() { >>> 414: return USER_REGION; >>> 415: } >> >> Using methods to retrieve these makes is more

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v10]

2023-12-06 Thread Srinivas Vamsi Parasa
On Wed, 6 Dec 2023 18:41:26 GMT, Vladimir Kozlov wrote: >> Srinivas Vamsi Parasa has updated the pull request incrementally with one >> additional commit since the last revision: >> >> add missing header files > > src/hotspot/share/opto/library_call.cpp line 5393: > >> 5391: if

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v11]

2023-12-06 Thread Srinivas Vamsi Parasa
> The goal is to develop faster sort routines for x86_64 CPUs by taking > advantage of AVX2 instructions. This enhancement provides an order of > magnitude speedup for Arrays.sort() using int, long, float and double arrays. > > For serial sort on random data, this PR shows upto ~7.5x

Re: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8 bytes with non-ascii characters [v5]

2023-12-06 Thread Jim Laskey
> A regression is found in Java9+ creating String instance from UTF8 bytes, a > side effect of string compactation https://openjdk.org/jeps/254 that changed > the decoding logic. Specifically, when constructing a string from bytes: > > ``` > String str = new String(largeBytes,

Re: RFR: 8320759: Creation of random BigIntegers can be made faster [v3]

2023-12-06 Thread Raffaello Giulietti
On Wed, 6 Dec 2023 15:07:59 GMT, fabioromano1 wrote: >> So, item 1 is a non-issue and item 2 is not likely a problem in practice. >> What, if anything, will be done about item 3? > > @bplb Maybe an assertion at the end of `randomBits(int, Random)` method, or a > test class. @fabioromano1 As

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v10]

2023-12-06 Thread Vladimir Kozlov
On Wed, 6 Dec 2023 17:48:04 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX2 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays. >>

Re: RFR: JDK-8319413: Start of release updates for JDK 23 [v6]

2023-12-06 Thread Joe Darcy
> Time to start making preparations for JDK 23. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Regenerate JDK 22 symbol files. - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v10]

2023-12-06 Thread Sandhya Viswanathan
On Wed, 6 Dec 2023 18:26:34 GMT, Vladimir Kozlov wrote: >> @TobiHartmann @vnkozlov Please advice if we can go head and integrate this >> PR today before the fork. > >> @TobiHartmann @vnkozlov Please advice if we can go head and integrate this >> PR today before the fork. > > Too late. Changes

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v10]

2023-12-06 Thread Vladimir Kozlov
On Wed, 6 Dec 2023 18:05:22 GMT, Sandhya Viswanathan wrote: > @TobiHartmann @vnkozlov Please advice if we can go head and integrate this PR > today before the fork. Too late. Changes looks fine to me (I am still on fence that we moving to C++ implementation of intrinsics and require latest

Re: RFR: 8321206: Make Locale related system properties `StaticProperty`

2023-12-06 Thread Naoto Sato
On Wed, 6 Dec 2023 15:18:27 GMT, Roger Riggs wrote: >> Currently, Locale-related system properties, such as `user.language` or >> `user.country`, are initialized when the `Locale` class is loaded. Making >> them static properties is safer than relying on the `Locale` class loading >> timing,

Re: RFR: 8321206: Make Locale related system properties `StaticProperty`

2023-12-06 Thread Naoto Sato
On Wed, 6 Dec 2023 15:27:48 GMT, Roger Riggs wrote: >> Currently, Locale-related system properties, such as `user.language` or >> `user.country`, are initialized when the `Locale` class is loaded. Making >> them static properties is safer than relying on the `Locale` class loading >> timing,

Re: RFR: 8321206: Make Locale related system properties static properties

2023-12-06 Thread Naoto Sato
On Wed, 6 Dec 2023 08:14:05 GMT, Alan Bateman wrote: >> Currently, Locale-related system properties, such as `user.language` or >> `user.country`, are initialized when the `Locale` class is loaded. Making >> them static properties is safer than relying on the `Locale` class loading >> timing,

Re: RFR: 8321206: Make Locale related system properties static properties

2023-12-06 Thread Naoto Sato
On Wed, 6 Dec 2023 02:14:13 GMT, David Holmes wrote: > I'm not following the changes to cdsHeapVerifier.cpp. You've marked the new > entries as `C` but the definition is: > > ``` > // [C] A non-final static string that is assigned a string literal during > class > // initialization; this

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v10]

2023-12-06 Thread Sandhya Viswanathan
On Wed, 6 Dec 2023 17:48:04 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX2 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays. >>

Re: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8 bytes with non-ascii characters [v4]

2023-12-06 Thread Roger Riggs
On Wed, 6 Dec 2023 17:56:58 GMT, Jim Laskey wrote: >> A regression is found in Java9+ creating String instance from UTF8 bytes, a >> side effect of string compactation https://openjdk.org/jeps/254 that changed >> the decoding logic. Specifically, when constructing a string from bytes: >> >>

Re: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8 bytes with non-ascii characters [v4]

2023-12-06 Thread Jim Laskey
> A regression is found in Java9+ creating String instance from UTF8 bytes, a > side effect of string compactation https://openjdk.org/jeps/254 that changed > the decoding logic. Specifically, when constructing a string from bytes: > > ``` > String str = new String(largeBytes,

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v10]

2023-12-06 Thread Srinivas Vamsi Parasa
> The goal is to develop faster sort routines for x86_64 CPUs by taking > advantage of AVX2 instructions. This enhancement provides an order of > magnitude speedup for Arrays.sort() using int, long, float and double arrays. > > For serial sort on random data, this PR shows upto ~7.5x

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v10]

2023-12-06 Thread Srinivas Vamsi Parasa
On Wed, 6 Dec 2023 17:42:39 GMT, Jatin Bhateja wrote: > LGTM, thanks! Thanks Jatin! - PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843372385

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v10]

2023-12-06 Thread Jatin Bhateja
On Wed, 6 Dec 2023 17:44:25 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX2 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays. >>

Re: RFR: 8321470: ThreadLocal.nextHashCode can be static final [v2]

2023-12-06 Thread Brett Okken
> The static AtomicInteger used for the nextHashCode should be final. Brett Okken has updated the pull request incrementally with one additional commit since the last revision: Update full name - Changes: - all: https://git.openjdk.org/jdk/pull/16987/files - new:

Re: RFR: 8321470: ThreadLocal.nextHashCode can be static final

2023-12-06 Thread Aleksey Shipilev
On Wed, 6 Dec 2023 00:52:48 GMT, Brett Okken wrote: > The static AtomicInteger used for the nextHashCode should be final. Looks okay to me! Since this is new contribution, I would like someone else to take a look. - Marked as reviewed by shade (Reviewer). PR Review:

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v9]

2023-12-06 Thread Srinivas Vamsi Parasa
> The goal is to develop faster sort routines for x86_64 CPUs by taking > advantage of AVX2 instructions. This enhancement provides an order of > magnitude speedup for Arrays.sort() using int, long, float and double arrays. > > For serial sort on random data, this PR shows upto ~7.5x

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v8]

2023-12-06 Thread Srinivas Vamsi Parasa
On Tue, 5 Dec 2023 19:37:34 GMT, Jatin Bhateja wrote: >> Srinivas Vamsi Parasa 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 17 >> additional

Re: RFR: 8321470: ThreadLocal.nextHashCode can be static final

2023-12-06 Thread Aleksey Shipilev
On Wed, 6 Dec 2023 00:52:48 GMT, Brett Okken wrote: > The static AtomicInteger used for the nextHashCode should be final. Submitted: https://bugs.openjdk.org/browse/JDK-8321470 Please change this PR title to "8321470: ThreadLocal.nextHashCode can be static final", and bots would do the rest.

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v9]

2023-12-06 Thread Srinivas Vamsi Parasa
On Tue, 5 Dec 2023 19:19:23 GMT, Jatin Bhateja wrote: >> Srinivas Vamsi Parasa has updated the pull request incrementally with one >> additional commit since the last revision: >> >> remove unused avx2 64 bit sort functions; add assertions > >

RFR: 8321470: ThreadLocal.nextHashCode can be static final

2023-12-06 Thread Brett Okken
The static AtomicInteger used for the nextHashCode should be final. - Commit messages: - Merge remote-tracking branch 'upstream/master' into threadlocal_final - make ThreadLocal.nextHashCode final Changes: https://git.openjdk.org/jdk/pull/16987/files Webrev:

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v9]

2023-12-06 Thread Srinivas Vamsi Parasa
On Wed, 6 Dec 2023 11:59:19 GMT, Magnus Ihse Bursie wrote: >> Hi Magnus (@magicus), >> >>> Are you saying that when compiling with GCC 6, it will just silently ignore >>> `-std=c++17`? I'd have assumed that it printed a warning or error about an >>> unknown or invalid option, if C++17 is not

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v8]

2023-12-06 Thread Srinivas Vamsi Parasa
On Tue, 5 Dec 2023 19:33:48 GMT, Jatin Bhateja wrote: >> Srinivas Vamsi Parasa 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 17 >> additional

Re: RFR: 8321467: MemorySegment.setString(long, String, Charset) throws IAE(Misaligned access) [v2]

2023-12-06 Thread Maurizio Cimadamore
> This PR fixes a couple of aligned accesses when reading/writing strings. Such > aligned accesses crept in when we optimized string read/write operations to > work in bulk. As a result, depending on the maximum alignment constraints > supported by the heap segment, some string operations might

RFR: 8321467: MemorySegment.setString(long, String, Charset) throws IAE(Misaligned access)

2023-12-06 Thread Maurizio Cimadamore
This PR fixes a couple of aligned accesses when reading/writing strings. Such aligned accesses crept in when we optimized string read/write operations to work in bulk. As a result, depending on the maximum alignment constraints supported by the heap segment, some string operations might fail.

Re: RFR: 8320759: Creation of random BigIntegers can be made faster [v3]

2023-12-06 Thread Brian Burkhalter
On Tue, 5 Dec 2023 22:01:04 GMT, Brian Burkhalter wrote: >> fabioromano1 has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Create RandomBigIntegers.java >> >> Create a benchmark to measure the performance of BigInteger(int, Random)

RFR: JDK-8320538: Obsolete CSS styles in collection framework doc-file

2023-12-06 Thread Hannes Wallnöfer
Please review a simple change to remove a stray inline CSS element from the Collection Framework index doc file. The only thing the `a {font-weight: bold;}` rule did was to make all links in the header and footer bold as [can be seen here][1]; the three content links to the other doc files are

Integrated: JDK-8319662 ForkJoinPool trims worker threads too slowly

2023-12-06 Thread Doug Lea
On Sun, 19 Nov 2023 17:36:01 GMT, Doug Lea wrote: > This update cascades timeouts to trim subsequent workers after the first > keepAlive inactive period. This pull request has now been integrated. Changeset: cc25d8b1 Author:Doug Lea URL:

Re: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout, MemorySegment) does not throw stated UnsupportedOperationException [v3]

2023-12-06 Thread Maurizio Cimadamore
On Wed, 6 Dec 2023 15:32:54 GMT, Per Minborg wrote: >> This PR proposes to change the exception type for exceptions thrown for >> certain methods with a parameter of type `MemorySegment` when it is >> `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` >> was specified

Re: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout, MemorySegment) does not throw stated UnsupportedOperationException [v3]

2023-12-06 Thread Maurizio Cimadamore
On Wed, 6 Dec 2023 15:32:54 GMT, Per Minborg wrote: >> This PR proposes to change the exception type for exceptions thrown for >> certain methods with a parameter of type `MemorySegment` when it is >> `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` >> was specified

Re: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent with the rest of the API [v2]

2023-12-06 Thread Adam Sotona
On Wed, 6 Dec 2023 10:40:51 GMT, Adam Sotona wrote: >> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an >> optional argument and does not respect >> `ClassFile.ClassHierarchyResolverOption` of the actual context. >> Parsing, building and transforming take options from

Integrated: 8321248: ClassFile API ClassModel::verify is inconsistent with the rest of the API

2023-12-06 Thread Adam Sotona
On Mon, 4 Dec 2023 11:12:37 GMT, Adam Sotona wrote: > ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an > optional argument and does not respect > `ClassFile.ClassHierarchyResolverOption` of the actual context. > Parsing, building and transforming take options from the

Re: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout, MemorySegment) does not throw stated UnsupportedOperationException [v3]

2023-12-06 Thread Per Minborg
> This PR proposes to change the exception type for exceptions thrown for > certain methods with a parameter of type `MemorySegment` when it is > `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` > was specified but in some cases, in reality, an

Re: RFR: 8321206: Make Locale related system properties static properties

2023-12-06 Thread Roger Riggs
On Tue, 5 Dec 2023 23:04:55 GMT, Naoto Sato wrote: > Currently, Locale-related system properties, such as `user.language` or > `user.country`, are initialized when the `Locale` class is loaded. Making > them static properties is safer than relying on the class initialization > timing, which

Re: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout, MemorySegment) does not throw stated UnsupportedOperationException [v2]

2023-12-06 Thread Per Minborg
> This PR proposes to change the exception type for exceptions thrown for > certain methods with a parameter of type `MemorySegment` when it is > `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` > was specified but in some cases, in reality, an

Re: RFR: 8320759: Creation of random BigIntegers can be made faster [v3]

2023-12-06 Thread fabioromano1
On Tue, 5 Dec 2023 22:01:04 GMT, Brian Burkhalter wrote: >> fabioromano1 has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Create RandomBigIntegers.java >> >> Create a benchmark to measure the performance of BigInteger(int, Random)

Re: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8 bytes with non-ascii characters [v3]

2023-12-06 Thread Roger Riggs
On Wed, 6 Dec 2023 11:47:13 GMT, Jim Laskey wrote: >> A regression is found in Java9+ creating String instance from UTF8 bytes, a >> side effect of string compactation https://openjdk.org/jeps/254 that changed >> the decoding logic. Specifically, when constructing a string from bytes: >> >>

Re: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent with the rest of the API [v2]

2023-12-06 Thread Maurizio Cimadamore
On Wed, 6 Dec 2023 10:40:51 GMT, Adam Sotona wrote: >> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an >> optional argument and does not respect >> `ClassFile.ClassHierarchyResolverOption` of the actual context. >> Parsing, building and transforming take options from

Re: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent with the rest of the API [v2]

2023-12-06 Thread Jan Lahoda
On Wed, 6 Dec 2023 10:40:51 GMT, Adam Sotona wrote: >> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an >> optional argument and does not respect >> `ClassFile.ClassHierarchyResolverOption` of the actual context. >> Parsing, building and transforming take options from

Re: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout, MemorySegment) does not throw stated UnsupportedOperationException

2023-12-06 Thread Maurizio Cimadamore
On Wed, 6 Dec 2023 14:09:31 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template >> line 153: >> >>> 151: static void set(VarHandle ob, Object obb, long base, $type$ value) >>> { >>> 152: VarHandleSegmentViewBase

Re: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout, MemorySegment) does not throw stated UnsupportedOperationException

2023-12-06 Thread Maurizio Cimadamore
On Wed, 6 Dec 2023 14:06:00 GMT, Maurizio Cimadamore wrote: >> This PR proposes to change the exception type for exceptions thrown for >> certain methods with a parameter of type `MemorySegment` when it is >> `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` >> was

Re: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout, MemorySegment) does not throw stated UnsupportedOperationException

2023-12-06 Thread Maurizio Cimadamore
On Wed, 6 Dec 2023 13:52:37 GMT, Per Minborg wrote: > This PR proposes to change the exception type for exceptions thrown for > certain methods with a parameter of type `MemorySegment` when it is > `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` > was specified but

Re: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout, MemorySegment) does not throw stated UnsupportedOperationException

2023-12-06 Thread Maurizio Cimadamore
On Wed, 6 Dec 2023 13:52:37 GMT, Per Minborg wrote: > This PR proposes to change the exception type for exceptions thrown for > certain methods with a parameter of type `MemorySegment` when it is > `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` > was specified but

RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout, MemorySegment) does not throw stated UnsupportedOperationException

2023-12-06 Thread Per Minborg
This PR proposes to change the exception type for exceptions thrown for certain methods with a parameter of type `MemorySegment` when it is `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` was specified but in some cases, in reality, an `IllegalArgumentException` was

Re: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v8]

2023-12-06 Thread Viktor Klang
On Mon, 4 Dec 2023 13:56:55 GMT, Doug Lea wrote: >> This update cascades timeouts to trim subsequent workers after the first >> keepAlive inactive period. > > Doug Lea has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the

Re: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v8]

2023-12-06 Thread Alan Bateman
On Mon, 4 Dec 2023 13:56:55 GMT, Doug Lea wrote: >> This update cascades timeouts to trim subsequent workers after the first >> keepAlive inactive period. > > Doug Lea has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v8]

2023-12-06 Thread Magnus Ihse Bursie
On Tue, 5 Dec 2023 17:26:06 GMT, Srinivas Vamsi Parasa wrote: >> That sounds weird. You can't check for if compiler options should be enabled >> or not inside source code files. >> >> Are you saying that when compiling with GCC 6, it will just silently ignore >> `-std=c++17`? I'd have assumed

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v8]

2023-12-06 Thread Magnus Ihse Bursie
On Mon, 4 Dec 2023 22:15:24 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX2 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays. >>

Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v7]

2023-12-06 Thread Magnus Ihse Bursie
On Wed, 6 Dec 2023 09:14:58 GMT, Xiaohong Gong wrote: >> Currently the vector floating-point math APIs like >> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, >> which causes large performance gap on AArch64. Note that those APIs are >> optimized by C2 compiler on

Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v7]

2023-12-06 Thread Magnus Ihse Bursie
On Wed, 6 Dec 2023 09:14:58 GMT, Xiaohong Gong wrote: >> Currently the vector floating-point math APIs like >> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, >> which causes large performance gap on AArch64. Note that those APIs are >> optimized by C2 compiler on

Re: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8 bytes with non-ascii characters [v2]

2023-12-06 Thread Jim Laskey
On Tue, 5 Dec 2023 20:44:54 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Bump up memory >> - Cotrrect NegativeSize.java > > test/jdk/java/lang/String/CompactString/NegativeSize.java line 30: >

Re: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8 bytes with non-ascii characters [v3]

2023-12-06 Thread Jim Laskey
> A regression is found in Java9+ creating String instance from UTF8 bytes, a > side effect of string compactation https://openjdk.org/jeps/254 that changed > the decoding logic. Specifically, when constructing a string from bytes: > > ``` > String str = new String(largeBytes,

Re: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent with the rest of the API [v2]

2023-12-06 Thread Adam Sotona
> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an > optional argument and does not respect > `ClassFile.ClassHierarchyResolverOption` of the actual context. > Parsing, building and transforming take options from the actual `ClassFile` > context and verification should

Re: RFR: 8318809: java/util/concurrent/ConcurrentLinkedQueue/WhiteBox.java shows intermittent failures on linux ppc64le and aarch64

2023-12-06 Thread Andrew Haley
On Tue, 5 Dec 2023 09:08:59 GMT, Andrew Haley wrote: >> We've seen some rare failures of the CLQ Whitebox test on "less-strong" >> architectures, and the only thing which -- given my research -- could be the >> culprit is spuriously failing weakCAS (which is correct in terms of the >>

Re: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent with the rest of the API

2023-12-06 Thread Adam Sotona
On Wed, 6 Dec 2023 09:42:49 GMT, Adam Sotona wrote: >> test/jdk/jdk/classfile/VerifierSelfTest.java line 62: >> >>> 60: >>> 61: @Test >>> 62: void testFailedDump() throws IOException { >> >> Why is this removed? > > Dump (print) of the classfile to an optional log (ConsumerString >

Re: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent with the rest of the API

2023-12-06 Thread Adam Sotona
On Wed, 6 Dec 2023 09:26:29 GMT, Maurizio Cimadamore wrote: >> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an >> optional argument and does not respect >> `ClassFile.ClassHierarchyResolverOption` of the actual context. >> Parsing, building and transforming take

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

2023-12-06 Thread Severin Gehwolf
On Tue, 5 Dec 2023 19:15:53 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a "jmodless" jlink mode to the JDK. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >> install might not come with the packaged modules (directory `jmods`). This >> is

Re: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent with the rest of the API

2023-12-06 Thread Maurizio Cimadamore
On Mon, 4 Dec 2023 11:12:37 GMT, Adam Sotona wrote: > ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an > optional argument and does not respect > `ClassFile.ClassHierarchyResolverOption` of the actual context. > Parsing, building and transforming take options from the

Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v7]

2023-12-06 Thread Xiaohong Gong
> Currently the vector floating-point math APIs like > `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, > which causes large performance gap on AArch64. Note that those APIs are > optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. > To close

Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v5]

2023-12-06 Thread Xiaohong Gong
On Tue, 5 Dec 2023 13:03:22 GMT, Magnus Ihse Bursie wrote: >> Thanks for the suggestion @magicus ! >> >> The check in current `lib-sleef.m4` is very common: >> >> - If user has specified libsleef root by '--with-libsleef', we assume it is >> the manually built sleef lib. So only `lib/` and

Re: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily logs even when process has already completed [v3]

2023-12-06 Thread Stefan Karlsson
On Wed, 6 Dec 2023 01:56:46 GMT, David Holmes wrote: > FWIW exitCode out numbers exitValue in source code 3:1 (and > 5:1 in test > code). That might be the case, but both the called function returning the value and the function we are changing uses the name exitValue. It seems irrelevant that

Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v6]

2023-12-06 Thread Xiaohong Gong
On Fri, 1 Dec 2023 16:26:02 GMT, Magnus Ihse Bursie wrote: >> Xiaohong Gong 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 ten additional >>

Re: RFR: 8321206: Make Locale related system properties static properties

2023-12-06 Thread Alan Bateman
On Tue, 5 Dec 2023 23:04:55 GMT, Naoto Sato wrote: > Currently, Locale-related system properties, such as `user.language` or > `user.country`, are initialized when the `Locale` class is loaded. Making > them static properties is safer than relying on the class initialization > timing, which

Integrated: 8321159: SymbolLookup.libraryLookup(Path, Arena) Assumes default Filesystem

2023-12-06 Thread Per Minborg
On Mon, 4 Dec 2023 07:29:37 GMT, Per Minborg wrote: > This PR proposes to reject paths provided to the > `SymbolLookup.libraryLookup(Path path, Arena arena)` method if a path is not > in the default file system. This pull request has now been integrated. Changeset: a0920aa4 Author:Per