One of the problems with these sort of discussions is the total lack of hard facts. Words such as "could do this" or "doesn't do that" when referring to HotSpot are very rarely backed up by actual benchmarks, or ASM printouts. I would imagine that any serious attempt at an optimization layer will be prefixed by lots of research into where the current compiler fails, and what the proper enhancements should be.
Timothy On Wed, Oct 9, 2013 at 6:29 AM, Mikhail Kryshen <mikh...@kryshen.net> wrote: > Nicola Mometto <brobro...@gmail.com> writes: > > > 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. > > Actually I am talking about the same problem. For virtual calls the JIT > compiler can determine that only one implementation of the method is > being used, inline the call and perform object explosion, effectively > removing boxing of primitives. When new implementation becomes > available it dynamically recompiles affected bytecode. I don't know if > the current implementation does this for invokedynamic calls, but there > is a potential. It just does not feel right to invent a whole new > complex optimization layer on the Clojure side until we fully use the > optimization capabilities of the JVM. > > -- > Mikhail > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- 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.
