Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pull request? - Allocating underlying store from non-global allocator #259

Open
vron opened this issue Nov 28, 2024 · 4 comments
Open

Pull request? - Allocating underlying store from non-global allocator #259

vron opened this issue Nov 28, 2024 · 4 comments

Comments

@vron
Copy link

vron commented Nov 28, 2024

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:

  • 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 :-)

@fitzgen
Copy link
Owner

fitzgen commented Dec 4, 2024

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.

Would this satisfy your use case?

@fitzgen
Copy link
Owner

fitzgen commented Dec 4, 2024

(This would be gated on a cargo feature until Rust's Allocator trait is stabilized, since it would be nightly only)

@vron
Copy link
Author

vron commented Dec 4, 2024

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.

@fitzgen
Copy link
Owner

fitzgen commented Dec 4, 2024

Probably a month or two at least. Really depends on how many free cycles I'm able to scrap together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants