Interesting, thanks for the pointer. I'll read up a little more on the
technicalities of invokedynamic. Can anyone answer the other question about
why, in the 95% case of non-dynamic vars we still need the var indirection?
It seems like caching the IFn (or even the concrete derived class, since
we're assuming it won't change) would be a huge performance win.
Cheers,
Colin
On 17 June 2013 14:38, Ben Mabey <b...@benmabey.com> wrote:
> On Sun Jun 16 16:51:41 2013, Colin Fleming wrote:
>
>> Hi all,
>>
>> This is slightly tangential to the current discussion on unnecessary
>> type checks - does anyone have any good links to information about the
>> JIT optimisations performed by Hotspot? One question I've been
>> interested in recently is how well it can optimise Clojure function
>> calls. The compiled classes of Clojure fns cache references to the
>> vars of functions that they call with the bytecode equivalent of:
>>
>> private static Var const__0 = RT.var("namespace", "var")
>>
>> and the calls are like:
>>
>> ((IFn) const__0.getRawRoot()).invoke(**args)
>>
>> for non-dynamic bindings (the default from 1.3+ IIRC), and
>>
>> ((IFn) const__0.get()).invoke(args)
>>
>> Does anyone know if Hotspot is capable of optimising these calls?
>> Another question would be why in the non-dynamic case the IFn
>> contained in the var is not cached since the root binding should never
>> be modified. Is this just to support alter-var-root, or is it to
>> support declare'd vars which may not contain an IFn at compilation
>> time? I would imagine that Hotspot would optimise this case much
>> better since this mimics what objects in Java tend to do.
>>
>> Cheers,
>> Colin
>>
>> --
>> --
>> 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+unsubscribe@**googlegroups.com<clojure%2bunsubscr...@googlegroups.com>
>> For more options, visit this group at
>> http://groups.google.com/**group/clojure?hl=en<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+unsubscribe@**googlegroups.com<clojure%2bunsubscr...@googlegroups.com>
>> .
>> For more options, visit
>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>> .
>>
>>
>>
> Fogus touched on this issue in this post about invoke dynamic:
>
> http://blog.fogus.me/2011/10/**14/why-clojure-doesnt-need-**
> invokedynamic-but-it-might-be-**nice/<http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/>
>
> From the post:
>
> "To provide this level of flexibility Clojure establishes a level of
> indirection.3 Specifically, all function lookups through a Var occur, at
> the lowest level, through an atomic volatile.4 This happens every time that
> a function bound using the def/defn special forms is called. This
> indirection is not amenable to HotSpot optimizations.
>
> This is a great place for invokedynamic, especially during production
> scenarios where the root value of Vars remain stable. That is,
> invokedynamic would eliminate the volatile lookup on every call and likely
> lead to HotSpot inlining."
>
>
> -Ben
>
>
> --
> --
> 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+unsubscribe@**googlegroups.com<clojure%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en<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+unsubscribe@**googlegroups.com<clojure%2bunsubscr...@googlegroups.com>
> .
> For more options, visit
> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> .
>
>
>
--
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
