Performance problem with invoke dynamic

[Christian Thalinger]

On Aug 10, 2011, at 9:10 PM, Christian Thalinger wrote:

> 
> On Jul 28, 2011, at 7:29 PM, Ola Bini wrote:
> 
>> On 2011-07-28 10.11, Christian Thalinger wrote:
>>> 
>>> On Jul 28, 2011, at 6:10 PM, Ola Bini wrote:
>>> 
>>>>> The bad performance sounds like something is not inlined at all.
>>>>> How are you invoking valueMH?  Via invokedynamic or a direct MH
>>>>> call?
>>>> 
>>>> valueMH is combined with an exactInvoker and then chained together
>>>> with another method handle that calls a method on the result of it
>>>> that returns another methodhandle that is set as the target for the
>>>> call site.
>>> 
>>> Hard to follow :-)
>>> 
>>>> 
>>>> Exactly the same thing that was done in the emitted bytecode,
>>>> actually.
>>> 
>>> Do you have a test case to run?
>>> 
>> 
>> Yes, it's a specific benchmark run (bench/bench_read_lexical.sp). The
>> current master of Seph (12e906d6cac94608a1da565fe748f87421210c97) has
>> the method handle implementation. The
>> c92f2246c09cef9eb9018128e19bfa25593afd2f checkin is the last with the
>> bytecode based version.
> 
> Sorry, I forgot to look into that.
> 
> $ bin/seph --version bench/bench_read_lexical.sp
> Seph 0.0.1-SNAPSHOT [2011-08-10 07:44 -- c92f224]
> variable reading, flat short lex 1.803377237
> variable reading, flat short lex 1.716815071
> variable reading, flat short lex 1.720287124
> variable reading, flat short lex 1.721601836
> variable reading, flat short lex 1.718097445
> 
> $ bin/seph --version bench/bench_read_lexical.sp
> Seph 0.0.1-SNAPSHOT [2011-08-10 07:46 -- 12e906d]
> variable reading, flat short lex 7.131910330
> variable reading, flat short lex 6.479506665
> variable reading, flat short lex 6.427145377
> variable reading, flat short lex 6.472033742
> variable reading, flat short lex 6.481569097
> 
> Current master is even slower:
> 
> $ bin/seph --version bench/bench_read_lexical.sp
> Seph 0.0.1-SNAPSHOT [2011-08-10 07:50 -- 4520464]
> variable reading, flat short lex 8.043511168
> variable reading, flat short lex 7.227023135
> variable reading, flat short lex 7.167401210
> variable reading, flat short lex 7.153554078
> variable reading, flat short lex 7.157729388
> 
> Looking at the compiled methods and the inlinees I found this one (I suppose this the body for flat_short_scope, correct?):
> 
>   1490  167             seph$gen$abstraction$1$flat_short_scope::activationFor (9 bytes)
>                            @ 3   java.lang.invoke.MethodHandle::invokeExact (36 bytes)   inline (hot)
>                              @ 5   java.lang.invoke.MethodHandle::invokeExact (5 bytes)   inline (hot)
>                                @ 1   sun.invoke.util.ValueConversions::identity (2 bytes)   inline (hot)
>                              @ 12   java.lang.invoke.MethodHandle::invokeExact (12 bytes)   inline (hot)
>                                @ 5   java.lang.invoke.MethodHandleImpl::selectAlternative (10 bytes)   inline (hot)
>                              @ 29   java.lang.invoke.MethodHandle::invokeExact (38 bytes)   inline (hot)
>                              @ 29   java.lang.invoke.MethodHandle::invokeExact (11 bytes)   inline (hot)
>                                @ 4   seph.lang.ActivationHelpers::arityErrorMH (45 bytes)   too big
>                                @ 5   java.lang.invoke.MethodHandle::invokeExact (6 bytes)   inline (hot)
>                                  @ 2   seph.lang.compiler.SephCallSite::int_eq (11 bytes)   inline (hot)
>                                @ 14   java.lang.invoke.MethodHandle::invokeExact (12 bytes)   inline (hot)
>                                  @ 5   java.lang.invoke.MethodHandleImpl::selectAlternative (10 bytes)   inline (hot)
>                                @ 31   java.lang.invoke.MethodHandle::invokeExact (38 bytes)   inline (hot)
>                                @ 31   java.lang.invoke.MethodHandle::invokeExact (10 bytes)   inline (hot)
>                                  @ 3   java.lang.invoke.MethodHandle::bindTo (58 bytes)   already compiled into a medium method
>                                  @ 5   java.lang.invoke.MethodHandle::invokeExact (6 bytes)   inline (hot)
>                                    @ 2   seph.lang.compiler.SephCallSite::int_eq (11 bytes)   inline (hot)
>                                  @ 14   java.lang.invoke.MethodHandle::invokeExact (12 bytes)   inline (hot)
>                                    @ 5   java.lang.invoke.MethodHandleImpl::selectAlternative (10 bytes)   inline (hot)
>                                  @ 31   java.lang.invoke.MethodHandle::invokeExact (11 bytes)   inline (hot)
>                                  @ 31   java.lang.invoke.MethodHandle::invokeExact (10 bytes)   inline (hot)
>                                    @ 3   java.lang.invoke.MethodHandle::bindTo (58 bytes)   already compiled into a medium method
>                                    @ 4   seph.lang.ActivationHelpers::arityErrorMH (45 bytes)   inline (hot)
> 
> The problem is:  java.lang.invoke.MethodHandle::bindTo
> 
> That one calls
> 
> java.lang.invoke.BoundMethodHandle::<init> (19 bytes)   already compiled into a big method
> 
> which calls
> 
> java.lang.invoke.MethodHandleNatives::init (0 bytes)   native method
> 
> and there we have our performance bugger.

FYI, this is:

7071693: JSR 292: native method calls slow down method handle constructor execution

I'm not sure if John is already working on that but that's the plan.

-- Christian

> 
> -- Christian
> 
>> 
>> Cheers
>> -- 
>> Ola Bini (http://olabini.com)
>> Ioke - JRuby - ThoughtWorks
>> 
>> "Yields falsehood when quined" yields falsehood when quined.
>> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev