Refactor ProcessEdgesBase::worker
to make it safe
#1040
Labels
A-work-queue
Area: Work queue
C-refactoring
Category: Refactoring
F-project
Call For Participation: Student projects. These issues are available student projects.
G-safety
Goal: Safety
P-normal
Priority: Normal.
The
ProcessEdgesBase::worker
field is a raw pointer*mut GCWorker<VM>
. It is initialised as null when instantiatingProcessEdgesBase
, but later set to the pointer to the worker indo_work()
. It is used inProcessEdgesWork::trace_object
: It will dispatch to thetrace_object
method of different spaces. But sincetrace_object
can copy object, it needs itscopy_context
to do the copying. For this reason, we need to pass the worker (or the underlyingCopyContext
to thetrace_object
method of concrete spaces.ProcessEdgesWork::start_or_dispatch_scan_work
: If it decides to execute theScanObjects
work packet immediately after tracing all slots (Edge), it will callScanObjects::do_work
, and one parameter is the GC worker.Obviously, raw pointers are unsafe.
The root problem is that the
ProcessEdgesWork
work packet is instantiated when enqueuing the slots, but the reference to theGCWorker
is only available when executing theProcessEdgesWork
work packet.There are two obvious solutions:
&mut GCWorker
fromdo_work()
all the way throughprocess_edges()
,process_edge()
andtrace_object()
. But also be ware thatProcessEdgesWork::trace_object
is sometimes called directly, bypassingprocess_edges
. For example,Edge
) to process as well as a reference toGCWorker
, and move theprocess_edges
,process_edge
andtrace_object
methods to that struct. Because the struct is constructed when a&mut GCWorker
is available, theworker
field (as shown below) is safe, but has a lifetime annotation. For example,Related issues and PRs
There is a stale PR for solving the problem by adding the parameter
worker: &mut GCWorker
to several functions. #597The text was updated successfully, but these errors were encountered: