RFR: 8294245: Make Compile::print_inlining_stream stack allocated

[Thomas Stuefe]

On Thu, 22 Sep 2022 22:33:17 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> PrintInlining is used only for debugging and testing. That is why we chose to dynamically allocate data when it is needed. You are permanently increase size of Compile class which affects each compilation. Do you know size of `stringStream`. If it is small we can go with your changes.

152 bytes on 64-bit, including the internal scratch buffer of 48 bytes which may grow or (less probable) shrink in the future. I like this change though. Compile only exists once on the stack, right?

We also may trim down the stream classes somewhat, since we use it all over the place. 152 bytes seem excessive, and much of that is inherited crud from outputStream. There are size_t members that could be at least 32-bit, possibly even 16-bit indices. We waste 16 bytes on scratch buffer pointer + length, only used for a single purpose (error handling buffer) and that one could be done by accessing a static buffer in VMError directly. Indentation count could be a byte instead of 31-bit int. _width is unused. Probably more, if someone looks deeper. ostream is a bit of a grown mess.

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

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