runtime/coverage: Support set mode

[r-hang]

Go's coverageredesign in a non unit set setting enforces that the program be instrumented in atomic coverage mode.
-

go/src/internal/coverage/cfile/apis.go

Line 39 in 6fbad4b

return fmt.Errorf("WriteCountersDir invoked for program built with -covermode=%s (please use -covermode=atomic)", cmode.String())

• https://cs.opensource.google/go/go/+/refs/tags/go1.24.5:src/runtime/coverage/coverage.go;l=64

Can we support set mode and provide performance estimates for for atomic mode? https://go.dev/blog/cover states that set mode can incur ~3% overhead.

One possible application of this feature is deploying coverage instrumented binaries in production in order to detect and remove unused code. Atomic mode is prohibitively expensive to do on some production workloads.

[mknyszek]

CC @thanm maybe?

[thanm]

It's certainly possibly to collect coverage data with "set" mode for applications (non unit tests), it's just not possible to do that and also use the various APIs that allow more user control (e.g. ClearCounters, WriteCounters, etc).

What's important to remember about the coverage API functions is that when they run, they will be reading from or writing to a counter data segment that the program itself is in the process of updating as it runs -- there is no locking or synchronization between the writer (the executing program itself) and the reader (the API func). The way the counter segment is designed, it intermixes the counters themselves with meta-data about the covered functions. If the instrumented program isn't using atomic ops when writing values into the counter segment, there's no guarantee on a modern processor that these writes are in program order -- this is a recipe for disaster given the current design.

It is possible to imagine a redesign of the coverage runtime that splits off the meta-data from the counter values in some way, so that you could use atomic ops just for the meta-data and not the counters, but the various ideas that I've brainstormed in this space seem expensive (e.g. increase memory overhead and/or link time for all cases, including unit testing). I can also imagine switching to using a lock-free list of registered live (covered) functions in the runtime, but again that would be at the cost of additional memory and time.

So I think the TLDR here is that there isn't any way to easily support non-atomic "set" mode in combination with use of the APIs without a careful redesign / reimplementation of the way counters are stored.