On Fri, Oct 23, 2015 at 2:24 AM Attila Szegedi <szege...@gmail.com> wrote:
> Hi folks, > > Mark Reinhold announced JEP 276 “Dynamic Linking of Language-Defined > Object Models" on core-libs-...@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-libs-...@openjdk.java.net to be > the mailing list for the discussion of the JEP, so that’s why I’m pointing > you over there. > 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 -- 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-languages+unsubscr...@googlegroups.com. To post to this group, send email to jvm-languages@googlegroups.com. Visit this group at http://groups.google.com/group/jvm-languages. For more options, visit https://groups.google.com/d/optout.
