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@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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
