4 ms·

Aiyayyay. Were to begin. calls are made via a known path to a specific function, and only via rebinding can that target change. The general case

by fogus 15y ago

Aiyayyay. Were to begin. calls are made via a known path to a specific function, and only via rebinding can that target change. The general case goes straight through. This is half true. The rebinding via def will change the target, but the call always happens via a lookup through a volatile. In fact, it's this very chain that can benefit from invokedynamic. If Clojure had to deal with dynamically selecting a method based on a target object type Clojure's protocols are polymorphic on the type of the first argument. The protocol functions are call-site cached (with no per-call lookup cost if the target class remains stable). This is another place where invokedynamic would help. benefit out of invokedynamic...if it hadn't already added hacks and syntax I think you're mixed up here. The JVM already optimizes classes and interfaces. All that Clojure's type hints allow you to do is to help the compiler in the cases where it's unable to infer the proper type. Hinting is not always necessary and better inferencing will start chipping into the remaining cases. JRuby compares favorably to Clojure without the typing syntax, performance-wise, which is quite acceptable to me. With invokedynamic That's because JRuby is awesome tech. You've certainly set the bar high for dynamic dispatch that invokedynamic has yet to meet. as the Hotspot guys optimize invokedynamic. What's the over-under on it happening by Java8? Java9?

headius 15y ago
I will grant I do not know the details of Clojure's dispatch protocols, but I've always felt like there's more that invokedynamic could do. Sounds like that's the case. My statements were based mostly on brief discussions with Rich about how dispatch happens...which made most of them sound pretty static in nature. Regarding invokedynamic optimization: Most of what I'm playing with will go into the first Java 7 update. I'm helping to validate that it works, it's fast, and it's ready for consumption.
- fogus 15y ago
  there's more that invokedynamic could do Definitely. As with anything, there are tradeoffs, so we'll likely hold off to see how it plays out. Most of what I'm playing with will go into the first Java 7 update. Hey no fair, you have inside information. All bets are off. This is great news actually. :-)
  - headius 15y ago
    It's all public on the MLVM list. Unfortunately there's only a handful of dynlangs actively hitting this stuff. Would love to see more Clojure folks get involved.

by fogus 15y ago

headius 15y ago

I will grant I do not know the details of Clojure's dispatch protocols, but I've always felt like there's more that invokedynamic could do. Sounds like that's the case. My statements were based mostly on brief discussions with Rich about how dispatch happens...which made most of them sound pretty static in nature. Regarding invokedynamic optimization: Most of what I'm playing with will go into the first Java 7 update. I'm helping to validate that it works, it's fast, and it's ready for consumption.

fogus 15y ago
there's more that invokedynamic could do Definitely. As with anything, there are tradeoffs, so we'll likely hold off to see how it plays out. Most of what I'm playing with will go into the first Java 7 update. Hey no fair, you have inside information. All bets are off. This is great news actually. :-)
- headius 15y ago
  It's all public on the MLVM list. Unfortunately there's only a handful of dynlangs actively hitting this stuff. Would love to see more Clojure folks get involved.