Clojurians Log v2

never heard of it - link?

You must mean the jvm invokedynamic instruction

Yes invokedynamic . Apologies.

the instruction is understood by the jvm regardless, so it is usable in that sense

there is nothing in a released version of the clojure language that generates that bytecode when compiled

Okay thanks. I think I can work with that. Sorry I didn't look into it enough to ask a better question.

there have been various experiments trying to use it to improve the functioning of existing features in clojure, but nothing conclusive enough to rewrite bits of the compiler to use it seems to have been found

years ago when invokedynamic was first becoming available headius (jruby guy) joked that clojure was "cheating" because so much of it is actually static, so doesn't need invokedynamic to by fast on the jvm

the next alpha will use invokedynamic to adapt Clojure IFn's to Java functional interfaces

the flip side of that is it doesn't necessarily get any kind of boost from (at the time) a new feature

it was not particularly fast when it was introduced, but they've really improved the ability of methodhandles produced by invokedynamic to get optimized and I expect we will be using it more.

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L1732-L1765 is the new code emitting indy for IFn adapters

well, the bottom of it at least

that's bootstrapping with LambdaMetaFactory, basically mimicking what Java does with lambdas to adapt a static IFn invoker (fixed static methods in FnInvokers) to look like the target functional interface SAM method

which really exposes that Java is all lies, and the jvm is awesome

the are jvm/java things that are annoying to use with clojure because clojure doesn't have some way in the language to make invokedynamic bytecodes, particularly if I recall some of the methods on varhandles and methodhandles can't actually be called without using invokedynamic

yeah, the "signature polymorphic" https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/invoke/MethodHandle.html#invoke(java.lang.Object...) that do dynamic spreading. we came close to fixing that in the course of doing some of this work but were trying not to get distracted

you can get around that one by calling asSpreader or by calling invokeWithArguments, but there are some perf consequences

we actually reimplemented reflection with cached MethodHandles and spreaders and about 95% of that was pretty great (and it's 100x faster than current reflective calls), but the other 5% was tricky enough that we ultimately bailed out (focus focus)

really made us ask, what if reflection was almost as fast as direct? would you even care most of the time?

I wouldn't, at least most of the time.

the major reason to avoid reflection(in large production code bases) isn't performance, it is because you want no ambiguities about which method is called

To be more precise, I wouldn't mind reflection, if it was almost as fast as direct in non performance critical code in Java interop, where there often is no real ambiguity.

If there is ambiguity at runtime then it’s probably an error either way