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

[Jorn Vernee]

On Wed, 3 Dec 2025 04:10:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Sorry, I still don't understand how it is intended to work. Why does `MethodHandleImpl.isCompileConstant(vh) == true` imply that the cached value is compatible with the constant `vh`?
>> 
>> 
>> // Keep capturing - vh may suddenly get promoted to a constant by C2
>> 
>> 
>> Capturing happens outside compiler thread. It is not affected by C2 (except when it completely prunes the whole block).
>> 
>> So, either any captured adaptation is valid/compatible or there's a concurrency issue when C2 kicks in and there's a concurrent cache update happening with incompatible version.
>
>> any captured adaptation is valid/compatible
> 
> Yes, if `vh` is a constant, any captured adaptation from `vh.getMethodHandle(mode).asType(symbolicMethodTypeInvoker)` is valid/compatible.
> 
> For thread safety, MethodHandle supports safe publication, so I think we are fine publishing this way.

Looking at this, I'm not sure we can assume that we only see one mode and type when the VH is constant. There seems to be a lot of non-local reasoning involved.

For example, you could have a var handle invoker created with `MethodHandless::varHandleInvoker`, which is cached, so the `AccessDescriptor` can be shared among many different use sites. For an individual use-site, the receiver VH may well be a constant, but that doesn't mean that the cache isn't polluted by the var handle from another use site, as far as I can tell.

The thread safety issue comes from a C2 thread racing to read the `lastAdaption` cache vs another Java thread writing to the cache. AFAICS, this race is still possible even when `vh` is a compile time constant.

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

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