From vladimir.x.ivanov at oracle.com Thu Feb 19 17:48:43 2015 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Thu, 19 Feb 2015 17:48:43 +0000 Subject: hg: panama/panama/hotspot: MethodHandle.linkToNative prototype Message-ID: <201502191748.t1JHmjbS010487@aojmv0008> Changeset: 298f5197762b Author: vlivanov Date: 2015-02-19 20:43 +0300 URL: http://hg.openjdk.java.net/panama/panama/hotspot/rev/298f5197762b MethodHandle.linkToNative prototype * inspired by http://cr.openjdk.java.net/~jrose/panama/native-call-primitive.html. * correctly generates an adapter for (NativeEntryPoint)I only (covers getpid() case) * works on x86_64 only ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/vmStructs.cpp From vladimir.x.ivanov at oracle.com Thu Feb 19 17:49:02 2015 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Thu, 19 Feb 2015 17:49:02 +0000 Subject: hg: panama/panama/jdk: MethodHandle.linkToNative prototype Message-ID: <201502191749.t1JHn7m7011061@aojmv0008> Changeset: 9a0f75940493 Author: vlivanov Date: 2015-02-19 20:47 +0300 URL: http://hg.openjdk.java.net/panama/panama/jdk/rev/9a0f75940493 MethodHandle.linkToNative prototype * inspired by http://cr.openjdk.java.net/~jrose/panama/native-call-primitive.html * added Lookup.findNative(Object,String) and Unsafe.findNativeAddress(name) * trivial test to call getpid() ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java + src/java.base/share/classes/java/lang/invoke/NativeEntryPoint.java + src/java.base/share/classes/java/lang/invoke/NativeMethodHandle.java ! src/java.base/share/classes/sun/misc/Unsafe.java + test/java/lang/invoke/NativeCallTest.java From vladimir.x.ivanov at oracle.com Thu Feb 19 18:23:26 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 19 Feb 2015 21:23:26 +0300 Subject: Native call framework prototype Message-ID: <54E62A1E.1050902@oracle.com> Hi, As you, probably, already noticed, I've just pushed raw prototype of java.lang.invoke-based native function invocation framework, inspired by [1]. The first version is a raw prototype which is able to call getpid (see jdk/test/java/lang/invoke/NativeCallTest.java): MethodHandle mh = LOOKUP.findNative(null, "getpid", MethodType.methodType(int.class)); int pid = (int) mh.invokeExact(); NativeMethodHandle and NativeEntryPoint (MemberName counterpart) are used to represent native function. The implementation relies on 2 VM primitives: MethodHandle.linkToNative() & Unsafe.findNativeAddress() Native part is mostly a skeleton for future work: * linkToNative adapter generation is present only on x64; * supported adapter signature is trivial, just enough to call getpid() * generated adapter doesn't do thread state transition before calling native function (it corresponds to privileged "raw" invocation mode in [2]); On the other hand, Java part is in much better shape. No access & security checks yet, but once VM can generate more adapters, everything should "just work" :-) The next steps are: - extend linkToNative adapter to work on all Java signatures in raw invocation mode - introduce "state transitioning" calling mode (like JNI does) and different calling conventions support; the idea is to encapsulate such info in NativeEntryPoint - JIT-compiler support for "raw" mode: issue direct native call instead of using linkToNative adapter when possible - try some simple Java<->C type conversions (like String <-> char*); they can be done on LambdaForm level - try commoning thread state transitions in JIT-compiled code in order to reduce native call overhead Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~jrose/panama/native-call-primitive.html [2] https://blogs.oracle.com/jrose/entry/the_isthmus_in_the_vm From john.r.rose at oracle.com Thu Feb 19 21:11:05 2015 From: john.r.rose at oracle.com (John Rose) Date: Thu, 19 Feb 2015 13:11:05 -0800 Subject: Native call framework prototype In-Reply-To: <54E62A1E.1050902@oracle.com> References: <54E62A1E.1050902@oracle.com> Message-ID: <23770FEE-CAB8-493B-A935-635DF38A23ED@oracle.com> Congratulations, Vladimir! Mark this date... It's the first native call through a method handle! Another milestone to make (later) will be to attach BSMs to native methods, so that we can bind those through to MHs w/o JNI wrappers. Then, as Darth Vader would say, "the circle is complete". ? John On Feb 19, 2015, at 10:23 AM, Vladimir Ivanov wrote: > > As you, probably, already noticed, I've just pushed raw prototype of java.lang.invoke-based native function invocation framework, inspired by [1]. From vladimir.x.ivanov at oracle.com Thu Feb 19 21:26:31 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 20 Feb 2015 00:26:31 +0300 Subject: Native call framework prototype In-Reply-To: <23770FEE-CAB8-493B-A935-635DF38A23ED@oracle.com> References: <54E62A1E.1050902@oracle.com> <23770FEE-CAB8-493B-A935-635DF38A23ED@oracle.com> Message-ID: <54E65507.60905@oracle.com> > Congratulations, Vladimir! > > Mark this date... It's the first native call through a method handle! Thanks, John! :-) Hooray! > Another milestone to make (later) will be to attach BSMs to native > methods, so that we can bind those through to MHs w/o JNI wrappers. > Then, as Darth Vader would say, "the circle is complete". Are you talking about extending CONSTANT_MethodHandle CP entry to describe method handles to native methods? Considering presence of NativeMethodHandle in my prototype, what's missing right now is NativeEntryPoint explosion in JIT. It's already possible to bind indy to NativeMethodHandle with appropriate BSM and when JIT can get rid of linkToNative adapter the call site will end up as a raw native call. Best regards, Vladimir Ivanov