Compilation or complexity of .NET code?

Question

Q1) Why is C # initially compiled into IL, and then at runtime, JIT is executed and launched on top of the virtual machine (?). Or did this JIT execute its own machine code?

Q2) If the second is true (JIT corresponds to native machine codes), then where does .NET sandbox code work under?

Q3) Also, why is the code compiled in IL in the first place. Why not just compile your own machine code all the time? There is a tool from MS from this ngen, but why is this optional?

Answer 1

IL is JIT'd (JIT = Just In Time), compiled into native machine code as the process starts.

Using the virtual machine level allows .NET to behave consistently on different platforms (for example, int is always 32 bits regardless of whether you work on a 32-bit or 64-bit machine, this is not the case with C ++).

Compiling JIT allows you to optimize dynamically adapt to the code when you run it (for example, apply more aggressive optimizations to bits of code that are often called or use hardware instructions available on a specific machine, such as SSE2) that you can’t use with a static compiler.

Answer 2

A1) JIT is compiled into native machine code

A2) .net does not have such a term as a sandbox. Instead, there are AppDomains. And they are executed as part of the CLR (i.e., as part of the executable process).

A3) The disadvantages of NGen from Jeffrey Richter:

• NGen files may go out of sync. When the CLR loads the NGen'd file, it compares the number of characteristics of the previously compiled code and the current execution Environment. If any of the characteristics does not match, the NGen'd file cannot be used, and the regular JIT compiler is used instead.

• Performance degradation on boot (restore / bind). Assembly files are standard Windows PE files and, as such, each contains a preferred base address. Many windows developers are familiar with the problems associated with base addresses and rebooting. When compiling JIT code, these problems are not a problem because the correct references to the memory address are computed at runtime.

• Decreased performance. When compiling code, NGen cannot make as many assumptions about the runtime environment as the JIT compiler. This calls NGen.exe to create the inferior code. For example, NGen will not optimize the use of some processor instructions; it adds directions to access the static field, since the actual address of the static fields is unknown until run time. NGen inserts code to call class constructors everywhere because it does not know the order in which the code will execute and if the class constructor has already been called.

Answer 3

You can use NGEN to create your own versions of your .NET collections. This means that JIT should not do this at runtime.

.NET will be compiled first in IL and then in native, since JIT was designed to optimize IL code for the current processor in which the code runs.

.NET code compiled in IL for compatibility. Since you can create code using C #, VB.NET, etc., you need a common instruction set (IL) to compile your own JIT code. If the JIT was to know the languages, then the JIT would need to be updated when the new .NET language was released.

I'm not sure about the sandbox question, I suppose a .NET application works with 3 application domains. One domain contains the .NET runtimes (mscorlib, system.dll, etc.), the other domain contains your .NET code, and I can’t remember what the other domain is for. Check out http://my.safaribooksonline.com/9780321584090

Answer 4

1. C # is compiled into CIL (or IL) because it shares the platform with other .NET languages ​​(so you can write a DLL in C # and use it in VB.NET or F # without the hassle). The CLR will then JIT Compile the code into native machine code.

.NET can also be run on multiple platforms (Mono on * NIX and OS X). If C # is compiled into native code, it will not be so simple.

2. There is no sandbox.

3. Coverage in response to # 1

Answer 5

A1) Thus, he is an agnostic of the platform (Windows, Linux, Mac), and can also use certain optimizations for your current equipment. When he receives JIT, compiled it into machine code.

A2) The entire infrastructure (.NET platform) is the entire sandbox, so all the calls you can make through the application will go through the .NET framework.

A3) As in answer 1, it allows binary .NET to work on different platforms and perform certain optimizations on the client machine on the fly.

Answer 6

The compiled .Net code becomes IL, which is an intermediate language just like the Javas object code. Yes, you can create your own machine code using the NGen tool. NGen attaches the resulting native image to the machine, so copying the ngen'd binary to another system will not produce the expected results. Compilation of intermediate code allows you to make runtime decisions that otherwise could not (easily) be performed using a statically typed language, such as C ++, and also allows you to work with code on different hardware archetypes, because then the code becomes descriptive about what it is also describes the intent of what should happen in a bit (for example, 32 or 64) -diagnostic path, unlike machine code that only works on 32-bit systems or 64-bit systems, but not both.

In addition, NGen is optional because, as I said, it associates binary with the system, it can be useful when you need the performance of compiled machine code with the flexibility of a dynamically typed language, and you know that binary code will not go to system to which it is not attached.