Frontend: bound oversized radix BigInt conversion

Parent: #496 Related: #493, #480, #545

Problem

Oversized binary/octal/hexadecimal BigInt literals convert to canonical decimal text through a little-endian byte-per-decimal-digit ArrayList. Every source digit multiplies and carries across the growing decimal byte vector, while list growth and a second final output allocation amplify allocator and cache pressure. Property names and literal widths are attacker-controlled, so this conversion needs an explicit bounded representation and measured growth behavior.

Scope

• Commit parser-only 1K/2K/4K hexadecimal BigInt rows before changing conversion.
• Construct source and an independent exact decimal oracle before warmup; validate every output byte in every scored parse.
• Convert through bounded base-1e9 limbs with chunked radix ingestion and one exact canonical output allocation.
• Preserve binary/octal/hexadecimal values, case-insensitivity, separators, raw token text, offsets, small-value fast paths, leading zeros, arena ownership, and OOM atomicity.

No-workaround rules

• No preconverted scored source, oracle construction in the timed boundary, hash-only/output-prefix validation, reduced width, cache recognition, lazy conversion, arbitrary literal-length limit, third-party runtime BigInt, or different logical work between revisions.
• Do not modify stacks, queues, jobs, Promise/microtask behavior, or Thread/Worker lifecycle.

Acceptance

• Benchmark-first 1K/2K/4K rows freeze exact input/output identities, checksums, warmup, and parser-only timed boundaries.
• Exact-parent evidence reports wall, retired instructions, logical allocation requests/bytes, RSS, dispersion, and identical full-output checksums.
• Scratch capacity is calculated before conversion, bounded by input width, and output uses one exact allocation without byte-list growth/remap.
• Binary/octal/hex, upper/lowercase, separated/unseparated, leading-zero, small/large value, raw text, offsets, and OOM witnesses pass.
• Growth evidence remains visible at 1K/2K/4K; no claim hides the algorithmic class or moves conversion outside the boundary.
• Focused lexer/frontend, full units, BigInt test262, and TSan pass with no regressions.
• Raw evidence and report are checked in before any public performance claim.

Benchmark-first commit faa21251 is on main with no runtime change.

Frozen parser-only workloads:

• representative_frontend_bigint_hex_1024 → checksum 3558546504
• representative_frontend_bigint_hex_2048 → checksum 1043763980
• representative_frontend_bigint_hex_4096 → checksum 367560449

Source and an independent std.math.big.int.Managed decimal oracle are constructed once before ten reduced-work warmups. Every scored parse compares every canonical decimal output byte with that oracle; validation is not hash-only. Initial ReleaseFast medians are approximately 1.2 / 4.5 / 17.0 ms for 1K / 2K / 4K, keeping the current roughly quadratic growth visible before the conversion changes.

Completed on main in three traceable commits:

• faa21251 bench(frontend): add radix BigInt growth rows (#546)
• 727d87a5 perf(frontend): bound radix BigInt conversion (#546)
• 552a77a5 docs(frontend): publish radix BigInt evidence (#546)

The conversion now precomputes bounded base-1e9 scratch capacity, ingests maximal radix chunks, and emits canonical decimal digits into one exact output allocation. It preserves binary/octal/hexadecimal syntax, separators, case, leading zeros, the small-value fast path, token metadata, arena ownership, and OOM atomicity.

Validation:

• focused radix conversion: 2/2
• lexer: 16/16
• frontend: 12/12
• full units: 1,611 passed, 1 skipped, 0 failed, 0 leaked
• focused TSan: 2/2, no reports or leaks
• exact-parent test262: BigInt 59 → 59; numeric literals 157 → 157
• all three checked-in raw artifacts pass performance-attribution validation

Seven-pair exact-parent diagnostic evidence at 1K/2K/4K hexadecimal digits measures candidate wall ratios of 0.018x/0.017x/0.016x and instruction ratios of 0.0229x/0.0184x/0.0164x. Allocation requests fall 26.7%/31.3%/38.9%, with a fixed eleven requests per parse in the candidate. The report also preserves the approximately quadratic doubling ratios instead of claiming an algorithmic-class change.

Aggregate evidence: docs/.data/exact-parent-frontend-bigint-hex-2026-08-12.md