RFR: 8346836: C2: Introduce a way to verify the correctness of ConstraintCastNodes at runtime

Quan Anh Mai qamai at openjdk.org
Wed Jan 8 07:50:44 UTC 2025


On Wed, 8 Jan 2025 07:24:18 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Hi,
>> 
>> This patch adds a develop flag `VerifyConstraintCasts`, which will verify the correctness of `CastIINode`s and `CastLLNode`s at runtime and crash the VM if the dynamic value lies outside the type value range.
>> 
>> Please take a look, thanks a lot.
>
> Ah, I actually see that you have some examples. So you plan on introducing this flag first, and only then fixing the issues? But does it fail with a simple `java --version`? Or an empty `main` method, maybe with `-Xcomp`?

@eme64 Thanks for looking at this

The context is that while reviewing #22666 I came to the conclusion that our handling of `depends_only_on_test` is broken. I have added a comment explaining my understanding and concerns there. In principle, before the execution, a `DivINode` is the same as a `CastIINode` which limits the value range of the divisor to `!= 0`. As a result, there should not be any difference in the way we handle the movements of these nodes. This leads me to the conclusion that `CastIINode`s may also be wired to the wrong control input, the reason we have not caught them is that unlike a division complaining loudly, a `CastIINode` will silently accept incorrect input values. This motivates me to make this patch.

> If I remember correctly, we relax/widen the Cast ranges somewhere later in optimizations, so that different CastII etc can common. Probably happens after loop-opts. So the ranges usually go from `[1..10]` -> `[0, max]` or `[-1 .. 1]` -> `int`.

You are right, it is in `ConstraintCastNode::widen_type` for which I will disable that widening in the presence of `VerifyConstraintCasts`.

> So you plan on introducing this flag first, and only then fixing the issues?

There are several failures in tier 1 alone, and this flag is not enabled by default or in the pipeline, so I think incorporating it first would be preferable, then after fixing all the issues we can add it to the stress options.

> But does it fail with a simple `java --version`? Or an empty `main` method, maybe with `-Xcomp`?

No it does not fail with `--version` or with an empty `main` method with and without `-Xcomp`.

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

PR Comment: https://git.openjdk.org/jdk/pull/22880#issuecomment-2576960560


More information about the hotspot-compiler-dev mailing list