probe(vm): comment-only control for the repeat A/B noise floor

[mparrett]

Measurement control. Do not merge. Closing it once the numbers land, same as #691.

The entire diff is a comment. The point is to push a build with identical machine code through the repeat A/B lane, so whatever deltas come back are the lane's own noise at N=7 rather than a property of any change.

The code really is identical

Worth checking rather than assuming, since the whole value of the control rests on it. Built base and head with -trimpath and compared:

• go tool nm: 12907 symbols in both, at identical addresses — same layout, nothing moved.
• __text section: 0x338184 bytes in both.
• The binaries do differ, but only near the start of the file: the Go build ID hashes the source bytes, and a comment is a source byte.

So this holds code and placement constant, which is what makes any reported delta attributable to the harness and the runner alone.

Why now

#706 is a semantically inert change — it deletes a *Frame parameter that was never read. On this lane it measured SeqIteration/List/01000 +8.30% and FrameDispatch +4.97%, each consistent across all seven cycles, alongside −0.75% on FuncInvoke/Direct. I could not tell from that run whether those are real or whether the lane can produce numbers that size on its own, and that is not a question #706 should have to answer.

It is also the measurement #705 §1 is about. The 5% ratchet budget has never been checked against a measured floor, and #564 already found byte-identical binaries landing 3.7% and 1.1% apart on two packages.

Reading the result

• Swings of the same order as vm: drop leaveFrame's unused *Frame parameter to unpin f from memory #706's (five to eight percent on those families) — the lane's floor at N=7 is far above the 5% budget on memory-bound families. vm: drop leaveFrame's unused *Frame parameter to unpin f from memory #706's numbers carry no information, and the budget needs per-family or per-tier calibration before it can gate anything.
• Flat, say within one or two percent — the lane is trustworthy at N=7, and vm: drop leaveFrame's unused *Frame parameter to unpin f from memory #706's swings are a property of its binary. That would not yet say which property: this control holds layout constant, so it cannot distinguish code placement from a changed inlining or register-allocation decision. Separating those needs a second control that perturbs placement without changing semantics, which is only worth building if this one comes back flat.

Either way the number is worth having, and it belongs on #705 rather than buried in a PR thread. I will post it there too.

[mparrett]

Closing this — it did its job. Numbers below, and the combined analysis of all three A/A runs is on #705.

This run, comment-only diff so the machine code was identical (verified: same symbol addresses, same __text size, only the build ID differs):

• 53 families, clean at 6, 8 and 10%.
• Largest median move: −12.91% on VectorCreation/ArrayVector/10000. Negative, so it did not trip the gate, which is itself worth noting — a budget that only looks at regressions misses half of what the noise does.
• Largest single-cycle swing: 49.66%.

Taken with the two accidental A/A runs on #708, the conclusion is that the floor is per-family and spans roughly 0.3% to 13.4% on this tier. The allocation-heavy families at sizes 1000 and 10000 are where nearly all of it lives; 29 of 53 families stay under 2%. Details and the per-family table are on #705.

The one thing I would carry forward from building this: a deliberate control was not needed. Both of the other samples came from PRs that happened to touch no Go source, and this repo produces those routinely. Recording A/A results when they occur would accumulate the per-family floor for free.