refactor(allocator/pool): single AllocatorPool implementation
#13622
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
C-cleanup
This was referenced Sep 9, 2025
Member
Author
This was referenced Sep 9, 2025
CodSpeed Instrumentation Performance ReportMerging #13622 will not alter performanceComparing Summary
Footnotes |
graphite-app
bot
force-pushed
the
09-09-refactor_allocator_pool_share_allocatorguard_between_pool_impls
branch
from
7a28218 to
fbeb154
Compare
graphite-app
bot
requested review from
Dunqing,
camc314 and
leaysgur
as code owners
graphite-app
bot
force-pushed
the
09-09-refactor_allocator_pool_single_allocatorpool_implementation
branch
from
308ef51 to
0285003
Compare
Contributor
Merge activity
|
Previously we had 2 different versions of `AllocatorPool`. Which version is used was controlled purely by the `fixed_size` / `disable_fixed_size` Cargo features. Combine the 2 versions into a single `AllocatorPool` struct which can represent *either* a standard or a fixed-size allocator pool at runtime. 1. `AllocatorPool::new` creates a pool which uses standard allocators. 2. `AllocatorPool::new_fixed_size` creates a pool which uses fixed-size allocators. `AllocatorPool::new_fixed_size` is feature-gated behind `fixed_size` Cargo feature. Currently `AllocatorPool::new` still creates a fixed-size pool if `fixed_size` feature is enabled. That's just to avoid a change which would break the linter. Next PR will update the linter to conditionally use `AllocatorPool::new_fixed_size`, and then this workaround can be removed.
Member
Author
|
@camc314 has reviewed the top of this stack - where the changes to |
graphite-app
bot
force-pushed
the
09-09-refactor_allocator_pool_share_allocatorguard_between_pool_impls
branch
from
fbeb154 to
99dd1a7
Compare
graphite-app
bot
force-pushed
the
09-09-refactor_allocator_pool_single_allocatorpool_implementation
branch
from
0285003 to
a306c6f
Compare
graphite-app bot
pushed a commit
that referenced
this pull request
Sep 10, 2025
…ter` exists (#13623) We're trying to move the linter away from relying on Cargo features to enable/disable support for JS plugins, and over to runtime options. The signal that JS plugins are in use is the existence of an `ExternalLinter`. Select what kind of `AllocatorPool` to use based on this criteria - fixed-size allocators if JS plugins are in use, or standard allocators otherwise. Utilize the `AllocatorPool::new_fixed_size` method added in #13622 to do this.
graphite-app bot
pushed a commit
that referenced
this pull request
Sep 10, 2025
… pool (#13624) #13622 added `AllocatorPool::new_fixed_size` method to create a fixed-size allocator pool. #13623 switched the linter over to using this method when a fixed-size allocator is required. So now we can make `AllocatorPool::new` do what it's intended to do, and create a standard allocator pool. Strictly speaking this is a breaking change, but I don't think anyone is using the `fixed_size` feature, except for the linter. Without that, this change makes no difference to behavior.
graphite-app bot
pushed a commit
that referenced
this pull request
Sep 10, 2025
…13625) #13622 and #13624 altered what happens when the `fixed_size` Cargo feature is enabled. Previously, enabling that feature altered behavior of `AllocatorPool`. Now the feature is additive - it does nothing on it's own, but only adds additional APIs, and *those APIs* can be used to alter behavior. The purpose of the `disable_fixed_size` Cargo feature was to prevent the `fixed_size` feature being activated when tests are run with `--all-features`. Now that enabling `fixed_size` feature doesn't alter behavior, we don't need to worry about it being enabled in tests. Therefore `disable_fixed_size` feature can be removed. This removes a bunch of `#[cfg]` boilerplate, and ugly hacks which were previously required to workaround feature unification.
Base automatically changed from
09-09-refactor_allocator_pool_share_allocatorguard_between_pool_impls
to
main
September 10, 2025 04:11
camc314
approved these changes
Sep 10, 2025
graphite-app
bot
deleted the
09-09-refactor_allocator_pool_single_allocatorpool_implementation
branch
graphite-app bot
pushed a commit
that referenced
this pull request
Sep 10, 2025
…ter` exists (#13623) We're trying to move the linter away from relying on Cargo features to enable/disable support for JS plugins, and over to runtime options. The signal that JS plugins are in use is the existence of an `ExternalLinter`. Select what kind of `AllocatorPool` to use based on this criteria - fixed-size allocators if JS plugins are in use, or standard allocators otherwise. Utilize the `AllocatorPool::new_fixed_size` method added in #13622 to do this.
graphite-app bot
pushed a commit
that referenced
this pull request
Sep 10, 2025
… pool (#13624) #13622 added `AllocatorPool::new_fixed_size` method to create a fixed-size allocator pool. #13623 switched the linter over to using this method when a fixed-size allocator is required. So now we can make `AllocatorPool::new` do what it's intended to do, and create a standard allocator pool. Strictly speaking this is a breaking change, but I don't think anyone is using the `fixed_size` feature, except for the linter. Without that, this change makes no difference to behavior.
graphite-app bot
pushed a commit
that referenced
this pull request
Sep 10, 2025
…13625) #13622 and #13624 altered what happens when the `fixed_size` Cargo feature is enabled. Previously, enabling that feature altered behavior of `AllocatorPool`. Now the feature is additive - it does nothing on it's own, but only adds additional APIs, and *those APIs* can be used to alter behavior. The purpose of the `disable_fixed_size` Cargo feature was to prevent the `fixed_size` feature being activated when tests are run with `--all-features`. Now that enabling `fixed_size` feature doesn't alter behavior, we don't need to worry about it being enabled in tests. Therefore `disable_fixed_size` feature can be removed. This removes a bunch of `#[cfg]` boilerplate, and ugly hacks which were previously required to workaround feature unification.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously we had 2 different versions of
AllocatorPool. Which version is used was controlled purely by thefixed_size/disable_fixed_sizeCargo features.Combine the 2 versions into a single
AllocatorPoolstruct which can represent either a standard or a fixed-size allocator pool at runtime.AllocatorPool::newcreates a pool which uses standard allocators.AllocatorPool::new_fixed_sizecreates a pool which uses fixed-size allocators.AllocatorPool::new_fixed_sizeis feature-gated behindfixed_sizeCargo feature.Currently
AllocatorPool::newstill creates a fixed-size pool iffixed_sizefeature is enabled. That's just to avoid a change which would break the linter. Next PR will update the linter to conditionally useAllocatorPool::new_fixed_size, and then this workaround can be removed.