RFR: 8319850: PrintInlining should print which methods are late inlines [v14]

[Dean Long]

On Fri, 22 Nov 2024 14:34:43 GMT, theoweidmannoracle <duke at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/16595 @caojoshua previously suggested changes to indicate which calls were inlined late, when printing inlines. This PR re-introduces the changes from the previously closed PR and fixes a minor issue where asserts were triggered.
>> 
>> Concerns were raised by @rwestrel in the previous PR:
>> 
>>> When InlineTree::ok_to_inline() is called, some diagnostic message is recorded for the call site. Do I understand right that with this patch, if the call is inlined late, then that message is dropped and replaced by a new "late inline.." message? If that's the case, isn't it the case that sometimes the InlineTree::ok_to_inline() has some useful information that's lost when late inlining happens?
>> 
>> As already pointed out in the PR by @caojoshua, this does not matter for string/methodhandle/vector/boxing late inlines, as they are [only performed if ok_to_inline() returns true](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/doCall.cpp#L189). This is also the only call to ok_to_inline().  
>> 
>> The only other location, where late inline call generators are created, are calls to CallGenerator::for_late_inline_virtual(), which creates a LateInlineVirtualCallGenerator. LateInlineVirtualCallGenerator (introduced in https://github.com/openjdk/jdk/pull/1550) does not really perform inlining but rather performs strength reduction from virtual to static calls. As can be verified by running the according test `test/hotspot/jtreg/compiler/c2/irTests/TestPostParseCallDevirtualization.java`, this does not affect the printing for inlining:
>> 
>> 
>> 5022 1026       3       compiler.c2.irTests.TestPostParseCallDevirtualization::callHelper (7 bytes)   made not entrant
>>                               @ 1   compiler.c2.irTests.TestPostParseCallDevirtualization$I::method (0 bytes)   failed to inline: virtual call
>> 
>> 
>> Thus, as far as I can tell, the proposed changes by @caojoshua do not lose any useful information about why no inlining prior to the late inlining occurred.
>
> theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestDuplicatedLateInliningOutput

src/hotspot/share/compiler/compileTask.hpp line 222:

> 220: 
> 221:   /**
> 222:    * @deprecated Please rely on Compile::inline_printer. Do not directly write inlining information to tty.

Can we get rid of these instead of making them deprecated?

src/hotspot/share/opto/printinlining.cpp line 78:

> 76:     return child;
> 77:   }
> 78:   auto child = new (_arena) IPInlineSite(callee, _arena, bci);

This code is nice and compact, but I'm worried about the memory footprint.  In the worst case, we get an array element for every bytecode parsed, right?  It might be better to use a hash table.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21899#discussion_r1854955825
PR Review Comment: https://git.openjdk.org/jdk/pull/21899#discussion_r1854955353