.NET code compilation or complication?

Question

Q1) Why is C# initially compiled to IL and then at runtime JIT complied and run on top of a virtual machine(?). Or is it JIT complied to native machine code?

Q2) If the second is true (JIT complied to native machine code), then where is the .NET sandbox the code runs under?

Q3) In addition, why is the code compiled to IL in the first place. Why not simply compile to native machine code all the time? There is a tool from MS from this called ngen but why is that optional?

Answer 1

The IL is JIT'd (JIT = Just In Time) compiled to native machine code as the process runs.

The use of a virtual machine layer allows .NET to behave in a consistent manner across platforms (e.g. an int is always 32 bits regardless of whether you're running on a 32- or 64- bit machine, this is not the case with C++).

JIT compiling allows optimisations to dynamically tailor themselves to the code as it runs (e.g. apply more aggressive optimisations to bits of code that are called frequently, or make use of hardware instructions available on the specific machine like SSE2) which you can't do with a static compiler.

Answer 2

A1) JIT compiles to native machine code

A2) In .net there is no such term as sandbox. There is AppDomains instead. And they runs as part of CLR (i.e. as part of executable process)

A3) NGen drawbacks from Jeffrey Richter:

• NGen'd files can get out of sync. When the CLR loads an NGen'd file, it compares a number of characteristics about the previously compiled code and the current execution environment. If any of the characteristics don't match, the NGen'd file cannot be used, and the normal JIT compiler process is used instead.

• Inferior Load-Time Performance (Rebasing/Binding). Assembly files are standard Windows PE files, and, as such, each contains a preferred base address. Many Windows developers are familiar with the issues surrounding base addresses and rebasing. When JIT compiling code, these issues aren't a concern because correct memory address references are calculated at run time.

• Inferior Execution-Time Performance. When compiling code, NGen can't make as many assumptions about the execution environment as the JIT compiler can. This causes NGen.exe to produce inferior code. For example, NGen won't optimize the use of certain CPU instructions; it adds indirections for static field access because the actual address of the static fields isn't known until run time. NGen inserts code to call class constructors everywhere because it doesn't know the order in which the code will execute and if a class constructor has already been called.

Answer 3

You can use NGEN to create native versions of your .NET assemblies. Doing this means that the JIT does not have to do this at runtime.

.NET is compiled to IL first and then to native since the JIT was designed to optimize IL code for the current CPU the code is running under.

.NET code is compiled to IL for compatability. Since you can create code using C#, VB.NET, etc then the JIT needs a common instruction set (IL) in order to compile to native code. If the JIT had to be aware of languages, then the JIT would need to be updated when a new .NET language was released.

I'm not sure about the sandbox question, my best guess is that a .NET app runs with 3 application domains. One domain contains the .NET runtimes (mscorlib, system.dll, etc), another domain contains your .NET code, and I can't recall what the other domain's for. Check out http://my.safaribooksonline.com/9780321584090