search

mmtk / mmtk-core

Memory Management ToolKit
https://www.mmtk.io
Other
379 stars 69 forks source link

Do not do any significant amount of work in `Release` #1147

Open wks opened 5 months ago

wks commented 5 months ago

In https://github.com/mmtk/mmtk-core/issues/1146, we observed that when using the native MarkSweep and the eager sweeping is enabled, no ReleaseMutator work packet is executed until Release finishes. It can be seen from the eBPF timeline:

image

That is because the Release work packet calls Plan::release before spawning any ReleaseMutator work packet. See:

https://github.com/mmtk/mmtk-core/blob/401803ce44d851c19e4d04f152b494095f9b71e6/src/scheduler/gc_work.rs#L126-L154

This is not a bug, because Release is designed to have exclusive access to the Plan when executed. This means we shouldn't do any high-intensity work in Plan::release unless we don't need to release mutators.

This affects all plans.

MarkSweep does a non-trivial amount of work in Plan::release when doing eager sweeping.

Here is a zoomed-in timeline for Immix. ImmixSpace.release generates SweepChunk work packets, so they start executing before ReleaseMutator work packets start.

image

This is SemiSpace:

image

It looks OK. But after I turn on the VO bits:

image

Clearly the Release work packet is spending a significant amount of time clearing the VO bit.

We should revisit all plans and all spaces, and see if they do any significant amount of work in Plan.release and Space.release. If they do, they should be off-loaded to dedicated work packets so that they can be parallelized.

wks commented 5 months ago

It raises another question: If Release is supposed to have exclusive access to the Plan, and if it can spawn work packets (such as SweepChunk) that can start executing immediately, then it may not have exclusive access to the plan. because work packets such as SweepChunk may access the space which, according to Rust's concept of ownership, is part of the plan.