Collectible Assemblies and the CLR

[JoshVarty]

Hi there,

I would like to start the conversation about collectible assemblies and the CLR. For reference the user voice for this issue is available here. My understanding is that this is currently possible with Mono, but not the CLR.

With the new Roslyn compiler and projects like ScriptCS, I think we're going to see an increase in the number of users who are dynamically compiling and running code. Today there is no way to unload an assembly (without burning down the entire AppDomain 😄).

I'd love to get a feel for what limitations exist that would prevent this feature, how much work it might take and whether or not the team felt it was feasible (or necessary).

[jkotas]

Thank you for starting the conversation.

We have been mulling over this feature request for a while.System.Runtime.Loader.AssemblyLoadContext - .NET Core replacement for AppDomain.AssemblyResolve event - was designed with collectability in mind. Our tentative plan has been to expose it by adding a new constructor to this type that takes an extra flag to mark the context as collectible. That is the easy part.

The hard part is the runtime implementation of the collectability. It should build upon the existing Reflection.Emit collectability infrastructure (look for FEATURE_COLLECTIBLE_TYPES). The implementation needs to include targeted tests for corner cases as well as stress testing the unloading (e.g. run all existing corefx tests as unloadable in a loop for a long time, etc.)

In case somebody would like to start the implementation before the core team gets to it, it should be done in series of smaller commits under FEATURE_XXX define (e.g. FEATURE_COLLECTIBLE) that will be turned off by default until the implementation is completed. The first baby steps may be to add the extra argument to the AssemblyLoadContext constructor under this define.

[davidfowl]

+1! 😄 Would love this for razor compilation and other things

[jakesays-old]

I'd love to work on this!

[MattWhilden]

Start with the "easy" constructor changes and feel free to ask questions about the rest. :-)

[Rohansi]

System.Runtime.Loader.AssemblyLoadContext - .NET Core replacement for AppDomain.AssemblyResolve event - was designed with collectability in mind. Our tentative plan has been to expose it by adding a new constructor to this type that takes an extra flag to mark the context as collectible.

Would this behave like AppDomains where all loaded assemblies are collected with the context or does the context just mark assemblies loaded through it as collectible? After looking through the code it looks like it would be per assembly since the CLR already supports that.

So AssemblyLoadContext would need a new constructor that lets you specify whether it loads assemblies as collectible. It looks like that flag would need to make it down to Assembly::Create which has a parameter to mark assemblies as collectible.

A LoaderAllocater is required for collectible assemblies as well. Assembly::CreateDynamic uses AssemblyLoaderAllocator which is probably what should be used, assuming per assembly collection I guess.

Is this correct? I'm not really sure how I would get that information from AssemblyLoadContext all the way to Assembly::Create, or if I even need to.

[jkotas]

Would this behave like AppDomains where all loaded assemblies are collected with the context

All assemblies loaded into given collectible AssemblyLoadContext should be unloaded as a unit.

AssemblyLoadContext all the way to Assembly::Create

The owning AssemblyLoadContext can be retrieved in Assembly::Create from PEAssembly argument using GetBindingContext().

[Rohansi]

pFile->GetBindingContext() is giving me an instance of BINDER_SPACE::Assembly* downcasted to ICLRPrivBinder*. I can see the field I think I need in there but BINDER_SPACE::Assembly::GetBinder() is protected. Would I need to add a friend class or should I be looking at something else?

Also how would I safely cast the ICLRPrivBinder* to CLRPrivBinderAssemblyLoadContext*? I think I would need to make an interface so it can be done with QueryInterface but I'm new to COM so I'm probably missing something.

[jkotas]

Yes, creating interface would be a clean way to do this.

[Rohansi]

So I made an interface and changed CLRPrivBinderAssemblyLoadContext to inherit IUnknownCommon<ICLRPrivBinder, IAssemblyLoadContext> but now a static_cast is failing to compile, presumably because both interfaces inherit from IUnknown:

"bin\obj\Windows_NT.x64.Debug\src\vm\wks\cee_wks.vcxproj" (default target) (14:3) ->
    src\vm\coreassemblyspec.cpp(348): error C2594: 'static_cast': ambiguous conversions from 'IUnknown *' to 'CLRPrivBinderAssemblyLoadContext *'

Here's what I have for my interface right now:

class DECLSPEC_UUID("68220E65-3D3F-42E2-BAD6-2D07419DAB5E") IAssemblyLoadContext : public IUnknown
{
public:
    STDMETHOD(GetIsCollectible)(
            /* [retval][out] */ BOOL *pIsCollectible) = 0;
};

Also is there any reason why BINDER_SPACE::Assembly::GetBinder() is protected? I'm having trouble adding a friend class for ::Assembly.

[jkotas]

static_cast is failing to compile

How many places have this problem? You should be able to fix them by casting to the specific interface.

Any reason why BINDER_SPACE::Assembly::GetBinder() is protected?

I do not see a particularly strong reason. It should be ok to change it to public.

[Rohansi]

How many places have this problem? You should be able to fix them by casting to the specific interface.

It's just one place but there is no interface for that method, even though it looks like there should be one. I changed it to a reinterpret_cast to get it to build but I doubt that would work properly at runtime.

[Rohansi]

OK so I have it using the IsCollectible flag and LoaderAllocator I added to CLRPrivBinderAssemblyLoadContext in Assembly::Create() and it now crashes in LoaderAllocator::Destroy() because I didn't create a DomainAssembly. I'm not sure what it should be initialized with.

I'm basing this off of what Assembly::CreateDynamic() does and it creates a DomainAssembly for the PEAssembly it creates. I'm not sure if I should be doing the same. And how do I keep them together so they unload as a unit, do I just have to use the same LoaderAllocator for them?

[runxc1]

Is this going to make RC2?

[terrajobst]

No, which is why we moved it into the Future milestone.

[runxc1]

So if it's in the Future milestone is it effectively dead? A 'Future' sprint is usually where most tasks go to die and be forgotten