Describe JFR's event model: what kinds of events does it capture, and how does the sampling-and-buffering design keep the cost low enough for production?

## What an 'event' is In JFR, **everything recorded is an event**. An *event* is a typed record with, at minimum: a **timestamp**, optionally a **duration** (for things that take time), the **thread** that produced it, a **stack trace** (often), and a set of **typed fields** specific to that event kind. Events are described by *event types* (each has a name like `jdk.ObjectAllocationInNewTLAB`), so a recording is essentially a typed log of what the JVM and application did. ## The kinds of events The coverageArea lists the headline categories — here is what each tells you: - **Allocation events** — record object allocations. The JVM gives each thread a *TLAB* (Thread-Local Allocation Buffer, a private slab of the heap it can allocate from without locking); JFR emits an event when a thread allocates a new TLAB or allocates an object *outside* a TLAB. These reveal **allocation pressure** — the root cause of frequent GC. - **GC (garbage collection) events** — when collections start/stop, how long they **paused** application threads, which generation, and heap occupancy before/after. This is how you diagnose GC-induced latency. - **Lock / monitor events** — when a thread **contends** for a monitor (waits to enter a `synchronized` block) or parks on a `java.util.concurrent` lock. These expose **contention** that serializes your application. - **Exception / error events** — exceptions and errors thrown. A flood of thrown-and-caught exceptions is a common hidden cost. - **I/O events** — file and socket reads/writes and how long they took, exposing slow disk or network calls. - **Method sampling (execution-sample) events** — periodically, JFR captures the stack of running threads. Aggregating these stacks reconstructs a **CPU profile** (a flame graph of where time is spent) without instrumenting every method. Beyond these, JFR emits hundreds of event types (class loading, compilation, thread state, safepoints, JVM flags, container limits, etc.). ## Three structural categories 1. **Duration/instant events** — fired when a specific thing happens (a GC, a lock wait, an allocation). Often gated by a **threshold** so only the significant ones are kept (e.g. record only locks held longer than 10 ms, or I/O longer than 20 ms). 2. **Sampled events** — JFR *samples* rather than records every occurrence. Method profiling samples stacks at a configured rate; allocation profiling can also be sampled. Sampling is statistical: you get an accurate *distribution* at a tiny fraction of the cost of full instrumentation. 3. **Periodic events** — emitted on a timer to snapshot state: heap summary, GC config, thread/CPU/OS metrics, JVM flags. ## Why this keeps overhead near 1% - **Native instrumentation inside the JVM** — events are emitted by JVM internals, not by bytecode rewriting of your classes. - **Per-thread buffers** — each thread writes events into its own thread-local buffer, so threads almost never contend with each other to record. Full buffers are flushed to a global buffer and then to an on-disk *repository*. - **Sampling, not exhaustive tracing** — the costly question ('where is the CPU/where do allocations come from') is answered by sampling, so cost is bounded by the sample rate, not the application's call volume. - **Thresholds and per-event enablement** — a `.jfc` settings template enables/disables each event type and sets thresholds, letting you trade coverage for cost. The `default` template is tuned for < 1%; `profile` raises sampling density. ## Putting it together for diagnosis Because events are typed and timestamped, JMC (or a custom consumer) can correlate them: a latency spike (duration on a request event) lining up with a GC pause and a burst of allocation events points straight at allocation pressure; a throughput cliff lining up with monitor-contention events points at a lock. That correlation across event types is the analytical power of the model.