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 Min
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 co
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
>> co
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
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 `i
> 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 th
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 a
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
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 optio
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 (Consumer
>
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
>> implemen
> 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 f
> 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, StandardCharsets
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:
>
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 X8
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 X8
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.
>>
>>
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
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 unrelate
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 unrelate
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
t
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 i
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 i
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 sp
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 hand
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 t
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 t
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:
>>
>> `
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)
>
> 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
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 co
> 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
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 a
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 t
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 b
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 b
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:
https://git.openjdk.org/jdk/commit/cc25d8b1
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 s
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)
>
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.
I
> 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
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
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
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: https://webrevs.openjd
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
>
> src/java.base/linux/native/libsimdsort/avx2-linux
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.
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
> 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 improvement
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: https://git.o
> 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: https://git.
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.
>>
>>
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
> 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 improvement
> 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, StandardCharsets
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:
>>
>> `
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.
>>
>>
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 strin
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,
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, w
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, w
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 C+
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
> 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 JDK-83194
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.
>>
>>
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 s
> 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, StandardCharsets
> 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 improvement
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 (!Matcher
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 complicat
> 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 impleme
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&pr=17004&range=00
Issue: https://bugs.openjdk.org/browse/JD
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:
>
> ```
>
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, wh
> 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
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 w
> 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 improvement
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
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.
>>
>>
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 messa
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 te
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 te
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.
-
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 checkFinalizerCalle
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
> 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 JD
> 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: https://git.openjdk.org/jdk/pu
> 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 th
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()`),
`JvmtiV
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
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
>> const
> 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 `IndexOutOfBounds
91 matches
Mail list logo