docs: the v2 baseline holds on a second healthy run

Run 7 ended NO FREEZE within 1100s with the same shape as run 5: the same three
threads, the same ceiling of 13 distinct objects, and not one non-SUCCESS window
in 544 across both runs. The v1 stuck-wait side reported its usual single pair.

Run tally since v2 is three runs and no frozen sample - GAME OVER at ~22 min,
EMULATOR GONE at 810 s, and no freeze in 1100 s.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Sylpheed RE agent
2026-08-24 09:00:18 +00:00
parent 9cbef1f847
commit d35e99f95d

View File

@@ -510,3 +510,23 @@ run (342 MB resident here) and `run-canary` only clears it at *launch*; and
`vm.drop_caches` is not writable in the container (read-only `/proc/sys`), so
page cache can only be left to the kernel to reclaim. Clearing the stale shm
files between runs is the one lever available.
### The v2 baseline holds on a second healthy run (run 7)
`NO FREEZE within 1100s`, and the same shape as run 5 — so the control is
measured twice:
| thread | run 5 windows / peak / objects | run 7 windows / peak / objects |
|---|---|---|
| `F8000008` (main) | 224 / 1 235 / 13 | 167 / 947 / 13 |
| `F8000234` | 47 / 919 / 10 | 35 / 830 / 8 |
| `F800025C` | 41 / 819 / 7 | 28 / 737 / 7 |
| result | SUCCESS ×314 | SUCCESS ×230 |
Same three threads, same ceiling of **13 distinct objects**, and **not one
non-SUCCESS window in 544** across both runs. The v1 stuck-wait side reported its
usual single pair (`BE56BB5C`) and nothing else.
**Run tally since v2: three runs, no frozen sample** — GAME OVER at ~22 min
(run 5), `EMULATOR GONE` at 810 s (run 6), and no freeze in 1 100 s (run 7).