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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
