Proxy type map doesn't keep entries that can be created dynamically

[MichalStrehovsky]

Proxy2 is missed.

using System.Runtime.InteropServices;

[assembly: TypeMapAssociation<Program>(typeof(Gen<Atom1>), typeof(Proxy1))]
[assembly: TypeMapAssociation<Program>(typeof(Gen<Atom2>), typeof(Proxy2))]
[assembly: TypeMapAssemblyTarget<Program>("proxymap")]

class Program
{
    static void Main()
    {
        Console.WriteLine(TypeMapping.GetOrCreateProxyTypeMapping<Program>().GetValueOrDefault(new Gen<Atom1>().GetType()));
        Console.WriteLine(typeof(Program).GetMethod(nameof(GetProxyGeneric)).MakeGenericMethod(typeof(Atom2)).Invoke(null, []));
    }

    public static Type GetProxyGeneric<T>() where T : class
    {
        return TypeMapping.GetOrCreateProxyTypeMapping<Program>().GetValueOrDefault(new Gen<T>().GetType());
    }
}

class Gen<T>;

class Atom1;
class Atom2;

class Proxy1;
class Proxy2;

[Sergio0694]

Leaving this here for context too. This is related to microsoft/CsWinRT#2159. We're generating hundreds of these generic type instantiations in the proxy type map, but in practice we'll never need most of them (possibly none). We wouldn't want to keep all of them at all times, as it would be very bad for size. It'd be nice to have ILC trim those that it can be sure couldn't possibly be instantiated at runtime. In our case, those types:

• Will not be reflection targets
• Will never come from MakeGenericType/Method

[jkoritzinsky]

@MichalStrehovsky I think we could do something like the following, but please correct me if I'm wrong or if this doesn't work in the majority of cases:

• When the IL Scanner is not in use (or during the scanning phase): Assume all instantiations are used.
• When the IL Scanner is in use: Only preserve layouts with the seen dictionary layouts if we don't see a fallback to the runtime helper.

[Sergio0694]

Is this fix something we could backport to .NET 10 too? Asking because I suspect CsWinRT 3.0 might be broken there otherwise 🤔

[MichalStrehovsky]

@MichalStrehovsky I think we could do something like the following, but please correct me if I'm wrong or if this doesn't work in the majority of cases:

Depending on how much removal we want to be able to do, the fix could just be:

• We currently generate conditional dependency on the ConstructedType for the key, to depend on ConstructedType of the value
• We can add one more conditional dependency: when key has a canonical form, add a conditional dependency from factory.NativeLayout.TemplateTypeLayout(canonicalFormOfTheKey) to the ConstructedType of the key.

This way if there is a type loader template for Gen<__Canon> (in the above example), we will generate MethodTable for both Gen<Atom1> and Gen<Atom2>, which in turn triggers Proxy1 and Proxy2 per the existing rules.

We will keep ignoring generic types that don't have a type loader template.

[Sergio0694]

Just so I understand, can you clarify when is a "type loader template" created for a given generic type? Is that only when the type is a reflection target in some way, so you can do MakeGenericType on it? I.e. if in our scenarios we always only ever create those generic instantiations in code, will those be skipped? Is that the case even if we do so via multiple generics?

E.g. for a concrete example, we have something like this (simplified):

class DictionaryKeyCollection<TKey, TValue> : ICollection<TKey>;

class WindowsRuntimeDictionary<TKey, TValue> : IDictionary<TKey, TValue>
{
    private DictionaryKeyCollection<TKey, TValue> _keyCollection;

    public ICollection<TKey> Keys => _keyCollection ??= new(this);
}

// Some specialized generated type
class Dictionary_string_object : WindowsRuntimeDictionary<string, object>;

We then add proxy types for e.g. DictionaryKeyCollection<string, object>. The generated Dictionary_string_object type itself is only instantiated through some other code path from a value of yet another proxy in the proxy type map.

My question is: if Dictionary_string_object is trimmed, will the proxy entry for DictionaryKeyCollection<string, object> also be trimmed?

[MichalStrehovsky]

Just so I understand, can you clarify when is a "type loader template" created for a given generic type?

When the compiler needs it to build the types dynamically at runtime.

For example:

class IFoo
{
    void Do<T>();
}

class Foo
{
      public void Do<T>() => OtherGenericType<T>.Blah();
}

class OtherGenericType<T>
{
    public static void Blah<T>() => new Gen<T>();
}

IFoo f = new Foo();
f.Do<object>();

The generic virtual method dispatch to Do<object> triggers "type loader template" for Do<__Canon>, which in turn triggers template for OtherGenericType<__Canon>, which in turn triggers template for Gen<__Canon>.

Similar situation would happen if we e.g. found out that OtherGenericType<>.Blah is a target of reflection.

[Sergio0694]

I see. Does this mean that in our scenario we'd end up having to always root all of those types? 🥲

[MichalStrehovsky]

I see. Does this mean that in our scenario we'd end up having to always root all of those types? 🥲

I don't know. From what I saw above, I don't see why we would root them. You really need to either have a

1. Generic virtual method, that ends up using its T (even transitively) to construct a brand new DictionaryKeyCollection<,> that uses the T somehow (this is the runtime type loading scenario that we need to be conservative about at compile time), or
2. A generic method or method on a generic type that is target of reflection, that uses the T (even transitively) to construct a new DictionaryKeyCollection<,> using the T.

We only generate type loader templates for types that we need to load new instantiations of at runtime. The above two scenarios are the only scenarios that trigger it and even then when only make the template if this generic type is somewhere in the transitive closure of it all. We only do this for types that we transitively need to load.

If you stay away from generic virtual methods and various loose reflection (things like DynamicallyAccessedMemberTypes.All, or TrimmerRootAssembly), this should not be a problem at all. If you don't stay away from those, it might still be fine if this specific type is not reached from there and we don't need to create random new generic instances at runtime.

[Sergio0694]

Oh I see, that sounds much better than I thought! Just so I understand, can you clarify how can ILC understand all combinations of constructed generics that can be instantiated even in case of shared generics? Is it recursively constructing all generic types/members starting from entries in the TypeSpec/MethodSpec tables to try to figure out all the ones that can statically be constructed, or something else? Just wondering how it can know even for those combinations that don't directly appear in metadata.

[MichalStrehovsky]

Just so I understand, can you clarify how can ILC understand all combinations of constructed generics that can be instantiated even in case of shared generics? Is it recursively constructing all generic types/members starting from entries in the TypeSpec/MethodSpec tables to try to figure out all the ones that can statically be constructed, or something else?

Recursively track what is needed using the normal dependency algorithm. So if the code has new List<string>, we know we need code for List<__Canon>..ctor and a MethodTable (that has a generic dictionary in it) for List<string>. Things expand from there as needed.

The one exception is the MakeGeneric/GVM case we are talking about here. In that case we track something like List<__Canon>..ctor and "data structures to be able to build new List<T> at runtime for any T that canonicalizes to List<__Canon>" (so List<string>/List<object>/List<Whatever>)