Thanks David — to clarify: we're seeking feedback only. The doc( https://docs.google.com/document/d/1ml1y1__btqGdYiJwMtT6rXVcBrXeP3qlyc1gb6m9S3U/edit?usp=sharing ) above is a public Google Doc with just the design description and our questions (no internal code).
The core is a usage pattern: one custom JFR event per HTTP request (interval marker, @StackTrace(false), begin/commit around a servlet filter), any thread-bound event attributed by threadId + startTime ∈ [begin, commit], and worker threads reconstructing the marker from TransmittableThreadLocal-propagated context. Google doc's section 4's six questions are where your take would be most valuable — especially the clock-domain/ordering guarantees between custom and VM-internal events, and whether "marker event + interval join" is a pattern worth native JFR support. On Fri, Oct 2, 2026 at 8:57 AM David Holmes <[email protected]> wrote: > Hi Roy, > > Are you proposing to contribute this to OpenJDK or are you just looking > for feedback? If the former then the information needs to be hosted on > OpenJDK infrastructure so people can safely look at it. > > Cheers, > > David > On 1/10/2026 9:57 pm, Roy Zhang wrote: > > 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 > >
