Hi JFR Experts, We built something on JFR that we'd like your eyes on — not a bug, a usage pattern that quietly depends on some JFR-internal behaviors we'd love expert confirmation of.
*The gap*: production JFR tells us what resources were consumed (ExecutionSample, ObjectAllocation, SocketRead) and where (thread, stack) — but never on behalf of which API. "What did this API cost me?" is the question every service owner asks, and JFR couldn't answer it. Now it can. *How*: one custom event per request — an interval marker, @StackTrace(false), begin in a servlet filter, commit in its finally. Every other event is attributed to the API by threadId + startTime ∈ [begin, commit]. The fun part is cross-thread: worker threads rebuild the marker from TTL-propagated context, so async samples land on the right API too — 97–99% measured, virtual threads included. *The ask*: Section 4 of the write-up has 6 questions born from assumptions we couldn't verify from source alone — clock-domain consistency across event writers, custom-vs-VM event ordering, String-pool pressure, and whether a "marker event" idiom deserves native JFR support. Your answers either validate the foundation or catch a subtle breakage before production does. Full write-up: https://docs.google.com/document/d/1ml1y1__btqGdYiJwMtT6rXVcBrXeP3qlyc1gb6m9S3U/edit?usp=sharing Any comment is appreciated :) Thanks, Roy
