Архив за 21 января 2015 - 9

JIT компилирует вызов прокси-метода, который делает безусловный переход на компилятор необходимого и тот заменяет адрес перехода в прокси на новое тело метода. Это делается по нескольким причинам.

Изначально, когда методы компилируются, все точки вызова других методов указывают не на скомпилированное тело, а на кусочек ассемблерного кода фиксированной длинны и содержащий одни и те же инструкции для любого метода. По сути меняется только адрес, на который происходит jmp. До того как метод скомпилирован, адрес указывает на компилятор этого метода (потому при первом вызове происходит компиляция). Далее, когда компиляция закончена, аргумент команды jmp меняется с адреса компилятора на адрес целевого, уже скомпилированного метода. Плюсы очевидны: т.к. прокси — содержит одно и те же инструкции, то группу методов можно рассматривать как таблицу с двумя полями: Код и Адрес Перехода с одной стороны и не менять адреса у инструкции вызова метода — с другой.

Приведение типа к базовому — не происходит ничего, приведение к отнаследованному — для начала проверяется возможность приведения и работа с объектом будет идти по той же таблице виртуальных методов, что и раньше

Приведение к типу — синтаксический сахар языка, который не имеет почти ничего общего на уровне строения объекта в памяти. Поскольку объект состоит из полей + SyncBlockIndex + MethodsTablePtr, где MethodsTablePtr отвечает за указатель на описание типа объекта, то при помещении указателя на объект в переменную другого типа с объектом не происходит ничего (тип объекта же не меняется). Вызывается доп проверка при приведении вверх, т.к. на этапе компиляции заранее не известно, что вверху, какие типы. Необходимо проверить. Проверка осуществляется через уход в таблицу методов и проход по цепочке указателей ParentClassMethodsTable, пока не встретится либо Object (тогда кастинг не возможен) либо пока не встретим указатель, равный тому, который мы ищем. Как осуществляется вызов виртуального метода, хорошо описано тут: Wiki

В таблице типов существует ссылка на словарь интерфейсов и для проверки возможности приведения надо обойти ее всю. По базовым типам идти не надо, т.к. все они также присутствуют в словаре. Если соответствие найдено, в регистр загрузится адрес таблицы виртуальных методов интерфейса, а не типа объекта

Поскольку интерфейсы могут появиться в типе прямо посередине наследования как в одном типе, так и в другом, для них общая схема с таблицами виртуальных методов работать не будет. Вместо этого, в таблице виртуальных методов есть ссылка на вторую таблицу — словарь интерфейсов. По сути, это список ссылок на таблицы виртуальных методов каждого из них. При приведении типа осуществляется поиск необходимой таблицы методом бинарного поиска, поскольку поиск осуществляется по равенству указателя на необходимый (среди списка ищется наличие нужного нам указателя на таблицу виртуальных методов). Если он найден, в регистр грузится указатель на эту таблицу и далее вызов метода идет через нее (при этом таблица содержит адреса методов в классе. Потому для каждой имплементации интерфейса список методов присутствует в таблицах всех классов, которые имплементируют интерфейс, а также всех наследниках классов и интерфейсов)

И те и другие выделены в словарь интерфейсов, однако Explicit методы не находятся в таблице виртуальных методов класса, только в словаре интерфейсов

И действительно, поскольку методы implicit интерфейсов являются частью иерархии наследования класса и могут быть вызваны отдельно от приведения к типу интерфейса, они должны присутствовать в таблице виртуальных методов класса. Однако, есть еще и Explicit реализации, когда методы отделены от класса. Такие методы не присутствуют в таблице виртуальных методов класса. Однако для обоих случаев мы имеем право кастить к интерфейсу и работать через него. А это значит что в карте интерфейсов обоих типов они присутствовать будут, причем вместе со всеми базовыми типами — интерфейсами.

являются платформенными потоками MS Windows, потому цена переключения между потоками равна общей цене по Windows

Тут, в общем, без комментариев. GC не может встревать в общий процесс обслуживания многопоточного кода. Приложения .Net работают как обычные приложения Windows

JIT создает никак не связанные между собой классы под каждый параметр типа

Поскольку JIT не может ничего знать о логике приложения, он не может строить доводов что

 IEnumerable<object> a = new List<int>() 

должно как-то работать. потому имплементация под каждый конкретный набор generic аргументов компилируется в отдельный код.

this — первый параметр метода, который для целей синтаксического сахара не показывается

Если представить себе вызов метода, то на уровне процессора он будет происходить по нотации fastcall: первые два параметра метода уйдут в регистры, а остальные — в стек. если ничего дополнительно не передавать, то получится что внутри метода мы понятия не будем иметь, для какого объекта нас вызвали. чтобы исправить ситуацию, мы первым параметром всегда передаем this, а в языке программирования (например, C#) его просто не показываем, введя локальную переменную this, которая присутствует всегда, вне зависимости от желания программиста. Это и есть на самом деле первый параметр метода.

Value типы лежат и в стеке и в куче, а Reference — только в куче. Отличаются тем, что value — передаются по значению, а Reference — по ссылке

Огромный процент разработчиков на собеседованиях говорят первый вариант ответа. Причем на самом деле он их не устраивает, поскольку если Value тип является полем класса, в рабочем стеке его значение находиться ну никак не может, поскольку при выходе из метода, который его создал фрейм, его содержащий перестал бы быть валидным с правильными данными. Поле класса (даже если это Value тип) всегда находится в куче. Разница между Value и Ref типами в том, что при копировании у Ref типов копируется ссылка, а у Value — полностью вся структура. Второе отличие: у незабокшенных Value типов отсутствует поле MethodsTable и SyncBlockIndex.

Лежат во внутренних массивах и обращение идет по ссылке на массив + индексу

Это просто сакральное знание. Просто сделано так и все.

JIT создает для типа таблицу виртуальных методов, через которую идет вызов с заранее подсчитанным индексом
При наследовании и наличии виртуальных методов получается так: от класса к классу они могут только прибавляться в наличии, не пропадая в никуда. причем в каждом последующем классе гарантированно будут присутствовать все методы всех базовых. С одним отличием — при наследовании метод можно переопределить. Потому при построении таблицы методов для какого-то класса, методы базового класса должны находиться по тем же индексам, что и в таблице базового класса. Если метод не переопределен, то и адрес тела метода в таблице будет совпадать с адресом этого метода в таблице базового класса. Если метод переопределен, то значение будет другим. После всех методов базовых классов будут находиться методы ткущего класса. А сам вызов будет происходить так:

• Загрузить адрес таблицы вирт методов.
• Сместиться до начала списка методов
• взять адрес метода по индексу (например) 1
• Вызвать его.

Причем поскольку при наследовании на этом месте всегда будет находиться метод ToString(), то даже переопределяя его в наследниках, будет вызван именно метод ToString(), только не базового класса, а наследника.