Fork me on GitHub
#clojure-dev
<
2024-05-22
>
Ingy döt Net19:05:17

Somebody told me about importdynamic but looking online it support for it in Clojure seems to have been discussed but not added. Just wondering if it's currently usable or planned.

Alex Miller (Clojure team)19:05:04

never heard of it - link?

hiredman19:05:02

You must mean the jvm invokedynamic instruction

Ingy döt Net19:05:18

Yes invokedynamic . Apologies.

hiredman20:05:37

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

👍 1
hiredman20:05:13

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

Ingy döt Net20:05:46

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

hiredman20:05:42

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

hiredman20:05:19

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

Alex Miller (Clojure team)20:05:27

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

hiredman20:05:20

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

Alex Miller (Clojure team)20:05:20

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.

Alex Miller (Clojure team)20:05:04

well, the bottom of it at least

Alex Miller (Clojure team)20:05:54

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

Alex Miller (Clojure team)20:05:20

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

😂 3
👍 4
hiredman20:05:08

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

Alex Miller (Clojure team)20:05:17

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

Alex Miller (Clojure team)20:05:17

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

Alex Miller (Clojure team)20:05:05

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)

😮 3
Alex Miller (Clojure team)21:05:46

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

2
Ludger Solbach17:05:23

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

hiredman17:05:47

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

Ludger Solbach17:05:02

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.

Alex Miller (Clojure team)18:05:27

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