Repository navigation
Commit edba986
test(facts): the subtree count's deep-chain test builds its 20,000-deep chain on the packed store, as a scan does - the reference store keeps every node's whole path, about 1.2 GB of the 2 GB heap GitHub's macOS runner gives Node, for a count that reads none of them (CI4 sweep)
Found by the CI4 sweep for tests that could run a 2 GB heap out. "a deep
chain does not overflow the stack" built its chain with ObjectScanStore
(the oracle), whose addNode joins each node's path from its parent's and
keeps it - endsWith copies the parent's whole path, so every node held its
own, the depth squared: the file's peak was 1,427 MB resident, and under a
1 GB heap it died with the same "Reached heap limit" in
String.prototype.endsWith -> StringSlowFlatten as CI run 39095045009.
Under CI's 2 GB it passed with a little over half the heap to spare.
buildCountTable reads only isDir, forEachChild and count, the same on
either store, so the property is unchanged: 20,000 folders deep, the one
file and every folder counted, no stack frame per level. Now 258 MB peak,
and the whole file passes under a 1 GB heap. The reference store's own
deep build is not what this test is about, and production keeps it only to
wrap trees that already carry a path on every node.
Mutant: buildCountTable made recursive - RED, "RangeError: Maximum call
stack size exceeded", before and after the change; restored and checked by
SHA-256.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>1 parent b4e514e commit edba986
1 file changed
Lines changed: 5 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
80 | 80 | | |
81 | 81 | | |
82 | 82 | | |
83 | | - | |
| 83 | + | |
| 84 | + | |
| 85 | + | |
| 86 | + | |
| 87 | + | |
84 | 88 | | |
85 | 89 | | |
86 | 90 | | |
| |||
0 commit comments