Performance problem with invoke dynamic

[Christian Thalinger]

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.

-- 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