My bad - I assumed this didn't work anyway for non-dynamic vars, but it
does indeed work. So the only difference with dynamic vars is that you can
use thread-local bindings?
On 17 June 2013 16:25, Cedric Greevey <cgree...@gmail.com> wrote:
> Hot function replace by redefn'ing it at the REPL wouldn't work anymore.
> Such an optimization would have to be a deployment-time option rather than
> forced.
>
>
> On Mon, Jun 17, 2013 at 12:05 AM, Colin Fleming <
> colin.mailingl...@gmail.com> wrote:
>
>> 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.
>>
>>
>>
>
> --
> --
> 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.
>
>
>
--
--
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.
