-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cleanup GC worker init #514
Conversation
CommonPlan/BasePlan.trace_object
rather than the copy semantic. Simplify CopyContext.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no problem with this refactoring.
But the recurring long sequence of .as_ref().unwrap()
to get into Option<_>
shows that MMTk may have two-step initialisation anti-pattern. It is understandable because MMTk was originally developed in Java. We may consider a more major refactoring later, if we find it problematic.
@@ -206,9 +206,9 @@ impl<VM: VMBinding> GCWorkScheduler<VM> { | |||
buckets.iter().all(|&b| self.work_buckets[b].is_drained()) | |||
} | |||
|
|||
pub fn initialize_worker(self: &Arc<Self>, tls: VMWorkerThread) { | |||
pub fn initialize_coordinator_worker(self: &Arc<Self>, tls: VMWorkerThread) { | |||
let mut coordinator_worker = self.coordinator_worker.as_ref().unwrap().write().unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This as_ref().wrap()
is the same, but let's look at it later.
// Initialize the GC worker for coordinator. We are not using the run() method from | ||
// GCWorker so we manually initialize the worker here. | ||
self.scheduler | ||
.read() | ||
.unwrap() | ||
.as_ref() | ||
.unwrap() | ||
.initialize_coordinator_worker(tls); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The as_ref().unwrap()
part is for getting into the Option<_>
in RwLock<Option<Arc<GCWorkScheduler<VM>>>>
.
This long sequence may be a consequence of MMTk using two-phase initialisation. It is considered by Rust as an anti-pattern, but considering that GC is very low-level, there may be reasons why it has to be done this way. Let's investigate it later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have an issue tracking this: #57. In this particular case, I don't think it is because of GC being low-level.
This PR resolves the discussion here: #499 (comment).