You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow querying if the current GC may move objects. (#1128)
The major changes include:
- Adding a method `Plan::current_gc_may_move_object`.
- Immix-based plans now reset the in-defrag state at the end of GC.
The main change of this PR is allowing querying if the current GC may
move any object.
Whether a plan moves objects or not is not a simple "yes or no"
question. It may vary in each GC.
- Some plans, such as MarkSweep, never moves any object.
- Some plans, such as SemiSpace and MarkCompact, moves objects in every
GC.
- Some plans, such as Immix, moves object in defrag GC, while "fast" GCs
are non-moving.
- Some plans, such as Immix and StickyImmix, depends on Cargo features.
"immix_non_moving" prevents all movement, and
"sticky_immix_non_moving_nursery" prevents movement in nursery GCs.
The information of whether the current GC is useful inside mmtk-core.
For example, we can skip clearing on-the-side forwarding bits in
non-moving GCs because no objects will be forwarded. Because this should
happen during the Release stage, we postponed the time for Immix-based
plans to reset the in-defrag state to the end of GC so that
`Plan::current_gc_may_move_object` remains callable during the Release
stage. *(Note that this PR does not fix#1118, but this mechanism
introduced in this PR can be used to implement the clearing of side
forwarding bits efficiently.)*
The information is also useful for VM bindings. Therefore,
`Plan::current_gc_may_move_object` is part of the public API.
- For VMs that have "potential pinning parents" (PPP, i.e. non-root
objects that have fields that cannot be updated), the VM binding must
pin the children of those fields before starting tracing. If the VM
binding knows the current GC never moves any object, it can skip pinning
the children of PPPs.
- For VMs that maintain weak tables (tables that contain weak references
to heap objects) in the runtime, the VM binding needs to scan the weak
tables, updating entries for objects that are moved, and deleting
entries for unreachable objects. (Note the cost of updating entries may
be high if the table is hashed by address.) If the VM binding knows the
current GC never moves any object, it will not need to update the
entries for moved live objects. And if the current GC is also a nursery
GC, the VM binding will only need to scan entries added before the last
GC.
This new method complements existing mechanisms for checking if objects
can be moved. They are useful for different purposes and cannot replace
each other.
- The scope of the new `Plan::current_gc_may_move_object` is one GC. It
is useful for the VM to decide whether to pin PPPs objects before a GC
and how to process weak references or weak tables.
- `PlanConstraints::moves_objects` is a per-plan constant. It is useful
for the VM to determine the object layout w.r.t. address-based hashing.
- The scope of `ObjectReference::is_movable` is a single object. It is
useful for the VM to skip pinning certain objects when interacting with
native code.
- The scope of `PlanTraceObject::may_move_object` is a trace. It is an
internal mechanism for MMTk core to specialize work packets for
different kinds of traces.
0 commit comments