Re: RFR: 8318650: Optimized subword gather for x86 targets. [v11]

2024-02-01 Thread Quan Anh Mai
On Fri, 2 Feb 2024 03:34:38 GMT, Jatin Bhateja wrote: >> Hi @sviswa7 , I have rolled back to originally proposed solution. > >> I don't think Lilliput will relax the array alignment to below 4 bytes since >> the array length needs to be aligned at that. > > HI @merykitty > > Lilliput wiki

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v11]

2024-02-01 Thread Quan Anh Mai
On Thu, 1 Feb 2024 00:28:26 GMT, Paul Sandoz wrote: >> I guess the fact that the Java objects are 8 byte alignment padded and the >> alignment being done at lines 1609-1611 and 1616-1621 somehow takes care of >> this. > > Drive by comment, that can change with Project Lilliput. I don't think

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v7]

2024-01-25 Thread Quan Anh Mai
`MemorySessionImpl::checkValidStateRaw` to eliminate the > lifetime check on global sessions without imposing additional branches on > other non-global sessions. This is similar to `__builtin_constant_p` in GCC > and clang. > > Please kindly give your opinion as well as your reviews, th

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-25 Thread Quan Anh Mai
On Thu, 25 Jan 2024 05:06:12 GMT, David Holmes wrote: >> I agree. All values are produced by evaluating expressions. In this case we >> want to query whether a value produced by the compiler evaluating its >> expression is a constant value (inputs to the expression are constants and >> the

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v6]

2024-01-25 Thread Quan Anh Mai
On Thu, 25 Jan 2024 12:52:21 GMT, Maurizio Cimadamore wrote: >>> > Naive question: the right way to use this would be almost invariably be >>> > like this: >>> > ``` >>> > if (isCompileConstant(foo) && fooHasCertainStaticProperties(foo)) { >>> > // fast-path >>> > } >>> > // slow path >>>

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v6]

2024-01-24 Thread Quan Anh Mai
On Wed, 24 Jan 2024 18:56:15 GMT, Aleksey Shipilev wrote: >>> Naive question: the right way to use this would be almost invariably be >>> like this: >>> >>> ``` >>> if (isCompileConstant(foo) && fooHasCertainStaticProperties(foo)) { >>> // fast-path >>> } >>> // slow path >>> ``` >>> >>>

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-24 Thread Quan Anh Mai
On Wed, 24 Jan 2024 09:03:43 GMT, Aleksey Shipilev wrote: >> That sounds like a better name for the class, although I think >> `jdk.internal.misc` is more suitable than `jdk.internal.vm`. Do you have any >> preference? Thanks. > > +1 to `ConstantSupport`. I think `jdk.internal.vm` is a proper

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v6]

2024-01-24 Thread Quan Anh Mai
`MemorySessionImpl::checkValidStateRaw` to eliminate the > lifetime check on global sessions without imposing additional branches on > other non-global sessions. This is similar to `__builtin_constant_p` in GCC > and clang. > > Please kindly give your opinion as well as your reviews, th

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-23 Thread Quan Anh Mai
On Wed, 24 Jan 2024 06:27:20 GMT, David Holmes wrote: >> I think of this as an expression that is always evaluated to the same value. >> The value itself is not interesting, it is the set of values that this >> expression can take that we are talking about. > > This seems really weird to me

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-23 Thread Quan Anh Mai
On Tue, 23 Jan 2024 20:01:45 GMT, Paul Sandoz wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> ident > > src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 32: >

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-23 Thread Quan Anh Mai
On Tue, 23 Jan 2024 17:42:40 GMT, Aleksey Shipilev wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> ident > > src/java.base/share/classes/jdk/internal/misc/JitCompiler.java li

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-23 Thread Quan Anh Mai
On Tue, 23 Jan 2024 17:40:52 GMT, Aleksey Shipilev wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> ident > > src/java.base/share/classes/jdk/internal/misc/JitCompiler.java li

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v3]

2024-01-23 Thread Quan Anh Mai
On Tue, 23 Jan 2024 16:01:05 GMT, Aleksey Shipilev wrote: >> Would it be possible to list further examples where this might be used? >> Asking because I'm wondering about the usability and maintainability of >> if-then-else code. > >> Would it be possible to list further examples where this

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-23 Thread Quan Anh Mai
`MemorySessionImpl::checkValidStateRaw` to eliminate the > lifetime check on global sessions without imposing additional branches on > other non-global sessions. This is similar to `__builtin_constant_p` in GCC > and clang. > > Please kindly give your opinion as well as your reviews, th

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v3]

