.Net Framework

Was feeling lazy to work today. Hence, looked at .net framework programming......Some highlights of points learnt for future reference
1. .Net currently supports around 20 languages to be compiled into IL(Intermediate Language) format.
2. For shift from J2EE to dot net, c# can be a better option.
3. A simple helloworld C# code is:
class App{
public static void Main(){
System.Console.WriteLine("Hello World!");
}
}
4. To compile the above code, type "csc filename.cs". This generates the filename.exe. (for vb, use vbc and for javascript, jsc)
5. Hierarchy : Managed Executable -> CLR(JIT compilation) -> OS
6. CLR is similar to the other execution engine like JVM for J2EE. The CLR supplies memory management, type safety, code verifiability, thread management and security.
7. Important points are

• Managed Code is never interpreted

• Managed code doesn't run in virtual machine.

8. CIL(Common IL) is the high level assembly language includes instructions for advanced programming concepts as instantiating objects or calling virtual functions.
9. The CLR translates these and every other IL instruction into a native machine language instruction at runtime, and then executes the code natively.
10. Metadata describes class definitions, method signatures, parameter types and return values.
11. The exe generated out of compiling the managed code contains the metadata and the IL. We can use the IL disassemebler(ILDASM) to view the structure of the managed exe.
12. At runtime, this exe is JIT compiled by the CLR and converted into the machine language instructions.
13. Some of the benchmarck results shows dot net executed code is 2-3 times faster than the J2EE...

JIT COMPILATION
The first time that a managed executable references a class or type (such as a structure, interface, enumerated type or primitive type) the system must load the code module or managed module that implements the type. At the point of loading, the JIT compiler creates method stubs in native machine language for every member method in the newly loaded class. These stubs include nothing but a jump into a special function in the JIT compiler.

Once the stub functions are created, the system fixes up any method calls in the referencing code to point to the new stub functions. At this time no JIT compilation of the type's code has occurred. However, if a managed application references a managed type, it is likely to call methods on this type (in fact it is almost inevitable).

When one of the stub functions is called the stub causes execution to jump into the JIT compiler. The JIT compiler looks up the source code (IL and metadata) in the associated managed module, and builds native machine code for the function on the fly. Then, it replaces the stub function with a jump to the newly JIT compiled function. The next time this same method is called in source code, it will be executed full speed without any need for compilation or extra steps.

The good thing about this approach is that the system never wastes time JIT compiling methods that won't be called by this run of your application.