Clarification on JIT force inlining top-level limit

[HurricanKai]

Wondering what the thought process behind this limit is.
If I understand correctly, this means

int Caller() => M();
[MethodImpl(MethodImplOptions.AggressiveInlining)]
int M()
{
   // some large body, that could be inlined, but JIT doesn't know it will be small, for example, because of type instantiations.
}

will be inlined, but

int Caller() => M1();
[MethodImpl(MethodImplOptions.AggressiveInlining)]
int M1() => M2();
[MethodImpl(MethodImplOptions.AggressiveInlining)]
int M2()
{
   // some large body, that could be inlined, but JIT doesn't know it will be small, for example, because of type instantiations.
}

will only inline M2 into M1 but not M2 into Caller.
If I understand correctly, this is to prevent JIT from considering too many methods for inlining, but I would've thought that this is not a concern for AggressiveInlining methods, since those can be expected to be "rare", and are expected to be inlined by the user.

[tannergooding]

CC. @AndyAyersMS

[AndyAyersMS]

The jit has protection against runaway inlining for two reasons

• to prevent the jit from causing OOM or similar problems because of runaway recursive aggressive inlines or large aggressive inline trees
• to try and forestall loss of CQ as various other jit circuit-breakers kick in for large methods.

Here are some ideas on how to make the check above a bit more forgiving in cases where the methods being inlined are large but the part that gets inlined is small; see #41692 (comment).

[HurricanKai]

OOM = OutOfMemory I guess?
Never really considered JIT as something needing large amounts of memory, but makes sense, thinking about it.
Whats CQ here? Code Quality? Not sure what the second point means honestly.

[SingleAccretion]

My guess would be that as methods grow larger, JIT optimizations are disabled (the 500 locals limit comes to mind). So, if you are too aggressive with inlining, you may end up with one large method with bad CQ instead of a few smaller ones with good CQ.