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

Theo Weidmann tweidmann at openjdk.org
Tue Jan 7 17:52:40 UTC 2025


On Mon, 25 Nov 2024 21:07:40 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>>> 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.
>
>> > 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.
> 
> Don't use `ttyLock`, we really want to get rid of that mechanism. The best would be to port the output to UL, but if that's not possible use a `stringStream` as Dean said.

@jdksjolen It's been a while since I was working on this, but if I remember correctly: The problem with the approach you suggest is that GrowableArray will fill the entire allocated buffer by calling the default constructor. Moving the new call into the constructor would therefore cause "n+1" heap allocations every time GrowableArray grows and some of these allocations might never be used.

https://github.com/openjdk/jdk/blob/9702accdd9a25e05628d470bf248edd5d80c0c4d/src/hotspot/share/utilities/growableArray.hpp#L521-L534

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

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


More information about the hotspot-compiler-dev mailing list