Implement method handle support for GraalVM Native Image #2761
Comments
|
Is the plan that every method handle created either via a field/constructor/executable or via java.lang.invoke.MethodHandles as part of an image's build time will work at runtime without any additional configuration? |
|
Method handles will require some configuration. Whether it will be the existing reflection configuration or a separate one is still open. |
|
I'm not sure I understand why you need any configuration. MethodHandles that are strongly reachable after the image creation phase will in 99.99% of all cases be meant for invocation at runtime. |
Yes, and such method handles will work without configuration. Same as reflection: if you have a But if you create new method method handle at run time, then you need configuration at image build time. |
|
Sounds great. I must admit the more I work with MHs the less my need for runtime support for them. Transformations via the various static methods on MethodHandles can mostly be done at image creation time. The only thing I actually miss is being able to bind object instances that cannot be created until runtime. For example, via MethodHandle#bindTo or MethodHandles#insertArguments |
|
Are invokedynamic instructions supported whose bootstrap method returns a dynamically computed |
|
When everything is finished, all aspects of method handles including bootstrap methods will be supported. |
|
For Scala, this sbt plugin will handle replacing a use of method handles in the standard library: https://github.com/scalameta/sbt-native-image That may solve scala issues for the short term. It would still be nice to not need a work around. |
|
Full method handles support will be included in the 21.0 release. This will remove the need for |
|
Is there any to get a warning/error if you create non-direct methodhandles at runtime? |
|
@kaspernielsen sorry for the late reply. There is currently no way of checking that, but you can create an issue to request that feature. |
|
Something seems to be missing from the MethodHandle support, getting: The exception above is when trying to invoke the method final Class<?> unsafeClass = Class.forName("sun.misc.Unsafe");
final MethodHandle unmapper = lookup.findVirtual(unsafeClass, "invokeCleaner", methodType(void.class, ByteBuffer.class));
final Field f = unsafeClass.getDeclaredField("theUnsafe");
f.setAccessible(true);
final Object theUnsafe = f.get(null);
unmapper.bindTo(theUnsafe);
//...
unmapper.invokeExact(buffer); |
|
@gustavonalle can you open a separate issue for this bug? I'll look into it. |
|
@loicottet sure, I have a reproducer inside Quarkus only, when trying to create a reproducer for GraalVM directly, got caught in #3241, could you take a look? |
|
I'm using native-image 20.0.1 2023-04-18 this is causing a great trouble, as I have to manually patch every callsites, and the changed version are not equivalent to the panama one(think
|
|
@revintec "Panama" is an umbrella term for many different features. But most of them are currently not support on Native Image, because they are still incubator / preview and changing quickly. So nothing is "specifically disabled", but when you enable preview features and use them then you can get all sorts of strange errors like the one you observed. We are actively working on the foreign call interface of Panama. For other parts like the vector API we have not started any implementation at all. |
|
https://mail.openjdk.org/pipermail/panama-dev/2023-July/019510.html Foreign Function & Memory API will (very likely) be stable in Java 22, I'm looking forward to seeing it on GraalVM. |
Does it support vector api in native-image now？ |
No, there is no work on vector API support for native image. It does not seem likely that the vector API moves out of the incubator status anytime soon. |
@christianwimmer it seems FFM is finally stable in JDK22 https://openjdk.org/jeps/454 currently I have to cook every native call in my java program to suit native-image... the code was littered with |
|
There is some support for the Foreign Function & Memory API in the upcoming GraalVM for JDK 22, but not everything is working yet and it is not optimize yet, i.e., the parts that are working are likely to be slow compared to the HotSpot VM. |
|
@christianwimmer from what I've read here reference code: import java.lang.foreign.*
import java.lang.foreign.Linker.Option
import java.lang.foreign.Linker.Option.captureStateLayout
import java.lang.foreign.MemoryLayout.PathElement
val linker=Linker.nativeLinker()
val opts=arrayOf(Option.captureCallState("errno"))
val _errno=captureStateLayout()
val errno=_errno.varHandle(PathElement.groupElement("errno"))
fun downcallHandle(name:String,fn:FunctionDescriptor,vararg opts:Option)=linker.defaultLookup().find(name).orElse(null)?.let{
linker.downcallHandle(it,fn,*opts)
}
fun main(args:Array<String>) {
val mh=downcallHandle("geteuid",FunctionDescriptor.of(ValueLayout.JAVA_INT,*arrayOfNulls<MemoryLayout>(0)),*opts)
val arena = Arena.ofConfined()
val state = arena.allocate(_errno)
println(mh!!.invokeExact(state)as Int)
val aa=errno.get(state)as Int
println(aa)
} |
并非全部的符号lookup都会有支持，请参考https://www.graalvm.org/latest/reference-manual/native-image/dynamic-features/foreign-interface/这篇文档 |
thanks for your swift reply! it's of a great help |
No description provided.
The text was updated successfully, but these errors were encountered: