4 ms·

Immutable values are reference counted, so for most code, things will be dropped when they exit scope. For captured mutable values, there is a fairly mundane ma

Immutable values are reference counted, so for most code, things will be dropped when they exit scope. For captured mutable values, there is a fairly mundane mark and sweep collector. It is possible to manually control the garbage collector, however I have not optimized it for that kind of workload. If you were embedding Steel in a game, I don't think it would be explicitly necessary to tune the GC as long as you aren't using a ton of mutation. If you were using a lot of mutation and still wanted a relatively performant GC collection at the end of every frame, then the underlying GC implementation would have to be changed or swapped to a different one (which is not impossible - I just only have one GC implemented)

mst 3y ago
You might find the Recycler algorithm interesting - nim's ORC collector is ARC + Recycler and seems to be working out rather well.
- mattparas 3y ago
  Thanks for the recommendation, with some brief poking around it does seem promising! It looks like the algorithm is this? https://github.com/fitzgen/bacon-rajan-cc https://github.com/fitzgen/bacon-rajan-cc The link to the paper seems dead unfortunately from this blog post https://nim-lang.org/blog/2020/12/08/introducing-orc.html https://nim-lang.org/blog/2020/12/08/introducing-orc.html I could see how it works as a drop in replacement for Rc
  - zozbot234 3y ago
    The bacon-rajan-cc link says it's stop-the-world. Samsara seems to be fully concurrent.
    - mst 3y ago
      The bacon-rajan-cc link has only -implemented- a stop-the-world version, but notes right at the top of the README that it -can- be concurrent, and the stop-the-world-only-ness is only 'Currently.' https://trout.me.uk/gc/ https://trout.me.uk/gc/ has two Recycler papers if you want more details.
      - zozbot234 3y ago
        Samsara is implementing the same algorithm and seems to be further along. Though there's also 'shredder' https://github.com/Others/shredder https://github.com/Others/shredder with a different overall approach.
        mst 3y ago
        Ah, I see what you meant now. Thanks for mentioning Samsara, I shall try and remember it exists later today when I'm more caffeinated.
  - mst 3y ago
    https://trout.me.uk/gc/ https://trout.me.uk/gc/ - see recycler-overview.pdf and recycler-algorithm.pdf As with /lisp/ I tend to grab my own copies of papers I think I'll want to refer to later in case the original URL vanishes in a puff of bitrot :)
    - j-james 3y ago
      Heh, neat to see you've got the Perceus paper there too. That is in fact the other part (the "ARC") of Nim's memory management for those unaware - with the only differences being Nim frees memory at the end of scope, rather than last use, and and Perceus maybe might be atomic (do not fully remember. ARC isn't atomic.)
CooCooCaCha 3y ago
Thanks, I think swapping and controlling the GC would be a very useful feature. In the game example I gave performance is important, but what's also important is consistency. Interactive apps rely on a steady framerate so what you want to avoid is accumulating garbage across multiple frames, then doing a single large collection pass. In other words, it's better to do a bit of GC every frame than a bunch at once and risk stuttering.
- mattparas 3y ago
  I'll make a tracking issue for it - new GC work is fun! I'll do some research, I have on my back log to integrate Steel into Bevy or some other Rust game engine, would give me a reason to make some fun GCs
  - CooCooCaCha 3y ago
    Nice! Hopefully my statements didn't come off as demanding. Just providing some info on that use case.
    - mattparas 3y ago
      Not at all! I agree it is a useful feature, I'd be curious how much it is necessary if not using any mutation, but the best way for me to find out is to try it out :)
- zozbot234 3y ago
  There are concurrent GC implementations for Rust, e.g. Samsara https://redvice.org/2023/samsara-garbage-collector/ https://redvice.org/2023/samsara-garbage-collector/ https://github.com/chc4/samsara https://github.com/chc4/samsara that avoid blocking, except to a minimal extent in rare cases of contention. That fits pretty well with the pattern of "doing a bit of GC every frame". (Note that doing GC over large object graphs will nonetheless involve significant overhead, even with efficient implementations as seen here; GC is not at all a silver bullet, and should be avoided if at all possible. The actual point of GC is to enable computing over highly general, possibly cyclical object graphs - if that doesn't apply, other memory management strategies can be used instead.)

mst 3y ago

You might find the Recycler algorithm interesting - nim's ORC collector is ARC + Recycler and seems to be working out rather well.

mattparas 3y ago
Thanks for the recommendation, with some brief poking around it does seem promising! It looks like the algorithm is this? https://github.com/fitzgen/bacon-rajan-cc https://github.com/fitzgen/bacon-rajan-cc The link to the paper seems dead unfortunately from this blog post https://nim-lang.org/blog/2020/12/08/introducing-orc.html https://nim-lang.org/blog/2020/12/08/introducing-orc.html I could see how it works as a drop in replacement for Rc
- zozbot234 3y ago
  The bacon-rajan-cc link says it's stop-the-world. Samsara seems to be fully concurrent.
  - mst 3y ago
    The bacon-rajan-cc link has only -implemented- a stop-the-world version, but notes right at the top of the README that it -can- be concurrent, and the stop-the-world-only-ness is only 'Currently.' https://trout.me.uk/gc/ https://trout.me.uk/gc/ has two Recycler papers if you want more details.
    - zozbot234 3y ago
      Samsara is implementing the same algorithm and seems to be further along. Though there's also 'shredder' https://github.com/Others/shredder https://github.com/Others/shredder with a different overall approach.
      - mst 3y ago
        Ah, I see what you meant now. Thanks for mentioning Samsara, I shall try and remember it exists later today when I'm more caffeinated.
- mst 3y ago
  https://trout.me.uk/gc/ https://trout.me.uk/gc/ - see recycler-overview.pdf and recycler-algorithm.pdf As with /lisp/ I tend to grab my own copies of papers I think I'll want to refer to later in case the original URL vanishes in a puff of bitrot :)
  - j-james 3y ago
    Heh, neat to see you've got the Perceus paper there too. That is in fact the other part (the "ARC") of Nim's memory management for those unaware - with the only differences being Nim frees memory at the end of scope, rather than last use, and and Perceus maybe might be atomic (do not fully remember. ARC isn't atomic.)

CooCooCaCha 3y ago

Thanks, I think swapping and controlling the GC would be a very useful feature. In the game example I gave performance is important, but what's also important is consistency. Interactive apps rely on a steady framerate so what you want to avoid is accumulating garbage across multiple frames, then doing a single large collection pass. In other words, it's better to do a bit of GC every frame than a bunch at once and risk stuttering.

mattparas 3y ago
I'll make a tracking issue for it - new GC work is fun! I'll do some research, I have on my back log to integrate Steel into Bevy or some other Rust game engine, would give me a reason to make some fun GCs
- CooCooCaCha 3y ago
  Nice! Hopefully my statements didn't come off as demanding. Just providing some info on that use case.
  - mattparas 3y ago
    Not at all! I agree it is a useful feature, I'd be curious how much it is necessary if not using any mutation, but the best way for me to find out is to try it out :)
zozbot234 3y ago
There are concurrent GC implementations for Rust, e.g. Samsara https://redvice.org/2023/samsara-garbage-collector/ https://redvice.org/2023/samsara-garbage-collector/ https://github.com/chc4/samsara https://github.com/chc4/samsara that avoid blocking, except to a minimal extent in rare cases of contention. That fits pretty well with the pattern of "doing a bit of GC every frame". (Note that doing GC over large object graphs will nonetheless involve significant overhead, even with efficient implementations as seen here; GC is not at all a silver bullet, and should be avoided if at all possible. The actual point of GC is to enable computing over highly general, possibly cyclical object graphs - if that doesn't apply, other memory management strategies can be used instead.)