Dan Sugalski <[EMAIL PROTECTED]> wrote:
Every PMC should have a next_for_GC pointer. You moved it to the ext structure, ...
I moved it there for a good reason: speed. The smaller a PMC the faster is the interpreter.
Right, and this part is only needed by the DOD sweep, the freeze/thaw code, and the destruction ordering code, so since it's in the ext struct it won't get in the way for normal usage.
> ... but it's there, and they all ought to have one. Any PMC thatgets frozen *will* have one, as it needs to have it for traversal to work properly.
Ok. Its a macro and back again in a second *if* needed.
That's easy, then, as it is. :) Besides, from looking at pobj.h, it's already there, so I'm not sure what we'd need to do. Perhaps I need to resync.
>> Using the DOD functionality doesn't match freeze, thaw, dump at all andinterferes with DOD runs.
Oh, nonsense, it doesn't at all interfere with things.
Calling mark sets the live flag on PMC headers. When you use mark() you have to reset the whole arena after a single clone. I expect a lot of clone()s to be emitted by the HLL.
I expect very few clones to be emitted. Past history indicates that it's an unusual operation. Besides, there's nothing wrong with setting the live flag, since the PMCs *are* alive. We don't care about the live flag for this, what we care is that the PMC is put on the traversal list.
If we don't use mark() we are almost at my proposal: have an extra traverse() vtable, that gets a vtable pointer doing freeze, thaw, clone, or dump. If you want to have a general traverse() for DOD too (currents mark?) then you have to pass in a function pointer - or put each and every item on the next_for_GC list.
When you have a PerlArray containing 100.000 plain PerlInts, you have your linked list with 100.001 entries or one entry. You have polluted caches or not - that's it (I'm speaking of DOD here).
So you shortcut in the normal course of DOD? I suppose--I presume you've benchmarked to see if testing all the flags of the contained PMCs when marking the container is faster than just throwing them on the list and checking them when you get to them? I can see that being the case in some cases, but I'm concerned that it'll consume more memory and take more time in some reasonably common cases.
> ... I designed it withthis as one of the applications for the DOD system. It should also work reasonably well for destruction ordering. If it's been changed in a way that makes this untenable, it needs to be fixed so it does.
Or the design ;-)
Yep. In this case, though, design flaws turn out not to be the case. :-P
And I still don't see, how you will handle duplicate lookup of self-referential structures for freeze and thaw with a linked list of items alone.
The same way the DOD sweep handles it, unless you've changed things beyond recognition. The way it used to work is that when you marked a PMC as live, it got put on the end of the chain unless the PMC's next pointer field is non-NULL, in which case it's already been put on the list, and nothing happens.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
