Description
I'm just recording this here, as an idea, since this keeps popping up here and there, and since it _might_ be a solution to providing context to events not under the control of the user, especially if/when most events are using rate limited sampling rather than thresholds in some possible future.
Go supports adding context for a go routine to the profiler through profiler labels (https://rakyll.org/profiler-labels/). They are kept in a struct in the goroutine:
https://sourcegraph.com/github.com/golang/go@135c9f45ecaec719bcc297ec9f9f19042bc9adf6/-/blob/src/runtime/runtime2.go#L469
It's a handy way to add context to profiling samples, for samples that are not under the control/created by the user, such as (currently only, AFAIK) CPU profiling samples.
It would probably need a recording option to define whether or not pick up the context at all.
Go supports adding context for a go routine to the profiler through profiler labels (https://rakyll.org/profiler-labels/). They are kept in a struct in the goroutine:
https://sourcegraph.com/github.com/golang/go@135c9f45ecaec719bcc297ec9f9f19042bc9adf6/-/blob/src/runtime/runtime2.go#L469
It's a handy way to add context to profiling samples, for samples that are not under the control/created by the user, such as (currently only, AFAIK) CPU profiling samples.
It would probably need a recording option to define whether or not pick up the context at all.
Attachments
Issue Links
- relates to
-
JDK-8284453 Optionally Record Thread Context in JFR
- Draft