Re: Why is LambdaMetafactory 10% slower than a static MethodHandle but 80% faster than a non-static MethodHandle?

[Vladimir Ivanov]

In staticMethodHandle target method is statically known [1], but in 
case of lambdaMetafactory [2] compiler has to rely on profiling info 
to devirtualize Function::apply(). The latter requires exact type 
check on the receiver at runtime and that explains the difference you 
are seeing. 
Ah, so it's unlikely that a future JDK version could eliminate
that 10% difference between LambdaMetafactory and staticMethodHandle?

Yes, that's correct.

But comparing that with nonStaticMethodHandle is not fair: there's no 
inlining happening there. 
Agreed.

However, for java framework developers,
it would be really useful to have inlining for non-static method handles 
too (see Charles's thread),
because - unlike JVM language developers - we can't use static method 
handles and don't want to use code generation.

Though inlining is desireable, benefits quickly diminish with the number 
of cases. (For example, C2 only inlines up to 2 targets and only in case 
of bimorphic call site - only 2 receiver classes have been ever seen.)

With non-constant method handles it's even worse: just by looking at the 
call site we can't say anything about what will be called (and how!) 
except its signature (reified as MethodType instance at runtime).

There were some discussions about implementing value profiling for MH 
invokers (invoke()/invokeExact()), but it can only benefit cases where 
the same MethodHandle instance is used always/most of the time.

I seriously doubt it scales well to the use cases you have in mind (like 
JPA/JAXB).

Best regards,
Vladimir Ivanov

For example, if a JPA or JAXB implementation did use a static fields,
the code to call methods on a domain hierarchy of classes would look 
like this:

public final class MyAccessors {

     private static final MethodHandle handle1; // Person.getName()
     private static final MethodHandle handle2; // Person.getAge()
     private static final MethodHandle handle3; // Company.getName()
     private static final MethodHandle handle4; // Company.getAddress()
     private static final MethodHandle handle5; // ...
     private static final MethodHandle handle6;
     private static final MethodHandle handle7;
     private static final MethodHandle handle8;
     private static final MethodHandle handle9;
     ...
     private static final MethodHandle handle1000;

}

And furthermore, it would break down with domain hierarchies
that have more than 1000 getters/setters.


With kind regards,
Geoffrey De Smet

On 19/02/18 13:00, Vladimir Ivanov wrote:
Geoffrey,

In both staticMethodHandle & lambdaMetafactory Dog::getName is 
inlined, but using different mechanisms.

In staticMethodHandle target method is statically known [1], but in 
case of lambdaMetafactory [2] compiler has to rely on profiling info 
to devirtualize Function::apply(). The latter requires exact type 
check on the receiver at runtime and that explains the difference you 
are seeing.

But comparing that with nonStaticMethodHandle is not fair: there's no 
inlining happening there.

If you want a fair comparison, then you have to measure with polluted 
profile so no inlining happens. In that case [3] non-static 
MethodHandles are on par (or even slightly faster):

LMF._4_lmf_fs  avgt   10  20.020 ± 0.635  ns/op
LMF._4_lmf_mhs avgt   10  18.360 ± 0.181  ns/op

(scores for 3 invocations in a row.)

Best regards,
Vladimir Ivanov

[1] 715  126    b        org.lmf.LMF::_1_staticMethodHandle (11 bytes)
...
    @ 37 java.lang.invoke.DirectMethodHandle$Holder::invokeVirtual (14 
bytes)   force inline by annotation
      @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 
bytes)   force inline by annotation
      @ 10   org.lmf.LMF$Dog::getName (5 bytes)   accessor




[2] 678  117    b        org.lmf.LMF::_2_lambdaMetafactory (14 bytes)
@ 8   org.lmf.LMF$$Lambda$37/552160541::apply (8 bytes)   inline (hot)
 \-> TypeProfile (6700/6700 counts) = org/lmf/LMF$$Lambda$37
  @ 4   org.lmf.LMF$Dog::getName (5 bytes)   accessor


