[mattparas]

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)

[CooCooCaCha]

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.

[zozbot234]

There are concurrent GC implementations for Rust, e.g. Samsara https://redvice.org/2023/samsara-garbage-collector/ 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.)

[mattparas]

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]

Nice! Hopefully my statements didn't come off as demanding. Just providing some info on that use case.

[mattparas]

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 :)

[mst]

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

[mattparas]

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

The link to the paper seems dead unfortunately from this blog post https://nim-lang.org/blog/2020/12/08/introducing-orc.html

I could see how it works as a drop in replacement for Rc

[mst]

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]

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.)

[zozbot234]

The bacon-rajan-cc link says it's stop-the-world. Samsara seems to be fully concurrent.

[mst]

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/ has two Recycler papers if you want more details.

[zozbot234]

Samsara is implementing the same algorithm and seems to be further along. Though there's also 'shredder' https://github.com/Others/shredder with a different overall approach.

[mst]

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.