Re: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v4]

2021-05-21 Thread Jorn Vernee
On Fri, 21 May 2021 08:53:51 GMT, Gavin Bierman wrote: >> Hi all, >> >> Please review this patch to make the ConstantDesc hierarchy `sealed`, as was >> promised in its Javadoc, now that sealed classes are finalising in JDK 17. >> >> Thanks, >> Gavin > > Gavin Bierman has updated the pull

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v24]

2021-05-20 Thread Jorn Vernee
On Thu, 20 May 2021 13:00:14 GMT, Maurizio Cimadamore wrote: >> Maurizio Cimadamore 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 35 >>

Re: RFR: 8266310: deadlock while loading the JNI code [v3]

2021-05-19 Thread Jorn Vernee
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 >>

Re: RFR: 8266835: Add a --validate option to the jar tool [v2]

2021-05-19 Thread Jorn Vernee
s://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077420.html > > Testing: running jdk/tools/jar test suite locally, tier 1-3 (in progress), > manual testing. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

Re: RFR: 8267321: Use switch expression for VarHandle$AccessMode lookup

2021-05-19 Thread Jorn Vernee
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. > >

Re: RFR: 8266835: Add a --validate option to the jar tool

2021-05-19 Thread Jorn Vernee
On Tue, 11 May 2021 10:51:18 GMT, Jorn Vernee wrote: > 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 differen

RFR: 8266835: Add a --validate option to the jar tool

2021-05-19 Thread Jorn Vernee
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

Re: RFC: Add a --validate option to the jar tool

2021-05-18 Thread Jorn Vernee
I'll go ahead with this enhancement, and make sure the wording is open to adding validation logic not related to multi-release jars in the future. Jorn On 12/05/2021 14:47, Jorn Vernee wrote: On 12/05/2021 14:41, Alan Bateman wrote: On 12/05/2021 11:58, Jorn Vernee wrote: Hi, I see

Re: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles [v2]

2021-05-17 Thread Jorn Vernee
On Fri, 14 May 2021 07:27:08 GMT, Claes Redestad 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 conta

Re: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles [v2]

2021-05-17 Thread Jorn Vernee
150 > true avgt 30 4.676 � 0.011 ms/op > MethodHandlesTableSwitchRandom.testSwitch 100 150 > false avgt 30 13.476 � 0.043 ms/op > > > Testing: > - [x] Running of included benchmarks > - [x] Inspecting inlining trace and verifying

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v16]

2021-05-12 Thread Jorn Vernee
On Wed, 12 May 2021 14:06:46 GMT, Vladimir Ivanov wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> * Remove unused imports >> * Fix broken javadoc after removal of @throws clauses >> * Remove other

Re: RFC: Add a --validate option to the jar tool

2021-05-12 Thread Jorn Vernee
On 12/05/2021 14:41, Alan Bateman wrote: On 12/05/2021 11:58, Jorn Vernee wrote: Hi, I see that the jar tool has validation logic for multi-release jars that is triggered when creating or updating a jar that has a versioned file as an input. I wanted to ask what people think about the idea

Re: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles

2021-05-12 Thread Jorn Vernee
On Thu, 8 Apr 2021 18:51:21 GMT, Jorn Vernee wrote: > This patch adds a `tableSwitch` combinator that can be used to switch over a > set of method handles given an index, with a fallback in case the index is > out of bounds, much like the `tableswitch` bytecode. Here is a description

RFC: Add a --validate option to the jar tool

2021-05-12 Thread Jorn Vernee
Hi, I see that the jar tool has validation logic for multi-release jars that is triggered when creating or updating a jar that has a versioned file as an input. I wanted to ask what people think about the idea of exposing this validation logic directly under a --validate command line flag as

Re: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native

2021-05-03 Thread Jorn Vernee
On Mon, 26 Apr 2021 14:30:17 GMT, Maurizio Cimadamore wrote: >> macOS on Apple silicon uses slightly different ABI conventions to the >> standard AArch64 ABI. The differences are outlined in [1]. In >> particular in the standard (AAPCS) ABI, variadic arguments may be passed >> in either

Re: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native

2021-05-03 Thread Jorn Vernee
On Mon, 3 May 2021 15:31:53 GMT, Jorn Vernee wrote: >> macOS on Apple silicon uses slightly different ABI conventions to the >> standard AArch64 ABI. The differences are outlined in [1]. In >> particular in the standard (AAPCS) ABI, variadic arguments may be passed >

Re: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native

2021-05-03 Thread Jorn Vernee
On Thu, 22 Apr 2021 08:19:53 GMT, Nick Gasson wrote: > macOS on Apple silicon uses slightly different ABI conventions to the > standard AArch64 ABI. The differences are outlined in [1]. In > particular in the standard (AAPCS) ABI, variadic arguments may be passed > in either registers or on

Re: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native

2021-05-03 Thread Jorn Vernee
On Tue, 27 Apr 2021 02:14:07 GMT, Nick Gasson wrote: >> How about StandardAArch64Linker? Otherwise MacOsAArch64Linker sounds like it >> should be a specialisation of AArch64Linker. > > Or LinuxAArch64Linker if we're going to rename the CABI enum AArch64 -> > LinuxAArch64? But this would also

Re: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native

2021-04-26 Thread Jorn Vernee
On Thu, 22 Apr 2021 08:19:53 GMT, Nick Gasson wrote: > macOS on Apple silicon uses slightly different ABI conventions to the > standard AArch64 ABI. The differences are outlined in [1]. In > particular in the standard (AAPCS) ABI, variadic arguments may be passed > in either registers or on

Integrated: 8265079: Implement VarHandle invoker caching

2021-04-19 Thread Jorn Vernee
On Mon, 12 Apr 2021 16:24:37 GMT, Jorn Vernee wrote: > This patch implements 2 leftover TODOs for implementing var handle invoker MH > caching (lambda forms for those were already shared/cached). > > This piggybacks on the existing mechanism for method handle invoker caching.

Re: RFR: 8265079: Implement VarHandle invoker caching [v3]

2021-04-19 Thread Jorn Vernee
On Wed, 14 Apr 2021 22:57:59 GMT, Mandy Chung wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Review comment: simplify test > > test/jdk/java/lang/invoke/TestVHInvokerCaching.java lin

Re: RFR: 8265079: Implement VarHandle invoker caching [v4]

2021-04-19 Thread Jorn Vernee
e` tests. Tier 1-3 > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Remove manual -ea -esa test flags - Changes: - all: https://git.openjdk.java.net/jdk/pull/3439/files - new: https://git.openjdk.j

Re: RFR: 8265079: Implement VarHandle invoker caching [v2]

2021-04-14 Thread Jorn Vernee
On Tue, 13 Apr 2021 15:24:13 GMT, Paul Sandoz wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Review comments: >> - Use boolean instead of index for var handle cache

Re: RFR: 8265079: Implement VarHandle invoker caching [v3]

2021-04-14 Thread Jorn Vernee
e` tests. Tier 1-3 > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Review comment: simplify test - Changes: - all: https://git.openjdk.java.net/jdk/pull/3439/files - new: https://git.openjdk.j

Re: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles

2021-04-13 Thread Jorn Vernee
On Tue, 13 Apr 2021 22:00:57 GMT, Remi Forax wrote: > About your benchmark, did you test with some strings going into "default", > because it is usually in that case that you need a proper lookup switch, another way to say it is that, your results are too good when you use a cascade of

Re: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles

2021-04-13 Thread Jorn Vernee
On Tue, 13 Apr 2021 22:00:57 GMT, Remi Forax wrote: > About your benchmark, did you test with some strings going into "default", > because it is usually in that case that you need a proper lookup switch, another way to say it is that, your results are too good when you use a cascade of

