stream: decouple transform backpressure changes

[mcollina]

Thirteenth round of pure-JS webstreams optimizations. Stacked on #65138 — the first three commits are that PR; please review only the last commit (stream: decouple transform backpressure changes).

The transform stream's [[backpressureChangePromise]] is observed only internally: by the source pull algorithm (settles when backpressure next becomes true) and by a sink write arriving under backpressure (settles when it next becomes false). On the pipeThrough passthrough shape both flips are observed on every chunk, so the record plus its reactions and the performTransform async-wrapper pair accounted for roughly 10% of the profile.

• Continuation slots instead of the promise record. A parked pull returns a sentinel (kParkedAlgorithmResult) and the next backpressure→true flip enqueues the readable controller's cached pull-fulfilled step on the shared resolved promise — the exact microtask position of the old record's reaction. A parked write stores the chunk plus one promise record; the false-flip runs a cached per-stream continuation that resolves it with the perform-transform promise, and adoption reproduces the previous derived-chain settle depth bit-for-bit. Erroring/cancel paths deliver through the same flip (transformStreamUnblockWrite), rejecting inside the continuation microtask like the old reaction-throw did.
• Reference-exact performTransform. transformStreamDefaultControllerPerformTransform now mirrors the reference implementation's promiseCall(transformAlgorithm, …).then(undefined, rejectionSteps) directly: the transformer.transform callback is wrapped raw, a non-thenable result reuses the shared resolved promise, and a synchronous throw is delivered through a rejected promise so the stream is still errored inside a reaction, not synchronously.
• New pipe-through benchmark, since the suite had no transform-throughput row.

Benchmark results (30 runs, vs the #65138 head):

                                                                  confidence improvement accuracy (*)    (**)   (***)
webstreams/pipe-through.js kind='default' n=500000                         *      8.73 %       ±7.15%  ±9.52% ±12.39%
webstreams/pipe-through.js kind='transform' n=500000                              8.34 %       ±8.80% ±11.70% ±15.24%

A writer-driven write()/read() transform loop improves ~14% in spot runs. creation, js_transfer, pipe-to, and the read families are unchanged (all n.s.; the machine's ambient load makes the confidence intervals wide — direction was consistent across interleaved spot runs).

Verified with the WPT streams/compression/encoding suites, the full parallel webstream/whatwg set, and a transform-specific ordering stress (writer-driven backpressure parking with microtask-depth probes, reentrant reads inside transform(), terminate() mid-stream, rejected/throwing transforms, reader cancel with a parked write, chained pipeThrough) whose event log is byte-identical to the #65138 head.

[nodejs-github-bot]

Review requested:

• @nodejs/performance

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.33%. Comparing base (347e266) to head (0195e8e).
⚠️ Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #65143      +/-   ##
==========================================
+ Coverage   90.30%   90.33%   +0.02%     
==========================================
  Files         759      759              
  Lines      248294   248489     +195     
  Branches    46860    46881      +21     
==========================================
+ Hits       224220   224465     +245     
+ Misses      15516    15468      -48     
+ Partials     8558     8556       -2     

Files with missing lines	Coverage Δ
lib/internal/webstreams/readablestream.js	98.18% <100.00%> (+0.02%)	⬆️
lib/internal/webstreams/transformstream.js	98.68% <100.00%> (+0.12%)	⬆️
lib/internal/webstreams/util.js	97.10% <100.00%> (-0.61%)	⬇️
lib/internal/webstreams/writablestream.js	99.52% <100.00%> (+<0.01%)	⬆️

... and 36 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pacocartones]

Independent verification — continuation slots are behavior-equivalent to [[backpressureChangePromise]]

Reviewed the last commit (0195e8e2cd) in isolation against its parent (0ff1bfc362). I traced every transition and the refactor preserves observable behavior; the design is sound.

Mutual exclusion of the two parked states: a pull is parked while backpressure is false (the pull algorithm sets it false, then parks), a write while it is true. The assert(state.backpressure !== backpressure) guarantees one direction per call, so the true-flip can only deliver a parked pull and the false-flip only a parked write — never both, no ambiguity.

Pull side: pullFulfilled is created by the readable controller before the pull algorithm is invoked (readableStreamDefaultControllerCallPullIfNeeded creates it lazily on first pull), and the algorithm-clearing paths don't touch it — so it is always present when a flip delivers it. kParkedAlgorithmResult makes thenAlgorithmResult return early, which leaves controller[kState].pulling = true (correct: the pull is in flight) until the true-flip schedules pullFulfilled on the shared resolved promise. That is the same settle depth the old materialized change promise had, and since that promise was only ever resolved, the skipped rejection path is genuinely unreachable. pullAgain re-pull works because pullFulfilled clears pulling and re-invokes callPullIfNeeded.

Write side: one pending slot is safe because the writable dispatches writes serially (the assert(state.pendingWrite === undefined) backs the comment). The cached continuation rejects with storedError when erroring, otherwise resolves the pending write with the perform-transform result; resolve-with-promise adoption reproduces the old derived-chain settle depth exactly.

performTransform: the raw callback plus the memoized performTransformRejected mirrors the reference promiseCall(...).then(undefined, rejectionSteps): results are coerced with PromiseResolve, non-thenables take the kResolvedPromise fast path (same microtask depth as the old await), and a rejection errors the stream before rethrowing. The transformAlgorithm === undefined early return covers the concurrent cancel/abort/close clear, matching the old return; in the async wrapper.

Shared kResolvedPromise vs per-stream promises: reactions on an already-resolved promise run FIFO at the next microtask checkpoint, and flips schedule them in flip order, so cross-stream ordering matches the old per-stream change promises.

Erroring while parked: if the stream errors while backpressure stays true, the parked write waits for a flip in both the old and new code (the change promise was never rejected) — spec-conformant, no regression.

Two non-blocking nits:

• writeContinuation is cached for the stream's lifetime via ??=; negligible, but it could be cleared after use for symmetry with pendingWrite/pendingWriteChunk.
• The nonOp* consolidation is a pure merge (same raw-callback contract); the benchmark additions are additive.

LGTM.