Ever pondered the workings of a C# code? What is occurring behind the scenes? Let's dig deep into the history of C# code execution in this blog post, focusing on the crucial element known as CLR, which is in charge of carrying out our code.

Prior to delving into the fundamentals of CLR, let's grasp some fundamental ideas,

A controlled code: what is it?
Managed code, or just code that executes under the supervision of a runtime environment, is code that we write with a language compiler that targets a runtime.

Why Managed Code?
Managed code with a runtime environment gives a number of benefits.

• Memory Management
• Security
• Cross Platform compatibility
• Cross-language integrity
• Exception handling
• Debugging and profiling services etc.

How does it operate?
Every runtime loadable portable executable (PE) file, such as dll and exe, has metadata and a common Intermediate language (CIL) that identifies types, members, and references. These are produced by language compilers. This method is used by the runtime to find and load classes, arrange memory, and resolve method invocation. A built-in compiler will convert CIL to native code while the procedure is running. One way to sum up the managed code execution process is as follows.

1. Compiling source code to CIL by Language compiler]
2. Translating the CIL to native code during execution
3. Running the code using the metadata from the PE file with provided memory management, Type checking, and exception handling.

Fantastic We now understand what managed code is and how a runtime interacts with it. Let's get right into Core CLR. The runtime environment supplied by.net core, known as Core CLR, is in charge of managing code execution. There are several language compilers that target the Core CLR runtime, including Visual Basic, C#, Visual C++, F#, Perl, and COBOL. Let's use C# as an example to delve deeper into the CLR.

Our language compiler creates metadata and translates C# code into Common Intermediate Language (CIL), a low-level, CPU-independent set of instructions that was formerly known as Microsoft Intermediate Language (MSIL). A language compiler creates this intermediate, which CLR will then further compile into machine code. CLR receives this.

Let's now examine the function of CLR. CLR must compile CIL to native code based on the architecture of the target machine in order to carry out the instructions given in the form of CIL..NET offers two methods for this purpose.

1. Just-in-time compiler (JIT)
2. Native Image Generator

Just-in-time compiler
JIT converts the CIL to machine code during runtime on demand when the content of assembly is loaded and executed.

How it works?

• The method is executed, CLR hands over the CIL for the method to JIT
• JIT will translate the code to machine code
• The Generated machine code is cached, so the subsequent calls to the method will be handled from the cache.
• Native machine code is executed by the CPU.

Types of JIT
.net core runtime includes several types of JIT compilation strategies.

Tired Compilation
Aims to provide fast startup and High throughput. It involves compiling the methods in two tiers.

• Tier 0 – Quick JIT: Methods are initially compiled with minimal optimization to provide faster throughput
• Tier 1 – Optimized JIT: Methods that are executed frequently are recompiled with higher optimization.

Regular JIT
These are the regular JIT, Where the methods are initially compiled with higher optimization and cached.

• Pre-compilation (Ready to Run – R2R): R2R is a case of ahead-of-time compilation, where the CIL code is compiled to native code during the build time itself.
• Dynamic Profile Guided Optimization: This is a highly advanced option, where the runtime collects profiling information about the application while it runs and uses this data to optimize the code.

Native Image Generator
JIT compiler converts the CIL code to machine code when methods defined in the assembly are invoked. This will have a negative impact on the performance, and also, the code generated by the JIT compiler is bound to the process that triggered the compilation. It cannot be shared among other processes. To allow the generated machine code to be shared among multiple processes, the CLR supports ahead-of-time compilation (AOT) mode. This mode uses Ngen.exe I to convert CIL to machine code as JIT does, but slightly in a unique way.

How does Ngen.exe work?
It performs CIL to Machine code conversion before running the application. It compiles the entire assembly, one at a time, and stores the machine-generated code in Native Image Cache as a file on the disk.

Now let’s go back to the CLR, Let’s see what the other functionalities of CLR other are than converting CIL to Machine Code. Another key role of the CLR is to perform Verification of the CIL code. The CLR always examines the CIL code to make sure it is type-safe. Type safety means the code only accesses the memory locations it is authorized to do. This type of safety verification makes sure the objects are isolated from each other and it avoids any kind of corruption. CLR uses various verification steps like,

• Verifies the value assigned to the variable matches the declared types.
• Verifies the method calls using the correct number and type of the arguments.
• Validate the meta data and make sure the members are defined correctly matching their metadata, external libraries used are resolved properly.

Like these, various validations are available. Finally, the CLR does the job of executing the generated machine code. During this time CLR provides a lot of added functionalities like Garbage Collection, Thread Handling, Interoperability, etc. These we will discuss in detail in my upcoming blog.