RFR: 8356027: Print enhanced compilation timings [v8]

[Vladimir Ivanov]

On Fri, 9 May 2025 16:00:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I also note that -- as practical example -- AFAICS in Leyden this rich diagnostic logging was implemented for PrintCompilation while LogCompilation was kept intact. Which kinda tells which facility people actually use more :) I can put new stuff in LogCompilation output as well in this PR, BTW, if you want.

I was the one who introduced it in Leyden :-) (Thanks for taking care of upstreaming it BTW!)

The pure reason it was built on top of PrintCompilation was ease of hacking. I was looking at short-running small applications (javac, in particular) and it was enough to meet the goal.
For a larger workload I'd look for a more reliable and tooling-friendly approach. 

There's plenty of information JVM could hose at users, but the more data is produced the harder it becomes to find important pieces. Tools can alleviate the problem, but then they eventually become the sole consumers of the raw output. Struggling to parse the format intended to be consumed by humans. So, in this particular case, I don't think the right answer for excessive amount of output are tools.

The nice thing about UL is that it provides a standard way to control amount of output using logging levels. What about leaving PrintCompilation as is and use UL-only output to communicate fine-grained details/events about JIT-compilation activity? Tracing/debugging output can be made much more verbose and disambiguous compared to existing PrintCompilation.

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

PR Comment: https://git.openjdk.org/jdk/pull/24984#issuecomment-2868322125