On May 23, 2011, at 5:13 PM, Charles Oliver Nutter wrote:
> 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.
You can also just wait for a fix. I've started writing the logic for it and
just need to duplicate the guard. We should be able to have this fixed for
JDK7.
tom
>
>> 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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
