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

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

Answer 2

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 3

As a (perhaps-)interesting aside... GetType() is unusual in that it isn't virtual - this leads to some very, very odd things.

(marked as wiki as it is somewhat off-topic to the actual question)

Answer 4

The compiler doesn't know the real type of o in the first expression, but it does know the real type in the second expression. It looks like it's only looking at one statement at a time.

This is fine, because C# depends heavily on the JIT for optimization. It's very likely in such a simple case that both calls will become instance calls at runtime.

I don't believe callvirt is ever emitted for non-virtual methods, but even if it was, it would be no problem because the method would never be overridden (for obvious reasons).

Answer 5

I would hazard a guess that it's because the first assigns to a variable, which potentially could contain a downcasted instance of another type that could've overridden GetType (even though we can see it doesn't); the second could never be anything other than Object.