Joshua Yanovski

In a way, but you're saving on the dynamic overhead of constantly pinning and unpinning. In any case, I think most of the time values pointed to by stack roots are allowed to move in cases like that, except when the trace and copy phases have to be split up for whatever reason.

No I mean if you say you can’t move anything that’s alive, you can’t move anything..

Oh. No, I didn't mean that transitively--was just talking about the stack roots (and globals I guess, but I think all the safe GC interfaces I've ever seen in Rust rely on lifetimes so you don't have to worry about that).

Gotcha. That’s even tricksier tho because you have to map references you get out of the gc, not just the original roots

Well, the idea would be that all the roots are whatever's currently live on the stack *right now* and you somehow know how to trace from that to all Gc'd values. The trick is limiting the places Gc'd values can be hiding... which is a tall order in Rust, as you noted.

This is also assuming a stop the world GC; for parallel GCs it's harder, but I haven't focused too much on that since Rust already has solutions for concurrent data structures that beat general purpose GCs.

But yeah, the alternative is to have the user basically set up their own "safepoints" by making it explicit when collection can occur and requiring you to put all GC'd references into designated locations before it can run. Which is a lot more tedious than stack maps could be...

I don’t know how you could possibly implement stack maps sufficiently for this. If you can get an &T into the gc heap you can’t distinguish it in the map