Use the MarkState in ImmixSpace and LOS

[wks]

Work items:

• Let ImmixSpace, LargeObjectSpace and MarkSweepSpace use MarkState for marking
• Let MarkState use AtomicU8 internally, removing the need to use &mut self to flip the mark state
• (optional) Let MarkSweepSpace implement cyclic mark bits.

Currently the MarkState implements cyclic mark state for ImmortalSpace and VMSpace. But both ImmixSpace and LargeObjectSpace reinvent the wheel, i.e. they implement the mark states in their own fields. The native MarkSweepSpace for some reasons doesn't use cyclic mark states.

And the re-inveneted mark_state: u8 field is one field that needs to be modified in prepare or release, and it is one of the reasons why fn prepare and fn release have to have the &mut self parameter instead of &self.

We should use the MarkState struct for the mark bit and not reinvent the wheel.

To address the "uniqueness of &mut Plan" problem mentioned in #852 (comment), MarkState should internally use AtomicU8.

[k-sareen]

LOS cannot use the mark state. It has a different metadata granularity requirement. I had a branch which did exactly this. Replace the mark state in ImmixSpace and LOS. I had to revert the LOS changes because the mark state in LOS is 1-bit per 4-KB page (technically 2-bits because of the combined mark-and-nursery spec) while the mark bit spec is 1-bit per minimum object.

Here's the mark state change for ImmixSpace: k-sareen@c31c80e

[wks]

LOS cannot use the mark state. It has a different metadata granularity requirement. I had a branch which did exactly this. Replace the mark state in ImmixSpace and LOS. I had to revert the LOS changes because the mark state in LOS is 1-bit per 4-KB page (technically 2-bits because of the combined mark-and-nursery spec) while the mark bit spec is 1-bit per minimum object.

Here's the mark state change for ImmixSpace: k-sareen@c31c80e

Maybe we can decouple the MarkState with the per-object mark bit metadata. Currently MarkState::test_and_mark and MarkState::is_marked access LOCAL_MARK_BIT_SPEC. We can just move them out of MarkState to their respective metadata and have something like

impl VMLocalMarkBitSpec {
    pub fn mark(&self, object: Object, mark_state: &MarkState) {
        // access per-object mark bit
    }
}

impl VMLocalLOSMarkNurserySpec {
    pub fn mark(&self, object: Object, mark_state: &MarkState) {
        // access LOS mark bit
    }
}

So those methods will take MarkState as a parameter, but will access different metadata. MarkState will only be responsible for flipping the mark state. Plans and spaces decide whether and when to flip the state by calling MarkState::flip() at the appropriate time.

[qinsoon]

We can just move them out of MarkState to their respective metadata and have something like

We could specify which metadata to use for MarkState. In that way, MarkState still provides good abstraction.

pub struct MarkState {
    mark_bit_spec: &MetadataSpec, // something like this. Or making it as a const type parameter if Rust allows it
    state: u8,
}

For LOS, I believe our assumptions are:

1. We could decouple mark bit and nursery bit.
2. Those side metadata need to be per page.

[k-sareen]

We could be cleverer and make the LOS mark bits' granularity depend on the plan. For example, SemiSpace uses 8 KB as the min LOS object size while Immix uses 16 KB. But I think it might not be easily doable since our metadata is const usually.