[HN Gopher] Techniques for safe garbage collection in Rust
       ___________________________________________________________________
        
       Techniques for safe garbage collection in Rust
        
       Author : PaulHoule
       Score  : 37 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."
        
       | 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/
        
       ___________________________________________________________________
       (page generated 2024-08-24 23:00 UTC)