Parent: #496 Related: #493, #520, #611, #612
Problem
After #611 removed impossible parameter/body conflict indexes and #612 shortened raw identifier scanning, the current ReleaseFast 4K Unicode-parameter profile spends most of the parser half in Parser.validateStrictParams. Its StringHashMapUnmanaged starts empty even though the complete params.len upper bound is already known, so attacker-sized unique lists repeatedly allocate, grow, and rehash the same names before the strict-mode duplicate early error can be decided.
The current #612 exact-parent ASCII control performs 57 allocation requests and allocates 2,534,568 bytes per parse. The profile attributes 88 of 91 sampled validateStrictParams frames to getOrPut/growth and its string hashes.
Proposed resolution
Give strict simple-parameter uniqueness validation one capacity decision derived from the already-parsed formal-parameter count, then retain the existing exact string hash/equality insertion and duplicate rejection semantics. Do not change sloppy duplicate permission, destructuring BoundNames validation, generator/async/arrow/method rules, or parameter/body lexical conflicts.
If sharing the reservation primitive with other UniqueFormalParameters paths is measurably beneficial, it must reserve from an exact bound-name count rather than under-reserving an arena-backed map that later leaks a superseded table.
Acceptance
- Strict ordinary functions reject every duplicate,
eval,arguments, and strict-reserved binding accepted by the current validator. - Sloppy simple ordinary functions retain duplicate-name compatibility.
- Generator, async, arrow, method, default/rest, and destructuring uniqueness rules remain exact; no duplicate validation is accidentally performed twice.
- Empty and small parameter lists avoid unnecessary capacity allocation; wide valid lists avoid geometric growth and rehashing.
- Allocator exhaustion propagates without stale parser state or leaked scratch memory.
- Exact-parent 1K/2K/4K ASCII, escaped, and Unicode controls preserve checksums while reducing wide-list allocation requests/bytes and CPU work; direct/nested body controls remain exact.
- Focused parser/frontend Debug/TSan, full units, affected test262 subtrees, and forced tree-walker/required-bytecode witnesses pass.
Security boundary
Parameter count, name length, hash distribution, duplicate position, escape spelling, destructuring depth, and allocator failure are attacker-controlled. Capacity arithmetic must be checked, allocation must remain request-scoped scratch storage, equality must remain exact after hashing, and the algorithm must remain expected linear rather than introducing a quadratic pre-scan.
No-workaround rules
No parameter-count cap, approximate fingerprint equality, skipped Unicode/escape decoding, weakened early errors, source/benchmark recognition, AST widening, or jobs/Promise/microtask/Worker lifecycle changes.