Intermediate Language IL and Just-In-Time JIT Compilation Metadata

117 Because Visual Basic .NET automatically generates CLS-compliant components, this book does not describe the CLS rules. However, to give you a sense of the kind of thing that the CLS specifies, consider that some languages support a feature called operator overloading . This allows the developer to specify actions that should be taken if the standard operator symbols + , - , , , = , etc. are used on user-defined classes. Because it is not reasonable to expect that all languages should implement such a feature, the CLS has a rule about it. The rule states that if a CLS-compliant component has public types that provide overloaded operators, those types must provide access to that functionality in another way as well usually by providing a public method that performs the same operation.

3.7 Intermediate Language IL and Just-In-Time JIT Compilation

All compilers that target the CLR compile source code to Intermediate Language IL, also known as Common Intermediate Language CIL. IL is a machine language that is not tied to any specific machine. Microsoft designed it from scratch to support the CLIs programming concepts. The CLI specifies that all CLR implementations can compile or interpret IL on the machine on which the CLR is running. If the IL is compiled versus interpreted, compilation can occur at either of two times: • Immediately prior to a method in the application being executed • At deployment time In the first case, each method is compiled only when it is actually needed. After the method is compiled, subsequent calls bypass the compilation mechanism and call the compiled code directly. The compiled code is not saved to disk, so if the application is stopped and restarted, the compilation must occur again. This is known as just-in-time JIT compilation and is the most common scenario. In the second case, the application is compiled in its entirety at deployment time. IL is saved to .exe and .dll files. When such a file containing IL is executed, the CLR knows how to invoke the JIT compiler and execute the resulting code. Note that on the Microsoft Windows platforms, IL is always compiled—never interpreted.

3.8 Metadata

Source code consists of some constructs that are procedural in nature and others that are declarative in nature. An example of a procedural construct is: someObject.SomeMember = 5 This is procedural because it compiles into executable code that performs an action at runtime. Namely, it assigns the value 5 to the SomeMember member of the someObject object. In contrast, here is a declarative construct: Dim someObject As SomeClass This is declarative because it doesnt perform an action. It states that the symbol someObject is a variable that holds a reference to an object of type SomeClass. In the past, declarative information typically was used only by the compiler and did not compile directly into the executable. In the CLR, however, declarative information is everything The CLR uses type and signature information to ensure that memory is always referenced in a safe way. The JIT compiler uses type and signature information to resolve method calls to the appropriate target code at JIT compile time. The only way for this to work is for this declarative information to be included alongside its associated procedural information. Compilers that target the CLR therefore store both procedural 118 and declarative information in the resulting .exe or .dll file. The procedural information is stored as IL, and the declarative information is stored as metadata. Metadata is just the CLIs name for declarative information. The CLI has a mechanism that allows programmers to include arbitrary metadata in compiled applications. This mechanism is known as custom attributes and is available in Visual Basic .NET. Custom attributes were discussed in detail in Chapt er 2 .

3.9 Memory Management and Garbage Collection