Some basic facts of inner workings in .Net
- The SOS debugger extension was introduced with .Net 1.0. It is used to find out complex problems in .Net code. It was initially called STRIKE by the Microsoft Development team. As it matured it was then called SOS (Son Of Strike).
- Are there any other CLI Compliant Implementation besides CLR? The answer is YES. The one being MONO project (sponsored by Novell). Additionally Microsoft has released Shared Source Common Language Infrastructure (2.0) also known as Rotar Project.
- To increase reliability of code, code isolation is needed. Windows implement isolation through the notion of process. .Net takes it one step further by by introducing another logical isolation layer called Application Domain. So the question arises, why not use multiple processes instead of application domain? Well, the answer is constructing and managing the process throughout its lifetime is an expensive operation. by using logical notion of application domains, the expense associated with creating and managing the isolation layers goes down tremendously.
- There are 2 type of assemblies, Private and Shared. The later is stored in GAC and is used by different applications. An assembly is identified by the following key components :
- Assembly Name
- Culture
- Version
- Public Key
- Processor architecture
- There are 2 different types of heap managers in windows, which utilizes the virtual memory manager to manage memory. These are :
- [NTDLL] Heap Manager :This is used in user applications
- [MSCORWKS] CLR Heap Manager : mostly used by .Net applications.
- As far as CLR Heap Manager is concerned, it has one heap per processor
- Are there any other type of CLR heaps ? Yes, the JIT compiler translates IL to machine code using its own heap. The CLR loader utilizes its own heap.
- The CLR GC assumes that everything is garbage unless otherwise told. Besides this it implements a reference tracking scheme to identify live objects in the system. The GC attempts to collect short lived objects more often than long lived objects. So young objects are placed in generation 0 and old objects are placed in generation 1 or 2. So as an object grows older it is promoted to the next generation and up.
- The GC continously fine tunes itself. GC can be manually triggered with GC.Collect. Although using GC.Collect should be used only if its needed, as it can wreck havoc on the GC's fine tuning algorithm.
- The GC doesn't implement the logic of which object are still being referenced, rather the CLR has some other components (that have far more knowledge about the lifetime of an object) that helps the GC with this. One of this component is the JIT compiler, which maintains the references of an object in a table
- Finalization : A finalizer can be compared to destructor in C++. the finalize method gets translated to a function called Finalize. The GC treats these objects differently. To keep a tab on which objects have finalizers, the GC maintains a seperate queue called finalization queue. Objects that are created by managed code and have finalization in it are automatically placed in the finalization queue on creation. When an object with a finalizer becomes rootless, the GC places the object in a different queue called f-reachable queue. The .Net process contains special thread called finalization thread that wakes up on request of GC and checks the state of f-reachable queue. It then picks object from this queue and executes the finalize method.
- Why not execute the finalize method as part of GC? because the finalize method contains managed code and during GC, the managed code threads are suspended. The finalizer runs outside the boundary of the GC.
- How is memory reclaimed post-GC ? The GC compacts all live objects so that they stay close to each otherand coalesces any free blocks on the managed heap into a larger block that is located after the last live object.
- NOTE : In case of LOH (Large Object Heap) the GC doesn't compact live objects although it does coalesce of adjacent free blocks
- Mutex : It is a kernel mode synchronization construct that can be used to synchronize threads within a process or across multiple processes.
- Semaphore : It is a kernel mode synchronization object. It is similar to mutex however it employs resource counting, where in it allows X number of threads to access the resource.
- Monitor: It is a construct that allows access to an object and creating lock on it, there by not allowing other threads to obtain access until the owning thread explicitly leaves the monitor. It has 2 static methods : Monitor.Enter and Monitor.Exit
- ReaderWriterLock (Slim) : The Monitor suffers in performance, if there are more reads and less writes. To address this issue, we could use ReaderWriterLock