RFR: 8356968: JFR: Compilation event should be enabled for all compilations by default

[Aleksey Shipilev]

On Thu, 15 May 2025 09:22:05 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> In the field, we are using -XX:+PrintCompilation to track compiler performance. Alternatively, -Xlog:jit* prints the same. JFR has a the related jdk.Compilation event that gives us even richer diagnostics. Yet, that event is set at a very high threshold (1000ms), which skips almost all compilations! This threshold is set to such a high value from the beginning. 
>> 
>> It is fairly normal to have lots of compilations in 100+ ms range individually, and their sum impact is what we are after. Also, the compilations are normally quite rare, and there are a couple of thousands of compiles in most workloads, and they only happen sporadically. This means, the event count without any threshold is not high.
>> 
>> Therefore, it would be convenient to make sure that basic Compilation event is enabled unconditionally, e.g. by dropping the default threshold to 0.
>> 
>> See more logs in the bug itself.
>> 
>> Additional testing:
>>  - [x] Ad-hoc tests with printing compilation events
>>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`
>
> The overhead of the event is low, I believe, but I think the concern was that too many events were generated with little value to the end user. The buffers will be filled, and other, more important events will be pushed out. That said, there are probably other JVM events, i.e., low-level GC or runtime events, that are on by default, which may be less interesting than the compilation event.
> 
> `jfr summary` lists the number of events and how much space they take up.
> 
> Maybe we should reprioritize them?

@egahlin -- does summary analysis alleviate your concern about event overheads?

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

PR Comment: https://git.openjdk.org/jdk/pull/25247#issuecomment-2890039307