Comment by monadic2 | Hacker News Reader

Comment by monadic2 | Hacker News Reader

Parent Full thread

If by GC you’re referring to its reference counting, either by Rc or Arc, there is no GC reachability beyond the reference counting. The responsibility for counting the contained object and dropping (cleanup before dealloc) is up to the type, either Rc or Arc (a stands for atomic, not automatic, as both are “automatic” in the sense that you never need to manually increment or decrement a reference). the owned, mutable object would contain the type information necessary to generate the right Rc calls ay the right time, but a distinct type is necessary to encapsulate the behavior.

There are also escape hatches, between unsafe leaking and the RefCell type, to provide “interior mutability”, i.e. mutable aliasing via an without the memory safety issues which come with this. Note I have only had to use the unsafe bits when passing memory up to a c stack.

I don’t believe there is a tracing GC implementation in the standard library, although I’ve heard plenty of discussion and you can find some simple implementations on crates.io. However, I would assume there would need to be some language changes to properly account for assumptions on how the Drop (free) functionality fires, not to mention significant backend work for tracing to work.

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?

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

Edit: I left out a phrase apparently, it should be “...mutable aliasing via an apparently, to the lifetime checker in each function, an immutable reference”.

Reply on news.ycombinator.com