JEP 276: Dynamic Linking of Language-Defined Object Models

[Attila Szegedi]

Hi folks,

Mark Reinhold announced JEP 276 “Dynamic Linking of Language-Defined Object Models" on core-l...@openjdk.java.net mailing list about a week ago (here’s the thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035961.html). This is basically an effort to make Dynalink available as a publicly supported API in the “jdk.dynalink” package for JDK 9. Dynalink has matured a lot with Nashorn and by now sufficiently stabilized that we’re confident going forward and committing to having it as such a publicly supported API.

I just posted an update on that thread with availability of current state of the code and documentation: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/036052.html

Please note that the JEP declared core-l...@openjdk.java.net to be the mailing list for the discussion of the JEP, so that’s why I’m pointing you over there.

Thanks,

  Attila.

 

[Charles Oliver Nutter]

Excellent! I endorse! This will allow Mirah to support dynamic
dispatch while still not shipping any runtime.

I will jump in on the core-libs conversation after we've got our
JavaOne talk ready :-)

- Charlie

> --
> You received this message because you are subscribed to the Google Groups
> "JVM Languages" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jvm-language...@googlegroups.com.
> To post to this group, send email to jvm-la...@googlegroups.com.
> Visit this group at http://groups.google.com/group/jvm-languages.
> For more options, visit https://groups.google.com/d/optout.

[Jason Zaugg]

Scala committer here. I wasn't subscribed to core-libs-dev yesterday so I can't reply to the message over there, so posting here instead.

A while back, I prototyped [1] a change to Scala's structural invocations to use dynalink. The existing implementation generates code at each callsite to reflect on the receiver to lookup the matching target method (employing a cache) and is described in "Compiling Structural Types on the JVM" (Dubochet, Odersky) [2].

dynalink was really simple to integrate, and seems to fit our use case perfectly.

The need to add a runtime dependency was a little off-putting (tilting the balance from "no brainer, let's use this" to "nice to have, but I'd rather not touch our build") , so I welcome the move to standardize the API.

One problem that came to mind when reviewing the dynalink internals was potential class loader leaks in the cache in ChainedCallSite: an call site will contain a strong reference to the method handle of recently invoked targets. Has this issue been raised before?

Scala's existing cache [3] associated with each structural type callsites suffers from the same problem. I don't remember anyone reporting it in practice, but this might be because structural calls are something of a niche / frowned-upon feature in Scala.

I understand that this sort of problem is notoriously painful to code around, though.

Jason Zaugg

[1] https://github.com/scala/scala/compare/2.11.x...retronym:topic/indy-structural

[2] http://infoscience.epfl.ch/record/138931/files/2009_structural.pdf

[3] https://github.com/scala/scala/blob/v2.11.7/src/library/scala/runtime/MethodCache.scala