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 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 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
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 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 Feb 2022 05:33:52 GMT, kabutz wrote:
> A question about wording of the @implNote. In multiply() they say: "An
> implementation may offer better algorithmic ...", but we changed this to
> "This implementation may offer better algorithmic ..." I've kept it as "This
> implementation
On Thu, 3 Feb 2022 05:29:51 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since
On Thu, 3 Feb 2022 06:35:47 GMT, Joe Darcy wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Updated comment to include information about performance
>
> src/java.base/share/classes/java/math/BigInteger.java line 1603:
>
…ArgumentExcept on zero vectors
This PR fixes issues for reduction using FIRST_NONZERO and add tests. The
testing infrastructure is generalized to reduction functions and tests for
min/max reductions are updated to use that.
-
Commit messages:
- 8281294: [vectorapi] FIRST_NONZERO
On Fri, 28 Jan 2022 19:03:39 GMT, kabutz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Benchmark for testing the effectiveness of BigInteger.parallelMultiply()
>
> I have added a benchmark for checking performance
On Wed, 26 Jan 2022 02:12:11 GMT, Joe Darcy wrote:
> Use floating-point library methods to nudge down the result if needed. The
> nextAfter(r, origin) call return the next value in the direction of origin,
> handling cases for negative values, etc.
>
> Changing to call nextDown for the origin
On Tue, 25 Jan 2022 15:22:30 GMT, Maurizio Cimadamore
wrote:
> This patch fixes some inconsistencies in the foreign API javadoc. The main
> fix is to make javadoc of all predicate methods consistent, and to use the
> `@return` tag where appropriate, as to avoid duplication.
>
> There were
On Wed, 24 Nov 2021 19:20:08 GMT, Paul Sandoz wrote:
> Add two new cross-lane vector operations, `compress` and `expand`.
>
> An example of such usage might be code that selects elements from array `a`
> and stores those selected elements in array `z`:
>
>
> int[]
On Wed, 24 Nov 2021 19:20:08 GMT, Paul Sandoz wrote:
> Add two new cross-lane vector operations, `compress` and `expand`.
>
> An example of such usage might be code that selects elements from array `a`
> and stores those selected elements in array `z`:
>
>
> int[]
On Fri, 14 Jan 2022 09:15:37 GMT, kabutz wrote:
>>> > embarrassingly parallelizable
>>>
>>> Having looked at [embarrassingly
>>> parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not
>>> certain that this particular problem would qualify. The algorithm is easy
>>> to
On Thu, 16 Dec 2021 06:07:29 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since
On Fri, 14 Jan 2022 09:15:37 GMT, kabutz wrote:
>>> > embarrassingly parallelizable
>>>
>>> Having looked at [embarrassingly
>>> parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not
>>> certain that this particular problem would qualify. The algorithm is easy
>>> to
On Thu, 13 Jan 2022 18:32:20 GMT, Maurizio Cimadamore
wrote:
>> When looking at larger benchmarks, I noted a discrepancy between the
>> performance of off-heap segments and on-heap segments. Looking at the
>> assembly for the `MemorySegment::asSlice` method I could see some additional
>>
On Thu, 13 Jan 2022 12:26:17 GMT, Maurizio Cimadamore
wrote:
>> When looking at larger benchmarks, I noted a discrepancy between the
>> performance of off-heap segments and on-heap segments. Looking at the
>> assembly for the `MemorySegment::asSlice` method I could see some additional
>>
On Wed, 12 Jan 2022 19:07:00 GMT, Maurizio Cimadamore
wrote:
>> yes, that should be harmless
>
> Actually, no, sorry. If I sharpen the type, then `dup` has to cast, so we go
> back to the original issue.
Ah yes, i see. Maybe it's worth adding a general comment to the class doc of
On Wed, 12 Jan 2022 15:48:20 GMT, Maurizio Cimadamore
wrote:
> When looking at larger benchmarks, I noted a discrepancy between the
> performance of off-heap segments and on-heap segments. Looking at the
> assembly for the `MemorySegment::asSlice` method I could see some additional
>
On Wed, 5 Jan 2022 18:08:01 GMT, Maurizio Cimadamore
wrote:
>> This patch fixes a performance issue when dereferencing memory segments
>> backed by different kinds of scopes. When looking at inline traces, I found
>> that one of our benchmark, namely `LoopOverPollutedSegment` was already
>>
On Wed, 5 Jan 2022 17:57:44 GMT, Maurizio Cimadamore
wrote:
>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ResourceScopeImpl.java
>> line 190:
>>
>>> 188: @ForceInline
>>> 189: public final void checkValidState() {
>>> 190: if (owner != null && owner !=
On Wed, 5 Jan 2022 16:59:30 GMT, Maurizio Cimadamore
wrote:
> This patch fixes a performance issue when dereferencing memory segments
> backed by different kinds of scopes. When looking at inline traces, I found
> that one of our benchmark, namely `LoopOverPollutedSegment` was already
>
On Wed, 24 Nov 2021 19:20:08 GMT, Paul Sandoz wrote:
> Add two new cross-lane vector operations, `compress` and `expand`.
>
> An example of such usage might be code that selects elements from array `a`
> and stores those selected elements in array `z`:
>
>
> int[]
On Thu, 16 Dec 2021 21:48:14 GMT, kabutz wrote:
> > embarrassingly parallelizable
>
> Having looked at [embarrassingly
> parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not
> certain that this particular problem would qualify. The algorithm is easy to
> parallelize, but
On Thu, 16 Dec 2021 20:09:59 GMT, kabutz wrote:
> "embarrassingly parallel when employing recursive" -> "embarrassingly
> non-parallel when employing recursive" (?)
I corrected to "embarrassingly parallelizable" (i believe that is a common
phrase we as software engineers use in these cases).
On Thu, 16 Dec 2021 19:39:59 GMT, kabutz wrote:
> Terribly sorry to ask this, but where would I see the CSR? I don't have
> access to the JIRA in the backend.
You should be able to view it but not edit:
https://bugs.openjdk.java.net/browse/JDK-8278886
(To get creation/update access rights
On Thu, 16 Dec 2021 05:55:14 GMT, kabutz wrote:
>> This is looking good. I will create the CSR and propose it. Since the
>> holiday season is imminent it's likely no approval of the CSR will happen on
>> until the new year.
>
>> This is looking good. I will create the CSR and propose it. Since
On Wed, 15 Dec 2021 20:18:39 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since
On Wed, 15 Dec 2021 14:31:26 GMT, kabutz wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 2000:
>>
>>> 1998: da1 = a2.add(a0);
>>> 1999: db1 = b2.add(b0);
>>> 2000: var vm1_task = RecursiveOp.multiply(da1.subtract(a1),
>>> db1.subtract(b1), parallel,
On Wed, 15 Dec 2021 14:40:34 GMT, kabutz wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 1909:
>>
>>> 1907: @Override
>>> 1908: public BigInteger compute() {
>>> 1909: return a.multiply(b, true, super.parallel,
>>> super.depth);
>>
On Mon, 6 Dec 2021 18:19:39 GMT, Alan Bateman wrote:
>> Deprecate the sun.misc.Unsafe methods that return field offsets. These
>> method are an impediment to possible future changes. Layout may not be fixed
>> in the future, the VM should be allowed to re-layout dynamically based on
>>
On Mon, 6 Dec 2021 17:47:37 GMT, Alan Bateman wrote:
> I toyed with including staticFieldBase but I didn't find anything like the
> usage as the offset methods. Easy to include if you think it's worth doing.
Yes, I think you should include it, it's part of this set of functionality
(since
On Fri, 3 Dec 2021 13:05:44 GMT, Alan Bateman wrote:
> Deprecate the sun.misc.Unsafe methods that return field offsets. These method
> are an impediment to possible future changes. Layout may not be fixed in the
> future, the VM should be allowed to re-layout dynamically based on patterns
>
On Thu, 2 Dec 2021 20:56:46 GMT, Vamsi Parasa wrote:
>> Vamsi Parasa has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add seeds for the random generators to eliminate run-to-run variance
>
> @JimLaskey Could you please review this PR
On Fri, 3 Dec 2021 03:44:09 GMT, Mai Đặng Quân Anh
wrote:
> Thanks a lot for your support and review. Do I need another review here?
No need for this one, for next PR for the intrinsics will likely need two
HotSpot reviewers.
-
PR: https://git.openjdk.java.net/jdk/pull/6634
On Wed, 1 Dec 2021 12:03:15 GMT, Mai Đặng Quân Anh
wrote:
> When doing an unsigned upcast, we perform a signed cast followed by a bitwise
> and operation to clip the extended signed bit. The sign clip mask is
> currently calculated incorrectly, the correct mask should have the number of
>
On Fri, 3 Dec 2021 02:11:24 GMT, Vamsi Parasa wrote:
>> This change optimizes random number generators using
>> Math.unsignedMultiplyHigh()
>
> Vamsi Parasa has updated the pull request incrementally with one additional
> commit since the last revision:
>
> minor changes to the benchmark
On Fri, 3 Dec 2021 00:17:04 GMT, Vamsi Parasa wrote:
>> This change optimizes random number generators using
>> Math.unsignedMultiplyHigh()
>
> Vamsi Parasa has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update the JMH micro to take RNG
On Wed, 1 Dec 2021 12:03:15 GMT, Mai Đặng Quân Anh
wrote:
> When doing an unsigned upcast, we perform a signed cast followed by a bitwise
> and operation to clip the extended signed bit. The sign clip mask is
> currently calculated incorrectly, the correct mask should have the number of
>
On Thu, 2 Dec 2021 20:43:56 GMT, Vamsi Parasa wrote:
>> This change optimizes random number generators using
>> Math.unsignedMultiplyHigh()
>
> Vamsi Parasa has updated the pull request incrementally with one additional
> commit since the last revision:
>
> add seeds for the random
On Thu, 2 Dec 2021 22:04:36 GMT, Mai Đặng Quân Anh
wrote:
>> I am inclined to separated out. Fix the bug, add the tests, and integrate
>> for 18. Then enhance with the intrinsics for 19.
>>
>> If you agree to that I will create two bugs.
>
> @PaulSandoz Yes, I think that should be the case,
On Wed, 1 Dec 2021 12:03:15 GMT, Mai Đặng Quân Anh
wrote:
> This patch implements vector unsigned upcast intrinsics for x86. I also fixed
> a bug in the current implementation where the zero extension masks are
> computed incorrectly and add relevant tests.
>
> Thank you very much.
I am
On Tue, 30 Nov 2021 19:22:53 GMT, Paul Sandoz wrote:
> Remove Vector API scripts for building and running tests. `jtreg` should be
> used instead.
>
> Also updated the test generation script to remove options that assume
> mercurial as the code repository.
This pull reque
On Wed, 24 Nov 2021 15:20:42 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since
> Remove Vector API scripts for building and running tests. `jtreg` should be
> used instead.
>
> Also updated the test generation script to remove options that assume
> mercurial as the code repository.
Paul Sandoz has updated the pull request incrementally with one additiona
On Tue, 30 Nov 2021 23:24:24 GMT, Jie Fu wrote:
> Shall we also update the copyright year?
Doh! of course, updated.
-
PR: https://git.openjdk.java.net/jdk/pull/6621
Remove Vector API scripts for building and running tests. `jtreg` should be
used instead.
Also updated the test generation script to remove options that assume mercurial
as the code repository.
-
Commit messages:
- JDK-8278014: [vectorapi] Remove test run script
Changes:
On Tue, 30 Nov 2021 13:20:32 GMT, Maurizio Cimadamore
wrote:
>> Following integration of the second incubator of the foreign function and
>> memory API [1], we detected few divergences between the contents of the jdk
>> repo and the panama repo:
>>
>> * the name of some of the
Add two new cross-lane vector operations, `compress` and `expand`.
An example of such usage might be code that selects elements from array `a` and
stores those selected elements in array `z`:
int[] a = ...;
int[] z = ...;
int ai = 0, zi = 0;
while (ai < a.length) {
IntVector av =
On Fri, 19 Nov 2021 10:42:23 GMT, kabutz wrote:
> > I think the functionality in this PR is worth pursuing, but with the JDK 18
> > rampdown 1 date fast approaching, as a non-urgent issue, I think we
> > shouldn't try to rush it into JDK 18.
>
> > I looked more closely and now understand a
On Wed, 17 Nov 2021 19:48:25 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since
On Wed, 17 Nov 2021 19:21:39 GMT, Paul Sandoz wrote:
>>> @mcimadamore Thanks!
>>>
>>> @PaulSandoz I'll keep this PR open until after the integration is done, and
>>> check if or what parts are still needed after that. I don't want to mess up
>>> y
On Fri, 12 Nov 2021 17:01:38 GMT, Paul Sandoz wrote:
>>> > You could also do this directly in the Panama repo branches. I'll
>>> > volunteer to help, if you want.
>>>
>>> I'll run the script on the PR I've submitted for the Foreign API, and I
On Wed, 17 Nov 2021 18:20:07 GMT, Brian Burkhalter wrote:
> I also do not like potentially non-obvious default behavior, nor a command
> line flag, nor a (static) setting on `BigInteger`. Thus I think the original
> `parallelMultiply()` (or perhaps `multiplyParallel()`) would be preferable.
On Fri, 8 Oct 2021 21:25:26 GMT, Paul Sandoz wrote:
> This PR improves the performance of vector operations that accept masks on
> architectures that support masking in hardware, specifically Intel AVX512 and
> ARM SVE.
>
> On architectures that do not support masking in ha
On Fri, 12 Nov 2021 11:13:24 GMT, Maurizio Cimadamore
wrote:
>>> You could also do this directly in the Panama repo branches. I'll volunteer
>>> to help, if you want.
>>
>> I'll run the script on the PR I've submitted for the Foreign API, and I will
>> update that one - thanks. Perhaps
On Thu, 11 Nov 2021 15:47:11 GMT, Maurizio Cimadamore
wrote:
>> I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This
>> scripts verifies that modifiers are in the "blessed" order, and fixes it
>> otherwise. I have manually checked the changes made by the script to make
t; No API enhancements were required and only a few additional tests were needed.
Paul Sandoz has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 16 commits:
- Merge branch 'master' into JDK-8271515-vector-api
- Add missing null che
On Thu, 11 Nov 2021 14:50:43 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by the script to make
>
t; No API enhancements were required and only a few additional tests were needed.
Paul Sandoz has updated the pull request incrementally with one additional
commit since the last revision:
Add missing null check post mask unboxing.
-
Changes:
- all: https://git.openjdk.java.ne
On Thu, 4 Nov 2021 19:49:08 GMT, Sandhya Viswanathan
wrote:
>> This patch removes conflicts with libsvml.so distributed with Intel's MKL
>> library:
>> Renames exported symbols from __svml to __jsvml.
>> Renames library from libsvml.so to libjsvml.so.
>> Updates the
t; No API enhancements were required and only a few additional tests were needed.
Paul Sandoz has updated the pull request incrementally with two additional
commits since the last revision:
- Merge pull request #2 from nsjian/vector-conversion-fix
AArch64: Incorrect SVE double to int
On Tue, 2 Nov 2021 10:30:42 GMT, Maurizio Cimadamore
wrote:
>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java line
>> 111:
>>
>>> 109: class VarHandleCache {
>>> 110: private static final Map handleMap
>>> = new ConcurrentHashMap<>();
>>> 111:
On Mon, 1 Nov 2021 22:36:40 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Tue, 2 Nov 2021 10:30:42 GMT, Maurizio Cimadamore
wrote:
>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java line
>> 111:
>>
>>> 109: class VarHandleCache {
>>> 110: private static final Map handleMap
>>> = new ConcurrentHashMap<>();
>>> 111:
On Mon, 1 Nov 2021 22:36:40 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Mon, 1 Nov 2021 22:36:40 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Tue, 2 Nov 2021 10:30:42 GMT, Maurizio Cimadamore
wrote:
>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java line
>> 111:
>>
>>> 109: class VarHandleCache {
>>> 110: private static final Map handleMap
>>> = new ConcurrentHashMap<>();
>>> 111:
On Mon, 1 Nov 2021 12:05:32 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Mon, 1 Nov 2021 12:05:32 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Mon, 1 Nov 2021 12:05:32 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Thu, 28 Oct 2021 20:23:41 GMT, Mandy Chung wrote:
>> Classes compiled prior to the nestmate support will generate
>> `REF_invokeSpecial` if the implementation method is a private instance
>> method. Since a lambda proxy class is a hidden class, a nestmate of the
>> host class, it can
On Thu, 28 Oct 2021 08:47:31 GMT, Aleksey Shipilev wrote:
> `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
> `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed (useless?)
> to call to runtime for a single memory barrier. We can simplify the native
> `Unsafe`
t; No API enhancements were required and only a few additional tests were needed.
Paul Sandoz has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 12 commits:
- Merge branch 'master' into JDK-8271515-vector-api
- Merge pull request #1 fr
t; No API enhancements were required and only a few additional tests were needed.
Paul Sandoz has updated the pull request incrementally with two additional
commits since the last revision:
- Merge pull request #1 from nsjian/JDK-8271515
Address AArch64 review comments from Nick.
t; No API enhancements were required and only a few additional tests were needed.
Paul Sandoz has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains ten commits:
- Merge branch 'master' into JDK-8271515-vector-api
- Resolve review comment
On Tue, 19 Oct 2021 21:14:08 GMT, Sandhya Viswanathan
wrote:
>> Paul Sandoz has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains seven commits:
>>
>> - Merge branch 'master' into JDK-8271515-vector-api
>
t; No API enhancements were required and only a few additional tests were needed.
Paul Sandoz has updated the pull request incrementally with one additional
commit since the last revision:
Resolve review comments.
-
Changes:
- all: https://git.openjdk.java.ne
On Tue, 19 Oct 2021 18:57:59 GMT, Sandhya Viswanathan
wrote:
>> It's actually redundant because the class is final. Better to drop final
>> from all declarations, at the risk of creating a larger diff.
>
> Got it. I am ok with leaving things as is if it makes it easier.
For now to reduce
On Mon, 18 Oct 2021 22:56:37 GMT, Sandhya Viswanathan
wrote:
>> Paul Sandoz has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains seven commits:
>>
>> - Merge branch 'master' into JDK-8271515-vector-api
>
t; No API enhancements were required and only a few additional tests were needed.
Paul Sandoz has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains seven commits:
- Merge branch 'master' into JDK-8271515-vector-api
- Apply patch from http
501 - 600 of 3421 matches
Mail list logo
