feat(allocator): add cap to FixedSizeAllocatorPool and block when exhausted

[camc314]

This PR adds a capacity limit to FixedSizeAllocatorPool to prevent unbounded memory consumption.

Previously, each call to get() on an empty pool would create a new 4 GiB allocator without any limit, risking memory exhaustion in multi-threaded scenarios. Now the pool caps the number of allocators at thread_count and blocks threads using a Condvar when all allocators are in use.

Key changes include:

• Eager creation of the first allocator during construction (fail-fast).
• Lock-free ID assignment with compare-and-swap.
• Blocking with condition variables when at capacity.
• Tracking allocation failures to avoid repeated attempts.

[camc314]

• docs(linter): fix typo in doc comment #17091
• test(linter/plugins): enable import plugin on one test fixture #17089
• perf(linter): avoid cloning source text when cloning AST into fixed-size allocator #17088
• refactor(linter): reduce repeat code in JS plugin linting #17087
• refactor(linter): reduce repeated logic in JS plugin linting #17086
• refactor(allocator): simplify return type of FixedSizeAllocatorPool::create_new_allocator #17080
• perf(allocator): reduce time Mutex lock is held in FixedSizeAllocatorPool::get #17079
• refactor(allocator): move nested function out of FixedSizeAllocatorPool::get #17078
• refactor(allocator): remove AllocError from fixed size allocator #17077
• fix(linter): OOM problems with custom plugins #17013
• feat(allocator): add cap to FixedSizeAllocatorPool and block when exhausted #17023 👈 (View in Graphite)
• refactor(allocator/fixed-size): return Result from allocation instead of panicking #17022
• 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 Performance Report

Merging #17023 will degrade performances by 3.08%

_{Comparing c/12-17-refactor_allocator_add_docs_for_fixedsizeallocatorpool_fields_and_handle_thread_count_0 (da244dd) with main (1e2d011)}

Summary

❌ 1 regression
✅ 41 untouched
⏩ 3 skipped¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Mode	Benchmark	BASE	HEAD	Change
❌	Simulation	minifier[cal.com.tsx]	36.3 ms	37.5 ms	-3.08%

Footnotes

1. 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. ↩

[Copilot]

Pull request overview

This PR adds a capacity limit to FixedSizeAllocatorPool and implements blocking behavior when the pool is exhausted. Previously, the pool would create allocators on demand without limit. Now it enforces a maximum number of allocators (based on thread count) and blocks threads in get() when all allocators are in use, using a condition variable to wake threads when allocators are returned via add().

Key changes:

• Adds capacity limiting with blocking wait when exhausted
• Creates one allocator upfront during pool initialization instead of lazy creation
• Implements condition variable-based thread synchronization for allocator availability

---

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

[camc314]

@overlookmotel this is a pretty nice summary of the PR:

https://api.vibekanban.com/review/bc8cf657-4769-44d6-b041-6c39413aa5e2

[overlookmotel]

To be honest, I'm not 100% sure this works perfectly. Synchronization across threads is hard to reason about, and I'm not familiar with Condvar.

I worry there might be scope for a deadlock on the Mutex, as there's 2 places that take a lock on it in FixedSizeAllocatorPool::get. Just might though - I can't figure out a scenario in which that could happen, but I don't feel I understand it fully, so I might be missing something.

Hopefully it's OK!

I also worry that we're potentially not leaving enough memory free for standard allocators. If there's 24.01 GB memory available, and we create 4 x 6 GiB fixed-size allocators, we'll successfully create those 4, but only leave 0.01 GB of free memory remaining. So then other memory allocations might hit OOM.

It's just luck of the draw how close your total available memory is to a multiple of 6 GiB! If it's close, bad times...

---

Pushed one nit. Maybe I'm stupid, but I always find a.max(b) confusing. I find cmp::max(a, b) clearer.

Am also going to follow-up with some refactoring PRs.