Inlining heuristic trouble

[Rémi Forax]

On 06/21/2011 05:43 AM, Mark Roos wrote:
>
> John Rose stated
>
>         See section 5, "Case Study: Inline Caches and invokedynamic".
>
> Thanks John, I have read that several times and it is very helpful
>
>        A small (non-megamorphic) polymorphic cache can be represented 
> as a cascade or decision tree of GWT                 combinators, 
> probably with a control block of some sort that can rebalance from 
> time to time.
>
> This is interesting but it seems that the jvm is in a better place to 
> collect the information and
> reorder the paths.  I would have to add counters and some way to 
> remember the MHs ( no reflection yet)
> which seems like a lot of book keeping.  My current approach is to 
> keep track of the total methods in use
> and then invalidate the entire set of call sites ( cache flush ). 
>  This matches the ST I am using as
> a reference and seems to keep the working set and depths under control.
>
>        A megamorphic call site can be represented using the class 
> pattern of a two-step dispatch plus indirect         function call.
>
> How about the case where the site is megamorphic in classes but has 
> only one or two implementations? 

If the hierarchy is frozen, you can use instanceof (or 
Class.isInstanceof) instead of
a getClass() == as guard test.

But if it's open, you need a way to know when a class is loaded and 
currently
there is no "official" way to get this information.


>  I'll study the foldArguments to see if I can see how to do this

The pattern is foldArgument + an invoker.

>
> thanks
>
> mark

Rémi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110621/35c93a7e/attachment.html