couple questions on method handle combinators

[Vladimir Ivanov]

>>> 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 
same type).

Caching on call site side (in appendix) favors call sites w/ a single 
receiver (MH), which JIT-compiler can't observe as a constant.

Best regards,
Vladimir Ivanov