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! Observe:

```
$ build/linux-x86_64-server-release/images/jdk/bin/java -XX:StartFlightRecording=filename=comp.jfr Hello.java
Hello world!

$ jfr print comp.jfr | grep jdk.Compilation | wc -l
      0
```

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:

```
$ build/linux-x86_64-server-release/images/jdk/bin/java -XX:StartFlightRecording=filename=comp.jfr,jdk.Compilation#threshold=0 Hello.java

$ jfr print comp.jfr | grep jdk.Compilation | wc -l
    929
```