how to keep assemblyloadcontext delay gc collected after call unload method

[srxqds]

how to keep assemblyloadcontext delay gc collected after call unload method?

our situation:

the collectiable assembmlyloadcontext ALC1 loading some assembly A1.dll and A2.dll

we want the ALC1 object delay been gc collected, we create strong gchandle with Assembly A1 and A2 object before call ALC1.Unload()

but it not work. the ALC1 object will be collected when gc occur.

the detail about our code flow:

AssemblyLoadContext ALC1;
Assembly A1, A2; // loadeding in ALC1

GCHandle H1 = GCHandle.Alloc(A1, GCHandleType.Normal);
GCHandle H2 = GCHandle.Alloc(A2, GCHandleType.Normal);

ALC1.Unload();

// some other code

GC.Collect();  // the ALC1 object will be gc collected.

H1.Free();
H2.Free();

// I want it keep alive after we free the assembly handle.

what excatly solution solving the situation?

[huoyaoyuan]

The description and the code comment doesn't match. When assemblies are alive, the ALC will also be kept alive. It won't be collected before freeing handles of assembly. There's nothing keeping it alive after handles of assembly are freed, and it will be collected as expected.

What are you trying to achieve here? Why do you need to keep the ALC alive without keeping the loaded stuff alive?

[AustinWise]

The UnloadSentinal will trigger the callback before the ALC object has been fully collected. Weak references get cleared at about the same time an object is put on the finalization queue. If you want to know when the managed ALC object is completely gone, you will want to use the constructor for WeakReference that takes a boolean trackResurrection parameter and pass true.

private readonly WeakReference<AssemblyLoadContext> _wr = new(alc, true);

Though the original question does not make sense to me. Why call Unload() on the ALC before the application is ready for things to be unloaded?

[srxqds]

private readonly WeakReference _wr = new(alc, true);

this don't make change

Why call Unload() on the ALC before the application is ready for things to be unloaded?

because we don't know when is clean up reference the alc, so we need delay collected it.

[srxqds]

Why call Unload() on the ALC before the application is ready for things to be unloaded?

I want to know how to avoid collected

[AustinWise]

I see two more problems with the UnloadSentinel class as written:

• the WeakReference class it is using gets finalized and cleared before the UnloadSentinel class. So UnloadSentinel is detecting the unload early. In general it is recommended to not use other managed classes in a finalizer, as the order of finalization is not guaranteed.
• Once the above is fixed, the alc primary constructor variable keeps the ALC alive.

Here is a test program and a version of UnloadSentinel that solves these two problems.

using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
using System.Runtime.Loader;

CreateUnloadSentinel();

while (true)
{
    GC.Collect();
    GC.WaitForPendingFinalizers();
    Thread.Sleep(100);
}

[MethodImpl(MethodImplOptions.NoInlining)]
static void CreateUnloadSentinel()
{
    var alc = new PluginLoadContext();
    alc.Unload();

    // comment to allow the ALC to be fully collected
    GCHandle.Alloc(alc, GCHandleType.Normal);
    new UnloadSentinal(alc, _ => Console.WriteLine("COLLECTED!"));
}

class PluginLoadContext : AssemblyLoadContext
{
    public PluginLoadContext() : base(nameof(PluginLoadContext), isCollectible: true) { }

    public IntPtr GetNativeALC() => 0;
}

internal class UnloadSentinal
{
    private readonly GCHandle _wr;
    private readonly IntPtr _nativeALC;
    private readonly Action<IntPtr> _callback;

    public UnloadSentinal(PluginLoadContext alc, Action<IntPtr> callback)
    {
        _wr = GCHandle.Alloc(alc, GCHandleType.WeakTrackResurrection);
        _nativeALC = alc.GetNativeALC();
        _callback = callback;
    }

    ~UnloadSentinal()
    {
        if (_wr.Target is null)
        {
            _callback.Invoke(_nativeALC);
        }
        else
        {
            GC.ReRegisterForFinalize(this);
        }
    }
}

[srxqds]

thank you

[AustinWise]

No problem. Two more fixes:

• Free the GC handle
• Handle the case if GCHandle.Alloc throws an exception

