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
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
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
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
> * 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
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
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
.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
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
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
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 ->
, 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
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
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, 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: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: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
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 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 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.
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 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
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
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 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
>
> 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
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
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 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 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
>
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 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`.
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
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:
Add benchmarks
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/843/files
- n
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
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
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 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
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
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
d.
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8257187
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
Address review comments:
- remove explicit @throws NPE tags
- add example to class doc
-
Changes:
- all: https://git.o
On Fri, 27 Nov 2020 10:48:31 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review comments:
>> - remove explicit @throws NPE tags
>> - add
On Thu, 26 Nov 2020 18:29:42 GMT, Maurizio Cimadamore
wrote:
> There is a subtle bug in the heap segment factories: the byte size is
> computed using an int multiplication instead of a long multiplication.
> Because of that, it is possible to observe overflow when creating segments
> out of
d.
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8257187
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
Update
src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java
Co-authored-by: Maurizio Cimada
` blocks.
>
> Testing: `make images` on Linux and Windows x86_32 platforms.
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
Pass in thread instead of rematerializing it.
-
Changes:
- all: https://git.openjdk.java.n
` blocks.
>
> Testing: `make images` on Linux and Windows x86_32 platforms.
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
Split out 32-bit impl from native invoker and upcall handler
-
Changes:
- all:
On Wed, 25 Nov 2020 12:41:40 GMT, Chris Hegarty wrote:
> The ByteBuffers micro benchmark seems to be a little dated.
>
> It should be a useful resource to leverage when analysing the performance
> impact of any potential implementation changes in the byte buffer classes.
> More specifically,
On Wed, 25 Nov 2020 00:01:47 GMT, David Holmes 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 10 addi
On Wed, 25 Nov 2020 12:16:01 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Pass in thread instead of rematerializing it.
>
> src/hotspot/cpu/x86/universa
On Tue, 24 Nov 2020 06:12:55 GMT, David Holmes wrote:
>> src/hotspot/share/prims/universalUpcallHandler.cpp line 36:
>>
>>> 34: extern struct JavaVM_ main_vm;
>>> 35:
>>> 36: JNI_ENTRY_CPP_NOENV(void,
>>> ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff))
>>
>> I do not
` blocks.
>
> Testing: `make images` on Linux and Windows x86_32 platforms.
Jorn Vernee has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 13 commits:
- Merge branch 'master' into Linker_32bit-fixes_New-Master
- Split out 32-b
On Tue, 17 Nov 2020 17:19:13 GMT, Jorn Vernee wrote:
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using
This patch fixes several failures on x86_32 of java/foreign tests.
This is mostly done by disabling the failing tests, but the impl of CLinker is
also adjusted ton properly detect 32 bit platforms as unsupported.
CLinker is specified to fail in the initializer on unsupported platforms, and a
dk.java.net/browse/JDK-8256757 is filed for the remaining
> failure in TestStringLatin1IndexOfChar.
>
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8256863
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
Exclude Te
On Mon, 23 Nov 2020 14:54:21 GMT, Jorn Vernee wrote:
> This patch fixes several failures on x86_32 of java/foreign tests.
>
> This is mostly done by disabling the failing tests, but the impl of CLinker
> is also adjusted ton properly detect 32 bit platforms as unsupported.
On Thu, 26 Nov 2020 19:24:16 GMT, Jorn Vernee wrote:
> This upstreams the patch from:
> https://github.com/openjdk/panama-foreign/pull/396
>
> There were only some minor merge conflicts due to imports and some tests
> being replaced by java/foreign/TestNulls. All tests still
On Mon, 7 Dec 2020 17:38:40 GMT, Maurizio Cimadamore
wrote:
> This simple patch updates the jaavdoc in the module-info file of
> jdk.incubator.foreign to reflect the fact that support of foreign function
> calls has been added.
Marked as reviewed by jvernee (Committer).
-
PR:
JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the
needed changes to get it working again.
Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro.
Using just JNI_ENTRY was causing a linkage failure, due to the declaration of
the function in
` blocks.
>
> Testing: `make images` on Linux and Windows x86_32 platforms.
Jorn Vernee has updated the pull request incrementally with two additional
commits since the last revision:
- Remove JNI_ENTRY_CPP_NOENV
- - Move reset_last_Java_frame
-
Changes:
- all:
/11/2020 13:35, David Holmes wrote:
On 24/11/2020 9:38 pm, Jorn Vernee wrote:
On Tue, 24 Nov 2020 06:12:55 GMT, David Holmes
wrote:
src/hotspot/share/prims/universalUpcallHandler.cpp line 36:
34: extern struct JavaVM_ main_vm;
35:
36: JNI_ENTRY_CPP_NOENV(void,
ProgrammableUpcallHandler
` blocks.
>
> Testing: `make images` on Linux and Windows x86_32 platforms.
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 10 addit
On Tue, 24 Nov 2020 13:31:17 GMT, Aleksey Shipilev wrote:
>> Jorn Vernee has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Remove JNI_ENTRY_CPP_NOENV
>> - - Move reset_last_Java_frame
>
> This
On Tue, 17 Nov 2020 17:19:13 GMT, Jorn Vernee wrote:
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using
On Mon, 23 Nov 2020 19:25:31 GMT, Aleksey Shipilev 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 contain
` blocks.
>
> Testing: `make images` on Linux and Windows x86_32 platforms.
Jorn Vernee 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. The pull request contains
` blocks.
>
> Testing: `make images` on Linux and Windows x86_32 platforms.
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
Use the Unimplemented() macro instead of hlt()
-
Changes:
- all: https://git.openjdk.ja
On Mon, 23 Nov 2020 13:19:23 GMT, Aleksey Shipilev wrote:
>> Jorn Vernee 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.
>
` blocks.
>
> Testing: `make images` on Linux and Windows x86_32 platforms.
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 seven addit
On Mon, 23 Nov 2020 15:11:49 GMT, Maurizio Cimadamore
wrote:
> Both the Foreign Memory Access and the Foreign Linker APIs leave something to
> be desired when it comes to handling NPEs - first, most of the API javadoc is
> oblivious to NPEs being thrown. Secondly, not all API method
On Thu, 10 Dec 2020 09:15:47 GMT, Nick Gasson wrote:
>> This is more-or-less a straight port of the x86 code to AArch64.
>> GraphKit::make_native_call() calls SharedRuntime::make_native_invoker()
>> to generate a blob that jumps to the native function entry point. This
>> simply switches the
On Thu, 10 Dec 2020 09:46:07 GMT, Chris Hegarty wrote:
>> Marked as reviewed by bpb (Reviewer).
>
> While the updated set of scenarios covered by this benchmark is
> reasonably (and vastly improves coverage), I find myself reluctant to
> add the last remaining buffer property - read-only views.
On Tue, 24 Nov 2020 23:59:11 GMT, David Holmes 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 10 addi
This upstreams the patch from:
https://github.com/openjdk/panama-foreign/pull/396
There were only some minor merge conflicts due to imports and some tests being
replaced by java/foreign/TestNulls. All tests still pass, no other changes were
needed.
-
Commit messages:
- Add a
On Wed, 2 Dec 2020 18:47:10 GMT, Maurizio Cimadamore
wrote:
> The accessor methods in the `MemoryAccess` class are missing `@ForceInline`
> annotations. This causes odd behavior on certain benchmarks, especially if
> these methods are called many times in the body of a single method.
Marked
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
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
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,
&
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 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 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
>>
(Continuing this thread from relevant discussion on [1])
Discussing the following RFE:
https://bugs.openjdk.java.net/browse/JDK-8256341
Also (as mentioned offline), while it's possible with the current API
to provide an `Object[]` as class data, and then load elements of
that array into CP
On Sat, 14 Nov 2020 07:55:35 GMT, Hui Shi wrote:
>> Notice that the `/test` command is currently un-available (some
>> implementation concerns are still under consideration). As an alternative,
>> GitHub actions can be used to do basic automatic testing when pushes occur.
>>
>> However,
On Fri, 13 Nov 2020 18:42:53 GMT, Mandy Chung wrote:
> > Also (as mentioned offline), while it's possible with the current API to
> > provide an `Object[]` as class data, and then load elements of that array
> > into CP entries using downstream condys (e.g. by creating an array access
> > var
On Fri, 13 Nov 2020 19:23:54 GMT, Jorn Vernee wrote:
>>> Also (as mentioned offline), while it's possible with the current API to
>>> provide an `Object[]` as class data, and then load elements of that array
>>> into CP entries using downstream condys (e.g. by creati
On Fri, 13 Nov 2020 23:56:21 GMT, Hui Shi wrote:
>> …ructorAccessorImpl object
>>
>> duplicate with https://github.com/openjdk/jdk/pull/1070, try trigger test
>> with new PR
>
> @JornVernee
> Could you please help approve and start tier1 test?
> This is same PR with
On Fri, 20 Nov 2020 20:23:27 GMT, Mandy Chung wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2148:
>>
>>> 2146: * (unlike private static fields that are accessible to
>>> nestmates).
>>> 2147: * Care should be taken w.r.t. mutability for
On Tue, 17 Nov 2020 18:32:30 GMT, Jorn Vernee wrote:
> This PR sharpens the testing done by
> test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java after
> @mcimadamore reported that the test was not catching an issue with memory
> access var handles; namely that the im
On Wed, 18 Nov 2020 00:50:22 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 Tue, 17 Nov 2020 08:33:20 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 Tue, 17 Nov 2020 14:55:07 GMT, Maurizio Cimadamore
wrote:
> The current memory segment implementation defines a hierarchy with 3 concrete
> classes: one for heap segments, one for native segments and one for mapped
> segments.
>
> Since there can be many kinds of heap segments (e.g.
1 - 100 of 384 matches
Mail list logo