Re: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles

2021-04-13 Thread Jorn Vernee
On Thu, 8 Apr 2021 18:51:21 GMT, Jorn Vernee wrote: > This patch adds a `tableSwitch` combinator that can be used to switch over a > set of method handles given an index, with a fallback in case the index is > out of bounds, much like the `tableswitch` bytecode. Here is a description

Re: RFR: 8265079: Implement VarHandle invoker caching

2021-04-13 Thread Jorn Vernee
On Mon, 12 Apr 2021 16:24:37 GMT, Jorn Vernee wrote: > This patch implements 2 leftover TODOs for implementing var handle invoker MH > caching (lambda forms for those were already shared/cached). > > This piggybacks on the existing mechanism for method handle invoker caching.

Re: RFR: 8265079: Implement VarHandle invoker caching [v2]

2021-04-13 Thread Jorn Vernee
e` tests. Tier 1-3 > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Review comments: - Use boolean instead of index for var handle cache - Changes: - all: https://git.openjdk.java.net/jdk/pul

RFR: 8265079: Implement VarHandle invoker caching

2021-04-13 Thread Jorn Vernee
This patch implements 2 leftover TODOs for implementing var handle invoker MH caching (lambda forms for those were already shared/cached). This piggybacks on the existing mechanism for method handle invoker caching. Testing: Local testing `java/lang/invoke` tests. Tier 1-3 Thanks, Jorn

Re: RFR: 8265061: Simplify MethodHandleNatives::canBeCalledVirtual

2021-04-12 Thread Jorn Vernee
On Mon, 12 Apr 2021 10:45:20 GMT, Claes Redestad wrote: > Desugaring the single-case switch in MethodHandleNatives::canBeCalledVirtual > is a cleanup and minimal startup improvement on apps spinning up > MethodHandles. Marked as reviewed by jvernee (Committer). - PR:

Re: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles

2021-04-09 Thread Jorn Vernee
On Fri, 9 Apr 2021 18:27:07 GMT, Jorn Vernee wrote: >> This patch adds a `tableSwitch` combinator that can be used to switch over a >> set of method handles given an index, with a fallback in case the index is >> out of bounds, much like the `tableswitch` bytecode. Her

Re: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles

2021-04-09 Thread Jorn Vernee
On Thu, 8 Apr 2021 18:51:21 GMT, Jorn Vernee wrote: > This patch adds a `tableSwitch` combinator that can be used to switch over a > set of method handles given an index, with a fallback in case the index is > out of bounds, much like the `tableswitch` bytecode. Here is a description

Re: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles

2021-04-09 Thread Jorn Vernee
On 09/04/2021 18:54, Remi Forax wrote: - Mail original - De: "Jorn Vernee" À: "core-libs-dev" Envoyé: Vendredi 9 Avril 2021 12:51:53 Objet: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles This patch adds a `tableSwitch`

RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles

2021-04-09 Thread Jorn Vernee
This patch adds a `tableSwitch` combinator that can be used to switch over a set of method handles given an index, with a fallback in case the index is out of bounds, much like the `tableswitch` bytecode. The combinator does not support specifying the starting index, so the switch cases always

Integrated: 8264288: Performance issue with MethodHandle.asCollector

2021-04-05 Thread Jorn Vernee
On Thu, 1 Apr 2021 13:25:05 GMT, Jorn Vernee wrote: > This patch speeds up MethodHandle.asCollector handles where the array type is > not Object[], as well as speeding up all collectors where the arity is > greater than 10. > > The old code is creating a collector handle by

Re: RFR: 8264288: Performance issue with MethodHandle.asCollector [v4]

2021-04-05 Thread Jorn Vernee
On Mon, 5 Apr 2021 15:39:39 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Review comment: Rearrange code to explicitly reference erased setter > > Looks good.

Re: RFR: 8264288: Performance issue with MethodHandle.asCollector [v3]

2021-04-05 Thread Jorn Vernee
On Mon, 5 Apr 2021 12:48:07 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> - Revert back to injected constructor handle >> - Add lambda form sharing >&

Re: RFR: 8264288: Performance issue with MethodHandle.asCollector [v4]

2021-04-05 Thread Jorn Vernee
or.testObjectCollect avgt 30 6.813 � 0.035 ns/op > TypedAsCollector.testObjectCollectHighArity avgt 30 9.718 � 0.066 ns/op > TypedAsCollector.testStringCollect avgt 30 6.737 � 0.016 ns/op > TypedAsCollector.testStringCollectHighArity avgt 30 9.618 �

Re: RFR: 8264288: Performance issue with MethodHandle.asCollector [v3]

2021-04-05 Thread Jorn Vernee
On Fri, 2 Apr 2021 13:23:07 GMT, Jorn Vernee wrote: >> That's an elegant solution. >> >> At first i thought it might unduly perturb lambda form generation and >> caching. but you slotted a different lambda form implementation underneath >> the varargs implementat

Re: RFR: 8264288: Performance issue with MethodHandle.asCollector [v2]

2021-04-05 Thread Jorn Vernee
On Fri, 2 Apr 2021 15:12:04 GMT, Vladimir Ivanov wrote: >> That's what I thought as well (but not 100% sure). I can partially roll back >> the last commit so the code still uses an injected array constructor handle, >> and then it should be easy to add caching in the cases where the component

Re: RFR: 8264288: Performance issue with MethodHandle.asCollector [v3]

2021-04-05 Thread Jorn Vernee
or.testObjectCollect avgt 30 6.813 � 0.035 ns/op > TypedAsCollector.testObjectCollectHighArity avgt 30 9.718 � 0.066 ns/op > TypedAsCollector.testStringCollect avgt 30 6.737 � 0.016 ns/op > TypedAsCollector.testStringCollectHighArity avgt 30 9.618 � 0.

Re: RFR: 8264288: Performance issue with MethodHandle.asCollector [v2]

2021-04-02 Thread Jorn Vernee
On Fri, 2 Apr 2021 13:56:31 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> - Address review comments >> - Use cached version of store func getter >> -

Re: RFR: 8264288: Performance issue with MethodHandle.asCollector [v2]

2021-04-02 Thread Jorn Vernee
On Thu, 1 Apr 2021 19:19:10 GMT, Paul Sandoz wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> - Address review comments >> - Use cached version of store func getter >> -

Re: RFR: 8264288: Performance issue with MethodHandle.asCollector [v2]

2021-04-02 Thread Jorn Vernee
or.testObjectCollect avgt 30 6.813 � 0.035 ns/op > TypedAsCollector.testObjectCollectHighArity avgt 30 9.718 � 0.066 ns/op > TypedAsCollector.testStringCollect avgt 30 6.737 � 0.016 ns/op > TypedAsCollector.testStringCollectHighArity avgt 30 9.618 �

Re: RFR: 8264288: Performance issue with MethodHandle.asCollector

2021-04-01 Thread Jorn Vernee
On Thu, 1 Apr 2021 19:09:53 GMT, John R Rose wrote: >> This patch speeds up MethodHandle.asCollector handles where the array type >> is not Object[], as well as speeding up all collectors where the arity is >> greater than 10. >> >> The old code is creating a collector handle by combining a

Re: RFR: 8264288: Performance issue with MethodHandle.asCollector

2021-04-01 Thread Jorn Vernee
On Thu, 1 Apr 2021 19:09:14 GMT, John R Rose wrote: >> This patch speeds up MethodHandle.asCollector handles where the array type >> is not Object[], as well as speeding up all collectors where the arity is >> greater than 10. >> >> The old code is creating a collector handle by combining a

Re: RFR: 8264288: Performance issue with MethodHandle.asCollector

2021-04-01 Thread Jorn Vernee
On Thu, 1 Apr 2021 19:12:42 GMT, Paul Sandoz wrote: >> This patch speeds up MethodHandle.asCollector handles where the array type >> is not Object[], as well as speeding up all collectors where the arity is >> greater than 10. >> >> The old code is creating a collector handle by combining a

RFR: 8264288: Performance issue with MethodHandle.asCollector

2021-04-01 Thread Jorn Vernee
This patch speeds up MethodHandle.asCollector handles where the array type is not Object[], as well as speeding up all collectors where the arity is greater than 10. The old code is creating a collector handle by combining a set of hard coded methods for collecting arguments into an Object[],

Re: RFR: 8263380: Unintended use of Objects.nonNull in VarHandles

2021-03-10 Thread Jorn Vernee
On Wed, 10 Mar 2021 16:04:22 GMT, Roger Riggs wrote: >> Use requireNonNull instead. > > Well spotted. Nice catch! We have a test that is supposed to test this: https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java But it is only checking if an NPE is thrown, and not

Integrated: 8255531: MethodHandles::permuteArguments throws NPE when duplicating dropped arguments

2021-01-28 Thread Jorn Vernee
On Tue, 12 Jan 2021 16:58:45 GMT, Jorn Vernee wrote: > Hi, > > This small patch fixes the NPE in the following case: > > MethodHandle mh = MethodHandles.empty(MethodType.methodType(void.class, > int.class, int.class)); > MethodHandles.permuteArguments(mh,

Re: RFR: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException

2021-01-20 Thread Jorn Vernee
On Mon, 18 Jan 2021 12:09:23 GMT, Claes Redestad wrote: > Change `MethodHandles.byteArrayViewVarHandle` to throw > `ArrayIndexOutOfBoundsException` rather than the more generic > `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the > risk for subtle behavioral mismatch

