Dan Sugalski <[EMAIL PROTECTED]> wrote: > [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) Yes. Creating a x Meg array is ugly with DOD runs. Destroying that array, though, is much more ugly with refcounts. I had some test, where perl5 did spend ages just to get rid of such an array and Parrot did it in fractions of a second. But we can possibly and sometimes optimize that with hints from the compiler or programer. If we know, that we are creating tons of PMCs its easy: $ parrot -j 10m.pasm create 4e+06 PerlInts 2.697033 DOD sweeps: 1 one is 0.552909 *if* DOD is turned off during filling the array. Thats exactly a factor of 10. with sweepoff - sweepon around the loop. > 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 That *is* already in, kind of. If the previous DOD run didn't yield much, the next one is skipped. Grep for "skip" in F<src/smallobject.c> > *) Lay in a generational garbage collector. Good for that degenerated case, probably, but see below. > *) Put in a mixed-mode garbage collection system. It's not solvable at the GC level IMHO. It needs help by: need_PMCs 1_000_000 # fill Array need_done turning DOD off isn't an option, because you might have a million of PMCs on the free list. > 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. And not for the "plain" and normal way. That's the problem. Refcounting increases object size (yes there is some 1-bit refounting). We are still not talking about reusing objects after a DOD run. The test doesn't do that. With refcounting you are touching the object on each DOD run. With the current ARENA_DOD_FLAGS you are touching 1/8th of that memory (which might still be beyond any caches but ...). And finally I dont't know of any such advanced or generational GC scheme, that doesn't move objects around and/or is strictly architecture dependend, like using mprotect() to catch references to old generations. Not speaking of special hardware support ... Before talking about such schemes, I'd first like to hear about a vague implementation idea. > 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. Sure. I'd be really surprised if such a scheme works better. But any approaches are of course welcome. leo
