Hacker News Reader

Comment by ridiculous_fish | Hacker News Reader

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?

View on HN

&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&edit...

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.

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.

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?

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.

Reply on news.ycombinator.com