2 ms·
Thanks for the reply, what you wrote makes sense to me. I want to expand on the copying GC ideas: > I want to make this GC moving at some point and didn't thin
by ridiculous_fish 4y ago
Thanks for the reply, what you wrote makes sense to me. I want to expand on the copying GC ideas:
> I want to make this GC moving at some point and didn't think the rooting system would be a limitation.
Currently the rune RootSet is "a list of pointers to be treated as roots" and so long as the pointer is in the list, the GC will not collect it, and you are free to pass around copies of that pointer. But if the heap object were to be moved, the GC could only update the pointers in the RootSet, not those on the native C (err, Rust) stack. So you would get dangling pointers, which is bad.
One solution for this is double indirection:
1. StackRoot changes from "a pointer which should be rooted" to "a location in memory containing a pointer which should be rooted, and this location is known and updated by the GC."
2. You stop passing around copies of pointers, you pass around pointers to a StackRoot which itself contains a pointer. We do this because the GC may change the pointer stored in a StackRoot at any collection point. Hence double indirection: we have a pointer to a location which is known by the GC, which in turn contains a pointer to our data.
This approach is mind-bending and took me a while to grok.
- celeritascelery 4y agoahh! That makes sense now. You are right, that would have to change to enable a copying collector.