On 12/01/2010 02:54 PM, Charles Oliver Nutter wrote:
On Wed, Dec 1, 2010 at 4:36 AM, Rémi Forax<[email protected]> wrote:
If you can stack-allocate a closure. Your closure don't escape.
So your runtime should be able to know if a closure escape or not
and if it doesn't escape, you can generate the bytecode from
where you create the closure to where you use it.
No, that's not correct. A simple case: All calls on a given thread
would still use the same stack-allocated closure, but Hotspot only
inlines up to two target methods at a given call site. So...
i = 1234
p = proc {|i| puts i }
You mean
p = proc {|anything_but_i| puts i }
objs = ['foo', [:a, :b], {:a => :b}]
for j in 1..1000 do
objs[j % 3].each&p
end
In this case, there's three different target impls of "each" at the
same call site that will receive the same closure. All will be on the
same thread and could use the same stack-allocated object, but
according to Hotspot's EA, the closure object would not be eligible
for elimination since it won't inline three targets at a given call
site.
Here objs[..].each is megamorphic. That's the problem.
It's not related to closure or EA.
So yes, in your example, you have to heap allocate p,
but you will have to do it once.
Of course this is a trivialized example, but the point is that EA is
still very fragile, and any one path that receives an object but isn't
inlined will prevent it, where stack allocation would work fine.
- Charlie
yes, inlining is the mother of a bunch of optimizations
but as you know even in a dynamic language
megamorphic callsites are rare.
BTW, I wonder if instead of using invokevirtual when calling each
you use invokedynamic and produce a tree of guardWithtest.
In my own abstract hotspot mental model, the megamorphic callsite
should be inlineable (at least in this example).
Rémi
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
