couple questions on method handle combinators
vladimir.x.ivanov at oracle.com
Fri Jun 16 16:46:55 UTC 2017
>>> Would not invalidate the contract of @Stable where the value changes at most once? thereby causes issues for already compiled methods treating that as a constant when other code updates the value via an asType call.
>>> i realize that we break similar rules for updating the LF, but that is a special case where we are in control where as we don’t control who calls MH.asType.
>> It does break @Stable contract, but the JVM doesn't forbid multiple updates to @Stable fields and it's a benign case: keeping a stale value "cached" in compiled code doesn't break asType() caching logic. (For user it looks like the cache is always stale and MH.asType() should be recomputed.)
> Just concerned that biasing to the first caller of asType may push the perf problem around.
It's not necessarily the first caller, but an interim cached value
observed by a compiler once it tries to inline through a generic invoker
on a constant method handle.
> I have a hunch for generic invokers we could cache an asType equivalent result at the call site by stuffing into some stable field of an appendix holder. That’s more work though.
I don't see how caching in appending can improve the situation. Method
handle instance and a method type declared at call site are
complementary and both are required for completing MH.asType()
tranformation and performing generic invocation.
Caching on method handle side favors constant method handles w/ a stable
conversion (singe asType() conversion or multiple conversions w/ the
Caching on call site side (in appendix) favors call sites w/ a single
receiver (MH), which JIT-compiler can't observe as a constant.
More information about the valhalla-dev