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

[Chen Liang]

On Tue, 2 Dec 2025 20:12:12 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> No. The avoidance of cache update simply trims down the generated code by throwing away the meaningless cache update.
>> 
>> The access to cache is already safeguarded by `constant == MethodHandleImpl.CONSTANT_YES`. I should have moved `var cache = adaptedMh;` into the if block of `constant == CONSTANT_YES`.
>
> I still find it confusing, especially tri-state logic part.
> 
> For background, `isCompileConstant` was introduced as part of LF sharing effort to get rid of Java-level profiling in optimized code. The pattern is was designed for was:
> 
>   if (isCompileConstant(...)) {
>     return ...;
>   } else {
>     ... // do some extra work (either in interpreter, C1, or not-fully-optimized version in C2) 
>   }
> 
> 
> In this patch, you don't follow that pattern and aadd new state (`CONSTANT_PENDING`) to distinguish interpreter/C1 from C2. What's the motivation? Why do you want to avoid cache updates coming from C2-generated code?

I am assuming that if C2 determines this `vh` is not a constant, we can drop it. Is that a right way to move along, or could C2 transition from "not a constant" to "is a constant" during the phases?

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

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