fix(allocator): `AllocatorPool` do not consume all memory on Windows by overlookmotel · Pull Request #17094 · oxc-project/oxc

overlookmotel · 2025-12-19T01:14:35Z

Modification of fixed-size allocator limits, building on #17023.

The problem

This is an alternative design, intended to handle one flaw on Windows:

Each allocator is 4 GiB in size, so if system has 16.01 GiB of memory available, we could succeed in creating 4 x 4 GiB allocators, but that'd only leave 10 MiB of memory free. Likely then some other allocation (e.g. creating a normal Allocator, or even allocating a heap String) would fail due to OOM later on.

Note that "memory available" on Windows does not mean "how much RAM the system has". It includes the swap file, the size of which depends on how much free disk space the system has. So numbers like 16.01 GiB are not at all out of the question.

Proposed solution

On Windows, create as many allocators as possible when creating the pool, up to thread count + 1. Then return the last allocator back to the system. This ensures that there's at least 4 GiB of memory free for other allocations, which should be enough.

Redesign

In working through the various scenarios, I realized that the implementation can be simplified for both Linux/Mac and Windows.

In both cases, no more than thread_count fixed-size allocators can be in use at any given time - see doc comment on FixedSizeAllocatorPool for full explanation.

So create the pool with thread_count allocators (or as close as we can get on Windows). Thereafter the pool does not need to grow, and cannot.

This allows removing a bunch of synchronization code.

On Linux/Mac, fix(linter): OOM problems with custom plugins #17013 solved the too-many-allocators problem another way, so all we need is the Mutex.
On Windows, we only need a Mutex + a Condvar.

In both cases, it's much simplified, which makes it much less likely for subtle race conditions like #17112 to creep in.

Removing the additional synchronization should also be a little more performant.

Note that the redesign is not the main motivator for this change - preventing OOM on Windows is.

overlookmotel · 2025-12-19T01:14:51Z

fix(allocator): AllocatorPool do not consume all memory on Windows #17094 👈 (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 · 2025-12-19T01:21:57Z

CodSpeed Performance Report

Merging #17094 will not alter performance

_{Comparing om/12-19-fix_allocator_allocatorpool_do_not_consume_all_memory_on_windows (dae1f00) with main (2c45017)¹}

Summary

✅ 42 untouched
⏩ 3 skipped²

No successful run was found on main (cf70b57) during the generation of this report, so 2c45017 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩
3 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

camc314

I deliberatly did not take this approach as it's going to lead to people complaining about high memory usage.

Lets take the language server, when it starts, it's going to consume ~ (N - 4GB), where N is the total system memory (assuming N < thread_count * 4 GB. This memory is going to be consumend for the entire lifecycle of the language server, and it's not going to be freed until the language server is shut down

overlookmotel · 2025-12-19T13:53:29Z

I deliberatly did not take this approach as it's going to lead to people complaining about high memory usage.

Lets take the language server, when it starts, it's going to consume ~ (N - 4GB), where N is the total system memory (assuming N < thread_count * 4 GB. This memory is going to be consumend for the entire lifecycle of the language server, and it's not going to be freed until the language server is shut down

Yes, I know, and I see the LSP problem.

I'm not saying that this is the ideal solution, but I think we do need some solution for Windows OOM, which I think is inevitable in the current implementation (though you've made it much less likely, which is a huge win).

Do you have a better idea?

We don't support JS plugins in language server at present, so unless we can come up with a better solution, perhaps we go with this for now, and figure out something better when we get to the LSP?

As you know, I have in mind a longer-term solution by changing how raw transfer handles memory. So this is only intended as a stopgap anyway.

@camc314 What do you think?

Copilot

Pull request overview

This PR redesigns the FixedSizeAllocatorPool to prevent memory exhaustion on Windows while simplifying the overall implementation. The key changes address Windows' lack of virtual memory overcommit by creating a fixed pool of allocators upfront and ensuring sufficient memory remains for other allocations.

Key Changes:

Split implementation into platform-specific versions (Linux/Mac vs Windows) with different allocation strategies
Removed dynamic pool growth capability in favor of fixed-size pool created at initialization
On Windows, create up to thread_count + 1 allocators and discard the last one to ensure 4 GiB remains free

Reviewed changes

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

File	Description
`crates/oxc_allocator/src/pool/fixed_size.rs`	Redesigned allocator pool with platform-specific implementations; removed synchronization for pool growth; added comprehensive documentation explaining design rationale
`.github/workflows/ci.yml`	Commented out the conditional limiting Windows NAPI tests to main branch only

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

crates/oxc_allocator/src/pool/fixed_size.rs

.github/workflows/ci.yml

camc314 · 2025-12-19T14:28:24Z

I deliberatly did not take this approach as it's going to lead to people complaining about high memory usage.
Lets take the language server, when it starts, it's going to consume ~ (N - 4GB), where N is the total system memory (assuming N < thread_count * 4 GB. This memory is going to be consumend for the entire lifecycle of the language server, and it's not going to be freed until the language server is shut down

Yes, I know, and I see the LSP problem.

I'm not saying that this is the ideal solution, but I think we do need some solution for Windows OOM, which I think is inevitable in the current implementation (though you've made it much less likely, which is a huge win).

Do you have a better idea?

We don't support JS plugins in language server at present, so unless we can come up with a better solution, perhaps we go with this for now, and figure out something better when we get to the LSP?

As you know, I have in mind a longer-term solution by changing how raw transfer handles memory. So this is only intended as a stopgap anyway.

@camc314 What do you think?

Ah i see, yeah this seems reasonable

Later comment says this PR seems reasonable.

overlookmotel · 2025-12-19T17:04:29Z

Ah i see, yeah this seems reasonable

OK cool, I'll merge then.

overlookmotel · 2025-12-19T17:04:44Z

Merge activity

Dec 19, 5:04 PM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
Dec 19, 5:23 PM UTC: overlookmotel added this pull request to the Graphite merge queue.
Dec 19, 5:29 PM UTC: Merged by the Graphite merge queue.

…17094) Modification of fixed-size allocator limits, building on #17023. ### The problem This is an alternative design, intended to handle one flaw on Windows: Each allocator is 4 GiB in size, so if system has 16.01 GiB of memory available, we could succeed in creating 4 x 4 GiB allocators, but that'd only leave 10 MiB of memory free. Likely then some other allocation (e.g. creating a normal `Allocator`, or even allocating a heap `String`) would fail due to OOM later on. Note that "memory available" on Windows does not mean "how much RAM the system has". It includes the swap file, the size of which depends on how much free disk space the system has. So numbers like 16.01 GiB are not at all out of the question. ### Proposed solution On Windows, create as many allocators as possible when creating the pool, up to `thread count + 1`. Then return the last allocator back to the system. This ensures that there's at least 4 GiB of memory free for other allocations, which should be enough. ### Redesign In working through the various scenarios, I realized that the implementation can be simplified for both Linux/Mac and Windows. In both cases, no more than `thread_count` fixed-size allocators can be in use at any given time - see doc comment on `FixedSizeAllocatorPool` for full explanation. So create the pool with `thread_count` allocators (or as close as we can get on Windows). Thereafter the pool does not need to grow, and cannot. This allows removing a bunch of synchronization code. * On Linux/Mac, #17013 solved the too-many-allocators problem another way, so all we need is the `Mutex`. * On Windows, we only need a `Mutex` + a `Condvar`. In both cases, it's much simplified, which makes it much less likely for subtle race conditions like #17112 to creep in. Removing the additional synchronization should also be a little more performant. Note that the redesign is not the main motivator for this change - preventing OOM on Windows is.

github-actions bot added the C-bug Category - Bug label Dec 19, 2025

overlookmotel force-pushed the om/12-19-fix_allocator_allocatorpool_do_not_consume_all_memory_on_windows branch from 498bf05 to 8646be9 Compare December 19, 2025 01:15

overlookmotel self-assigned this Dec 19, 2025

overlookmotel added the A-linter-plugins Area - Linter JS plugins label Dec 19, 2025

overlookmotel force-pushed the om/12-19-fix_allocator_allocatorpool_do_not_consume_all_memory_on_windows branch 3 times, most recently from 7ac9e8c to d77d515 Compare December 19, 2025 04:58

camc314 previously requested changes Dec 19, 2025

View reviewed changes

overlookmotel force-pushed the om/12-19-fix_allocator_allocatorpool_do_not_consume_all_memory_on_windows branch 2 times, most recently from 586524b to 803113a Compare December 19, 2025 13:48

overlookmotel marked this pull request as ready for review December 19, 2025 14:25

Copilot AI review requested due to automatic review settings December 19, 2025 14:25

Copilot started reviewing on behalf of overlookmotel December 19, 2025 14:26 View session

Copilot AI reviewed Dec 19, 2025

View reviewed changes

overlookmotel force-pushed the om/12-19-fix_allocator_allocatorpool_do_not_consume_all_memory_on_windows branch from 803113a to dae1f00 Compare December 19, 2025 17:03

overlookmotel added the 0-merge Merge with Graphite Merge Queue label Dec 19, 2025

overlookmotel force-pushed the om/12-19-fix_allocator_allocatorpool_do_not_consume_all_memory_on_windows branch from dae1f00 to 1302ed4 Compare December 19, 2025 17:16

graphite-app bot force-pushed the om/12-19-fix_allocator_allocatorpool_do_not_consume_all_memory_on_windows branch from 1302ed4 to adb41ba Compare December 19, 2025 17:23

graphite-app bot merged commit adb41ba into main Dec 19, 2025
21 checks passed

graphite-app bot deleted the om/12-19-fix_allocator_allocatorpool_do_not_consume_all_memory_on_windows branch December 19, 2025 17:29

graphite-app bot removed the 0-merge Merge with Graphite Merge Queue label Dec 19, 2025

overlookmotel mentioned this pull request Dec 19, 2025

linter: Experimental jsPlugins not loading on windows #14375

Closed

Boshen mentioned this pull request Dec 22, 2025

release(crates): oxc v0.105.0 #17259

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Comments

fix(allocator): `AllocatorPool` do not consume all memory on Windows#17094

fix(allocator): `AllocatorPool` do not consume all memory on Windows#17094
graphite-app[bot] merged 1 commit intomainfrom
om/12-19-fix_allocator_allocatorpool_do_not_consume_all_memory_on_windows

overlookmotel commented Dec 19, 2025 •

edited

Loading

Uh oh!

overlookmotel commented Dec 19, 2025

Uh oh!

codspeed-hq bot commented Dec 19, 2025 •

edited

Loading

Uh oh!

camc314 left a comment

Uh oh!

overlookmotel commented Dec 19, 2025 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

camc314 commented Dec 19, 2025

Uh oh!

overlookmotel commented Dec 19, 2025

Uh oh!

overlookmotel commented Dec 19, 2025 •

edited by graphite-app bot

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Comments

Conversation

overlookmotel commented Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The problem

Proposed solution

Redesign

Uh oh!

overlookmotel commented Dec 19, 2025

How to use the Graphite Merge Queue

Uh oh!

codspeed-hq bot commented Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

CodSpeed Performance Report

Merging #17094 will not alter performance

Summary

Footnotes

Uh oh!

camc314 left a comment

Choose a reason for hiding this comment

Uh oh!

overlookmotel commented Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

camc314 commented Dec 19, 2025

Uh oh!

overlookmotel commented Dec 19, 2025

Uh oh!

overlookmotel commented Dec 19, 2025 • edited by graphite-app bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merge activity

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

overlookmotel commented Dec 19, 2025 •

edited

Loading

codspeed-hq bot commented Dec 19, 2025 •

edited

Loading

overlookmotel commented Dec 19, 2025 •

edited

Loading

overlookmotel commented Dec 19, 2025 •

edited by graphite-app bot

Loading