Age of JIT compiling. Part II. CLR is watching you15.03.2015 19:02

Продолжая тему JIT-компиляции .NET’a, сегодня мы рассмотрим диспетчеризацию методов у интерфейсов, generics (как классов, так и отдельных методов вместе с реальными сигнатурами); производить отладку релизных сборок с оптимизациями; разберемся с истинным предназначением типа System.__Canon (это не то, что Вы подумали).Настройка средыПрежде чем двигаться дальше, нам необходимо подготовить Visual Studio для отладки релизных сборок.Использовать будем VS 2013, поэтому для использования SOS.dll придется включить compatibility mode:

Tools → Options → Debugging → General Далее снимем галочки здесь же с: Suppress JIT optimization on module load Enable Just My Code Также необходимо включить поддержку Native Debugging: Project Settings → Debug → Enable native code debuggingТеперь приступим к нашим исследованиям.Interface dispatch stubs (Virtual Stub Dispatch) CLR постоянно проводит мониторинг всех участков кода. Имеет несколько стратегий по обновлению нативного кода методов. Именно так — не только HotSpot в Java имеет такой функционал, или же современные JS-движки.Такой функционал появился в CLR 2.0 еще в 2006 году. И…остался во многом в таком же виде + новые эвристики.

Особенно «бдительно» среда следит за интерфейсами.Надеюсь, Вы уже настроили студию для дебага релизного кода.

Рассмотрим пример: class Program { static void Main (string[] args) { ICallable target = new FirstCallableImpl (); CallInterface (target);

ICallable target2 = new SecondCallableImpl (); CallInterface (target2); }

[MethodImpl (MethodImplOptions.NoInlining)] private static void CallInterface (ICallable callable) { for (int i = 0; i < 1000000; i++) { callable.DoSomething(); // place breakpoint } } }

interface ICallable { void DoSomething (); }

class FirstCallableImpl: ICallable { public void DoSomething () {

} }

class SecondCallableImpl: ICallable { public void DoSomething () {

} } Запустим отладку. Далее откроем окно Disassembly (Debug → Windows → Disassembly).Рассмотрим инструкцию call dword ptr ds:[00450010h].Чтобы узнать значение по адресу 0×00450010 откроем окно памяти (Debug → Windows→ Memory→ Memory1).

На данном этапе JIT еще не создал необходимый узел вызова, пока что среда сама производит «интерпретацию» вызова метода интерфейса (это значит, происходит линейный поиск требуемого метода в рантайме).

Однако позволим еще 2 раза выполниться этому коду и увидим, что значение адреса 0×0450010 изменилось:

Для инспекции значения 00457012 загрузим SOS.dll: Immediate window → .load sos

! u 00457012 Unmanaged code 00457012 813908314400 cmp dword ptr [ecx],443108h 00457018 0F85F32F0000 jne 0045A011 0045701E E9BD901D00 jmp 006300E0 Инструкция jmp 006300E0 представляет собой вызов требуемого метода интерфейса. Проверим: ! u 006300E0 Normal JIT generated code ConsoleApplication1.FirstCallableImpl.DoSomething () Begin 006300e0, size 1 >>> 006300E0 C3 ret Так… С методом понятно, но что же за сравнение происходит в инструкции cmp dword ptr [ecx],443108h? ! DumpMT 443108 EEClass: 00441378 Module: 00442c5c Name: ConsoleApplication1.FirstCallableImpl mdToken: 02000004 (C:\*path to project*\InterfaceStubsTest.exe) BaseSize: 0xc ComponentSize: 0×0 Number of IFaces in IFaceMap: 1 Slots in VTable: 6 Ага! Сравниваем this на соответствие типу FirstCallableImpl (т.е. MethodTable) и при значении true вызываем метод FirstCallableImpl.DoSomething ().Инструкция jne 0045A011 представляет собой fallback на линейный поиск, как и было до кэширования.Когда дело дойдет до вызова следующего типа — SecondCallableImpl, то все так же будет проверяться в узле вызова именно FirstCallableImpl, а не SecondCallableImpl.

Но это же неэффективно! Именно поэтому, по достижению определенного количества итераций вызова кода, среда просто заменит данный узел вызова с кэшем на (как Вы уже догадались) линейный поиск.

Кэширование весьма эффективно, если мы вызываем методы у коллекций, например.

Generic types stubs Выход CLR 2.0 вместе с generics ознаменовал существенные изменения в среде исполнения. Если до этого для описания конкретного типа «хватало» лишь структуры EEClass, то теперь связка структура EEClass+MethodTable представляет собой текущий тип.Более того, для List<string> и List<int> разными будут даже EEClass (про code-sharing будет чуть ниже).

Рассмотрим пример: class Program { static void Main (string[] args) { var refTypeHolder = new HolderOf