Hi, [Sorry for not replying earlier... this got lost in my inbox somewhere.]
John Leuner <[email protected]> writes: > It's not clear to me how you can distinguish between an object pointer > and an integer at garbage collection time? I assume your figure language > is not typed (doesn't have a type checker), Yes, you're correct. > unless you're able to use the C type checker for that? No, I can only use the C type checker for early-bound bootstrap calls, since everything is late-bound either through Figure's multimethod bind or an untyped ccall. > Besides the stack frames, can you distinguish between integers and > object pointers in heap allocated objects? Every gc root is either a tagged integer (low bit set, a la Cola) or a pointer to an object with a header that was allocated by the runtime. The header specifies the allocated size, garbage collector metadata, and multimethods that the object participates in. Each list of multimethods begins with a special method that specifies the object's debug name and a function that folds over the object's tagged/pointer elements (but not the "opaque" pointers allocated outside of Figure, or "raw" C integers). So, an object can use whatever encoding it wants to for its data, so long as the fold function decodes the pointers correctly. This is exploited to properly type the object representing the registers of the VM, which may contain raw C integers and pointers as well as tagged integers or object pointers. The incremental garbage collector calls each root object's fold with a function that adds white objects to the greylist, then folds over and blackens each greyed object until there are none remaining. Then, the sweep phase frees all the old whitelisted objects, then invokes any destructors for the newly whitelisted objects. Hope that explains things a bit better, -- Michael FIG <[email protected]> //\ http://michael.fig.org/ \// _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
