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

[theoweidmannoracle]

On Mon, 25 Nov 2024 19:33:58 GMT, Dean Long <dlong at openjdk.org> wrote:

>>> I pulled your latest changes, and I am seeing missing newlines in the output, just by running `java -XX:+PrintInlining`. With -XX:+PrintIntrinsics, there is no additional output, so I'm wondering how -XX:+PrintIntrinsics tests are passing. Maybe we are missing test coverage for that flag.
>> 
>> 
>> 
>>> I'm also seeing missing method names:
>>> 
>>> ```
>>>                               @ 10   java.lang.StringBuilder::                              @ 7   jdk.internal.classfile.impl.SplitConstantPool::utf8Entry (45 bytes)   failed to inline: callee is too large
>>> ```
>>> 
>>> and weird indentation:
>>> 
>>> ```
>>>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline
>>>                                                             @ 1   sun.invoke.util.Wrapper::basicTypeChar (18 bytes)   inline
>>> ```
>> 
>> @dean-long The reason for this is that multiple compile threads are trying to print at the same time. The odd formatting goes away with `-Xbatch`, preventing concurrent compilation. I didn't remove any explicit locking or synchronizing mechanism during refactoring. I think there was never any explicit mechanism to make this work without -Xbatch but it rather worked because the entire printinlining for one method was first dumped into a stringStream, which was then dumped onto tty in one go. With my refactoring though, InlinePrinter::IPInlineSite::dump will directly print individual segments of the output to tty, opening the door widely for bad interleavings with multiple compile threads. 
>> 
>> Do you think I should introduce an explicit synchronization mechanism to ensure the formatting is still correct with multiple compile threads?
>
>> Do you think I should introduce an explicit synchronization mechanism to ensure the formatting is still correct with multiple compile threads?
> 
> Yes, we could try grabbing the tty lock in dump(), but in the past I think there were sometimes problems with that approach, which is why there were places where we print everything to a stringStream first.

@dean-long After further investigation, I discovered that also before my refactoring the formatting can be messed up severely. For example, running


javac  -J-XX:+PrintCompilation -J-XX:+TieredCompilation -J-XX:+PrintInlining test/jdk/com/sun/jdi/HelloWorld.java 


on a recent master debug build, will also produce messed up output. So `stringStream`s do not really help with the problem.

Since it wasn't synchronized before, I propose that we do not change it as part of this PR. Should we file an RFE to look into this in the future?

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

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