ReviewOS

home-lang/home

Bun parity: port Blob synthetic OOM and lazy segment semantics

#338
Closed chris opened this 10 days ago ·
10 days ago

Corpus position 4110, js/web/fetch/blob-oom.test.ts, currently times out after five minutes while consuming sustained CPU and roughly 700 MB RSS.

Root cause: the Home corpus Blob implementation eagerly converts each 64 MiB ArrayBuffer part through Array.from, then appends nine copies byte-by-byte in JavaScript. It does not model Bun synthetic allocation limits at the Blob/body-operation boundary, so the intended deterministic OOM cases become pathological materialization loops.

Port the real semantics without reducing upstream sizes or counts:

  • preserve large Blob parts as lazy/segmented storage while retaining arbitrary byte content and slice behavior;
  • enforce the synthetic allocation limit for Blob, Response, Request, and Bun.file text/JSON/bytes operations with Bun-compatible messages;
  • keep arrayBuffer operations allowed where the upstream suite requires them;
  • release segment references and temporary materializations deterministically;
  • surface permanent structured allocation errors with operation, requested size, configured limit, original cause, and source-aware composed stacks;
  • pin positions 4109 and 4110 in the permanent HTTP/web queue and update #66.

Current evidence: positions 4107 (11 pass), 4108 (1 pass), and 4109 (1 pass) are green. The first contiguous gap is 4110.

10 days ago

Completed in c212cd21c.

The eager JavaScript number-array expansion has been replaced with immutable large-part segments. Repeated ArrayBuffer parts are snapshotted once, preserve arbitrary bytes after source mutation, and retain byte-exact slicing across segment boundaries. Materialization uses native typed-array copies rather than per-byte JavaScript loops.

Synthetic allocation limits now apply at the correct operation boundary for Blob, Response, Request, and Bun.file text/JSON/bytes methods, while the upstream arrayBuffer cases remain allowed and return full byte-accurate buffers. Allocation failures are permanent structured ERR_BLOB_ALLOCATION RangeErrors carrying operation, requested size, configured limit, original cause, and a source-aware composed stack.

Verification:

  • js/web/fetch/blob-oom.test.ts at the original 64 MiB parts: 16 passed, 0 failed/todo/unsupported in about three seconds;
  • focused immutable-segment, seam-slice, synthetic-limit, cause, and stack regressions: 3 passed;
  • blob-file-name-ownership.test.ts: 1 passed and now permanently pinned;
  • full permanent HTTP/web tail queue: passed;
  • zig fmt --check, git diff --check, and clean-cache project build: passed.

Closing as complete.

Sign in to comment on this issue.