On Wed, 3 Dec 2025 04:10:05 GMT, Chen Liang <[email protected]> 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
