Wednesday, August 12, 2009

:: Microsoft Intermediate Language ::

Microsoft Intermediate Language (MSIL)
Introduction

MSIL stands for Microsoft Intermediate Language, similar to that of Java Byte code that is formed when you compile a Source Code. The main purpose of this Intermediate code formation is to have a platform independent code. That is once MSIL/Java Byte Code is available you can run on any platform provided appropriate run time environments are installed on the specific platform you wish to run. JVM in case of Java and CLR in case of .NET

The ILDasm (Intermediate Language Disassembler) program that ships with the .NET Framework SDK (You can find it in C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin\ildasm.exe) allows the user to see MSIL code in human-readable format. By using this utility, we can open any .NET executable file (EXE or DLL) and see MSIL code.

Just go to the path and click on "ildasm.exe" file and you will see a window which is shown below



Then you can open the .NET executable file by going to "File menu and click on Open link". In the open wizard select the dll that you want to view. Here i opened PringString.exe file and then the above window will look like as shown below.



Then you can manifest of the file by clicking on the MANIFEST and which is shown in below image.



You can view function by clicking on function name and is shown in the below image.



The ILAsm program (Intermediate Language Assembler) generates an executable file from the MSIL language. We can find this program in the WINNT\Microsoft.NET\Framework\vn.nn.nn directory.

Learning MSIL

Learning MSIL gives a user the chance to understand some things that are hidden from a programmer working with C# or VB.NET. Knowing MSIL gives more power to a .NET programmer. We never need to write programs in MSIL directly, but in some difficult cases it is very useful to open the MSIL code in ILDasm and see how things are done.

All operations in MSIL are executed on the stack. When a function is called, its parameters and local variables are allocated on the stack. Function code starting from this stack state may push some values onto the stack, make operations with these values, and pop values from the stack.
Execution of both MSIL commands and functions is done in three steps:
  1. Push command operands or function parameters onto the stack.
  2. Execute the MSIL command or call function. The command or function pops their operands (parameters) from the stack and pushes onto the stack result (return value).
  3. Read result from the stack.

Steps 1 and 3 are optional. For example, the void function doesn't push a return value to the stack.

The stack contains objects of value types and references to objects of reference type. Reference type objects are kept in the heap.

MSIL commands used to push values onto the stack are called ld... (load). Commands used to pop values from the stack are called st... (store), because values are stored in variables. Therefore, we will call the push operation loading and the pop operation storing.

Sample Program

.assembly PrintString {}

/* Console.WriteLine("Hello, World)"*/

.method static public void main() il managed

{ .entrypoint // this function is application entry point
.maxstack 8

// *****************************************************

// Console.WriteLine("Hello, World)";

// *****************************************************

ldstr "Hello, World" // load string onto stack

// Call static System.Console.Writeline function

// (function pops string from the stack)

call void [mscorlib]System.Console::WriteLine(class System.String)

// *****************************************************************

ldstr "Press Enter to continue"

call void [mscorlib]System.Console::WriteLine(class System.String)

// Call the System.Console.Read function

call int32 [mscorlib]System.Console::Read()

// The pop instruction removes the top element from the stack.

// (remove number returned by Read() function)

pop

// *****************************************************************
ret

}

Save this file as PrintString.il on your desktop. "il" is the extension of the intermediate language file.

Then go to VS command prompt from "Start/Programs/Visual Studio .Net 2003/Visual Studio .Net tool/Visual Studio .Net 2003 Command Prompt". Then point to your desktop from the command prompt and execute your PrintString.il file by typing the following command.

-- ilasm printstring.il

Then a PrintString.exe file is created on the desktop. Clicking on the .exe file we can see the output of the program that we have written. The same .exe i opened with the ILDASM for viewing the code in the begining.

Even we can view the IL code of the .Net compatible file by tying following command in the command prompt of Visual Studio.

-- ildasm printstring.exe

By pressing the enter key on keyboard will will see the window shown in the second image above. So this way is very easy than the above one.

Tuesday, August 11, 2009

-:: Garbage Collection In .Net ::-

Garbage Collection In .NET

Garbage Collection is a technique introduced in Microsoft .NET that manages memory automatically. This article discusses the concepts of Garbage Collection and the strategies adopted by Microsoft .NET for handling managed memory efficiently. It also discusses the methods and properties of the System. GC class, the class that is responsible for controlling the garbage collector in the .NET environment.

What is Garbage Collection?

The Common Language Runtime (CLR) requires that you create objects in the managed heap, but you do not have to bother with cleaning up the memory once the object goes out of the scope or is no longer needed. This is unlike the strategies adopted in programming languages like C and C++ where you needed to cleanup the heap memory explicitly using a free function of C and delete operator of C++. Garbage collection refers to the strategy adapted by Microsoft .NET to free unused objects or objects that go out of the scope automatically.

A "garbage" object is one that is no longer needed, is unreachable from the root or goes out of the scope in which it is created. Microsoft .NET uses the information in the metadata to trace the object graph and detect the objects that need to be garbage collected. Objects that are not reachable from the root are referred to as garbage objects and are marked for garbage collection. It is to be noted here that there is a time gap between the time when an object is identified as garbage and the time when the object is actually collected. It is also to be noted that objects in the managed heap are stored in sequential memory locations. This is unlike C and C++ and makes allocation and de-allocation of objects faster.

About Garbage Collection:

Every program uses the resources like - memory buffers, network connections, database resources and so on. To use these resources memory must be allocated to represent the type.

Steps required to access the resource:

  1. Allocate the memory for the type the represents the resource.
  2. Initialize the memory to set initial state of the resource for making the resource available to use.
  3. Now use the resource by the instance of the resource.
  4. Tear down the state of the resource for clean up.
  5. Free the memory by some mechanism.

The Garbage Collector of .Net will do the above steps automatically. So the developer need not to write any code or concentration on allocating memory to the resources and when to free the memory. .Net CLR has to allocate all the resource from mamaged heap. You never free the objects from managed heap and they will be automatically freed from the heap when those objects are not needed by the application.

Memory is not infinate. The GC must perform the task of freeing the memory and Garbage Collectors Optimized Engine will determines the best time for collection based on the allocation being made.

When GC performs the collection, It checks the heap for the objects which are not needed by the application and performs necessary actions to reclaim the memory.

However for automatic memory management, the garbage collector has to know the location of the roots i.e. it should know when an object is no longer in use by the application. This knowledge is made available to the GC in .NET by the inclusion of a concept know as metadata. Every data type used in .NET software includes metadata that describes it. With the help of metadata, the CLR knows the layout of each of the objects in memory, which helps the Garbage Collector in the compaction phase of Garbage collection. Without this knowledge the Garbage Collector wouldn't know where one object instance ends and the next begins.

Garbage Collection Algorithm:

Application Roots:

Every application has a set of roots. Roots identify storage locations, which refer to objects on the managed heap or to objects that are set to null.
For example:

  • All the global and static object pointers in an application.
  • Any local variable/parameter object pointers on a thread's stack.
  • Any CPU registers containing pointers to objects in the managed heap.
  • Pointers to the objects from Freachable queue
  • The list of active roots is maintained by the just-in-time (JIT) compiler and common language runtime, and is made accessible to the garbage collector's algorithm.

Implementation:

The most commonly used strategy involves the mark and compact algorithm. This occurs in two phases, Mark and Compact.

Mark:

When the garbage collector starts running, it makes the assumption that all objects in the heap are garbage. In other words, it assumes that none of the application's roots refer to any objects in the heap.
The following steps are included in Phase I:

  • The GC identifies live object references or application roots.
  • It starts walking the roots and building a graph of all objects reachable from the roots.
  • If the GC attempts to add an object already present in the graph, then it stops walking down that path. This serves two purposes. First, it helps performance significantly since it doesn't walk through a set of objects more than once. Second, it prevents infinite loops should you have any circular linked lists of objects. Thus cycles are handles properly.

Once all the roots have been checked, the garbage collector's graph contains the set of all objects that are somehow reachable from the application's roots and any objects that are not in the graph are not accessible by the application, and are therefore considered garbage.

Compact:

Move all the live objects to the bottom of the heap, leaving free space at the top.
Phase II includes the following steps:

  • The garbage collector now walks through the heap linearly, looking for contiguous blocks of garbage objects (now considered free space).
  • The garbage collector then shifts the non-garbage objects down in memory, removing all of the gaps in the heap.
  • Moving the objects in memory invalidates all pointers to the objects. So the garbage collector modifies the application's roots so that the pointers point to the objects' new locations. In addition, if any object contains a pointer to another object, the garbage collector is responsible for correcting these pointers as well.

After all the garbage has been identified, all the non-garbage has been compacted, and all the non-garbage pointers have been fixed-up, a pointer is positioned just after the last non-garbage object to indicate the position where the next object can be added.

Finalization:

.NET Framework's garbage collection implicitly keeps track of the lifetime of the objects that an application creates, but fails when it comes to the unmanaged resources (i.e. a file, a window or a network connection) that objects encapsulate.

The unmanaged resources must be explicitly released once the application has finished using them. .NET Framework provides the Object.Finalize method: a method that the garbage collector must run on the object to clean up its unmanaged resources, prior to reclaiming the memory used up by the object. Since Finalize method does nothing, by default, this method must be overridden if explicit cleanup is required.

It would not be surprising if you will consider Finalize just another name for destructors in C++. Though, both have been assigned the responsibility of freeing the resources used by the objects, they have very different semantics. In C++, destructors are executed immediately when the object goes out of scope whereas a finalize method is called once when Garbage collection gets around to cleaning up an object.

The potential existence of finalizers complicates the job of garbage collection in .NET by adding some extra steps before freeing an object.

Whenever a new object, having a Finalize method, is allocated on the heap a pointer to the object is placed in an internal data structure called Finalization queue. When an object is not reachable, the garbage collector considers the object garbage. The garbage collector scans the finalization queue looking for pointers to these objects. When a pointer is found, the pointer is removed from the finalization queue and appended to another internal data structure called Freachable queue, making the object no longer a part of the garbage. At this point, the garbage collector has finished identifying garbage. The garbage collector compacts the reclaimable memory and the special runtime thread empties the freachable queue, executing each object's Finalize method.

The next time the garbage collector is invoked, it sees that the finalized objects are truly garbage and the memory for those objects is then, simply freed.

Thus when an object requires finalization, it dies, then lives (resurrects) and finally dies again. It is recommended to avoid using Finalize method, unless required. Finalize methods increase memory pressure by not letting the memory and the resources used by that object to be released, until two garbage collections. Since you do not have control on the order in which the finalize methods are executed, it may lead to unpredictable results.

Limits of the Garbage Collection:

Unused objects that are still referenced:

The biggest limitation of the garbage collector in .NET is a subtle one: while it is said as being able to detect and remove unused objects, it actually finds unreferenced objects. This is an important distinction: an object might never be referred to by a program ever again; but, while there is some path from it leading to an object that might still be used, it will never be released from memory. This leads to memory leaks; in .NET these occur when an object that will not be used again remains referenced.

Fragmentation of the heap:

A less widely known limitation in .NET is that of the large object heap. Objects that become part of this heap are never moved by the runtime, and this can lead to a program running out of memory prematurely. When some objects live longer than others, this causes the heap to form holes where objects used to be - this is known as fragmentation. The problem occurs when the program asks for a large block of memory but the heap has become so fragmented that there is no single region of memory big enough to accommodate it. A memory profiler can estimate the largest object that can be allocated by a program: if this is declining then this is likely to be the cause. An OutOfMemoryException caused by fragmentation will typically happen when the program apparently has a lot of free memory - on a 32-bit system, processes should be able to use at least 1.5Gb, but failures due to fragmentation will often start to occur before it is using that much memory.

The System.GC class

The System.GC class represents the garbage collector and contains many of methods and properties that are described in this section.

GC.Collect Method

This method is used to force a garbage collection of all the generations. It can also force a garbage collection of a particular generation passed to it as a parameter. The signatures of the overloaded Collect methods are:

public static void Collect();
public static void Collect(Integer int);

GC.GetTotalMemory Method

This method returns the total number of bytes that is allocated in the managed memory. This method accepts a boolean parameter. If the parameter is true, it indicates that it should wait for the garbage collector to finish.

GC.KeepAlive Method

This method extends the life time of an object passed to it as a parameter. The signature of this method is as follows:
public static void KeepAlive(object objToKeepAlive);

GC.ReRegisterForFinalize Method

This method re-registers an object for finalization, i.e., makes an object eligible for finalization. The method signature is as follows:
public static void ReRegisterForFinalize(objectobjToRegister);

GC.SupressFinalize Method

This method suppresses the finalization on an object. The prototype of this method is:
public static void SupressFinalize(object obj);

GC.GetGeneration Method

This method returns the current generation of an object or the same of the target of the weak reference. The signature of this overloaded method is:

System.GC.GetGeneration(object obj);
System.GC.GetGeneration(WeakReferenceweakReference);

GC.MaxGeneration Property

This property returns the maximum number of generations available.

GC.WaitForPendingFinalizers Method

This method blocks the current thread till the execution of all the pending finalizers is over. The signature of this method is:
public static void WaitForPendingFinalizers();

Microsoft Enterprise Library

Microsoft Enterprise Library

The Microsoft Enterprise Library is a collection of reusable software components (application blocks) designed to assist software developers with common enterprise development cross-cutting concerns (such as logging, validation, data access, exception handling, and many others). Application blocks are a type of guidance; they are provided as source code, test cases, and documentation that can be used "as is," extended, or modified by developers to use on complex, enterprise-level line-of-business development projects.
Goals for Enterprise Library
Enterprise Library is a collection of application blocks intended for use by developers who build complex, enterprise-level applications.

Enterprise Library is used when building applications that are typically to be deployed widely and to interoperate with other applications and systems. In addition, they generally have strict security, reliability, and performance requirements.

The goals of Enterprise Library are the following:
  1. Consistency. All Enterprise Library application blocks feature consistent design patterns and implementation approaches.
  2. Extensibility. All application blocks include defined extensibility points that allow developers to customize the behavior of the application blocks by adding their own code.
  3. Ease of use. Enterprise Library offers numerous usability improvements, including a graphical configuration tool, a simpler installation procedure, and clearer and more complete documentation and samples.
  4. Integration. Enterprise Library application blocks are designed to work well together or individually.

Community

The Enterprise Library has a thriving online community.
On this community site, you can post questions, provide feedback, or connect with other users for sharing ideas. Community members can also help Microsoft plan future releases of the Enterprise Library and/or related guidance, and download additional content such as extensions and training material.

Benefits

  • Improved Productivity: Each of the Application Blocks provides several interfaces meant to satisfy common application concerns.
  • Configuration Driven Design: Many technical decisions about the application behaviour can be delayed until configuration time of the application. For instance, if an application does not properly handle an exception, instead of adding another exception handler to the code, an administrator can configure an additional exception handling policy.
  • Improved Testability: Many application areas can be reconfigured to improve testing of the application in isolation.

Application Blocks

The Application Blocks in Enterprise Library are designed to be as agnostic as possible to the application architecture, for example the Logging Application Block may be used equally in a web, smart client or service-oriented application. The patterns and practices team also produces more specialized Application Blocks that are not included in Enterprise Library, such as the User Interface Process Application Block, Aggregator Application Block, Updater Application Block and the Composite UI Application Block.
The patterns and practices team produces a number of other deliverables that leverage Enterprise Library Application Blocks. These include the Web Service Software Factory and Smart Client Software Factory.

Utilities

In addition to the Application Blocks, the standard Microsoft distribution of the Enterprise library includes:

  • Configuration Console: to visually add an Application Block to an application's configuration.
  • Security Database Console: to add roles, profiles and authorization rules to support the Security Application Block.

History

There have been several versions of the Microsoft Enterprise Library:

  • Enterprise Library 1.0 (January 2005) - Deprecated
  • Enterprise Library 1.1 (June 2005) - Deprecated
  • Enterprise Library 2.0 (January 2006) - Active/Retired
  • Enterprise Library 3.0 (April 2007) - Deprecated \
  • Enterprise Library 3.1 (May 2007) - Active
  • Enterprise Library 4.0 (May 2008) - Active
  • Enterprise Library 4.1 (October 2008) - Current Enterprise Library 5.0 (early 2010) - Next in Development

Version 1.1

Two releases of Enterprise Library were released for .NET Framework 1.1. The first was released in January 2005, followed by a minor maintenance release in June 2005. The .NET 1.1 releases of Enterprise Library contained the following Application Blocks:

  • Caching
  • Configuration
  • Cryptography
  • Data Access
  • Exception Handling
  • Logging and Instrumentation Security

Version 2.0

In January 2006, a new version of Enterprise Library was released that targeted .NET Framework 2.0. The most significant change in this release was that the Configuration Application Block was removed, and the blocks were updated to use .NET's improved System.Configuration capabilities. This release also included significant improvements to the Logging Application Block, and much of the Security Application Block was removed due to similar capabilities provided in .NET Framework 2.0. The .NET 2.0 release of Enterprise Library contained the following Application Blocks:

  • Caching
  • Data Access
  • Cryptography
  • Exception Handling
  • Logging Security

Version 3.0

In April 2007, Enterprise Library 3.0 was released. It contains new Application Blocks, a new Application Block Software factory designed to simplify the development of new Application Blocks and extensions, and new features providing better integration with .NET Framework 3.0. The 3.0 release of Enterprise Library contains the following Application Blocks:

  • Caching
  • Data Access
  • Cryptography
  • Exception Handling
  • Logging
  • Policy Injection
  • Security
  • Validation

Version 3.1

In May 2007, Enterprise Library 3.1 was released with minor enhancements to the Validation and Policy Injection Application Blocks.

Version 4.0

This release of Enterprise Library includes the following:

  • Integration with the Unity Application Block
  • Windows Management Instrumentation (WMI) 2.0 support and improved instrumentation
  • Performance improvements (particularly, in the Logging Application Block)
  • Pluggable Cache Managers
  • Visual Studio 2008 support
  • Bug fixes

Version 4.1

This release of Enterprise Library is a service release that includes the following:

  • Unity interception mechanism and integration of the Policy Injection Application Block with the Unity Application Block
  • Added support for generics in the Unity Application Block
  • Added support for arrays in the Unity Application Block
  • Performance improvements
  • Usability improvements to the configuration tool
  • Visual Studio 2008 Service Pack 1 support
  • Bug fixes

Note: Existing public APIs (v3.1) are still supported.
The Application Block Software Factory and the Strong Naming Guidance Package are not included in this release but are available as a separate download. Thus, there is no longer a dependency on Guidance Automation Extensions (GAX).
For the detailed list of all changes, see About This Release of Enterprise Library.

Version 5.0

This is the next release that the patterns & practices team is planning now. See tentative backlog posted by Grigori Melnik, EntLib Product Owner.

Download:

You can download the libraries from the below link

http://msdn.microsoft.com/en-us/library/cc467894.aspx