Description
The GcStatus
type is defined as following:
pub enum GcStatus {
NotInGC,
GcPrepare,
GcProper,
}
It is inherited from JikesRVM. The status is set during different phases of a GC.
- It is set to
GCPrepare
- in
ScheduleCollection
in Rust MMTk, and - in the
INITIATE
phase in JikesRVM.
- in
- It is set to
GCProper
- when all mutator stacks have been scanned in Rust MMTk, and
- in the end of the
STACK_ROOTS
andROOTS
phases in JikesRVM. Also set toGC_PROPER
inprocessPhaseStack
- It is set to
NotInGC
- right before calling
resume_mutators
in Rust MMTk, and - in the
COMPLETE
phase in JikesRVM. Also set toNOT_IN_GC
inprocessPhaseStack
- right before calling
But its value is never read in the Rust MMTK. Neither MMTK::gc_in_progress()
nor MMTk::gc_in_progress_proper()
is called anywhere in the Rust MMTk or any of its bindings.
In JikesRVM,
gcInProgress()
is only used in assertions, especially for concurrent plans.gcInProgressProper()
is only called inmodifyCheck
which no longer exists in the Rust MMTk.
It looks like the GC status mainly helps in concurrent GC algorithms, but the lxr branch of Rust MMTk does not read the gc_status
field, either.
So I think GcStatus
can be safely removed from MMTK without any harm.
Repurposing
When I was trying to remove the coordinator thread (See #1053), I realized that with the coordinator thread removed, we need a state machine to record the GC status, in a more fine-grained way than the current GcStatus
and the current fields of GCReqeuster
, and the states will affect the behavior of several things, including triggering GC, and the behavior of the last parked GC worker (to open new buckets or to wait for the GC to be triggered). I think we can re-purpose the GcStatus
type for this.
(Update: #1067 which fixes #1053 now uses its own state for that purpose, and will not affect this issue.)