JIT Optimizations, Inlining, and Interface Method Dispatching (Part 2 of N)
Not a full-blown post again, but just a couple of notes to give myself some (though not all) closure regarding the subjects brought up in the first part.
First of all, I've bothered to check with VB.NET (those of you who haven't tried it, really should... the cuteness of writing something like Public NotOverridable Overrides Sub Foo() is overwhelming). The VB.NET compiler produces the same IL we have seen in the first part, i.e. the same IL the C# compiler produces, for both interesting scenarios: dispatching a virtual method on a statically known sealed type, and emitting the callvirt opcode for calling a non-virtual instance method. Therefore, there can't be any JIT-differences.
Right after that check, I wanted to see what code the x64 JIT was generating. After all, it was written by a different team, and the code itself is a little newer, so there were quite some odds that new optimizations would be present. So let's have a look at the dispatching of virtual methods on a statically known sealed type.
The code we're talking about is the following:
The most intriguing question is: what's the JIT code generation for the B.Foo call site in the Method method? Again, bearing in mind the fact that under the debugger no optimizations will take place, we'll put a DebugBreak() call inside the method so that we get a chance to attach and see what's going on.
This is the b.Foo() method call:
00000642`8015047d 488b03 mov rax, qword ptr [rbx]
00000642`8015048b 488bcb mov rcx, rbx
00000642`8015048e ff5060 call qword ptr [rax+60h]
So again, we're calling through a method table even though the static and dynamic types are known in advance. (RBX holds the parameter value, RCX is setup to the same because it has to hold this, and then the call is through RAX+60h).
That's it for now; one day I will also analyze the interface method dispatch on the x64 JIT, but the above quite diminishes my expectations to find something really different from the x86.