On Jun 20, 2011, at 3:06 PM, Charles Oliver Nutter wrote: > ...and as a result the inlining heuristics would behave the same as if we'd > written the above in Java by hand. Interesting to note: currently, the first > cached result ends up further down the list. In other words, it's a PIC that > does not rebalance based on frequency. A PIC that rebalances might work > better in a heuristic where more weight is placed on the success paths. > > Am I assuming too much?
No, this is a reasonable assumption. The thesis of the VMIL paper is that bytecodes and combinators are complementary program representations. The implication (for the present conversation) is that the sorts of fancy tricks that apply to bytecodes also apply to method handles. Hotspot has invocation counters on all methods. When you make an indirect MH, you in effect make an ad hoc method (without the overhead of loading a class). Many (or even all) such methods will eventually have their own invocation counters, until (as is the case with bytecoded methods) they get optimized into a final format. At a minimum, for GWT, we need to leave a trail of breadcrumbs on the "fallback" path of the GWT that lets the optimizer know how many times the fallback has been run. As people have already observed, putting statistics only on the bytecodes of selectAlternative, while somewhat useful, is subject to profile pollution. (Profile pollution is a risk whenever a profiled component is used many times by unrelated clients.) This sort of thing is not in JDK7 "dot oh". Applying all the Hotspot tricks to MHs (and inventing new ones) will be a delightful exercise... -- John P.S. And the rebalancing trick is classic and reasonable, though it hasn't been worth implementing in Hotspot. I hope to see someone render that pattern with a subclass of MutableCallSite, on top of 292. _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
