Jeff Clites <[EMAIL PROTECTED]> wrote: > On Nov 19, 2003, at 9:04 AM, Dan Sugalski wrote:
> Two initial concerns: > 1) I have a patch which I've been assembling to do ordered destruction. > That needs to use the next_for_GC pointer (and I think any alternate > implementation would need to as well). But Parrot_freeze_at_destruct() > uses next_for_GC. I assume Parrot_freeze_at_destruct is intended to be > called from a destroy() method; if so, there's a problem, and we'd need > 2 next_for_GC-ish pointers. I don't know yet, when and from where freeze_at_destruct() is run. It seems, that objects are already dead then. That could mean, that destruction ordering is run before. But, even if these 2 get run at the same time, it could be possible to share the next_for_GC pointer - ordering could (if possible) skip some PMCs that don't need ordering. > ... So I > would modify my ordered GC code to use Leo's vtable->visit, but it has > a different notion of what children to visit, ... which, AFAIK isn't carved in stone yet. We don't have a notion for logical children that need ordered destruction. An array holding some scalar PMCs can get destructed in any order. We first should separate destruction (i.e. mainly freeing system memory or maybe closing other resources) and the more HLL-like finalizing, which might depend on other objects to get finalized first. This needs IMHO another vtable, that if present (not default), is a sign for "destruction ordering" or finalizing. > ... so I think we are either > going to end up with two very-similar-but-different vtable methods, or > we'll need extend vtable->visit to allow it to serve both purposes > (either by calling visit with a flag which tells it which type of > visitation to do, The visit vtable passes all "visited" PMCs on to a callback, which puts these on some kind of a TODO list. visit, when called via freeze is different to visit called from thaw. So destruction ordering can setup just its on visit_todo_list() and work on from there. If that's not enough, the visit vtable has all the info, that may be needed in the visit_info structure. > ... or by instead having a flag which is passed to the > visit_child_function to tell it whether this is a "logical" child or > merely a referenced object). I need for freeze/thaw another vist_info structure member called possibly "void *extra" anyway, to be able to e.g. call back to the original PMC to freeze/thaw native data or to handle sparse arrays. While I'd rather have the visit vtable free of such functionality, it seems not achievable. So if destruction ordering has to pass some info, we'll just do it. > JEff I'll try to put together some docs tomorrow, how it currently works and what extensions will be necessary to get freeze/thaw running for all currently known PMCs. We can have a look then, how destruction ordering fits in that scheme. leo
