RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3]

[Chen Liang]

On Tue, 2 Dec 2025 02:00:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Indeed, I should move the adaptedMh read into `constant == MethodHandleImpl.CONSTANT_YES` block.
>> 
>> `constant != MethodHandleImpl.CONSTANT_NO` prevents capturing any further if the VH is known non-constant; we keep this branch in constant case in case the adapted MH is not ready when we know the VH is constant.
>
> I still have a hard time reasoning about state transitions of the cache.
> 
> 1) Why do you limit successful cache read (`cache != null`) to constant `vh` case (`constant == MethodHandleImpl.CONSTANT_YES`)?
> 
> 2) Why do you avoid cache update in non-constant case (`constant != MethodHandleImpl.CONSTANT_NO`)? What happens if it runs compiled `adaptedMethodHandle` method?

So an `AccessDescriptor` is created for each sigpoly VH site in the source code. Usually it is `VH.operation()`, but it is legal to use a non-constant VarHandle variable and call an operation on that. If `constant == MethodHandleImpl.CONSTANT_NO`, we are sure that we have the non-constant case, so we cannot trust that cached method handle, and there is no point further caching. We can only read that previous MH conversion cache if `constant == MethodHandleImpl.CONSTANT_YES` because this means our cache is always correct.

>> No. The old code worked because it implicitly depended on the backdoor path present in the now removed `GUARD_METHOD_TEMPLATE_V` in `VarHandleGuardMethodGenerator`. If this test is intact, now its IR compiles to doing something in adaptedMethodHandle and calling a MethodHandle.  Not sure why it doesn't inline through that MethodHandle.
>
> Ok, so you eliminated a fast-path check for void-return case and now JIT can't fully optimize it anymore. Do I get it right? Since this particular bytecode shape is exposed through public API, I don't see why user code can't step on it.

JIT can fully optimize it in JMH benchmarks. I don't know why the IR in this test can't optimize it - I couldn't reproduce this CI failure locally on my linux-x64-debug profile, but this modified test passes on CI.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579352226
PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579353722