> This patch optimizes the following patterns:
> For integer types:
>
> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
> => (VectorMaskCmp src1 src2 ncond)
> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
> => (VectorMaskCmp src1 src2 ncond)
>
> cond can be eq, ne, le, ge, l
On Mon, 7 Jul 2025 09:32:42 GMT, erifan wrote:
>> src/hotspot/share/opto/vectornode.cpp line 2243:
>>
>>> 2241: !VectorNode::is_all_ones_vector(in2)) {
>>> 2242: return nullptr;
>>> 2243: }
>>
>> Suggestion:
>>
>> if (in1->Opcode() != Op_VectorMaskCmp ||
>> in1->outcnt() !=
On Tue, 17 Jun 2025 15:22:24 GMT, Nizar Benalla wrote:
> Once https://bugs.openjdk.org/browse/JDK-8358769 is resolved,
> JavaBaseCheckSince no longer needs to be problemlisted.
Hello Nizar, if I understand correctly, this problem listing can be removed and
the PR integrated once the merge conf
On Thu, 3 Apr 2025 18:47:43 GMT, Matthew Donovan wrote:
> In this PR I added TLS groups and signature algorithms to the output of the
> show settings flag. The values are printed in a single column, like the
> cipher suites. There can be a lot of values so putting on a single line is
> ugly. I
On Sat, 5 Jul 2025 00:05:39 GMT, Kim Barrett wrote:
> Please review this change that removes the class jdk.internal.ref.Cleaner.
> It is no longer used after JDK-8344332.
>
> Testing: mach5 tier1-3
This looks OK to me and matches with what was discussed about this in a recent
PR https://github
On Tue, 3 Jun 2025 10:09:44 GMT, Nizar Benalla wrote:
> Please review this patch to add a new test to check `@since` tags in the
> `jdk.editpad` module.
>
> TIA
This looks OK to me.
-
Marked as reviewed by jpai (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/25613#pullre
On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
>> u
Thanks for the quick reply, Viktor!
On Mon, Jul 7, 2025 at 2:35 AM Viktor Klang wrote:
> Hi Jige,
>
> >Initially, I thought this design choice might provide a strong
> happens-before guarantee. My assumption was that an application catching a
> RuntimeException would be able to *observe all side
On Mon, 7 Jul 2025 13:23:15 GMT, Fei Gao wrote:
> > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392
> >
> >
> > Actually I didn't change the min vector size for `char` vectors in
On Mon, 7 Jul 2025 06:59:20 GMT, Xiaohong Gong wrote:
>> Have you measured the performance of this micro-benchmark on NEON machine?
>> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java#L251-L256
>>
>> W
On Tue, 8 Jul 2025 01:28:04 GMT, Julian Waters wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove the got local
>
> Sorry for waiting so long. It's become clear that I won't be able to get awt
> and accessibi
On Wed, 23 Oct 2024 04:40:50 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals that trigger the
> unuse
On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
>> u
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals that trigger the
> unuse
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 04:48:18 GMT, Florian Weimer wrote:
> Isn't this effectively a libm benchmark (where the `sinh` implementation
> resides)? Please include the libm version for reference here. Thanks.
I'm not sure which libm version you're referring to. The only current sinh
benchmark I'm awa
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 18:01:26 GMT, Joe Darcy wrote:
> Are there plans for a cosh intrinsic as follow-up work? There was a previous
> effort to intrinsify tanh.
Yes, the intention is to have cosh as next math intrinsic.
-
PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecommen
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 18:03:54 GMT, Joe Darcy wrote:
> A large fraction of floating-point numbers are in the [-2^(-28), 2^(-28)]
> range where there is a performance degradation with the new implementation.
>
> What is the expected distribution of arguments to sinh?
I don't know about an expected
The class file API verifier seems to be based off a version of hotspot verifier
before Mar 3 2021. We are thus missing a few patches in the hotspot verifier:
[JDK-8350029](https://bugs.openjdk.org/browse/JDK-8350029)
[JDK-8340110](https://bugs.openjdk.org/browse/JDK-8340110)
[JDK-8330606](https:
On Mon, 7 Jul 2025 22:54:32 GMT, Michael Hall wrote:
> What is the .jdk extension preceded by?
{NAME}-{VERSION}.jdk, where {NAME} is value of `--name` and {VERSION} is value
of `--version`.
-
PR Comment: https://git.openjdk.org/jdk/pull/26173#issuecomment-3046781194
> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
> conflict was resolved. Old PR will be closed.
>
> All comments are addressed from old PR. Merge conflict was significant, so it
> is like new fix.
>
> Fixed jpackage to produce valid Java runtimes based on description be
What is the .jdk extension preceded by?
A normal system jdk is like jdk-23.jdk
Maybe something like jpkg-23.jdk to indicate the source of the jre image is
jpakcage? Also ensuring it doesn’t conflict with a normally distributed one.
> On Jul 7, 2025, at 5:23 PM, Alexander Matveev wrote:
>
>
Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict
was resolved. Old PR will be closed.
All comments are addressed from old PR. Merge conflict was significant, so it
is like new fix.
Fixed jpackage to produce valid Java runtimes based on description below:
Definiti
On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev
wrote:
> Fixed jpackage to produce valid Java runtimes based on description below:
>
> Definitions:
>
> - JDK bundle defined as bundle which contains "Contents/Home",
> "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK
On Mon, 7 Jul 2025 18:29:34 GMT, Roger Riggs wrote:
> Identical doc-only backport to jdk 25. Already approved in the CSR.
This pull request has now been integrated.
Changeset: 3e93b98b
Author:Roger Riggs
URL:
https://git.openjdk.org/jdk/commit/3e93b98baf2a53d2d142e9f0ca9af8d99023ffa
On Tue, 29 Apr 2025 17:02:38 GMT, kabutz wrote:
> In 2015, Google discovered a rare disastrous classloading bug in first call
> to LockSupport.park() that occurred in the AppClassLoader using the Java 7
> ConcurrentHashMap, which used ReentrantLock for the synchronization.
>
> Since then, the
On Mon, 7 Jul 2025 20:24:21 GMT, Naoto Sato wrote:
>> Refining the description of "Unicode Scalar Value" in the `Character` class.
>> The original description referenced the outdated Unicode 3.1 specification,
>> which previously included the U+ notation but no longer does. Updated
>> the r
> Refining the description of "Unicode Scalar Value" in the `Character` class.
> The original description referenced the outdated Unicode 3.1 specification,
> which previously included the U+ notation but no longer does. Updated the
> reference to point to the Unicode glossary, which defines
On Mon, 7 Jul 2025 19:08:22 GMT, Naoto Sato wrote:
> Refining the description of "Unicode Scalar Value" in the `Character` class.
> The original description referenced the outdated Unicode 3.1 specification,
> which previously included the U+ notation but no longer does. Updated the
> refer
Refining the description of "Unicode Scalar Value" in the `Character` class.
The original description referenced the outdated Unicode 3.1 specification,
which previously included the U+ notation but no longer does. Updated the
reference to point to the Unicode glossary, which defines the term
On Mon, 7 Jul 2025 18:29:34 GMT, Roger Riggs wrote:
> Identical doc-only backport to jdk 25. Already approved in the CSR.
Changes appear to be identical to those in `master` branch.
-
Marked as reviewed by iris (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/26168#pullrequ
Identical doc-only backport to jdk 25. Already approved in the CSR.
-
Commit messages:
- Backport afb4a1be9e5dc2a9c0d812f5a36717c9f82241a9
Changes: https://git.openjdk.org/jdk/pull/26168/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26168&range=00
Issue: https://bugs.op
On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa wrote:
> The goal of this PR is to implement an x86_64 intrinsic for
> java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are
> included to check the performance of specific input value ranges to help
> prevent regressions in
On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa wrote:
> The goal of this PR is to implement an x86_64 intrinsic for
> java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are
> included to check the performance of specific input value ranges to help
> prevent regressions in
On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley wrote:
> Neither `ScopedValue.orElse` nor `ScopedValue.orElseThrow` consult the cache
> when searching for a binding. Neither do they update the cache when a binding
> is found.
> While this issue does not affect spec compliance, it is surprising to
On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley wrote:
> Neither `ScopedValue.orElse` nor `ScopedValue.orElseThrow` consult the cache
> when searching for a binding. Neither do they update the cache when a binding
> is found.
> While this issue does not affect spec compliance, it is surprising to
Neither `ScopedValue.orElse` nor `ScopedValue.orElseThrow` consult the cache
when searching for a binding. Neither do they update the cache when a binding
is found.
While this issue does not affect spec compliance, it is surprising to users
that `x.orElse(other)` should be slower than `x.isBound
Fixed an issue where null value component is not checked in class
java/awt/Mixing/AWT_Mixing/OverlappingTestBase.
Also removed test java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java from
problem list file.
-
Depends on: https://git.openjdk.org/jdk/pull/25971
Commit messages:
-
On Mon, 7 Jul 2025 06:59:20 GMT, Xiaohong Gong wrote:
> > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392
>
> Actually I didn't change the min vector size for `char` vectors in this
On Mon, 7 Jul 2025 12:58:39 GMT, Jaikiran Pai wrote:
>> This mostly just adds overrides to the wrapper implementations in
>> java.util.Collections. However, in order to satisfy the test, some overrides
>> are also added to ReverseOrderSortedMapView, which is used by the SortedMap
>> wrapper ke
On Wed, 28 May 2025 03:03:45 GMT, Stuart Marks wrote:
> This mostly just adds overrides to the wrapper implementations in
> java.util.Collections. However, in order to satisfy the test, some overrides
> are also added to ReverseOrderSortedMapView, which is used by the SortedMap
> wrapper keySe
On Wed, 28 May 2025 03:03:45 GMT, Stuart Marks wrote:
> This mostly just adds overrides to the wrapper implementations in
> java.util.Collections. However, in order to satisfy the test, some overrides
> are also added to ReverseOrderSortedMapView, which is used by the SortedMap
> wrapper keySe
On Wed, 18 Jun 2025 20:16:18 GMT, Roger Riggs wrote:
> Improve the documentation of Process use of system resources.
>
> Describe the implementation closing streams when no longer referenced.
> Clarify the interactions between inputStream and inputReader and errorStream
> and errorReader.
> Add
On Wed, 28 May 2025 03:03:45 GMT, Stuart Marks wrote:
> This mostly just adds overrides to the wrapper implementations in
> java.util.Collections. However, in order to satisfy the test, some overrides
> are also added to ReverseOrderSortedMapView, which is used by the SortedMap
> wrapper keySe
On Wed, 28 May 2025 03:03:45 GMT, Stuart Marks wrote:
> This mostly just adds overrides to the wrapper implementations in
> java.util.Collections. However, in order to satisfy the test, some overrides
> are also added to ReverseOrderSortedMapView, which is used by the SortedMap
> wrapper keySe
> Hi all,
>
> please review this change that implements (currently Draft) JEP: G1:
> Improve Application Throughput with a More Efficient Write-Barrier.
>
> The reason for posting this early is that this is a large change, and the JEP
> process is already taking very long with no end in sight
On Wed, 28 May 2025 03:03:45 GMT, Stuart Marks wrote:
> This mostly just adds overrides to the wrapper implementations in
> java.util.Collections. However, in order to satisfy the test, some overrides
> are also added to ReverseOrderSortedMapView, which is used by the SortedMap
> wrapper keySe
On Mon, 7 Jul 2025 09:58:15 GMT, Viktor Klang wrote:
>> src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
>> line 407:
>>
>>> 405: if (Modifier.isStatic(modifiers))
>>> 406: throw new IllegalArgumentException("Must not be a
>>> s
On Mon, 7 Jul 2025 09:54:28 GMT, Per Minborg wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test to verify observed internal unsafe behaviors
>
> src/java.base/share/classes/java/util/concurrent/atomic/AtomicInteger
On Mon, 7 Jul 2025 06:59:20 GMT, Xiaohong Gong wrote:
>> Have you measured the performance of this micro-benchmark on NEON machine?
>> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java#L251-L256
>>
>> W
On Thu, 3 Jul 2025 18:41:27 GMT, Chen Liang wrote:
>> Unsafe throws IAE for misusing static vs instance fields, and it's revealed
>> that AtomicXxxFieldUpdaters are using this mechanism to reject static
>> fields. This is not a good practice, but we can at least document this so we
>> don't ac
On Mon, 7 Jul 2025 09:56:07 GMT, Alan Bateman wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test to verify observed internal unsafe behaviors
>
> src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntege
On Thu, 3 Jul 2025 18:41:27 GMT, Chen Liang wrote:
>> Unsafe throws IAE for misusing static vs instance fields, and it's revealed
>> that AtomicXxxFieldUpdaters are using this mechanism to reject static
>> fields. This is not a good practice, but we can at least document this so we
>> don't ac
> Hi,
>
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP
> Client API](https://openjdk.org/jeps/517).
>
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP
> Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>
> This JEP propose
On Mon, 7 Jul 2025 06:19:15 GMT, Emanuel Peter wrote:
>> erifan 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 15 additional commits since
>> t
Hi Jige,
>Initially, I thought this design choice might provide a strong happens-before
>guarantee. My assumption was that an application catching a RuntimeException
>would be able to observe all side effects from the virtual threads, even
>though this practice is generally discouraged. This se
On Fri, 27 Jun 2025 14:32:11 GMT, Andrew Haley wrote:
> Scoped values cannot be used early in the JDK boot process because of some
> dependencies on System.getProperty(). This dependency should be removed in a
> way that allows scoped values to be created (but not necessarily bound) at
> any s
On Sat, 5 Jul 2025 15:08:35 GMT, Fei Gao wrote:
> Have you measured the performance of this micro-benchmark on NEON machine?
>
> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java#L251-L256
>
> We added
71 matches
Mail list logo
