Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 6:37 PM +0200 8/29/03, Leopold Toetsch wrote:
>>Aren't you saying the opposite of above here? I want to be able to >>traverse from a given start point (being it the own interpreter or some >>PMC) as deeply down as there is something. You did say, that we don't >>recursively mark() because of recursion depth. clone(), dump(), freeze() >>all have these same issues (plus self-referntial structures). > No, I'm just not being clear, so lets fix that. > We don't need any special iterator, since we already have one--the > DOD iterator, which is not only sufficient for our needs its likely > the only thing that *can* have sufficient information to do the > iteration. While a general iterator would be very similar to the DOD iterator, we can't use it IMHO: - this prohibits DOD runs during clone/thaw, when we run out of free headers[1] - it would need an extra function pointer to call the actual vtable (mark, freeze, clone ...) - we have currently shortcuts for DOD marking (is_PMC_ptr ..) which don't play nicely with it probably and most important: - we must track duplicates (or restore pointers to these during thaw/clone) while marking (pobject_lives) just returns here. This would slow down DOD runs remarkably. > ... The encoding subsystem should have a way to > encode: Basically packfile extensions. Yep. [1] when we want to thaw/clone big structures, we should have some means to estimate the amount of needed headers. If we will not have enough, we do a DOD run before clone/thaw and then turn DOD off - it will not yield any more free headers anyway. This can avoid a couple of DOD runs that do just nothing except burning a lot of cycles and massive cache pollution. To achieve this, we might call aggregates.elements() first by means of the iterator again or with some depth restriction and returning, when we reach the free-header limit. leo
