Printable View
Hello my friends , I had gone through this forum and really was impressed to see the development related threads as well apart from the hardware related queries as well in this also I had read an article regarding the languages being used in the .NET framework and how it provides a common platform for the .Net languages to develop code in it , but I have heard that JIT compiler plays a vital role in this process , can anyone please elaborate this in brief.
Before you can run Microsoft intermediate language (MSIL) code that you had read in the thread that is specifically meant for it , it must be transformed by a .NET Framework just-in-time (JIT) compiler to local code or also called as native code , which is CPU- explicit code that works on the same system architecture as the JIT compiler. Because the common language runtime or you can say that provides a JIT compiler for each supported CPU structural design,
Programmers can code a set of MSIL that can be compiled into this JIT compiler and run on system with dissimilar structures . However, your MSIL code will execute only on a explicit operating system if it invokes platform- specific native APIs, or a platform- explicit class library. So this MSIL code which is a byte code is compiled by this Just in time compiler.
JIT compilation takes into description the information that a few code may never get invoked while execution. Rather than utilize time and memory to change all the MSIL in a manageable executable (PE) file to local code, it changes the MSIL as desired throughout execution and saves the resulting native code so that it is easy to get to for successive calls.
The loader generates and connects a stub to each of a type's functions while the type is loaded. On the first invoke to the function , the stub passes access to the JIT compiler, which changes the MSIL for that functions into native code and changes the stub to straight execution to the place of the native code. Successive calls of the JIT-compiled method carry on straight to the native code that was formerly created, dropping the time it takes to JIT-compile and execute the code.
The MSIL also called as managed code . The runtime provides another form of compilation known as install-time code generation. This code generation mode transforms MSIL to native program just as the normal JIT compiler does, but it transforms bigger units of code at a time, storing the consequential native code to apply when the assembly is consequently loaded and run. While making the use of install-time code generation, the complete assembly that is being installed is transformed into a local code or more called as native code, considering what is acknowledged about other assemblies that are previously installed. The consequential file loads and begins more faster than it would have if it were being transformed to this native code by the regular JIT option.As part of compiling managed code to native code, this code must go through a confirmation process unless an administrator has established a safety guidelines that permits code to find a way around verification. Verification scrutinizes MSIL and metadata to locate whether the code is type safe, which implies that it only accesses the memory locations it is allowed to access. Type safety assists segregate objects from each other and consequently assists protect them from involuntary or nasty corruption. It also renders guarantee that safety restrictions on code can be dependably imposed.
The runtime depends on the fact that the below given statements are true for code that is surely type safe:
- A reference to a type is sternly companionable with the type being referenced.
- Only suitably described operations are called on an object.
- Identities are what they state to be.
During the confirmation procedure, MSIL code is scrutinized in an effort to verify that the code can access memory locations and invoke methods only through appropriately described types. For assistance, code cannot permit an object's attributes to be accessed in a approach that permits memory locations to be flooded. In addition, confirmation tests code to decide whether the MSIL has been properly generated, because wrong MSIL can lead to a breach of the type security rules. The verification procedure passes a well-defined collection of type-safe program, and it passes only code that results out to be type safe. However, some type-safe program may not clear verification because of few drawbacks of the verification procedure, and a few languages, by design, do not create verifiably type-safe code. If type-safe program is necessary by safety policy and the program does not clear verification, an exception is thrown when the code is executed.