Integrated: 8319850: PrintInlining should print which methods are late inlines

[Theo Weidmann]

On Tue, 5 Nov 2024 10:19:51 GMT, Theo Weidmann <tweidmann at openjdk.org> wrote:

> This PR overhauls the print inlining system. It now allows to record multiple inlining messages per potential inline/call site. Since inlines can trigger further inlines, the entire print inlining information is now stored as a tree. This structure enables more detailed logging and prevents the accidental overwriting of useful logs, an issue encountered in the past.
> 
> Also, prints will contain detailed information about which methods are late inlines.
> 
> This rewrite became necessary due to the hard-to-understand way in which the old print inlining worked, which made it almost impossible to implement printing which methods are late inlines without losing previous print statements (see discussion below).
> 
> 
> Here is a new example print output, showing different messages logged for the same location. In this case, a nice progression, from not being able to inline to late inline can be witnessed.
> 
> 
> @ 18    java.lang.invoke.MethodHandle::invokeBasic()V (0 bytes)   failed to inline: receiver not constant    callee changed to java.lang.invoke.LambdaForm$DMH/0x000000012a403470::invokeStatic (17 bytes)  force inline by annotation   late inline succeeded (method handle)
> 
> 
> Naturally, the output of print inlining changes with this PR, but I tried to keep the changes small.
> 
> ----
> 
> Original PR description before rewrite:
> 
> 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 ...

This pull request has now been integrated.

Changeset: 96fefed3
Author:    Theo Weidmann <tweidmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/96fefed37f658c3aefd7419dd96ccaa474949a42
Stats:     942 lines in 17 files changed: 449 ins; 287 del; 206 mod

8319850: PrintInlining should print which methods are late inlines

Reviewed-by: chagedorn, kvn, jsjolen, dlong

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

PR: https://git.openjdk.org/jdk/pull/21899