couple questions on method handle combinators

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Wed Jun 14 17:04:34 UTC 2017


>> The is due to the call to invoke, which performs an asType
>> transformation and thus the receiver is not constant.
>
> So it's effectively constant but the compiler can't see it? I had a
> patch that added profiling of that receiver value. It didn't seem to
> show any benefit at the time. I wonder it would make sense to experiment
> with something similar again.

There's a simpler solution: since MH.asType() already uses 1-element 
cache [1], it should be enough to just mark MH.asTypeCache as @Stable.

The problem with MH.asType() is more general: 1-element caching scheme 
doesn't scale for multiple MH.invoke() call sites with different 
signatures. Every cache miss requires a new method handle to be created.

Best regards,
Vladimir Ivanov

[1] jdk/src/java.base/share/classes/java/lang/invoke/MethodHandle.java:
...
public abstract class MethodHandle {
...
     /*private*/ MethodHandle asTypeCache;
...
     public MethodHandle asType(MethodType newType) {
         // Fast path alternative to a heavyweight {@code asType} call.
         // Return 'this' if the conversion will be a no-op.
         if (newType == type) {
             return this;
         }
         // Return 'this.asTypeCache' if the conversion is already memoized.
         MethodHandle atc = asTypeCached(newType);
         if (atc != null) {
             return atc;
         }
         return asTypeUncached(newType);
     }

     private MethodHandle asTypeCached(MethodType newType) {
         MethodHandle atc = asTypeCache;
         if (atc != null && newType == atc.type) {
             return atc;
         }
         return null;
     }


More information about the valhalla-dev mailing list