On Aug 4, 11:27 am, Boris Mizhen - 迷阵 <bo...@boriska.com> wrote:
> > Second, the caching is a barrier to escape analysis. Since rather than
> > seeing a freshly-boxed integer 42, which can be optimized away, the
> > compiler sees a branch into cache lookup code that returns something
> > the compiler cannot know, thus it can't get rid of the lookup.
>
> Rich, please pardon my ignorance, but we are talking about parameter
> passing, so they have already escaped by definition?
>
> Or are you talking about inner-loop-kind-of operations?
>
A number might be boxed, passed into a nested call, passed to
another... then used in a calculation and never escape. The optimizer
could (potentially) see that whole chain and avoid the box throughout
the call sequence, inline it etc.
But none of that matters to the cache case, because the cache-using
code says "either use the Integer value found when looking up 42 in
this hash table, or, if missing, the new Integer(42)". It can't
unconditionally replace that with the primitive 42, since it has no
idea what Integer is in the hashtable at key 42 (i.e. it doesn't know
that the value at that key _is_ Integer(42)). So it can't remove the
box, nor avoid the lookup.
Rich
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
