On Mon, May 23, 2011 at 6:17 PM, Rémi Forax <fo...@univ-mlv.fr> wrote: > On 05/24/2011 12:44 AM, Tom Rodriguez wrote: >> I haven't been following 292 that closely but it used to be a piece of code >> that did precisely that. >> >> + private Object invoke_L0() throws Throwable { >> + if ((boolean) test.invokeExact()) >> + return target.invokeExact(); >> + return fallback.invokeExact(); >> + } >> >> It looks like it was reworked at some point to use selectAlternative but the >> optimizer was never updated to deal with it properly. It's not particularly >> hard, we just need to generate code like we would for a bimorphic call site. >> The current code expects to either get a constant or something else and >> doesn't inline if it's something else. In this case we have a Phi of two >> constants which we just need to split.
I'll give it a shot. I'll put together a benchmark that produces "effectively monomorphic" calls at the invokedynamic call site, but which uses an intermediate hand-written piece of Java code (that ends up polymorphic) in place of GWT. Obviously GWT should not fail this badly in final release, but if this works it could mean many, many other patterns will too. And it will definitively answer the question about whether such a case inlines in current logic. > The main problem of writing your own variant is that you will have to > write 256 * (number_of_primitive_type + 1) variants. > The main idea of GWT (and all other method handle combiners) is that > they provide a way to get such polymorphic variant > without coding all combinations. > > The benefit is also that these combiners are known by the VM that can > provide > dedicated path that are more efficient, > by ex, the arguments of GWT is pushed only once and used by the test > *and* the target (or fallback) > or better guarantee about how trees of combiners are inlined. I am not currently specializing any call paths for primitives, but that will come soon. For experiment's sake, I only need to provide one such GWT replacement to test fib (no block passed, single IRubyObject argument) and one more for the dispatch bench (no block, no args). We'll see how it looks. - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev