Dan gave a list a bit ago about some minimal assumptions about how we'll deal with memory. I've been researching various memory management techniques, and I'm noticing that various optimizations can occur if certain assumptions are made.. It's still early in the game, but I thought it might be helpful to see if we could identify any other "truths" that we can take advantage in selecting an algorithm.
1) Are we allowing _any_ dynamic memory to be non-GC-managed? I assume that there are core parts / naive-extensions that assume a malloc/free memory model. While we could always define free as an empty macro, I think it would be to our benifit to utilize regular mem managers where possible. Further, our memory format wouldn't necessarily be compatible with external libraries anyway. 2) Can we assume that a "buffer object" is ONLY accessible by a single reverse-path-to-PMC? PMC's or array-buffers can point to other PMC's, so it's possible to have multiple paths from the root to an object, but I'm asking if, for example, we could use an algorithm that relied upon the fact that it only has one direct parent. 3) I believe Dan said that we _could_ assume that PMC's were unmovable, but are we requiring this? This is related to the next question. 4) Are _all_ handles (PMC's, Strings, or whatever) that serve as root-set elements dynamically allocated? Or can c-code declare PMC-structs instead of PMC-structs-pointers? That Dan defined a "foreign access" portion of the root-set suggests to me that c-code might acquire it's own handles (though we can enforce an API for their allocation). This is important because we do have to perform garbage collection on the handles. If a register-stack is decremented, for example, valid pointers to PMC's / string would become garbage that requires some sort of collection. While this is easy enough to manage, a heterogenous pool of handles would complicate things (and disqualify many desirable algorithms). I'm evaluating algorithms for the handles which requires prepending a linked-list. It's easily hidden away and thus ignored by non memory manager algorithms IFF we require that all handles be allocated by the API. This will be especially important since root-set navigation in it's raw form will be slow due to the complex nature of some data-types. That's all for now. -Michael
