CLR 全面透彻解析: 使用 CoreCLR 编写 Silverlight

核心提示： 深入了解 CoreCLR 引擎自 2005 年 10 月发行 CLR 的 2.0 版本后即开始了 CoreCLR 的设计，它的两个主要设计目标是大小和兼容性：从编程人员的角度来看，CLR 全面透彻解析: 使用 CoreCLR 编写 Silverlight(2)，针对 CLR 的编码应该始终

深入了解 CoreCLR 引擎

自 2005 年 10 月发行 CLR 的 2.0 版本后即开始了 CoreCLR 的设计。它的两个主要设计目标是大小和兼容性：从编程人员的角度来看，针对 CLR 的编码应该始终相同，而从用户的角度来看，下载必须非常小。由于 Silverlight 旨在提供一组不同于桌面 CLR 的方案，因此，我们可以进行一些更改，以简化 CoreCLR 并允许我们缩减 Silverlight 的安装大小。但是，堆栈底部的一致性至关重要。行为差异（即使这些行为差异都正确）表明堆栈上部有错误。

为了确保兼容性，我们在堆栈底部的各个组件中使用相同的代码。执行引擎和虚拟机都是相同的。其中包括类型系统和元数据、垃圾回收器 (GC)、JIT 编译器、线程池以及运行时引擎的其他核心部件。

但是，为了适应 Web 应用程序方案，进行了一些更改。例如，富 Internet 应用程序通常简单且运行时间短，JIT 编译器主要侧重于减少启动时间，而非执行更复杂的优化操作。同样，服务器垃圾回收模式可以对使用相似分配模式的多个工作线程进行优化，而对 Web 托管应用程序则行不通。因此，Silverlight 只包含针对交互式应用程序进行优化的标准工作站 GC。但是，在 Silverlight 应用程序中使用 Microsoft 中间语言 (MSIL) 和元数据的方式与在针对桌面的托管应用程序中的使用方式完全相同，而且应用程序的行为在用户的桌面上和在浏览器上一致。

事实上，Silverlight 并不打算取代桌面 CLR，这就引发了核心引擎中最大的变化：CoreCLR 将与桌面 CLR 进程并行运行。过去，我们从来就不能在同一进程中运行 CLR 的两个版本。这是一个难题，原因有好几个，其中一个是管理进程范围的状态：每个 CLR 实例都假定进程中只有一个 CLR，因而只有它可以处理其静态数据。如果 CLR 1.1 和 2.0 中都包含 staticFoo 变量，而且在同一个进程中同时加载了这两个 CLR 版本，则任一版本都无法在不影响另一个 CLR 状态的情况下写入 staticFoo 变量。