class Base
{
//...
}

class Derived: Base
{
//...
}

Почему эти две команды Console.WriteLine выводят разные значения?

Base base1 = new Derived();
Console.WriteLine(base1.GetType());
Base base2 = new Base();
Console.WriteLine(base2.GetType());

Base b = new Derived();
b.SomeMethod(); // SomeMethod is not virtual

Base b = new Derived();
b.SomeVirtualMethod();

IBase ib = new Derived();
ib.SomeInterfaceMethod();

Base b = new Derived();
MC>>b.SomeMethod(); // SomeMethod is not virtual

JR>По поводу выделенной фразы — это точно? Признаться, есть некоторые сомнения. Просто не вижу необходимости возлагать это на JIT, так как вся необходимая информация доступна уже на этапе компиляции в IL, по-моему

void M3() {
  Employee e = new Manager();
  year = e.GetYearsEmployed();
  ...
}

The next line of code in M3 calls Employee’s nonvirtual instance GetYearsEmployed method. When calling a nonvirtual instance method, the JIT compiler locates the type object that corresponds
to the type of the variable being used to make the call. In this case, the variable e is defined as an Employee. (If the Employee type didn’t define the method being called, the JIT compiler walks down the class hierarchy toward Object looking for this method. It can do this because each type object has a field in it that refers to its base type; this information is not shown in the figures.) Then, the JIT compiler locates the entry in the type object’s method table that refers to the method being called, JITs the method (if necessary), and then calls the JITted code.

void M3() {
MC>  Employee e = new Manager();
MC>  year = e.GetYearsEmployed();
MC>  ...
MC>}

    static int y;

    public void Test()
    {
        DerivedObj obj = new DerivedObj()
        var y1 = obj.Mul(2, 4);
        var y2 = obj.Sum(5, 10);
        y = y1 + y2;
    }
}

public class BaseObj
{
    public int Sum(int x1, int x2)
    {
        return x1 + x2;
    }
}

public class DerivedObj : BaseObj
{
    public int Mul(int x1, int x2)
    {
        return x1 * x2;
    }
}

.method public hidebysig instance void  Test() cil managed
{
  // Code size       34 (0x22)
  .maxstack  3
  .locals init ([0] class CarpetCleaner.DerivedObj obj,
           [1] int32 y1,
           [2] int32 y2)
  IL_0000:  newobj     instance void CarpetCleaner.DerivedObj::.ctor()
  IL_0005:  stloc.0
  IL_0006:  ldloc.0
  IL_0007:  ldc.i4.2
  IL_0008:  ldc.i4.4
  IL_0009:  callvirt   instance int32 CarpetCleaner.DerivedObj::Mul(int32,
                                                                    int32)
  IL_000e:  stloc.1
  IL_000f:  ldloc.0
  IL_0010:  ldc.i4.5
  IL_0011:  ldc.i4.s   10
  IL_0013:  callvirt   instance int32 CarpetCleaner.BaseObj::Sum(int32,
                                                                 int32)
  IL_0018:  stloc.2
  IL_0019:  ldloc.1
  IL_001a:  ldloc.2
  IL_001b:  add
  IL_001c:  stsfld     int32 CarpetCleaner.Form1::y
  IL_0021:  ret
} // end of method Form1::Test

(If the Employee type didn’t define the method being called, the JIT compiler walks down the class hierarchy toward Object looking for this method. It can do this because each type object has a field in it that refers to its base type; this information is not shown in the figures.) Then, the JIT compiler locates the entry in the type object’s method table that refers to the method being called, JITs the method (if necessary), and then calls the JITted code.

void Test(Derived obj)
{
    obj.Test();
}

callvirt   instance void ConsoleApplication5.Base::Test()

using System;

namespace JitTest
{
    class Program
    {
        static void Main(string[] args)
        {
            Employee e;
            e = new Manager();
            int years = e.GetYearsEmployed();
            Console.ReadKey();
        }

        public class EmployeeBase
        {
            public int GetYearsEmployed()
            {
                Console.WriteLine("Method in EmployeeBase called.");
                return 1;
            }
        }

        public class Employee : EmployeeBase
        {
            public void SomeOtherMethod() { }
        }

        public class Manager : Employee
        {
            public void GenProgressReport() { }
        }
    }
}

    L_0000: nop 
    L_0001: newobj instance void JitTest.Program/Manager::.ctor()
    L_0006: stloc.0 
    L_0007: ldloc.0 
    L_0008: callvirt instance int32 JitTest.Program/EmployeeBase::GetYearsEmployed()

callvirt instance int32 JitTest.Program/EmployeeBase::GetYearsEmployed()

callvirt instance int32 JitTest.Program/Employee::GetYearsEmployed()

    L_0000: nop 
    L_0001: newobj instance void JitTest.Program/Manager::.ctor()
    L_0006: stloc.0 
    L_0007: ldloc.0 
    L_0008: callvirt instance int32 JitTest.Program/Employee::GetYearsEmployed()

MissingMethodException is thrown if a non-static method with the indicated name and signature could not be found in the class associated with obj or any of its base classes. This is typically detected when Microsoft Intermediate Language (MSIL) instructions are converted to native code, rather than at runtime.

That is, the method is chosen based on the runtime type of obj rather than the compile-time class visible in the method pointer.

callvirt method

Calls a specific method associated with obj.

The stack transitional behavior, in sequential order, is:
1. An object reference obj is pushed onto the stack.
2. Method arguments arg1 through argN are pushed onto the stack.
3. Method arguments arg1 through argN and the object reference obj are popped from the stack; the method call is performed with these arguments and control is transferred to the method in obj referred to by the method metadata token. When complete, a return value is generated by the callee method and sent to the caller.
4. The return value is pushed onto the stack.

JR>С другой стороны, тут есть ещё один момент, который я прошлой ночью упустил — рефлексия. (Ну очень спать хотелось ) Для неё необходимо, чтобы информация о всех членах класса, в том числе невиртуальных методах, была доступна в рантайм. В принципе, JIT может ей воспользоваться при необходимости. Но с другой стороны, ей-же может воспользоваться и C# компилятор, то есть такие вопросы можно вроде как разрешить на этапе компиляции в IL. Иначе у меня не получается непротиворечиво объяснить тот листинг, что я приводил здесь

Автор: Jolly Roger
Дата: 05.02.11

. Ведь в методе Test нет никаких упоминаний BaseObj, однако в IL-листинге он присутствует. Это, по-моему, может означать только одно — C#-компилятор произвёл поиск метода вверх по иерархии и подставил в результирующий IL код его адрес, этот адрес мы и видим в виде метки BaseObj::Sum. Иначе у меня как-то не срастается

Компилируем с помощью ILAsm.

Проверяем в ILDasm или Reflector'е:

    L_0000: nop 
    L_0001: newobj instance void JitTest.Program/Manager::.ctor()
    L_0006: stloc.0 
    L_0007: ldloc.0 
    L_0008: callvirt instance int32 JitTest.Program/Employee::GetYearsEmployed()

That is, the method is chosen based on the runtime type of obj rather than the compile-time class visible in the method pointer.