> At 12:06 AM -0400 5/19/02, Mike Lambert wrote: > >Is there a plan to make a freed method for when pmc header gets put back > >onto the free list? (This would require we call this method on all pmc's > >before moving anything to the freelist, in case of dependancies between > >pmcs and buffers) > > Nope. I don't see a need--once the PMC's been destroyed, it belongs > to the system.
Um. I see we have a destroy() vtable method, but it's only called when one calls the destroy() op, and the PMC has PMC_active_destroy_FLAG. I don't get this. What's the point of actively-destroying things? I thought since we had a GC, we don't need to worry about this kind of stuff. I'd argue that destroy() should get called when the PMC gets put back on to the free list (similar to destructors in C++). That was the behavior I was documenting when I discussed destruct below, at least. > Collect's dead, I think. I'm not seeing the point anymore, and since > we do collect runs through the buffers and not the PMCs, there's no > place to find what needs calling. Well, the hashtable could certainly use it. :) There is a hashtable pmc, which stores a bunch of pointers into some internal buffer data. Every time functions get called, it calls restore_invariants to fix them up. It might be better to do those fixups in the collect() method, so that they could update their internal data pointers. Or perhaps it should be rewritten to use indices. :) Mike Lambert
