v0.1.2

Correctness and tooling fixes, expanded hotpathcheck checks, and a re-measured benchmark suite on three Go toolchains.

Note: v0.1.2 replaces v0.1.1 for hotpathcheck: under Go 1.26's go vet -vettool protocol, v0.1.1's analyzer binary printed raw JSON and exited 0 — a CI gate that never failed. Fixed by building against golang.org/x/tools v0.50.0 (pinned toolchain go1.26.8).

Fixed

• profile.Apply rolls back when read-back fails (previously left knobs half-applied)
• Session.Undo restores a previous GOGC=0 correctly
• profile.QuietGC reports real reclaimed bytes (Reclaimed(), heap-objects delta) instead of misusing /gc/heap/live
• profile.CgroupMemoryLimit resolves the process's own cgroup and ancestor limits (v2 then v1) instead of only the root
• bench: runtime-reported histogram bucket edges (no hand-copied table), no 32-bit overflow in op count, rate cap
• hotpathcheck: generic-method resolution, trailing //hotpath:allow no longer leaks to the next line, exact directive match
• CI now actually runs (workflow triggered on main; default branch is master), plus a gofmt gate

Added

• bench.Regressed — percentiles that slowed by >10% and >1 µs, for CI gates
• hotpathcheck flags string concatenation and map writes; math, math/bits, sync/atomic count as verified
• godoc examples for profile and bench
• guard.Exact documented as process-wide (not t.Parallel-safe)

Benchmarks (re-measured, 3 repeats × 3 toolchains)

A zero-allocation order book's p99 moved ~3 µs → ~30-35 µs (~10×) when 4 neighbor goroutines allocated in the same process, on go1.22.12, go1.26.8, and go1.27.1 — while an equally busy non-allocating control group barely moved it, isolating GC (not CPU contention) as the mechanism. Service time stayed ~3 µs the whole time; a closed-loop benchmark would have printed no regression.

Full methodology, per-version tables, and caveats in BENCHMARK.md.

Requirements

• Library: Go 1.22+ (recommended 1.26+); verified on 1.22.12 / 1.26.8 / 1.27.1
• hotpathcheck: builds with Go 1.26, vets code targeting any version
• Apache-2.0 — safe for closed-source integration

v0.1.1 — guard, profile, bench, hotpathcheck

First public release of go-hotpath — a small, dependency-free Go toolkit for detecting, measuring, and controlling garbage-collector interference in latency-sensitive systems.

What's inside

Package	What it does
guard	Zero-allocation GC-interference windows (~450 ns, 0 allocs) + exact ReadMemStats assertions for tests
profile	Reversible GOGC/GOMEMLIMIT/GOMAXPROCS control with verified read-back; SilentWindow, QuietGC, Snapshot
bench	Open-loop latency harness — coordinated-omission-safe, dual Latency/Service series, run-level GC CPU attribution
cmd/hotpathcheck	go vet-compatible analyzer enforcing //hotpath:noalloc across packages

Measured (Apple M4 Pro, go1.26.0, open-loop 100k ops/s)

A zero-allocation order book ran clean in isolation — then 4 neighbor goroutines triggered 338 GC cycles and its p99 went 0.9 µs → 16.5 µs (18×) despite allocating zero bytes itself. The process is the interference boundary; this library is how you see it. Full tables: BENCHMARK.md

Install

go get github.com/0xshikhar/go-hotpath/guard
go get github.com/0xshikhar/go-hotpath/profile
go get github.com/0xshikhar/go-hotpath/bench
go install github.com/0xshikhar/go-hotpath/cmd/hotpathcheck@latest

Compatibility

• Go 1.26+ recommended / 1.22+ minimum — CI runs 1.22 / 1.26 / 1.27 on linux/macOS
• Zero dependencies for the library; hotpathcheck is a standalone module on golang.org/x/tools
• Apache-2.0 — permissive; safe for closed-source integration

Docs: INTEGRATIONS.md · BENCHMARK.md · runtime/metrics audit

Full changelog: https://github.com/0xshikhar/go-hotpath/commits/v0.1.1