refactor(linter): create AllocatorPool in Runtime::new
#13106
Conversation
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
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 Instrumentation Performance ReportMerging #13106 will not alter performanceComparing Summary
Footnotes |
There was a problem hiding this comment.
Pull Request Overview
This PR refactors the creation of AllocatorPool by moving it into Runtime::new instead of creating it in multiple places and passing it to LintService::new. This centralizes allocator pool creation and ensures consistent initialization across all usage sites.
Key Changes:
- Removed
AllocatorPoolparameter fromLintService::newandRuntime::newconstructors - Moved
AllocatorPoolcreation intoRuntime::newwith proper thread count initialization - Updated all call sites to use the simplified constructor signatures
Reviewed Changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| crates/oxc_linter/src/tester.rs | Removes AllocatorPool import and parameter from LintService::new call |
| crates/oxc_linter/src/service/runtime.rs | Creates AllocatorPool internally with rayon::current_num_threads() |
| crates/oxc_linter/src/service/mod.rs | Removes AllocatorPool parameter from LintService::new constructor |
| crates/oxc_language_server/src/linter/isolated_lint_handler.rs | Updates LintService::new call to use simplified signature |
| apps/oxlint/src/lint.rs | Removes AllocatorPool creation and simplifies LintService::new call |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
|
@camc314 Is there any reason why this is a bad idea? I can't see one, but I'm not sure if there's a reason it was designed the way it is. |
48772f3 to
06c1f67
Compare
Merge activity
|
Move creation of `AllocatorPool` into just one place. Previously it was created in various places and passed in to `LintService::new` which passed it to `Runtime::new`. Just create it in `Runtime::new` instead. This does have one substantive effect. Language server was creating `AllocatorPool` with `AllocatorPool::default` (0 slots for `Allocator`s) whereas now it's created with `rayon::current_num_threads()` slots. This doesn't make much difference at present, because the pool creates allocators on demand. But it's going to become important when running JS plugins multi-threaded. At that point it'll be essential that the `AllocatorPool` is created with an accurate thread count, and undefined behavior may result if it isn't.
06c1f67 to
6c5b8be
Compare
|
Thanks for reviewing! |
Since #13106, `Default` is not used, and it shouldn't be. Remove it.
Move creation of
AllocatorPoolinto just one place. Previously it was created in various places and passed in toLintService::newwhich passed it toRuntime::new. Just create it inRuntime::newinstead.This does have one substantive effect. Language server was creating
AllocatorPoolwithAllocatorPool::default(0 slots forAllocators) whereas now it's created withrayon::current_num_threads()slots.This doesn't make much difference at present, because the pool creates allocators on demand. But it's going to become important when running JS plugins multi-threaded. At that point it'll be essential that the
AllocatorPoolis created with an accurate thread count, and undefined behavior may result if it isn't.