C# What JIT Generates? - Struct Devirtualization

[@MGSncB]

About these methods at 8:13 and why they all got optimized... It's probably not a bug, and yes, it is related to tiered compilation. The reason is (I think) due to something called the "JIT interface". In .NET Core and .NET 5, the JIT and the runtime (CLR) communicate via the JIT interface. When the jitter consumes the IL code for the first time, it initializes fields, it may do a ton of extra stuff, and it generates code with very few optimizations, if any (because remember - the jitter has to put very limited time for compilation to good use here). If the code path is hot, the JIT compiler recompiles the code, but before that it will sort of "consult" the runtime via that interface, and it is going to tell the JIT that this Get() method's return value has already been set. "Hey, you don't need to initialize anything, the value is known (it is hot, thus we already called the method), it is ALWAYS 4 in every single scenario!" From the CLR's point of view, that "4" is a hidden static readonly field, even though it is used in an instance method. Discard everything you can, and load-return 4. Voilà.

[@KoziLord]

(I'm like two years too late but oh well) Actually I'm pretty sure that the JIT can just see from the context that 'a' is ALWAYS of type S because it's initialised in the same scope. There's no other type that it can possibly ever be in that case. If you know that a is of type S, you know which Get() you will end up calling which means no need for virtual dispatch. To me it seems like the case of "1 + a.Get()" not optimising that is just the compiler not being clever enough to see that fact in a more complex scenario.

[@driversteve9345]

What are you using or how do you set up a way to see the MSIL code immediately after changing your source code? Thanks!

[@LevelUppp]

SharpLab.io