Skip to content
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

Fix GCWorker ownership. #523

Merged
merged 2 commits into from
Jan 28, 2022
Merged

Fix GCWorker ownership. #523

merged 2 commits into from
Jan 28, 2022

Conversation

wks
Copy link
Collaborator

@wks wks commented Jan 17, 2022

This PR fixes #522

We let GC worker threads own GCWorker, and isolate shared parts into GCWorkerShared. We also used AtomicRefCell for WorkerLocalStat.

This PR does not fix the potential data race between the mutator (harness_begin and harness_end) and the GC. If such a race occurs, it will panic.

I found that GC worker may access the GC scheduler (the worker_group field) before the GC scheduler is fully consructed. Rust doesn't like this (and therefore there is an Arc::get_mut_unchecked in scheduler.rs:106), and that should be fixed in another PR.

@wks wks force-pushed the fix-spawn-worker-thread branch 6 times, most recently from 6e287a9 to 22b332f Compare January 24, 2022 08:13
@wks wks requested a review from qinsoon January 25, 2022 02:58
Copy link
Member

@qinsoon qinsoon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Did you test this with harness_begin/end used?

I will approve this PR later. I will submit PRs to update V8 and JikesRVM for this PR.

src/scheduler/worker.rs Outdated Show resolved Hide resolved
src/scheduler/work.rs Outdated Show resolved Hide resolved
This commit fixes an inconsistency in the VMCollection interface where a
GCWorker is exposed to the binding via `Collection::spawn_worker_thread`
as a `&GCWorker`, but later received from the binding via
`memory_manager::start_worker` as a `&mut GCWorker`.  The root cause is
because GCWorker is wrongly owned by the scheduler.

We make each GC worker thread the owner of its `GCWorker` struct, and we
pass the `GCWorker` struct across API boundary as owning `Box`, fixing
the interface.

We isolate the part of `GCWorker` shared with the GC scheduler into a
`GCWorkerShared` struct, and ensure the fields are properly
synchronized.

Particularly, we now use `AtomicRefCell` for `WorkerLocalStat`.
`AtomicRefCell` allows it to be borrowed mutably by the GC worker and
the mutator (via `harness_begin/end` methods) at different time.
However, it is a known issue that in concurrent GC, it is possible for
GC to happen when `harness_begin/end` is called.  In that case, it will
panic.

Fixes: mmtk#522
Copy link
Member

@qinsoon qinsoon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@qinsoon qinsoon merged commit 4ebb6b6 into mmtk:master Jan 28, 2022
@wks wks mentioned this pull request Jan 29, 2022
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Inconsistent mutability of GCWorker across VM interface
2 participants