Make bulk built-ins interruptible by execution constraints (#2486)

[lahma]

Fixes #2486.

Problem

Several built-ins perform a full bulk operation in a single CLR call without per-step constraint checks, so a configured TimeoutInterval / MaxStatements / LimitMemory cannot interrupt them. For large inputs they either hang for seconds (no constraint can fire until the call returns) or the CLR throws System.OutOfMemoryException — which is not one of Jint's catchable constraint exceptions (TimeoutException, MemoryLimitExceededException, StatementsCountOverflowException).

The cases from the issue:

'x'.padStart(2147483647)        // hang, then OOM
'x'.padEnd(536870911, 'ab')     // hang, then OOM
Array.from({ length: 50000000 })// hang

This is the same fix class as #2349 (BigInt **) and #2465 (String.prototype.repeat, BigInt.asIntN/asUintN, Function.prototype.apply). The reporter and maintainer asked to also cover String.raw, Array.prototype.join, Array.prototype.sort, and any other affected sites, so this PR does the full sweep.

Approach

Two complementary mechanisms already present in the codebase are reused:

1. Hard size cap — ClrLimits.MaxArrayLength (0x7FFFFFC7). Converts a would-be OutOfMemoryException into a catchable RangeError, exactly as String.prototype.repeat already does.
2. Periodic constraint check — the established ConstraintCheckInterval = 10_000 idiom (already used by Array.prototype.fill/reverse/with, etc.):

   if (k > 0 && k % ConstraintCheckInterval == 0) _engine.Constraints.Check();

   A periodic Check() in a native loop lets all three constraints fire: time (stopwatch), memory (allocations accumulate as the structure grows), and statements (the counter increments per Check()).

A single giant up-front allocation can't be interrupted before it OOMs, so it is either pre-capped (mechanism 1) or built incrementally with periodic checks (mechanism 2).

Changes

String.prototype.padStart / padEnd (the issue) — rewritten:

• Use ToLength instead of ToInt32 so a large maxLength can't wrap and slip past the size cap (spec step 2).
• Resolve fillString (and run its ToString) only after the maxLength <= stringLength early return — fixes an observable side-effect-ordering bug.
• Throw a catchable RangeError("Invalid string length") when the result exceeds MaxArrayLength.
• Build incrementally with a bounded initial capacity + periodic checks, instead of Enumerable.Repeat + string.Join + Substring + interpolation (~3× transient allocation).

Array.from (the issue) — periodic checks in ConstructArrayFromArrayLike and ConstructArrayFromIEnumerable.

String.raw / fromCharCode / fromCodePoint — periodic checks in the element/char loops; size cap added to fromCharCode.

Array.prototype & %TypedArray%.prototype bulk loops — join, sort (collection/write-back), map, filter, forEach, reduce/reduceRight, find* (via FindWithCallback), slice, splice, unshift, shift, concat, toSpliced, toLocaleString, set, and the slow indexOf/lastIndexOf/includes scans. Dense primitive fast-path scans are intentionally left unguarded (they're tight, bounded by MaxArraySize, and the one place a per-iteration check would actually cost).

RegExp.prototype — @@replace / @@split / @@match outer match-collection loops.

JSON — JSON.stringify breadth (array/object/replacer) and JSON.parse array/object/string-literal loops (depth was already capped; breadth was not).

Not changed (already covered / fast paths)

• ArrayBuffer/TypedArray constructors — already capped at int.MaxValue.
• String.prototype.repeat single-char path, new Array(N) — already capped/lazy.
• Dense array fast-path scans — fast and MaxArraySize-bounded.

Performance

Reuses the % ConstraintCheckInterval idiom (RyuJIT lowers % const to a multiply+shift; the branch is predicted not-taken 9999/10000). The predicate is added only to loops whose body is already heavy (a JS call, property Get/Set, ToString, regex NextMatch), and the common small-input case runs the predicate a handful of times.

Measured with BenchmarkDotNet (--job short, net10.0, 1000 ops/benchmark), base (main) vs this branch:

Benchmark (1000 ops)	Mean before	Mean after	Alloc before	Alloc after
padStart (small)	223.6 µs	186.9 µs	188.7 KB	71.5 KB
padEnd (small)	231.2 µs	194.4 µs	204.3 KB	79.3 KB
filter (1000-elem)	138,494 µs	120,107 µs	48,095 KB	48,095 KB
forEach (1000-elem)	142,163 µs	150,465 µs	66,525 KB	66,525 KB
join (1000-elem)	7,230 µs	7,966 µs	7,688 KB	7,688 KB

• padStart/padEnd: ~60% fewer allocations and slightly faster — the rewrite removes the old 3× transient allocation.
• Guarded array methods: allocation counts are identical (the guard allocates nothing). The time deltas are within the noise of the ShortRun config — between two baseline runs filter alone varied 119,636 → 138,494 µs (±16%), which is larger than any of the before/after deltas.

Testing

• Full Test262: 99,015 passed, 0 failed (no regressions). The 70 padStart/padEnd conformance tests pass, confirming the ToLength + side-effect-ordering changes are spec-correct.
• Jint.Tests: 3024 passed, 0 failed, including new tests in ExecutionConstraintTests for the three issue repros plus String.raw, sort, an empty-callback forEach, padStart/padEnd correctness, and the fill-string side-effect ordering.

🤖 Generated with Claude Code