This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-05-22
Channels
- # announcements (17)
- # beginners (11)
- # biff (5)
- # calva (22)
- # cider (30)
- # clj-kondo (33)
- # clj-on-windows (20)
- # clojure (59)
- # clojure-dev (25)
- # clojure-europe (31)
- # clojure-nl (1)
- # clojure-norway (13)
- # clojure-sweden (5)
- # clojure-uk (6)
- # clojurescript (5)
- # community-development (2)
- # cursive (4)
- # datahike (5)
- # datalevin (7)
- # datomic (11)
- # emacs (8)
- # events (1)
- # gratitude (1)
- # hoplon (5)
- # hyperfiddle (1)
- # lsp (59)
- # matrix (11)
- # polylith (14)
- # portal (3)
- # practicalli (1)
- # rdf (2)
- # reitit (9)
- # releases (3)
- # rum (5)
- # yamlscript (6)
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.
never heard of it - link?
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