Иво Салмре - Программирование мобильных устройств на платформе .NET Compact Framework

Оглядываясь назад, мы можем констатировать, что принятое нами решение было правильным.

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

1 . Загружается управляемое приложение. Двоичный заголовок приложения указывает операционной системе на то, что оно не является приложением в собственных кодах. Вместо того чтобы просто предоставить возможность выполняться инструкциям кода, загружается исполнительный механизм .NET Compact Framework, которому сообщается о том, что он должен запустить приложение на выполнение.

2. Исполнительный механизм находит класс, содержащий "главную" точку входа "main", с которой должно начинаться выполнение приложения. Таковым является класс с сигнатурой функции, соответствующей виду static void Main(). В случае обнаружения типа с такой сигнатурой происходит загрузка класса и производится попытка выполнения "главной" процедуры (шаги 3 и 4).

3. Загружается класс. Информация о классе загружается и верифицируется с той целью, чтобы убедиться в корректности и согласованности определения класса. Все методы (то есть точки входа исполняемого кода) класса обозначаются как "некомпилированные".

4. Исполнительный механизм пытается выполнить указанную процедуру. Если уже имеется откомпилированный код, связанный с процедурой, осуществляется выполнение этого кода.

5. Если исполнительный механизм обнаруживает, что свойство или метод, которые требуется запустить на выполнение, не откомпилированы, они компилируются по требованию. Производится загрузка содержащейся в классе информации, которая необходима методу. Код верифицируется для гарантии того, что он содержит безопасные, допустимые и корректно сформированные IL-инструкции, а затем подвергается JIT-компиляции. Если метод ссылается на другие типы, которые еще не были загружены, осуществляется необходимая загрузка определений соответствующих классов и типов. Методы, содержащиеся в классах, не компилируются до тех пор, пока в этом не возникнет необходимости; именно в этом и состоит смысл JIT-компиляции.

6. Выполняется скомпилированный к этому моменту метод. Если возникает необходимость в распределении памяти для типов или методов, исполнительному механизму направляются соответствующие запросы. Любые вызовы классов методами возвращают нас к шагу 5.

На первый взгляд, вышеперечисленные действия требуют выполнения большого объема работы, однако в действительности все происходит очень быстро.

На заметку! "Типом" являются любые данные, с которыми может работать программист. Это можно сформулировать и иначе, сказав, что типами являются любые типы данных и классы. Все является типом, включая целые и десятичные числа, другие скалярные величины, строки и классы. Любая "сущность", которой вы можете манипулировать внутри кода, является экземпляром типа. Классы являются специальными типами в том смысле, что они содержат не только данные, но и код, и поддерживают такие объектно-ориентированные свойства, как наследование.

На заметку! После загрузки определений классов и других типов в память, их верификации и компиляции эти данные размещаются в распределенной памяти точно так же, как и любые другие данные, которые разработчики распределяют в своих приложениях. Рассмотрим пример. Предположим, вы создаете объект ArrayList:

System.Collection.ArrayList aList = new System.Collection.ArrayList();

При этом выполняются следующие операции:

1. Вышеприведенный код представляется в вашем приложении на промежуточном языке IL. Этот IL-код подвергается JIT-компиляции во время выполнения непосредственно перед тем, как выполняться в первый раз. Этот код помещается в распределенную память.

2. По окончании JIT-компиляции кода исполнительный механизм пытается определить, загружена ли информация о типе System.Collections.Array в память; если это не так, выполняется распределение памяти для этого типа, а также загрузка и связывание определения с классом ArrayList.

3. Во время выполнения приведенного выше фактического кода должен быть выполнен конструктор объекта ArrayList. Если соответствующий код еще не загружался и не подвергался JIT-компиляции, осуществляется распределение памяти для кода конструктора и JIT-компиляция этого кода. Выполняется загрузка кода, его верификация и JIT-компиляция, и память, распределенная для кода этого конструктора, связывается с конструктором класса ArrayList.

То же самое относится и к любому другому загружаемому типу или вызываемому методу; если необходимая работа по их загрузке не была до этого выполнена, они загружаются и компилируются по мере необходимости, и используемая для этого память связывается с типом.

Описанное распределение и отслеживание памяти играет очень важную роль. Как далее будет показано, к данным о коде и определениях классов, как и к любым другим объектам, могут применяться операции сборки мусора.

В процессе своего обычного выполнения ваш код периодически инициирует загрузку определений типов в память, компиляцию и выполнение кода, а также размещение объектов в памяти и их удаление из памяти. .NET Compact Framework проектировалась таким образом, чтобы обеспечить наилучший баланс между скоростью запуска, устойчивостью и непрерывностью выполнения кода даже в условиях существования жестких ограничений на объем доступной памяти. Для достижения этой цели загрузчик классов, механизм JIT-компиляции, а также модули распределения памяти и сборки мусора работают скоординированным образом.

Вероятнее всего, выполнение вашего кода будет сопровождаться периодическим созданием новых объектов и их последующим уничтожением после того, как необходимость в них исчезает. Эффективное удовлетворение запросов памяти для размещения объектов и ее освобождение достигаются в .NET Compact Framework за счет утилизации освобождаемой памяти путем так называемой "сборки мусора" (garbage collection). Операции по сборке мусора в той или иной форме используются в большинстве современных сред выполнения управляемого кода.

Сборка мусора в основном предназначена для решения двух задач: 1) восстановления памяти, которая больше не используется, и 2) уплотнения участков используемой памяти таким образом, чтобы для вновь распределяемых областей памяти были доступны как можно более крупные блоки. Тем самым решается одна из наиболее распространенных проблем, которая называется фрагментацией памяти. По своей сути эта проблема аналогична проблеме фрагментации дискового пространства. Если дисковое пространство периодически не реорганизовывать, то по прошествии некоторого времени оно дезорганизуется и разобьется на ряд чередующихся свободных и занятых участков небольшого размера; эти участки и являются фрагментами. Можно считать, что здесь мы имеем дело с проявлением действия закона увеличения энтропии применительно к дисковому пространству и памяти; для того, чтобы обратить энтропийные эффекты, необходимо затратить определенную работу. В результате фрагментации доступ к данным замедляется, поскольку в процессе чтения файлов головкам приходится многократно перемещаться вдоль поверхности диска. Фрагментация памяти оборачивается еще худшими бедами, так как для размещения объектов требуются достаточно большие непрерывные блоки памяти, способные уместить целиком все данные, относящиеся к объекту. После выполнения многочисленных операций выделения и освобождения порций памяти различного размера свободные области оказываются расположенными вразброс, а их размеры являются недостаточными, чтобы обеспечивалось наличие больших непрерывных участков памяти, необходимых для размещения объектов. Уплотнение всей используемой, но расположенной вразброс памяти позволяет создавать крупные блоки свободной памяти, которую можно эффективно использовать при распределении памяти для вновь создаваемых объектов.