Why is the C# compiler emitting a callvirt instruction for a GetType() method call?

Question

I am curious to know why this is happening. Please read the code example below and the corresponding IL that was emitted in comments below each section:

using System;  class Program {     static void Main()     {         Object o = new Object();         o.GetType();          // L_0001: newobj instance void [mscorlib]System.Object::.ctor()         // L_0006: stloc.0          // L_0007: ldloc.0          // L_0008: callvirt instance class [mscorlib]System.Type [mscorlib]System.Object::GetType()          new Object().GetType();          // L_000e: newobj instance void [mscorlib]System.Object::.ctor()         // L_0013: call instance class [mscorlib]System.Type [mscorlib]System.Object::GetType()     } } 

Why did the compiler emit a callvirt for the first section but a call for the second section? Is there any reason that the compiler would ever emit a callvirt instruction for a non-virtual method? And if there are cases in which the compiler will emit a callvirt for a non-virtual method does this create problems for type-safety?

Answer 1

See this old blog post by Eric Gunnerson.

Here's the text of the post:

Why does C# always use callvirt?

This question came up on an internal C# alias, and I thought the answer would be of general interest. That's assuming that the answer is correct - it's been quite a while.

The .NET IL language provides both a call and callvirt instruction, with the callvirt being used to call virtual functions. But if you look through the code that C# generates, you will see that it generates a "callvirt" even in cases where there is no virtual function involved. Why does it do that?

I went back through the language design notes that I have, and they state quite clearly that we decided to use callvirt on 12/13/1999. Unfortunately, they don't capture our rationale for doing that, so I'm going to have to go from my memory.

We had gotten a report from somebody (likely one of the .NET groups using C# (thought it wasn't yet named C# at that time)) who had written code that called a method on a null pointer, but they didn’t get an exception because the method didn’t access any fields (ie “this” was null, but nothing in the method used it). That method then called another method which did use the this point and threw an exception, and a bit of head-scratching ensued. After they figured it out, they sent us a note about it.

We thought that being able to call a method on a null instance was a bit weird. Peter Golde did some testing to see what the perf impact was of always using callvirt, and it was small enough that we decided to make the change.

Answer 2

Just playing safe.

Technically C# compiler doesn't always use callvirt

For static methods & methods defined on value types, it uses call. The majority is provided via the callvirt IL instruction.

The difference that swung the vote between the two is the fact that call assumes the "object being used to make the call" is not null. callvirt on the other hand checks for not null and throws a NullReferenceException if required.

• For static methods, the object is a type object and cannot be null. Ditto for value types. Hence call is used for them - better performance.
• For the others, the language designers decided to go with callvirt so the JIT compiler verifies that the object being used to make the call is not null. Even for non-virtual instance methods.. they valued safety over performance.

See Also: Jeff Richter does a better job at this - in his 'Designing Types' chapter in CLR via C# 2nd Ed