Why does growing the heap cause a pause ?
But if our goal is to satisfy a hard real-time guarantee, I only know of > three allocation strategies that actually work: > > - No allocation at all. > - Strictly LIFO allocation with a known upper bound using preallocated > storage. > - Size-partitioned allocation with known sizes and known maxima for > each size, again using preallocated storage. > > Which brings me to the question: what problem are we actually trying to > solve here? > Why do we want to support allocation for hard real time ? static or create storage at start are fine not just for pauses but they reduce bugs. Though the fact is most people hence almost real time is good enough eg linux . > What RC-immix *appears* to do is lower the delay between the time an > object becomes unreferenced and the time it becomes available for > allocation. On paper, that should mean that the scheme requires less > overall heap space than conventional GC. But the reality is less > clear-cut. Lines in a block may go free, but blocks are recycled by GC > and/or allocation. The good news is that this is done without a full > examination of the heap, because we know where frees have occurred. The bad > news is that the delay between object release and recycling of storage can > be higher than you might think from an initial reading of the paper. It > would be interesting to see metrics on that, but the RC-immix papers offer > none. It isn't that hard for RC-immix to put recyclable blocks back in > circulation. It is rather harder for RC-immix to arrange for blocks to be > entirely free. > Also for short lived blocks the time may be worse... do we have a handle on how often the trace runs ? With a GC the Nursury can make this quite quick eg lots of activity forces it to run often and short lived object which can hold OS/DB resources quickly release them . Once teh objects go to Gen1 cleanup takes longer but cleanup time is less of an issue. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
