On Wed, Dec 1, 2010 at 8:20 AM, Rémi Forax <[email protected]> wrote:
>> i = 1234
>> p = proc {|i| puts i }
>
> You mean
> p = proc {|anything_but_i| puts i }
Er, yeah :)
>> objs = ['foo', [:a, :b], {:a => :b}]
>>
>> for j in 1..1000 do
>> objs[j % 3].each&p
>> end
...
>
> 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.
Yes, but that's the point. EA is too fragile since it can't see
through megamorphic (or N > 2 polymorphic) call sites of any kind. So
you can't just say "if it can be stack allocated, it doesn't escape"
because that's now how Hotspot sees it.
> yes, inlining is the mother of a bunch of optimizations
> but as you know even in a dynamic language
> megamorphic callsites are rare.
Sure...I'm just making a point :)
> 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).
Yes, I've wondered that as well. Having a tree of GWT should simulate
a PIC, and rebalancing the PIC would simply be reordering the GWTs. In
theory, if Hotspot treats each GWT as its own call site in the graph,
they should all inline. One of these days I'll get back to indyfying
JRuby...but maybe you can come up with a contrived example to try it
out.
- Charlie
--
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.
