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