Remove policy-specific code from plans, create space-specific work packets

[steveblackburn]

Policy-specific code should not be in the Plans. The old MMTk use the plans only for dispatch to policies (eg a switch statement dispatching to various implementations of traceObject().

For both software engineering and performance reasons, work packets should be homogenous w.r.t. the type of work they do.

So for something like traceObject(), there should be a separate work packet type for every space (note that there needs to be one per space, rather than one per policy since spaces can maintain space-specific state).

Then a general call to traceObject() will place the respective object on the correct work queue according to which space the object resides in.

The dispatch can be optimized in a variety of ways, including an address-based scheme, where certain bits within the object address denote the space ID and the dispatch requires simply indexing into an array of space-specific work queues. This can be further improved by hiding the dispatch behind the syntactic sugar of a function call on the ObjectReference type.

[qinsoon]

Policy-specific code should not be in the Plans. The old MMTk use the plans only for dispatch to policies (eg a switch statement dispatching to various implementations of traceObject().

We do have 'dispatch' code in the plans, but I am not aware of policy-specific code in the plans. Can you clarify which part of the code you meant?

So for something like traceObject(), there should be a separate work packet type for every space (note that there needs to be one per space, rather than one per policy since spaces can maintain space-specific state).

Then a general call to traceObject() will place the respective object on the correct work queue according to which space the object resides in.

Currently one work packet may include many object references and they could reside in different spaces (and policies). I don't quite get how space-specific work packets work. For example, when we trace one object and it references nodes in different spaces, currently we have a buffer to store all the nodes, and create a new work packet when the buffer is full. For space-specific packets, do we have multiple buffers and store nodes by spaces to different buffers, and create space-specific work packets when any of the buffer is full?

[qinsoon]

Most of this issue is done by #542.

There are some leftover work for mark compact and immix (including gen immix). Both mark compact and immix are still using their own trace object implementation. We should do some refactoring for them with the goal of moving policy-specific code out of plan. The idea is simple: policy-specific code should not be in the Plans. We should consider letting policies provide GC work packets and use those work packets in the plan.

Space-specific work packet is an optimisation. We possibly want to track it in another issue if the rest is done for this issue and the issue can be closed.