CLR comprehensive and thorough parsing: using CORECLR to write Silverlight

Silverlight™2 contains a number of changes to the Windows®presentation Foundation (WPF) UI framework: New controls, Rich network APIs, and digital Rights Management (DRM) support. One of the major changes in Silverlight 2 is the ability to write WEB clients in a microsoft®.net-compliant language. In this article, I will highlight the development core of Silverlight: CoreCLR.

Over the past more than 10 years, we've had a number of different WEB programming technologies, from CSS to ECMAScript variants. Most of these technologies are specific to WEB programming tasks, and for example, the techniques learned by programming CSS are not applicable to other areas. In contrast, Silverlight 2 allows you to use the same. NET Framework technologies (such as base class libraries, XAML, and C #) that apply to desktop programming, and allows you to apply these technologies directly to WEB client applications. In addition, you do not need to create a separate CORECLR development environment: You can use visual studio® to design, develop, debug, and configure C # or Visual basic® just as you would with a desktop application. The Silverlight 2 coreclr we create can make WEB programming as rich as desktop programming.

Although it is good for developers to have a rich programming environment, users do not want to download large browser plug-ins. To make Silverlight suitable for users, you must implement a quick installation. We have reduced the Beta 1 installation size to 4.3MB, which takes approximately 6-10 seconds to install via a broadband connection. Think about the size of the. NET Framework 2.0 The two main core parts of the CLR (Mscorwks.dll and mscorlib.dll) equal to the size of the Silverlight 2 Coreclr.dll and mscorlib.dll addition, which That was a great achievement.

Deep understanding of the CORECLR engine

The CORECLR design began after the release of the 2.0 version of the CLR in October 2005. Its two main design goals are size and compatibility: From a programmer's perspective, the encoding for the CLR should always be the same, and the download must be very small from the user's point of view. Since Silverlight is designed to provide a different set of scenarios than the desktop CLR, we can make some changes to simplify coreclr and allow us to reduce the installation size of Silverlight. However, consistency at the bottom of the stack is critical. Behavioral differences, even if these behavior differences are correct, indicate an error on the top of the stack.

To ensure compatibility, we use the same code in each of the components at the bottom of the stack. Both the execution engine and the virtual machine are the same. These include the type system and metadata, the garbage collector (GC), the JIT compiler, the thread pool, and other core parts of the Run-time engine.

However, some changes have been made to accommodate the WEB application scenario. For example, rich Internet applications are typically simple and run for a short time, and the JIT compiler focuses primarily on reducing startup time rather than performing more complex optimization operations. Similarly, the server garbage collection model can be optimized for multiple worker threads that use similar allocation patterns, but not for Web managed applications. As a result, Silverlight contains only standard workstation GC that is optimized for interactive applications. However, the use of Microsoft intermediate language (MSIL) and metadata in Silverlight applications is exactly the same as in a managed application for the desktop, and the behavior of the application is consistent on the user's desktop and on the browser.

In fact, Silverlight is not going to replace the desktop CLR, which raises the biggest change in the core engine: CORECLR will run in parallel with the desktop CLR process. In the past, we have never been able to run the two versions of the CLR in the same process. This is a difficult problem for several reasons, one of which is managing a process-scoped state: Each CLR instance assumes that there is only one CLR in the process, and that only it can handle its static data. If both CLR 1.1 and 2.0 contain Staticfoo variables, and the two CLR versions are loaded simultaneously in the same process, neither version can write the Staticfoo variable without affecting another CLR state.

While the process-scoped state is the most obvious problem, running two of the CLR in parallel in one process can cause other problems. For example, if you run two GC at the same time, how do you prevent one GC from suspending another GC thread? In addition, there is a problem with space occupancy: If you load multiple CLR in a process, each CLR must load code, which may be the same, and leave space for its static variables and the managed heap.

In some important cases, the managed CORECLR needs to run in parallel with the desktop runtime. If the CoreCLR and desktop CLR cannot run at the same time, we will not be able to write a desktop Windows form or WPF application for a managed Web browser control that can navigate to a Web page that uses Silverlight. To resolve this potential problem, simply install the CLR-dependent Silverlight on your Windows computer: Each time you install Windows XP SP2 and Windows vista®, a fairly new CLR will be installed with the operating system. However, regardless of which version of the CLR is installed on your computer (for Mac OS X, even if no CLR is installed on your computer), you must ensure absolute compatibility if all Silverlight code is run on CORECLR. Therefore, we strive to enable CORECLR to run in parallel with the desktop CLR process, and we believe that users will get a better Silverlight experience through our efforts.