public abstractclassMutatorContext
implements
Constants
Overview
Inheritance
Members
Usage
Source
Books
SinceNot specified.
VersionNot specified.
Author(s)Not specified.
This class (and its sub-classes) implement per-mutator 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).
MMTk assumes that the VM instantiates instances of MutatorContext
in thread local storage (TLS) for each thread participating in
collection. Accesses to this state are therefore assumed to be
low-cost during mutator time.
This class (and its children) is therefore used for unsynchronized
per-mutator operations such as allocation and write barriers.
The semantics and necessary state for these operations are therefore
specified in the GC-specific subclasses of this class.
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). Gloabl (Plan)
and per-thread (this class) state are also explicitly separated.
Operations in this class (and its children) are therefore strictly
local to each mutator thread, and synchronized operations always
happen via access to explicitly global classes such as Plan and its
children. Therefore only "fast path" (unsynchronized)
allocation and barrier semantics are defined in MutatorContext and
its subclasses. These call out to "slow path" (synchronize(d)
methods which have global state and are globally synchronized. For
example, an allocation fast path may bump a pointer without any
syncrhonization (the "fast path") until a limit is reached, at which
point the "slow path" is called, and more memory is aquired from a
global resource.
As the super-class of all per-mutator contexts, this class implements
basic per-mutator behavior common to all MMTk collectors, including
support for immortal and large object space allocation, as well as
empty stubs for write barriers (to be overridden by sub-classes as
needed).
MMTk assumes that the VM instantiates instances of MutatorContext in thread local storage (TLS) for each thread participating in collection. Accesses to this state are therefore assumed to be low-cost during mutator time.
This class (and its children) is therefore used for unsynchronized per-mutator operations such as allocation and write barriers. The semantics and necessary state for these operations are therefore specified in the GC-specific subclasses of this class. 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). Gloabl (Plan) and per-thread (this class) state are also explicitly separated. Operations in this class (and its children) are therefore strictly local to each mutator thread, and synchronized operations always happen via access to explicitly global classes such as Plan and its children. Therefore only "fast path" (unsynchronized) allocation and barrier semantics are defined in MutatorContext and its subclasses. These call out to "slow path" (synchronize(d) methods which have global state and are globally synchronized. For example, an allocation fast path may bump a pointer without any syncrhonization (the "fast path") until a limit is reached, at which point the "slow path" is called, and more memory is aquired from a global resource.
As the super-class of all per-mutator contexts, this class implements basic per-mutator behavior common to all MMTk collectors, including support for immortal and large object space allocation, as well as empty stubs for write barriers (to be overridden by sub-classes as needed).