You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a need to use bumpalo in a context where I do not want the backing storage to come from the global allocator.
If I did the work to provie a pull request to modify bumpalo such that it could allocate from a different allocator, would that be merged considered?
Specifically when I review the code I would suggest to:
under the nighly-allocatopr api flag do the following changes:
modify ChunkFooter to have an extra fields: allocator: &'static Allocator
replace the (only two?) calls to alloc() and dealloc() with calls to that field in the Chunk footer
Add additional "new" methog in bump where a static ref to the dersired allocator is provided
Obviously I have not tested this approach yet - wanted to check the interest before testing it / doing the work.
The clear downside of this is that a static ref to the underlying allocator must be used, but I cannot see any way to get aroundt his without introducing an additionall lifetime in Bump which I assume is not desired as it will complicate the API? (though it could be 'static by default when using the global allocator)
Please let me know if you want me to proceed with this work or not :-)
The text was updated successfully, but these errors were encountered:
Hi, just got back from vacation, thanks for your patience.
I am planning a new major version release and one of the features I intend to include is being generic over an A: Allocator. With this approach, you could implement an Allocator for (say) a static block of memory rather than the global heap, and then construct a Bump on top of that Allocator.
Yes, I think it would indeed do :-) - and I agree that making it generic over the allocator is even better and avoid the need to store a reference to the allocator.
Would that also allow to use bumpalo with a Allocator with non-static lifetime?
Do you think this is weeks, months or longer away? Just so I can now if I should wait or do som hack in-between myself.
Hi,
I have a need to use bumpalo in a context where I do not want the backing storage to come from the global allocator.
If I did the work to provie a pull request to modify bumpalo such that it could allocate from a different allocator, would that be merged considered?
Specifically when I review the code I would suggest to:
under the nighly-allocatopr api flag do the following changes:
Obviously I have not tested this approach yet - wanted to check the interest before testing it / doing the work.
The clear downside of this is that a static ref to the underlying allocator must be used, but I cannot see any way to get aroundt his without introducing an additionall lifetime in Bump which I assume is not desired as it will complicate the API? (though it could be 'static by default when using the global allocator)
Please let me know if you want me to proceed with this work or not :-)
The text was updated successfully, but these errors were encountered: