RFR: 8370914: C2: Reimplement Type::join [v4]

[Vladimir Ivanov]

On Wed, 7 Jan 2026 18:31:17 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> @marc-chevalier Thanks for your reviews. I have addressed and responded to your concerns.
>
>> Thanks @merykitty. I do hope I am not misunderstanding. I would argue that in theory, empty is correct here and null is wrong, but in practice I don't think it matters except for dead code. Can you come up with an example where the difference matters?
> C2 only remembers one Klass, so it makes sense to use LCA(Klass1,Klass2) for meet(Klass1,Klass) in the summarized result, even though it loses information.
> 
> Something that looks like this:
> 
>     Object o;
>     Integer i = (Integer) o;
>     Float f = (Float) f;
>     // C2 may wrongly assume it is dead code here, the reason we do not encounter this is that `GraphKit::gen_checkcast` does the null path and the non-null path separately, so we end up with `Phi(null, non-null Float)` and since the `non-null Float` is dead it is left with `null`

I haven't looked at the PR in details, but I have a data point on `Type::join()` as it is implemented now: C2 tracks interface types these days and while experimenting with JDK-8373633 I tried to filter receiver type and narrow it using a context interface (think of `(I1 & I2 & I3 & I4).filter(I1) == (I1 & I2)` where `I2 <: I1` and `I3`/`I4` are unrelated. But the current implementation doesn't have any effect and leaves the original type intact (`(I1 & I2 & I3 & I4).filter(I1) == (I1 & I2 & I3 & I4)`). As a result of `Type::join()` and `Type::dual()` decoupling we can improve `Type::join` and make results more accurate for oop types (both interfaces and classes). I'm glad to see we are moving in that direction. Good work, @merykitty.

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

PR Comment: https://git.openjdk.org/jdk/pull/28051#issuecomment-3720520666