При работе с .NET часто встречается термин «управляемый код». В этой статье объясняется, что означает управляемый код , и приводятся дополнительные сведения о нем.
Проще говоря, управляемый код — это код, выполнение которого управляется средой выполнения. В этом случае соответствующая среда выполнения называется общеязыковой средой выполнения или средой CLR, независимо от реализации (например, Mono, .NET Framework или .NET Core/.NET 5 и более поздних версий). Среда CLR отвечает за получение управляемого кода, его компиляцию в машинный код, а затем его выполнение. Кроме того, среда выполнения предоставляет несколько важных служб, таких как автоматическое управление памятью, границы безопасности и безопасность типов.
Сравните это с запуском программы C/C++, которая также называется «неуправляемым кодом». В мире неуправляемого кода практически за все отвечает программист. Сама программа представляет собой двоичный файл, который операционная система (ОС) загружает в память и запускает. За все остальное — от управления памятью до различных аспектов безопасности — отвечает программист.
What is CLR | What is Common Language Runtime | .NET CLR | .NET interview question
Управляемый код пишется в одном из языков высокого уровня, которые могут выполняться в .NET, например C#, Visual Basic, F# и других. При компиляции кода, написанного на этих языках, с помощью соответствующего компилятора вы получаете не машинный код. Вы получаете код промежуточного языка, который затем компилируется и запускается средой выполнения. Язык C++ является исключением из этого правила, так как он позволяет создавать машинные неуправляемые двоичные файлы, которые запускаются в Windows.
Выполнение промежуточного языка промежуточный язык» (сокращенно IL)? Это результат компиляции кода, написанного на языках высокого уровня .NET. После компиляции кода, написанного на одном из этих языков, вы получаете двоичный файл на базе IL. Важно отметить, что IL не зависит от языка, выполняемого поверх среды выполнения. Для него даже есть отдельная спецификация, с которой при желании можно ознакомиться.
После создания IL из кода высокого уровня вы, скорее всего, захотите запустить его. В этот момент среда CLR берет управление на себя и запускает процесс JIT-компиляции, используя JIT для преобразования кода из промежуточного языка в машинный код, который может выполняться на ЦП. Таким образом, среде CLR точно известно, что делает код, поэтому она может эффективно управлять им.
Промежуточный язык иногда называют языком CIL или MSIL.
Взаимодействие неуправляемого кода
Конечно, среда CLR позволяет передавать границы между управляемым и неуправляемым миром, и есть много кода, который делает это, даже в библиотеках классов .NET. Это называется взаимодействиемили взаимодействием. Все это позволяет вам, например, заключить неуправляемую библиотеку в оболочку и вызвать ее. Но следует отметить, что после того как код пересекает границы среды выполнения, управление выполнением снова осуществляется в виде неуправляемого кода с соответствующими ограничениями.
.NET Framework — CLR
Аналогично этому язык C# позволяет использовать неуправляемые конструкции, такие как указатели, непосредственно в коде, используя так называемый небезопасный контекст, который обозначает фрагмент кода, выполнение которого не управляется средой CLR.
Дополнительные ресурсы
- Общие сведения о платформе .NET
- Небезопасный код и указатели
- Взаимодействие на уровне машинного кода
Источник: learn.microsoft.com
Общеязыковая исполняющая среда CLR
Существует ряд средств, которые поддерживаются .NET, но не поддерживаются C#, и, возможно, вас удивит, что есть также средства, поддерживаемые C# и не поддерживаемые .NET (например, некоторые случаи перегрузки операций). Однако поскольку язык C# предназначен для применения на платформе .NET, вам, как разработчику, важно иметь представление о .NET Framework, если вы хотите эффективно разрабатывать приложения на C#. Поэтому давайте заглянем «за кулисы» .NET.
Центральной частью каркаса .NET является его общеязыковая исполняющая среда, известная как Common Language Runtime (CLR) или .NET runtime. Код, выполняемый под управлением CLR, часто называют управляемым кодом. С точки зрения программирования под термином может пониматься коллекция внешних служб, которые требуются для выполнения скомпилированной единицы программного кода. Например, при использовании платформы MFC для создания нового приложения разработчики осознают, что их программе требуется библиотека времени выполнения MFC (т.е. mfc42.dll). Другие популярные языки тоже имеют свою исполняющую среду: программисты, использующие язык VB6, к примеру, вынуждены привязываться к одному или двум модулям исполняющей среды (вроде msvbvm60.dll), а разработчики на Java — к виртуальной машине Java (JVM).
В составе .NET предлагается еще одна исполняющая среда. Главное отличие между исполняющей средой .NET и упомянутыми выше средами, состоит в том, что исполняющая среда .NET обеспечивает единый четко определенный уровень выполнения, который способны использовать все совместимые с .NET языки и платформы.
Однако перед тем как код сможет выполняться CLR, любой исходный текст (на C# или другом языке) должен быть скомпилирован. Компиляция в .NET состоит из двух шагов:
1. Компиляция исходного кода в Microsoft Intermediate Language (IL)
2. Компиляция IL в специфичный для платформы код с помощью CLR
Этот двухшаговый процесс компиляции очень важен, потому что наличие Microsoft Intermediate Language (IL) является ключом ко многим преимуществам .NET. Microsoft Intermediate Language (промежуточный язык Microsoft) разделяет с байт-кодом Java идею низкоуровневого языка с простым синтаксисом (основанным на числовых, а не текстовых кодах), который может быть очень быстро транслирован в родной машинный код.
Основной механизм CLR физически имеет вид библиотеки под названием mscoree.dll (и также называется общим механизмом выполнения исполняемого кода объектов — Common Object Runtime Execution Engine). При добавлении ссылки на сборку для ее использования загрузка библиотеки mscoree.dll осуществляется автоматически и затем, в свою очередь, приводит к загрузке требуемой сборки в память. Механизм исполняющей среды отвечает за выполнение целого ряда задач. Сначала, что наиболее важно, он отвечает за определение места расположения сборки и обнаружение запрашиваемого типа в двоичном файле за счет считывания содержащихся там метаданных. Затем он размещает тип в памяти, преобразует CIL-код в соответствующие платформе инструкции, производит любые необходимые проверки на предмет безопасности и после этого, наконец, непосредственно выполняет сам запрашиваемый программный код.
Помимо загрузки пользовательских сборок и создания пользовательских типов, механизм CLR при необходимости будет взаимодействовать и с типами, содержащимися в библиотеках базовых классов .NET. Хотя вся библиотека базовых классов поделена на ряд отдельных сборок, главной среди них является сборка mscorlib.dll. В этой сборке содержится большое количество базовых типов, охватывающих широкий спектр типичных задач программирования, а также базовых типов данных, применяемых во всех языках .NET. При построении .NET-решений доступ к этой конкретной сборке будет предоставляться автоматически.
На данной схеме наглядно видно, как выглядят взаимоотношения между исходным кодом (предусматривающим использование типов из библиотеки базовых классов), компилятором .NET и механизмом выполнения .NET.
Использование байт-кода с четко определенным универсальным синтаксисом дает ряд существенных преимуществ:
Независимость от платформы
Первым делом, это значит, что файл, содержащий инструкции байт-кода, может быть размещен на любой платформе; во время выполнения может быть легко проведена финальная стадия компиляции, что позволит выполнить код на конкретной платформе. Другими словами, компилируя в IL, вы получаете платформенную независимость .NET — во многом так же, как компиляция в байт-код Java обеспечивает независимость от платформы программам на Java.
Следует отметить, что независимость .NET от платформы в настоящее время является лишь теоретической, поскольку реализация .NET доступна только для ОС Windows. Однако уже существуют частичные реализации для других платформ (например, проект Mono — попытка создать реализацию .NET с открытым кодом).
Повышение производительности
Хотя язык IL выше сравнивался с Java, все же IL на самом деле более гибкий, чем байт-код Java. Код IL всегда компилируется оперативно (Just-In-Time, JIT-компиляция), в то время как байт-код Java часто интерпретируется. Одним из недостатков Java было то, что во время выполнения программ процесс трансляции байт-кода Java в родной машинный код приводил к снижению производительности (за исключением самых последних версий, где Java компилируется оперативно (JIT) на некоторых платформах).
Вместо компиляции всего приложения за один проход (что может привести к задержкам при запуске), JIT-компилятор просто компилирует каждую порцию кода при ее вызове (т.е. оперативно). Если промежуточный код однажды скомпилирован, то результирующий машинный исполняемый код сохраняется до момента завершения работы приложения, поэтому его перекомпиляция при повторных обращениях к нему не требуется. В Microsoft аргументируют, что такой процесс более эффективен, чем компиляция всего приложения при запуске, поскольку высока вероятность того, что крупные фрагменты кода приложения на самом деле не будут выполняться при каждом запуске. При использовании JIT-компилятора такой код никогда не будет скомпилирован.
Это объясняет, почему можно рассчитывать на то, что выполнение управляемого кода IL будет почти настолько же быстрым, как и выполнение родного машинного кода. Однако это не объясняет того, почему Microsoft ожидает повышения производительности. Причина состоит в том, что поскольку финальная стадия компиляции происходит во время выполнения, JIT-компилятор на этот момент уже знает, на каком типе процессора будет запущена программа. А это значит, что он может оптимизировать финальный исполняемый код, используя инструкции конкретного машинного кода, предназначенные для конкретного процессора.
Традиционные компиляторы оптимизируют код, но они могут проводить лишь оптимизацию, не зависящую от конкретного процессора, на котором код будет выполняться. Это происходит потому, что традиционные компиляторы генерируют исполняемый код до того, как он поставляется пользователям. А потому компилятору не известно, на каком типе процессора они будут работать, за исключением самых общих характеристик вроде того, что это будет х86-совместимый процессор либо же процессор Alpha.
COM и COM+
Формально СОМ и СОМ+ не являются технологиями, нацеленными на .NET, поскольку компоненты, основанные на них, не могут компилироваться в IL (хотя в определенной степени это и можно сделать, применяя управляемый С++, если исходный компонент СОМ+ был написан на С++). Однако СОМ+ остается важным инструментом, потому что его средства не дублируют .NET. К тому же компоненты СОМ будут по-прежнему работать, и .NET включает средства взаимодействия с СОМ, позволяющие управляемому коду вызывать компоненты СОМ и наоборот. Тем не менее, скорее всего, вы обнаружите, что в большинстве случаев удобнее кодировать новые компоненты в виде компонентов .NET, чтобы воспользоваться преимуществами базовых классов .NET, а также другими выгодами от запуска управляемого кода.
Источник: professorweb.ru
Вопрос 4. Компиляция и выполнение приложений на платформе Microsoft .Net.
Все CLR-совместимые компиляторы вместо этого генерируют IL-код, который также называется управляемым модулем, потому что CLR управляет его жизненным циклом и выполнением. Рассмотрим составные части управляемого модуля:
Метаданные — это набор таблиц данных, описывающих то, что определено в модуле. Есть два основных вида таблиц: описывающие типы и члены, определенные в вашем исходном коде, и описывающие типы и члены, на которые имеются ссылки в вашем исходном коде. Метаданные служат многим целям:
1)устраняют необходимость в заголовочных и библиотечных файлах при компиляции, так как все сведения о типах и членах, на которые есть ссылки, содержатся в файле с IL-кодом, в котором они реализованы. Компиляторы могут читать метаданные прямо из управляемых модулей.
2)при компиляции IL-кода в машинный код CLR выполняет верификацию (проверку «безопасности» выполнения кода) используя метаданные, например, нужное ли число параметров передается методу, корректны ли их типы, правильно ли используется возвращаемое значение и т.д.
3)позволяют сборщику мусора отслеживать жизненный цикл объектов и т.д.
IL-код: управляемый код, создаваемый компилятором при компиляции исходного кода. Во время исполнения CLR компилирует IL-код в команды процессора.
По умолчанию CLR-совместимые компиляторы генерируют управляемый код, безопасность выполнения которого поддается проверке средой CLR. Вместе с тем возможно разрабатывать неуправляемый или «небезопасный» код, которому разрешается работать непосредственно с адресами памяти и управлять байтами в этих адресах. Эта возможность, обычно полезна при взаимодействии с неуправляемым кодом или при необходимости добиться максимальной производительности при выполнении критически важных алгоритмов. Однако использовать неуправляемый код довольно рискованно, т.к. он способен разрушить существующие структуры данных.
Чтобы понять принцип выполнения программы в среде CLR рассмотрим небольшой пример:
Непосредственно перед исполнением функции Main CLR находит все типы, на которые ссылается ее код. В нашем случае метод Main ссылается на единственный тип — Console, и CLR выделяет единственную внутреннюю структуру WriteLine.
Когда Main первый раз обращается к WriteLine, вызывается функция JITCompiler (условное название), которая отвечает за компиляцию IL-кода вызываемого метода в собственные команды процессора. Функции JITCompiler известен вызываемый метод и тип, в котором он определен.
JITCompiler ищет в метаданных соответствующей сборки IL-код вызываемого метода, затем проверяет и компилирует IL-код в собственные команды процессора, которые сохраняются в динамически выделенном блоке памяти. После этого JITCompiler возвращается к внутренней структуре данных типа и заменяет адрес вызываемого метода адресом блока памяти, содержащего собственные команды процессора. В завершение JITCompiler передает управление коду в этом блоке памяти. Далее управление возвращается в Main, который продолжает работу в обычном порядке.
Затем Main обращается к WriteLine вторично. К этому моменту код WriteLine уже проверен и скомпилирован, так что производится обращение к блоку памяти, минуя вызов JITCompiler. Отработав, метод WriteLine возвращает управление Main.
Таким образом, за счет такой компиляции производительность теряется только при первом вызове метода. Все последующие обращения к одной и той же структуре выполняются «на полной скорости», без повторной верификации и компиляции.
Промежуточный Язык и JIT компилятор
MSIL – это процессоронезависимый промежуточный язык, созданный Microsoft. MSIL — язык более высокого уровня, чем большинство машинных языков. Он понимает типы объектов и имеет инструкции для создания и инициализации объектов, вызова виртуальных методы и непосредственной манипуляции элементами массива. Он даже имеет инструкции, которые оперируют исключениями.
Как и любой другой машинный язык, MSIL может быть написан на ассемблере. Microsoft предоставляет ассемблер и дизассемблер для MSIL.
Перед тем, как выполнять управляемый код CLR должен сначала скомпилировать управляемые MSIL инструкции в инструкции процессора. Здесь возникает типичная проблема: когда пользователь запускает программу, он не намерен ждать пока вся программа скомпилируется, тем более, что большинство функций программы не будут вызваны. Поэтому CLR, компилирует MSIL код в инструкции процессора, когда функции непосредственно вызваны. Всякий раз, когда такая функция вызывается в будущем, сразу выполняется машинный код (а компилятор уже не вовлекается в процесс). Поскольку MSIL компилируется только в нужный момент (just-in-time — JIT), этот компонент CLR часто упоминается как JIT компилятор (JIT compiler) или JITter.
(Перевод: исходный код-> компилятор -> exe/dll (IL и метаданные) –> загрузчик класса -> JIT компилятор с необязательной проверкой -> машинные коды -> выполнение -> проверки безопасности; runtime engine; Библиотеки класов (IL и метаданные); безопасный прекомпилированный код; вызов некомпилированного метода)
Источник: studfile.net