Graal: Implement method handle support for GraalVM Native Image

[christianwimmer]

[kaspernielsen]

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?

[loicottet]

Method handles will require some configuration. Whether it will be the existing reflection configuration or a separate one is still open.

[kaspernielsen]

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.

[christianwimmer]

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 java.lang.reflect.Method instance strongly reachable in the image heap, it works without further configuration.

But if you create new method method handle at run time, then you need configuration at image build time.

[kaspernielsen]

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

[felixbarny]

Are invokedynamic instructions supported whose bootstrap method returns a dynamically computed ConstantCallSite?

[christianwimmer]

When everything is finished, all aspects of method handles including bootstrap methods will be supported.

[galderz]

I'm aware MethodHandle support is not complete, but there's something about the current status that found slightly surprising and wondered if in the future it'd be improved: @yrodiere was playing with MethodHandle.Lookup.findVirtual and it didn't work when used on a non-final method on a non-final class that was not extended in the codebase. You'd get error ...could not be reduced to at most a single call or single field access.... The example worked when either the class or method was made final, but I wondered: if the class is not extended by anyone, couldn't the close world analysis deduce that the class and method were virtually final?

[dufoli]

about how to proceed, I try to analyse how to implement it, am I right ?:

• add a new config file and register it in substratevm/src/com.oracle.svm.agent/src/com/oracle/svm/agent/NativeImageAgent.java
• add load of config in substratevm/src/com.oracle.svm.configure/src/com/oracle/svm/configure/config/ConfigurationSet.java
• create a methodHandleConfigurationParser which extend ConfigurationParser (json format and close to reflection one)
• TraceProcessor process methodHandle and create an AbstractProcessor for TraceProcessor
• add option for the config file in substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/configure/ConfigurationFiles.java
• add FallbackFeature to collect methodHandle invoke
• add MethodHandleFeature implements Feature to register methodHandle based of config.
• create JavaLandInvokeSubstitutions for :
  
  
  
  • MethodHandles.Lookup.find
  
  
  • or only MethodHandle.invoke to call