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. > ... but it's there, and they all ought to have one. Any PMC that > gets 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. >> Using the DOD functionality doesn't match freeze, thaw, dump at all and >> interferes 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. 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). > ... I designed it with > this 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 ;-) 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. > Dan leo
