Sweep #64 interim checkpoints: 708 oom_kill out of ~65k records, concentrated — 496 mui__material-ui, 141 Multi-SWE instances, 69 huggingface__transformers, 2 microsoft__vscode. Container limit 44g, RAYON_NUM_THREADS=1, workers=10.
The edge-pipeline interning fix (3a6da4a, "halve graph peak memory, Go OOM fix") evidently does not cover the mui-class JS monorepo profile: these die inside the 44g cgroup with exitcode -9 (_handle_process_expired -> status=oom_kill).
To do:
- profile ONE mui instance on the dev build (peak RSS by phase — fragmentation vs edge collection vs graph vs scoring;
latency_breakdown already exposes counts, not bytes);
- identify the dominant allocation (suspects: fragment content strings for huge vendored JS, per-builder intermediate edge maps inside the parallel closure, tree-sitter parse trees);
- fix or bound it; success = mui instances complete inside the same 44g limit.
Recovers ~1% of sweep data and unblocks real-world use on mui-scale JS monorepos. Related but distinct from #70 (wall-clock hangs).
Sweep #64 interim checkpoints: 708 oom_kill out of ~65k records, concentrated — 496 mui__material-ui, 141 Multi-SWE instances, 69 huggingface__transformers, 2 microsoft__vscode. Container limit 44g, RAYON_NUM_THREADS=1, workers=10.
The edge-pipeline interning fix (3a6da4a, "halve graph peak memory, Go OOM fix") evidently does not cover the mui-class JS monorepo profile: these die inside the 44g cgroup with exitcode -9 (
_handle_process_expired-> status=oom_kill).To do:
latency_breakdownalready exposes counts, not bytes);Recovers ~1% of sweep data and unblocks real-world use on mui-scale JS monorepos. Related but distinct from #70 (wall-clock hangs).