Plans with multiple traces

[qinsoon]

Each policy provides their trace_object() method and that should be used for a GC transitive closure. However, if a plan needs to do multiple traces, do we expect trace_object() be used for all the traces?

For example, in mark compact, the GC needs multiple traces. The MarkCompactSpace provides several trace_object() methods, and each trace will use a different one. However, in mark compact, the common policies (such as LOS) is still in use, and they only provide one trace_object(). For the current implementation (ad95d7797f020eaab1e608dc03b7db6a3d79839a), trace_object() in LOS may not keep tracing objects that have already been traced in previous traces, which leads to a bug and we do not have a full transitive closure.

There are a few things we need to figure out:

1. Do we expect trace_object() to be used for all the traces?
2. If not, should each policy provide a re_trace_object() method? What is the difference between trace and re_trace? Do we expect trace to happen before re_trace?
3. Who should provide the re_trace_object() for each policy? The plan or the policy itself?

[qinsoon]

Discussion on Zulip: https://mmtk.zulipchat.com/#narrow/stream/262673-mmtk-core/topic/Immix.20with.20Evacuation/near/267529252

[qinsoon]

There are a few things we need to figure out:

1. Do we expect trace_object() to be used for all the traces?

We would expect all the traces to use trace_object(). Each policy should provide a prepare() function that can help reset some states so trace_object() can be used correctly.

2. If not, should each policy provide a re_trace_object() method? What is the difference between trace and re_trace? Do we expect trace to happen before re_trace?
3. Who should provide the re_trace_object() for each policy? The plan or the policy itself?

We do not expect a re_trace_object() method for each policy.