On Mon, Oct 14, 2013 at 3:47 AM, Bennie Kloosteman <[email protected]>wrote:
Why does growing the heap cause a pause ? > Because allocating a (sequence of) underlying pages from the operating system is a surprisingly expensive operation. > 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 . > I'm not sure we do. But we have a subset of people here on the list who state that they are interested in "real time collection." Real-time collection is only interesting if you are doing real-time allocation. So I'm asking for clarification on what the actual requirement is. > > >> 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. > That's one of the things that I am trying to chase down. I don't know how large the young generation is. They don't reference count the young generation at all, which means that they either have to keep a stack map or they are using a ZCT and performing tracing in the nursery. I'm pretty sure they are doing nursery tracing and using a ZCT. If the nursery is small enough, that ought to be okay. Note that they don't necessarily need to do a copying/compacting collection in the nursery. The alternative would be to run the tracing exercise, see how much has survived, and either (a) recycle the nursery block[s] or (b) tenure the * blocks* and allocate free block[s] for a new nursery. The "newness" of objects is recorded at line granularity, so a range of policies is possible here. My point is that you can possibly background evacuation as an alternative to a copying nursery design. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