2024-01-23 Thread Quan Anh Mai
On Tue, 23 Jan 2024 15:44:40 GMT, Aleksey Shipilev wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> add more overloads > > src/hotspot/share/classfile/vmIntr

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v4]

2024-01-23 Thread Quan Anh Mai
`MemorySessionImpl::checkValidStateRaw` to eliminate the > lifetime check on global sessions without imposing additional branches on > other non-global sessions. This is inspired by `std::is_constant_evaluated` > in C++. > > Please kindly give your opinion as well as your reviews, thanks ver

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v3]

2024-01-23 Thread Quan Anh Mai
On Tue, 23 Jan 2024 11:18:43 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch introduces `JitCompiler::isConstantExpression` which can be used >> to statically determine whether an expression has been constant-folded by >> the Jit compiler, leading to more

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v3]

2024-01-23 Thread Quan Anh Mai
`MemorySessionImpl::checkValidStateRaw` to eliminate the > lifetime check on global sessions without imposing additional branches on > other non-global sessions. This is inspired by `std::is_constant_evaluated` > in C++. > > Please kindly give your opinion as well as your reviews, thanks ver

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler

2024-01-23 Thread Quan Anh Mai
On Tue, 23 Jan 2024 08:16:07 GMT, Aleksey Shipilev wrote: > I would suggest we just do the private > `java.lang.{Integer,...}.isCompileConstant` methods and bind them to that > intrinsic. Maybe I am ignorant but doesn't the definition of an intrinsics contain the signature of the method as

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler

2024-01-23 Thread Quan Anh Mai
On Tue, 23 Jan 2024 08:16:07 GMT, Aleksey Shipilev wrote: >> Hi, >> >> This patch introduces `JitCompiler::isConstantExpression` which can be used >> to statically determine whether an expression has been constant-folded by >> the Jit compiler, leading to more constant-folding opportunities.

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v2]

2024-01-23 Thread Quan Anh Mai
`MemorySessionImpl::checkValidStateRaw` to eliminate the > lifetime check on global sessions without imposing additional branches on > other non-global sessions. This is inspired by `std::is_constant_evaluated` > in C++. > > Please kindly give your opinion as well as your reviews, thanks ver

RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler

2024-01-23 Thread Quan Anh Mai
Hi, This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to

Re: RFR: 8322768: Optimize non-subword vector compress and expand APIs for AVX2 target. [v3]

2024-01-08 Thread Quan Anh Mai
On Mon, 8 Jan 2024 06:06:22 GMT, Jatin Bhateja wrote: >> Thanks for the updates! >> >> One more idea: Your AVX2 solution has a lot of cost for converting the mask >> to a permutation. Might it make sense to split this off into a separate >> vector-node, so that it can float out of a loop if

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v7]

2023-11-21 Thread Quan Anh Mai
On Wed, 15 Nov 2023 02:17:58 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch optimizes sub-word gather operation for x86 targets with AVX2 and >> AVX512 features. >> >> Following is the summary of changes:- >> >> 1) Intrinsify sub-word gather with high performance backend

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v7]

2023-11-20 Thread Quan Anh Mai
On Wed, 15 Nov 2023 02:17:58 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch optimizes sub-word gather operation for x86 targets with AVX2 and >> AVX512 features. >> >> Following is the summary of changes:- >> >> 1) Intrinsify sub-word gather with high performance backend

Re: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2]

2023-11-05 Thread Quan Anh Mai
On Fri, 3 Nov 2023 23:22:27 GMT, Claes Redestad wrote: >> https://github.com/cassioneri/eaf suggest this code for leap year >> calculation: >> >> public static boolean isLeap(long year) { >> int d = year % 100 != 0 ? 4 : 16; >> return (year & (d - 1)) == 0; >> } >> >>

Re: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2]

2023-11-03 Thread Quan Anh Mai
On Fri, 3 Nov 2023 23:22:27 GMT, Claes Redestad wrote: >> https://github.com/cassioneri/eaf suggest this code for leap year >> calculation: >> >> public static boolean isLeap(long year) { >> int d = year % 100 != 0 ? 4 : 16; >> return (year & (d - 1)) == 0; >> } >> >>

Re: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2]

