runtime: add GODEBUG=inittrace=1 support

[martisch]

Note: Like #38714 this is not a proposal for the proposal process.

This issue is to discuss and track the addition of support for init function tracing through GODEBUG for ad hoc debugging and profiling of init start times.

For the first minimal implementation (future iterations can expand functionality) I think that just showing the package name, start time of the init function, wall clock duration and total heap allocated bytes and number of allocs is sufficient. Later information like module version could be added.

Due to larger complexity and limited utility init tracing of plugins is not supported.

Having a more structured format like json output is omitted and likely needs a more holistic approach and decision in unison with adding support for gctrace in json format too.

Prototype CL: https://go-review.googlesource.com/c/go/+/254659

Example output:

$ GODEBUG=inittrace=1 go test
init internal/bytealg @0.008 ms, 0 ms clock, 0 bytes, 0 allocs
init runtime @0.059 ms, 0.026 ms clock, 0 bytes, 0 allocs
init math @0.19 ms, 0.001 ms clock, 0 bytes, 0 allocs
init errors @0.22 ms, 0.004 ms clock, 0 bytes, 0 allocs
init strconv @0.24 ms, 0.002 ms clock, 32 bytes, 2 allocs
init sync @0.28 ms, 0.003 ms clock, 16 bytes, 1 allocs
init unicode @0.44 ms, 0.11 ms clock, 23328 bytes, 24 allocs
...

/cc @mknyszek @aclements @randall77 @prattmic @josharian

[gopherbot]

Change https://golang.org/cl/254659 mentions this issue: runtime: implement GODEBUG=traceinit=1 support

[heschi]

Sorry if this is a silly question; is it not possible to start a pprof profile and end it right before starting main?

[martisch]

In principle possible with the following caveats that come into my mind (im sure there are more):

• to be able to profile all std lib packages one would need to find the first init function and start the profiling in there or add a GODEBUG flag to immediately start profiling (the user wanting to trace might not have the ability to change the std library)
• interrupt driven profiling is sample based and especially for small init functions will require a lot of samples to approximate all init runtimes. we can instead measure with init tracing the same values we are trying to sample with profiling.
• profiling flame graphs or summaries usually do not have any ordering (init foo happend before init bar)