Anyone building the below GC? Can you give us an update? - Weldon
On 8/22/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
Hi, Going on what's in the email called, "[DRLVM][GC] Goals for 2006/2007", I put together a top-level design of GC. The intention is to use this design to guide the implementation of Harmony GCV5. Briefly the goals are to build a Generational Mark-Compaction (GenMC) garbage collector, initially it will be two generations: Nursery and Mature. Your comments are welcome. 1. Design principles - The source code should have parallel allocation from the start. Also, the collector should be able to take advantage of multiprocessor HW from the start. In other words when a single threaded Java app runs out of memory on a 4-way box, all 4 CPUs should be involved in GC. - Collection policy should be separated from the issue of object age. One space has one collection policy, while multiple spaces can be of same age. - There should be a clear distinction between collection policy and allocation policy. - Where it is not too time consuming, we should develop our own core data structures such as queues and locks. The intention is to reduce memory/performance/functional dependencies on platform-specific libraries. 2. Generations - The nursery should support linear scan and flexible copying order. The size should be variable at runtime with min and max boundaries. For expedient initial implementation, the nursery can use depth-first trace-forwarding algorithm for the collection. - The mature can be arranged in blocks and collected with parallel mark-compaction algorithm. (c.f. Compressor). The blocks are in the range of 64KB in size. - Large Object Space can start with a simple treadmill collector. - Collection triggering should be abstracted from collection itself. The intention is to allow experimentation with different collection trigger heuristics without actually modifying the collector. - More than two generations should be considered in the design. 3. Write barrier - The initial implementation should be a "slot remembering" barrier. Object remembering and card marking can be implemented later for experiments or performance evaluation. Substituting write barrier may be implemented if initial performance data suggests it is worthwhile. (Substituting write barrier is a kind of barrier design that does both the write and the barrier operations. It is an optimization for performance and flexibility.) - putfield/aastore/putstatic will need a write barrier, so do some native functions. It would be a good idea to evaluate if it is better to enumerate statics as root references or use a write barrier. The VM itself will need manual write barriers at places appropriate. - The initial write barrier implementation should be an SSB. Its OK to use explicit buffer overflow checks at the beginning. 4. Parallelism - Parallel allocation: Each mutator thread should grab a Nursery chunk for thread local allocation. Also, each collector thread should grab a Mature chunk for promoting live objects into Mature space. LOS allocation does not have to be parallel. - Parallel collection: The new GC should be designed with parallel trace-forwarding for the nursery and parallel mark-compaction for mature space. - Data structures and algorithms should be thread-safe in design from the beginning. The parallelism should be controllable, e.g., the number of parallel collection threads should be controllable at the command line. - For debug purposes, it should be possible to force the GC into single threaded collection. Comments? Thanks, xiaofeng --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Weldon Washburn Intel Middleware Products Division
