RFR: 8372634: C2: Materialize type information from instanceof checks [v5]

[Christian Hagedorn]

On Wed, 10 Dec 2025 22:20:11 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/inlining/TestSubtypeCheckTypeInfo.java line 363:
>> 
>>> 361:     // Sample:
>>> 362:     //    213   42    b        compiler.inlining.TestSubtypeCheckTypeInfo::testIsInstanceCondLatePost (13 bytes)
>>> 363:     static final Pattern TEST_CASE = Pattern.compile("^\\d+\\s+\\d+\\s+b\\s+" + TEST_CLASS_NAME + "::(\\w+) .*");
>> 
>> Drive by comment, no need to change things here now:
>> @iwanowww @chhagedorn Would it not be nice if we could do this kind of matching with the `TestFramework`? Instead of `IR` matching, just match the output of any compilation tracing / printing.
>
> Indeed, that would be a much better way.
> 
> Also, `-XX:+LogCompilation` is a nice option since publishes all information in a structured way, but it would introduce a dependency on LogCompilation tool in the test library.

That's an interesting idea to think about more. But I it would be a separate concept next to `@IR` even though some code could probably be shared.

> but it would introduce a dependency on LogCompilation tool in the test library.

The IR framework already uses `LogCompilation` to parse the IR dumps from. But I think that's quite an overhead - a lot of the information is not needed and makes the parsing logic more complicated.

I've been thinking about introducing a separate IR framework file for all relevant dumps, similar to dumping IGV dumps to a separate file. This will simplify things and only dumps relevant information. It will also have a positive impact on performance.

We could even go a step further and send the dumps over a port to the IR framework (similar to dumping the graph directly to the opened IGV over the network). Today, we already have sockets in place to send messages from the test VM to the driver VM. I guess we could extend that to also allow HotSpot to send dumps to the driver VM (it sounds feasible to do but would need to experiment with it).

Sending dumps from HotSpot to the IR framework has another benefit that HotSpot can provide all the information needed for the IR framework to figure out where this dump belongs to (i.e. no additional parsing of a file needed). This might also allow us to do IR matching in parallel to the test VM execution. This is much more efficient because today, the driver VM just waits until the test VM is finished and only then starts to do IR matching. 

Anyway, that was just a digression about future ideas for the IR framework. What you have now to parse the output is the best we can do today.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28517#discussion_r2613767737