refactor(syntax): use allocator HashMap in ModuleRecord fields

[Boshen]

No description provided.

[Copilot]

Pull Request Overview

This PR refactors the ModuleRecord to use the allocator-backed HashMap instead of the standard FxHashMap, aligning with the project's memory allocation strategy.

Key changes:

• Replace FxHashMap with allocator-backed HashMap for module fields
• Update HashMap construction to use allocator-aware initialization
• Add Debug derive to the HashMap wrapper type

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
crates/oxc_syntax/src/module_record.rs	Replace FxHashMap fields with allocator-backed HashMap and update initialization
crates/oxc_allocator/src/hash_map.rs	Add Debug trait implementation to HashMap wrapper

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Boshen]

• refactor(syntax): use allocator HashMap in ModuleRecord fields #14141 👈 (View in Graphite)
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codspeed-hq]

CodSpeed Instrumentation Performance Report

Merging #14141 will not alter performance

_{Comparing 09-26-refactor_syntax_use_allocator_hashmap_in_modulerecord_fields (7e42b0a) with main (3542572)¹}

Summary

✅ 37 untouched

Footnotes

1. No successful run was found on main (f1047e9) during the generation of this report, so 3542572 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[Boshen]

@camchenry weird how my local just allocs is different from CI 🤔

https://github.com/oxc-project/oxc/actions/runs/18029568358/job/51303075325?pr=14141

[overlookmotel]

@camchenry weird how my local just allocs is different from CI 🤔

https://github.com/oxc-project/oxc/actions/runs/18029568358/job/51303075325?pr=14141

I think it just had got out of sync: #14145

Edit: Ah no I'm wrong. I see you rebased on top of #14145, and it's still different on CI and locally (I can reproduce the same allocs result as in this PR locally on my Mac Mini M4).

I've rebased again on latest main. Still mismatch between CI and local.

[camchenry]

@overlookmotel @Boshen This feels very familiar to some of the issues that I was having getting the system allocator bytes to match between CI and local. I ended up removing the number of bytes allocated by the system allocator because it rarely matched.

I don't think we've used the arena allocator for HashMap before and now the arena allocator is having the same instability now that we are. I wonder if HashMap could be the source of problematic allocations? The number of allocations appears to be accurate, but only the size is different.

If necessary, we could remove the number of arena bytes allocated as well, I think that should stabilize this task again.

[Boshen]

Merge activity

• Sep 27, 8:22 AM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Sep 27, 8:22 AM UTC: Boshen added this pull request to the Graphite merge queue.
• Sep 27, 8:27 AM UTC: Merged by the Graphite merge queue.

[overlookmotel]

@camchenry I asked Claude to look into the differences across platforms. Looks like cause is:

hashbrown has different implementations of Group depending on platform, to capitalize on their different SIMD capabilities: https://github.com/rust-lang/hashbrown/blob/9e812fdd350b58e9d60888c1f9dc9c5eb953f716/src/control/group/mod.rs

• On ARM Mac, Group::WIDTH == 8.
• On x86 SSE2, Group::WIDTH == 16.

Group::WIDTH is used in calculation of minimum capacity for a HashMap: https://github.com/rust-lang/hashbrown/blob/9e812fdd350b58e9d60888c1f9dc9c5eb953f716/src/raw/mod.rs#L131-L136. So, in some cases, size of a HashMap's allocation will be larger on x86 than on ARM Mac.

More annoyingly for our allocation-tracking, it's possible that we'll also see the allocation count be different across platforms. A larger-capacity HashMap is less likely to need to grow (reallocate) when you insert into it.

This will be the case regardless of whether the HashMap is heap or arena-allocated.

I don't see an easy way to avoid this problem. hashbrown doesn't have a Cargo feature to disable SIMD optimizations, which means no way to control GROUP::WIDTH from outside. Maybe we could add something to oxc_allocator::HashMap to enforce a higher minimum capacity when an allocs_count feature is enabled. But I've not dug deep enough into hashbrown to know if value of GROUP::WIDTH has other effects aside from minimum capacity.

This still doesn't explain why we see HashMaps exhibiting non-deterministic behavior on a single platform (e.g. in our CodSpeed benchmarks). That one remains a mystery.