通过

Exploring the CoreCLR Inside Silverlight

  • 项目

Brandon Bray gave an interesting presentation at MIX09 on how the CLR (the execution engine that underlies the .NET Framework) was refactored to support for Silverlight; I thought I’d share my distilled notes from the session.

Bringing .NET to the Silverlight world was an obvious choice. Not only does it have a broad community and powerful tools ecosystem, but the CLR also offers many important and useful features for building RIAs: strong type safety, partial trust security verification and AppDomains (providing isolation for multiple applications within a single process). But the existing .NET Framework is specific to Windows, and has grown too large for deployment in a web runtime where every byte counts. So it was necessary to rework the CLR to be optimized for this purpose.

CLR Size Reductions

Looking at the .NET architecture, it was designed to support many different scenarios across client and server, including profiling and debugging, just-in-time compilation, and so on. For Silverlight, we just needed to focus on one scenario: interactive client applications. Silverlight contains “CoreCLR”, a cut down version built from the same sources that runs side-by-side with the full .NET CLR. CoreCLR is just 2MB in size. It’s worth noting in passing that CoreCLR is also embedded within other Microsoft technologies, most notably Live Mesh.

Some compromises that could be made to trim the size of the CLR right down:

  • We don’t need to support full-trust applications; applications downloaded from the web are always partial trust.
  • We don’t need interoperability with native or COM code.
  • The versioning model is simpler: we only need one runtime at a time (we don’t need to ship older versions)
  • CoreCLR can only be activated through a host (the Silverlight control): it doesn’t need to be activated through an executable or a COM object.

image The Silverlight architecture is fundamentally the same: the same architectural boxes are present (albeit the surface area is much smaller in each case), with the exception of NGEN and profiling API support. The JIT does a minimum of optimization to improve startup time and reduce code size. The server-optimized garbage collector is removed, since it isn’t required; the reflection engine is substantially reduced, and Silverlight relies on the underlying operating system for collation string tables that are already standardized.

But that wasn’t enough. To get the CoreCLR down to its target size of 2MB, a good proportion of the size savings had to come from the base class library. CoreCLR includes a subset of the base class library called Small BCL. As with the rest of CoreCLR, Small BCL is built from the same source code as the full .NET BCL.

CoreCLR Security Model

image One other area that has contributed significant code size savings is the notion of transparent libraries. The full desktop .NET supports Code Access Security, a very rich but complex security model. The CoreCLR security model makes reasoning about security much easier. There are three layers of code:

  • SecurityCritical code: this is code that has full trust (for example, accessing native code through P/Invoke or changing an application’s global state). It also trusts any code that calls it, but can only be accessed by SafeCritical code.
  • SafeCritical code is the bridge between SecurityCritical code and the outside world; it should always verify the input from any code that calls it.
  • Transparent code is the code that can call into SafeCritical APIs in the Silverlight runtime. This is the only layer that can exist outside of the Silverlight runtime.

Along with the transparent code that a developer compiles into a XAP, the same concept is used for other libraries like LINQ and the DLR as well as many controls; this means that they don’t need to be installed as part of the Silverlight runtime itself but can be downloaded on-demand as part of the application download on request. In Silverlight 3, transparent libraries can be cached so they only have to be downloaded once.

Cross-Platform Support
In one critical way the CoreCLR in Silverlight has to do more than the full .NET CLR: it has to run on Mac OS as well as Windows. This is implemented through a Platform Abstraction Layer (PAL), based on the work done some years ago for a research project called Rotor. The PAL can be fairly simple because Silverlight only needs to support the x86 instruction set. Again, this is checked into the main CLR codebase, but is only required for the CoreCLR implementation.

For more information about the CoreCLR, Andrew Pardoe’s MSDN Magazine article on Programming Silverlight with the CoreCLR is perhaps the most authoritative online source.

Comments

  • Anonymous
    March 23, 2009
    PingBack from http://blogs.msdn.com/tims/archive/2009/03/23/exploring-the-coreclr-inside-silverlight.aspx

  • Anonymous
    March 23, 2009
    Hi, Very informative article, meanwhile I have written something similar on my blog, rather I attempt to write at my best a month back : http://pendsevikram.blogspot.com/2009/02/silverlight-coreclr-and-revisiting.html This SafeCritical and SecurityCritical information is really valuable, Thanks for sharing the same. I saw in one of session at PDC, where they talking about Silverlight on mobile, just curious to know whether Core CLR for mobile will be subset of compact framework?, If you have any information, please share with us.

  • Anonymous
    March 24, 2009
    Thank you for submitting this cool story - Trackback from DotNetShoutout

  • Anonymous
    March 26, 2009
    For everyone who attended MIX this year, we hope it was a lot of fun. Brandon from our team, gave a talk

  • Anonymous
    March 29, 2009
    Tim, thanks for the great article! A couple of questions pop in my mind: Is CoreCLR a separate product that is used by both Silverlight and LiveMesh? Or do these projects have their own custom versions of CoreCLR. Additionally, is CoreCLR available for anyone to embedded in their applications?

  • Anonymous
    April 01, 2009
    The comment has been removed

  • Anonymous
    May 18, 2009
    Silverlight (Architectures, Features and Comparison) Part-IV