4 ms·

If you read the paper, they needed to throw out the thread safety from Rust's borrow checker in order to make the GC work. That is a massive surface area for bu

If you read the paper, they needed to throw out the thread safety from Rust's borrow checker in order to make the GC work. That is a massive surface area for bugs they are opening back up to make the language easier for beginners.

bjourne 5y ago
Because their gc is a proof-of-concept created specifically for this research. It doesn't even deallocate memory. Most likely, they didn't have their students write any threaded code so thread-safety wasn't a concern. For a production ready tracing gc, of course they would add thread safety, it's not a big problem.
- dahfizz 5y ago
  No, this is the fundamental tradeoff they made to make the Bronze'd Rust easy to use: > Rust permits only one mutable reference to a value at a time... With Bronze, mutation is permitted through all references to each garbage-collected object, with no extra effort. A key tradeoff is that Bronze does not guarantee thread safety; as in other garbage collected languages, it is the programmer’s responsibility to ensure safety. Allowing mutability anywhere is what fundamentally makes Bronze easier to learn, and more error-prone.
  - bjourne 5y ago
    The paper's author has already explained to you how thread safety can be achieved in a production-ready gc. This is not something that is particularly difficult to engineer and is quite orthogonal to whether one chooses to use tracing gc, ref counting or Rust-like borrow checking.
mcoblenz 5y ago
I just added a clarification to the README about this. The main issue is that the current implementation keeps track of roots with a shadow stack technique (https://llvm.org/docs/GarbageCollection.html#using-llvm-gcwrite https://llvm.org/docs/GarbageCollection.html#using-llvm-gcwr...), which is not thread-safe. It wasn't worth the engineering work for this particular study since the tasks didn't require more than one thread. A practical implementation, of course, would need to be thread-safe.
- dahfizz 5y ago
  I'm sure the GC implementation itself could be made thread safe. But the paper mentions that Bronze lets you have multiple mutable references to an object. Doesn't this open the door to the user's code having data races, whereas it would be safe by default in vanilla Rust?

bjourne 5y ago

Because their gc is a proof-of-concept created specifically for this research. It doesn't even deallocate memory. Most likely, they didn't have their students write any threaded code so thread-safety wasn't a concern. For a production ready tracing gc, of course they would add thread safety, it's not a big problem.

dahfizz 5y ago
No, this is the fundamental tradeoff they made to make the Bronze'd Rust easy to use: > Rust permits only one mutable reference to a value at a time... With Bronze, mutation is permitted through all references to each garbage-collected object, with no extra effort. A key tradeoff is that Bronze does not guarantee thread safety; as in other garbage collected languages, it is the programmer’s responsibility to ensure safety. Allowing mutability anywhere is what fundamentally makes Bronze easier to learn, and more error-prone.
- bjourne 5y ago
  The paper's author has already explained to you how thread safety can be achieved in a production-ready gc. This is not something that is particularly difficult to engineer and is quite orthogonal to whether one chooses to use tracing gc, ref counting or Rust-like borrow checking.

mcoblenz 5y ago

I just added a clarification to the README about this. The main issue is that the current implementation keeps track of roots with a shadow stack technique (https://llvm.org/docs/GarbageCollection.html#using-llvm-gcwrite https://llvm.org/docs/GarbageCollection.html#using-llvm-gcwr...), which is not thread-safe. It wasn't worth the engineering work for this particular study since the tasks didn't require more than one thread. A practical implementation, of course, would need to be thread-safe.

dahfizz 5y ago
I'm sure the GC implementation itself could be made thread safe. But the paper mentions that Bronze lets you have multiple mutable references to an object. Doesn't this open the door to the user's code having data races, whereas it would be safe by default in vanilla Rust?