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 addit
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 a
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 may
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 To
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 diff
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 als
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 paral
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 T
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 paral
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
>> barr
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
>> barr
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
`HeapMemoryS
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
> barriers
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
>> h
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 != Thread.
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
> hitti
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 y
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 T
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
>> pattern
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 base
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
> of
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 whic
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
> lea
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
Ma
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 p
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
> lea
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 generator
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, th
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 incl
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 T
> 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: https://
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 `FunctionDescri
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 = IntVector
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 bit
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 T
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
>
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 Forei
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.
Fo
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 @PaulS
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 missin
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
> sur
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
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] - https://openjdk
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] - https://openjdk
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 invo
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` interfac
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 req
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 revi
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-vecto
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 chang
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-vecto
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
On Thu, 14 Oct 2021 17:21:25 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 s
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:
Apply patch from https://github.com/openjdk/panama-vector/pull/152
-
Changes:
- all: h
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 hardware the same technique as
before is applied to most operations, specifically com
On Tue, 12 Oct 2021 20:51:02 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] - https://openjd
Hi Tagir,
Do you mind if we slow down on this and let the idea bake somewhat, captured in
this thread/issue/PR(draft).
I am always a little wary of compact-only or fluent-only methods, as I find
them harder to justify. In this case I think there might be something more with
regards to a patter
On Wed, 25 Aug 2021 15:52:06 GMT, Igor Ignatyev wrote:
>> See the bug report for more details. I would appreciate if people with their
>> corporate testing systems would run this through their systems to avoid
>> surprises. (ping @RealCLanger, @iignatev).
>
> the testing in our infra returned g
On Thu, 16 Sep 2021 19:40:19 GMT, Kartik Ohri
wrote:
>> Hi all!
>>
>> Please review this PR to add a benchmark comparing the performance of
>> Arrays.mismatch intrinsic in the JDK with that of the Vector API. Kindly
>> refer to this [thread] on panama-dev regarding some initial discussion abo
On Mon, 13 Sep 2021 20:06:08 GMT, Andrey Turbanov
wrote:
> 8273711: Remove redundant stream() call before forEach in jdk.jlink
In some cases you can use a method ref (no need for another review if you
update those).
src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugi
On Tue, 14 Sep 2021 00:15:31 GMT, David Holmes wrote:
> Please review this trivial fix to add the missing comma.
>
> Thanks,
> David
Marked as reviewed by psandoz (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5504
On Fri, 10 Sep 2021 08:32:02 GMT, Kartik Ohri
wrote:
> Hi all!
>
> Please review this PR to add a benchmark comparing the performance of
> Arrays.mismatch intrinsic in the JDK with that of the Vector API. Kindly
> refer to this [thread] on panama-dev regarding some initial discussion about
>
On Fri, 10 Sep 2021 08:32:02 GMT, Kartik Ohri
wrote:
> Hi all!
>
> Please review this PR to add a benchmark comparing the performance of
> Arrays.mismatch intrinsic in the JDK with that of the Vector API. Kindly
> refer to this [thread] on panama-dev regarding some initial discussion about
>
On Tue, 7 Sep 2021 20:25:25 GMT, Sandhya Viswanathan
wrote:
> Fix the copyright header of SVML files to match others.
>
> This was brought up on jdk-dev mailing list:
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html
Marked as reviewed by psandoz (Reviewer).
---
On Wed, 1 Sep 2021 16:16:38 GMT, Vladimir Ivanov wrote:
>> Get rid of WeakReference-based logic in
>> DirectMethodHandle::checkInitialized() and reimplement it with
>> `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`.
>>
>> The key observation is that `Unsafe::ensureClassInitialized
On Wed, 25 Aug 2021 09:31:51 GMT, Vladimir Ivanov wrote:
> `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle`
> and it can introduce a class loader leak through its `MethodType`.
>
> Proposed fix introduces a 2-level cache (1 element each) where 1st level can
> only
On Wed, 25 Aug 2021 22:05:24 GMT, Vladimir Ivanov wrote:
> Get rid of WeakReference-based logic in
> DirectMethodHandle::checkInitialized() and reimplement it with
> `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`.
>
> The key observation is that `Unsafe::ensureClassInitialized()`
On Tue, 24 Aug 2021 20:49:52 GMT, Sandhya Viswanathan
wrote:
>> This pull request adds a micro benchmark for Vector API.
>> The Black Scholes algorithm is implemented with and without Vector API.
>> We see about ~6x gain with Vector API for this micro benchmark using 256 bit
>> vectors.
>
> San
Hi,
Thanks for sharing.
I browsed through the code (not a review) and gave it a test drive, generally
it looks of good quality.
Over time, since LinkedList was added, there are less reasons to use it,
thereby making such improvements you propose less impactful. CPU caches have
got much better
On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote:
> See the bug report for more details. I would appreciate if people with their
> corporate testing systems would run this through their systems to avoid
> surprises. (ping @RealCLanger, @iignatev).
Struggling to recall all the details.
On Sun, 15 Aug 2021 01:43:32 GMT, Brian Goetz wrote:
> To reiterate: These issues were explored in the JSR 335 EG and it was agreed
> that this abstraction did not carry its weight.
Yes, we explored this when the Stream API was being designed. It's hard, if not
impossible, to capture all deci
On Wed, 4 Aug 2021 18:42:08 GMT, Joe Darcy wrote:
> Remove extraneous tag to fix build breakage.
Marked as reviewed by psandoz (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5002
On Tue, 27 Jul 2021 18:31:20 GMT, Sandhya Viswanathan
wrote:
>> Jatin Bhateja has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 19 commits:
>>
>> - 8266054: Re-designing benchmark to remove noise.
>> - Merge branch 'master' of ht
On Wed, 30 Jun 2021 10:23:32 GMT, Jan Lahoda wrote:
>> Currently, an enum switch with patterns is desugared in a very non-standard,
>> and potentially slow, way. It would be better to use the standard
>> `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs
>> to accept en
On Wed, 23 Jun 2021 11:58:06 GMT, Jan Lahoda wrote:
>> Currently, an enum switch with patterns is desugared in a very non-standard,
>> and potentially slow, way. It would be better to use the standard
>> `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs
>> to accept en
On Wed, 23 Jun 2021 19:10:41 GMT, Paul Sandoz wrote:
> The Foreign Memory API supports viewing a `MemorySegment` as a `ByteBuffer`,
> an instance of which can then be passed to the vector load/store access
> methods.
>
> Such `ByteBuffer` access requires accesses are s
The Foreign Memory API supports viewing a `MemorySegment` as a `ByteBuffer`, an
instance of which can then be passed to the vector load/store access methods.
Such `ByteBuffer` access requires accesses are scoped (a method annotated with
`ScopedMemoryAccess.Scoped`) and the `ByteBuffer`'s scope (
On Tue, 22 Jun 2021 02:58:28 GMT, Yi Yang wrote:
> I found that after solving the problem that Preconditions cannot be used
> during the VM startup, a series of functions such as
> String.checkIndex/checkOffset/.. can also be harmlessly replaced, but this
> changeset is somewhat large and may
On Mon, 21 Jun 2021 05:17:09 GMT, Yi Yang wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally
101 - 200 of 2576 matches
Mail list logo
