On Sat, 31 May 2025 17:27:30 GMT, Ian Graves wrote:
>> Removing incorrect assumptions and assertions from a breaking test related
>> to https://bugs.openjdk.org/browse/JDK-8358218
>
> Ian Graves has updated the pull request with a new target base due to a merge
> or a rebase. The pull request n
On Sat, 31 May 2025 13:14:17 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which fixes the problem listing
> entry for the `jdk/incubator/vector/PreferredSpeciesTest.java#id0` test which
> has been failing in our CI?
>
> tier1 testing with this change is currently in prog
On Thu, 29 May 2025 22:03:29 GMT, Ian Graves wrote:
>> VectorShape#largestShapeFor is referenced in existing JavaDoc but has been
>> package-private. This propose change makes it public and adds documentation
>> for it.
>
> Ian Graves has updated the pull request incrementally with one addition
On Wed, 28 May 2025 21:22:30 GMT, Ian Graves wrote:
> VectorShape#largestShapeFor is referenced in existing JavaDoc but has been
> package-private. This propose change makes it public and adds documentation
> for it.
Can you add something to the method testVectorShape in
test/jdk/jdk/incubato
Thank you Archie, nicely expressed.
The discussions in this thread will help us write a crisper set of
goals/non-goals and a clearer motivation for the to-be-written JEP.
Paul.
On May 21, 2025, at 10:03 AM, Archie Cobbs wrote:
On Wed, May 21, 2025 at 11:30 AM Paul Sandoz
mailto:paul.san
It was a design choice to be consistent with each json value having an X,
accepting X in on construction and producing X out (notionally) on
deconstruction, which leans into pattern matching. Definitely pros/cons to that
e.g., we could instead make JonObject implement Map, or do as you suggest [
I consider this a “known unknown” (in the words of Mr. Rumsfeld). We would need
to explore this area throughly, which includes the interconnection with
Serialization 2.0, before we really know what we can and should do in the near
and long term. That’s a significant effort, and I would like to s
Data binding is a complex feature, even if some examples make it appear simple.
Our intention is to explore alignment with the serialization 2.0 effort, when
we are ready to so. Hence, I would urge folks to be patience and watch out
Brian and Viktor’s Devoxx 2024 talk on the topic.
Paul.
> On
JEP 198 will likely be withdrawn and a new JEP will be drafted aligned with the
document sent in this email thread.
It’s a not a goal to solve the dependency problem (a very hard problem!) even
in a narrow sense.
A potential advantage that we (the OpenJDK community) can more easily do is
devis
object member.
(but still wouldn't solve for absent ones - I have a doc somewhere with like 15
options none of which inspire joy and many of which are conditional on exactly
how patterns ship)
On Mon, May 19, 2025, 3:55 PM Paul Sandoz
mailto:paul.san...@oracle.com>> wrote:
>
&
specified for
implementations of List.
Paul.
On May 19, 2025, at 1:56 PM, fo...@univ-mlv.fr wrote:
From: "Paul Sandoz"
To: "Remi Forax"
Cc: "Brian Goetz" , "core-libs-dev"
Sent: Monday, May 19, 2025 10:02:50 PM
Subject:
Hi Cay,
It would be really helpful to share some more detailed use-cases on
editing/modification that you may reasonably expect users to perform.
I hope we might be able to devise a transformation API, hopefully layered on
top of the public API and possibly with structural sharing for unmodifie
The approach to the design of this API leans heavily on ongoing and future
language and library features. This is why the API is so small as we don’t want
conflicts with what we may do in the future. In the document we briefly mention
data binding but don’t provide further context:
Advanced fea
On May 19, 2025, at 8:16 AM, Remi Forax wrote:
Okay,
i've taken a look to the design and this is not pretty.
That seems an exaggerated statement to me. It's a trade-off, a compromise,
allowing others to implement their own parsers, perhaps from non-textual
representations. So of course we c
On May 17, 2025, at 4:37 AM, Ethan McCue wrote:
I think it's worth noting that the way you used the prospective API in your
ONNX code is not representative of how the API would generally be used in a
jdk-only scenario. Custom making a general transformation from JsonValue ->
Record is outsid
>
> This is part of why fromUntyped/toUntyped is uncomfortable - it's choosing
> one particular encoding of JSON and making it central to the API. Is that
> really the most important encoding?
>
It's one opinionated kind, a simple bi-directional mapping
(embedding-projection pair) based on
Hi,
We would like to share with you our thoughts and plans towards a JSON API for
the JDK.
Please see the document below.
-
We have had the pleasure of using a clone of this API in some experiments we
are conducting with
ONNX and code reflection [1]. Using the API we were able to quickly writ
On Mon, 28 Apr 2025 19:41:28 GMT, Vladimir Ivanov wrote:
> Both SVML and SLEEF libraries reuse 128-bit versions for vector of 2 floats.
> Usually, only `Float64Vector` shape satisfies that condiditon, but
> with`-XX:MaxVectorSize=8` `FloatMaxVector` becomes 2 element vector as well.
>
> Adjus
On Wed, 16 Apr 2025 19:29:07 GMT, Vladimir Ivanov wrote:
>> Migrate Vector API math library (SVML and SLEEF) linkage from native code
>> (in JVM) to Java FFM API.
>>
>> Since FFM API doesn't support vector calling conventions yet, migration
>> affects only symbol lookup for now. But it still e
On Wed, 16 Apr 2025 21:27:32 GMT, Vladimir Ivanov wrote:
> Both `CPUFeatures.validateFeatures` and the checks it performs are
> assertions, so it has to be explicitly enabled by `-esa`. The assert
> validates some assumptions the code has about the format of features string
> VM produces. And
On Fri, 11 Apr 2025 21:23:52 GMT, Vladimir Ivanov wrote:
>> Migrate Vector API math library (SVML and SLEEF) linkage from native code
>> (in JVM) to Java FFM API.
>>
>> Since FFM API doesn't support vector calling conventions yet, migration
>> affects only symbol lookup for now. But it still e
On Fri, 21 Mar 2025 17:38:53 GMT, Ian Graves wrote:
> Adding ForceInline to helper methods.
Marked as reviewed by psandoz (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/24165#pullrequestreview-2707336821
On Tue, 25 Mar 2025 20:44:31 GMT, Ian Graves wrote:
> Updating Javadoc for vector operators with VO_NOFP flags, but no
> corresponding "Integral only." note in docs.
src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java
line 455:
> 453: /** Produce {@code -a}. *
On Tue, 25 Mar 2025 21:56:24 GMT, Ian Graves wrote:
>> Updating Javadoc for vector operators with VO_NOFP flags, but no
>> corresponding "Integral only." note in docs.
>
> Ian Graves has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Missing
On Tue, 25 Mar 2025 15:52:07 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revamp toString() methods
src/java.base/share/classes/java/l
On Thu, 27 Feb 2025 06:43:19 GMT, Xiaohong Gong wrote:
> Method `checkMaskFromIndexSize` is called by some vector masked APIs like
> `fromArray/intoArray/fromMemorySegment/...`. It is used to check whether the
> index of any active lanes in a mask will reach out of the boundary of the
> given
On Tue, 25 Feb 2025 23:11:30 GMT, Chen Liang wrote:
> Indeed, the byte access currently only supports read/write (automatically
> aligned). No CAS or bitwise for now in FFM.
Do you know why that is so?
-
PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2683738533
On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang wrote:
>> Simplify the layout access var handles to be direct in some common cases.
>> Also made `VarHandle::isAccessModeSupported` report if an access mode is
>> supported for a VH.
>>
>> Reduces the instructions to execute this code in a simple ma
On Mon, 17 Feb 2025 06:40:11 GMT, Nicole Xu wrote:
>> Please try with following command line
>> `java -jar target/benchmarks.jar -f 1 -i 2 -wi 1 -w 30 -p ARRAYLEN=30
>> MaskedLogic`
>
> Thanks for pointing that out. Typically, ARRAYLEN is almost always a POT
> value, which is also assumed by ma
Hi Fabian,
Thanks for sharing and reaching out with the idea before getting too beholden
to it.
I logged this is quite a while ago. It seemed like a possible good idea at the
time, although I never liked the duplication of suppliers. I have become less
enthusiastic overtime, especially so as G
On Tue, 11 Feb 2025 06:32:56 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> This patch adds C2 compiler support for various Float16 operations added by
>> [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>>
>> Following is the summary of changes included with this patch:-
>>
>> 1. Detection
On Tue, 4 Feb 2025 10:05:09 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> This patch adds C2 compiler support for various Float16 operations added by
>> [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>>
>> Following is the summary of changes included with this patch:-
>>
>> 1. Detection o
I would like to amplify this point — undermining Java’s integrity is a big
deal. Every time we use unsafe mechanisms within the JDK we risk doing that.
The more complex such code is the harder it is reason about whether overall it
is safe [*]. We need to balance reasoning about code, quality, an
On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang wrote:
> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to
> byte arrays via VarHandle. This larger access speeds up many operations, yet
> it cannot be used in early bootstrap, and as a result, people tend to use
> `Unsafe`
On Tue, 14 Jan 2025 13:07:27 GMT, Jatin Bhateja wrote:
> Given the above observations passing 3 additional box arguments to intrinsic
> and returning a box value needs additional changes in the compiler while
> minor re-structuring in Java implementation packed with in the glue logic
> looks l
On Mon, 13 Jan 2025 09:02:24 GMT, Jatin Bhateja wrote:
>> Uncertain on what bits, but i am guessing it's mostly related to the
>> fallback code in the lambda. To avoid the intrinsics operating on Float16
>> instances we instead "unpack" the carrier (16bits) values and pass those as
>> argument
On Thu, 9 Jan 2025 13:23:19 GMT, Emanuel Peter wrote:
>> Jatin Bhateja has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request contains one
>> new com
On Mon, 6 Jan 2025 09:12:01 GMT, SendaoYan wrote:
> Hi all,
> This PR add JVM option `jvmArgs={"--add-modules=jdk.incubator.vector"}` for
> test/micro/org/openjdk/bench/jdk/incubator/vector/SpiltReplicate.java, to fix
> test bug which cause jmh test fails 'java.lang.NoClassDefFoundError:
> j
On Thu, 19 Dec 2024 17:26:50 GMT, Nizar Benalla wrote:
>> Please review this doc-only patch to avoid some unwanted failures in our
>> HTML checks.
>>
>> Javadoc wraps everything under `@param` in a ``, so having an `h2` tag
>> there trips some of our tests that use html validators (html-tidy
On Thu, 19 Dec 2024 17:26:50 GMT, Nizar Benalla wrote:
>> Please review this doc-only patch to avoid some unwanted failures in our
>> HTML checks.
>>
>> Javadoc wraps everything under `@param` in a ``, so having an `h2` tag
>> there trips some of our tests that use html validators (html-tidy
On Wed, 18 Dec 2024 17:44:02 GMT, Paul Sandoz wrote:
>> Hi,
>>
>> This patch adds the missing null checks to the shuffle arguments of the
>> various `rearrangeTemplate` method. For all other API points, we null check
>> arguments by calling `check` on them. As `r
On Wed, 18 Dec 2024 16:22:51 GMT, Quan Anh Mai wrote:
> Hi,
>
> This patch adds the missing null checks to the shuffle arguments of the
> various `rearrangeTemplate` method. For all other API points, we null check
> arguments by calling `check` on them. As `rearrange` implementations cast the
On Tue, 17 Dec 2024 00:08:10 GMT, Paul Sandoz wrote:
> This pull request contains a backport of commit
> [31c3b191](https://github.com/openjdk/jdk/commit/31c3b191745b5c97ae4e757323355fb9831da9fe)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit b
On Mon, 16 Dec 2024 18:47:50 GMT, Joe Darcy wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adding more test points
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line
> 1415:
>
>>
This pull request contains a backport of commit
[31c3b191](https://github.com/openjdk/jdk/commit/31c3b191745b5c97ae4e757323355fb9831da9fe)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Paul Sandoz on 16 Dec 2024 and was
reviewed by
On Fri, 13 Dec 2024 18:42:27 GMT, Paul Sandoz wrote:
> Add functional support for unsigned min/max reductions on vectors.
>
> We also need to ensure that the `reductionCoerced` intrinsic bails out when
> there is no reduction operation for the lanewise operation. When intrinsic
> On Dec 10, 2024, at 4:54 PM, Vladimir Ivanov
> wrote:
>
>
>
> On 12/9/24 07:55, Paul Sandoz wrote:
>> Some further observations.
>> - This arguably makes it harder for the auto-vectorize to access the
>> SVML/SLEEF functionality. However, in comes cas
On Tue, 10 Dec 2024 16:10:09 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly
>> just the revert of the backout.
>>
>> Regarding the related issues:
>>
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and
>> [JDK-83
On Mon, 9 Dec 2024 14:12:19 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly
>> just the revert of the backout.
>>
>> Regarding the related issues:
>>
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and
>> [JDK-830
Some further observations.
- This arguably makes it harder for the auto-vectorize to access the SVML/SLEEF
functionality. However, in comes cases, we cannot guarantee the same guarantees
(IIRC mainly around monotonicity) as the scalar operations in Math.
- There is an open bug to adjust the sim
Hi Vladimir,
Excellent work, very happy to see more of this moved to Java leveraging Panama
features. The Java code looks very organized.
I am wondering if this technique can be applied to stubs dynamically generated
by HotSpot via some sort of special library lookup e.g., for crypto.
Do you h
On Tue, 26 Nov 2024 18:17:05 GMT, Quan Anh Mai wrote:
>> @merykitty Could you please merge with the latest and resolve conflicts?
>
> @sviswa7 @PaulSandoz @eme64 @jatin-bhateja Thanks for taking a look, I have
> merged the PR with a more recent master and resolved the sematic difference
> with
On Fri, 6 Dec 2024 17:00:15 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly
>> just the revert of the backout.
>>
>> Regarding the related issues:
>>
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and
>> [JDK-830
On Thu, 5 Dec 2024 20:36:48 GMT, Paul Sandoz wrote:
>> The cast is added so that we have the concrete type of the shuffle, the
>> result of `toShuffle` is only `VectorShuffle`
>
> Ah i see now, you want to ensure an invocation to the final/concrete method.
> (The IDE&
On Fri, 6 Dec 2024 09:14:07 GMT, Quan Anh Mai wrote:
>> I incorrectly read `!=` as `==` :-) as that is the more common pattern used
>> in the code base, so i was thinking the power of two code path was using
>> `shuffleFromOp`. Could you invert the check to be more consistent?
>
> This piece of
On Tue, 26 Nov 2024 18:15:47 GMT, Quan Anh Mai wrote:
>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java
>> line 228:
>>
>>> 226: }
>>> 227:
>>> 228: AbstractVector iota = vspecies().asIntegral().iota();
>>
>> I suspect the non-power of two code
On Tue, 26 Nov 2024 18:11:59 GMT, Quan Anh Mai wrote:
>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java
>> line 870:
>>
>>> 868: @Override
>>> 869: public final Int256Shuffle rearrange(VectorShuffle
>>> shuffle) {
>>> 870: return (Int2
On Sat, 23 Nov 2024 13:41:24 GMT, Piotr Tarsa wrote:
> Could you add some code that disables the AVX512 version on Zen4, but keeps
> it enabled on Zen5 and future Zen architectures?
Or as you suggest
[here](https://github.com/intel/x86-simd-sort/issues/6#issuecomment-2506476505)
revert to AVX
On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja wrote:
> Hi All,
>
> This patch adds C2 compiler support for various Float16 operations added by
> [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>
> Following is the summary of changes included with this patch:-
>
> 1. Detection of vario
On Thu, 17 Oct 2024 21:33:03 GMT, Joe Darcy wrote:
>
> Before the work in this PR proceeds, I think the java.lang ->
> jdk.incubator.vector move of Float16 should occur first. This will allow
> leaner reviews and better API separation. I can get an updated PR of the move
> prepared within the
On Fri, 25 Oct 2024 04:46:52 GMT, Jatin Bhateja wrote:
>> Hi Jatin, could you also include the idealization tests here -
>> test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java and
>> ConvF2HFIdealizationTests.java in this PR?
>
>> Hi Jatin, could you also include the idealiza
On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja wrote:
> Hi All,
>
> This patch adds C2 compiler support for various Float16 operations added by
> [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>
> Following is the summary of changes included with this patch:-
>
> 1. Detection of vario
On Fri, 15 Nov 2024 01:02:49 GMT, Joe Darcy wrote:
> Looks fine; please manually verify the expected javac warnings are given for
> misuse of Float16 in non-value ways.
I manually and successfully tested compilation and execution of source that
synchronized on an instance of Float16.
On Fri, 15 Nov 2024 00:25:20 GMT, Paul Sandoz wrote:
> Annotate `Float16` with `jdk.internal.ValueBased`. This requires we export
> the package `jdk.internal` in module `java.base` to module`
> jdk.incubator.vector`.
>
> Doing so enables the compiler and runtime to report
Annotate `Float16` with `jdk.internal.ValueBased`. This requires we export the
package `jdk.internal` in module `java.base` to module` jdk.incubator.vector`.
Doing so enables the compiler and runtime to report warnings about improper
attempts to synchronize on instances of `Float16`, as describe
On Wed, 13 Nov 2024 06:40:15 GMT, Joe Darcy wrote:
>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java
>> line 91:
>>
>>> 89: // JEP-401 (https://openjdk.org/jeps/401).
>>> 90: // @jdk.internal.MigratedValueClass
>>> 91: // @jdk.internal.ValueBased
>>
>> Please uncommen
On Sun, 6 Oct 2024 08:32:20 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly
>> just the revert of the backout.
>>
>> Regarding the related issues:
>>
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and
>> [JDK-830
On Thu, 24 Oct 2024 13:36:50 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> for following new vector operators.
>>
>>
>> . SUADD : Saturating unsigned addition.
>> . SADD: Saturating signed addition.
>
On Thu, 24 Oct 2024 14:07:34 GMT, Jatin Bhateja wrote:
>> @PaulSandoz do you think this is sufficient coverage?
>
> Please note this test was added just to cover scalar operation validation in
> VectorMath, automated tests exercise these APIs in fallback implementation
> anyways.
I think the c
On Thu, 24 Oct 2024 13:41:13 GMT, Emanuel Peter wrote:
>> To exercise non memory operand pattern we need a vector operation padding
>> layer after load vector, this will always ensure that selector pick all
>> register operands flavor of instruction. Since its a generic limitation, do
>> you t
On Thu, 24 Oct 2024 13:31:00 GMT, Jatin Bhateja wrote:
>> Also: why did we not add these `Long.minUnsigned` etc? I guess that was
>> already discussed?
>> Because we can easily also use this with the auto-vectorizer or more
>> generally. Saturating and unsigned ops are generally useful I think.
On Wed, 23 Oct 2024 15:46:31 GMT, Joe Darcy wrote:
>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java
>> line 865:
>>
>>> 863: public static Float16 min(Float16 a, Float16 b) {
>>> 864: return
>>> shortBitsToFloat16(floatToFloat16(Math.min(a.floatValue(),
>
On Mon, 21 Oct 2024 17:07:35 GMT, Joe Darcy wrote:
>> Port of Float16 from java.lang in the lworld+fp16 branch to
>> jdk.incubabor.vector.
>
> Joe Darcy has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the unrelated changes brough
On Mon, 21 Oct 2024 12:25:46 GMT, Jatin Bhateja wrote:
> Can you kindly run this though your test infrastructure and approve if it
> goes fine ?
>
Internal tier 1 to 3 testing passed (i needed to merge with master at
7133d1b983d, due to some updates to unrelated test configuration files the te
On Mon, 21 Oct 2024 12:25:37 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> for following new vector operators.
>>
>>
>> . SUADD : Saturating unsigned addition.
>> . SADD: Saturating signed addition.
>
On Thu, 17 Oct 2024 23:35:36 GMT, Paul Sandoz wrote:
> > I have restricted the IR validation to just newly added UMin/UMax
> > transformations.
>
> Even then i think it better to do so in follow on PR, otherwise it is a
> moving target for review and testing. This new
On Thu, 17 Oct 2024 18:23:12 GMT, Jatin Bhateja wrote:
> I have restricted the IR validation to just newly added UMin/UMax
> transformations.
Even then i think it better to do so in follow on PR, otherwise it is a moving
target for review and testing. This new test fails on aarch64 e.g.,
STA
On Wed, 16 Oct 2024 17:29:04 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> for following new vector operators.
>>
>>
>> . SUADD : Saturating unsigned addition.
>> . SADD: Saturating signed addition.
>
On Tue, 15 Oct 2024 10:19:46 GMT, Emanuel Peter wrote:
> Are there any IR rules that verify that the correct C2 nodes are used? Is
> that a thing you generally do with the VectorAPI, just to make sure things
> get correctly intrinsified?
Not systematically. We have some IR testing for more com
On Tue, 15 Oct 2024 16:39:57 GMT, Paul Sandoz wrote:
> > Hi @vnkozlov , Can you kindly run this through your test infrastructure. We
> > have two review approvals for Java and x86 backend code.
>
> I have kicked off some internal tests (FYI @vnkozlov)
Tier 1 to 3 test pa
On Tue, 15 Oct 2024 16:03:13 GMT, Paul Sandoz wrote:
> > I gave it a quick scan, and I have no further comments. LGTM.
>
> Thank you, i will kick off an internal test.
Tier 1 to 3 tests pass.
-
PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2415121395
On Sun, 13 Oct 2024 09:57:00 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> for following new vector operators.
>>
>>
>> . SUADD : Saturating unsigned addition.
>> . SADD: Saturating signed addition.
>
On Thu, 10 Oct 2024 16:24:35 GMT, Jatin Bhateja wrote:
> Hi @vnkozlov , Can you kindly run this through your test infrastructure. We
> have two review approvals for Java and x86 backend code.
I have kicked off some internal tests (FYI @vnkozlov)
-
PR Comment: https://git.openjdk.o
On Tue, 15 Oct 2024 09:35:23 GMT, Emanuel Peter wrote:
> I gave it a quick scan, and I have no further comments. LGTM.
Thank you, i will kick off an internal test.
-
PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2414431367
On Sun, 13 Oct 2024 11:18:01 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> for following new two vector permutation APIs.
>>
>>
>> Declaration:-
>> Vector.selectFrom(Vector v1, Vector v2)
>>
>>
>> Semantics:-
>>
On Thu, 3 Oct 2024 19:05:14 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> for following new two vector permutation APIs.
>>
>>
>> Declaration:-
>> Vector.selectFrom(Vector v1, Vector v2)
>>
>>
>> Semantics:-
>>
On Fri, 4 Oct 2024 00:01:59 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> for following new vector operators.
>>
>>
>> . SUADD : Saturating unsigned addition.
>> . SADD: Saturating signed addition.
>>
y in a follow-up patch.
>>
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Doc fixups
src/jdk.incubator.vector/share/classes/jdk/incubator/v
On Thu, 3 Oct 2024 19:13:22 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> for following new vector operators.
>>
>>
>> . SUADD : Saturating unsigned addition.
>> . SADD: Saturating signed addition.
>>
On Wed, 2 Oct 2024 14:02:19 GMT, Maurizio Cimadamore
wrote:
>> The fix for JDK-8331865 introduced an accidental performance regression.
>> The main issue is that now *all* memory segment var handles go through some
>> round of adaptation.
>> Adapting a var handle results in a so called *indirec
On Sat, 28 Sep 2024 17:37:10 GMT, Sandhya Viswanathan
wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Handling NPOT vector length for AArch64 SVE with vector sizes varying b/w
>> 128 and 2048 bits at 128 bit inc
On Thu, 19 Sep 2024 06:53:15 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> for following new vector operators.
>>
>>
>> . SUADD : Saturating unsigned addition.
>> . SADD: Saturating signed addition.
>
On Tue, 17 Sep 2024 16:13:55 GMT, Quan Anh Mai wrote:
> Hi,
>
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just
> the revert of the backout.
>
> Regarding the related issues:
>
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and
> [JDK-8309531](ht
On Tue, 17 Sep 2024 16:13:55 GMT, Quan Anh Mai wrote:
> Hi,
>
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just
> the revert of the backout.
>
> Regarding the related issues:
>
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and
> [JDK-8309531](ht
On Wed, 18 Sep 2024 16:22:30 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> following new vector operators.
>>
>>
>> . SUADD : Saturating unsigned addition.
>> . SADD: Saturating signed addition.
>>
On Wed, 18 Sep 2024 14:22:16 GMT, Emanuel Peter wrote:
> > > Why is this even called `VectorMath`? Because those ops are not at all
> > > restricted to vectorization, right?
> >
> >
> > Nomenclature is suggested by Paul.
>
> @PaulSandoz Do you want to limit these **scalar** operations to a cl
On Tue, 17 Sep 2024 16:59:07 GMT, Quan Anh Mai wrote:
> @PaulSandoz What do you think regarding x86-32?
I don't see anything obvious in the changes of this PR that would affect
x86-32, but i ain't a HotSpot expert. Perhaps this just exacerbates some
existing bug?@sviswa7 what do you think?
My
On Thu, 22 Aug 2024 18:43:56 GMT, Paul Sandoz wrote:
> Adding link to UTF-8 decoding use case for convenience and reminder:
> https://github.com/AugustNagro/utf8.java/blob/master/src/main/java/com/augustnagro/utf8/Utf8.java.
Another related link to base 64 decoding https://github.com/s
On Tue, 17 Sep 2024 07:02:12 GMT, Jatin Bhateja wrote:
>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template
>> line 2974:
>>
>>> 2972: final $abstractvectortype$ selectFromTemplate(Class>> Vector<$Boxbitstype$>> indexVecClass,
>>> 2973:
On Tue, 17 Sep 2024 07:02:15 GMT, Jatin Bhateja wrote:
>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template
>> line 561:
>>
>>> 559: for (int i = 0; i < vlen; i++) {
>>> 560: int index = ((int)vecPayload1[i]);
>>> 561: res[i] = in
1 - 100 of 433 matches
Mail list logo
