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

Hm, we still have the type loader on Linux. At least two reasons:

1. ConsolePal uses a multi-dim array on Linux and multi-dim array construction has this piece of code to handle a dumb IL-level corner case.

   runtime/src/coreclr/nativeaot/System.Private.CoreLib/src/Internal/Runtime/CompilerHelpers/ArrayHelpers.cs

   Lines 63 to 69 in d0d7154

   	if (rank == 1)
   	{
   	// Multidimensional array of rank 1 with 0 lower bounds gets actually allocated
   	// as an SzArray. SzArray is castable to MdArray rank 1.
   	Type elementType = Type.GetTypeFromHandle(new RuntimeTypeHandle(eeType.ArrayElementType))!;
   	return RuntimeImports.RhNewArray(elementType.MakeArrayType().TypeHandle.ToEETypePtr(), pDimensions[0]);
   	}

   
   MakeArrayType needs the type loader in theory. (In practice, the MethodTable for this was created by the compiler, we just need to find it in a hashtable. Still annoying though.)
2. This one is really annoying:
   
   Boils down to "we have a delegate to something that takes something with a ValueTuple over a reference type, which means we need to make the target reflectable, which means we need a type loader template for all the arguments and the template needs the equality comparer infrastructure for the cctor". This is what I was trying to "fix" in Limit impact of reflectable Invoke methods #83066 but then it went away on its own on Windows (the delegate is a SpanAction so it would conveniently go away).

In practice, the MethodTable for this was created by the compiler, we just need to find it in a hashtable.

Ah, nope. We could still be in some shared code and the MdArray handle was template-type-loaded. So we might need to template-type-load the SzArray.

We'll have to live with this.

I'll update the Linux baseline size to not expect the template type loader saving.

Ah, nope. We could still be in some shared code and the MdArray handle was template-type-loaded. So we might need to template-type-load the SzArray.

We can teach the JIT to use a different JIT helper for MD arrays that have rank 2 or more. The JIT helper for this case would not have this dependency.

This one is really annoying:

We can fix this one by calling FastAllocateString directly. We are calling FastAllocateString directly in System.Globalization in number of places, so one more is not a big deal.

We can teach the JIT to use a different JIT helper for MD arrays that have rank 2 or more. The JIT helper for this case would not have this dependency.

I was afraid you would suggest this :).

This one is really annoying:

We can fix this one by calling FastAllocateString directly. We are calling FastAllocateString directly in System.Globalization in number of places, so one more is not a big deal.

Another alternative would be delaying making the delegate targets reflectable: #82607 (comment). But FastAllocateString is even more savings.