In general we've assumed that these are constants for the life of the program. It's unclear what would happen if some of these "run-time constants" started changing underfoot, even if we did all the wiring you suggest. It would probably be better to identify things that users really need to change and add explicit functions instead of reparsing $GODEBUG.

For example GODEBUG lets you set memprofilerate but there's a direct way to set it too.

/cc @aclements @RLH for whether it makes sense to be able to toggle gctrace, scavenge.

Explicit functions to enable GC logging, or recording the last N logs in-memory without printing them, and making them visible on /debug/pprof/heap would be good enough.

OK, it sounds like this issue should be narrowed from arbitrary GODEBUG toggling to really how to get better info about recent GCs. I apologize for the terrible-ness of the current MemStats - the GC and everything else was much simpler back then. Retitled this issue to be about GC info, some kind of extra helper alongside ReadMemStats for GC info. Or maybe even other runtime info.

The runtime team discussed this earlier this week but no progress on anything concrete yet.

I think the bigger issue here is how we can export stats from the runtime that may change from version to version. I would love to expose programmatic access to gctrace, but we haven't because those stats change between releases, often substantially. And simply exposing the string formatted gctrace and forcing people to parse what they want out of it would make users' lives harder without addressing the compatibility problem.

We've been talking about a more general mechanism to expose "unstable" runtime stats. Probably these would be named, with some way to enumerate the current names and fetch the value of a given stat. The set of names would not be guaranteed between versions, but monitoring systems could enumerate and collect them, and applications could use them with the understanding that they may change in the future. Probably the API would fetch a single stat so that expensive stats could be computed only when fetched (versus, for example, exposing all stats at once in a map). And probably the API should have explicit support for "streaming" stats that have a meaningful history, like in the gctrace.

The problem is vaguely similar to MIBs used by SNMP, where the tool that examines the stats can not know the exact nature of the stats provided by a specific device.

On hold for the runtime team.

If this data cannot be exposed through a library function, could it be exposed through a HTTP endpoint on /debug/pprof?

Bumping this, can pprof be used to export the GC data?