"Just-in-Time" Compiling and .NET

I've mentioned "just-in-time" (JIT) compiling in passing in previous columns. Now let's talk more about how JIT compiling works.

Computers don't speak VBScript, C#, or any other high-level programming language. To let a computer understand what you're telling it, the code must be interpreted (as scripting languages such as VBScript are) or compiled. The act of compiling transforms source code into object code, which is similar to the machine language that a computer understands. Source code--the code written in the high-level programming language--is compiled for a particular processor design. Consequently, even though four different kinds of processors support Windows NT 4.0, you need different software to support PowerPC and x86-based computers--the two types of processors arrange storage in different ways and so can't read each other's compiled code.

Programs written in C++, for example, are already compiled from the source code for the appropriate platform. The Microsoft .NET platform, however, is designed to handle JIT compiling. The JIT compiling function compiles source code for an application as it's executed. Although this approach necessarily incurs a performance hit, JIT compiling has some advantages for code management. Updates to the source code are implemented each time you run the application, so the developer doesn't need to recompile the code each time the application runs. The JIT compiler can tell whether the computer the code will execute on has one processor or is a multiprocessor machine and compiles accordingly. Also, because the code is compiled as it's run, the addresses that the machine code references are correct. Precompiled code assumes that the OS loads code at a particular base address. If the code doesn't load at that base address, then the relative address locations will be incorrect, and the OS loader must sort out what those addresses should be, given the new location. JIT compilers make no assumptions about the base address.

A function within the Common Language Runtime (CLR) compiles the source code into machine code. The OS can detect managed code by looking for a value in the program. When managed code calls a particular method, the compiling function wakes up, looks up the intermediate code (processor-agnostic object code that's similar to the machine code), then compiles the intermediate code into instructions for the available processor. The managed code then saves those instructions in a dynamically allocated location in memory. The compiling function points back to the original method so that the two are linked: When the method in the assembly executes, it executes the processor instructions stored in memory. As long as these instructions stay in memory (in other words, as long as the application keeps running), the compiler function doesn't have to do anything when that method executes again. However, when the application terminates, all the processor instructions are unloaded from memory. Every time that application restarts, the code needs to be recompiled. A second instance of the application, or the same method called by another application, will need to be compiled as well because the mapping of processor instructions to the method's location in memory won't be accurate for the new process.

Precompiling .NET code is possible. You do this by running the compiling utility with the name of the managed code. Doing so loads the CLR, which then loads the assembly, which then compiles all the intermediate code associated with the assembly into processor instructions. However, you should use precompiling only to offset the performance hit that JIT compiling incurs because by using precompiled code you lose the advantages of managed code and JIT compiling, such as automatic updates and correct memory locations. (The precompiling approach assumes that code executes at a particular base location, and if the base location changes, the OS loader has to translate all the instruction addresses.) Precompiling is also irreversible.

That's a quick and dirty look at how JIT compiling works and why .NET applications use it. The point of JIT compiling is to make code execute more easily on various platforms. (Learn more from "10 More VBScript Techniques").