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

[Theo Weidmann]

> 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 ...

Theo Weidmann has updated the pull request incrementally with one additional commit since the last revision:

  Update bytecodeInfo.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21899/files
  - new: https://git.openjdk.org/jdk/pull/21899/files/2db77384..c005f6b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21899&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21899&range=27-28

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21899.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21899/head:pull/21899

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