4 ms·

Let's put it this way: if you have a &mut to a heap allocated object (Box, whatever), you pretend it's unique, BUT its contents are also reachable by the global

Let's put it this way: if you have a &mut to a heap allocated object (Box, whatever), you pretend it's unique, BUT its contents are also reachable by the global allocator, say, malloc. So it's not really a unique reference. If you allocate something new, Rust pretends it is independent, assuming that malloc won't muck with the other objects it knows about. What if we relax that assumption? Allocations may perturb other allocations - that's how moving GC heaps work! Can that be modeled usefully in Rust?

pitaj 6y ago
I think Rust's model with smart pointers and deref could work really well with a colored pointer, short-pause GC like ZGC. Rust has the capability to do things like execute load barriers on access, so it could still work when objects have been moved around.
amaranth 6y ago
The allocator API hands out `*mut u8` so... not really. If you changed the allocator API and everything that uses it and makes assumptions about how it works then sure, you could make it hand out a pointer to a pointer so you could come in later and update the inner pointer after you've done a GC pass. You couldn't do something like handing out a normal `Box` and keeping track of where it lives so you can patch it later though. Rust doesn't have move or copy constructors so as it gets passed around it'll just be `memcpy`'d and you'll lose track of it.
- monadic2 6y ago
  I can’t imagine this utility will be replaced, either, as it’s the essence of why rust works so well with the c abi. Augmented, hopefully?
monadic2 6y ago
Ah, I see what you’re saying, and I am afraid I am out of my depth because this touches on a lot of maintainer intentions I can’t speak to. You are correct in implementation assumptions at least.
fluffything 6y ago
&mut T does not mean what you think it means &mut T means that there is only one pointer (the &mut T) that will be used to access some memory. You can have as many other pointers to that memory as you want, as long as you don't invalidate the first one. This code is safe: let mut foo = 13_i32; let x: &mut i32 = &mut foo; // First &mut { let y: &mut i32 = unsafe { std::mem::transmute(x as *mut i32) }; // Second &mut T (copy) *y = 42; // Write through second } dbg!(*x); // Read through first You can run this under miri here: https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=bd4c7e965c6317f15bcd151a87f373a4 https://play.rust-lang.org/?version=stable&mode=release&edit...

pitaj 6y ago

I think Rust's model with smart pointers and deref could work really well with a colored pointer, short-pause GC like ZGC. Rust has the capability to do things like execute load barriers on access, so it could still work when objects have been moved around.

amaranth 6y ago

The allocator API hands out `*mut u8` so... not really. If you changed the allocator API and everything that uses it and makes assumptions about how it works then sure, you could make it hand out a pointer to a pointer so you could come in later and update the inner pointer after you've done a GC pass. You couldn't do something like handing out a normal `Box` and keeping track of where it lives so you can patch it later though. Rust doesn't have move or copy constructors so as it gets passed around it'll just be `memcpy`'d and you'll lose track of it.

monadic2 6y ago
I can’t imagine this utility will be replaced, either, as it’s the essence of why rust works so well with the c abi. Augmented, hopefully?

monadic2 6y ago

Ah, I see what you’re saying, and I am afraid I am out of my depth because this touches on a lot of maintainer intentions I can’t speak to. You are correct in implementation assumptions at least.

fluffything 6y ago

&mut T does not mean what you think it means &mut T means that there is only one pointer (the &mut T) that will be used to access some memory. You can have as many other pointers to that memory as you want, as long as you don't invalidate the first one. This code is safe: let mut foo = 13_i32; let x: &mut i32 = &mut foo; // First &mut { let y: &mut i32 = unsafe { std::mem::transmute(x as *mut i32) }; // Second &mut T (copy) *y = 42; // Write through second } dbg!(*x); // Read through first You can run this under miri here: https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=bd4c7e965c6317f15bcd151a87f373a4 https://play.rust-lang.org/?version=stable&mode=release&edit...