On 19/05/2021 10:15, Andrew Haley wrote:
:
Yes, that's true. I think that what you have in mind is a more elaborate
mechanism than what is proposed here, which does no more than bind values
to names over a scope. There needs to be more discussion in the JEP of
what this proposal isn't intended
On Wed, 19 May 2021 08:20:13 GMT, Jatin Bhateja wrote:
> Relevant declarations modified and tested with -Werror, no longer see
> unchecked conversion warnings.
>
> Kindly review and approve.
Marked as reviewed by thartmann (Reviewer).
-
PR:
On Wed, 19 May 2021 08:20:13 GMT, Jatin Bhateja wrote:
> Relevant declarations modified and tested with -Werror, no longer see
> unchecked conversion warnings.
>
> Kindly review and approve.
This pull request has now been integrated.
Changeset: 88b11423
Author:Jatin Bhateja
URL:
On Tue, 18 May 2021 22:41:06 GMT, Brent Christian wrote:
>> Please review this enhancement to add a new JFR event, generated whenever a
>> finalizer is run.
>> (The makeup is similar to the Deserialization event,
>> [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
>>
>> The
On 5/18/21 3:19 AM, Mike Rettig wrote:
> With the current proposal I can't simply flush and close at the
> end of the scope because there might be a child scope that is still active.
Yes, that's true. I think that what you have in mind is a more elaborate
mechanism than what is proposed here,
Relevant declarations modified and tested with -Werror, no longer see unchecked
conversion warnings.
Kindly review and approve.
-
Commit messages:
- 8267357: build breaks with -Werror option on micro benchmark added for
JDK-8256973
Changes:
On Tue, 18 May 2021 23:14:53 GMT, Stephen Colebourne
wrote:
>> src/java.base/share/classes/java/time/Clock.java line 487:
>>
>>> 485: // it more unlikely to hit the 1ns in the future condition.
>>> 486: localOffset = System.currentTimeMillis()/1000 - 1024;
>>> 487:
>>
On Wed, 19 May 2021 08:20:13 GMT, Jatin Bhateja wrote:
> Relevant declarations modified and tested with -Werror, no longer see
> unchecked conversion warnings.
>
> Kindly review and approve.
LGTM
-
Marked as reviewed by jiefu (Reviewer).
PR:
On 5/15/21 6:50 PM, Peter Levart wrote:
> What if I wanted to create and start a thread that would be "pristine" -
> not have any ScopeLocal value bound? Is this intentionally not allowed
> in order to make sure that inheritable ScopeLocal(s) can't be cleared by
> code that has no access to
On Wed, 19 May 2021 07:50:55 GMT, Erik Gahlin wrote:
> I wonder if there needs to be one event per finalized object?
>
> Perhaps a counter per class would be as useful, i.e.
> jdk.FinalizationStatistics, and if it could be implemented in the VM, without
> other implications, that would be
On Tue, 18 May 2021 22:41:06 GMT, Brent Christian wrote:
>> Please review this enhancement to add a new JFR event, generated whenever a
>> finalizer is run.
>> (The makeup is similar to the Deserialization event,
>> [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
>>
>> The
> This is a preview of a patch implementing JEP 406: Pattern Matching for
> switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
>
> The current draft of the specification is here:
> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
>
> A
On Wed, 19 May 2021 03:37:11 GMT, Sandhya Viswanathan
wrote:
>> This PR contains Short Vector Math Library support related changes for
>> [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414),
>> in preparation for when targeted.
>>
>> Intel Short Vector Math Library
On Wed, 19 May 2021 08:20:13 GMT, Jatin Bhateja wrote:
> Relevant declarations modified and tested with -Werror, no longer see
> unchecked conversion warnings.
>
> Kindly review and approve.
Looks good.
-
Marked as reviewed by neliasso (Reviewer).
PR:
On Wed, 19 May 2021 23:50:04 GMT, Phil Race wrote:
>> I just made it P3 (P4 was the default value), and I will target it to 17
>> once JEP 411 is targeted 17. But I think it's probably not a good idea to
>> include it inside *this* PR. There are some middle ground where it's
>> debatable if a
On Thu, 20 May 2021 02:06:46 GMT, Weijun Wang wrote:
>> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and
>> definitely if it misses the fork,
>> and I don't get why you can't do it here. And if it isn't done the JEP isn't
>> really ready.
>> I already pasted the patch
On Thu, 20 May 2021 02:09:57 GMT, Weijun Wang wrote:
>> I can make it a bug.
>>
>> I don't want to do it here is because it involves indefinite amount of
>> manual work and we will see everyone having their preferences. The more time
>> we spend on this PR the more likely there will be merge
On Thu, 20 May 2021 04:05:23 GMT, Phil Race wrote:
>> By converting JDK-8267432 to a bug, there is an extra benefit that we can
>> fix it after RDP. So I'll convert it now.
>
> That is unfortunate, but nonetheless I think required to be done.
> We have acknowledeged this can't reasonably be
> Update module summary, add a few existing properties and features into the
> tables.
Joe Wang has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase. The pull request contains six
On Tue, 18 May 2021 23:35:12 GMT, Naoto Sato wrote:
>> test/jdk/java/util/Locale/LocaleTest.java line 683:
>>
>>> 681: * @bug 4052404 4778440 8263202
>>> 682: */
>>> 683: public void TestChangedISO639Codes() {
>>
>> Could probably be simplified with a DataProvider.
>
> That would
On Tue, 18 May 2021 23:39:37 GMT, Naoto Sato wrote:
>> Please review the changes to the subject issue. java.util.Locale class has a
>> long-standing issue for those obsolete ISO 639 languages where its
>> normalization ends up in the obsolete codes. This change intends to flip the
>>
On Tue, 18 May 2021 22:41:06 GMT, Brent Christian wrote:
>> Please review this enhancement to add a new JFR event, generated whenever a
>> finalizer is run.
>> (The makeup is similar to the Deserialization event,
>> [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
>>
>> The
On Wed, 19 May 2021 06:20:59 GMT, Erik Gahlin wrote:
> This looks useful, but I am worried about the performance impact:
>
> * The added allocation for every object that is finalized.
> * The event being enabled in the default configuration.
>
> The default configuration must be safe to use
On Tue, 18 May 2021 23:01:05 GMT, Mark Reinhold wrote:
>> Please review this implementation of JEP 403
>> (https://openjdk.java.net/jeps/403).
>> Alan Bateman is the original author of almost all of it. Passes tiers 1-3
>> on
>> {linux,macos,windows}-x64 and {linux,macos}-aarch64.
>
> Mark
> Hi,
>
> Could someone please review my code for updating the code in the `java.util`
> package to make use of the `instanceof` pattern variable?
>
> Kind regards,
> Patrick
Patrick Concannon has updated the pull request with a new target base due to a
merge or a rebase. The incremental
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
> This PR contains the API and implementation changes for JEP-412 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/412
Maurizio Cimadamore has updated the pull
On Tue, 18 May 2021 23:01:05 GMT, Mark Reinhold wrote:
>> Please review this implementation of JEP 403
>> (https://openjdk.java.net/jeps/403).
>> Alan Bateman is the original author of almost all of it. Passes tiers 1-3
>> on
>> {linux,macos,windows}-x64 and {linux,macos}-aarch64.
>
> Mark
On Tue, 18 May 2021 21:21:45 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
> Please review this implementation of [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> The code change is divided into 3 commits. Please review them one by one.
>
> 1.
> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
> The essential change for this JEP,
I added
--jlink-options '--strip-debug --no-man-pages --no-header-files’
to my invocation, avoiding --strip-native-commands, so that the native java
commands are not stripped. I believe currently recommended jpackage way to do
this.
I get the following commands in my embedded JDK
java
This patch adds a `--validate` option to the jar tool which can be used to
validate a jar file that might be malformed. For instance, if a jar is a
multi-release jar, it is malformed if different versions expose different APIs.
The implementation is straight forward since there already exists
On Tue, 18 May 2021 20:59:49 GMT, Claes Redestad wrote:
> Using a switch expression instead of a (read-only) static `HashMap` reduces
> initialization overhead of `VarHandle$AccessMode`. This gets loaded earlier
> after JDK-8265079, so it started showing up in a few lambda startup tests.
>
>
I don't think jlink will ever include the jdk development tools in a
custom runtime (using jlink on windows or mac without
--strip-native-commands only gives me java and keytool), but you can
include the whole jdk (less src.zip and the jmods directory) by using
--runtime-image and pointing
On Wed, 19 May 2021 14:31:48 GMT, Jorn Vernee wrote:
> LGTM. I assume existing tests verify that all values of the enum are covered
> by the switch?
Thanks! Yes, the method with the switch is called when linking a VH, and the
tests should be exhaustive in that regard.
-
PR:
On Tue, 18 May 2021 20:59:49 GMT, Claes Redestad wrote:
> Using a switch expression instead of a (read-only) static `HashMap` reduces
> initialization overhead of `VarHandle$AccessMode`. This gets loaded earlier
> after JDK-8265079, so it started showing up in a few lambda startup tests.
>
>
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
On Wed, 19 May 2021 14:11:40 GMT, Jaroslav Bachorik
wrote:
>> With this change it becomes possible to surface various cgroup level metrics
>> (available via `jdk.internal.platform.Metrics`) as JFR events.
>>
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
>>
On Wed, 19 May 2021 15:23:55 GMT, Jaroslav Bachorik
wrote:
>> With this change it becomes possible to surface various cgroup level metrics
>> (available via `jdk.internal.platform.Metrics`) as JFR events.
>>
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
>>
> This patch adds a `--validate` option to the jar tool which can be used to
> validate a jar file that might be malformed. For instance, if a jar is a
> multi-release jar, it is malformed if different versions expose different
> APIs.
>
> The implementation is straight forward since there
On Mon, 1 Feb 2021 13:11:52 GMT, Aleksey Shipilev wrote:
> Since Compact Strings implementation, there are simple methods in String and
> StringBuilders: `coder()`, `value()`, `isLatin1()`. They are mostly there to
> capture `COMPACT_STRINGS` flag that would fold to "false" when compact
>
> On May 19, 2021, at 9:40 AM, Andy Herrick wrote:
>
> I don't think jlink will ever include the jdk development tools in a custom
> runtime (using jlink on windows or mac without --strip-native-commands only
> gives me java and keytool),
Mac gave me the 9 commands shown earlier. Something
> Please review this PR which fixes the deadlock in ClassLoader between the two
> lock objects - a lock object associated with the class being loaded, and the
> ClassLoader.loadedLibraryNames hash map, locked during the native library
> load operation.
>
> Problem being fixed:
>
> The initial
On Thu, 17 Dec 2020 13:36:17 GMT, PROgrm_JARvis
wrote:
> Please review this change moving lookup of MD5 digest in `java.lang.UUID` to
> an internal holder class.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.net/jdk/pull/1821
Hi David, Mandy,
In the updated PR I removed the lock held during the load/unload calls.
Our testing confirmed that without that removal the deadlock can easily
be reproduced, even without signed jars. Now the lock is only held to
prevent races during access to "libraries" and
> Please review this PR which fixes the deadlock in ClassLoader between the two
> lock objects - a lock object associated with the class being loaded, and the
> ClassLoader.loadedLibraryNames hash map, locked during the native library
> load operation.
>
> Problem being fixed:
>
> The initial
On Wed, 19 May 2021 16:21:41 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked during the native
>>
On Tue, 18 May 2021 23:18:42 GMT, Stephen Colebourne
wrote:
>> 8266846: Add java.time.InstantSource
>
> Stephen Colebourne has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8266846: Add java.time.InstantSource
On Tue, 18 May 2021 23:22:49 GMT, Stephen Colebourne
wrote:
>> test/jdk/java/time/test/java/time/TestInstantSource.java line 86:
>>
>>> 84: assertEquals(test.instant(), instant);
>>> 85: assertSame(test.equals(InstantSource..fixed(instant));
>>> 86:
On Tue, 18 May 2021 23:01:05 GMT, Mark Reinhold wrote:
>> Please review this implementation of JEP 403
>> (https://openjdk.java.net/jeps/403).
>> Alan Bateman is the original author of almost all of it. Passes tiers 1-3
>> on
>> {linux,macos,windows}-x64 and {linux,macos}-aarch64.
>
> Mark
On 15/05/2021 19:50, Peter Levart wrote:
Another question: Suppose there are two inheritable ScopeLocal
variables with bound values in scope (A and B) when I take a snapshot:
var snapshot = ScopeLocal.snapshot();
now I pass that snapshot to a thread which does the following:
ScopeLocal
On Fri, 14 May 2021 23:58:38 GMT, Sandhya Viswanathan
wrote:
> Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and
> IS_NEGATIVE) are computed in three steps:
> 1) reinterpreting the floating point vectors as integral vectors (int/long)
> 2) perform the test in integer
On Wed, 19 May 2021 08:41:08 GMT, Peter Levart wrote:
>> This isn't my logic - it is existing code that has been moved. I'm not a fan
>> of infinite retry loops as the can hang the system. But I'm happy to change
>> it to work that way if there is a consensus to do so.
>
> I see the
On Wed, 21 Apr 2021 22:38:32 GMT, Erik Gahlin wrote:
>> Jaroslav Bachorik has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR.
>
> I wonder if something similar to
On Wed, 19 May 2021 09:00:27 GMT, Alan Bateman wrote:
> I wonder if there needs to be one event per finalized object?
I also concern with the performance overhead of one event per finalized object.
The primary goal of this JFR event is to help identifying the use of finalizers
in existing
On Wed, 21 Apr 2021 22:38:32 GMT, Erik Gahlin wrote:
>> Jaroslav Bachorik has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR.
>
> I wonder if something similar to
On Tue, 18 May 2021 23:18:42 GMT, Stephen Colebourne
wrote:
>> 8266846: Add java.time.InstantSource
>
> Stephen Colebourne has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8266846: Add java.time.InstantSource
Another test started failing
On Tue, 18 May 2021 22:41:06 GMT, Brent Christian wrote:
>> Please review this enhancement to add a new JFR event, generated whenever a
>> finalizer is run.
>> (The makeup is similar to the Deserialization event,
>> [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
>>
>> The
On Tue, 18 May 2021 23:18:42 GMT, Stephen Colebourne
wrote:
>> 8266846: Add java.time.InstantSource
>
> Stephen Colebourne has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8266846: Add java.time.InstantSource
It's a side effect of JEP
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Thu, 26 Nov 2020 18:51:10 GMT, Richard Fussenegger
wrote:
> 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant
@bridgekeeper I guess it will stay open for a little longer.
-
PR: https://git.openjdk.java.net/jdk/pull/1467
On Sat, 28 Nov 2020 10:12:10 GMT, Richard Fussenegger
wrote:
>> Made byte constructor public and changed the length assertion to an
>> `IllegalArgumentException`, added a `getBytes` method that allows users to
>> retrieve the raw bytes of the UUID, and created a new private constructor
>>
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Tue, 18 May 2021 23:18:42 GMT, Stephen Colebourne
wrote:
>> 8266846: Add java.time.InstantSource
>
> Stephen Colebourne has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8266846: Add java.time.InstantSource
The Error was caused by the
On Wed, 19 May 2021 18:26:25 GMT, Phil Race wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.desktop/share/classes/java/awt/Component.java
On Wed, 19 May 2021 17:57:11 GMT, Erik Gahlin wrote:
> > I was also thinking if this event should be implemented in the VM in order
> > to avoid some performance overhead such as object allocation. Erik, what is
> > the benefit of implementing in in the VM?
>
> No startup cost, no allocation
On Wed, 19 May 2021 18:39:10 GMT, Weijun Wang wrote:
>> src/java.desktop/share/classes/java/awt/Container.java line 97:
>>
>>> 95: * @since 1.0
>>> 96: */
>>> 97: @SuppressWarnings("removal")
>>
>> Same issue as with Component. a > 5,000 line file that uses AccessController
>> in just 4
On Wed, 19 May 2021 16:29:33 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked during the native
>>
On Wed, 19 May 2021 18:44:06 GMT, Weijun Wang wrote:
>> Similar as the one above, it's because of
>>
>> static {
>> // Don't lazy-read because every app uses invalidate()
>> isJavaAwtSmartInvalidate = AccessController.doPrivileged(
>> new
On Tue, 18 May 2021 23:18:42 GMT, Stephen Colebourne
wrote:
>> 8266846: Add java.time.InstantSource
>
> Stephen Colebourne has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8266846: Add java.time.InstantSource
my bad
-
PR:
On Wed, 19 May 2021 03:37:11 GMT, Sandhya Viswanathan
wrote:
>> This PR contains Short Vector Math Library support related changes for
>> [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414),
>> in preparation for when targeted.
>>
>> Intel Short Vector Math Library
On Wed, 19 May 2021 18:38:39 GMT, Weijun Wang wrote:
>> src/java.desktop/share/classes/java/awt/Component.java line 217:
>>
>>> 215: * @author Sami Shaio
>>> 216: */
>>> 217: @SuppressWarnings("removal")
>>
>> Why is this placed on the *entire class* ??
>> This class is 10535 lines long
On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang wrote:
>> Please review the test changes for [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> With JEP 411 and the default value of `-Djava.security.manager` becoming
>> `disallow`, tests calling `System.setSecurityManager()` need
>>
> Please review this PR that intents to make sealed classes a final feature in
> Java. This PR contains compiler and VM changes. In line with similar PRs,
> which has made preview features final, this one is mostly removing preview
> related comments from APIs plus options in test cases. Please
On Wed, May 19, 2021 at 4:01 AM Andrew Haley wrote:
> On 5/15/21 6:50 PM, Peter Levart wrote:
> > What if I wanted to create and start a thread that would be "pristine" -
> > not have any ScopeLocal value bound? Is this intentionally not allowed
> > in order to make sure that inheritable
For debug build on macOS, runtime which used for test fill be located in
/path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files except
fastdebug and in this case our check to decide if we need to copy app or
runtime will return /path/jdk-17 which is not correct. Fixed by
Has it ever been conceived to create an entire new API like how it was
done for Dates and Times? Obviously this would be a massive
undertaking, but it seems to me we've just about reached the limits of
how far we can stretch the current API.
"This code is a mess, we should throw it away and
On Wed, May 12, 2021 at 9:43 AM Andrew Haley wrote:
> There's been considerable discussion about scope locals on the loom-dev
> list,
> and it's now time to open this to a wider audience. This subject is
> important
> because. although scope locals were motivated by the the needs of Loom,
> they
> This PR contains Short Vector Math Library support related changes for
> [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414),
> in preparation for when targeted.
>
> Intel Short Vector Math Library (SVML) based intrinsics in native x86
> assembly provide optimized
On Wed, 19 May 2021 19:31:24 GMT, Phil Race wrote:
>> This happens when a deprecated method is called inside a static block. The
>> annotation can only be added to a declaration and here it must be the whole
>> class. The call in this file is
>>
>> s =
> 8266846: Add java.time.InstantSource
Stephen Colebourne has updated the pull request incrementally with one
additional commit since the last revision:
8266846: Add java.time.InstantSource
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/4016/files
- new:
On Tue, 18 May 2021 23:18:42 GMT, Stephen Colebourne
wrote:
>> 8266846: Add java.time.InstantSource
>
> Stephen Colebourne has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8266846: Add java.time.InstantSource
I've made the obvious changes
On Mon, 3 May 2021 21:41:26 GMT, Paul Sandoz wrote:
>> Sandhya Viswanathan has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains six commits:
>>
>> - Merge master
>> - remove whitespace
>> - Merge master
>> - Small fix
>> -
On Mon, 3 May 2021 21:41:26 GMT, Paul Sandoz wrote:
>> Sandhya Viswanathan has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains six commits:
>>
>> - Merge master
>> - remove whitespace
>> - Merge master
>> - Small fix
>> -
On Wed, 19 May 2021 21:53:35 GMT, Weijun Wang wrote:
>> That's a sad limitation of the annotation stuff then, but I don't think that
>> it is insurmountable.
>> You can define a static private method to contain this and call it from the
>> static initializer block.
>> Much better than applying
> This PR contains Short Vector Math Library support related changes for
> [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414),
> in preparation for when targeted.
>
> Intel Short Vector Math Library (SVML) based intrinsics in native x86
> assembly provide optimized
On Wed, 19 May 2021 22:02:14 GMT, Paul Sandoz wrote:
>> Tier 1 to 3 tests pass for the default set of build profiles.
>
>> Thanks a lot for the review @PaulSandoz @iwanowww @erikj79.
>> Paul and Vladimir, I have implemented your review comments. Please take a
>> look.
>
> `case VECTOR_OP_OR`
On Wed, 19 May 2021 22:04:57 GMT, Phil Race wrote:
>> Correct, there are ways to modify the code to make it more
>> annotation-friendly. We thought about whether it's good to do it before
>> adding the annotations or after it. Our decision now is to do it after
>> because it will be more easy
On Wed, 19 May 2021 22:16:18 GMT, Sandhya Viswanathan
wrote:
>> This PR contains Short Vector Math Library support related changes for
>> [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414),
>> in preparation for when targeted.
>>
>> Intel Short Vector Math Library
On 20/05/2021 2:29 am, Aleksei Voitylov wrote:
On Wed, 19 May 2021 16:21:41 GMT, Aleksei Voitylov
wrote:
Please review this PR which fixes the deadlock in ClassLoader between the two
lock objects - a lock object associated with the class being loaded, and the
ClassLoader.loadedLibraryNames
> This PR contains Short Vector Math Library support related changes for
> [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414),
> in preparation for when targeted.
>
> Intel Short Vector Math Library (SVML) based intrinsics in native x86
> assembly provide optimized
On Wed, 19 May 2021 21:58:08 GMT, Stephen Colebourne
wrote:
>> 8266846: Add java.time.InstantSource
>
> Stephen Colebourne has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8266846: Add java.time.InstantSource
I believe that the default
> This PR contains Short Vector Math Library support related changes for
> [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414),
> in preparation for when targeted.
>
> Intel Short Vector Math Library (SVML) based intrinsics in native x86
> assembly provide optimized
On Wed, 19 May 2021 22:14:20 GMT, Weijun Wang wrote:
>> I don't think it is a separate P4 enhancement (?) that someone will (maybe)
>> do next release.
>> I think it should all be taken care of as part of this proposed change.
>
> I just made it P3 (P4 was the default value), and I will target
On Wed, 19 May 2021 16:51:33 GMT, Paul Sandoz wrote:
>> Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and
>> IS_NEGATIVE) are computed in three steps:
>> 1) reinterpreting the floating point vectors as integral vectors (int/long)
>> 2) perform the test in integer domain
> Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and
> IS_NEGATIVE) are computed in three steps:
> 1) reinterpreting the floating point vectors as integral vectors (int/long)
> 2) perform the test in integer domain to get a int/long mask
> 3) reinterpret the int/long mask
Hi,
I have made some changes to the Strings class I proposed in my previous message.
The changes are:
* Use str.isEmpty() instead of EMPTY_STRING.equals(str)
* Create methods using str.strip() to check a String is not Whitespace
You can see the new code here:
On Mon, 3 May 2021 13:16:06 GMT, Jaroslav Bachorik
wrote:
>> With this change it becomes possible to surface various cgroup level metrics
>> (available via `jdk.internal.platform.Metrics`) as JFR events.
>>
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
>>
On Wed, 19 May 2021 10:00:04 GMT, Severin Gehwolf wrote:
>> Jaroslav Bachorik has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains 10 commits:
>>
>> - Small fixes
>> - Remove trailing spaces
>> - Doh
>> - Report container type and
1 - 100 of 101 matches
Mail list logo
