As Nick seems to be hitting some limits, I've tried this: stuff a differing amount of PMCs into an Array and time a DOD run:
[Progressively nastier numbers snipped]
Athlon 800, optimized build. These 78 DOD runs all taking half a second are of course totally in vain. There is nothing to be recycled, all is alive in the array. So around approaching one million live PMCs things get starting look really ugly.
That's with Scalars, that don't have a next_for_GC pointer. They are marked directly in the fast path.
Now do the same and use a PMC *with* a next_for_GC field (note - the created Array is really almost empty just one Buffer_header.
[Even worse number snipped]
Yeah, you've hit the degenerate case. The current DOD system is geared towards a relatively small live set, and cases where we actually find garbage when we trace the live set. (This is a case where refcounting is the better option, though it goes nuts as well if you guarantee timely destruction when the array dies)
There are a few things we can do to make things less bad. In order:
*) Some feedback on DOD performance to tune things, so failed allocations sometimes trigger new pmc pool allocation rather than a trace run
*) Lay in a generational garbage collector.
*) Put in a mixed-mode garbage collection system.
The mixed-mode system's more complex than a generational system (since it mixes generational collection with tracing and refcounting) but it's likely the best way in really nasty situations.
If we start getting the pointer accessor macros in now we can layer in a generational or mixed-mode (or pluggable, I suppose) collector later without messing around with the internals much.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
