You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yay. Probably a regular, pause-the-world mark-and-sweep?
Ideally the GC would be done without polluting the original data model ("mark" in "mark-and-sweep" requires a way to mark objects w/o references), but I'm not sure how feasible that would be. Perhaps an ad-hoc GC-specific Value wrapper just for the time of GC collection?
The text was updated successfully, but these errors were encountered:
type Refcount = Int
data GCValue = GCValue Value Refcount
The only objects that can be cleaned are functions and tables. The global table implicitly extends lifetimes of everything touched by it.
Maybe instead of GCValue it's enough to have GCTableData and GCFunctionData
Then I would go over those two tables separately. First, each of them gets marked with 0. Then, I go through all the tables (starting with the global one) and for every table ref I find the appropriate table and ping it.
This wont work properly when two tables form a cycle. That would require tracking references from global separately somehow
The gc branch doesn't currently merge cleanly, but those changes aren't that important. What's more important is MonadState Context currently introduced. I think the direct access to the context is valuable, but it's probably the point where those things should only be exported to some internal module or something, or simply just exported as separate functions?
Yay. Probably a regular, pause-the-world mark-and-sweep?
Ideally the GC would be done without polluting the original data model ("mark" in "mark-and-sweep" requires a way to mark objects w/o references), but I'm not sure how feasible that would be. Perhaps an ad-hoc GC-specific Value wrapper just for the time of GC collection?
The text was updated successfully, but these errors were encountered: