bundler: size each chunk's renamer name table from the chunk, not the whole bundle

[Jarred-Sumner]

What does this PR do?

NumberRenamer::init (#41286) pre-sizes its root name table — the ids hash map and the slots vec — to root_names.len() + symbol_count / 4, where symbol_count is summed over symbols.symbols_for_source, i.e. every symbol in the bundle. That is fine for a single chunk, but with --splitting generateChunksInParallel builds a renamer for every chunk up front and each one stays alive in chunk.renamer until its chunk has been printed. So a build with N JS chunks reserves N bundle-sized tables at once.

On a large app that splits into ~800 chunks (~1M symbols), each chunk reserved a ~4.4 MB hashbrown table plus a ~3 MB Vec<NameSlot> and used a few hundred entries of it:

	peak RSS (Linux, 4 cores)
before #41286 (858f4e7)	6.2 GB
main	7.7 GB
this PR	6.2 GB

Linux only pays for the pages that get touched (the control-byte memset plus scattered inserts, ~2 MB per chunk). On Windows mimalloc commits the whole block when it is allocated, so the same build carried several GB of extra commit charge and, on a machine with a small commit limit, bun build aborted with memory allocation of 4456464 bytes failed — 4,456,464 bytes being exactly this table (262,144 × 16-byte (StoreStr, u32) buckets + control bytes).

The fix sizes the table from the symbols of the files in the chunk (files_in_order), which is what the chunk's renamer can actually add. A non-splitting build has one chunk containing every file, so it reserves exactly what it did before and the #41286 benchmarks are unaffected.

How did you verify your code works?

Measured the build above with release builds of 858f4e7, main and this branch, pinned to 4 cores, two runs each (numbers in the table; run-to-run spread ±0.1 GB). Page-fault profiles of main attribute the extra faults to renamer::intern_into and hashbrown's control-byte memset under NumberRenamer::init; both disappear with this change. Output is byte-identical (capacity is only a hint; intern grows the table on demand).

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Essentials

Run ID: 3bd8f058-c119-4262-ba27-719a84280abb

📥 Commits

Reviewing files that changed from the base of the PR and between 62838e1 and f177054.

📒 Files selected for processing (2)

• src/bundler/linker_context/renameSymbolsInChunk.rs
• src/js_printer/renamer.rs

Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

Walkthrough

The linker now computes the total symbols in each chunk and passes that value to NumberRenamer::init. The renamer sizes its name ID map and slot vector from the chunk-local count.

Changes

Chunk symbol renaming

Layer / File(s)	Summary
Chunk count and renamer capacity src/bundler/linker_context/renameSymbolsInChunk.rs, src/js_printer/renamer.rs	The linker sums symbols across chunk files and passes the total to NumberRenamer::init. The renamer uses the chunk count to size both name IDs and slots.

Suggested reviewers: robobun

Merge Risk: ⚪ Minimal · up to f1770

Chunk renamer capacity is now sized from symbols in each chunk, reducing memory use for splitting builds while retaining bundle-wide sizing for a single chunk. No current merge-blocking risk remains.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description includes both required sections. It clearly explains the chunk-local sizing change, its memory impact, non-splitting behavior, and verification results.
Title check	✅ Passed	The title clearly and concisely describes the main change: each chunk's renamer name table is sized from chunk symbols instead of the entire bundle.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

LGTM — capacity-hint-only change, output is unaffected.

What was reviewed:

• Confirmed NumberRenamer::init has a single call site (this one), so no sibling callers to update.
• Verified files_in_order holds source indices and symbols_for_source is indexed by source index — same pattern as the surrounding all_module_scopes[source_index] / ast_flags_col[source_index] loops in this function.
• Both NameIds::with_capacity_and_hasher and Vec::with_capacity grow on demand, so under-sizing cannot change renamer output; a single-chunk (non-splitting) build sums the same files as before.

Extended reasoning...

Overview

This PR touches two files: src/js_printer/renamer.rs adds a symbols_in_chunk: usize parameter to NumberRenamer::init and uses it (instead of summing the whole bundle's symbols_for_source) to size the ids hashmap and slots vec; src/bundler/linker_context/renameSymbolsInChunk.rs computes that count by summing symbols_view.symbols_for_source[i].len() over the chunk's files_in_order before calling init. The capacity formula root_names.len() + N / 4 is unchanged and now deduplicated into one local. A short doc comment on init records why the caller must supply the count.

Security risks

None. This changes only the initial capacity reservation of a hashmap and a vec inside the bundler's symbol renamer. No untrusted-input parsing, no I/O, no auth/crypto, no user-facing API surface.

Level of scrutiny

Low-to-moderate. The change is ~15 lines and purely affects allocation sizing hints — HashMap::with_capacity_and_hasher and Vec::with_capacity both grow on demand, so even a wrong estimate cannot alter renamer output (the PR states output is byte-identical, which follows structurally). I checked that NumberRenamer::init has exactly one caller in the tree, so there are no sibling sites left with the old signature. The files_in_order → symbols_for_source[i as usize] indexing matches the established pattern used four other times in the same function for other per-source-index tables, and symbols_for_source is indexed by source_index elsewhere in renamer.rs. For a non-splitting build the single chunk contains every file, so the reserved capacity equals what it was before and the #41286 benchmark path is unchanged.

Other factors

The PR description supplies before/after peak-RSS measurements (6.2 GB → 7.7 GB regression on main, back to 6.2 GB with this change) and a page-fault attribution, satisfying the Performance section's "before/after numbers" requirement. No behavioral test is added, but capacity hints are not observable in output, so REVIEW.md's "every behavioral change ships a test" does not apply here — existing bundler correctness tests cover the renamer's output. No CODEOWNERS entry covers src/bundler/ or src/js_printer/. No prior reviews or outstanding objections on the timeline. Exit reason was dry_streak with zero findings.