I've sketched out a plan for implementing garbage collection in my Lox interpreter. I skipped ahead to the garbage collection chapter in Crafting Interpreters, for inspiration. I can't draw directly from it, due to the following points of difference:
- Implementation language
- Memory representation of values
- Update strategies
- Degree of implementation completeness
However, it did still help, because of general inspiration, and the considerations of "when and how often do we want to run the GC?" are equally relevant.
My initial plan for this, and this is trying to work with the rest of my design, is to, instead of recreating the state variables but with one less entry each time, I would just traverse the state variable data to populate mutable versions of the state variables, then convert those to an immutable form, and replace them in. By planning for this approach, I was able to remove some lines I'd added due to anticipating using a different approach.
Looking over the structure of all of this, I think the way I want to implement this is with mutators around the top-level containers, because none of the items in the container get mutated. I'm going to need to sketch out some of the details by hand, but my current thinking is that I can write helper functions that modify the mutators, and iterate over the referenced items using some methods and helpers I need to write, but only if the item was not already in the mutator.
I think that'll work, but we won't know for sure until I flesh out the design and actually try to implement it.
My basic plan right now is to get this stuff implemented, write any tests I need to get coverage back up, and then change gears to tooling. It seems to me that limit-coverage and my mutation testing helper should be able to share config logic. And possibly cell as well. I'll be really excited if it ends up going that way.