RFR: 8348887: Create IR framework test for JDK-8347997

[Tobias Hartmann]

On Tue, 1 Apr 2025 13:01:05 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/c2/irTests/TestContinuationPinningAndEA.java line 118:
>> 
>>> 116: 
>>> 117:         @DontInline
>>> 118:         public CrashesNoInline() throws Throwable {
>> 
>> It's probably my own ignorance, but just in case are others are in the same boat, why does this crash? Could you add a brief javadoc for future readers? Same with other Crashes cases.
>
> It's rather bad (uninspired) naming. I based this test on the test introduced by [JDK-8347997](https://bugs.openjdk.org/browse/JDK-8347997), which (I suspect) is based on the reproducer mentioned in JBS. There are 2 cases: one made EA crash, the other make it fail (not detect the non escaping, as far as I understand). From Vladimir's comment on PR 23284, it used to crash because of a corrupted memory graph. Honestly, I'm not quite clear on that. There is already a test (from said ticket and PR) making sure it doesn't crash. The point of the test I'm adding is to check that the allocation is gone (thanks to EA). Maybe the best is rather to rename the cases "Crashes" and "FailEA": it made sense in the context of the original bug, but it's not very useful names for the future. But I'm not sure what would be fitting.

Right, I would suggest to rename these methods. The purpose of this test is not to reproduce the crashes that happened before [JDK-8347997](https://bugs.openjdk.org/browse/JDK-8347997) (which has it's own regression test), but to verify that EA is able to remove allocations around the pin/unpin intrinsic now that the crashes are fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24328#discussion_r2024265119