asmhatre/jfr
1
0
Fork 0
Code Activity

Add jfr-demo: JFR + Mission Control profiling of a live Spring Boot app

Browse Source 
Custom OrderProcessed event, CPU/allocation/lock workloads, a diagnostic
endpoint over the JVM's live FlightRecorder state, a JUnit test using the
jdk.jfr.Recording API, and nine captured recordings (flagship, mid-flight
snapshot, isolated vs concurrent threshold comparisons, and a real
dump+stop duplication bug) with their docs/output/*.txt transcripts.
This commit is contained in:
asmhatre
2026-10-01 04:37:26 +00:00
commit c7eccd1db5
40 changed files with 1326 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/output/08-concurrent-recordings-shared-threshold.txt
+32
View File
@@ -0,0 +1,32 @@
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.