On Mon, Oct 14, 2013 at 11:56 PM, Jonathan S. Shapiro <[email protected]>wrote:
> 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 that wont stop the progam , just allocating threads which is not as important. > >> 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. > No allocation etc are all fine but i supose what we dont want is another thread / stop the world stopping a non allocated thread. > > >> >> >>> 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. > Why use a ZCT ? , I mean to find zero counts you can just scan the Nursery when you need to evacuate it presuming its sequentailly allocated ( which im not sure about as they apear to have a similar structure to the main heap in there diagreams) but that does help you need live objects ? Actually the tracer should identify life objects which need to be copied and hence work out the counts but this is a whole heap trace. To minimize this time 2 Nurseries would be attractive. Im thinking too much like GCs just re reading im not even convinced there is a nursery just a "modbuf" a list of modified objects which new objects end up on. I supose the allocation is a bit like a nursery eg bump ptr and limit of a "block" but im not going to call it that unless its copying , Note re min effective heap size could be improved its a function of fragmentation. The faster degradation in RC Immix compared to GenIm- mix at the very smallest heap sizes is likely to be due to the more aggressive defragmenting effect of GenImmix’s copy- ing nursery. When a nursery collection occurs, those objects that survive are all copied into the mature space, which uses the Immix discipline, in the case of GenImmix. So while the surviving objects may be scattered throughout the nursery at the start of the collection, they will generally be contigu- ous after the nursery collection. GenImmix will tend to have a less fragmented mature space than RC Immix because the mature space is not intermingled with the fragmented young space, as it is in RC Immix and Sticky Immix. The result will be two-fold; both improved spatial locality and more importantly, reduced fragmentation which will substantially reduce GC load at small heap sizes, as seen in Figure 4(c). Furthermore, as hinted by the data cache miss rates for semi- space in Table 1, the copying order of a copying collector will generally result in particularly good locality among the surviving objects. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
