On Wed, 11 Nov 2020 18:52:10 GMT, Mandy Chung wrote:
> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live
> objects
> be shared between a hidden class and other classes. A hidden class can load
> these live objects as dynamically-computed constants via this API.
>
>
On Wed, 11 Nov 2020 11:05:47 GMT, Vladimir Ivanov wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with 10
>> additional commits since the last revision:
>>
>> - Merge pull request #7 from JornVernee/Additional_Review_Comments
>>
>>Additional review comments
>>
On Wed, 11 Nov 2020 14:17:20 GMT, Vladimir Ivanov wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with 10
>> additional commits since the last revision:
>>
>> - Merge pull request #7 from JornVernee/Additional_Review_Comments
>>
>>Additional review comments
>>
On Wed, 11 Nov 2020 12:44:56 GMT, Vladimir Ivanov wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with 10
>> additional commits since the last revision:
>>
>> - Merge pull request #7 from JornVernee/Additional_Review_Comments
>>
>>Additional review comments
>>
On Wed, 11 Nov 2020 13:25:32 GMT, Doug Simon wrote:
>> The context is a thread that is spawned by native code doing an upcall. We
>> need to attach the thread to the VM first in that case. Normally this would
>> be handled by the calling code, but in our case the calling code doesn't
>> know
On Wed, 11 Nov 2020 07:18:33 GMT, David Holmes wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with 10
>> additional commits since the last revision:
>>
>> - Merge pull request #7 from JornVernee/Additional_Review_Comments
>>
>>Additional review comments
>> -
On Fri, 23 Oct 2020 17:47:36 GMT, Jorn Vernee wrote:
> Hi,
>
> This patch adds an asExact() combinator to VarHandle, that will return a new
> VarHandle that performs exact type checks, similar to
> MethodHandle::invokeExact, to help developers catch inexact VarHandle usage,
&
at the location where the VarHandle is
> being used.
>
> Thanks,
> Jorn
>
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
Add additional asserts to tests
On Tue, 10 Nov 2020 16:27:48 GMT, Chris Hegarty wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Re-order javadoc
>
> LGTM.
>
> The test could be sprinkled with a number of ass
at the location where the VarHandle is
> being used.
>
> Thanks,
> Jorn
>
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
Re-order javadoc
-
On Mon, 9 Nov 2020 04:10:30 GMT, David Holmes wrote:
>> Maurizio Cimadamore has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 64 commits:
>>
>> - Merge branch '8254162' into 8254231_linker
>> - Fix post-merge issues caused by
On Mon, 9 Nov 2020 03:52:27 GMT, David Holmes wrote:
>> Maurizio Cimadamore has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 64 commits:
>>
>> - Merge branch '8254162' into 8254231_linker
>> - Fix post-merge issues caused by
On Mon, 9 Nov 2020 03:56:38 GMT, David Holmes wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix typo in upcall helper for aarch64
>
> src/java.base/share/classes/java/lang/System.java line 2086:
>
>>
On Fri, 6 Nov 2020 22:02:31 GMT, Coleen Phillimore wrote:
>> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 81:
>>
>>> 79: #endif
>>> 80:
>>> 81: Method* method = k->lookup_method(mname_sym, mdesc_sym);
>>
>> This "method" appears unused.
>
> This should be moved into
On Mon, 9 Nov 2020 12:11:56 GMT, Jorn Vernee wrote:
>> I agree with Coleen.
>
> I'll give this another try, but I think last time I tried this resolution of
> the class failed when trying to build the JDK, seemingly since it exists in
> an incubator module, which i
On Fri, 6 Nov 2020 22:07:39 GMT, Coleen Phillimore wrote:
>> Maurizio Cimadamore has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 64 commits:
>>
>> - Merge branch '8254162' into 8254231_linker
>> - Fix post-merge issues caused
Hi David,
On 09/11/2020 14:51, David Holmes wrote:
Hi Jorn,
On 9/11/2020 9:57 pm, Jorn Vernee wrote:
On Mon, 9 Nov 2020 03:29:05 GMT, David Holmes
wrote:
src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 99:
97: if (thread == NULL) {
98: JavaVM_ *vm = (JavaVM *)(_vm
On Mon, 9 Nov 2020 03:31:15 GMT, David Holmes wrote:
>> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 55:
>>
>>> 53:
>>> 54: // FIXME: This should be initialized explicitly instead of lazily/racily
>>> 55: static void upcall_init() {
>>
>> The FIXME is right this should be
On Mon, 9 Nov 2020 03:29:05 GMT, David Holmes wrote:
>> Maurizio Cimadamore has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 64 commits:
>>
>> - Merge branch '8254162' into 8254231_linker
>> - Fix post-merge issues caused by
On Mon, 9 Nov 2020 06:07:32 GMT, Nick Gasson wrote:
>> Maurizio Cimadamore has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 64 commits:
>>
>> - Merge branch '8254162' into 8254231_linker
>> - Fix post-merge issues caused by
at the location where the VarHandle is
> being used.
>
> Thanks,
> Jorn
>
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375
Jorn Vernee has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated cha
On Fri, 30 Oct 2020 15:23:28 GMT, Paul Sandoz wrote:
>> Jorn Vernee 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 12 addi
On Thu, 5 Nov 2020 15:42:54 GMT, Roland Westrelin wrote:
>> src/java.base/share/classes/java/lang/IndexOutOfBoundsException.java line 83:
>>
>>> 81: */
>>> 82: public IndexOutOfBoundsException(long index) {
>>> 83: super("Index out of range: " + index);
>>
>> For consistency
On Mon, 2 Nov 2020 10:47:18 GMT, Roland Westrelin wrote:
> This change add 3 new methods in Objects:
>
> public static long checkIndex(long index, long length)
> public static long checkFromToIndex(long fromIndex, long toIndex, long length)
> public static long checkFromIndexSize(long
On Mon, 26 Oct 2020 15:18:08 GMT, Jorn Vernee wrote:
> Hi,
>
> This patch adds a `dropReturn` combinator to `MethodHandles` that can be used
> to create a new method handle that drops the return value, from a given
> method handle. Similar to the following code:
>
>
at the location where the VarHandle is
> being used.
>
> Thanks,
> Jorn
>
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
s/an arity/and arity
On Fri, 30 Oct 2020 12:47:59 GMT, Jorn Vernee wrote:
> Guard libJNIPoint.c impl in `#ifdef _LP64` block
>
> This fixes a 32-bit build error
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.net/jdk/pull/956
at the location where the VarHandle is
> being used.
>
> Thanks,
> Jorn
>
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
behaviour ->
at the location where the VarHandle is
> being used.
>
> Thanks,
> Jorn
>
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
- behaviour -> behaviour
On Tue, 27 Oct 2020 10:40:40 GMT, Jorn Vernee wrote:
>>> …`dropReturn` seemed like a good choice since we already have
>>> `dropArguments`. WRT changing to `MethodHandle::changeReturnType`...
>>
>> That's a very reasonable point. People might look for `dropR
Guard libJNIPoint.c impl in `#ifdef _LP64` block
This fixes a 32-bit build error
-
Commit messages:
- Guard libJNIPoint.c impl in #ifdef _LP64 block
Changes: https://git.openjdk.java.net/jdk/pull/956/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=956=00
Issue:
On Tue, 27 Oct 2020 12:43:47 GMT, Jorn Vernee wrote:
> Hi,
>
> Currently, if MethodHandles::permuteArguments is used with a reorder array
> that is the wrong size, or one of the indexes in it is out of bounds of the
> new type, we simply get the exception message:
>
>
at the location where the VarHandle is
> being used.
>
> Thanks,
> Jorn
>
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375
Jorn Vernee has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated cha
On Tue, 27 Oct 2020 15:01:31 GMT, Jorn Vernee wrote:
>> I've updated the implementation of accessModeType to work with the ordinal
>> directly. Note that it was using the AccessType ordinal though, so I also
>> had to change the parameter type of accessModeTypeUncached, and
essage into e.g.:
>
> old type parameter count and reorder array length do not match:
> (int,int,String)int, [0, 0]
>
> For an incorrect reorder array length, and:
>
> index is out of bounds for new type: 2, (int,String)int
>
> For an out of bounds index.
>
On Wed, 28 Oct 2020 11:52:17 GMT, Jorn Vernee wrote:
>> Seems like a reasonable change. Is there an already existing test for "bad"
>> permute args that could be expanded to discern the new exception message?
>
>>
>>
>> Seems like a reasonabl
essage into e.g.:
>
> old type parameter count and reorder array length do not match:
> (int,int,String)int, [0, 0]
>
> For an incorrect reorder array length, and:
>
> index is out of bounds for new type: 2, (int,String)int
>
> For an out of bounds index.
>
On Wed, 28 Oct 2020 09:20:54 GMT, Aleksey Shipilev wrote:
>
>
> This looks okay to me. Someone from core-libs should take a look as well.
>
> As the follow-up, maybe reconcile that method returns normally only with
> `true`, and throws exceptions otherwise. There are some uses like
>
On Wed, 28 Oct 2020 10:19:58 GMT, Chris Hegarty wrote:
>
>
> Seems like a reasonable change. Is there an already existing test for "bad"
> permute args that could be expanded to discern the new exception message?
There are several tests for permuteArguments, but none that explicitly test
On Mon, 26 Oct 2020 18:54:45 GMT, Jorn Vernee wrote:
>> Paul,
>> an invoker has the MethodHandle (resp. VarHandle) as first argument so it's
>> not the same semantics.
>
> I've updated the implementation of accessModeType to work with the ordinal
> direc
Hi,
Currently, if MethodHandles::permuteArguments is used with a reorder array that
is the wrong size, or one of the indexes in it is out of bounds of the new
type, we simply get the exception message:
bad reorder array [...]
I think we can improve the exception message by splitting these
On Mon, 26 Oct 2020 18:33:11 GMT, Rémi Forax
wrote:
>>> …`dropReturn` seemed like a good choice since we already have
>>> `dropArguments`. WRT changing to `MethodHandle::changeReturnType`...
>>
>> That's a very reasonable point. People might look for `dropRT` after they
>> find `dropAs`.
at the location where the VarHandle is
> being used.
>
> Thanks,
> Jorn
>
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
Use AccessType ordinal in guar
at the location where the VarHandle is
> being used.
>
> Thanks,
> Jorn
>
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
Update accessModeType to use
On Mon, 26 Oct 2020 17:13:05 GMT, Rémi Forax
wrote:
>> We can clarify the new methods and tie them closer to method handle
>> semantics. I suggest the names `asExactInvoker` and `asInvoker`, referencing
>> `MethodHandles.exactInvoker` and `MethodHandles.invoker` respectively. (The
>> term
On Mon, 26 Oct 2020 17:16:17 GMT, John R Rose wrote:
>> LGTM, pending CSR.
>>
>> A minor simplification suggested inline.
>
> I don't mind shorthands, but the existing idiom is shorter than advertised,
> a one-liner assuming the MH is already bound to a var:
>
> target =
target.type().returnType();
> if (targetReturnType != void.class)
> target = filterReturnValue(target, empty(methodType(void.class,
> targetReturnType)));
> // use target
>
> But as a short-hand.
>
> Thanks,
> Jorn
Jorn Vernee has updated the pull request incre
target.type().returnType();
> if (targetReturnType != void.class)
> target = filterReturnValue(target, empty(methodType(void.class,
> targetReturnType)));
> // use target
>
> But as a short-hand.
>
> Thanks,
> Jorn
Jorn Vernee has updated the pull request incre
Hi,
This patch adds a `dropReturn` combinator to `MethodHandles` that can be used
to create a new method handle that drops the return value, from a given method
handle. Similar to the following code:
MethodHandle target = ...;
Class targetReturnType = target.type().returnType();
if
On Fri, 23 Oct 2020 23:58:29 GMT, Jorn Vernee wrote:
>> @PaulSandoz Thanks. I initially tested this with memory access VarHandles,
>> which don't erase the receiver type. e.g.
>>
>> MemoryLayout layout = MemoryLayout.ofSequence(10, JAVA_INT);
>> VarHandle v
at the location where the VarHandle is
> being used.
>
> Thanks,
> Jorn
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
Add benchmarks
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/843/files
- n
at the location where the VarHandle is
> being used.
>
> Thanks,
> Jorn
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
- Update javadoc
- Make isExact() public
-
Changes:
- all: https://git.openjdk.java.
at the location where the VarHandle is
> being used.
>
> Thanks,
> Jorn
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
Fixes failing tests, and enable verifier on Exact test
-
Changes:
- all: ht
On Fri, 23 Oct 2020 21:38:16 GMT, Jorn Vernee wrote:
>> This approach does not work for reference types, since they are erased to
>> `Object`, and then exact checking will be performed on the erased reference
>> types.
>>
>> For example try this:
>>
>
at the location where the VarHandle is
> being used.
>
> Thanks,
> Jorn
Jorn Vernee has updated the pull request incrementally with three additional
commits since the last revision:
- Fix whitespace
- Comment out VarHandleGuards generator code
- Makes exactness a property of a
On Fri, 23 Oct 2020 20:41:31 GMT, Paul Sandoz wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make internalName helper method static
>
> This approach does not work for referenc
On Fri, 23 Oct 2020 18:02:11 GMT, Rémi Forax
wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make internalName helper method static
>
> src/java.base/
> This is implemented using a boolean flag in VarForm. If the flag is set, the
> exact type of the invocation is checked against the exact type in the
> VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
>
> Thanks,
> Jorn
Jorn Vernee has updated the pull re
Hi,
This patch adds an asExact() combinator to VarHandle, that will return a new
VarHandle that performs exact type checks, similar to
MethodHandle::invokeExact, to help developers catch inexact VarHandle usage,
which can lead to performance degradation.
This is implemented using a boolean
On Thu, 22 Oct 2020 16:31:00 GMT, Maurizio Cimadamore
wrote:
>> Some of this is familiar to me from reviews in the `panama-foreign`
>> repository, but less so than the memory API. I focused on the Java code, and
>> ignored changes that are common with the memory API PR.
>>
>> If it helps in
On Tue, 20 Oct 2020 21:53:55 GMT, Paul Sandoz wrote:
>> Maurizio Cimadamore has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 25 commits:
>>
>> - Merge branch 'master' into 8254231_linker
>> - Fix incorrect capitalization in one
On Tue, 20 Oct 2020 21:08:26 GMT, Paul Sandoz wrote:
>> Maurizio Cimadamore has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 25 commits:
>>
>> - Merge branch 'master' into 8254231_linker
>> - Fix incorrect capitalization in one
On Mon, 19 Oct 2020 11:24:45 GMT, Jorn Vernee wrote:
>> I looked through some Hotspot runtime code and that looks ok. I saw a
>> couple of strange things on my way through the code. See comments.
>
> Hi David, this code somewhat predates me, so I initially kept the
On Mon, 19 Oct 2020 18:08:28 GMT, Stuart Marks wrote:
> This is a fix for "just a typo" or copy/paste error, but it probably requires
> a CSR since it changes a normative
> portion of the spec.
Looks good, though I'm not a Reviewer™, I'm the one who introduced this code.
It is indeed a typo.
On Fri, 16 Oct 2020 11:12:01 GMT, Jorn Vernee wrote:
>> src/hotspot/cpu/x86/foreign_globals_x86.cpp line 56:
>>
>>> 54: }
>>> 55:
>>> 56: const ABIDescriptor parseABIDescriptor(JNIEnv* env, jobject jabi) {
>>
>> I don't know if you care about
On Thu, 15 Oct 2020 23:15:07 GMT, Coleen Phillimore wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Re-add file erroneously deleted (detected as rename)
>
> I looked through some Hotspot runtime code and
On Thu, 15 Oct 2020 22:42:49 GMT, Coleen Phillimore wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Re-add file erroneously deleted (detected as rename)
>
> src/hotspot/cpu/x86/foreign_globals_x86.cpp line
On Thu, 15 Oct 2020 22:52:14 GMT, Coleen Phillimore wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Re-add file erroneously deleted (detected as rename)
>
> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line
On Thu, 15 Oct 2020 22:44:54 GMT, Coleen Phillimore wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Re-add file erroneously deleted (detected as rename)
>
> src/hotspot/cpu/x86/foreign_globals_x86.hpp line
On Thu, 15 Oct 2020 22:39:50 GMT, Coleen Phillimore wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Re-add file erroneously deleted (detected as rename)
>
> src/hotspot/cpu/x86/foreign_globals_x86.cpp line
hich contains only the differences between this PR
> and the memory access PR. I will be
> periodically uploading new webrevs, as new iterations come out, to try and
> make the life of reviewers as simple as
> possible. A big thank to Jorn Vernee and Vladimir Ivanov - they are the main
On Thu, 10 Sep 2020 15:50:39 GMT, Alan Bateman wrote:
>> 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to
>> post, but even if you are a reply-all will
>> be delayed due to all of the mails being held up for moderator approval due
>> to:
>> " Too many recipients to
.04/
Thanks,
Jorn
On 18/03/2020 15:08, Jorn Vernee wrote:
Hi,
Can someone please sponsor this patch that makes Boolean, Character,
Byte, and Short implement Constable?
Bug: https://bugs.openjdk.java.net/browse/JDK-8241100
Webrev: http://cr.openjdk.java.net/~jvernee/8241100/webrev.00/
Having
Hi,
I think the problem with perf might be caused by the fact that while the
array is now a constant, the elements are not (the array is mutable
after all). For fields you can fix this by using @Stable, but not for CP
entries :)
I think what could work is; rather than ldc'ing the array, and
Thanks, Paul and John, for the CSR reviews.
Please find the latest version of the patch here:
http://cr.openjdk.java.net/~jvernee/8241100/webrev.04/index.html
Jorn
On 14/04/2020 18:18, Jorn Vernee wrote:
Hi David,
Thanks for the heads up! A CSR for this patch was created here:
https
Holmes wrote:
Hi Jorn,
This needs a CSR request before it can be pushed.
Thanks,
David
On 19/03/2020 12:08 am, Jorn Vernee wrote:
Hi,
Can someone please sponsor this patch that makes Boolean, Character,
Byte, and Short implement Constable?
Bug: https://bugs.openjdk.java.net/browse/JDK-8241100
, Jorn Vernee wrote:
W.r.t. the source type being needed, I see the following 4 major cases:
1. src=Prim & dst=Prim -> cast convert. For boolean the least-significant-bit
is used to convert it to/from an integer type.
2. src=Prim & dst=Ref -> box the source value and potentially c
W.r.t. the source type being needed, I see the following 4 major cases:
1. src=Prim & dst=Prim -> cast convert. For boolean the
least-significant-bit is used to convert it to/from an integer type.
2. src=Prim & dst=Ref -> box the source value and potentially cast
3. src=Ref & dst=Prim ->
Hi,
Can someone please sponsor this patch that makes Boolean, Character,
Byte, and Short implement Constable?
Bug: https://bugs.openjdk.java.net/browse/JDK-8241100
Webrev: http://cr.openjdk.java.net/~jvernee/8241100/webrev.00/
Having the other box types implement Constable makes them easier
> * drop offset() - but then add an overload of MemorySegment::asSlice
which takes an address instead of a plain long offset
This sounds good to me, since it fits with what we're doing with
makeUncheckedSegment(MemoryAddress, length), and we added the offset()
accessor to support slicing. I
able, like javac
does, instead of doing the double SWAP if there is a return value
of size 1 ?
Rémi
- Mail original -----
De: "Jorn Vernee"
À: "Claes Redestad" , "core-libs-dev"
Envoyé: Mardi 12 Novembre 2019 15:56:06
Objet: Re: RFR 8233920: MethodHandles
tore in a local variable, like javac
does, instead of doing the double SWAP if there is a return value of
size 1 ?
Rémi
- Mail original -
De: "Jorn Vernee"
À: "Claes Redestad" , "core-libs-dev"
Envoyé: Mardi 12 Novembre 2019 15:56:06
Objet: Re: RFR
ed exception to the
exact type being thrown (T1?) rather than Throwable?
I can sponsor the patch.
/Claes
On 2019-11-12 12:09, Jorn Vernee wrote:
Hi,
Please review the following patch that fixes handling of long/double
returns for the tryFinally MethodHandle combinator.
Bug: https://bugs.openj
Hi,
Please review the following patch that fixes handling of long/double
returns for the tryFinally MethodHandle combinator.
Bug: https://bugs.openjdk.java.net/browse/JDK-8233920
Webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.01/
(Testing=tier1)
FWIW, I also added some missing
301 - 384 of 384 matches
Mail list logo
