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/75e34ba0-995d-4e70-9fca-b031d844ec1a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
