JEP 276: Dynamic Linking of Language-Defined Object Models

Skip to first unread message

Attila Szegedi

Oct 22, 2015, 12:24:49 PM10/22/15
Hi folks,

Mark Reinhold announced JEP 276 “Dynamic Linking of Language-Defined Object Models" on mailing list about a week ago (here’s the thread: 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:

Please note that the JEP declared to be the mailing list for the discussion of the JEP, so that’s why I’m pointing you over there.


Charles Oliver Nutter

Oct 22, 2015, 6:16:44 PM10/22/15
to JVM Languages
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
> To post to this group, send email to
> Visit this group at
> For more options, visit

Jason Zaugg

Oct 23, 2015, 1:17:29 AM10/23/15
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

Reply all
Reply to author
0 new messages