JEP 276: Dynamic Linking of Language-Defined Object Models

[Attila Szegedi]

> On Oct 18, 2015, at 10:49 AM, Jochen Theodorou <blackdrag at gmx.org> wrote:
> 
> On 17.10.2015 13:30, Martijn Verburg wrote:
>> This looks very, very promising.  Would it help to get the language
>> maintainers of the most popular scripting/dynamic JVM languages involved
>> ASAP?  Happy to contact Groovy, Clojure, Scala, JRuby folks (although I
>> suspect many of them are on this list).
> 
> still easy to miss something like this ;)
> 
> But I can give some comments for Groovy on this already. As I understand it, this JEP is mostly for calls from Java on objects from other languages.

I would say that understanding is incomplete. It is used to call from any language to any language. You can certainly use it to call from Java to another language, as well as to do dynamic calls within a single language, and across two different languages, neither of them necessarily being Java.

> I have basically only  main points:
> 
> * Invokedynamic (like invokeinterface and invokevirtual) does not like calls with null as receiver, quitting the call right away with a NPE.

This is fortunately not true, and Nashorn can show you that it isn’t. Launch it with:

$JAVA_HOME/bin/jjs -doe -J-XX:+UnlockDiagnosticVMOptions -J-XX:+ShowHiddenFrames

and type “null()” at the command prompt (Nashorn’s JS null is also Java null). You’ll get this stack trace:

<shell>:1 TypeError: null is not a function
	at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:57)
	at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:213)
	at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:185)
	at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:172)
	at jdk.nashorn.internal.runtime.linker.NashornBottomLinker.linkNull(NashornBottomLinker.java:176)
	at jdk.nashorn.internal.runtime.linker.NashornBottomLinker.getGuardedInvocation(NashornBottomLinker.java:66)
	at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124)
	at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:154)
	at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:253)
>>	at java.lang.invoke.LambdaForm$DMH/348100441.invokeSpecial_LLIL_L(LambdaForm$DMH:1000016)
>>	at java.lang.invoke.LambdaForm$BMH/827966648.reinvoke(LambdaForm$BMH:1000054)
>>	at java.lang.invoke.LambdaForm$MH/1273765644.exactInvoker(LambdaForm$MH:1000016)
>>	at java.lang.invoke.LambdaForm$MH/2013559698.linkToCallSite(LambdaForm$MH:1000011)
	at jdk.nashorn.internal.scripts.Script$Recompilation$1$\^shell\_.:program(<shell>:1)
	at ...

The frames I marked with “>>” are all java.lang.invoke internals going from the invokedynamic instruction with a null receiver, successfully dispatching into Dynalink and then Nashorn. (The bottommost frame before the cutoff is the invokedynamic instruction itself). It’s Nashorn that will ultimately respond to this throwing a JavaScript-specific TypeError from within the linker. invokedynamic doesn’t treat the first argument specially (in this one sense it’s more like invokestatic).

> But languages may allow for calls on null. That again means some kind of dummy receiver is required, if this is supposed to work. Then of course, if you want to allow calls on null, every call would have to go through the runtime in the end, thus I suspect this will be out of scope for this JEP.
> 
> * Another part is the lookup of calls itself. To me the JEP is not fully clear here. Sure, there is a service for this, but is every call checked? That may slow down normal compilation for Java. The JEP speaks of methods provided beyond what Java offers - but what about methods replacing normal Java methods?

JEP 276 does not concern itself with any aspect of a compilation. It concerns itself with what happens at run time when an invokedynamic instructions needs to be linked.

It is the job of the language-specific linkers to resolve the method handle to be linked. JEP 276 specifies one built-in linker named BeansLinker which provides the “usual” operational semantics for POJOs that can be used standalone or composed with other linkers (Nashorn obviously composes it with its own linkers so it can link both POJOs and native JS objects at any call site). BeansLinker looks up method handles mostly through unreflection. I’m not sure what do you mean by “checked” either - only public methods on publicly accessible classes are considered at this time.

Hope this clarifies few things.

Attila.

> 
> Btw, one part that would make me very happy, is an official API, that allows some control of phases of the Java compiler as well as make missing classes programatically known to the compiler without requiring the java compiler to write those out as well. And that especially because I assume that jigsaw will put all the api needed for this into hiding by modules.
> 
> bye Jochen Theodorou
>