Jeff Clites <[EMAIL PROTECTED]> wrote: > On Nov 19, 2003, at 1:34 PM, Leopold Toetsch wrote:
> ... What I'm really worried about here is the case > where something like an array may have a reference to some PMC which > its using as a cache, but which is not supposed to be archived along > with the array (because it's not part of the "contents" of the array). > The GC traversals need to know about this reference, but freezing does > not. Seems to me like kind of a weak reference. GC would have to mark the hash and the keys, but not the values. We will need special PMCs for such cache-like things, where the visit() vtable does the right thing. >> 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. > I've been assuming that these two are tied--that for an HLL object, > whatever PMC is used to implement it would be responsible for calling > the HLL DESTROY() from the PMC's vtable->destroy. For the HLL case yes. But we are currently "finalizing" e.g. ParrotIO objects too. We should separate vtable->destroy() (free system memory) and vtable->destruct() or vtable->finalize(). The latter might have ordering issues and has to be done always on each interpreter shutdown. The former hasn't to be done for the last interpreter. > ... If not, then I'm > pretty confused--because any recycling of objects is going to need a > global view of what is reachable, and of what things reference what > other things. But I may be missing something, so I'm anxious to hear > your thoughts about this. We need a notion for a PMC logically referencing another PMC and for an orderly destruction of such containers. As said, an array holding PerlInts doesn't impose any ordering constraints. An array of objects does (or may do). > ... In particular, > as I had thought of it vtable->mark would be re-implemented in terms of > vtable->visit, since ordered destruction and mark both care about > _exactly_ the same "child" objects. In that case, visit_child_function > would basically be pobject_lives(). While this is true, it will very probably not happen for performance reasons. DOD is called thousands of times during normal operation and has to be as fast as possible. All other functionality using visit() isn't really that time-critical. > That sounds good. I'll wait for the docs, and then we can discuss it > more. docs/dev/pmc_freeze.pod > But I'm pretty optimistic that we've converged on very similar > approaches to two different problems, and I think we'll be able to > arrive at a unified solution to both. Yep, that was/is the goal. > JEff leo
