On Tue, 8 Jul 2025 11:42:02 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 17 additional commits since
>> t
On Tue, 8 Jul 2025 11:42:18 GMT, Emanuel Peter wrote:
>> Oh wow, my bad. I misunderstood the brackets!
>>
>> Instead of:
>>
>> !(in1->as_VectorMaskCmp())->predicate_can_be_negated() ||
>> !VectorNode::is_all_ones_vector(in2)) {
>>
>> I read:
>>
>> !(in1->as_VectorMaskCmp()->
> 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 23:21:58 GMT, Chen Liang wrote:
> 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](ht
On Mon, 7 Jul 2025 23:21:58 GMT, Chen Liang wrote:
> 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](ht
On Tue, 8 Jul 2025 10:33:50 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 siz
On Tue, 8 Jul 2025 09:07:00 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 vect
> ### Background
> On AArch64, the minimum vector length supported is 64-bit for basic types,
> except for `byte` and `boolean` (32-bit and 16-bit respectively to match
> special Vector API features). This limitation prevents intrinsification of
> vector type conversions between `short` and wide
On Tue, 8 Jul 2025 10:33:50 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 ve
On Tue, 8 Jul 2025 18:53:08 GMT, Lance Andersen wrote:
>> It was just a suggestion, but it’s not really related to the main change. I
>> can undo it if you think it’s appropriate
>
> Please revert this change
Fixed
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25925#discus
> 8360122: Refine formatting of Connection.java interface
>
> -
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1
> [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must
> In the `class` file format, a lot of the values are `u1` or `u2`; the
> Class-File API consistently model them with `int`. However, the API does not,
> in general, validate that int values passed to the factory methods are not
> out of the bounds as defined in the class file format. This patch
In the `class` file format, a lot of the values are `u1` or `u2`; the
Class-File API consistently model them with `int`. However, the API does not,
in general, validate that int values passed to the factory methods are not out
of the bounds as defined in the class file format. This patch propose
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 pull request has now been integrated.
Changeset: 117f0b40
Author:Kim Barrett
URL:
On Tue, 8 Jul 2025 04:59:04 GMT, Jaikiran Pai 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 http
On Thu, 3 Jul 2025 01:44:27 GMT, simon wrote:
>> src/java.sql/share/classes/java/sql/Connection.java line 303:
>>
>>> 301:
>>> //==
>>> 302: // Advanced features:
>>> 303:
>>
>> Why was this removed as this is not for
In a recent inspection of all methods that accept an `int` argument in the
Class-File API, I noticed this method that validates its argument but did not
document the validation. The behavior is to throw IOOBE. We can simply document
this behavior and enhance existing tests to verify exceptional
On Tue, 8 Jul 2025 17:59:32 GMT, Alan Bateman wrote:
>> Tracked in 8360541; I think we can implement in a separate patch. Don't know
>> if this is worth backporting to MRs.
>
> Ah yes, I'd forgotten I created this issue to track clarifying the spec.
Sure, the clarification is long past being us
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 12:06:54 GMT, Chen Liang wrote:
>> @AlanBateman Yeah, I think that makes sense—IIRC it's been that way in
>> practice since forever, but making it clear in documentation seems like the
>> right thing to do.
>
> Tracked in 8360541; I think we can implement in a separate patch.
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 Tue, 8 Jul 2025 17:20:34 GMT, Chen Liang wrote:
>> I have updated this patch to avoid a redundant `runtimeSetup` annotation -
>> we have agreed that the requirement for setup is a side effect of
>> initialization, and such methods in AOTCI classes must be automatically
>> recognized. This l
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
> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we
> have agreed that the requirement for setup is a side effect of
> initialization, and such methods in AOTCI classes must be automatically
> recognized. This latest revision implements that model.
>
> I intentionall
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
On Tue, 8 Jul 2025 16:28:45 GMT, ExE Boss wrote:
>> 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]
On Mon, 7 Jul 2025 23:21:58 GMT, Chen Liang wrote:
> 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](ht
On Tue, 8 Jul 2025 05:18:31 GMT, Jaikiran Pai 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
On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke wrote:
> This PR aims to Panamize the Java Kqueue implementation, This is based on the
> work that was previously shared in https://github.com/openjdk/jdk/pull/22307
> , The main change since then is that this branch takes advantage of the
> cha
This PR aims to Panamize the Java Kqueue implementation, This is based on the
work that was previously shared in https://github.com/openjdk/jdk/pull/22307 ,
The main change since then is that this branch takes advantage of the changes
made in https://github.com/openjdk/jdk/pull/25043 to allow fo
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
Thanks Kim!
-
Marked as reviewed by vklang (Reviewer).
PR Review: https://git.open
On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke wrote:
> This PR aims to Panamize the Java Kqueue implementation, This is based on the
> work that was previously shared in https://github.com/openjdk/jdk/pull/22307
> , The main change since then is that this branch takes advantage of the
> cha
On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke wrote:
> This PR aims to Panamize the Java Kqueue implementation, This is based on the
> work that was previously shared in https://github.com/openjdk/jdk/pull/22307
> , The main change since then is that this branch takes advantage of the
> cha
On Sat, 31 May 2025 02:07:40 GMT, Chen Liang wrote:
>> This PR aims to Panamize the Java Kqueue implementation, This is based on
>> the work that was previously shared in
>> https://github.com/openjdk/jdk/pull/22307 , The main change since then is
>> that this branch takes advantage of the cha
On Thu, 19 Jun 2025 08:19:55 GMT, Per Minborg wrote:
>> This PR aims to Panamize the Java Kqueue implementation, This is based on
>> the work that was previously shared in
>> https://github.com/openjdk/jdk/pull/22307 , The main change since then is
>> that this branch takes advantage of the ch
On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke wrote:
> This PR aims to Panamize the Java Kqueue implementation, This is based on the
> work that was previously shared in https://github.com/openjdk/jdk/pull/22307
> , The main change since then is that this branch takes advantage of the
> cha
> 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 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 Tue, 8 Jul 2025 10:21:03 GMT, erifan wrote:
>>> predicate cannot be negated AND the vector is all ones. Can you explain
>>> this condition?
>>
>> Ok, I'll add a comment for it.
>>
>>> Why do you guard against VectorNode::is_all_ones_vector(in2) at all?
>>
>> Because one of the nodes in the
On Tue, 8 Jul 2025 11:41:01 GMT, Emanuel Peter wrote:
>> The purpose of this PR is optimizing the following kinds of patterns:
>>
>> XXXVector va, vb;
>> va.compare(EQ, vb).not()
>>
>> And the generated IR of `va.compare(EQ, vb).not()` is `(XorVMask
>> (VectorMaskCmp va vb EQ) (MaskAll -1))`.
On Tue, 8 Jul 2025 06:00:38 GMT, erifan wrote:
>> 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))
>> => (VectorMas
On Tue, 8 Jul 2025 01:49:14 GMT, David Holmes wrote:
>> Sorry for waiting so long. It's become clear that I won't be able to get awt
>> and accessibility up to speed for a long time, so I will go ahead with this
>> one first
>
> @TheShermanTanker the commented out code really should have been d
On Tue, 8 Jul 2025 04:59:04 GMT, Jaikiran Pai 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 http
On Tue, 8 Jul 2025 04:20:32 GMT, Jaikiran Pai wrote:
> > Since your change was applied there have been 3762 commits pushed to the
> > master branch
>
> It's usually risky to be integrating a PR which is so far behind the master
> branch, without first merging the latest changes and running the
On Tue, 8 Jul 2025 09:07:00 GMT, Xiaohong Gong wrote:
> > > > Hi @XiaohongGong, is there any way we can implement 2HF -> 2S and 2S ->
> > > > 2HF in these match rules ?
> > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#
On Tue, 8 Jul 2025 09:00:53 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 vect
On Tue, 8 Jul 2025 09:49:30 GMT, erifan wrote:
>> Thanks for your answers @erifan !
>>
>> Can you please answer these as well?
>>
>>> predicate cannot be negated AND the vector is all ones. Can you explain
>>> this condition?
>>
>> A code comment would be helpful for this case. I'm a little b
On Tue, 8 Jul 2025 08:56:44 GMT, Emanuel Peter wrote:
> predicate cannot be negated AND the vector is all ones. Can you explain this
> condition?
Ok, I'll add a comment for it.
> Why do you guard against VectorNode::is_all_ones_vector(in2) at all?
Because one of the nodes in the supported pat
>I understand that explicit API contracts are what matters. My concern,
>however, is that even if the API contract explicitly states no happens-before
>guarantee upon an unchecked exception, this behavior would still be a
>significant deviation from established visibility standards in other JDK
On Mon, 7 Jul 2025 16:33:22 GMT, Chen Liang wrote:
> Can `get` and `slowGet` be refactored to use this `findBinding` too?
Not really, no. Inlining is critical here, and `get()` is written in this way
for efficiency of generated code.
-
PR Comment: https://git.openjdk.org/jdk/pull
On Tue, 8 Jul 2025 09:00:53 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
On Tue, 8 Jul 2025 08:18:57 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 `c
On Tue, 8 Jul 2025 05:56:58 GMT, erifan wrote:
>> The current testing status for the conditions you listed:
>>> 1. Not MaskCmp.
>>
>> **No test for it, tested locally**, Because I think this condition is too
>> straightforward.
>>
>>> 2. More than one use.
>>
>> **Tested**, see `VectorMaskCom
On Mon, 7 Jul 2025 23:21:58 GMT, Chen Liang wrote:
> 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](ht
On Tue, 8 Jul 2025 01:55:55 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 `cha
On Tue, 8 Jul 2025 01:55:55 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
56 matches
Mail list logo