RFR: 8255531: MethodHandles::permuteArguments throws NPE when duplicating dropped arguments

2021-01-12 Thread Jorn Vernee
Hi, This small patch fixes the NPE in the following case: MethodHandle mh = MethodHandles.empty(MethodType.methodType(void.class, int.class, int.class)); MethodHandles.permuteArguments(mh, MethodType.methodType(void.class, int.class), 0, 0); If a parameter name was changed by a

Re: RFR: 8257074 Update the ByteBuffers micro benchmark [v4]

2020-12-10 Thread Jorn Vernee
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.

Re: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v2]

2020-12-10 Thread Jorn Vernee
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

Re: RFR: 8257194: Add 'foreign linker API' in 'jdk.incubator.foreign' module desc/summary

2020-12-07 Thread Jorn Vernee
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:

Integrated: 8257184: Upstream 8252504: Add a method to MemoryLayout which returns a offset-computing method handle

2020-12-07 Thread Jorn Vernee
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

Re: RFR: 8257622: MemoryAccess methods are missing @ForceInline annotations

2020-12-02 Thread Jorn Vernee
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

Re: RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout which returns a offset-computing method handle [v3]

2020-11-27 Thread Jorn Vernee
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

Re: RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout which returns a offset-computing method handle [v2]

2020-11-27 Thread Jorn Vernee
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

Re: RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout which returns a offset-computing method handle [v2]

2020-11-27 Thread Jorn Vernee
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

Re: RFR: 8257186: Size of heap segments is not computed correctlyFix overflow in size computation for heap segments

2020-11-26 Thread Jorn Vernee
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

RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout which returns a offset-computing method handle

2020-11-26 Thread Jorn Vernee
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

Integrated: 8256862: Several java/foreign tests fail on x86_32 platforms

2020-11-26 Thread Jorn Vernee
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.

Re: RFR: 8256862: Several java/foreign tests fail on x86_32 platforms [v2]

2020-11-25 Thread Jorn Vernee
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

RFR: 8256862: Several java/foreign tests fail on x86_32 platforms

2020-11-25 Thread Jorn Vernee
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

Integrated: 8256486: Linux/Windows-x86 builds broken after JDK-8254231

2020-11-25 Thread Jorn Vernee
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

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v9]

2020-11-25 Thread Jorn Vernee
` 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

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v6]

2020-11-25 Thread Jorn Vernee
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

Re: RFR: 8257074 Update the ByteBuffers micro benchmark

2020-11-25 Thread Jorn Vernee
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,

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v8]

2020-11-25 Thread Jorn Vernee
` 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:

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v7]

2020-11-25 Thread Jorn Vernee
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

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v7]

