Refresh async memory accounting for current runtime

[sebastienros]

Summary

• refresh Account memory across async continuations #3036 memory accounting onto the current pump-driven web/runtime seams
• carry allocation state through finite continuations (fetch/streams, timers, idle callbacks and scheduler tasks) while giving persistent external events a fresh per-delivery budget
• coordinate memory segments with nested cross-thread callback ownership transfer and preserve fatal constraint provenance across host Tasks
• abort and clean transient async work safely when a memory operation exceeds its budget

Context

Follow-up to merged #3036. This is the semantic current-main refresh requested in the cascade review comment. The latest QuotaExceededError, pump-driven timeout, ownership, WPT and web-API changes remain intact.

Validation

• all-target dotnet build Jint/Jint.csproj -c Release
• full unit suite: 9,810 passed / 5 skipped (excluding the known local timezone-sensitive year-10000 test)
• public interface: 2,105 passed / 9 configuration skips
• host-contract public interface: 2,109 passed / 5 inverse-configuration skips
• focused memory/concurrency/web stress: 112 passed per run, repeated 3 times
• post-rebase focused unit tests: 352 passed
• post-rebase focused public tests: 112 passed
• git diff --check

Benchmark project restore is currently blocked by the mandated package proxy not carrying YantraJS.Core 1.2.462 (nearest available 1.2.422); no alternate feed was used.

[lahma]

Heads-up on the rebase this now needs: the merged #3036 carries one thing that was not in the version you refreshed from.

main had grown around thirteen cross-thread AddToEventLoop sites since #3036 was written — timers, fetch, streams, WebSocket, EventSource, MessagePort/BroadcastChannel, finalization-registry cleanup — and none was in that PR's stated scope. Rather than quietly extend the budget into them, the merged version adds an explicit unaccounted overload, AddToEventLoop(Action continuation, int generation), whose doc comment names those subsystems and says that extending the budget to them is a deliberate change with its own tests.

That is precisely what this PR does, so on rebase those call sites should move to the three-argument accounted overload, and the unaccounted one can go with them if nothing is left using it. Keeping it around after this lands would just be a documented hole nobody needs.

Everything else in #3036 is as you had it; the only other change from the refresh was composing ConstraintFailure.MustPropagate over Throw.MustPropagateHostException rather than keeping two overlapping lists.

[lahma]

Rebased onto main (9817530) and pushed, with a second commit for what the rebase and a read-through turned up. Your commit is untouched underneath it, so the two are reviewable apart.

What main had grown under this

ConstraintFailure was the only textual conflict, and the interesting one. Main's version composes over Throw.MustPropagateHostException, and that list already carries a marker: Throw.TimeoutException and Throw.OperationCanceledException register what they mint in EngineAbortRegistry, so Jint's own timeout and cancellation are already distinguishable from a host's. This PR brought a second marker for the same job — an Exception.Data key, Throw.Constraint*Exception duplicates of three helpers, and a MemoryLimitPlatformNotSupportedException subclass — plus a standalone list to read it with. I dropped all of it and kept what it was for, in the one place that actually needed it: the faulted-Task scan in ConvertTaskToPromise reads Throw.MustPropagateHostException rather than ConstraintFailure.MustPropagate. The distinction matters exactly there — for a queued turn a TimeoutException is Jint's own and nothing else, but for a host Task it is an HttpClient timeout, and HostTaskTimeoutRemainsACatchablePromiseRejection still passes because of it.

Constraint.BeforeFailure went too. The same commit added Engine.CheckConstraint, which does the same job at the call site and covers user-derived constraints the hook could never reach — DirectAccessorMemoryTeardownDoesNotMaskACustomConstraintFailure only passes because of the wrapper, not the hook. Two mechanisms for one thing; the hook was the one that also put a settable property on the public Constraint base and a delegate per constraint per engine. It is now a try around each of the three constraint loops rather than a wrapper per constraint, so the non-throwing path is unchanged instruction for instruction, and the filter excludes JavaScriptException — script can catch that one, and abandoning the operation under it would hand the script a fresh budget.

On the AddToEventLoop note

I did not move the thirteen sites, because this PR's answer is better than the one I suggested and the diff argues it: a WebSocket frame or a MessagePort delivery is not one finite continuation of the operation that created the object, so inheriting that operation's budget would fail a long-lived socket permanently once the creating operation had spent it. Keeping the unaccounted overload for those, with the doc rewritten to say so, is right.

What I did do is collapse the accounted overloads. EventLoopRegistration is exactly (generation, memory state), so (Action, int, OperationState?) and EnqueueModuleLoadCompletion's triple were a second spelling of it; five overloads are now three, and ModuleLoadCompletion and the Atomics.waitAsync waiter each lose a field. Same for HostStreamBridge, which parked the registration in a field for the next line to read — TryBeginOperation hands it back instead, and the now-unread Generation goes with it. GetHostCallbackOwner no longer returns an owner, so it is GetHostCallbackAuthorization.

