On Fri, Aug 12, 2011 at 1:18 PM, Tom Rodriguez <tom.rodrig...@oracle.com> wrote: > I wonder if we need to be slightly more selective than this. Most method > handle chains are relatively small and we shouldn't be penalized for that but > they could be arbitrarily large too. Worst case they just expand into a > bunch of call sites I guess so maybe it's not that bad. Maybe we need an > alternate metric for this, like number of call sites in the method handle > adapter?
Well, let me play devil's advocate here: why not just discount MH chains completely? I've been treating method handles as a way to communicate intent directly to the JVM. Method handles are like JVM IR...and I'd like to see them unhindered by limits designed around JVM bytecode. What's the problem with having them discounted en masse? > This wouldn't be so bad if method handle chains could be compiled separately. > I suspect we're going to have to support that eventually. Doing that would > make the performance cliff much smaller I think. This probably needs to happen for client mode at the very least. We probably can't get client to inline invokedynamic, but if it at least dispatches to a compiled MH chain it would be a lot better than what it does now (which I think is just execute the chain of handles as-is...usually very slow). - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev