CLR & Garbage Collector

 Memory management is the main concern for any application whether application is window based or web based. In .Net, CLR has a garbage collector that executes as a part of our program and responsible for reclaiming the memory of no longer used objects. Garbage collector free the memory for objects that are no longer referenced and keeps the memory for future allocations

 

Advantages 

·       Allow us to develop an application without having worry to free memory.

·       Allocates memory for objects efficiently on the managed heap.

·       Reclaims the memory for no longer used objects and keeps the free memory for future allocations.

·       Provides memory safety by making sure that an object cannot use the content of another object. 

Generations in Managed Heap 

The managed heap is organized into three generations so that it can handle short lived and long lived objects efficiently. Garbage collector first reclaim the short lived objects that occupy a small part of the heap. 

Gen0

This is the youngest generation and contains the newly created objects. Generation 0 has short-lived objects and collected frequently. The objects that survive the Generation 0 are promoted to Generation 1.

 Example : A temporary object

 Gen1

This generation contains the longer lived objects that are promoted from generation 0. The objects that survive the Generation 1 are promoted to Generation 2. Basically this generation serves as a buffer between short-lived objects and longest-lived objects.

 Gen2

This generation contains the longest lived objects that are promoted from generation 1 and collected infrequently.

Example : An object at application level that contains static data which is available for the duration of the process

 

 

 

Garbage Collector Working Phases

 1.     Marking Phase: In this phase garbage collector finds and creates a list of all live objects.

 2.     Relocating Phase: In this phase garbage collector updates the references to the objects that will be compacted.

 3.     Compacting Phase: In this phase garbage collector reclaims the memory occupied by the dead objects and compacts the surviving objects. The compacting phase moves the surviving objects towards the older end of the memory segment

 

Memory Reclaim Process

 The objects which are not reachable from application's roots, are considered as garbage since these are not accessible by the application. In above heap objects 2,5,7,9 will be

considered as dead objects.

                       

 

After Reclaim Process

The garbage collector then remove the dead objects from the heap and live objects will move toward the older end of the memory segment

 

                

CLR

Security Manager

 Code Access Security (CAS) is the .NET Common Language Runtime (CLR) mechanism for maintaining security based on the identity of code.

 Most developers don't have to work with CAS on a daily basis because the .NET Framework libraries take care of much of the work involved in securing code.

For example, if you have a Smart Client application that runs over Internet Explorer, you will need to consider what permissions your application requires and how you are going to configure policy so that your code will run on a client machine. Or, suppose that your application defined a custom permission for a scenario not already covered by the permissions that ship with .NET. Here again you need to understand CAS policy.

 CAS is built on the following elements, among others 

·       Permissions: These are the basic rights needed to access a protected resource or execute a protected operation.

·       Permission Set: This is a set of permissions, such "full trust", "nothing", "Internet", "local intranet" and others.

·       Code Group: This is a logical grouping of code with a specified condition for membership such as LocalIntranet_zone and Internet_zone.

·       Evidence: This is assembly-related information such as application directory, publisher, URL and security zone.

·       Security Policy: This is a set of rules configured by an administrator to determine the permissions granted for a code expressed hierarchically at four levels as enterprise, machine, user and application domain.