Jan Kotas

/azp run runtime-coreclr outerloop

/azp run runtime-coreclr outerloop

/azp run runtime-coreclr outerloop

EntityFrameworkCore has infinite generic expansion here in ExecuteImplementation and ExecuteImplementationAsync methods. These two methods call themselves with different generic arguments. It makes them unfriendly to AOT compilation, and incompatible with...

.NET Native for UWP used universal shared generics to handle these cases. The code worked, but run number of times slower. Universal shared generics are not really full AOT compilation.

Note that the infinite generic expansion does not work too well with CoreCLR partial AOT either: crossgen will try to compile several expansions (that is usually a lot more than...

I diagnose these by looking at the stacktrace of the stackoverflow, and then correlate it with sources. I agree that it would be nice to have better diagnostics for this...

Marking this as up-for-grabs. This should be fixed by submitting PR to EFCore that removes the recursive call in ExecuteImplementation/ExecuteImplementationAsync.

@ajcvickers We have an ongoing discussion on this topic and the answer is more nuanced than this.

> dynamically generate the memory at runtime How is it different from just having JIT?