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.
