On Wed, 8 Jun 2022 22:07:38 GMT, liach wrote:
>> Paul Sandoz has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Let java.management participate in preview features.
>
> Just curious, is it still up to incubato
Update the code examples in the api notes of Long::compress/expand. Some
constants need to be explicitly long values.
-
Commit messages:
- Correct Long.compress/expand api notes.
Changes: https://git.openjdk.org/jdk19/pull/14/files
Webrev:
On Wed, 8 Jun 2022 15:46:24 GMT, Paul Sandoz wrote:
> Allow JDK modules that use preview features (preview language features or
> preview API features from dependent modules) to participate without the need
> to compile with `--enable-preview`.
>
> It's difficult to enable part
ve been
> updated accordingly, both of which participate in preview APIs (APIs in
> `java.lang.foreign` and `Thread.ofVirtual`, respectively).
Paul Sandoz has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated change
On Wed, 8 Jun 2022 17:21:08 GMT, Alan Bateman wrote:
> Can java.management participate too? It would allow
> sun.management.Util.isVirtual(Thread) to go away (lots of methods in
> sun.management.ThreadImpl need to test if a thread is virtual).
Pushed update.
-
PR:
ve been
> updated accordingly, both of which participate in preview APIs (APIs in
> `java.lang.foreign` and `Thread.ofVirtual`, respectively).
Paul Sandoz has updated the pull request incrementally with one additional
commit since the last revision:
Let java.management participate in
Allow JDK modules that use preview features (preview language features or
preview API features from dependent modules) to participate without the need to
compile with `--enable-preview`.
It's difficult to enable participation using an annotation due to the nature in
which symbols are
On Thu, 2 Jun 2022 01:29:54 GMT, Xiaohong Gong wrote:
>> Checking whether the indexes of masked lanes are inside of the valid memory
>> boundary is necessary for masked vector memory access. However, this could
>> be saved if the given offset is inside of the vector range that could make
>>
On Thu, 2 Jun 2022 03:27:59 GMT, Xiaohong Gong wrote:
>> Currently the vector load with mask when the given index happens out of the
>> array boundary is implemented with pure java scalar code to avoid the IOOBE
>> (IndexOutOfBoundaryException). This is necessary for architectures that do
>>
On Mon, 30 May 2022 01:17:00 GMT, Xiaohong Gong wrote:
>> Xiaohong Gong has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Wrap the offset check into a static method
>
> @PaulSandoz, could you please help to check whether the current
On Tue, 24 May 2022 18:15:45 GMT, Maurizio Cimadamore
wrote:
>> Constructing indexed var handles using the `MemoryLayout` API produces
>> `VarHandle` which do not check the input indices for out-of-bounds
>> conditions.
>> While this can never result in a VM crash (after all the memory
On Tue, 24 May 2022 17:55:13 GMT, Paul Sandoz wrote:
>> Here's a concrete example:
>>
>> Consider a sequence layout with 6 elements. Then:
>>
>> element count = 6
>> valid indices 0, 1, 2, 3, 4, 5
>>
>> Now consider a var handle that is obtained
On Tue, 24 May 2022 17:53:38 GMT, Maurizio Cimadamore
wrote:
>> Indices start at zero. The ceilDiv operation is needed so that the operation
>> returns the first index outisde the range (it's a bit subtle, sorry, but I
>> don't know how else to express).
>
> Here's a concrete example:
>
>
On Tue, 24 May 2022 15:28:27 GMT, Maurizio Cimadamore
wrote:
>> Constructing indexed var handles using the `MemoryLayout` API produces
>> `VarHandle` which do not check the input indices for out-of-bounds
>> conditions.
>> While this can never result in a VM crash (after all the memory
On Tue, 24 May 2022 15:28:27 GMT, Maurizio Cimadamore
wrote:
>> Constructing indexed var handles using the `MemoryLayout` API produces
>> `VarHandle` which do not check the input indices for out-of-bounds
>> conditions.
>> While this can never result in a VM crash (after all the memory
On Sat, 21 May 2022 16:25:57 GMT, Alan Bateman wrote:
>> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java
>> line 1172:
>>
>>> 1170: }
>>> 1171: };
>>> 1172: return AccessController.doPrivileged(pa);
>>
>> ItÂ
On Thu, 19 May 2022 13:05:54 GMT, Alan Bateman wrote:
> This is the implementation of JEP 428: Structured Concurrency (Incubator).
>
> This is a non-final API that provides a gentle on-ramp to structure a task as
> a family of concurrent subtasks, and to coordinate the subtasks as a unit.
On Thu, 19 May 2022 21:11:41 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> Patch adds the planned support for new vector operations and APIs targeted
>> for [JEP 426: Vector API (Fourth
>> Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>>
>> Following is the brief summary of
On Thu, 19 May 2022 21:11:41 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> Patch adds the planned support for new vector operations and APIs targeted
>> for [JEP 426: Vector API (Fourth
>> Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>>
>> Following is the brief summary of
On Thu, 5 May 2022 08:56:07 GMT, Xiaohong Gong wrote:
>> Currently the vector load with mask when the given index happens out of the
>> array boundary is implemented with pure java scalar code to avoid the IOOBE
>> (IndexOutOfBoundaryException). This is necessary for architectures that do
>>
On Thu, 12 May 2022 11:08:10 GMT, Ludovic Henry wrote:
>> Looks like you are making great progress.
>>
>> Have you thought about ways the intrinsic implementation might be simplified
>> if some code is retained in Java and passed as constant arguments? e.g.
>> table of constants, scalar loop,
On Thu, 12 May 2022 01:56:25 GMT, Xiaohong Gong wrote:
>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template
>> line 4086:
>>
>>> 4084: } else {
>>> 4085: $Type$Species vsp = vspecies();
>>> 4086: if (offset < 0 || offset >
On Thu, 5 May 2022 08:56:07 GMT, Xiaohong Gong wrote:
>> Currently the vector load with mask when the given index happens out of the
>> array boundary is implemented with pure java scalar code to avoid the IOOBE
>> (IndexOutOfBoundaryException). This is necessary for architectures that do
>>
t through an enhancement to
>> the autovectorizer, the complexity of doing it by hand is trivial and the
>> gain is sizable (2x speedup) even without the Vector API. The algorithm has
>> been proposed by Richard Startin and Paul Sandoz [1].
>>
>> Speedup are a
On Tue, 10 May 2022 01:23:55 GMT, Xiaohong Gong wrote:
> Checking whether the indexes of masked lanes are inside of the valid memory
> boundary is necessary for masked vector memory access. However, this could be
> saved if the given offset is inside of the vector range that could make sure
>
On Wed, 11 May 2022 03:23:13 GMT, Xiaohong Gong wrote:
>> I modified the code of this PR to avoid the conversion of `boolean` to
>> `int`, so a constant integer value is passed all the way through, and the
>> masked load is made intrinsic from the method at which the constants are
>> passed
On Thu, 5 May 2022 08:56:07 GMT, Xiaohong Gong wrote:
>> Currently the vector load with mask when the given index happens out of the
>> array boundary is implemented with pure java scalar code to avoid the IOOBE
>> (IndexOutOfBoundaryException). This is necessary for architectures that do
>>
On Fri, 6 May 2022 15:05:57 GMT, Doug Lea wrote:
> Changes ForkJoinPool.close spec and code to trap close as a no-op if called
> on common pool
Changes look good, it will need a CSR.
-
PR: https://git.openjdk.java.net/jdk/pull/8577
On Fri, 6 May 2022 04:49:39 GMT, Xiaohong Gong wrote:
>> offset is long so uses two argument slots (5 and 6).
>> mask is argument (7).
>> offsetInRange is argument(8).
>
> Make sense! Thanks for the explanation!
Doh! of course. This is not the first and will not be the last time i get
caught
On Thu, 5 May 2022 08:56:07 GMT, Xiaohong Gong wrote:
>> Currently the vector load with mask when the given index happens out of the
>> array boundary is implemented with pure java scalar code to avoid the IOOBE
>> (IndexOutOfBoundaryException). This is necessary for architectures that do
>>
On Thu, 5 May 2022 01:13:23 GMT, Xiaohong Gong wrote:
> Yeah, I agree that it's not good by adding a branch checking for
> `offsetInRange`. But actually I met the constant issue that passing the
> values all the way cannot guarantee the argument a constant in compiler at
> the compile time.
On Wed, 4 May 2022 01:59:17 GMT, Quan Anh Mai wrote:
> Hi,
>
> This patch optimises the matching rules for floating-point comparison with
> respects to eq/ne on x86-64
>
> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF`
> is always set, so we don't need
On Wed, 27 Apr 2022 11:03:48 GMT, Jatin Bhateja wrote:
> Hi All,
>
> Patch adds the planned support for new vector operations and APIs targeted
> for [JEP 426: Vector API (Fourth
> Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>
> Following is the brief summary of changes:-
On Wed, 4 May 2022 12:30:53 GMT, Doug Lea wrote:
> This is the revised jsr166 refresh for jdk19. See
> https://bugs.openjdk.java.net/browse/JDK-8285450 and
> https://bugs.openjdk.java.net/browse/JDK-8277090. Out of caution, this PR
> removes the unrelated commits from original version.
On Tue, 3 May 2022 15:32:27 GMT, Martin Buchholz wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review comments
>
> src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line
> 2153:
>
>>
On Mon, 2 May 2022 13:33:33 GMT, Doug Lea wrote:
>> This is the jsr166 refresh for jdk19. See
>> https://bugs.openjdk.java.net/browse/JDK-8285450 and
>> https://bugs.openjdk.java.net/browse/JDK-8277090
>
> Doug Lea has updated the pull request incrementally with one additional
> commit since
On Fri, 22 Apr 2022 07:08:24 GMT, Xiaohong Gong wrote:
>> Currently the vector load with mask when the given index happens out of the
>> array boundary is implemented with pure java scalar code to avoid the IOOBE
>> (IndexOutOfBoundaryException). This is necessary for architectures that do
>>
On Fri, 29 Apr 2022 06:35:44 GMT, Jie Fu wrote:
>> Hi all,
>>
>> The Current Vector API doc for `LSHR` is
>>
>> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>>
>>
>> This is misleading which may lead to bugs for Java developers.
>> This is because for negative byte/short elements, the results
On Wed, 27 Apr 2022 09:06:12 GMT, Jie Fu wrote:
>> Hi all,
>>
>> The Current Vector API doc for `LSHR` is
>>
>> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>>
>>
>> This is misleading which may lead to bugs for Java developers.
>> This is because for negative byte/short elements, the results
On Wed, 27 Apr 2022 09:06:12 GMT, Jie Fu wrote:
>> Hi all,
>>
>> The Current Vector API doc for `LSHR` is
>>
>> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>>
>>
>> This is misleading which may lead to bugs for Java developers.
>> This is because for negative byte/short elements, the results
On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 27 Apr 2022 17:27:56 GMT, Mandy Chung wrote:
>> Alan Bateman has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> src/java.base/share/classes/java/lang/PinnedThreadPrinter.java
On Wed, 27 Apr 2022 09:06:12 GMT, Jie Fu wrote:
>> Hi all,
>>
>> The Current Vector API doc for `LSHR` is
>>
>> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>>
>>
>> This is misleading which may lead to bugs for Java developers.
>> This is because for negative byte/short elements, the results
On Thu, 21 Apr 2022 04:23:22 GMT, Jie Fu wrote:
>> Hi all,
>>
>> The Current Vector API doc for `LSHR` is
>>
>> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>>
>>
>> This is misleading which may lead to bugs for Java developers.
>> This is because for negative byte/short elements, the results
On Tue, 19 Apr 2022 08:41:50 GMT, Jie Fu wrote:
> Hi all,
>
> The Current Vector API doc for `LSHR` is
>
> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>
>
> This is misleading which may lead to bugs for Java developers.
> This is because for negative byte/short elements, the results computed
On Tue, 19 Apr 2022 08:41:50 GMT, Jie Fu wrote:
> Hi all,
>
> The Current Vector API doc for `LSHR` is
>
> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>
>
> This is misleading which may lead to bugs for Java developers.
> This is because for negative byte/short elements, the results computed
On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu wrote:
> Hi all,
>
> According to the Vector API doc, the `LSHR` operator computes
> `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
>
> The background is that one of our customers try to vectorize
On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu wrote:
> Hi all,
>
> According to the Vector API doc, the `LSHR` operator computes
> `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
>
> The background is that one of our customers try to vectorize
On Tue, 19 Apr 2022 13:19:31 GMT, Claes Redestad wrote:
> Trivially fix the resolution of the `NF_UNSAFE` named function to use the
> appropriate lookup mode.
>
> In [JDK-8187826](https://bugs.openjdk.java.net/browse/JDK-8187826) we changed
> from regular reflection to use a `NamedFunction`
On Tue, 19 Apr 2022 08:41:50 GMT, Jie Fu wrote:
> Hi all,
>
> The Current Vector API doc for `LSHR` is
>
> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>
>
> This is misleading which may lead to bugs for Java developers.
> This is because for negative byte/short elements, the results computed
On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu wrote:
> Hi all,
>
> According to the Vector API doc, the `LSHR` operator computes
> `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
>
> The background is that one of our customers try to vectorize
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Tue, 5 Apr 2022 22:05:19 GMT, Paul Sandoz wrote:
> Add support to compress bits and expand bits of `int` and `long` values, see
> Hacker's Delight (2nd edition), section 7.4.
>
> Compressing or expanding bits of an `int` or `long` value can be composed to
> enable gener
On Thu, 10 Feb 2022 04:30:34 GMT, Tagir F. Valeev wrote:
>> See the bug description for details.
>>
>> I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED
>> and report artificial estimatedSize(), much bigger than the real one. This
>> will allow AbstractSpliterator and
On Mon, 11 Apr 2022 10:03:58 GMT, Claes Redestad wrote:
>>> How would the performance change if the `isDirect` and
>>> `checkExactAccessMode` merger was reverted?
>>
>> Add around 15-20ns/op for these micros.
>
> Restructuring so that we only check `direct` once sounds reasonable at face
>
> verify against the JDK implementations (which later will also be made
> intrinsic). To compensate all tests are also run flipping the test methods
> and the methods under test.
> 2. Tests composed of compress and expand and vice versa.
> 3. Tests with known mask patterns, whose expected
> verify against the JDK implementations (which later will also be made
> intrinsic). To compensate all tests are also run flipping the test methods
> and the methods under test.
> 2. Tests composed of compress and expand and vice versa.
> 3. Tests with known mask patterns, whose expected
> verify against the JDK implementations (which later will also be made
> intrinsic). To compensate all tests are also run flipping the test methods
> and the methods under test.
> 2. Tests composed of compress and expand and vice versa.
> 3. Tests with known mask patterns, whose expected
On Thu, 7 Apr 2022 20:02:51 GMT, Alan Bateman wrote:
>> Examples added in latest commit.
>
> I see you've added a comment on each example too, I think this really helpers
> readers to see how they can be used.
>
> The class description of both Integer and Long have an implementation note
>
On Wed, 6 Apr 2022 18:22:45 GMT, John R Rose wrote:
>> Paul Sandoz has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Fix typo.
>> - Provide examples.
>
> src/java.base/share/classes/java/lan
> verify against the JDK implementations (which later will also be made
> intrinsic). To compensate all tests are also run flipping the test methods
> and the methods under test.
> 2. Tests composed of compress and expand and vice versa.
> 3. Tests with known mask patterns, whose expected
> verify against the JDK implementations (which later will also be made
> intrinsic). To compensate all tests are also run flipping the test methods
> and the methods under test.
> 2. Tests composed of compress and expand and vice versa.
> 3. Tests with known mask patterns, whose expected
On Thu, 7 Apr 2022 14:01:53 GMT, Claes Redestad wrote:
>> Paul Sandoz has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Doc and test updates.
>
> I experimented with this and drafted a few microbenchmarks alo
On Wed, 6 Apr 2022 17:39:48 GMT, John R Rose wrote:
>> Paul Sandoz has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Doc and test updates.
>
> test/jdk/java/lang/AbstractCompressExpandTest.java line 145:
>
On Wed, 6 Apr 2022 17:43:34 GMT, John R Rose wrote:
>> Paul Sandoz has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Doc and test updates.
>
> test/jdk/java/lang/AbstractCompressExpandTest.java line 104
> verify against the JDK implementations (which later will also be made
> intrinsic). To compensate all tests are also run flipping the test methods
> and the methods under test.
> 2. Tests composed of compress and expand and vice versa.
> 3. Tests with known mask patterns, whose expected
On Wed, 6 Apr 2022 14:58:37 GMT, Alan Bateman wrote:
>> Add support to compress bits and expand bits of `int` and `long` values, see
>> Hacker's Delight (2nd edition), section 7.4.
>>
>> Compressing or expanding bits of an `int` or `long` value can be composed to
>> enable general
Add support to compress bits and expand bits of `int` and `long` values, see
Hacker's Delight (2nd edition), section 7.4.
Compressing or expanding bits of an `int` or `long` value can be composed to
enable general permutations, and the "sheep and goats" operation (SAG) see
Hacker's Delight
On Wed, 30 Mar 2022 21:51:16 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-424 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Mon, 28 Mar 2022 09:56:22 GMT, Xiaohong Gong wrote:
>> The current vector `"NEG"` is implemented with substraction a vector by zero
>> in case the architecture does not support the negation instruction. And to
>> fit the predicate feature for architectures that support it, the masked
>>
On Wed, 23 Mar 2022 23:22:31 GMT, Mandy Chung wrote:
>> A simple patch to call `Objects.requireNonNull(recv)` for an explicit null
>> receiver check rather than NPE thrown by `Object::getClass`. The message of
>> NPE generated by JEP 358 (Helpful NullPointerExceptions) is supposed to be
>>
On Wed, 23 Mar 2022 16:27:29 GMT, Mandy Chung wrote:
> This patch changes VarHandle and its implementation hierarchy to use sealed
> classes. All VarHandle permitted classes are package-private and either
> final or sealed abstract classes.
>
> Please also review the CSR:
On Tue, 8 Mar 2022 15:13:46 GMT, Claes Redestad wrote:
>> Ludovic Henry has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add UTF-16 benchmarks
>
> An awkward effect of this implementation is that it perturbs results on small
> Strings a
t through an enhancement to
>> the autovectorizer, the complexity of doing it by hand is trivial and the
>> gain is sizable (2x speedup) even without the Vector API. The algorithm has
>> been proposed by Richard Startin and Paul Sandoz [1].
>>
>> Speedup are a
On Thu, 10 Feb 2022 04:30:34 GMT, Tagir F. Valeev wrote:
>> See the bug description for details.
>>
>> I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED
>> and report artificial estimatedSize(), much bigger than the real one. This
>> will allow AbstractSpliterator and
On Thu, 10 Feb 2022 04:22:34 GMT, Tagir F. Valeev wrote:
>> Tagir F. Valeev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Benchmark to demonstrate the patch usefulness
>
> I added a microbenchmark to demonstrate the speed improvement
On Thu, 3 Mar 2022 08:12:46 GMT, Xiaohong Gong wrote:
>> The vector `"test"` api is implemented with vector `"compare"`. And the
>> masked `"test" `is implemented with `"test(op).and(m)"` which means
>> `"compare().and(m)"` finally. Since the masked vector `"compare"` has been
>> optimized
On Wed, 2 Mar 2022 02:50:27 GMT, Xiaohong Gong wrote:
> The vector `"test"` api is implemented with vector `"compare"`. And the
> masked `"test" `is implemented with `"test(op).and(m)"` which means
> `"compare().and(m)"` finally. Since the masked vector `"compare"` has been
> optimized with
On Wed, 2 Mar 2022 00:32:46 GMT, Quan Anh Mai wrote:
>> Quan Anh Mai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> the other
>
> Thanks a lot for your reviews, do I need a second review for this?
> @ExE-Boss IMO generally we only
On Tue, 1 Mar 2022 02:22:49 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> `Objects.requireNonNull` may fail to be inlined. The call is expensive and
>> may lead to objects escaping to the heap while the null check is cheap and
>> is often elided. I have observed this when using the vector API when a
On Sat, 19 Feb 2022 05:51:52 GMT, Quan Anh Mai wrote:
> Hi,
>
> `Objects.requireNonNull` may fail to be inlined. The call is expensive and
> may lead to objects escaping to the heap while the null check is cheap and is
> often elided. I have observed this when using the vector API when a call
On Sun, 13 Feb 2022 05:14:47 GMT, Quan Anh Mai wrote:
>> Observing the following failures on CPUs with
>> "Intel_R__Xeon_R__Gold_6354_CPU___3.00GHz" with HotSpot flags:
>>
>> -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100
>> -XX:+UnlockExperimentalVMOptions -server
On Sun, 13 Feb 2022 05:18:34 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch implements the unsigned upcast intrinsics in x86, which are used
>> in vector lane-wise reinterpreting operations.
>>
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one
On Thu, 10 Feb 2022 15:14:44 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch implements the unsigned upcast intrinsics in x86, which are used
>> in vector lane-wise reinterpreting operations.
>>
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with two
On Wed, 9 Feb 2022 21:36:01 GMT, Paul Sandoz wrote:
> …ArgumentExcept on zero vectors
>
> This PR fixes issues for reduction using FIRST_NONZERO and adds tests. The
> testing infrastructure is generalized to reduction functions and tests for
> min/max reductions are
1 - 100 of 2479 matches
Mail list logo
