megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 09:17 PM, Jochen Theodorou wrote:
> Mark,
>
> can you explain what you mean with "depth"? if you mean the depth of a
> call path, then more than 20 is indeed more rare, but it depends on the
> circumstances. In Grails for example (web frame work in the Groovy
> world) a depth of 20 should be a much more commen case, simply because
> there is a framework around it, that already has the usual call path
> depth. As for seeing depth of the call path from the point the blokc is
> called to the point the iterator method is called, that is usually a
> quite short path of maybe depth <3. But maybe you something else by depth.

No, I think here depth means depth of the guardWithTest,
i.e. number of different receiver types.

> Anyway, the goal is inlining and inlining is something you get with a
> more or less constant call site. Invalidating it means to remove that
> attribute of being constant, the counter will start new. That's why you
> may be able to remove old cases from your call site structure that way,
> but for inlining it does not help at all. Well... I am sure Remi will
> correct me should I tell wrong things here ;)

adding a new GWT to a tree of GWTs or trashing the tree of GWTs
and use only one GWT is equivalent if the tree of GWTs is already JITed,
because the generated code will be deoptimized anyway.

A big tree of GWTs is really bad because it's a linear search so it's slow,
moreover a code with to many nodes will not be inlined at all.

Also trashing a tree of GWTs is not only a way remove path that
has not used but also a way to re-order a tree of GWTs.

> bye Jochen

cheers,
Rémi