3 ms·

This study, along with their GC library, is fundamentally flawed: The Bronze garbage collector doesn't just provide automatic memory management, it also allows

by adwn 5y ago

This study, along with their GC library, is fundamentally flawed: The Bronze garbage collector doesn't just provide automatic memory management, it also allows shared mutable references! This undermines one of the most critical principles of Rust, one which is necessary for many of Rust's safety guarantees: There is never have more than one live mutable reference to the same memory location. As soon as you create two mutable references to the same memory location, you get undefined behavior, even if you don't dereference them. That's why the entire approach is flawed: They didn't study "Rust + GC", but effectively created a new language. See [1] for more details. Personally, as someone who uses Rust professionally, I believe optional GC would be a great addition to Rust! The compiler would provide support for GC, and the actual GC runtimes would be library-based, similar to how async/await is handled. However, this GC would merely replace Arc/Rc, not Mutex/RefCell/Cell. [1] https://users.rust-lang.org/t/bronze-gc-and-aliasing-problems/65679/9 https://users.rust-lang.org/t/bronze-gc-and-aliasing-problem...

codeflo 5y ago
I absolutely agree. There’s prior art in that direction. It’s more or less abandoned now, but Microsoft developed an extension to C++ that integrated the .NET runtime with it’s garbage collector called C++/CLI. The way it worked is that in addition to C++’s native pointers and references (Foo* and Foo&), you had a new kind of garbage collected reference, written Foo^. There were some annoying limitations that a GC built directly for this use case might have solved better, but mostly, this worked really well. And I think Rust would be a much better target language for such a system than C++ was. For example, one of the interesting problems was that the .NET GC is compacting — it will move objects around to improve cache locality and simplify the allocation algorithm. To interact with ordinary C++ code, you need native pointers into GC’d objects. But it was only safe to take such a pointer while you told the GC to temporarily “pin” the object in memory, otherwise, your pointer could be randomly invalidated. Forgetting that step was a very evil source of nondeterministic memory bugs. It’s not hard to see how the borrow checker would help there.
- pjmlp 5y ago
  It isn't abandoned at all, it was one of the milestones for .NET Core 3.1 release and is currently up to date with C++17. Much easier than dealing with P/Invoke declarations or dealing with COM over RCW/CCW layer.

by adwn 5y ago

codeflo 5y ago

I absolutely agree. There’s prior art in that direction. It’s more or less abandoned now, but Microsoft developed an extension to C++ that integrated the .NET runtime with it’s garbage collector called C++/CLI. The way it worked is that in addition to C++’s native pointers and references (Foo* and Foo&), you had a new kind of garbage collected reference, written Foo^. There were some annoying limitations that a GC built directly for this use case might have solved better, but mostly, this worked really well. And I think Rust would be a much better target language for such a system than C++ was. For example, one of the interesting problems was that the .NET GC is compacting — it will move objects around to improve cache locality and simplify the allocation algorithm. To interact with ordinary C++ code, you need native pointers into GC’d objects. But it was only safe to take such a pointer while you told the GC to temporarily “pin” the object in memory, otherwise, your pointer could be randomly invalidated. Forgetting that step was a very evil source of nondeterministic memory bugs. It’s not hard to see how the borrow checker would help there.

pjmlp 5y ago
It isn't abandoned at all, it was one of the milestones for .NET Core 3.1 release and is currently up to date with C++17. Much easier than dealing with P/Invoke declarations or dealing with COM over RCW/CCW layer.