Re-check amortized constraints at interpreter/host-code boundaries

[lahma]

Summary

Discussion #2707 reports that since #2672 a CancellationToken (or timeout) can go unobserved when a loop's time is spent inside host (CLR) calls:

var engine = new Engine(o => o.CancellationToken(cts.Token));
engine.SetValue("sleep", (Action<int>)(ms => Thread.Sleep(ms)));
cts.CancelAfter(TimeSpan.FromMilliseconds(200));
engine.Execute("for (let i = 0; i < 40; i++) { sleep(100); }"); // pre-fix: runs ~4 s to completion

The amortization introduced in #2672 bounds time/cancellation detection latency in statement count (64 statements). That is a valid wall-clock proxy only while statements stay cheap; a statement that calls user CLR code can take arbitrarily long, so a loop of slow host calls stretches the 64-statement window to minutes.

Fix

Re-check the amortized constraints when control returns from user CLR code to the interpreter. Detection latency is again bounded by one host call, as it was pre-#2672 (which checked before every statement). The mechanism's boundaries are deliberate:

• Only after the host call returns, never on entry — an entry check would block host cleanup calls (e.g. a release-the-lock delegate inside a JS finally block) once cancellation is pending.
• Only while script evaluation is active — constraint state is only meaningful inside an Execute/Invoke window: the time constraint's CTS is re-armed at the end of every run and keeps counting while the engine is idle, and a token cancelled during normal teardown must not make later C#-side reads of wrapped objects throw.
• Not in debug mode — a debugger paused longer than the timeout would otherwise deterministically fail every interop read in watch/conditional-breakpoint evaluation.
• Awaitable delegate results reach promise conversion before the check, so an in-flight Task always gets its continuation attached and is never dropped unobserved.

Covered boundaries:

• DelegateWrapper — user delegates registered via SetValue (the discussion's repro)
• MethodInfoFunction — method calls on wrapped CLR objects
• TypeReference.Construct — all three creation branches (reflected constructors, Options.Interop.CreateTypeReferenceObject factory, Activator value-type path)
• ReflectionAccessor.GetValue/SetValue — ObjectWrapper property/field/indexer reads and writes
• The dictionary interop lane (TryGetDictionaryValue/TrySetDictionaryValue on wrapped IDictionary<,>)
• The wrapped-IEnumerable iterator lane (MoveNext in for-of)
• The Options.Interop.MemberAccessor callback

Intentionally not instrumented: built-in ClrFunction dispatch (would reintroduce the per-call cost on hot built-ins that #2672 removed; long-running built-ins self-check via Engine.ConstraintCheckInterval), operator-overload resolution (its catch-all would launder constraint exceptions into TargetInvocationException), and user-supplied converter/factory callbacks — embedder-authored code hosting long operations can observe the CancellationToken itself.

Why not an option to disable/tune the amortization?

Considered and rejected: an interval knob would force embedders to trade performance for correctness and leave the default behavior broken for the reported scenario. The boundary re-check restores the wall-clock bound automatically with no new API surface. The checks are volatile-bool reads (~1–2 ns) on paths that already do reflection/delegate dispatch (hundreds of ns to µs); unconstrained engines pay only an empty-array length check.

Verification

The discussion repro now throws ExecutionCanceledException after ~290 ms — the 200 ms CancelAfter plus the in-flight 100 ms sleep whose return observes the cancellation (pre-fix: runs the full ~4 s to completion).

12 new tests in ExecutionConstraintTests:

• Deterministic cancellation tests (token cancelled from inside the 3rd host call, exactly 3 calls asserted) for: delegate calls in a top-level loop and in the tight for-body lane, CLR method call, property read, property write, CLR constructor, dictionary read, and for-of iteration.
• A lone-host-call test that isolates the post-invoke check (no further host call or countdown follows, so only the check at that call's own return can observe the cancellation).
• Regression guards: host-side C# reads of wrapped objects must not throw after post-execution cancellation or after the idle-engine time budget expires, and debug-mode engines keep the pre-existing countdown-only behavior.

Full Jint.Tests, Jint.Tests.PublicInterface, Jint.Tests.CommonScripts and Test262 suites pass on net10.0 and net472.

Benchmarks

InteropLambdaBenchmark.ForLoop (hot wrapped-object property reads — ClrObject exercises ReflectionAccessor.GetValue, Dictionary exercises the newly covered dictionary lane), same-machine back-to-back A/B:

Type	main	this PR
ClrObject	14.015 μs	13.382 μs
JsonNode	36.586 μs	34.178 μs
Dictionary	23.889 μs	22.016 μs
JsValue	9.691 μs	9.872 μs

Deltas are within run-to-run variance (signs flip across measurement windows) and allocations are byte-identical — expected, since an unconstrained engine pays only an empty-array length check per boundary and a constrained one two volatile bool reads.

Fixes the scenario reported in #2707.

🤖 Generated with Claude Code