2023-11-03 Thread Quan Anh Mai
On Fri, 3 Nov 2023 23:22:27 GMT, Claes Redestad wrote: >> https://github.com/cassioneri/eaf suggest this code for leap year >> calculation: >> >> public static boolean isLeap(long year) { >> int d = year % 100 != 0 ? 4 : 16; >> return (year & (d - 1)) == 0; >> } >> >>

Re: RFR: 8315004: Runtime.halt() debug logging

2023-10-30 Thread Quan Anh Mai
On Tue, 31 Oct 2023 00:14:39 GMT, Masanori Yano wrote: >>> @AlanBateman Sorry for missing your comment on JBS. I can't find any >>> discussion of the need for logs in Runtime.halt in JDK-8301627, so I'm not >>> sure if it was intentional that no logging output was added to Runtime.halt. >>>

Re: RFR: 8254693: Add Panama feature to pass heap segments to native code [v12]

2023-10-27 Thread Quan Anh Mai
On Fri, 27 Oct 2023 03:49:17 GMT, Yasumasa Suenaga wrote: >> src/hotspot/cpu/x86/downcallLinker_x86_64.cpp line 110: >> >>> 108: __ mov(rsp, r12); // restore sp >>> 109: __ reinit_heapbase(); >>> 110: } >> >> This is a minor cleanup to share this code for the three use sites below. > >

Re: RFR: 8318678: Vector access on heap MemorySegments only works for byte[]

2023-10-25 Thread Quan Anh Mai
On Wed, 25 Oct 2023 13:08:06 GMT, Per Minborg wrote: > This PR proposes removing the restriction that only heap `MemorySegment` > wrapping a `byte` array can be accessed by Vectors. Now any array type can be > used provided the element alignment constraints are respected. Vector loads and

Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v42]

2023-10-13 Thread Quan Anh Mai
On Sat, 14 Oct 2023 03:21:52 GMT, himichael wrote: >>> my question is that this feature should improve performance several times, >>> but it doesn't look like there's much difference between open jdk 22.19 and >>> jdk 8. is there a problem with my configuration ? >> >> Hello @himichael, >>

Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v42]

2023-10-13 Thread Quan Anh Mai
On Fri, 13 Oct 2023 07:02:18 GMT, himichael wrote: >> Srinivas Vamsi Parasa has updated the pull request with a new target base >> due to a merge or a rebase. The pull request now contains 45 commits: >> >> - fix code style and formatting >> - Merge branch 'master' of

Re: RFR: 8317515: Unify the code of the parse*() families of methods in j.l.Integer and j.l.Long [v2]

