On Thursday, January 29, 2004, at 08:41 , Dan Sugalski wrote:
So, while I'm heaping much grumpiness on threads (though I suppose, as I've been out of touch for a bit maybe you've all solved the problem. That'd be nice) I've also been thinking about DOD, as there's a fair amount of overlap in the things that cause problems for threads and the ones that cause problems for generational garbage collectors.
Can you elaborate a bit on your concept of generational collection as they apply to parrot? To my ear, generational collection implies all of this (which is a lot, and a lot of it grossly inapplicable to parrot as the runtime now stands):
[Description snippage]
From my reading of the literature the generational collectors don't have to be copying collectors -- the only thing that's ultimately required is an identification of which generation an object is living in. Granted, with an absolute minimum support in the data (just a generation count) it makes collection pretty slow, but that's all you *need*.
Having all the objects of a generation in a single pool does make life significantly easier, to be sure, but you don't need to have the objects *themselves* in a single pool -- just have a quick way to identify all the objects in a generation. We could do that with a separate generation pool if we wanted, at the cost of a pointer per PMC plus overhead for the pool segmentation, much the way that we have the freelist for PMCs.
Might ultimately be untenable, of course. On the other hand, the code infrastructure and APIs needed for a generational collector are the same as the ones for incremental and concurrent collectors, so we may well just jump to an incremental collector instead if it turns out to be more worthwhile or less hassle.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
