Программирование для Silverlight с помощью CoreCLR - Внутри ядра CoreCLR

Внутри ядра CoreCLR

Разработка CoreCLR началась сразу после выпуска CLR версии 2.0 в октябре 2005. Двумя основными целями разработчиков были размер и совместимость: с точки зрения программиста, написание кода для CLR всегда должно быть одинаковым, тогда как с точки зрения пользователя загружаемый файл должен быть очень маленьким. Поскольку Silverlight изначально предназначен для иного набора ситуаций, чем настольный CLR, у нас имелась возможность внести некоторые изменения, упростившие CoreCLR и позволившие нам уменьшить размер установки Silverlight. Но единообразие внизу стека имеет ключевое значение. Различия в поведении (даже если они верны) проявляют себя как ошибки выше в стеке.

Чтобы гарантировать совместимость, мы использовали одинаковый код для компонентов внизу стека. Механизм исполнения и виртуальная машина идентичны. В них входят система типов и метаданные, сборщик мусора (garbage collector – GC), динамический компилятор и пул потоков, а также прочие ключевые части механизма среды выполнения.

Однако для соответствия случаю веб-приложения были внесены некоторые изменения. Например, поскольку расширенные приложения Интернета обычно являются простыми и короткоживущими, динамический компилятор сосредотачивается на уменьшении времени запуска, а не на выполнении более сложных оптимизаций. Аналогично, серверный режим сбора мусора, настроенный под несколько рабочих потоков, использующих похожие шаблоны выделения, не имеет смысла для размещенных в сети приложений. Так что в Silverlight включает лишь стандартный сборщик мусора рабочей станции, который настроен под интерактивные приложения. Но язык MSIL и метаданные, используемые в приложениях Silverlight, идентичны используемым в управляемых приложениях для рабочей среды; поведение приложения в рабочей среде и в обозревателе будет единообразным.

Тот факт, что Silverlight не предназначен для замены настольной CLR, вызвал крупнейшее изменение в его базовом механизме: CoreCLR будет работать в процессе параллельно с настольной CLR. В прошлом у нас никогда не было возможности выполнять две версии CLR изнутри одного процесса. Это непростая проблема по ряду причин. Одна из них – управление состоянием для всего процесса: каждый экземпляр CLR предполагает, что является единственным в процессе и, следовательно, единственным, касающимся его статических данных. Если переменная staticFoo существует в версиях CLR 1.1 и 2.0, и обе версии CLR загружаются в один и тот же процесс одновременно, ни одна из версий не может записывать в переменную staticFoo, не изменяя при этот состояние другой CLR.

Хотя состояние всего процесса является наиболее очевидной проблемой, параллельное выполнение двух CLR в одном процессе может породить и другие. Например, если два сборщика мусора работают разом, как удержать один сборщик мусора от приостановки потока второго сборщика мусора? Вдобавок, существует проблема с местом: при загрузке нескольких CLR в процесс каждой из них приходится загружать код, который может быть для них общим и каждая из них получает свое место для статических переменных и управляемых куч.

Существует несколько важных случаев, в которых требуется возможность размещать CoreCLR параллельно с настольной рабочей средой. Если CoreCLR и настольная CLR не могут работать рядом друг с другом, то невозможно написать настольную форму Windows Forms или приложение WPF, размещающее элемент управления веб-обозревателя, который может перейти к веб-странице, использующей Silverlight. Чтобы обойти эту потенциальную проблему, мы могли бы просто заставить Silverlight полагаться на CLR, установленную на компьютере Windows разработчика: в каждой установке Windows XP с пакетом обновления 2 или Windows Vista имеется достаточно свежая CLR, установленная вместе с системой. Но работа всего кода Silverlight на CoreCLR гарантирует абсолютную совместимость вне зависимости от того, какая CLR установлена на компьютере (или, в случае Mac OS X, есть ли CLR на компьютере вообще!) Так что мы проделали работу по обеспечению параллельной работы CoreCLR в процессе с настольной CLR, и мы думаем, что Silverlight сможет предоставить пользователям гораздо большее удобство благодаря нашим усилиям.