When do we process slots more than once?

[no-defun-allowed]

I am implementing a remembered set for the Compressor, so that we can enumerate the slots from outside the Compressor space which refer into the Compressor space, in order to update the references. But I sometimes find that slots are duplicated in the remset. Updating a slot is not idempotent with the Compressor, so I have to deduplicate the remset, which is fast but probably not as fast as not deduplicating. I build the remset by detecting these slots in a modified version of PlanProcessEdges::process_slot. I haven't worked out how to track the provenance of slots which are duplicated, but at least some appear to be roots from mmtk-openjdk, as the slots are misaligned as embedded OOPs would be.

Should an implementor of ProcessEdgesWork anticipate seeing a slot more than once? Should VM bindings be permitted to give MMTk duplicated slots?

[qinsoon]

Should an implementor of ProcessEdgesWork anticipate seeing a slot more than once?

Generally not. But we usually think that is a performance issue for tracing one slot more than once, rather than a correctness issue. With extreme_assertions enabled, there are checks for duplicated slots. Some plans explicitly allow duplicate slots, like mark sweep.

See

mmtk-core/src/plan/plan_constraints.rs

Line 32 in 94b75bf

pub may_trace_duplicate_edges: bool,

[qinsoon]

We do see duplicate edges with OpenJDK: mmtk/mmtk-openjdk#106 and mmtk/mmtk-openjdk#331

[no-defun-allowed]

With this change to mmtk-openjdk I can reliably trip the assertion with e.g. OpenJDKSlot { addr: 0x7a0459d8ebe8 } should be unique to 0x7a0459d8e490 but it was in 0x7a0459d8e490 before on all combinations of lusearch/fox/jython and SemiSpace/Compressor. Indeed at least some of it is binding-side then.

[qinsoon]

mmtk/mmtk-openjdk#331 is closed with mmtk/mmtk-openjdk#336. This issue can be closed as well.