-
Notifications
You must be signed in to change notification settings - Fork 3
Add tests and change bump allocator implementation #25
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
base: master
Are you sure you want to change the base?
Conversation
|
Nit: I'm not sure replacing pub struct BumpBox<'a, T> {
ptr: NonNull<T>,
_allocator: core::marker::PhantomData<&'a ()>,
}with pub struct BumpBox<'a, T> {
value: &'a mut T,
}... is necessarily making the intent clearer. However removing the destructor impl<T> Drop for BumpBox<'_, T> {
fn drop(&mut self) {
// Safety: The pointer is valid and we own the data
unsafe {
self.ptr.as_ptr().drop_in_place();
}
}
}... is absolutely NOK. Why did you do that? Otherwise, I totally like having |
It is OK (in that it will never, ever lead to a program crash or anything like that - it is just a UB if you read from the uninitialized memory which was assumed initialized, but we don't do that, and even if we did, it would be "undefined behavior" but not a crash).
Yeah. Maybe just |
I think I misunderstood a part of the code, yeah |
ivmarkov
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my two comments. Rest is fine.
src/bump.rs
Outdated
| const fn new() -> Self { | ||
| Self { | ||
| memory: MaybeUninit::uninit(), | ||
| memory: [const { MaybeUninit::uninit() }; N], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you confirmed that [const { MaybeUninit::uninit() }; N], would absolutely, positively NOT allocate on-stack and them move to the final destination?
To my understanding, only MaybeUninit::uninit() is guaranteed to have this property, regardless of the compiler optimization settings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried it out, and it worked fine, but based on my research, it seems like this is not always the case (seems to depend on compiler optimizations). Given that we are working with 1.77, the const expression is sadly unavailable.
|
PR #25: Size comparison from cf4a089 to 8ccbff4 Full report (2 builds for light, light_eth)
|
|
Hm, miri seems unhappy with your changes? How was it before your changes? |
|
The CI failure is what I referenced with this comment:
Here is what it outputs on master with the tests copied and the The fix here is // Safety: We just allocated the memory and it's properly aligned
let ptr = unsafe {
- let ptr = t_buf.as_ptr() as *mut T;
+ let ptr = t_buf.as_mut_ptr() as *mut T;
ptr.write(object);
NonNull::new_unchecked(ptr)
};and with that fix, miri will show the same problem on master that my PR has: The problem is this: It will return a pointer to the offsets Given that an I have tried a few things, but none of them made miri happy. |
|
I see. I played a bit with it today, and I think you are right - I'm not sure there is necessarily a bug in it (?) but I'm also not sure how to fix it so that Let me think about it a bit more in the next couple of days (a bit busy with other work ATM). |
While looking into #24, I noticed some pieces of code in the bump allocator that looked wrong.
What has been changed?
let ptr = t_buf.as_ptr() as *mut T;where a*const Tis cast to*mut T&selfby the use of pointers, I made this explicit through references. Note that this might have been a wrong decision, miri isn't happy with my current impl (see pending CI), because of overlapping borrows. Will have to check if the original code had that issue too.