2020-11-25 Thread Jorn Vernee
` 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

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v6]

2020-11-25 Thread Jorn Vernee
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

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v5]

2020-11-24 Thread Jorn Vernee
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

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v6]

2020-11-24 Thread Jorn Vernee
` 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

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v5]

2020-11-24 Thread Jorn Vernee
` 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:

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v4]

2020-11-24 Thread Jorn Vernee
/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

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v4]

2020-11-24 Thread Jorn Vernee
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

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v4]

2020-11-23 Thread Jorn Vernee
` 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

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v3]

2020-11-23 Thread Jorn Vernee
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. >

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v2]

2020-11-23 Thread Jorn Vernee
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

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v3]

2020-11-23 Thread Jorn Vernee
` 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

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v2]

2020-11-23 Thread Jorn Vernee
` 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

Re: RFR: 8256865: Foreign Memory Access and Linker API are missing NPE checks

2020-11-23 Thread Jorn Vernee
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

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231

2020-11-23 Thread Jorn Vernee
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

RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231

2020-11-23 Thread Jorn Vernee
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

Re: RFR: 8230501: Class data support for hidden classes [v4]

2020-11-20 Thread Jorn Vernee
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

Re: RFR: 8230501: Class data support for hidden classes [v4]

2020-11-19 Thread Jorn Vernee
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. >>

Integrated: 8256189: Exact VarHandle tests should test withInvokeBehavior() works as expected

2020-11-18 Thread Jorn Vernee
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

RFR: 8256189: Exact VarHandle tests should test withInvokeBehavior() works as expected

2020-11-17 Thread Jorn Vernee
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 implementation of withInvokeBehavior was incorrect. After some debugging it

Re: RFR: 8256477: Specialize heap memory segment implementations

2020-11-17 Thread Jorn Vernee
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.

Re: RFR: 8255150: Add utility methods to check long indexes and ranges [v7]

2020-11-17 Thread Jorn Vernee
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

Re: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same NativeMethod… [v6]

2020-11-14 Thread Jorn Vernee
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,

Re: RFR: 8255883: Avoid duplicated GeneratedMethodAccessor when reflect method invoked from different threads

2020-11-13 Thread Jorn Vernee
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

RFC: 8256341: Add bootstrap methods for getting array elements

2020-11-13 Thread Jorn Vernee
(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

Re: RFR: 8230501: Class data support for hidden classes [v2]

2020-11-13 Thread Jorn Vernee
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

Re: RFR: 8230501: Class data support for hidden classes [v2]

2020-11-13 Thread Jorn Vernee
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

Re: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same NativeMethod… [v6]

2020-11-13 Thread Jorn Vernee
On Fri, 13 Nov 2020 14:01:28 GMT, Hui Shi wrote: >> Thanks for the update, latest version looks good. > > Thanks all! May this test-request get approved? Notice that the `/test` command is currently un-available (some implementation concerns are still under consideration). As an alternative,

Re: RFR: 8230501: Class data support for hidden classes

2020-11-12 Thread Jorn Vernee
On Thu, 12 Nov 2020 15:11:03 GMT, Jorn Vernee 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-compute

<    1   2   3   4   >