proposal: runtime/pprof: get labels for current goroutine

[folays]

Proposal Details

Semi-related to [#67401] because it will remove some go:linkname I used.

Previously, I coded https://github.com/folays/pprof-gls , a one-file adding some sort of pprof.Do(),
except that my version (https://github.com/folays/pprof-gls/blob/master/labels.go) add a little tweak ;

pprof.Do() allows you to (temporarily) ADD (not just REPLACE) the label-set for a given function, which will be attached by the internals to the Goroutine.

My pprof_gls.Do() (same signature) allows me to temporarily ADD (not REPLACE) additional labels to the current Goroutine label-set, EVEN IF I pass to it a nil context.Context.

/// CONTEXT

proof uses context.Context, which hold a map[], in some special way : whilst context.Context aren't generally necessary tied to a Goroutine, regarding to pprof, Goroutines struct uses context.Context to hold the label-set, and use the context.Context general principle of map[] and copy-and-add to attach new labels to the Goroutine label-set.

When I'm not working on industrial-grade code, I sometimes don't bother to pass a context.Context around EVERYWHERE.
It means that I'm not always passing around a context.Context of a caller paths to their callees.

Sometimes, I don't even have a bug, I just want to profile CPU-bound stuff like trigonometry, octree and ray-polygon intersect stuff, and I would like to have the labels of the current area of code I'm profiling, inherit the labels of their callers, and I would also like to temporarily add some labels. (but ADD some, not just REPLACE all of them).

pprof use a "private" context.Context key, and If I remember well, also use some internals to attach the label-set to the current Goroutine struct.

In my code, ignore the //go:linkname runtime_setProfLabel runtime/pprof.runtime_setProfLabel which is unused,
I only use two specificities :

• //go:linkname runtime_getProfLabel runtime/pprof.runtime_getProfLabel : When I didn't bothered to pass around the context.Context of callers, to get my hand on the current context holding the label-set attached to the current Goroutine.
• Ugly reflectance to get around the restriction on accessing "unexported" field, to fetch a copy of the "proof" private context.Context key

// SUMMARY

My main need, which my whole code revolves around, can so be summarised as : proof.Do() is fine in itself, I just needed an API to fetch the label-set CURRENTLY APPLIED to the current Goroutine, when we didn't receive any context.Context from our callers.

// PROPOSAL

The proposal would be, instead of whitelisting usage of //go:linkname to pprof internals, would be to either or both :

• add an API to pprof, maybe some func GetGoroutineLabels() LabelSet, which would returns the currently applied label-set
• extend pprof.Do() like I do (when a nil context is passed, use the currently applied label-set)
• extend pprof.WithLabel() instead (in the same way)

Extending the case where a nil context.Context is passed to pprof.Do() / pprof.WithLabels() should not affect existing behaviour much, since in the current situation, passing nil to either panics due to a nil pointer dereference.

Thanks & best regards,

[gabyhelp]

Related Issues and Documentation

• proposal: runtime/pprof: add WriteGoroutineLabels function for logging #51223

• pprof: add support for profiler labels #17280 (closed)

• proposal: runtime/pprof: add new WithLabels* function that requires fewer allocations #33701

• [Package pprof > func Do
  ¶

   		1.9
   	](https://go.dev/pkg/runtime/pprof/?m=old#Do) <!-- score=0.83625 -->
  

• [Package pprof > func SetGoroutineLabels
  ¶

   		1.9
   	](https://go.dev/pkg/runtime/pprof/?m=old#SetGoroutineLabels) <!-- score=0.82615 -->
  

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}