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

Глава.1 .Модель.выполнения.кода.в.среде.CLR
мацию о том, какие методы проходят JIT-компиляцию во время выполнения при-
ложения. Если машина, на которой работает приложение, оснащена несколькими 
процессорами, при будущих запусках приложения JIT-компилятор параллельно 
компилирует эти методы в других программных потоках. В результате прило-
жение работает быстрее, потому что несколько методов компилируются парал-
лельно, причем это происходит во время инициализации приложения (вместо 
JIT-компиляции).
IL-код и верификация
IL является стековым языком; это означает, что все его инструкции заносят операнды 
в исполнительный стек и извлекают результаты из стека. IL не содержит инструкций 
для работы с регистрами, и это упрощает создание новых языков и компиляторов, 
генерирующих код для CLR.
Инструкции IL также являются нетипизованными. Например, в IL имеется 
инструкция для сложения двух последних операндов, занесенных в стек. У ин-
струкции сложения нет двух раздельных версий (32-разрядной и 64-разрядной). 
При выполнении инструкция сложения определяет типы операндов, хранящихся 
в стеке, и выполняет соответствующую операцию.
Однако, на мой взгляд, самое большое преимущество IL-кода состоит даже не 
в том, что он абстрагирует разработчика от конкретного процессора. IL-код обеспе-
чивает безопасность приложения и его устойчивость перед ошибками. В процессе 
компиляции IL в машинные инструкции CLR выполняется процедура, называемая 
верификацией
— анализ высокоуровневого кода IL и проверка безопасности всех 
операций. Например, верификация убеждается в том, что каждый метод вызы-
вается с правильным количеством параметров, что все передаваемые параметры 
имеют правильный тип, что возвращаемое значение каждого метода используется 
правильно, что каждый метод содержит инструкцию 
return
и т. д. Вся информация 
о методах и типах, используемая в процессе верификации, хранится в метаданных 
управляемого модуля.
В системе Windows каждый процесс обладает собственным виртуальным адрес-
ным пространством. Необходимость разделения адресных пространств объясняется 
тем, что код приложения в принципе ненадежен. Ничто не мешает приложению 
выполнить операцию чтения или записи по недопустимому адресу памяти (и к со-
жалению, это часто происходит на практике). Размещение процессов Windows в изо-
лированных адресных пространствах обеспечивает защищенность и стабильность 
системы; один процесс не может повредить другому процессу.
Однако верификация управляемого кода гарантирует, что код не будет не-
корректно обращаться к памяти и не сможет повредить выполнению кода другого 
приложения. Это означает, что вы можете запустить несколько управляемых при-
ложений в одном виртуальном адресном пространстве Windows.
Так как процессы Windows требуют значительных затрат ресурсов операцион-
ной системы, избыток их в системе снижает производительность и ограничивает 

---

45
Исполнение.кода.сборки
доступные ресурсы. Сокращение количества процессов за счет запуска нескольких 
приложений в одном процессе операционной системы улучшает производитель-
ность, снижает затраты ресурсов и обеспечивает такой же уровень защиты, как 
если бы каждое приложение располагало собственным процессом. Это еще одно 
преимущество управляемого кода по сравнению с неуправляемым.
Итак, CLR предоставляет возможность выполнения нескольких управляемых 
приложений в одном процессе операционной системы. Каждое управляемое при-
ложение выполняется в домене приложений (AppDomain). По умолчанию каждый 
управляемый EXE-файл работает в отдельном адресном пространстве, состоящем 
из одного домена. Тем не менее процесс, обеспечивающий размещение (хостинг) 
CLR — например, IIS (Internet Information Services) или Microsoft SQL Server, — 
может запустить несколько доменов приложений в одном процессе операционной 
системы. Обсуждению доменов приложений посвящена одна из частей главы 22.