RFR: 8372266: Relax store matchers in compiler/escapeAnalysis/TestRematerializeObjects.java test

[Emanuel Peter]

On Mon, 24 Nov 2025 16:41:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> But how do you now know that the `StoreL` is really coming from the merged `StoreI`, and that it is not some other unrelated `StoreL`? The info that it comes from an int-array is relevant here `int[int:4]`, don't you think?
>> 
>> What about all the other MergeStores IR tests? For consistency you would now have to adjust those too, but I hope you don't do that ;)
>> `./test/hotspot/jtreg/compiler/c2/TestMergeStores.java`
>> 
>> The motivation seems to be that printing of store nodes was a bit different in JDK25. But then we just have to adjust the matching a bit, maybe weaken the IR rule for backports. But I'd prefer not to weaken the IR rule on mainline.
>> 
>> What do you think?
>
>> But how do you now know that the `StoreL` is really coming from the merged `StoreI`, and that it is not some other unrelated `StoreL`?
> 
> Well, because there are no `long` stores in Java code at all, so whatever that `StoreL` came from, it is JIT-generated? So then the IR test verifies that whatever happens with EA and MergeStores makes sure the store either goes away, or some merged store remains. I personally dislike overly-specific tests that rely on particulars of optimization sequencing or some such, and would rather have a test that checks the generic final state, without over-specificity.
> 
>> The motivation seems to be that printing of store nodes was a bit different in JDK25. But then we just have to adjust the matching a bit, maybe weaken the IR rule for backports. But I'd prefer not to weaken the IR rule on mainline.
> 
> Yes. I mean, there is a tradeoff somewhere here: either mainline relaxes the test and then JDK 25 matches the test version, or JDK 25 diverges. We _usually_ try to avoid divergences, if we can, because they continuously bite us. If your preference about not relaxing the mainline version is strong, then I can yield and diverge JDK 25. It would likely be literally the same fix I have here.

@shipilev Thanks for your response. I'm trying to think through best practices below.

As far as I see, this change is motivated by a backport to JDK25, where either the printing of the MergeStore'd StoreL looks different, or MergeStores just does not happen. Since there is a functional difference between JDK25 and JDK26, it is not surprising that we need to adjust the IR rules.

> Well, because there are no long stores in Java code at all, so whatever that StoreL came from, it is JIT-generated?

Are we sure there cannot be another `StoreL` coming from somewhere else than the Java code?

@shipilev The IR rule failed on JDK25, and must have printed the `StoreL`, right? How does that line look like? Maybe it is a really minor difference, and we just adjust the IR rules for the backport ever so slightly.

> We usually try to avoid divergences, if we can, because they continuously bite us.

I understand that issue, yes. A divergence on backporting that would bite us a little less in terms of test failures in older JDKs: just relax/remove IR rules, and rely on the functional part of the test. There is a risk that the reproducer would not reproduce the issue any more because optimizations are reordered. The failing IR rule would detect that the test is now optimized differently, which is a hint that things are not tested the same way, and probably the original but would not be reproduced any more. The test is likely ineffective now. But it would also be a bit unclear how to then address that without immense effort (to write a different test).

But I do think that mainline and going to newer JDK should have more specific IR rules. Should such an IR rule fail for some reason because of new VM changes, then it is probably worth looking into that test. The test is likely to trigger some related behavior. Worst case we can at that point relax/remove the IR rule.

> I personally dislike overly-specific tests that rely on particulars of optimization sequencing

Right, that is a bit of a risk. I could see a scenario where one is trying to reorder some optimizations, and then suddenly hundreds of IR rules fail because they were too specific. That would be annoying.

Maybe @shipilev is right here: maybe we should not use IR rules in regression tests where a very specific ordering of optimizations was required. However, the IR rules would give us a hint that the regression test is still likely to test what we think it tests, so it would increase our confidence. But the question is what one is supposed to do when the IR rule fails...

Maybe IR rules should only be used for relatively "simple" tests, that only check that a single optimization happened, and not a very specific order/interaction of optimizations?

These are just my thoughts. I have very little experience with backports, so I'd really love to hear some general guidance on this from @vnkozlov . Maybe @chhagedorn also has an idea on the use of IR rules for regression tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/28437#issuecomment-3574041572