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

Implement a proper bump allocator #1

Merged
merged 1 commit into from Nov 5, 2018
Merged

Implement a proper bump allocator #1

merged 1 commit into from Nov 5, 2018

Conversation

blt
Copy link
Owner

@blt blt commented Nov 5, 2018

This commit introduces a proper thread-safe bump allocator to bh_alloc. The previous allocator is now moved to the fuzz sub-module. This work was inspired by a Reddit conversation. I felt pretty bad that my poor fuzzy allocator got held up to demonstrate a general purpose bump allocator. :)

Anyway, the only dicey bit here is the AtomicUsize. I haven't done any stress testing on an ARM machine, which should be done. x86 has stricter memory ordering, hiding bugs that only turn up under ARM.

Signed-off-by: Brian L. Troutwine brian@troutwine.us

This commit introduces a proper thread-safe bump allocator to
bh_alloc. The previous allocator is now moved to the `fuzz`
sub-module. This work was inspired by a Reddit
[conversation](https://www.reddit.com/r/rust/comments/9twam5/jemalloc_was_just_removed_from_the_standard/e902qnh/). I
felt pretty bad that my poor fuzzy allocator got held up to
demonstrate a general purpose bump allocator. :)

Anyway, the only dicey bit here is the AtomicUsize. I haven't done any
stress testing on an ARM machine, which should be done. x86 has
stricter memory ordering, hiding bugs that only turn up under ARM.

Signed-off-by: Brian L. Troutwine <brian@troutwine.us>
@blt blt merged commit 8810756 into master Nov 5, 2018
@blt blt deleted the proper_bump branch November 5, 2018 03:09
@SimonSapin
Copy link

Thank you for working on this!

I think there may be a bug in the alignment handling. It’s not the size that needs to be rounded up, is the addressed of the returned pointer. [u8; TOTAL_BYTES] has align 1, so HEAP could start at any address. For example if it starts at address 0x1_0003, offset is 0, and the requested alignment is 8, then the allocator should return a pointer with address 0x1_0010.

Although the size of Rust types is always a multiple of their alignment (to make arrays work), this is not necessarily the case of Layout. The end offset does not need to be aligned.

@blt
Copy link
Owner Author

blt commented Nov 5, 2018

@SimonSapin hey, thanks for this. I put this together without a test plan and fully believe there are bugs in it. Would you mind opening an issue?

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

Successfully merging this pull request may close these issues.

None yet

2 participants