internal class UnloadSentinal
{
    private readonly GCHandle _wr;
    private readonly IntPtr _nativeALC;
    private readonly Action<IntPtr> _callback;

    public UnloadSentinal(PluginLoadContext alc, Action<IntPtr> callback)
    {
        _wr = GCHandle.Alloc(alc, GCHandleType.WeakTrackResurrection);
        _nativeALC = alc.GetNativeALC();
        _callback = callback;
    }

    ~UnloadSentinal()
    {
        if (!_wr.IsAllocated)
        {
            // allocating the GC handle must have failed in constructor
            return;
        }
        if (_wr.Target is null)
        {
            _wr.Free();
            _callback.Invoke(_nativeALC);
        }
        else
        {
            GC.ReRegisterForFinalize(this);
        }
    }
}

[srxqds]

I print the execute stack log:

Loader PuginBase.Setup plugin Engine_1 with stage Inited
Loader AddEngineAssemblyContext: ALC Name: Engine_1, Pointer: 00000218C75AE3D0
Loader Successfully loaded assembly `UnrealEngine` in alc `Engine_1`.
Loader Successfully loaded assembly `UnrealEditor` in alc `Engine_1`.

// new assembly gchandle 
Loader NewAssemblyGChandle UnrealEditor, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
Loader NewAssemblyGChandle UnrealEngine, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null

// unload alc
Loader PluginInitiator.UnloadALC Engine_1, nativealc: 00000218C75AE3D0

GC.Collect();

Loader PluginInitiator.OnALCDelete nativealc: 00000218C75AE3D0
``

[srxqds]

I have tried to new gchandle of ALC object, also can't keep it alive.

ALC.Unload();

GCHandle.Alloc(ALC, GCHandleType.Normal);
new UnloadSentinal(ALC, OnALCDelete);

[srxqds]

as this issuse said, the new gchandle of assembly can't keep the alc alive #40547

but I new gchandle on alc, still been collected.

[janvorli]

There may be a bit of confusion here. The AssemblyLoadContext managed object can be collected long time before the instances of types from assemblies loaded into it are collected as well as the assemblies and the memory freed. Getting rid of all references to the AssemblyLoadContext or calling Unload on it just initiates the unloading. As long as your code has a reference to anything from that context (including methods of types from that context being on stack of any thread), the collection won't proceed.

Calling the AssemblyLoadContext.Unload is equivalent to getting rid of all references to the AssemblyLoadContext object, as you can see comparing the implementation of that method and the finalizer of the AssemblyLoadContext:

runtime/src/libraries/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyLoadContext.cs

Lines 459 to 468 in 8a9d492

	public void Unload()
	{
	if (!IsCollectible)
	{
	throw new InvalidOperationException(SR.AssemblyLoadContext_Unload_CannotUnloadIfNotCollectible);
	}
	GC.SuppressFinalize(this);
	InitiateUnload();
	}

runtime/src/libraries/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyLoadContext.cs

Lines 114 to 126 in 8a9d492

	~AssemblyLoadContext()
	{
	// Use the _unloadLock as a guard to detect the corner case when the constructor of the AssemblyLoadContext was not executed
	// e.g. due to the JIT failing to JIT it.
	if (_unloadLock != null)
	{
	// Only valid for a Collectible ALC. Non-collectible ALCs have the finalizer suppressed.
	Debug.Assert(IsCollectible);
	// We get here only in case the explicit Unload was not initiated.
	Debug.Assert(_state != InternalState.Unloading);
	InitiateUnload();
	}
	}

The only added value of AssemblyLoadContext.Unload is that your code can hook the AssemblyLoadContext.Unloading event and actively remove references to anything that could reference stuff in it to allow for the unload to proceed.

So to your initial question, keeping GCHandles referencing assemblies in the AssemblyLoadContext won't prevent the AssemblyLoadContext managed object to be collected, but it prevents the unloading from really happening.
If you don't want the AssemblyLoadContext managed object to be collected, you just need to keep a reference to it.

[janvorli]

If you want to understand the internals of how it all works, you can take a look at the https://github.com/dotnet/runtime/blob/main/docs/design/features/unloadability.md document that describes its internals.