Common Language Runtime

The Common Language Runtime (CLR) is an execution engine with the primary purpose of providing managed execution of .NET code. The central point to remember about the CLR is the word "managed." The CLR manages the execution, versioning, and security of all .NET code. This is why you'll often see .NET or C# code referred to as "managed code." All code that targets the .NET CLR is "managed code." Conversely, when speaking in .NET terms, the word "unmanaged" refers to code that is not managed by the CLR, including executables and libraries that are compiled directly to native machine code.

Managed code is not compiled to native machine code. Rather, it is compiled to Microsoft Intermediate Language (MSIL), which I'll refer to as just IL. Much like Java byte code (or just byte code), IL is an assembler-like language. However, one of the primary conceptual differences between byte code and IL is the fact that IL does not have an interpreted specification. IL is loaded and Just-In-Time (JIT) compiled to machine code in memory by the CLR at runtime. Another difference between Java byte code and IL is that IL is designed specifically to support multiple languages. One could split hairs about semantic differences between byte code and IL, and lengthy discussions persist on public forums, but the fact is that a compiled specification and multilanguage support are the intention of the designers of IL and something that a .NET developer, including C# developers, should be aware of.

.NET programs are composed of assemblies, which are the logical atomic unit of deployment, identification, and security. They differ from traditional executables in that an assembly can consist of one or more files. A .NET assembly is commonly packaged as a single executable or library file, but may also contain modules, which are nonexecutable code units that may be reused in other assemblies.

Assemblies are self-describing . Because they contain their own metadata, there is no need for separate repositories, such as the registry or other catalogs. Assemblies can also be signed and secured, making them safe from other malicious code. A "type" is a named abstraction that may be either intrinsic to the language you're using or a custom defined type. The significance of type safety is that it makes code more robust and helps protect against malicious use of your program. Because C# is a type-safe language, it will detect most type mismatches at compile time and render errors. For example, you wouldn't want to accidentally assign a double type in a scientific application to an integer type. By catching type errors at compile time, you are saved the potentially disastrous effects of missing a runtime error. Also, with type safety, it is harder for malicious code to coerce one type into another in order to manipulate your memory improperly. The CLR verifies the type safety of an assembly for extra protection against those runtime situations that can't be identified at compile time.

Another important feature to know about the CLR is how it loads and executes code. Understanding this process brings home the points of security and type safety. It also gives you insight into performance considerations and memory management. Figure 1.1 demonstrates how the CLR manages the lifetime of an application.

As soon as a .NET program begins execution, Windows detects that this is a .NET assembly and starts up the CLR. The CLR then identifies the program entry point and begins the Resolve Types process, in which it finds out where a given type is located. Identified assemblies are loaded by the Loader process.

This process illustrates why the .NET compiler is called a JIT compiler—types are loaded on an as-needed basis or just-in-time. The verification process ensures type safety and security. If the JIT compiler encounters a type that it needs, it will consult the Resolve Types process to find and load the necessary assembly, so that it can continue.

The initial JIT compilation represents a noticeable performance hit, occurring when an application first starts. Subsequent performance of loads will vary, depending on the type retrieved. As hinted, these are only initial delays, and performance improves greatly after a type has joined the in-memory working set.

After a type has been compiled to machine code, the memory manager handles it. Value types (structs) are allocated on the stack and reference types (classes) are allocated on the heap. Periodically, the garbage collector kicks in to clean up unused heap objects in a mark-and-sweep fashion. The garbage collector maintains generations, cleaning up newer unused objects before older ones. With additional optimizations, a garbage collection on average is no more intrusive than a typical page fault.

In-memory code is native machine code that has already been JIT compiled and can be fed directly to the CPU. The in-memory working set will remain in place until memory pressure causes a garbage collection. The generational behavior and other optimizations of the memory manager help prevent page faults in active code, resulting in greater performance.

When the CPU needs to execute type members that are not in memory, it will request that type from the JIT compiler. Because of optimizations, execution/JIT-Compilation/Resolution cycles are minimized. The important point to understand is that it is this cycle that causes performance loss. For small programs this is generally not a problem because it will be easier to keep the working set in memory. However, for larger programs you will want to release unused objects as soon as they are no longer needed. This relieves memory pressure and helps keep the primary working set in memory.

The CLR is central to all that happens in .NET. Understanding how it works is the key to writing well-behaved code that performs efficiently .

Programming Languages

Another important part of .NET is the concept of multilanguage support. IL is designed to support many languages. In fact, there are currently dozens of languages that target the CLR by compiling to IL. Besides C#, .NET ships with Visual Basic .NET, JScript .NET, J# .NET, and Managed C++. Other vendors include Borland Delphi .NET, Fujitsu COBOL .NET, Python .NET, Perl .NET, and many others.

The glue that holds all these languages together is referred to as the Common Type System (CTS). Although each language represents types in a unique manner, the underlying behavior and semantics of each type are the same to the CLR. The CTS defines which members a type may have: Field, Methods, Events, Properties, and Indexers. It also specifies their scope and visibility: public, internal, protected, protected internal, and private. Of course, this description is given through the perspective of C# keywords: Other languages may differ in keyword, but the underlying semantics of the CLR remain the same.

Why multiple languages? For a better perspective of the reasoning behind this approach, consider a large business with multiple software projects. It is often the case that the languages in many of these projects are different. Unless the developers are using a component technology such as COM, they are probably not getting much reuse of code between projects. Having multiple languages that target a single platform has more potential for reuse, which is an important business benefit.

The ability to code in multiple languages has benefits in business-to-business commerce also. The third-party component market is huge, with more companies joining the .NET arena every day. These companies can code their components in any .NET language they choose. These components are reusable by any other .NET application, regardless of the language it is being written in. Multiple language support in .NET opens new markets to component vendors that, in the past, might have been difficult to support and reach.