The same 40-round, ~12 ms-wait workload as 07-threshold-isolated-comparison.txt,
but this time two recordings are started AT THE SAME TIME on the same JVM: one
with settings=default (JavaMonitorEnter threshold 20 ms) and one with
settings=profile (threshold 10 ms).

$ jcmd 5287 JFR.start name=cmpA settings=default
$ jcmd 5287 JFR.start name=cmpB settings=profile
$ for i in $(seq 1 40); do curl -s "localhost:8080/api/lock/contend?workers=2&holdMillis=12" -o /dev/null; done
$ jcmd 5287 JFR.stop name=cmpA filename=recordings/compare-default.jfr
$ jcmd 5287 JFR.stop name=cmpB filename=recordings/compare-profile.jfr

$ jfr summary recordings/compare-default.jfr | grep JavaMonitorEnter
 jdk.JavaMonitorEnter                       40          1080
$ jfr summary recordings/compare-profile.jfr | grep JavaMonitorEnter
 jdk.JavaMonitorEnter                       40          1080

Both recordings show all 40 events -- including in "compare-default.jfr", the one
configured with a 20 ms threshold, for waits that are only ~12 ms long. Compare
this to 07-threshold-isolated-comparison.txt, where the exact same default
settings, run ALONE with the exact same workload, captured zero of these waits.

The difference is that the two recordings were active at the same time. Duration
thresholds for events like jdk.JavaMonitorEnter are implemented as a single
instrumentation check shared by the JVM across every currently-active recording,
not a private filter per recording -- the effective threshold the running code
uses is the MINIMUM threshold requested by any active recording. A second,
unrelated recording (a colleague's ad hoc `jcmd JFR.start`, an APM agent's own
continuous recording) with a lower threshold for an event type silently widens
what every other concurrently running recording captures for that same event
type. "My recording uses the default profile" is not, by itself, enough to know
what your recording actually contains on a box where something else might also be
recording.