Access checks triggered by the JIT may load generic types instantiated over the type variables of the generic method/generic type

[davidwrighton]

These could be avoided by either

1. Disabling access checks entirely for some/all assemblies. Notably we could probably avoid doing this for anything in System.Private.CoreLib
2. Changing the access checks to do access checks on the various typedef's referred to by the typespec/methodspec instead of actually loading them if the typespec/methodspec uses an MVAR/VAR in the spec.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[JulieLeeMSFT]

cc @dotnet/jit-contrib.

[EgorBo]

@davidwrighton since this is assigned to the jit team, do you have some specific repro in mind?

[JulieLeeMSFT]

@davidwrighton since this is assigned to the jit team, do you have some specific repro in mind?

Pinging @davidwrighton.

[davidwrighton]

Ah, this is a bit of an odd one. Its not really a codegen issue.

The issue is that when the JIT runs and attempts to call a generic method with constraints, the runtime needs to load the constraint type of the generic method. For instance,

static class Clazz
{
    static void Method<TMethod1_1, TMethod1_2>() where TMethod1_1 : IList<TMethod1_2>
    {
        Method2<TMethod1_1, TMethod1_2>();
    }
    static void Method2<TMethod2_1, TMethod2_2>() where TMethod2_1 : IList<TMethod2_2>
    {
    }

    static void Main()
    {
        Method<List<int>, int>()
    }
}

If this application is run and you watch the eventpipe output for type loads, you can see that the runtime finds a need to load IList<TMethod1_2> and IList<TMethod2_2>. Fundamentally, this is unnecessary, but the current logic for performing access checks likes to work with whole types, and there is an access rule around protected members which is really confusing which makes it somewhat tricky to simply clean up. This issue exists to track the work to reduce the number of type loads necessary in this scenario, as it really shouldn't be necessary to actually load the types instantiated over the generic method type parameters.