Dan Sugalski <[EMAIL PROTECTED]> wrote: > On Tue, 21 Oct 2003, Jeff Clites wrote:
>> 1) Serialization traversals need to "take note" of logical int and >> float slots > That's not an issue for us. A PMC is responsible for serializing itself, > so if its got a string, float, or int component then it must take > respnsibility for dumping those components to the serialization stream. > Basically PMCs *must* dump themselves out completely, but the engine > provides support to defer dumping of PMCs so that we don't get into > recursive dumping That's what my general traversal routine was intended for. A PerlHash may have native datatypes as well as PMCs as data members, plus the STRING keys, which are references. The hash itself and plain data members can get serialized/frozen/dumped whatever. The callback takes care of the desired action. PMCs inside (especially aggregates of any kind) would get postponed (only the ID or address needs to be serialized). If that is now done via the next_for_GC pointer, a seen hash a bitmap or whatever is debatable and seems (when destructor level freezing comes in) to be not too simple. But using mark() for it doesn't meat the goal. Its a different thing. It sets the live bit on objects. > That's what custom mark routines are for, though it does argue that we > should have a separate mark for freezing. Which can be traverse or visit or whatever, but different. >> 3) Traversal for GC needs to do loop detection, It stops, when the live bit is set or sets a live bit and places aggregates on an todo list. Its by far simpler then freezing. Its an optimization - yes. > The loop breaking needs for freezing are the same as for DOD sweeps, s/are/can be/ > In all cases (I made sure this was in the example, but it might not have > been clear) we only include a marker for child PMCs in the parent PMC's > serialized data, and serialize the child PMCs later on in the stream. So > if PMC1 has a pointer to PMC2, the stream has PMC1 dumped to it but in the > place of PMC2's data is just a marker saying "refer to PMC2 here" and then > after the end of PMC1's data in the stream we dump out PMC2's data. That's clear. But plain scalars don't have child PMCs. Freez em and be done with them. There is no need to put these on a next_for_GC list, mark() doesn't do it (anymore) and freeze doesn't have to do it. I don't see the small PMCs approach dieing because of that. > Dan leo
