Net framework 5, а также среды Visual Studio 2012 и C#

Глава.4 .Основы.типов
несущественно.) При вызове метода адрес возврата в вызывающий метод также 
заталкивается в стек (показано на рис. 4.4).
рис. 4.3.
.Размещение.локальной.переменной.метода.M1.в.стеке.потока
рис. 4.4.
.При.вызове.M2.метод.M1.заталкивает.аргументы.
и.адрес.возврата.в.стек.потока
В начале выполнения метода 
M2
его входной код выделяет в стеке потока память 
для локальных переменных 
length
и 
tally
(рис. 4.5). Затем выполняется код метода 
M2
. В конце концов, выполнение 
M2
доходит до команды возврата, которая запи-
сывает в указатель команд процессора адрес возврата из стека, и стековый кадр 
M2
возвращается в состояние, показанное на рис. 4.3. С этого момента продолжается 
выполнение кода 
M1
, который следует сразу за вызовом 
M2
, а стековый кадр метода 
находится в состоянии, необходимом для работы 
M1
.
В конечном счете, метод 
M1
возвращает управление вызывающей программе, 
устанавливая указатель команд процессора на адрес возврата (на рисунках не по-
казан, но в стеке он находится прямо над аргументом 
name
), и стековый кадр 
M1
возвращается в состояние, показанное на рис. 4.2. С этого момента продолжается 
выполнение кода вызвавшего метода, причем начинает выполняться код, непосред-
ственно следующий за вызовом 
M1
, а стековый кадр вызвавшего метода находится 
в состоянии, необходимом для его работы.

---

135
Как.разные.компоненты.взаимодействуют.во.время.выполнения
рис. 4.5.
.Выделение.в.стеке.потока.памяти.для.локальных.переменных.метода.M2
А сейчас давайте переключимся на исполняющую среду CLR. Допустим, есть 
следующие два определения классов:
internal class Employee {
public Int32 GetYearsEmployed () { ... }
public virtual String GetProgressReport () { ... }
public static Employee Lookup(String name) { ... }
} 
internal sealed class Manager : Employee { 
public override String GenProgressReport() { ... } 
} 
Процесс Windows запустился, в него загружена среда CLR, инициализирована 
управляемая куча, и создан поток (с его 1 Мбайт памяти в стеке). Поток уже выпол-
няет какой-то код, из которого вызывается метод 
M3
(рис. 4.6). Метод 
M3
содержит 
код, продемонстрирующий, как работает CLR; вряд ли вы будете включать такой 
код в свои приложения, потому что он, в сущности, не делает ничего полезного.
В процессе преобразования IL-кода метода 
М3
в машинные команды JIT-ком-
пилятор выявляет все типы, на которые есть ссылки в 
M3
, — это типы 
Employee
, 
Int32
, 
Manager
и 
String
(из-за наличия строки 
"Joe"
). На данном этапе CLR обе-
спечивает загрузку в домен приложений всех сборок, в которых определены все эти 
типы. Затем, используя метаданные сборки, CLR получает информацию о типах 
и создает структуры данных, собственно и представляющие эти типы. Структуры 
данных для объектов-типов 
Employee
и 
Manager
показаны на рис. 4.7. Поскольку 
до вызова 
M3
поток уже выполнил какой-то код, для простоты допустим, что объ-
екты-типы 
Int32
и 
String
уже созданы (что вполне возможно, так как это часто 
используемые типы), поэтому они не показаны на рисунке.
На минуту отвлечемся на обсуждение объектов-типов. Как говорилось ранее 
в этой главе, все объекты в куче содержат два дополнительных члена: указа-
тель на объект-тип и индекс блока синхронизации. В объектах типа 
Employee
и 
Manager
оба эти члена присутствуют. При определении типа можно включить 

---

136