[3] http://cr.openjdk.java.net/~vlivanov/misc/LMF.java

    static Function make() throws Throwable {
        CallSite site = LambdaMetafactory.metafactory(LOOKUP,
                "apply",
                MethodType.methodType(Function.class),
                MethodType.methodType(Object.class, Object.class),
                LOOKUP.findVirtual(Dog.class, "getName", 
MethodType.methodType(String.class)),
                MethodType.methodType(String.class, Dog.class));
        return (Function) site.getTarget().invokeExact();
    }

    private Function[] fs = new Function[] {
        make(), make(), make()
    };

    private MethodHandle[] mhs = new MethodHandle[] {
        nonStaticMethodHandle,
        nonStaticMethodHandle,
        nonStaticMethodHandle
    };

    @Benchmark
    public Object _4_lmf_fs() throws Throwable {
        Object r = null;
        for (Function f : fs {
            r = f.apply(dogObject);
        }
        return r;
    }

    @Benchmark
    public Object _4_lmf_mh() throws Throwable {
        Object r = null;
        for (MethodHandle mh : mhs) {
            r = mh.invokeExact(dogObject);
        }
        return r;
    }

On 2/19/18 1:42 PM, Geoffrey De Smet wrote:
Hi guys,

I ran the following JMH benchmark on JDK 9 and JDK 8.
Source code and detailed results below.

Benchmark on JDK 9        Score
staticMethodHandle          2.770
lambdaMetafactory          3.052    // 10% slower
nonStaticMethodHandle   5.250    // 90% slower

Why is LambdaMetafactory 10% slower than a static MethodHandle
but 80% faster than a non-static MethodHandle?


Source code (copy paste ready)
====================

import java.lang.invoke.CallSite;
import java.lang.invoke.LambdaMetafactory;
import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;
import java.util.concurrent.TimeUnit;
import java.util.function.Function;

import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Fork;
import org.openjdk.jmh.annotations.Measurement;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.annotations.Warmup;

//Benchmark on JDK 9     Mode  Cnt  Score   Error  Units
//staticMethodHandle     avgt   30  2.770 ± 0.023  ns/op // Baseline
//lambdaMetafactory      avgt   30  3.052 ± 0.004  ns/op // 10% slower
//nonStaticMethodHandle  avgt   30  5.250 ± 0.137  ns/op // 90% slower

//Benchmark on JDK 8     Mode  Cnt  Score   Error  Units
//staticMethodHandle     avgt   30  2.772 ± 0.022  ns/op // Baseline
//lambdaMetafactory      avgt   30  3.060 ± 0.007  ns/op // 10% slower
//nonStaticMethodHandle  avgt   30  5.037 ± 0.022  ns/op // 81% slower

@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(3)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Thread)
public class LamdaMetafactoryWeirdPerformance {

     // 
************************************************************************
     // Set up of the 3 approaches.
     // 
************************************************************************

     // Unusable for Java framework developers. Only usable by JVM 
language developers. Baseline.
     private static final MethodHandle staticMethodHandle;

     // Usuable for Java framework developers. 30% slower
     private final Function lambdaMetafactoryFunction;

     // Usuable for Java framework developers. 100% slower
     private final MethodHandle nonStaticMethodHandle;

     static {
         // Static MethodHandle setup
         try {
             staticMethodHandle = MethodHandles.lookup()
                     .findVirtual(Dog.class, "getName", 
MethodType.methodType(String.class))
                     .asType(MethodType.methodType(Object.class, 
Object.class));
         } catch (NoSuchMethodException | IllegalAccessException e) {
             throw new IllegalStateException(e);
         }
     }

     public LamdaMetafactoryWeirdPerformance() {
         try {
             MethodHandles.Lookup lookup = MethodHandles.lookup();

             // LambdaMetafactory setup
             CallSite site = LambdaMetafactory.metafactory(lookup,
                     "apply",
                     MethodType.methodType(Function.class),
                     MethodType.methodType(Object.class, Object.class),
                     lookup.findVirtual(Dog.class, "getName", 
MethodType.methodType(String.class)),
                     MethodType.methodType(String.class, Dog.class));
             lambdaMetafactoryFunction = (Function) 
site.getTarget().invokeExact();

             // Non-static MethodHandle setup
             nonStaticMethodHandle = lookup
                     .findVirtual(Dog.class, "getName", 
MethodType.methodType(String.class))
                     .asType(MethodType.methodType(Object.class, 
Object.class));
         } catch (Throwable e) {
             throw new IllegalStateException(e);
         }
     }

     // 
************************************************************************
     // Benchmark
     // 
************************************************************************

     private Object dogObject = new Dog("Fido");


     @Benchmark
     public Object _1_staticMethodHandle() throws Throwable {
         return staticMethodHandle.invokeExact(dogObject);
     }

     @Benchmark
     public Object _2_lambdaMetafactory() {
         return lambdaMetafactoryFunction.apply(dogObject);
     }

     @Benchmark
     public Object _3_nonStaticMethodHandle() throws Throwable {
         return nonStaticMethodHandle.invokeExact(dogObject);
     }

     private static class Dog {
         private String name;

         public Dog(String name) {
             this.name = name;
         }

         public String getName() {
             return name;
         }

     }

}


With kind regards,
Geoffrey De Smet

_______________________________________________
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