2023-10-06 Thread Quan Anh Mai
On Fri, 6 Oct 2023 10:28:31 GMT, 温绍锦 wrote: >> Raffaello Giulietti has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Avoid localized integers in radix-out-of-range exception messages. > > The reason parseUnsignedInt(CharSequence s, int

Re: RFR: 8317515: Unify the code of the parse*() families of methods in j.l.Integer and j.l.Long [v2]

2023-10-06 Thread Quan Anh Mai
On Fri, 6 Oct 2023 09:53:46 GMT, Raffaello Giulietti wrote: >> Could we parse the signed int by parsing the unsigned suffix then prepend >> the sign? It will unify the code path of `parseInt` and `parseUnsignedInt`. >> >> Thanks. > > @merykitty For a `String` input that would mean copying

Re: RFR: 8317515: Unify the code of the parse*() families of methods in j.l.Integer and j.l.Long [v2]

2023-10-05 Thread Quan Anh Mai
On Thu, 5 Oct 2023 10:31:31 GMT, Raffaello Giulietti wrote: >> See the [JBS issue](https://bugs.openjdk.org/browse/JDK-8317515) for the >> details. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > Avoid localized

Re: RFR: 8317515: Unify the code of the parse*() families of methods in j.l.Integer and j.l.Long [v2]

2023-10-05 Thread Quan Anh Mai
On Thu, 5 Oct 2023 10:31:31 GMT, Raffaello Giulietti wrote: >> See the [JBS issue](https://bugs.openjdk.org/browse/JDK-8317515) for the >> details. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > Avoid localized

Re: RFR: 8310929: Optimization for Integer.toString [v20]

2023-09-06 Thread Quan Anh Mai
On Wed, 6 Sep 2023 16:51:51 GMT, 温绍锦 wrote: >> I'd be more comfortable replacing the use of Unsafe with either the >> ByteArray functions or VarHandles. >> Using VarHandles will enable future optimizations, whereas Unsafe is a >> primitive tool and is brittle. > >> I'd be more comfortable

Re: RFR: 8310929: Optimization for Integer.toString [v20]

2023-09-06 Thread Quan Anh Mai
On Tue, 5 Sep 2023 00:10:12 GMT, 温绍锦 wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test

Re: RFR: 8310929: Optimization for Integer.toString [v12]

2023-09-03 Thread Quan Anh Mai
On Thu, 20 Jul 2023 09:20:00 GMT, 温绍锦 wrote: >> src/java.base/share/classes/java/lang/Long.java line 527: >> >>> 525: /** >>> 526: * Places characters representing the long i into the >>> 527: * character array buf. The characters are placed into >> >> Add the array bound check

Re: RFR: 8310929: Optimization for Integer.toString [v13]

2023-07-26 Thread Quan Anh Mai
On Tue, 18 Jul 2023 01:49:17 GMT, 温绍锦 wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test

Re: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex, length, initialValue)

2023-07-13 Thread Quan Anh Mai
On Thu, 13 Jul 2023 08:44:02 GMT, Pavel Rappo wrote: >>> For an arbitrary int[], unconditional vectorization might be unwarranted or >>> puzzling. >> >> Could you clarify this statement? Thanks a lot. > >> > For an arbitrary int[], unconditional vectorization might be unwarranted >> > or

Re: RFR: 8307523: [vectorapi] Optimize MaskFromLongBenchmark.java

2023-05-05 Thread Quan Anh Mai
On Sat, 6 May 2023 02:01:20 GMT, Chang Peng wrote: > To avoid dead code elimination, a use-point laneIsSet() is added in each > benchmark method in MaskFromLongBenchmark.java. > > However, currently laneIsSet() [1] is implemented by toLong(). So it may > generate a fromLong-toLong pair [2],

Re: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v6]

2023-05-05 Thread Quan Anh Mai
On Tue, 25 Apr 2023 11:59:30 GMT, Jatin Bhateja wrote: >> src/hotspot/share/opto/vectorIntrinsics.cpp line 1914: >> >>> 1912: if (vector_klass->const_oop() == NULL || elem_klass->const_oop() == >>> NULL || >>> 1913: !vlen->is_con() || !origin_type->is_con()) { >>> 1914: if

Re: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v6]

2023-05-05 Thread Quan Anh Mai
On Tue, 11 Apr 2023 19:03:21 GMT, Vladimir Ivanov wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> style > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector

Re: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v6]

2023-05-05 Thread Quan Anh Mai
On Thu, 6 Apr 2023 01:45:37 GMT, Xiaohong Gong wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> style > > test/hotspot/jtreg/compiler/vectorapi/TestVectorSlice.java line

Integrated: 8306008: Several Vector API tests fail for client VM after JDK-8304450

2023-04-25 Thread Quan Anh Mai
On Tue, 18 Apr 2023 12:21:11 GMT, Quan Anh Mai wrote: > Hi, > > Please review this patch which fixes the errors on machines where > TypeMaxVector has a length of 64 bits. I take an extra cautious approach and > fall back to putting elements one by one if the length is an u

Re: RFR: 8306008: Several Vector API tests fail for client VM after JDK-8304450

2023-04-24 Thread Quan Anh Mai
On Tue, 18 Apr 2023 12:21:11 GMT, Quan Anh Mai wrote: > Hi, > > Please review this patch which fixes the errors on machines where > TypeMaxVector has a length of 64 bits. I take an extra cautious approach and > fall back to putting elements one by one if the length is an u

RFR: 8306008: Several Vector API tests fail for client VM after JDK-8304450

2023-04-18 Thread Quan Anh Mai
Hi, Please review this patch which fixes the errors on machines where TypeMaxVector has a length of 64 bits. I take an extra cautious approach and fall back to putting elements one by one if the length is an unexpected value. All jdk/incubator/vector tests passed with MaxVectorSize=8, which

Integrated: 8304450: [vectorapi] Refactor VectorShuffle implementation

2023-04-13 Thread Quan Anh Mai
On Sun, 19 Mar 2023 13:04:19 GMT, Quan Anh Mai wrote: > Hi, > > This patch reimplements `VectorShuffle` implementations to be a vector of the > bit type. Currently, VectorShuffle is stored as a byte array, and would be > expanded upon usage. This poses several drawbacks: >

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v7]

2023-04-12 Thread Quan Anh Mai
On Tue, 11 Apr 2023 17:47:56 GMT, Jatin Bhateja wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> special case iotaShuffle > > Marked as reviewed by jbhateja (Reviewer). @jatin-

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v6]

2023-04-11 Thread Quan Anh Mai
On Mon, 10 Apr 2023 15:16:59 GMT, Jatin Bhateja wrote: >> Yes I think it is a drawback of this approach, however currently we do not >> support shuffling for 256-bit vectors on AVX1 machines either, and AVX1 >> seems to be a special case in this regard. This species of float and double >> may

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v6]

2023-04-10 Thread Quan Anh Mai
On Mon, 10 Apr 2023 15:16:59 GMT, Jatin Bhateja wrote: >> Yes I think it is a drawback of this approach, however currently we do not >> support shuffling for 256-bit vectors on AVX1 machines either, and AVX1 >> seems to be a special case in this regard. This species of float and double >> may

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v6]

2023-04-10 Thread Quan Anh Mai
On Mon, 10 Apr 2023 15:11:55 GMT, Jatin Bhateja wrote: >> Thanks a lot for your review, I think that transforming a multiplication by >> a power of 2 into a shift can be done by the C2 compiler. I have added the >> special case for `start = 0 && step == 1` since it may be more common and >>

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v6]

2023-04-07 Thread Quan Anh Mai
On Fri, 7 Apr 2023 11:51:21 GMT, Jatin Bhateja wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> small cosmetics > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/A

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v6]

2023-04-07 Thread Quan Anh Mai
On Fri, 7 Apr 2023 13:36:22 GMT, Jatin Bhateja wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java >> line 226: >> >>> 224: >>> 225: AbstractSpecies species = vspecies().asIntegral(); >>> 226: Vector iota = species.iota(); >> >> we can do

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v7]

2023-04-07 Thread Quan Anh Mai
00075158ac88})} > vmovdqu 0x10(%r10),%xmm2 > vpxor %xmm0,%xmm0,%xmm0 > vpcmpgtd %xmm2,%xmm0,%xmm3 > vtestps %xmm3,%xmm3 > jne0x7fa818b27cb1 > vpermd %ymm1,%ymm2,%ymm0 > movabs $0x751588c68,%r10; {oop([I{0x000751588c68}

Integrated: 8305461: [vectorapi] Add VectorMask::xor

2023-04-06 Thread Quan Anh Mai
On Sat, 1 Apr 2023 15:40:14 GMT, Quan Anh Mai wrote: > Hi, > > This patch adds `VectorMask.xor` to the public interface of `VectorMask`. > This method has already been existed in each concrete mask classes. > > Please kindly review. > Thanks a lot. This pull request ha

Re: RFR: 8305461: [vectorapi] Add VectorMask::xor

2023-04-05 Thread Quan Anh Mai
On Tue, 4 Apr 2023 15:44:41 GMT, Paul Sandoz wrote: >> Hi, >> >> This patch adds `VectorMask.xor` to the public interface of `VectorMask`. >> This method has already been existed in each concrete mask classes. >> >> Please kindly review. >> Thanks a lot. > > Thank you for doing this. I am

Re: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v4]

2023-04-04 Thread Quan Anh Mai
On Mon, 3 Apr 2023 16:36:08 GMT, Paul Sandoz wrote: >> Quan Anh Mai has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains ten commits: >> >> - instruction asserts >> - Merge branch 'master' into slic

Re: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v6]

2023-04-04 Thread Quan Anh Mai
crobenchmarks show improvement > using the slice instrinsics. Some have tremendous increases in throughput due > to the limitation that a mask of length 2 cannot currently be intrinsified, > leading to falling back to the Java implementations. > > Please take a look and have some r

Re: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v5]

2023-04-04 Thread Quan Anh Mai
crobenchmarks show improvement > using the slice instrinsics. Some have tremendous increases in throughput due > to the limitation that a mask of length 2 cannot currently be intrinsified, > leading to falling back to the Java implementations. > > Please take a look and have some r

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v6]

2023-04-03 Thread Quan Anh Mai
On Fri, 31 Mar 2023 12:25:16 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch reimplements `VectorShuffle` implementations to be a vector of >> the bit type. Currently, VectorShuffle is stored as a byte array, and would >> be expanded upon usage. This pos

RFR: 8305461: [vectorapi] Add VectorMask::xor

2023-04-03 Thread Quan Anh Mai
Hi, This patch adds `VectorMask.xor` to the public interface of `VectorMask`. This method has already been existed in each concrete mask classes. Also, this patch renames `VectorMask.eq` to `VectorMask::xorNot`, which is more consistent with other logical operations in the same interface.

Re: RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM [v2]

2023-04-03 Thread Quan Anh Mai
On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes wrote: >> We have the strange situation where calling `t.isAlive()` on a >> `java.lang.Thread` `t`, will call into the VM (via `alive()` then >> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract >> its `JavaThread`

Re: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v4]

2023-04-03 Thread Quan Anh Mai
crobenchmarks show improvement > using the slice instrinsics. Some have tremendous increases in throughput due > to the limitation that a mask of length 2 cannot currently be intrinsified, > leading to falling back to the Java implementations. > > Please take a look and have some r

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v5]

2023-03-31 Thread Quan Anh Mai
On Fri, 31 Mar 2023 00:18:21 GMT, Paul Sandoz wrote: >> Quan Anh Mai has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 14 commits: >> >> - move implementations up >> - Merge branch 'master' into shuf

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v2]

2023-03-31 Thread Quan Anh Mai
On Tue, 21 Mar 2023 16:29:44 GMT, Paul Sandoz wrote: >> I have moved most of the methods to `AbstractVector` and `AbstractShuffle`, >> I have to resort to raw types, though, since there seems to be no way to do >> the same with wild cards, and the generics mechanism is not powerful enough >>

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v6]

2023-03-31 Thread Quan Anh Mai
00075158ac88})} > vmovdqu 0x10(%r10),%xmm2 > vpxor %xmm0,%xmm0,%xmm0 > vpcmpgtd %xmm2,%xmm0,%xmm3 > vtestps %xmm3,%xmm3 > jne0x7fa818b27cb1 > vpermd %ymm1,%ymm2,%ymm0 > movabs $0x751588c68,%r10; {oop([I{0x000751588c68}

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v5]

2023-03-30 Thread Quan Anh Mai
On Thu, 23 Mar 2023 02:23:20 GMT, Xiaohong Gong wrote: >> I think not emitting `VectorLoadShuffleNode` is more common so it is better >> to emit them only when needed, as it will simplify the graph and may allow >> better inspections of the indices in the future. Additionally, a do-nothing >>

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v5]

2023-03-30 Thread Quan Anh Mai
On Thu, 23 Mar 2023 07:13:55 GMT, Xiaohong Gong wrote: >> Quan Anh Mai has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 14 commits: >> >> - move implementations up >> - Merge branch 'master' in

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v5]

2023-03-30 Thread Quan Anh Mai
00075158ac88})} > vmovdqu 0x10(%r10),%xmm2 > vpxor %xmm0,%xmm0,%xmm0 > vpcmpgtd %xmm2,%xmm0,%xmm3 > vtestps %xmm3,%xmm3 > jne0x7fa818b27cb1 > vpermd %ymm1,%ymm2,%ymm0 > movabs $0x751588c68,%r10; {oop([I{0x000751588c68})} &

Re: RFR: 8304717: Declaration aliasing between boolean and jboolean is wrong [v2]

2023-03-23 Thread Quan Anh Mai
On Thu, 23 Mar 2023 22:23:00 GMT, Julian Waters wrote: >> A couple of spots wrongly refer to boolean and jboolean as the same thing. >> While this does still compile thanks to a happy accident and implicit >> conversions, they are not the same at all, and should be fixed before a >> future

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v4]

2023-03-22 Thread Quan Anh Mai
On Wed, 22 Mar 2023 07:59:40 GMT, Xiaohong Gong wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> reviews > > src/hotspot/share/opto/vectorIntrinsics.cpp line 2059: > >> 2

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v3]

2023-03-22 Thread Quan Anh Mai
On Wed, 22 Mar 2023 08:09:03 GMT, Xiaohong Gong wrote: >> Quan Anh Mai has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - missing casts >> - clean up > > Please also update the copyright

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v4]

2023-03-22 Thread Quan Anh Mai
00075158ac88})} > vmovdqu 0x10(%r10),%xmm2 > vpxor %xmm0,%xmm0,%xmm0 > vpcmpgtd %xmm2,%xmm0,%xmm3 > vtestps %xmm3,%xmm3 > jne0x7fa818b27cb1 > vpermd %ymm1,%ymm2,%ymm0 > movabs $0x751588c68,%r10; {oop([I{0x000751588c68}

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v2]

2023-03-21 Thread Quan Anh Mai
On Tue, 21 Mar 2023 16:29:44 GMT, Paul Sandoz wrote: >> I have moved most of the methods to `AbstractVector` and `AbstractShuffle`, >> I have to resort to raw types, though, since there seems to be no way to do >> the same with wild cards, and the generics mechanism is not powerful enough >>

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v2]

2023-03-21 Thread Quan Anh Mai
On Sun, 19 Mar 2023 19:38:04 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch reimplements `VectorShuffle` implementations to be a vector of >> the bit type. Currently, VectorShuffle is stored as a byte array, and would >> be expanded upon usage. This pos

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v3]

2023-03-21 Thread Quan Anh Mai
00075158ac88})} > vmovdqu 0x10(%r10),%xmm2 > vpxor %xmm0,%xmm0,%xmm0 > vpcmpgtd %xmm2,%xmm0,%xmm3 > vtestps %xmm3,%xmm3 > jne0x7fa818b27cb1 > vpermd %ymm1,%ymm2,%ymm0 > movabs $0x751588c68,%r10; {oop([I{0x000751588c68}

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v2]

2023-03-19 Thread Quan Anh Mai
00075158ac88})} > vmovdqu 0x10(%r10),%xmm2 > vpxor %xmm0,%xmm0,%xmm0 > vpcmpgtd %xmm2,%xmm0,%xmm3 > vtestps %xmm3,%xmm3 > jne0x7fa818b27cb1 > vpermd %ymm1,%ymm2,%ymm0 > movabs $0x751588c68,%r10; {oop([I{0x000751588c68}

RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation

2023-03-19 Thread Quan Anh Mai
Hi, This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks: 1. Inefficient conversions between a shuffle and its corresponding vector. This

Re: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test [v2]

2023-03-15 Thread Quan Anh Mai
On Wed, 15 Mar 2023 14:23:35 GMT, Eirik Bjorsnos wrote: >> Many thanks to have tried, yep, I was curious indeed re the >> "StringLatin1.canEncode regression" case. >> I would still modify the benchmark to use inputs (I know that will make it >> memory bound sadly, due to reading inputs - but

Re: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v2]

2023-03-08 Thread Quan Anh Mai
On Wed, 8 Mar 2023 16:23:16 GMT, Paul Sandoz wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> address reviews > > Java changes look good. The HotSpot code looks well structured bu

Re: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v3]

2023-03-08 Thread Quan Anh Mai
crobenchmarks show improvement > using the slice instrinsics. Some have tremendous increases in throughput due > to the limitation that a mask of length 2 cannot currently be intrinsified, > leading to falling back to the Java implementations. > > Please take a look and have some r

Re: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v2]

2023-03-08 Thread Quan Anh Mai
On Wed, 8 Mar 2023 00:29:05 GMT, Paul Sandoz wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> address reviews > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector

Re: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v2]

2023-03-08 Thread Quan Anh Mai
crobenchmarks show improvement > using the slice instrinsics. Some have tremendous increases in throughput due > to the limitation that a mask of length 2 cannot currently be intrinsified, > leading to falling back to the Java implementations. > > Please take a look and have some r

Re: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice

2023-03-07 Thread Quan Anh Mai
On Tue, 7 Mar 2023 18:23:42 GMT, Quan Anh Mai wrote: > `Vector::slice` is a method at the top-level class of the Vector API that > concatenates the 2 inputs into an intermediate composite and extracts a > window equal to the size of the inputs into the result. It is used

RFR: 8303762: [vectorapi] Intrinsification of Vector.slice

2023-03-07 Thread Quan Anh Mai
`Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to

Re: RFR: 8301226: Add clamp() methods to java.lang.Math and to StrictMath [v8]

2023-02-13 Thread Quan Anh Mai
On Tue, 7 Feb 2023 12:53:25 GMT, Tagir F. Valeev wrote: >> clamp() methods added to Math and StrictMath >> >> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` >> value and safely clamps it to an `int` range. Other overloads work with a >> particular type (long, float

Re: RFR: 8301226: Add clamp() methods to java.lang.Math and to StrictMath [v8]

2023-02-13 Thread Quan Anh Mai
On Tue, 7 Feb 2023 12:53:25 GMT, Tagir F. Valeev wrote: >> clamp() methods added to Math and StrictMath >> >> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` >> value and safely clamps it to an `int` range. Other overloads work with a >> particular type (long, float

Re: RFR: 8301226: Add clamp() methods to java.lang.Math and to StrictMath [v8]

2023-02-13 Thread Quan Anh Mai
On Tue, 7 Feb 2023 12:53:25 GMT, Tagir F. Valeev wrote: >> clamp() methods added to Math and StrictMath >> >> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` >> value and safely clamps it to an `int` range. Other overloads work with a >> particular type (long, float

Re: RFR: 8301226: Add clamp() methods to java.lang.Math and to StrictMath [v2]

2023-02-08 Thread Quan Anh Mai
On Tue, 7 Feb 2023 13:30:24 GMT, Tagir F. Valeev wrote: >> A pure `int`‑only overload doesn’t have to go through the `int` → `long` →  >> `int` conversion. > > Is this a real problem? This should not be a problem with C2, and with the lower compilation levels this insignificant impact seems to

Re: RFR: 8301226: Add clamp() methods to java.lang.Math and to StrictMath [v4]

2023-02-06 Thread Quan Anh Mai
On Mon, 6 Feb 2023 09:46:15 GMT, Tagir F. Valeev wrote: >> clamp() methods added to Math and StrictMath >> >> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` >> value and safely clamps it to an `int` range. Other overloads work with a >> particular type (long, float

Re: RFR: 8301226: Add clamp() methods to java.lang.Math and to StrictMath [v2]

2023-02-06 Thread Quan Anh Mai
On Mon, 6 Feb 2023 08:46:54 GMT, Tagir F. Valeev wrote: >> That should probably include a comment then. > > @ExE-Boss I think that immediately following `isNaN` checks give enough hint > that we want NaN to be here. Ah I see, a comment explaining the intention would be helpful here, then

Re: RFR: 8301226: Add clamp() methods to java.lang.Math and to StrictMath [v2]

2023-02-05 Thread Quan Anh Mai
On Sun, 5 Feb 2023 13:52:23 GMT, Tagir F. Valeev wrote: >> src/java.base/share/classes/java/lang/Math.java line 2297: >> >>> 2295: */ >>> 2296: public static float clamp(float value, float min, float max) { >>> 2297: if (!(min < max)) { >> >> Wouldn't it be more simple to

Re: RFR: 8293198: [vectorapi] Improve the implementation of VectorMask.indexInRange() [v2]

2023-02-03 Thread Quan Anh Mai
On Fri, 3 Feb 2023 07:13:10 GMT, Xiaohong Gong wrote: >> The Vector API `"indexInRange(int offset, int limit)"` is used >> to compute a vector mask whose lanes are set to true if the >> index of the lane is inside the range specified by the `"offset"` >> and `"limit"` arguments, otherwise the

Re: RFR: 8293198: [vectorapi] Improve the implementation of VectorMask.indexInRange()

2023-02-02 Thread Quan Anh Mai
On Wed, 18 Jan 2023 08:58:42 GMT, Xiaohong Gong wrote: > The Vector API `"indexInRange(int offset, int limit)"` is used > to compute a vector mask whose lanes are set to true if the > index of the lane is inside the range specified by the `"offset"` > and `"limit"` arguments, otherwise the lanes

Re: RFR: 8293198: [vectorapi] Improve the implementation of VectorMask.indexInRange()

2023-01-18 Thread Quan Anh Mai
On Thu, 19 Jan 2023 03:45:43 GMT, Xiaohong Gong wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java >> line 219: >> >>> 217: @ForceInline >>> 218: public VectorMask indexInRange(int offset, int limit) { >>> 219: if (offset < 0) { >> >> These

Re: RFR: 8293198: [vectorapi] Improve the implementation of VectorMask.indexInRange()

2023-01-18 Thread Quan Anh Mai
On Wed, 18 Jan 2023 08:58:42 GMT, Xiaohong Gong wrote: > The Vector API `"indexInRange(int offset, int limit)"` is used > to compute a vector mask whose lanes are set to true if the > index of the lane is inside the range specified by the `"offset"` > and `"limit"` arguments, otherwise the lanes

Re: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v2]

2023-01-17 Thread Quan Anh Mai
On Tue, 17 Jan 2023 08:30:58 GMT, Sergey Tsypanov wrote: >>> > Do you see any concrete examples of classes in the JDK that could benefit >>> > from a "VarHandlization"? >>> >>> `ImageOutputStreamImpl` and `ImageInputStreamImpl` in >>> `javax.imageio.stream` have some very similar code that

  1   2   >