Aliasing rules for Box<T>

[RalfJung]

What should the aliasing rules for Box be? Stacked Borrows says they are the same as &mut T. (With the exception that no protectors are being added, so a Box<T> may actually be deallocated while a function is running. However, if we adopt #252, then even this difference will probably disappear.)

However, @jonhoo has a usecase that is in conflict with this. @jonhoo maybe you could briefly summarize what that is about? In particular I am wondering if you think you should be able to pull the same tricks with &mut-- so far I treated it as a given that both Box and &mut should require uniqueness in pretty much the same way.

[jonhoo]

Thank you! The use-case I have is in https://github.com/jonhoo/rust-evmap, which provides concurrent read-only access to a map by keeping two copies of the map, one used by readers, and one used by the (singular) writer. Since the two maps generally hold the same keys and values, it's wasteful to duplicate all the keys and values between the maps. Instead, (my hope is) the values can be aliased so long as they are only either accessed by multiple readers, or by a single writer, at a time. Since aliasing is unsafe, evmap makes users opt into this aliasing using an unsafe ShallowCopy trait. Up until now, I've been implementing ShallowCopy for Box<T>, which makes it really easy to make cheap copies of the map for evmap — all the values are just aliased pointers, so the only memory duplication is the map itself. But, if Box can't be aliased, this won't work.

While the value could be a raw pointer, that would make the ergonomics of using evmap significantly more painful, since the caller would have to cast *mut T to &T any time they access the map, even though evmap already guarantees all the requirements for using the value as &T.

[RalfJung]

Could you give a concrete self-contained piece of code demonstrating what you mean by "aliasing a Box"? Is this representative?

[digama0]

@jonhoo I don't think there is any way to make the aliased Box<T> not UB, although you might be able to argue that it's not likely to be optimized badly given the current compiler and LLVM. My suggestion would be to use a pointer, because this correctly represents the semantics, but that leaves the ergonomic question.

I think you could make ShallowCopy have an associated type, where T::Shallow is T with any inner allocations like Box<U> replaced by *mut U, plus a deref-like method &T::Shallow -> &T that would allow you to recover the ergonomic version when accessing the read map. Both operations would be unsafe, but I don't think this triggers any insta-UB; it just leaves open the possibility of UB via data races if you start accessing the write map while the readers are using it.

[jonhoo]

@RalfJung The relevant code is this bit, which I hadn't looked at in a while and just realized is horribly not okay as it casts from const to mut:

fn shallow_copy(self: &Box<T>) -> ManuallyDrop<Box<T>> {
    ManuallyDrop::new(Box::from_raw(&**self as *const _ as *mut _))
}

But yes, your example would be a better way to illustrate the same thing. And my guess is you'll tell me that that is still casting from a const to a mut, which is Not Okay 😅

@digama0 Hmm, yes, I think your suggestion could probably work. It would still make it a little painful to actually generate the value to insert into the map, but an additional method might be able to help there (something like ShallowCopy::from_t). It gets ugly pretty quickly, but maybe that's just the way it has to be.. The other path would be to have a MyBox which internally just holds a raw pointer, which the compiler then wouldn't make the same no aliasing assumption about, but that's not very nice either.

I was definitely hoping there'd be a way for me to just use Box<T> as long as I respected the exclusiveness of &mut and never used after drop, but it sounds like that's unlikely to be okay.

[digama0]

Here's a toy version of the evmap code, enough to show the UB: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4612588ebe044a19e4e72859b81fd443

[digama0]

Another way to look at the problem is that shallow_copy is actually a move according to the stacked borrows rules, even though the types don't make it obvious. When you call the function, it invalidates the pointer that it was given, so your oplog gets trashed and when you write the values the second time you don't have permission to read any of it, even though it is a bitwise copy of the values in the other map that you are allowed to read. Pointer provenance is weird.

[chorman0773]

Currently in lccc, the pointer field of Box is nonnull, aligned(align_of T), unique (which is the equivalent of noalias, except designed to actually be useful in optimizing rust code), as well as dereference_write(size_of T). (From these lines declaring Unique, and these lines for Box itself). This is, notably, exactly what would be emitted for &mut T, though it doesn't last for the entirity of the function, as destroying a box invalidates the pointer, so it's attribute "promises" cease to be in effect.
I can't see any Box particular optimizations that are enabled by this, basically just the standard ones that can be applied to &mut T.
I'd support making the aliasing rules for Box<T> the same as &mut T, so these optimizations can be performed there as well, but I could live without them.

[RalfJung]

@jonhoo

But yes, your example would be a better way to illustrate the same thing. And my guess is you'll tell me that that is still casting from a const to a mut, which is Not Okay sweat_smile

Basically, yeah. I am curious, if all Box here would be replaced by &'static mut, would you expect/want your code to still be okay? Basically I want to know if you think Box and &mut should differ, or if both should be weaker than Stacked Borrows makes them?

I can certainly imagine rules whereby &mut and Box only assert uniqueness when you write to them. That will carry a global (and hard to quantify) cost in terms of lost optimization potential though, in particular around moving write accesses up across unknown code. Maybe those optimizations are so hard to apply, or apply so rarely, that losing them is okay -- this is not a judgment call I can make.

We'll know a lot more about this design space once there is a concrete proposal that solves #133. Right now, all I can do is speculate.

@chorman0773

I'd support making the aliasing rules for Box the same as &mut T, so these optimizations can be performed there as well, but I could live without them.

I agree with this also just from a matter of simplicity -- not having yet another set of rules would be preferrable, I think.

[jonhoo]

@RalfJung Actually, no, I don't think I'd expect &'static mut to work the same way, because it having a &mut (to me) asserts perpetual exclusive access. I don't know exactly where that feeling comes from, but it just "feels like" it should be okay to have multiple ManuallyDrop<Box<T>> that point to the same T as long as you enforce the borrow rules for any references you take to that T. Whereas that doesn't feel true for &'static mut T, since it is already a reference that asserts an exclusive borrow. You couldn't have two &'static mut T around that both point to the same T, because, well, you're violating the &mut borrow rule directly.

I think maybe what's going on in my head is that the ManuallyDrop wrapper is what changes things. I _don't _ "feel" like it's okay to keep two Box<T> around that point to the same T; it only feels acceptable with the wrapper. In particular, I think in my head ManuallyDrop is an abdication of ownership — it implies that you don't really own the inner type, which means that you are not bound by the ownership rules for that type any more (though you are bound by the validity rules for the type).

[bjorn3]

ManuallyDrop doesn't imply that you don't really own the value to me. It merely supresses the drop implementation. In fact ManuallyDrop::into_inner is safe. If ManuallyDrop were to imply that you don't really oen the value, that method couldn't be safe as it makes you suddenly completely own the value.

[bjorn3]

Also you can safely go from ManuallyDrop<Box<T>> to &mut T, so any aliasing rules that apply to &mut T must also apply to ManuallyDrop<Box<T>>.