Just been looking at the Gen-Immix code and want to note a few things 1) Line size in production for Immix is now 256. 2) The implimentation of Gen-Immix is just the Jikes default Generational Nursery and the default Immix space , from a glance there were little changes from pure Immix ( it looks like it just uses the Immix and Gen collector code with no changes) . There is no changing of behaviour to account for the diffirence.
The block size for Immix is really chosen for cache size as it has no Nursery* but we may well find with a specialised Nursery as per Generational Immix that a larger block becomes more worth while based on the fact that less short lived objects admitted to the heap due to the Nursery the cost is an increase in fragmentation / copying but once you start talking double pages . Im still convinced in cases where you dont need micro pauses that a mark a sweep nursery adds a lot of value .. Generational Immix beat RC-Immix easily at the crucial 1 - 1.5* heap figure 4a. *Immix has no Nursery per-se , main heap blocks are allocated via a local thread allocater ( each allocater uses 2 blocks recycled or new and a initial empty block for mid size object ) . The confusing bit that looked like a Nursery is just the initial state when there are no recycled blocks in which cases it just uses new blocks until all free blocks are used. It then goes to a cycle of use all recycled blocks , then all free blocks then collect. I believe RC-Immix is also like this but the paper if not clear , it is clear they dont sweep and have lower locality because of this and it should benefit from a Nursery. They do copy / compact when needed. This means while we are confident in the fundamentals of the collector we will basically need to tune / redesign it to handle a nursery , the best approach is probably to port the Gen-Immix collector from Jives which has a good design for changing GC , then introduce RC-Immix main heap and tune it compared to Gen-Immix and possibly a standard generational collector which Gen-Immix uses. Ben On Sat, Oct 19, 2013 at 1:03 AM, Jonathan S. Shapiro <[email protected]>wrote: > On Fri, Oct 18, 2013 at 8:21 AM, Bennie Kloosteman <[email protected]>wrote: > >> My *guess* is that surviving objects are unconditionally moved to the >>> general heap. If so, *some* of those objects will be very young, which >>> will lead to heap churn. >>> >> >> My guess is moved to the heap but not copied eg the block moves to the >> heap ...they explicitly state that copy is much more expensive than a mark >> sweep of a nursery. So they may just update the counts for objects in the >> block , if all are 0 return the block to free , if not just add the block >> to the general heap . which will realize the low % use and copy out the few >> remaining objects. >> > > That's kind of hard for me to imagine. They'd have to allocate a new set > of empty blocks on every nursery sweep, and empty blocks aren't that easy > to come by. > > > shap > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
