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

ExE Boss duke at openjdk.org
Fri Dec 5 17:24:57 UTC 2025


On Mon, 1 Dec 2025 22:46:10 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> What I meant was where the `instanceof` is in the called method, the `testInstanceOfCondPre` all have the `instanceof` checks as part of the `if` statement.
>> 
>> --------------------------------------------------------------------------------
>> 
>> Something like:
>> 
>> static void testInstanceOfCondDefaultInlinePre(A a, boolean cond) {
>> 	if (defaultInlineInstanceOfCondPre(a, cond)) {
>> 		a.m();
>> 	}
>> }
>> static void testInstanceOfCondDefaultInlinePost(A a, boolean cond) {
>> 	if (defaultInlineInstanceOfCondPost(a, cond)) {
>> 		a.m();
>> 	}
>> }
>> 
>> static void testIsInstanceCondDefaultInlinePre(A a, boolean cond) {
>> 	if (defaultInlineIsInstanceCondPre(a, cond)) {
>> 		a.m();
>> 	}
>> }
>> static void testIsInstanceCondDefaultInlinePost(A a, boolean cond) {
>> 	if (defaultInlineIsInstanceCondPost(a, cond)) {
>> 		a.m();
>> 	}
>> }
>> 
>> 
>> --------------------------------------------------------------------------------
>> 
>> I suggest adding such a test because of real world code which use different internal implementation classes but expose their public API as only a single common supertype, like `java.lang.constant.ClassDesc` and its `isPrimitive()`/`isArray()`/`isClassOrInterface()` methods (which currently don’t do the `instanceof` check, but they probably should so that they can be reliably inlined).
>
> The test is intended as a white-box test. It focuses on bytecode shapes which result in different IR representations and exercise different optimizations. From compiler perspective, there's no difference between  `if (defaultInlineInstanceOfCond(a)) { ... }` and `if (a instanceof B) {...}` when inlining happens during parsing. Both test cases produce the very same IR after parsing is over.

It might be useful to have these tests in case the default inlining IR changes in the future.

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

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


More information about the hotspot-compiler-dev mailing list