Re: [jdk17] RFR: 8270025: DynamicCallSiteDesc::withArgs doesn't throw NPE

2021-07-12 Thread Jorn Vernee
On Sat, 10 Jul 2021 19:03:36 GMT, Vicente Romero wrote: > Please review this PR that is fixing a mismatch between the implementation > for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its > implementation. I made a mistake while working on a recent CSR >

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

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

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-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 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

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,

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: 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

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: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 [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 �

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 [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 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 [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 [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-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
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: 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

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

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: 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

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: 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 [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: 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

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: 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-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`

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: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage

2021-09-13 Thread Jorn Vernee
On Mon, 13 Sep 2021 11:06:15 GMT, Сергей Цыпанов wrote: > Currently the method is implemented like > > public List> parameterList() { > return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); > } > > This seems to be excessive, as three objects are allocated here. Instead we >

Re: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage

2021-09-13 Thread Jorn Vernee
On Mon, 13 Sep 2021 11:06:15 GMT, Сергей Цыпанов wrote: > Currently the method is implemented like > > public List> parameterList() { > return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); > } > > This seems to be excessive, as three objects are allocated here. Instead we >

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC

2021-07-13 Thread Jorn Vernee
On Tue, 13 Jul 2021 13:52:18 GMT, Vladimir Ivanov wrote: >> This patch rewrites the prologue and epilogue of panama upcalls, in order to >> fix the test failure from the title. >> >> Previously, we did a call to potentially attach the current thread to the >> VM, and then afterwards did the

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

2021-07-13 Thread Jorn Vernee
e upcall around the call on the back-edge, which was > previously missing. Since the new code allocates a handle block as well, I've > added handling for those oops to frame & OptimizedUpcallBlob. > > Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3 Jorn Verne

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

2021-07-15 Thread Jorn Vernee
On Thu, 15 Jul 2021 12:25:54 GMT, Jorn Vernee wrote: >> src/hotspot/share/prims/universalUpcallHandler.cpp line 76: >> >>> 74: >>> 75: // modelled after JavaCallWrapper::JavaCallWrapper >>> 76: Thread* >>> ProgrammableUpcallHandler:

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

2021-07-15 Thread Jorn Vernee
On Wed, 14 Jul 2021 00:58:38 GMT, David Holmes wrote: > The mapping to JavaCallWrapper seems reasonable but there are a few > differences that I'm now assuming stem from the fact upcalls start > _thread_in_native while JCW starts from _thread_in_vm? The main difference stems from the fact

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

2021-07-15 Thread Jorn Vernee
On Wed, 14 Jul 2021 00:24:38 GMT, David Holmes wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Assert frame is correct type in frame_data_for_frame > > src/hotspot/share/prims/univ

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

2021-07-15 Thread Jorn Vernee
On Wed, 14 Jul 2021 00:50:44 GMT, David Holmes wrote: >> src/hotspot/share/runtime/safepoint.cpp line 931: >> >>> 929: // See if return type is an oop. >>> 930: bool return_oop = nm->method()->is_returning_oop(); >>> 931: HandleMark hm(self); >> >> I was seeing an

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

2021-07-15 Thread Jorn Vernee
On Wed, 14 Jul 2021 00:47:47 GMT, David Holmes wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Assert frame is correct type in frame_data_for_frame > > src/hotspot/share/prims/univ

Re: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file

2021-09-23 Thread Jorn Vernee
On Thu, 16 Sep 2021 09:06:20 GMT, Christian Stein wrote: > This commit appends the name of the JAR file to the exception message for > when automatic module lists a non-existing provider class. Marked as reviewed by jvernee (Reviewer). - PR:

Re: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v7]

2021-10-12 Thread Jorn Vernee
On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore wrote: >> This patch overhauls the library loading mechanism used by the Foreign >> Linker API. We realized that, while handy, the *default* lookup abstraction >> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. >>

Re: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage

2021-09-22 Thread Jorn Vernee
On Mon, 13 Sep 2021 11:06:15 GMT, Сергей Цыпанов wrote: > Currently the method is implemented like > > public List> parameterList() { > return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); > } > > This seems to be excessive, as three objects are allocated here. Instead we >

Re: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage

2021-09-22 Thread Jorn Vernee
On Mon, 13 Sep 2021 11:06:15 GMT, Сергей Цыпанов wrote: > Currently the method is implemented like > > public List> parameterList() { > return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); > } > > This seems to be excessive, as three objects are allocated here. Instead we >

Re: RFR: 8277924: Small tweaks to foreign function and memory API [v2]

2021-11-29 Thread Jorn Vernee
st incrementally with one > additional commit since the last revision: > > Update > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java > > Co-authored-by: Jorn Vernee src/jdk.incubator.foreign/share/classes/jdk/incubator/fo

Re: RFR: 8277924: Small tweaks to foreign function and memory API

2021-11-29 Thread Jorn Vernee
On Mon, 29 Nov 2021 11:22:45 GMT, Maurizio Cimadamore wrote: > Following integration of the second incubator of the foreign function and > memory API [1], we detected few divergences between the contents of the jdk > repo and the panama repo: > > * the name of some of the

Re: RFR: 8277165: jdeps --multi-release --print-module-deps fails if module-info.class in different versioned directories

2021-11-23 Thread Jorn Vernee
On Tue, 23 Nov 2021 20:54:55 GMT, Mandy Chung wrote: > jdeps intends to report an error if there are multiple versions of the same > class being parsed. module-info.class should be excluded from such > detection. > > This patch also fixes a data race in `VersionHelper::set` and also unwraps

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v10]

2021-11-02 Thread Jorn Vernee
On Mon, 1 Nov 2021 12:05:32 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v10]

2021-11-02 Thread Jorn Vernee
On Mon, 1 Nov 2021 15:38:18 GMT, Jorn Vernee 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 17 commits: >> >> - Add cache for memory address var handles >> - Merg

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v12]

2021-11-02 Thread Jorn Vernee
On Mon, 1 Nov 2021 22:36:40 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v12]

2021-11-02 Thread Jorn Vernee
On Tue, 2 Nov 2021 19:02:51 GMT, Maurizio Cimadamore wrote: >> What is missing, I think, is a check (size > arenaSize) at the beginning of >> the method (we only check this in one of the paths). But we need to check >> before and after, I think, as it is possible to allocate a segment and

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v18]

2021-11-05 Thread Jorn Vernee
On Fri, 5 Nov 2021 14:33:44 GMT, Maurizio Cimadamore wrote: >> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java >> line 134: >> >>> 132: * >>> 133: * Upcall stubs are generally safer to work with, as the linker >>> runtime can validate the type of the target

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v18]

2021-11-05 Thread Jorn Vernee
On Fri, 5 Nov 2021 11:06:53 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v16]

2021-11-03 Thread Jorn Vernee
On Wed, 3 Nov 2021 13:08:55 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8278341: Liveness check for global scope is not as fast as it could be

2021-12-07 Thread Jorn Vernee
On Tue, 7 Dec 2021 13:12:13 GMT, Maurizio Cimadamore wrote: > When doing some unrelated performance measurements, I realized that segments > backed by global scope were still paying a relatively high cost for liveness > checks - that's because GlobalScopeImpl extends from SharedScopeImpl, and

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3]

2021-07-16 Thread Jorn Vernee
On Thu, 15 Jul 2021 15:54:50 GMT, Jorn Vernee wrote: >> This patch rewrites the prologue and epilogue of panama upcalls, in order to >> fix the test failure from the title. >> >> Previously, we did a call to potentially attach the current thread to the >> VM, an

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v4]

2021-07-16 Thread Jorn Vernee
e upcall around the call on the back-edge, which was > previously missing. Since the new code allocates a handle block as well, I've > added handling for those oops to frame & OptimizedUpcallBlob. > > Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3 Jorn Verne

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

2021-07-16 Thread Jorn Vernee
On Thu, 15 Jul 2021 23:43:38 GMT, Vladimir Kozlov wrote: >> Sorry, I sent the wrong godbolt link: https://godbolt.org/z/1665fWzff > > @JornVernee I have small correct to your comment. We use simple inheritance > for Thread subclasses. Their instances have **one** vtbl pointer at the same >

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3]

2021-07-16 Thread Jorn Vernee
On Fri, 16 Jul 2021 02:12:20 GMT, David Holmes wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Address David's review comments > > src/hotspot/share/prims/universalUpcallHandler.cpp li

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3]

2021-07-15 Thread Jorn Vernee
e upcall around the call on the back-edge, which was > previously missing. Since the new code allocates a handle block as well, I've > added handling for those oops to frame & OptimizedUpcallBlob. > > Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3 Jorn Verne

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3]

2021-07-15 Thread Jorn Vernee
On Thu, 15 Jul 2021 15:54:50 GMT, Jorn Vernee wrote: >> This patch rewrites the prologue and epilogue of panama upcalls, in order to >> fix the test failure from the title. >> >> Previously, we did a call to potentially attach the current thread to the >> VM, an

Re: [jdk18] RFR: 8278897: Alignment of heap segments is not enforced correctly [v2]

2022-01-04 Thread Jorn Vernee
On Tue, 4 Jan 2022 11:39:08 GMT, Maurizio Cimadamore wrote: >> This PR fixes an issue with alignment constraints not being enforced >> correctly on on-heap segments dereference/copy operations. Alignment of >> on-heap segments cannot be computed exactly, as alignment of elements in >> arrays

Re: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v3]

2022-01-07 Thread Jorn Vernee
On Thu, 6 Jan 2022 12:36:52 GMT, Maurizio Cimadamore wrote: >> This patch fixes a performance issue when dereferencing memory segments >> backed by different kinds of scopes. When looking at inline traces, I found >> that one of our benchmark, namely `LoopOverPollutedSegment` was already >>

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5]

2022-03-24 Thread Jorn Vernee
On Wed, 23 Mar 2022 14:06:56 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5]

2022-03-24 Thread Jorn Vernee
On Thu, 24 Mar 2022 17:48:23 GMT, Maurizio Cimadamore wrote: >> make/test/BuildMicrobenchmark.gmk line 97: >> >>> 95: SRC := $(MICROBENCHMARK_SRC), \ >>> 96: BIN := $(MICROBENCHMARK_CLASSES), \ >>> 97: JAVAC_FLAGS := --add-exports >>> java.base/sun.security.util=ALL-UNNAMED

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v11]

2022-03-24 Thread Jorn Vernee
On Thu, 24 Mar 2022 19:19:34 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5]

2022-03-24 Thread Jorn Vernee
On Thu, 24 Mar 2022 18:35:12 GMT, Jorn Vernee wrote: >> Sure, this is problematic - but at the same time I don't think there's a >> better way to deal with this? I'd prefer to defer this to a separate issue >> (and I think the build team is in a much better position to sugges

Re: RFR: 8283060: RawNativeLibraries should allow multiple clients to load/unload the same library

2022-03-30 Thread Jorn Vernee
On Tue, 29 Mar 2022 20:05:50 GMT, Mandy Chung wrote: > A small improvement to `RawNativeLibraries`. `RawNativeLibraries::load` > returns the same `NativeLibrary` instance of a given path if it's called > multiple times. This means that multiple clients have to coordinate that the > last one

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview)

2022-03-21 Thread Jorn Vernee
On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] -

Re: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v2]

2022-01-06 Thread Jorn Vernee
On Wed, 5 Jan 2022 18:08:01 GMT, Maurizio Cimadamore wrote: >> This patch fixes a performance issue when dereferencing memory segments >> backed by different kinds of scopes. When looking at inline traces, I found >> that one of our benchmark, namely `LoopOverPollutedSegment` was already >>

Re: RFR: 8283689: Update the foreign linker VM implementation [v3]

2022-04-12 Thread Jorn Vernee
5b62ed9092120 > [6]: > https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: > https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: > https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f

Re: RFR: 8285633: Take better advantage of generic MethodType cache

2022-04-26 Thread Jorn Vernee
On Tue, 26 Apr 2022 10:57:04 GMT, Claes Redestad wrote: > The `MethodType.genericMethodType` methods provide convenience methods for > certain common method types and also provide `@Stable` cache that allows for > constant folding. This patch enhances the more generic `methodType` methods >

Re: RFR: 8285633: Take better advantage of generic MethodType cache

2022-04-26 Thread Jorn Vernee
On Tue, 26 Apr 2022 17:20:55 GMT, Claes Redestad wrote: >> test/micro/org/openjdk/bench/java/lang/invoke/MethodTypeAcquire.java line >> 104: >> >>> 102: @Benchmark >>> 103: public MethodType testMultiPType_ObjectOnly() { >>> 104: return MethodType.methodType(Object.class,

Re: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3]

2022-05-17 Thread Jorn Vernee
On Tue, 17 May 2022 08:32:54 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> BootstrapMethodError -> ExceptionInInitializerError > > src/java.base/share

Re: RFR: 8283689: Update the foreign linker VM implementation [v22]

2022-05-17 Thread Jorn Vernee
e22920300c5ffa16fed805b62ed9092120 > [6]: > https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: > https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: > https://github.com/openjdk/jdk/pull/79

Re: RFR: 8283689: Update the foreign linker VM implementation [v21]

2022-05-17 Thread Jorn Vernee
On Tue, 17 May 2022 08:27:41 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Missing ASSERT -> NOT_PRODUCT > > src/java.base/share/classes/jdk/internal/for

Re: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3]

2022-05-17 Thread Jorn Vernee
On Tue, 17 May 2022 05:51:58 GMT, Rémi Forax wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> BootstrapMethodError -> ExceptionInInitializerError > > src/java.base/share

Re: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3]

2022-05-17 Thread Jorn Vernee
On Tue, 17 May 2022 06:13:04 GMT, Rémi Forax wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> BootstrapMethodError -> ExceptionInInitializerError > > src/java.base/share

Re: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v2]

2022-05-17 Thread Jorn Vernee
On Mon, 16 May 2022 12:58:51 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use unaligned layout constants when filling in reconstituted structs (was >&g

Re: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v4]

2022-05-17 Thread Jorn Vernee
those changes were mostly Java as well. > > Thanks, > Jorn > > Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on > Windows and Linux. Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now conta

Re: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3]

2022-05-17 Thread Jorn Vernee
On Tue, 17 May 2022 14:28:11 GMT, Rémi Forax wrote: >> What about using MethodTypeDesc/ClassDesc as building block? > > yes, it should be less expensive, the ClassDesc still need to be constructed > from Class to allow refactoring. Can't wait for constant folding :) I'll pull the

Re: RFR: 8283689: Update the foreign linker VM implementation [v23]

2022-05-17 Thread Jorn Vernee
e22920300c5ffa16fed805b62ed9092120 > [6]: > https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: > https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: > https://github.com/openjdk/jdk/pull/79

Re: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v5]

2022-05-18 Thread Jorn Vernee
On Wed, 18 May 2022 11:27:24 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR brings over commits from the panama-foreign repo. These commits >> mostly pertain to the switch to ASM and away from MethodHandle combinators >> for the binding recipe specialization. But,

Integrated: 8286669: Replace MethodHandle specialization with ASM in mainline

2022-05-18 Thread Jorn Vernee
On Thu, 12 May 2022 17:17:37 GMT, Jorn Vernee wrote: > Hi, > > This PR brings over commits from the panama-foreign repo. These commits > mostly pertain to the switch to ASM and away from MethodHandle combinators > for the binding recipe specialization. But, there is one mo

Re: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3]

2022-05-18 Thread Jorn Vernee
On Wed, 18 May 2022 14:51:02 GMT, Jorn Vernee wrote: >> I wasn't suggesting to add more bindings. I was more suggesting to filter >> out the load/store from the set of bindings (since these are virtualized >> anyways) that are passed to `doBindings`. Then, befo

Re: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3]

2022-05-18 Thread Jorn Vernee
On Wed, 18 May 2022 14:21:55 GMT, Maurizio Cimadamore wrote: >> I'm not sure if there is anything actionable here? >> >> I've thought in the past that it might be nice to have >> `GetArgument`/`SetArgument` and `GetReturnValue`/`SetReturnValue` binding >> operators as well, to make the

RFR: 8286825: Linker naming cleanup

2022-05-18 Thread Jorn Vernee
This patch is a batch naming cleanup for the foreign linker implementation. The naming changes are as follows: - ProgrammableInvoker -> DowncallLinker - ProgrammableUpcallHandler -> UpcallLinker - 'native invoker' -> 'downcall stub' - 'optimzed entry blob' -> 'upcall stub' -

Re: RFR: 8286825: Linker naming cleanup [v2]

2022-05-20 Thread Jorn Vernee
lLinker* > - foreign_globals* -> foreignGlobals* (to match existing convention) > > Method, field, and other variable names are also adjusted accordingly. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Comments + cleanup

Re: RFR: 8286825: Linker naming cleanup

2022-05-20 Thread Jorn Vernee
On Wed, 18 May 2022 16:54:06 GMT, Jorn Vernee wrote: > This patch is a batch naming cleanup for the foreign linker implementation. > > The naming changes are as follows: > > - ProgrammableInvoker -> DowncallLinker > - ProgrammableUpcallHandler -> UpcallLink

Re: RFR: 8286825: Linker naming cleanup

2022-05-20 Thread Jorn Vernee
On Fri, 20 May 2022 10:36:17 GMT, Maurizio Cimadamore wrote: >> This patch is a batch naming cleanup for the foreign linker implementation. >> >> The naming changes are as follows: >> >> - ProgrammableInvoker -> DowncallLinker >> - ProgrammableUpcallHandler -> UpcallLinker >> - 'native

Re: RFR: 8286825: Linker naming cleanup [v2]

2022-05-23 Thread Jorn Vernee
On Fri, 20 May 2022 10:57:44 GMT, Jorn Vernee wrote: >> This patch is a batch naming cleanup for the foreign linker implementation. >> >> The naming changes are as follows: >> >> - ProgrammableInvoker -> DowncallLinker >> - ProgrammableUpcallHandler

Integrated: 8286825: Linker naming cleanup

2022-05-23 Thread Jorn Vernee
On Wed, 18 May 2022 16:54:06 GMT, Jorn Vernee wrote: > This patch is a batch naming cleanup for the foreign linker implementation. > > The naming changes are as follows: > > - ProgrammableInvoker -> DowncallLinker > - ProgrammableUpcallHandler -> UpcallLink

<    1   2   3   4   >