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.anderson...@gmail.com> 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.
