Wasm: call RhpAssignRef for stfld and stelem

[yowl]

This PR changes the implementation of stfld and stelem when the target type IsGCPointer and adds a test for objects rooted through a Gen 2 parent. Are there other opcodes where RhpAssignRef should be used?

Thanks @Suchiman

[jkotas]

Are there other opcodes where RhpAssignRef should be used?

Yes: stind.ref, stobj. Also, make sure to handle value types. When the valuetype contains object references, the write barrier needs to be called for each of them.

[yowl]

I think I'm going to need to add DataLayout to LLVMSharp for this so marking as draft for now.

[yowl]

I have dotnet/LLVMSharp#141 which will allow this to progress I hope.

[yowl]

I'm having some trouble creating a failing test for assigning structs which contain object references before I actually make the fix. I have

    struct StructWithObjRefs
    {
        internal Child C1;
        internal Child C2;
    }

    class ParentOfStructWithObjRefs
    {
        internal StructWithObjRefs StructWithObjRefs;
    }

    private static ParentOfStructWithObjRefs aParentOfStructWithObjRefs;
    private static WeakReference childRef;

    private static unsafe bool TesClassInStructGC()
    {
        bool result = true;

        var parentRef = CreateParentWithStruct();
        GC.Collect();
        GC.Collect(); // parent in gen2

        StoreChildInC1();
        GC.Collect();
        if (!childRef.IsAlive)
        {
            PrintLine("Child died unexpectedly");
            result = false;
        }
        KillParentWithStruct();
        GC.Collect();
        if (childRef.IsAlive)
        {
            PrintLine("Child alive unexpectedly");
            result = false;
        }
        if (parentRef.IsAlive)
        {
            PrintLine("parent of struct Child1 alive unexpectedly");
            result = false;
        }
        return result;
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    unsafe static WeakReference CreateParentWithStruct()
    {
        var parent = new ParentOfStructWithObjRefs();
        aParentOfStructWithObjRefs = parent;
        return new WeakReference(parent);
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    static unsafe void StoreChildInC1()
    {
        var child = new Child();
        aParentOfStructWithObjRefs.StructWithObjRefs = new StructWithObjRefs
        {
            C1 = child,
        };
        childRef = new WeakReference(child);
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    static void KillParentWithStruct()
    {
        aParentOfStructWithObjRefs = null;
    }

I expect the if (!childRef.IsAlive) to fail, i.e. the child stored in the struct field to have died, but it is alive for some reason. I've printed the address of the child and the parent and neither are on the stack so it seems to be rooting the Child some other way. I can add some tracing to the collection code, unless I've made a mistake in the test?

[yowl]

Added support for structs, which has a test, and stind.ref and stobj (don't have a test for those), both these go through ImportStoreIndirect. Unfortunately #8210 is not fixed with this change, so either I've missed something or it's elsewhere.

Thanks @Suchiman for the GC understanding.

[jkotas]

Nit: withBarrier -> withGCBarrier to avoid confusion with memory barrier.

[jkotas]

This has a potential for race conditions if the LLVM codegen is used for anything multithreaded. Maybe add a comment about it?

[yowl]

Right, think I understand - thread1 can RhpAssignRef a struct field (after thread2 has done the same), thread1 calls BuildStore and then thread2 can get switched back in and executes BuildStore. Thread 2's field which requires the GC write barrier is then lost. Will add a comment for now.

[jkotas]

Thanks!