The problem is that this study is relatively worthless, because the API used by this GC inherently introduces UB. If you have a correct API, the usability tradeoff might be very different.
To phrase what my sibling commentor said but in a different way:
This paper is an experiment to see if a particular API could make using Rust easier. This specific API is not sound. This means that the paper's results are kind of irrelevant in a strict sense; this API cannot work in Rust, so it being easier is kind of a moot point. Maybe someone can take their API, make it sound, and then try again, and that's certainly good. But it is a serious flaw in the methodology.
Specifically, this API call is unsound:
GcRefCell<T>::as_mut(&self) -> &mut T
It's not about the internals of the GC. It's about the API that it exposes to users.
The author has some ideas: https://github.com/mcoblenz/Bronze/issues/2#issuecomment-939... These ones are straightforward, and would probably work, but they would also introduce some friction, and removing friction is the entire point of the exercise. Is it too much? Maybe! It also maybe isn't. You'd need another study to figure that out.
> This paper is an experiment to see if a particular API could make using Rust easier.
According to the author: "The Bronze project is exploring the usability costs of the restrictions that Rust imposes."
That does not require a sound gc to explore. Maybe it would have been different had the goal been to see whether a gc can be bolted onto Rust. Yes, that might be difficult given Rust's semantics and how to deals with pointers. But that doesn't seem to be the goal of the author's research.
Again, it's not about the GC being sound, it's about the API that's being used. There's (imho) not a lot of value in figuring out if an API that can't be used is usable.
There are other GC crates that offer sound APIs. Research using those sounds very promising and good!
Then explain to me why it matters. If none of the toy examples in the research actually required multiple mutable references to the same objects, then why would it matter that the compiler allowed it? I think you missed the point of the research: to "explor[e] the usability costs of the restrictions that Rust imposes."
If they didn’t require it, then that would significantly strengthen the paper! They could have not exposed that API and it would be much more useful. I suspect that they probably did need it though. An immutable GC would only be useful by adding an interior mutability wrapper, which is exactly the kind of friction the paper is trying to avoid.
It matters because the rest of the Rust universe follows this pattern. If they coded their own standard library (and any other allowed libraries) and modified the compiler to not miscompile this usage, then that exploration would be valid. But you’re also going to get friction from miscompiles and fighting with other APIs that do have this property. So it would be more useful to either go all-out ok this idea that Rust’s uniqueness properties are a bad thing, or fix the soundness issues. The halfway step simply confounds too many issues to be truly useful, in my opinion.
I agree that exploring the space is a good idea and useful. My issue is with the methodology, not the concept.
The problem isn't that the GC suffered from use after free. The problem is that the GC allowed the user to have 2 references to a mutable object which is UB in Rust (and a compile time error without unsafe code). The problem with the API is that without some pretty fundamental changes to the language, the only times a GC doesn't error, and Rust does is when the user tries to do undefined behavior. Removing the UB is also pretty much impossible because if you allow these references, you remove one of the main tools the Rust compiler uses to optimize code.
Having simultaneous mutable references to an object is UB in Rust because the memory manager cannot detect use-after-free errors. What you are talking about is not a feature but a limitation of Rust's borrow checker. But when using a gc multiple multiple references it not a problem at all so there is no reason to prevent it. This has almost nothing to do with performance. Restricting the number of mutable references to one does not mean that the compiler can emit significantly faster code.
> Having simultaneous mutable references to an object is UB in Rust
This is correct.
> because the memory manager cannot detect use-after-free errors.
... this is not. It is UB because the language declares it UB. It is absolutely to the core of the design of the language itself. All Rust code relies on this property to work. Something that breaks it is in fact broken, regardless of any other aspect of the program.