Yes Nicola, that's exactly the problem I was talking about. As far as I'm aware, the only way to make this maximally efficient at runtime on the JVM (and probably any other non-trivial runtime with typed method dispatch?) is to use some kind of recompilation strategy.
invokedynamic is nice but doesn't get you there either: it still has a non-trivial runtime overhead. Scala has an incremental recompilation strategy using dependencies, though I think their compilation units are a bit larger than individual Clojure forms. See for more information: http://www.scala-sbt.org/0.13.0/docs/Detailed-Topics/Understanding-incremental-recompilation.html<http://www.scala-sbt.org/0.12.3/docs/Detailed-Topics/Understanding-incremental-recompilation.html> On Wednesday, 9 October 2013 06:09:02 UTC+8, Nicola Mometto wrote: > > > I don't think that's what Mike was talking about. > Say we have (defn x ^long [] 1), clojure will use the IFn$L and emit an > "public long invokePrim()" method. > > When we do (defn y [] (let [a (x)] a) the compiler will call .invokePrim > instead of invoke. > > If we redefine (defn x [] "") then y won't work because the new version > of x doesn't implement IFn$L, we'd need to recompile y too. > > Mikhail Kryshen writes: > > > Mikera <mike.r.an...@gmail.com <javascript:>> writes: > > > >> 2) This in turn means we are going to have to "recompile" if we want to > >> retain any sort of dynamic behaviour. The current system of > independently > >> mutable vars won't work (for obvious reasons: changing a var could > easily > >> violate the previous type inference assumptions) > > > > The HotSpot JIT compiler already performs adaptive optimization based on > > runtime profile and dynamicaly recompiles bytecode when necessary. The > > problem is the way Clojure calls functions through vars is not > > transparent to the compiler's optimizer. Invokedynamic can help here, > > see > > > http://blog.headius.com/2011/10/why-clojure-doesnt-need-invokedynamic.html > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
