docs: add B2 reload-guard test protocol

This commit is contained in:
Dusk-92
2026-09-07 18:10:54 +02:00
parent d6262135a8
commit 5dde1f641e
+53
View File
@@ -0,0 +1,53 @@
# WeirdPerformance 2.4-B2 — GC Safe Sweep Reload Guard
Strict A/B experiment for WoW 1.12.1 build 5875.
## Baseline
Keep the validated 2.4-A binary unchanged:
- `weirdperformance.dll`
- SHA-256: `d35168ae06c19087ef9b7c68918a054640396dfbfcef0664e18e9372284b5eef`
## B2 variant
Add:
- `weirdperformance_gc24b2.dll`
B2 is generated from the ABI-fixed B1 source with one isolated behavioral change:
- whenever a new Lua `global_State` is observed (initial world entry, `/reload`, logout/relog), the first **3 GC collections stay fully native**;
- after those 3 native collections, the exact B1 incremental rootgc safe-sweep behavior resumes.
Nothing else is changed: same 50,000-object chunk size, same native mark/userdata/string work, same birth-mark ownership checks, same `lua_close` reconnect safety, same `IS_IN_WORLD` guard, no allocator changes, no generational age bitmap, no write barriers, no profiling/RDTSC.
The B2 delta is applied reproducibly by `b2_patch.py`; the build fails if any expected B1 source anchor no longer matches.
## Why this test exists
A delayed crash can be caused by corruption that happened earlier, so the crashing stack does not have to contain the GC companion. B2 specifically reduces risk during Lua state recreation without changing the core GC experiment.
## Installation
Keep both DLLs next to WoW and list both in `dlls.txt`:
```text
weirdperformance.dll
weirdperformance_gc24b2.dll
```
Remove `weirdperformance_gc24b1.dll` while testing B2. Never load B1 and B2 together.
Removing `weirdperformance_gc24b2.dll` returns exactly to the validated 2.4-A baseline.
## First test
1. Launch and enter the world.
2. Play normally for 10–15 minutes.
3. Do one `/reload`, then wait and play for several minutes.
4. If clean, do 10 `/reload` total.
5. Then test logout/relog and character changes.
6. Keep all other DLLs/addons/settings unchanged for the A/B comparison.
If an ERROR #132 occurs, keep both `Crash.txt` and `Crash.dmp` and note what happened shortly before the crash.