Do not do any significant amount of work in Release

[wks]

In #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:

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

mmtk-core/src/scheduler/gc_work.rs

Lines 126 to 154 in 401803c

	impl<C: GCWorkContext + 'static> GCWork<C::VM> for Release<C> {
	fn do_work(&mut self, worker: &mut GCWorker<C::VM>, mmtk: &'static MMTK<C::VM>) {
	trace!("Release Global");
	mmtk.gc_trigger.policy.on_gc_release(mmtk);
	// We assume this is the only running work packet that accesses plan at the point of execution
	let plan_mut: &mut C::PlanType = unsafe { &mut *(self.plan as *const _ as *mut _) };
	plan_mut.release(worker.tls);
	for mutator in <C::VM as VMBinding>::VMActivePlan::mutators() {
	mmtk.scheduler.work_buckets[WorkBucketStage::Release]
	.add(ReleaseMutator::<C::VM>::new(mutator));
	}
	for w in &mmtk.scheduler.worker_group.workers_shared {
	let result = w.designated_work.push(Box::new(ReleaseCollector));
	debug_assert!(result.is_ok());
	}
	#[cfg(feature = "count_live_bytes_in_gc")]
	{
	let live_bytes = mmtk
	.scheduler
	.worker_group
	.get_and_clear_worker_live_bytes();
	mmtk.state.set_live_bytes_in_last_gc(live_bytes);
	}
	}
	}

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.

This is SemiSpace:

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

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]

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.