Fix issue #82: share match fail chain behind a thunk (exponential compile) #89
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/freebsd-78-82"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fix issue #82: exponential match compilation (freeze building ober/jerboa-code)
Root cause
Both match macro compilers —
src/jerboa/core.ss(compile-match-clauses)and
lib/std/match2.ss(compile-clauses, the prelude'smatch) — embeddedthe compiled rest-of-clauses chain as code at every failure point of a
clause's pattern (2+ per clause for list/vector/tagged patterns). Each clause
duplicated the entire remaining chain, so expansion size doubled per clause:
mr82-c101.32s,mr82-c127.37s,mr82-c1318.8s; c16/c20 infeasible..sosize grew ~1.55x per clause (0.68MB @ k=6 → 3.6MB @ k=10 →13.5MB @ k=13) on the biggus FreeBSD harness.
macro/codegen work markers growing 3.3k → 18k → 123k for the same steps.
Fix
Compile the rest chain once per clause position and share it behind a
zero-argument fail thunk (a
letrec-boundmatch-failgensym); every failurepoint emits a tiny call to that thunk instead of a copy of the chain. The
success body stays a plain spliced expression so it remains inside the
pattern's variable bindings (a first attempt that thunked the ok side too
lifted bodies out of scope — "variable v is not bound" — and was discarded).
The fail chain carries no pattern variables, so calling it from outside the
pattern's bindings is sound.
Also reverts the temporary issue-82 instrumentation from the vendored Chez
sources (
vendor/ChezScheme/s/{syntax,compile,cpnanopass}.ssare back tomaster state — verified
git diff origin/master -- vendor/is empty).Verification
Toolchain (mac arm64 + FreeBSD 15.1 biggus):
mr82-c101.32s→0.10s,mr82-c127.37s→0.09s,mr82-c1318.8s→0.10s;mr82-c16/mr82-c20now compile+run in ~0.1stest-match-syntax68/68,test-match262/62,test-match2-persistent30/30make test: 226 suites, 0 failuresmake binary(macOS gate) builds; notejerboa-bin --versionfails with"incompatible record type" on this Mac also on pristine master
(verified via
git stashrebuild) — pre-existing, unrelated to this changetests/test-issue82-regression.ss(22-clause wide chain + dispatchchecks) passes and is gated in FreeBSD CI
Real consumer
ober/jerboa-code@ 7cb9f19 (biggus, rebuilt toolchain 0.12.15):gmake buildexits 0;lib/jcode/ui/tui.sois now 377KBtest/run.ss: 1623 passed, 0 failedtest/security-regression.shfails only on a cross-device hardlink(
/tmpvs repo dataset on this box) — environmental, unrelatedVERSION 0.12.14 → 0.12.15.
Process disclosure: during diagnosis, vendored Chez sources were temporarily
instrumented (committed on this branch across earlier commits and reverted
here), and one interim
.ssscratch edit was made with python3 before thebalanced-edit tooling was enforced; no such edits remain in this diff.
bootquick fails on the previous layout: PB compiles the kernel patch sources through module->hash, which rejects new top-level bindings ("undeclared variable assignment to $jct-enabled?" then build-one fails). Kernel convention is per-file internal definitions (cross-file sharing goes through include files); each patched file now carries identical internal copies of the three $jct helpers. - cpnanopass: helper block moved inside the big let (before define-once) - compile sources: helper block inserted after the language includes - tools/jct-move: one-shot repair that performed the moveAdd chi-external parse-loop marker ('libform i, counter fic) and chi-frobs maplr marker ('cfr i, counter cfc) to vendor/ChezScheme/s/syntax.ss via one-shot transformer tools/jct-libform (make jct-libform), plus exact-indent probe tools/jct-probe2 (make jct-probe2). Purpose: identify which tui library body form freezes expansion during the FreeBSD ta6fb child compile.