On Thu, 19 Sep 2024 06:41:16 GMT, Jatin Bhateja wrote:
> > > > > Why is this even called `VectorMath`? Because those ops are not at
> > > > > all restricted to vectorization, right?
> > > >
> > > >
> > > > Nomenclature is suggested by Paul.
> > >
> > >
> > > @PaulSandoz Do you want to limit
On Wed, 18 Sep 2024 14:22:16 GMT, Emanuel Peter wrote:
> > > Do we have tests for the publically exposed methods in this new file? Or
> > > are they only implicitly tested through the VectorAPI, and its tests?
> > > `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java`
>
> Hi All,
>
> As per the discussion on panama-dev mailing list[1], patch adds the support
> following new vector operators.
>
>
> . SUADD : Saturating unsigned addition.
> . SADD: Saturating signed addition.
> . SUSUB : Saturating unsigned subtraction.
> . SSUB:
On Wed, 18 Sep 2024 16:53:53 GMT, Paul Sandoz wrote:
> > > > Why is this even called `VectorMath`? Because those ops are not at all
> > > > restricted to vectorization, right?
> > >
> > >
> > > Nomenclature is suggested by Paul.
> >
> >
> > @PaulSandoz Do you want to limit these **scalar** o
On Tue, 17 Sep 2024 06:28:54 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to deprecate several
> outdated and undocumented java launcher options? This addresses
> https://bugs.openjdk.org/browse/JDK-8286851.
>
> Specifically, the non-standard launcher opti
On Fri, 6 Sep 2024 17:51:15 GMT, Jorn Vernee wrote:
>> As discussed in the JBS issue:
>>
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This
>> `Method*` is read from the `LambdaForm::vmentry` field associated with the
>> target method handle at the time when the upcal
On Thu, 12 Sep 2024 05:12:18 GMT, Amit Kumar wrote:
> This PR will ProblemList `jdk/java/util/zip/CloseInflaterDeflaterTest.java`
> on s390x. This change should be reverted while fixing
> [JDK-8339216](https://bugs.openjdk.org/browse/JDK-8339216).
This pull request has now been integrated.
Ch
On Wed, 18 Sep 2024 13:42:10 GMT, Lutz Schmidt wrote:
>> This PR will ProblemList `jdk/java/util/zip/CloseInflaterDeflaterTest.java`
>> on s390x. This change should be reverted while fixing
>> [JDK-8339216](https://bugs.openjdk.org/browse/JDK-8339216).
>
> Looks good. And trivial.
Thank you @R
The failure handler updated to use gdb scripts.
The initial version print some information about mutextes, safepoint and
threads state. So the deadlocks are easier to analyze without opening core
files.
The existing gdb processing is not changed.
Later the script might be improved with more inf
On Wed, 18 Sep 2024 18:03:47 GMT, Jorn Vernee wrote:
>> This PR moves the section on restricted methods from the the javadoc of
>> `java.lang.foreign` package into a standalone static [javadoc
>> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/la
On Wed, 18 Sep 2024 15:47:01 GMT, Maurizio Cimadamore
wrote:
> This PR moves the section on restricted methods from the the javadoc of
> `java.lang.foreign` package into a standalone static [javadoc
> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/j
On Wed, 18 Sep 2024 18:07:52 GMT, Jorn Vernee wrote:
> Is the java/lang/foreign package still the right place for this? (Maybe it
> should be under java/lang).
I agree, the scope for this is now outside the foreign package.
-
PR Comment: https://git.openjdk.org/jdk/pull/21067#issu
On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote:
>> Please review this PR which removes occurrences of 'applet' within the
>> corelibs specification. Applet has been deprecated since JDK9, and may be a
>> confusing term for new Java developers, so it should be removed from the
>> documentati
On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote:
>> Please review this PR which removes occurrences of 'applet' within the
>> corelibs specification. Applet has been deprecated since JDK9, and may be a
>> confusing term for new Java developers, so it should be removed from the
>> documentati
On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote:
>> Please review this PR which removes occurrences of 'applet' within the
>> corelibs specification. Applet has been deprecated since JDK9, and may be a
>> confusing term for new Java developers, so it should be removed from the
>> documentati
On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote:
>> Please review this PR which removes occurrences of 'applet' within the
>> corelibs specification. Applet has been deprecated since JDK9, and may be a
>> confusing term for new Java developers, so it should be removed from the
>> documentati
On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote:
>> Please review this PR which removes occurrences of 'applet' within the
>> corelibs specification. Applet has been deprecated since JDK9, and may be a
>> confusing term for new Java developers, so it should be removed from the
>> documentati
On Wed, 18 Sep 2024 15:47:01 GMT, Maurizio Cimadamore
wrote:
> This PR moves the section on restricted methods from the the javadoc of
> `java.lang.foreign` package into a standalone static [javadoc
> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/j
On Wed, 18 Sep 2024 06:53:27 GMT, Alan Bateman wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reflect review comments
>
> src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 39:
>
>> 37: * im
On Wed, 18 Sep 2024 06:52:17 GMT, Alan Bateman wrote:
>> `repaint()` could be substituted with another arbitrary method name to
>> highlight some work this thread has to perform.
>>
>> given the thread name `blink`, perhaps we could just use `blink()` in this
>> example.
>
> Don't waste too mu
> Please review this PR which removes occurrences of 'applet' within the
> corelibs specification. Applet has been deprecated since JDK9, and may be a
> confusing term for new Java developers, so it should be removed from the
> documentation.
>
> Primarily, usages where 'applet' is used interch
On Tue, 17 Sep 2024 16:13:55 GMT, Quan Anh Mai wrote:
> Hi,
>
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just
> the revert of the backout.
>
> Regarding the related issues:
>
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and
> [JDK-8309531](ht
On Wed, 18 Sep 2024 17:18:42 GMT, Paul Sandoz wrote:
> Will this have any direct impact on the changes proposed by #20508 and #20634?
I think we should first get the 20508 and 20634 integrated before this one.
-
PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-235902
On Tue, 17 Sep 2024 16:13:55 GMT, Quan Anh Mai wrote:
> Hi,
>
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just
> the revert of the backout.
>
> Regarding the related issues:
>
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and
> [JDK-8309531](ht
On Wed, 18 Sep 2024 16:22:30 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> following new vector operators.
>>
>>
>> . SUADD : Saturating unsigned addition.
>> . SADD: Saturating signed addition.
>>
> Currently the rearrange and selectFrom APIs check shuffle indices and throw
> IndexOutOfBoundsException if there is any exceptional source index in the
> shuffle. This causes the generated code to be less optimal. This PR modifies
> the rearrange/selectFrom Vector API methods to perform wrapIn
On Wed, 18 Sep 2024 14:22:16 GMT, Emanuel Peter wrote:
> > > Why is this even called `VectorMath`? Because those ops are not at all
> > > restricted to vectorization, right?
> >
> >
> > Nomenclature is suggested by Paul.
>
> @PaulSandoz Do you want to limit these **scalar** operations to a cl
Hi Viktor
Let me start with a question: is the requirement (a) "a Gatherer SHOULD be
reusable", or (b) "a Gatherer MUST be reusable"?
As of today the specification says (b), whereas the implementation matches (a).
In case of (a), I propose to align the specification to allow for compliant,
non-
On Wed, 18 Sep 2024 14:22:16 GMT, Emanuel Peter wrote:
> > > Do we have tests for the publically exposed methods in this new file? Or
> > > are they only implicitly tested through the VectorAPI, and its tests?
> > > `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java`
>
> Hi All,
>
> As per the discussion on panama-dev mailing list[1], patch adds the support
> following new vector operators.
>
>
> . SUADD : Saturating unsigned addition.
> . SADD: Saturating signed addition.
> . SUSUB : Saturating unsigned subtraction.
> . SSUB:
On Tue, 17 Sep 2024 22:29:01 GMT, Paul Sandoz wrote:
>> @PaulSandoz What do you think regarding x86-32?
>
>> @PaulSandoz What do you think regarding x86-32?
>
> I don't see anything obvious in the changes of this PR that would affect
> x86-32, but i ain't a HotSpot expert. Perhaps this just exa
On Tue, 17 Sep 2024 22:29:01 GMT, Paul Sandoz wrote:
> > @PaulSandoz What do you think regarding x86-32?
>
> I don't see anything obvious in the changes of this PR that would affect
> x86-32, but i ain't a HotSpot expert. Perhaps this just exacerbates some
> existing bug?@sviswa7 what do you t
On Tue, 17 Sep 2024 16:59:07 GMT, Quan Anh Mai wrote:
> @PaulSandoz What do you think regarding x86-32?
I don't see anything obvious in the changes of this PR that would affect
x86-32, but i ain't a HotSpot expert. Perhaps this just exacerbates some
existing bug?@sviswa7 what do you think?
My
On Tue, 17 Sep 2024 16:13:55 GMT, Quan Anh Mai wrote:
> Hi,
>
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just
> the revert of the backout.
>
> Regarding the related issues:
>
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and
> [JDK-8309531](ht
Hi,
This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just
the revert of the backout.
Regarding the related issues:
- [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and
[JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed
before the bac
This PR moves the section on restricted methods from the the javadoc of
`java.lang.foreign` package into a standalone static [javadoc
page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
This is because,
On Wed, 18 Sep 2024 05:54:40 GMT, Jaikiran Pai wrote:
> The current state of this PR looks good to me. I'll review the CSR too.
Thanks, @jaikiran, for your assistance.
-
PR Comment: https://git.openjdk.org/jdk/pull/20320#issuecomment-2358842957
On Wed, 18 Sep 2024 12:23:48 GMT, Emanuel Peter wrote:
> I'm a bit confused by the name `shuffleWrapIndexes` and
> `inline_vector_shuffle_wrap_indexes`.
>
> Are you **shuffling wrap-indexes**? I don't know what that would even mean. I
> think you should name it `wrapShuffleIndexes`. Or is ther
On Wed, 18 Sep 2024 13:44:11 GMT, Jatin Bhateja wrote:
> > Do we have tests for the publically exposed methods in this new file? Or
> > are they only implicitly tested through the VectorAPI, and its tests?
> > `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java`
> > Why
On Wed, 18 Sep 2024 12:35:28 GMT, Emanuel Peter wrote:
>> src/hotspot/cpu/x86/x86.ad line 6578:
>>
>>> 6576: %}
>>> 6577: ins_pipe( pipe_slow );
>>> 6578: %}
>>
>> Above, you name both the `format` and method name with `_reg` and `_mem`,
>> but here you do not do it for the method name. Wo
On Wed, 18 Sep 2024 12:51:00 GMT, Emanuel Peter wrote:
> Do we have tests for the publically exposed methods in this new file? Or are
> they only implicitly tested through the VectorAPI, and its tests?
> `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java`
>
> Why is t
On Thu, 12 Sep 2024 05:12:18 GMT, Amit Kumar wrote:
> This PR will ProblemList `jdk/java/util/zip/CloseInflaterDeflaterTest.java`
> on s390x. This change should be reverted while fixing
> [JDK-8339216](https://bugs.openjdk.org/browse/JDK-8339216).
Looks good. And trivial.
-
Marke
> Hi All,
>
> As per the discussion on panama-dev mailing list[1], patch adds the support
> following new vector operators.
>
>
> . SUADD : Saturating unsigned addition.
> . SADD: Saturating signed addition.
> . SUSUB : Saturating unsigned subtraction.
> . SSUB:
On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu wrote:
> Please review this PR which removes occurrences of 'applet' within the
> corelibs specification. Applet has been deprecated since JDK9, and may be a
> confusing term for new Java developers, so it should be removed from the
> documentation.
On Tue, 17 Sep 2024 07:14:57 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> following new vector operators.
>>
>>
>> . SUADD : Saturating unsigned addition.
>> . SADD: Saturating signed addition.
>>
On Wed, 18 Sep 2024 12:34:58 GMT, Emanuel Peter wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Missed code fragment from last review comment resolution.
>
> src/hotspot/cpu/x86/x86.ad line 6578:
>
>> 6576: %}
Hi Olexandr,
The initial set of Gatherers is not currently planned to change. With that
said, that doesn't mean that that set is fixed forever, rather we want to see
what people end up having to re-implement and see which ones of those would
make sense to incorporate down the line.
Cheers,
√
On Sun, 11 Aug 2024 22:25:40 GMT, Rafael Winterhalter
wrote:
> When a type uses a type variable without a declaration, no exception is
> thrown. This change triggers a `TypeNotFoundException` to be thrown.
This pull request has now been integrated.
Changeset: 1d070a32
Author:Rafael Winter
On Fri, 13 Sep 2024 22:30:36 GMT, Sandhya Viswanathan
wrote:
>> Currently the rearrange and selectFrom APIs check shuffle indices and throw
>> IndexOutOfBoundsException if there is any exceptional source index in the
>> shuffle. This causes the generated code to be less optimal. This PR modifi
On Tue, 17 Sep 2024 07:02:20 GMT, Jatin Bhateja wrote:
>> src/hotspot/share/opto/vectornode.cpp line 2122:
>>
>>> 2120: // index format by subsequent VectorLoadShuffle.
>>> 2121: int cast_vopc = VectorCastNode::opcode(0, index_elem_bt, true);
>>> 2122: Node* index_byte_vec =
>>> phase->tr
On Wed, 18 Sep 2024 07:21:52 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> for following new two vector permutation APIs.
>>
>>
>> Declaration:-
>> Vector.selectFrom(Vector v1, Vector v2)
>>
>>
>> Semantics:-
>>
On Wed, 18 Sep 2024 03:04:50 GMT, Ioi Lam wrote:
>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> The implementation of java.lang.invoke uses SoftReferences so that unused
>> MethodHandles, LambdaForms, etc, can b
Is in-built gatherers list finalized? I was thinking that
Gatherers::uniqueBy(Function) could be very popular
among stream users, although it is fairly easy to implement yourself (as
well as bunch of currently in-built ones though)
On Tue, Sep 3, 2024, 00:59 David Alayachew wrote:
> Thanks. Glad
Thanks David!
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
From: David Alayachew
Sent: Monday, 2 September 2024 23:58
To: core-libs-dev@openjdk.org
Cc: Viktor Klang ; jdk-...@openjdk.org
Subject: [External] : Re: New candidate JEP: 48
>
> It does not control, nor can it control, where the byte data comes from or
> where the byte data goes.
That's true. Although, why I am saying that one of the Class-File API goals
is to allow semantic modifications, is because the authors of API
specifically said that when asked about use case
On Thu, 12 Sep 2024 05:12:18 GMT, Amit Kumar wrote:
> This PR will ProblemList `jdk/java/util/zip/CloseInflaterDeflaterTest.java`
> on s390x. This change should be reverted while fixing
> [JDK-8339216](https://bugs.openjdk.org/browse/JDK-8339216).
@RealLucy can you have a quick look at this on
On Fri, 13 Sep 2024 14:49:01 GMT, Emanuel Peter wrote:
>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java
>> line 544:
>>
>>> 542: byte[] vpayload1 = ((ByteVector)v1).vec();
>>> 543: byte[] vpayload2 = ((ByteVector)v2).vec();
>>> 544: byte[] v
> Hi All,
>
> As per the discussion on panama-dev mailing list[1], patch adds the support
> for following new two vector permutation APIs.
>
>
> Declaration:-
> Vector.selectFrom(Vector v1, Vector v2)
>
>
> Semantics:-
> Using index values stored in the lanes of "this" vector, assembl
On Tue, 17 Sep 2024 09:28:02 GMT, Claes Redestad wrote:
> This PR exploits the observation that in many of the cases where we call
> `methodType.invokerType()` we immediately translate it into a `Name[]` where
> the only effect is to create an array with an additional leading
> `BasicType.L_TY
On Tue, 17 Sep 2024 22:40:34 GMT, Claes Redestad wrote:
>> This PR exploits the observation that in many of the cases where we call
>> `methodType.invokerType()` we immediately translate it into a `Name[]` where
>> the only effect is to create an array with an additional leading
>> `BasicType.
60 matches
Mail list logo
