This class (and its sub-classes) implement per-collector thread behavior. We assume N collector threads and M mutator threads, where N is often equal to the number of available processors, P (for P-way parallelism at GC-time), and M may simply be the number of mutator (application) threads. Both N and M are determined by the VM, not MMTk. In the case where a VM uses posix threads (pthreads) for each mutator ("1:1" threading), M will typically be equal to the number of mutator threads. When a uses "green threads" or a hybrid threading scheme (such as Jikes RVM), M will typically be equal to the level of true parallelism (ie the number of underlying kernel threads).

Collector operations are separated into per-collector thread operations (the bulk of the GC), and per-mutator thread operations (important in flushing and restoring per-mutator state such as allocator state and write buffer/remset state). SimplePhase ensures that per-collector thread GC phases are performed by each collector thread, and that the M per-mutator thread operations are multiplexed across the N active collector threads.

MMTk assumes that the VM instantiates instances of CollectorContext in thread local storage (TLS) for each thread participating in collection. Accesses to this state are therefore assumed to be low-cost at GC time.

MMTk explicitly separates thread-local (this class) and global operations (See Plan ), so that syncrhonization is localized and explicit, and thus hopefully minimized (See Plan ). Global (Plan) and per-thread (this class) state are also explicitly separated. Operations in this class (and its children) are therefore strictly local to each collector thread, and synchronized operations always happen via access to explicitly global classes such as Plan and its children.

This class (and its children) therefore typically implement per-collector thread structures such as collection work queues.