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

Create a C API posix-compatible malloc/free wrapper crate #9

Open
fitzgen opened this issue Feb 2, 2018 · 2 comments
Open

Create a C API posix-compatible malloc/free wrapper crate #9

fitzgen opened this issue Feb 2, 2018 · 2 comments
Labels
help wanted Extra attention is needed mentored

Comments

@fitzgen
Copy link
Member

fitzgen commented Feb 2, 2018

Summary

Add a C API crate that wraps wee_alloc and provides posix malloc and free.

Motivation

C and C++ projects targeting wasm could benefit from wee_alloc too, and more users = more bug reports and reliability work and all that good stuff.

Details

  • New crate at the top level of the repo, depending on wee_alloc

  • Wraps a wee_alloc global allocator and exposes malloc and free (and I think realloc is part of the posix spec too?)

@fitzgen fitzgen added help wanted Extra attention is needed mentored labels Feb 2, 2018
@pepyakin
Copy link
Member

pepyakin commented Feb 6, 2018

and I think realloc is part of the posix spec too?

I believe that not only realloc but also calloc.

There is some API mismatch, Rust allocators takes Layout argument for alloc and dealloc, so, I guess on call to free before calling to dealloc we need to somehow obtain Layout for this particular allocation?

@fitzgen
Copy link
Member Author

fitzgen commented Feb 6, 2018

Yeah.

An easy, expedient solution would be to have the posix crate allocate n + 1 words and store the size just before the real allocation.

An alternative, probably-better solution would be to tighten up the size classes' free list invariant to say that allocations from these lists must be exactly the size class's size. Right now, because we don't ensure that the blocks that populate a size class's free list are a multiple of the size class, and we never split a cell smaller than the size class's size, so the last cell from a block can have some remainder bloat size within it. If we fixed this and tightened the invariant, then we could just look at the cell's header's size to determine which free list to put it back in, and would not need to store any extra data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed mentored
Projects
None yet
Development

No branches or pull requests

2 participants