On Tue, 2 Dec 2025 20:12:12 GMT, Vladimir Ivanov <[email protected]> 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
