[HN Gopher] Techniques for safe garbage collection in Rust ___________________________________________________________________ Techniques for safe garbage collection in Rust Author : PaulHoule Score : 81 points Date : 2024-08-21 15:50 UTC (3 days ago) (HTM) web link (kyju.org) (TXT) w3m dump (kyju.org) | amelius wrote: | If you fit a gc on top of rust, the result is going to be less | efficient than when using a modern gc'd language to begin with. | So I'm curious what drove them to this. | the_mitsuhiko wrote: | The answer to your question is in the linked post. | Aurornis wrote: | This is a garbage collector written in Rust, not "on top of" | Rust. | | This isn't equivalent to adding garbage collection to the | entire language. It's a garbage collected pointer type that can | be employed for specific use cases. | | The article and the repo explain why they developed it: | Implementing VMs for garbage collected languages in Rust. | amelius wrote: | > It's a garbage collected pointer type that can be employed | for specific use cases. | | You mean use cases where performance does not matter? | twiss wrote: | Do you think Lua (for example, or any other GC'd language) | has valid use cases? If so, it needs an implementation. | This blog post shows (part of) one way to do that. | remexre wrote: | Use-cases like "implementing a garbage-collected language." | amelius wrote: | High performance garbage collectors are typically written | in assembly because of the intricacies of the cache | hierarchy. | remexre wrote: | Which one(s) are you thinking of? The JVM's appear to be | in C++, GHC's and SBCL's are in C, Go's is in Go, and I'm | not familiar with other high-performance garbage- | collected platforms. | hayley-patton wrote: | Citation very much needed, please; assembly wouldn't give | you more control over caches than any language with a | prefetch intrinsic. | vlovich123 wrote: | Out of curiosity, what language do you think the Java, | JavaScript, and Python VMs and garbage collectors are | written in? If you can understand why the VM is typically | written in a systems programming language that doesn't | itself have a VM or garbage collector, then you can start | to think about why this is useful regardless of whether | performance matters or not (& Java and C# are generally | considered fairly high performance languages and VM | implementations with efficient garbage collectors - the | downsides may not matter to your problem domain). | neonsunset wrote: | To expand on GPs point, I believe it implies that | implementing a GC type for the Rust _itself_ within its | constraints (and even LLVM is not perfect, if we skip to | LLVM-IR) is bound to be worse than in a language with | bespoke precise+tracing+moving garbage collector which | always requires deep compiler integration for "VM" to | have exact information of where gcrefs are located at | every safepoint (including registers!), be able to | collect objects as soon as they are no longer referenced | and not when they go out of scope later, determine | whether write (or, worse, read) barriers are required or | can be omitted and have the ability to suspend the | execution to update the object references upon moving | them to a different generation/heap/etc. | | All GC implementations in Rust that I've seen so far | relied on much more heavy handed techniques like having | GC<T> to be a double indirection, pushing references to | threadlocal queue, have GC pointers to be fat to pass | around metadata inline, etc. They have been closer to | modified RC with corresponding cost. | the_mitsuhiko wrote: | I strongly encourage people interested in this topic to look at | the piccolo VM that has been referenced in the post. It is a | fascinating exploration of how a stackless VM can work in Rust. | It uses "sequences" (think a bit like a future or promise) to | express control flow that yields or calls into other VM methods. | Particularly for a little while now it has the concept of an | async_sequence [1] which allows one to abuse (?) async/await | where it will create a shadow stack to make this code more | readable. | | I find all of this quite exciting because there are not that many | stackless VMs out there that are readable and not a massive | usability hazard if you do something wrong. | | [1]: | https://github.com/kyren/piccolo/blob/master/tests/async_seq... | CyberDildonics wrote: | Why wouldn't I forget about stackless VMs, "sequences" and | yielding calls to VM methods and just make a normal native | program with a lock free queue? | the_mitsuhiko wrote: | Quite frankly I don't understand the question. The assume | here is that you have the goal is to have/write a dynamic | language you will have to write a VM. If you write a VM a | stackless model is the preferred one for a variety of | reasons. However not having a stack causes pains for native | calls that can detour via native objects back into the VM. | That you often have when embedding these languages (which is | the goal). | | So if you have that sort of setup, you will need to find | solutions. | | What piccolo does is quite pretty and definitely beats some | other options out there. A lot of stackless VMs just crash | horribly if you do something naughty with re-entrant calls. | twiss wrote: | Companion blog post: https://kyju.org/blog/piccolo-a-stackless- | lua-interpreter/ | keithalewis wrote: | Techniques for safe garbage collection in C++: unique_ptr and | right curly brace }. Linear types with delayed gratification. | slaymaker1907 wrote: | This is assuming people don't abuse it and pass around raw | references/pointers to it (they will). The safest construct, | though with definite performance impact, is std::shared_ptr but | people think they are smarter than they are and don't use it. | SkiFire13 wrote: | This is neither safe (you can still get raw pointers/references | to its contents) nor garbage collection in the usual sense (you | can't even share it!) ___________________________________________________________________ (page generated 2024-08-25 09:00 UTC)