Hi Rémi! What a pleasant surprise to see your name here. The whole community owes you a great deal of gratitude for your work.
I'm hoping to be at JVMLS this summer to talk about some indy/condy experiments. Alex summed up the philosophy well: we don't do stuff just because it's possible to do, but because it satisfies some objective that seems worth doing. There are others, but improving peak performance (which is already quite good, thanks to Rich's design and HotSpot) and improving startup time are two interesting objectives. One complaint often heard in the community is long startup time. Clojure can be AOT compiled, which helps. We could also cache bytecode in a way that is sensitive to Maven or git dependencies. The rest of this post assumes that we have bytecode and not raw s-exprs. We could probably improve startup by 30-50% with bytecode changes alone, but I don't think that is a big enough number to assuage complaints, and personally I don't think this is one of the "large challenges" that Clojure programmers face day-to-day. It is important for containerization and AWS Lambda to have strategies for fast startup, maybe that needs more assistance from either the JVM (Class Data Sharing, Application CDS, etc.) or execution substrates like AWS Lambda. (The #1 way to help with startup is to depend on fewer dependencies and load fewer classes, and that's is a cultural thing that you can't solve in a compiler.) Some users are looking toward Graal native-image for fast startup, but there are so many restrictions with that tool that I don't even know what to say. A Lisp with eval is an open-world assumption, native-image is closed world, and it's Not Java. That being said, if you look at Clojure bytecode, in general a lot work happens in <clinit> that can be deferred until an indy instruction bootstraps. (The current strategy predates indy and certainly condy). For example, in https://gist.github.com/ghadishayban/72a87c8e12cd66b0f4e285c1754157f5 there are two constants (a Pattern and a Var) which get initialized in <clinit> and stuffed into final fields. During the load of Clojure namespaces, we load a lot of similar, larger datastructures that serve as Var's metadata. Another constant example is https://gist.github.com/ghadishayban/f7b4c2206836f29d7e9f8cd614cdd2d1 With condy, ldc's can take bootstrap methods, so we can get rid of the array construction and defer the <clinit> work, making the meat of the code degenerate to: ldc `:id` (Keyword.class) aload 1 ldc `:byte` aload 2 ldc `:is` aload 3 invokestatic IPersistentMap.of(Object,Object,Object,Object,Object,Object) (this API doesn't exist, but should!) areturn We can significantly reduce the bytecode size of regular Clojure functions, which is a proxy for better inlining+peak performance, and defer all the clinit setup, improving startup. (Aside: notice that three of the six components in the map are static, only the right hand side is dynamic. We could pre-fab an array factory indy that has the static parts filled in already. I've tried this, and it didn't pay off except with larger maps.) There are a couple of other invocation types (protocol invokes and keyword invokes) that open-code a PIC in the bytecode, with static fields for the caches. There are various strategies like MutableCallSite with GWTs to handle this, but hey you wrote the cookbook on this subject. In Clojure 1.8, the compiler learned "direct linking", which made calls to Clojure functions call a static method. *Previously*: getstatic clojure.lang.Var invokevirtual clojure.lang.Var.getRawRoot() checkcast clojure.lang.IFn push arguments... invokeinterface clojure.lang.IFn.invoke(.....) *With direct linking:* push arguments invokestatic someFunction.invokeStatic(....) Direct linking is not the default except for clojure.core itself comes direct linked, but direct linking traded away dynamicity for performance. (You can't reload things that are direct linked) Since a Var is essentially a box around a volatile field, there are other ways of getting the performance of the invokestatic without losing the dynamicity. Reflection is another use-case, but as Alex mentioned, the general suggestion to users is: don't write reflective code. One of the few compiler flags that exist is: (set! *warn-on-reflection* true) Anyways, thanks for starting this discussion On Wednesday, May 22, 2019 at 9:47:53 PM UTC-4, Alex Miller wrote: > > Hi Rémi! Thanks for all your work on ASM and other JVM stuff over the > years by the way. > > We have of course been poking at indy off and on over the years and there > have been a number of experiments with it. Ghadi Shayban has probably done > the most work on that and he probably has more useful feedback than I would > on the technical aspects of the code. > > Based on where we are in the release cycle right now, I expect that we > probably aren't ready to engage with this today and it might be a couple > months before we are in the meat of the next release and open to it. Some > quick thoughts and questions though... > > 1. As with anything we work on, we don't stuff just because it's possible > to do but because it satisfies some objective that seems worth doing. I > assume the target benefit here is performance, but is that really it? Are > there other benefits? Are there downsides to using indy vs reflection? > > One big thing here is that generally we expect people to remove reflective > calls in performance-sensitive code via type hints (and some people more > thoroughly try to remove all use of reflection). Thus my expectation would > be that the majority of users would experience no improvement or > improvements only in parts of the code that are considered not important > from a performance perspective. If we're adding code that increases > ambiguity (via having multiple invocation paths which might have different > failure modes) without a lot of benefit to users, then that prioritizes > this pretty far down the list for me. > > 2. You mentioned the caller sensitive stuff - can you point at some > resources about what those are? I guess those are calls checking security > policy, etc? > > 3. We did some work in the last release to avoid reflective calls to > module-private methods, by modifying our reflective search to prefer > interfaces or classes that are module accessible. Does module accessibility > affect indy calls as well? > > 4. Clojure has very few compiler / RT flags (and it's most common to use > none of them), and that's pretty intentional. Ideally we would not want a > clojure.compiler.emit-indy flag but maybe you added this just to make the > new work switchable. > > 5. We are somewhat sensitive to trying to make AOT-compiled code work with > later Clojure runtimes as much as possible (we don't guarantee binary > compatibility but we have a very good track record here and try to never > break that expectation). As such, we generally never change signatures in > RT or Reflector or other important interfaces and make only additive > changes. I think this patch is additive in that way, so that's good, but > would want to carefully consider the new publicly accessible methods in > Reflector (as we'd be supporting them forever), like the change in > toAccessibleSuperMethod (which I'm not sure is needed?). > > There are other imo far more interesting possible uses for indy in places > where we care a great deal about performance and those are places where I > would place a lot higher priority. Ghadi, in particular, has investigated > options for lazy-initing vars which could have a noticeable impact on > startup performance while minimizing the effect on subsequent calls like > other approaches that have been tried. Anyways, he can probably chime in on > that more. > > Alex > > > > On Wednesday, May 22, 2019 at 6:16:58 PM UTC-5, Rémi Forax wrote: >> >> Hi all, >> now that Clojure is compatible with java 8, it can use invokedynamic >> where it makes sense, i.e. when the compiler has no information to generate >> directly the call in bytecode, instead of using the reflection API. >> >> In fact, it's a little more complex than that, >> - you can not fully replace all calls to the reflective API to use >> invokedynamic instead, because you have restriction on the methods you can >> call (you can not call a method annotated with @CallerSensitive for >> security reason) and >> - using the method handle API doesn't necessary means that the calls will >> be faster than using the reflection API if the JIT is not able to inline >> the calls. >> >> So the idea of the patch is to always generate invokedynamic at compile >> time but at runtime to use the methodhandle API if there is a good chance >> that the call will be inlined and fallback to call the Reflector API >> otherwise. >> >> Obviously, i've not read how to contribute before writing the patch, so >> the patch is currently available on github >> https://github.com/clojure/clojure/pull/85 >> >> So now that i've read how to contribute, i think the first question to >> ask is: >> does it make sense to allow the Clojure to use invokedynamic ? >> >> regards, >> Rémi >> >> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/bb830fce-9a70-485f-aa23-5ae3f1e53413%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