Two defects

setInterval inherited one budget and charged every tick to it. The rule this PR states is that repeating work starts fresh and only finite continuations inherit — but its docs list "timers" as finite, and TimerEntry carries one registration for the life of the entry. So an engine with LimitMemory and a heartbeat that allocates a few bytes a second dies after enough ticks. A repeating TimerEntry now keeps the cycle stamp and drops the budget, which is what every persistent event source already does; AnIntervalStartsAFreshBudgetOnEveryTick fails without the fix. README and THREAT_MODEL now say setTimeout where they said "timers".

The teardown could run twice. MemoryLimitConstraint.Check → AbortMemoryLimitedOperation → ResetTransientEvaluationState runs host code — a worker host told its connection ended, a host stream disposed — and host code may re-enter the engine, where the next statement check finds a fresh operation over the same budget and starts a second teardown from inside the first. Guarded to run once.

Also folded Check's double-throw into an if/else (both branches threw), documented AbortMemoryLimitedOperation and RunWithMemoryAccounting, and reverted a signature-reflow in Host.cs that had no change in it.

Two things worth a second opinion before this lands

• The teardown's blast radius. ResetTransientEvaluationState is engine-wide, so on net8+ a memory overrun in one operation ends every worker connection the engine is party to and closes every host-stream bridge, not just the failing operation's. That is what makes the limit end the work rather than report on it, and it is documented in both files — but it is a real behaviour change for a pooled engine, and it is the piece I would most want you to confirm is the intent.
• Moving EndOperation() off the engine thread in the stream bridges is right, and it fixes a latent leak on main: EndOperation's own doc says it must be called before the completion is enqueued precisely because a job can be dropped by the generation fence, and the code called it inside the job. The consequence is that ReleaseHostStream — and therefore HostStream.Dispose() — can now run on the I/O completion thread rather than the engine thread. Consistent with the class's stated split, but worth naming.

Validation

All on the rebased head, Release.

suite	result
Jint.Tests	10,052 net10.0 / 7,102 net472, 0 failed
Jint.Tests + Jint.Tests.PublicInterface, JINT_HOST_CONTRACT_VERIFICATION=1	0 failed
Jint.Tests.PublicInterface	2,395 net10.0 / 1,874 net472, 0 failed
Jint.Tests.CommonScripts	28 + 28, 0 failed
Jint.Tests.SourceGenerators	52, 0 failed
Jint.Tests.Test262	102,488 passed, 7 failed — see below

The seven are staging/sm/TypedArray/{element-setting-converts-using-ToNumber,sort_large_countingsort}.js, ArrayBuffer.prototype.sliceToImmutable/argument-coercion.js and Atomics/notify/notify-renotify-noop.js, all of them 30-second engine timeouts on a loaded machine. main at 9817530 fails the same set on the same box — 22 of them in one full run, and 3 of 3 when the subset is run alone against each branch in turn. No delta.

Not benchmarked. Two things touch a hot path and both look free by inspection: HostCallScope grows two fields whose only writer is the transferred-callback constructor (SROA'd, constant branch in Dispose), and the constraint loops gain a try region that emits nothing until it throws. Say the word if you want a gate run on EngineConstructionBenchmark / EngineComparisonBenchmark anyway.

[lahma]

CI is green on 5cc597f8a — all five legs, including windows and linux - host-contract verification. MERGEABLE / CLEAN.

The first windows attempt failed and the re-run of the same commit passed. Both failures were wall-clock, and neither engine in them configures LimitMemory, so every path this PR touches is inert for them — RunEventLoopJob takes its memoryLimit is null early return, and CaptureEventLoopRegistration() yields (generation, null), which makes the rewritten enqueues byte-equivalent to the ones they replaced.

I reproduced the deadline one on both trees anyway rather than assume, by pinning the test host to two logical CPUs under contention: main 1/12, this branch 3/12, and 0/40 on each once the box was quiet. It is the OperationDeadlineConstraint budget-split family already tracked in #3221, whose standing rule is a budget-widening fix on recurrence — evidence and a proposed fix shape are in that issue rather than here, since the test belongs to #3046 and not to this PR. The second failure, WebApiMultipartTests.ReadsAMultipartResponseBackAsFormData hitting the 10 s PromiseTimeout on an in-memory HttpMessageHandler, is noted there too; it did not reproduce in 52 pinned runs on either tree.

Test262 on the CI runner: 102,495 passed, 0 failed. (The seven I reported locally were all 30 s engine timeouts on a loaded box, and main failed the same set there.)