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
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.
It is set to GCProper
when all mutator stacks have been scanned in Rust MMTk, and
in the end of the STACK_ROOTS and ROOTS phases in JikesRVM. Also set to GC_PROPER in processPhaseStack
It is set to NotInGC
right before calling resume_mutators in Rust MMTk, and
in the COMPLETE phase in JikesRVM. Also set to NOT_IN_GC in processPhaseStack
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 in modifyCheck 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.)
The text was updated successfully, but these errors were encountered:
Actually it is not "unused". Its most important use is the function MMTK::set_gc_status itself. This function marks the start and end of each GC, and is used to distinguish between mutator time and GC time in statistics. Such statistics is part of the output of harness_end.
The
GcStatus
type is defined as following:It is inherited from JikesRVM. The status is set during different phases of a GC.
GCPrepare
ScheduleCollection
in Rust MMTk, andINITIATE
phase in JikesRVM.GCProper
STACK_ROOTS
andROOTS
phases in JikesRVM. Also set toGC_PROPER
inprocessPhaseStack
NotInGC
resume_mutators
in Rust MMTk, andCOMPLETE
phase in JikesRVM. Also set toNOT_IN_GC
inprocessPhaseStack
But its value is never read in the Rust MMTK. Neither
MMTK::gc_in_progress()
norMMTk::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 currentGcStatus
and the current fields ofGCReqeuster
, 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 theGcStatus
type for this.(Update: #1067 which fixes #1053 now uses its own state for that purpose, and will not affect this issue.)
The text was updated successfully, but these errors were encountered: