A Tour of Safe Tracing GC Designs in Rust
manishearth.github.io
A Tour of Safe Tracing GC Designs in Rust
1–10 of 61 posts
Re: A Tour of Safe Tracing GC Designs in Rust
#2Having something like this available as vocabulary types would be quite nice for GUI libraries.
Re: A Tour of Safe Tracing GC Designs in Rust
#3Some history of the question of whether Rust should have GC as standard:
2014-09. RFC 256 https://rust-lang.github.io/rfcs/0256-remove-refcounting-gc-...
« Remove the reference-counting based Gc type from the standard library and its associated support infrastructure from rustc.
Doing so lays a cleaner foundation upon which to prototype a proper tracing GC »
Contemporary with that: https://news.ycombinator.com/item?id=8312327 nikomatsakis:
« I wouldn't be so quick to give up on GC support yet! "We have a plan!" But I don't think we'll have it in for Rust 1.0. »
2015-04:
https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h...
"Memory safety without garbage collection." is now advertised as a "key value proposition" (this isn't quite the same as saying "we're not thinking of ever adding garbage collection", of course).
2016-08: https://manishearth.github.io/blog/2016/08/18/gc-support-in-...
« Recently we (Felix, Niko, and I) have been working on getting compiler-level GC support for Rust. The plan is to provide a base set of APIs and intrinsics on which GCs can be built, without including an actual GC itself. »
This is the "Unfinished design for a builtin Rust GC" described in TFA.
2018-10:
the introductory post for the shifgrethor library (described in TFA): https://boats.gitlab.io/blog/post/shifgrethor-i/
includes a bolded « I do not expect we will ever “add GC to Rust” ».
Re: A Tour of Safe Tracing GC Designs in Rust
#4Wouldn't it make more sense to have garbage collectors at the level of LLVM?
That way, you could have direct access to all the pointers in a program without jumping through the language's hoops. And other languages could benefit from it too.
Re: A Tour of Safe Tracing GC Designs in Rust
#5Wouldn't it make more sense to have garbage collectors at the level of LLVM? That way, you could have direct access to all the pointers in a program without jumping through the language's hoops. And other languages could benefit from it too.
Yes, it makes total sense for the garbage collector to be tightly coupled to the memory allocation system, which is also tightly coupled to code generation (as is done in the case of various high-performance managed languages: Java, C#, Haskell, …). I remember hearing a talk a few years ago about a system of the kind you’re talking about - a kind of “managed language” micro-core that ran alongside LLVM so that it could hook into code generation, and was intended to be a kind of toolkit for making new managed languages. Can’t remember the name…
Re: A Tour of Safe Tracing GC Designs in Rust
#6Wouldn't it make more sense to have garbage collectors at the level of LLVM? That way, you could have direct access to all the pointers in a program without jumping through the language's hoops. And other languages could benefit from it too.
The concept of what a pointer "is" is somewhat language-dependent, particularly as people finally attempt to mitigate the waste of moving to 64-bit by using tagged pointers (which maybe could try to be modelled in LLVM also, but I think you will rapidly realize that LLVM just isn't modeling a lot of things that affect scanning).
Re: A Tour of Safe Tracing GC Designs in Rust
#7Wouldn't it make more sense to have garbage collectors at the level of LLVM? That way, you could have direct access to all the pointers in a program without jumping through the language's hoops. And other languages could benefit from it too.
LLVM has built in hooks for GC, used by Azul's Zing JVM JIT compiler and perhaps Safari's LLVM JS JIT.
I'm not sure if the GC integration is tied to JIT support or not. I think it's mostly related to insertion of safepoints which could be useful for Rust implementation
Re: A Tour of Safe Tracing GC Designs in Rust
#8One day, Rust needs a GC. Reference counting is a just crappy GC. Modern GC can perform better than this so Rust is actually hurting its own performance by not having one.
A good GC would make heavily concurrent apps much easier to build with Rust. And would have better performance than the typical Arc Mutex objects passed around right now
Re: A Tour of Safe Tracing GC Designs in Rust
#9>In Go, the compiler needs to automatically insert code that checks the “pulse” of the heap every now and then, and potentially runs garbage collection. It also needs to automatically insert code that can tell the scheduler “hey now is a safe time to interrupt me if a different goroutine wishes to run”
Is it still the case after Go 1.14 (February 2020) when asynchronous preemption was implemented? As far as I know, goroutines are now preempted using signals instead of inserting checks at every function call.
Re: A Tour of Safe Tracing GC Designs in Rust
#10The OP does not seem to mention CactusRef https://crates.io/crates/cactusref which provides deterministic deallocation (on par with simple refcounting) of reference cycles, with minimal tracing requirements and minimal memory overhead.