RFR: 8346280: C2: implement late barrier elision for G1 [v4]

[Amit Kumar]

On Fri, 7 Feb 2025 14:52:42 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:

>>> I see TestG1BarrierGeneration.java failure :(
>>> 
>>> [TestG1BarrierGeneration_jtr.log](https://github.com/user-attachments/files/18676532/TestG1BarrierGeneration_jtr.log)
>> 
>> @offamitkumar thanks for the report! Most likely the test failures are only due to missing optimizations (because of limitations in the barrier elision pattern matching analysis), but if you want me to confirm please send the entire jtreg log, without truncation. You can disable output truncation running the test like this:
>> `make run-test TEST="compiler/gcbarriers/TestG1BarrierGeneration.java" JTREG="MAX_OUTPUT=999999999"`
>> Please double-check that the output log file does not contain any `Output overflow` message.
>
>> @robcasloz Sure:
>> 
>> I can spend time on it, maybe on weekend, for now I am overloaded with some other tasks.
>> 
>> [TestG1BarrierGeneration_jtr_no_overflow.log](https://github.com/user-attachments/files/18706090/TestG1BarrierGeneration_jtr_no_overflow.log)
> 
> Thanks Amit, I had a look and the failures are indeed due to missing barrier elisions for atomic operations on newly created objects, which is suboptimal but safe (and in practice unlikely to make a noticeable performance difference). I just disabled IR checks for the two affected tests on s390 by now (commit 956e0ac5). The issue is likely due to limitations in the pattern matching logic of barrier elision, but I do not have the proper means to debug it on s390. If you find a solution before this changeset is fully reviewed, feel free to propose a patch and I will merge it into the changeset. Otherwise, it can always be done as follow-up work. Hope this works for you!

> > @robcasloz Sure:
> > I can spend time on it, maybe on weekend, for now I am overloaded with some other tasks.
> > [TestG1BarrierGeneration_jtr_no_overflow.log](https://github.com/user-attachments/files/18706090/TestG1BarrierGeneration_jtr_no_overflow.log)
> 
> Thanks Amit, I had a look and the failures are indeed due to missing barrier elisions for atomic operations on newly created objects, which is suboptimal but safe (and in practice unlikely to make a noticeable performance difference). I just disabled IR checks for the two affected tests on s390 by now (commit [956e0ac](https://github.com/openjdk/jdk/commit/956e0ac5a7d580ad0e8850cfc4497da77cdb525c)). The issue is likely due to limitations in the pattern matching logic of barrier elision, but I do not have the proper means to debug it on s390. If you find a solution before this changeset is fully reviewed, feel free to propose a patch and I will merge it into the changeset. Otherwise, it can always be done as follow-up work. Hope this works for you!

Thanks @robcasloz. Yes sure, that's works totally for us.

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2652551761