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

[theoweidmannoracle]

On Wed, 13 Nov 2024 08:43:09 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I've been trying to understand all these print_inlining_*() functions for a few days now, and I still don't understand the rules about when each can be called, when we should overwrite and when we should append, when the stringStream should be empty or not empty, and how _print_inlining_list works.  Then there is the parallel InlineTree that we build, and it has a success/fail message attached too.
>
>> I've been trying to understand all these print_inlining_*() functions for a few days now, and I still don't understand the rules about when each can be called, when we should overwrite and when we should append, when the stringStream should be empty or not empty, and how _print_inlining_list works. Then there is the parallel InlineTree that we build, and it has a success/fail message attached too.
> 
> It is indeed a mess.
> The way this work, I think, is that the message for the inlining that's currently happening is accumulated in `_print_inlining_stream`.
> `_print_inlining_list` is the list of inlining messages. A single entry of `_print_inlining_list` may contain the aggregated messages for multiple call sites. So once we are done, we simply iterate over the list and output each entry. 
> If there's no late inlining involved, then `_print_inlining_list` only has a single entry.
> When a call site is a candidate for late inlining (i.e. there is a chance that some messages need to be inserted at the current point at a later time), then a new element is added to `_print_inlining_list`. 
> If late inlining does happen at that call site, the logic iterates over `_print_inlining_list` and finds the entry with the matching `CallGenerator`. When the call site is inlined, it's possible that this will cause some inlining to happen right away (and so messages to be appended to the current `_print_inlining_list` entry) and some more late inlining to happen later on (and so a new entry to be added to `_print_inlining_list` right after the current one, possibly in the middle of the list). 
> 
> If I remember correctly I tried using `InlineTree` instead but that didn't work well. I don't remember the details though.

I have made changes such that previous information is no longer lost. So for @rwestrel's example the output is now:


200   24     n       jdk.internal.vm.Continuation::doYield (native)   (static)
208   25    b        TestLateInlining::test1 (4 bytes)
                            @ 0   TestLateInlining::inlined1 (1 bytes)   inline (hot);    late inline succeeded


I will work on adding a test for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/21899#issuecomment-2476015526