proposal: runtime/race: Pure-Go implementation without CGO dependency

[kolkov]

This proposal addresses the long-standing request for a race detector that works with CGO_ENABLED=0.

Related issues:

• runtime/race: eliminate dependency on libc #9918 - race: runtime depends on libc (opened by @dvyukov, 2014, still open)
• runtime/race: eliminate dependency on cmd/cgo #6508 - runtime/race: can't be used with CGO_ENABLED=0 (2013)
• Race detector should not require cgo #38955 - race detector should not require cgo (2020, closed as duplicate)

Background

The current race detector requires ThreadSanitizer (C++), which creates several limitations:

• CGO_ENABLED=1 is mandatory
• Cannot produce static binaries for FROM scratch Docker containers
• Cross-compilation requires target platform libc
• Platform-specific allocation failures (runtime: ThreadSanitizer failed to allocate / CHECK failed #37651, race: 'unsupported VMA range' on linux/arm64 #29948, runtime: linux/s390x ThreadSanitizer failed to allocate 0x7e0000 (8257536) bytes at address 900000180000 (errno: 12) in QEMU #67881)

Issue #9918 has been open for 11 years with "Unplanned" milestone. The solution proposed there — "eliminate all libc dependencies from race runtime" — is what this implementation provides.

Implementation

I've implemented a pure-Go race detector based on peer-reviewed algorithms:

Algorithm	Paper	Contribution
FastTrack	PLDI 2009	Core happens-before detection
BigFoot	PLDI 2017	Static coalescing (90% barrier reduction)
SmartTrack	PLDI 2020	Ownership tracking (10-20% faster)
O(1) Sampling	PLDI 2024	Probabilistic sampling for CI/CD

Current status (v0.7.0):

• 359/359 tests from Go's official race test suite passing
• Works with CGO_ENABLED=0
• Standalone CLI tool: racedetector build/run/test
• All Go platforms supported (pure Go, no assembly required)

Performance optimizations:

• Lazy stack capture: 2.6x faster hot path (329ns → 127ns)
• Lock-free VarState: 10x faster concurrent access
• Sharded shadow memory: 12.5% faster under contention
• VectorClock pooling: 99.7% fewer allocations

Real-world testing:

• Validated on gogpu/wgpu — a pure-Go WebGPU implementation that requires CGO_ENABLED=0

Repository: https://github.com/kolkov/racedetector

Questions for the community

Before pursuing a formal design document, I'd like to understand community needs:

1. Demand: Does the CGO dependency actually block you in production?

• 👍 Yes, this is a real blocker
• 👎 No, CGO_ENABLED=1 works fine for me

2. Integration preference:

• Standalone tool (current approach) is sufficient
• Would only use if built into go build -race
• Either option works

3. Performance expectations:

• ThreadSanitizer achieves 5-20x overhead
• What overhead is acceptable for pure-Go implementation?

4. Missing features:

• What would prevent you from using this today?

Compatibility

• API: Uses same raceread/racewrite semantics
• Behavior: Same detection capabilities as current race detector
• Breaking changes: None — this is additive functionality
• New capability: CGO_ENABLED=0 support

Next steps

Depending on community feedback:

• High demand: Prepare formal design document for Go team review
• Low demand: Continue as standalone tool

I'm happy to provide detailed benchmarks, demos, or additional technical information.

/cc @dvyukov (author of #9918, original ThreadSanitizer integrator)
/cc @aclements (runtime team lead)

[gabyhelp]

Related Issues

• Race detector should not require cgo #38955 (closed)
• proposal: runtime/pprof: structured, programmatic access to go race reports #75434
• runtime/race: adding support for the race detector on other platforms #19273

Related Discussions

• Race detection with CGO_ENABLED=0?

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

[slsyy]

AFAIK this set of options for unobtrusive CGO for windows:

$ CC="zig cc -target x86_64-windows-gnu" CXX="zig c++ -target x86_64-windows-gnu" GOOS=windows  GOARCH=amd64 go build -race 

does not work on non-windows build OS so there is an another use case for a pure implementation

[DmitriyMV]

#57175 (comment) this is probably related, since Go team is thinking about "lightweight always-on race detection" and even have prototype PR.

[kolkov]

Thanks @DmitriyMV for the pointer to #57175 and the prototype CL!

I wasn't aware of the "lightweight always-on race detection" discussion from the Nov 20 sync meeting. It's great to see the Go team exploring this direction.

Our implementation already includes sampling support (based on "Dynamic Race Detection with O(1) Samples", PLDI 2024) via RACEDETECTOR_SAMPLE_RATE environment variable. This was designed exactly for the use case mentioned — low overhead production monitoring where scale compensates for lower detection rates.

Happy to share implementation details or collaborate if it would be useful for the Go team's efforts. The approaches seem complementary:

• The prototype in CL 718640 focuses on lightweight always-on detection integrated into runtime
• Our implementation provides full FastTrack detection with CGO_ENABLED=0 support

Both solve real problems for different use cases.

[kolkov]

@slsyy Yes, cross-compilation is another pain point. Our implementation works for any GOOS/GOARCH combination since it's pure Go — no C toolchain required at all.

# Works today with racedetector
GOOS=windows GOARCH=amd64 CGO_ENABLED=0 racedetector build ./...