Is it safe to clear managed object references from unmanaged code?

[acaly]

Because of the write barrier required for the generational GC, usually we are not allowed to modify managed object references from unmanaged code. However, I think as a special case, clearing references to null from unmanaged code should be safe? Assuming the object containing the reference is on stack or pinned first.

For example:

ManagedType m = new() { B = new object() };
unsafe
{
    nint* ptr = &m.A;
    ptr[1] = 0; //Clear m.B
}

struct ManagedType
{
    public nint A;
    public object B;
}

[huoyaoyuan]

Assuming GC thread is going to do compact phase, and thus moving the reference. The moving and clearing may be in a race condition. Since pointer sizes are naturally atomic, the memory will probably not be corrupt, but it may be unreliable that GC move writes after cleaning, making the reference not really cleared.

[acaly]

Thanks! I was just thinking about marking stage and forgot about the compacting stage.

I check the code in Span<T>.Clear (actual work in SpanHelpers.ClearWithReferences), but it seems that it also clears the memory in a similar way.

[acaly]

Is it because the GC compactor actually uses something like CompareExchange so it can detect concurrent modification from the mutator? If so, I think the answer to the original question should still be yes?

[huoyaoyuan]

Well, unsafe managed code isn't same to managed code. Managed code may be paused by GC, and unmanaged code may block GC. If so, clearing reference may be safe.

[acaly]

OK. To summarize, for the STW GC, it won't run concurrently with managed unsafe code nor real unmanaged code, so that is definitely safe. For concurrent GC, I am not sure whether it will do compact. Since Span<T>.Clear is clearing managed references by zeroing IntPtrs, I assume it's safe in managed unsafe code (either due to no compact work in concurrent GC or the compactor is using atomic operations), but currently there is no evidence for whether it's safe or not in real unmanaged code.

Honestly I am more interested in managed unsafe case, so this would be enough for me. Thank you for the answer!

[acaly]

either due to no compact work in concurrent GC or the compactor is using atomic operations

Actually, seeing special handling of alignment in Span<T>.Clear, I think it should be the second reason. If that's the case, zeroing managed references as atomic operations from unmanaged code should also be safe.