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

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.
2026-10-01 04:37:26 +00:00
commit c7eccd1db5
40 changed files with 1326 additions and 0 deletions
@@ -0,0 +1,42 @@
+The complete, correctly-produced flagship recording for this post:
+recordings/live-demo.jfr. Produced by one JFR.start, one mid-flight JFR.dump to a
+DIFFERENT file (recordings/mid-flight-snapshot.jfr, to demonstrate inspecting a
+running recording without stopping it), and one final JFR.stop with its own
+filename= -- the pattern that avoids the duplication bug documented in
+docs/output/09-dump-duplication-bug.txt.
+
+$ jfr summary recordings/live-demo.jfr | head -19
+ Version: 2.1
+ Chunks: 2
+ Start: 2026-10-01 04:29:03 (UTC)
+ Duration: 6 s
+
+ Event Type                              Count  Size (bytes)
+=============================================================
+ jdk.ModuleExport                         1756         20764
+ jdk.ActiveSetting                        1137         30480
+ jdk.BooleanFlag                           992         31418
+ jdk.GCPhaseParallel                       570         15793
+ jdk.InitialEnvironmentVariable            360         46224
+ jdk.ModuleRequire                         318          3498
+ jdk.ObjectAllocationSample                317          5081
+ jdk.LongFlag                              274          9074
+ jdk.NativeMethodSample                    211          2532
+ jdk.UnsignedLongFlag                      186          6468
+ jdk.ThreadPark                            130          5283
+ jdk.ThreadAllocationStatistics            116          1337
+
+The four event types this post is actually about, pulled out of the same file:
+
+$ jfr summary recordings/live-demo.jfr | grep -E 'ExecutionSample|ObjectAllocationSample|JavaMonitorEnter|OrderProcessed'
+ jdk.ObjectAllocationSample                317          5081
+ jdk.ExecutionSample                        98          1176
+ com.ankurm.jfr.OrderProcessed              23           809
+ jdk.JavaMonitorEnter                       15           414
+
+317 allocation samples, 98 CPU samples (63% of them in the one hot method --
+docs/output/03-hot-method-samples.txt), 23 kept custom business events out of 60
+calls (docs/output/06-custom-event-live-demo.txt), and 15 monitor-enter events
+from one 16-worker contention burst (docs/output/05-lock-contention-live-demo.txt)
+-- all from a recording six seconds long, on an application that otherwise just
+sits idle.