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

Expose dealloc function that doesn't require Layout? #103

Open
rtfeldman opened this issue Sep 28, 2023 · 3 comments
Open

Expose dealloc function that doesn't require Layout? #103

rtfeldman opened this issue Sep 28, 2023 · 3 comments

Comments

@rtfeldman
Copy link

Thanks for making this!

I notice the dealloc function takes an unused _layout parameter (in order to satisfy the allocator trait, which makes sense) - but I have a use case where I'd like to call a version of that function that doesn't require being passed a layout at all (because I'll be calling it directly and won't have access to the layout when I'm calling it).

I could always call the current dealloc passing an empty layout, since I know that it's currently unused, but it would be risky for me to rely on that assumption; it seems pretty likely that I could get some really bad behavior if that argument somehow stopped being unused in a future release of the crate, and I wouldn't even get a compiler error!

If this is a design you're open to, I'd be happy to contribute a PR for it!

@nathaniel-daniel
Copy link
Contributor

Why not use mi_free from the -sys crate directly in that case? The wrapper would need to be unsafe anyways.

@thomcc
Copy link
Contributor

thomcc commented Sep 30, 2023

Note that dealloc is provided by the GlobalAlloc trait, it's interface is outside of this crate's control.

Also note that even if you know mimalloc is the #[global_allocator], mi_freeing a pointer allocated by from the rust global allocator (e.g. allocated with std::alloc::alloc) isn't guaranteed to be defined behavior (I believe LLVM would consider it UB).

@nathaniel-daniel
Copy link
Contributor

Also note that even if you know mimalloc is the #[global_allocator], mi_freeing a pointer allocated by from the rust global allocator (e.g. allocated with std::alloc::alloc) isn't guaranteed to be defined behavior (I believe LLVM would consider it UB).

Interesting, do you have more info on that? The docs seem to suggest std::alloc::alloc just forwards to GlobalAlloc's alloc method, which would return a pointer that was allocated by mimalloc. If it is known that the global allocator is mimalloc, would it not then be safe to free with mi_free, since the std::alloc::dealloc would just forward to the GlobalAlloc's dealloc? Or do you mean the docs don't actually promise that they just forward the pointer to the global allocator?

Note that dealloc is provided by the GlobalAlloc trait, it's interface is outside of this crate's control.

I think what is being asked for is a separate function on the MiMalloc struct that can free without a layout. Not sure how good of an idea it is to promote freeing without a layout though.

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

3 participants