RFR: 8370405: C2: mismatched store from MergeStores wrongly scalarized in allocation elimination

[Emanuel Peter]

On Wed, 29 Oct 2025 14:38:23 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> @TobiHartmann gave me this:
>> https://github.com/openjdk/jdk/pull/10901
>> https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2019-May/033803.html
>> I need to study it more, but the idea is that interfaces cannot be trusted, and I could just try to ignore the interface part of the type.
>
> It seems that we don't trust the return type of a method call (look at `TypeFunc::make(ciMethod*)` where we pass `ignore_interfaces` into `TypeTuple::make_domain` and `TypeTuple::make_range`). I don't understand why, though, interfaces are weird.
> 
> However, `tmp` is trusted because it is created with `anewarray`. In `Parse::do_anewarray`, we pass `trusted_interfaces` to `TypeKlassPtr::make`.
> 
> The question is, why are we storing an `Object` into an array of `Enumeration`s?

Right, I follow you all the way up to your question. I would answer like this:

`tmp` knows that its elements (the fields) have type `java/lang/Object (java/util/Enumeration)`, so they must be `Object` of interface `Enumeration`. But the projection from the call does not trust the interface, and so it just knows that it produces an `Object`.

I'll try to strip interface information from both, and see if I get a match that way. Does that sound reasonable?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27997#discussion_r2473586053