On Friday 11 April 2008 17:27:34 chromatic wrote: > 1) The Garbage Collector is algorithmically inefficient. There are various > potential optimization strategies here which don't require us walking every > allocated header in the system multiple times (yes, it's that bad in at > least two places), but the real solution I suspect is to replace the > current GC with at least the one specified in the new GC PDD.
I realize there's a third (potential) problem with the GC. I don't recall offhand (and I don't have time at the moment) to see if it keeps any statistics about whether the current GC run actually reclaimed anything substantial. That is, if we exhausted a free list and ran the GC but only freed a couple of headers, we know we'll just have to run another full mark and sweep shortly anyway. My evidenceless guess is that it's worth just allocating another empty pool unless we've reclaimed 1/3 to 1/2 of a pool's worth of headers. This is probably an optimization we should consider for any GC scheme. Oh, and while I'm asking for magic flying ponies who eat garbage and produce candy, wouldn't it be nice to have a way to allocate a PMC or other PObj you know you need for a couple of instructions and then never again and then immediately free it? -- c
