Showing posts with label .NET Memory Management. Show all posts
Showing posts with label .NET Memory Management. Show all posts

Sunday, April 21, 2013

.NET Book : Visual Studio 2012 and .NET 4.5 Expert Development Cookbook (Must Read)

Friends,

It is my great honor to tell you that my book has finally been released this week. If you have ever liked any of my blogs or internals, you would like this book for sure. There are lot of things to learn from the book and I can assure you that you wont be upset with this book if you buy it.

The "Visual Studio 2012 and .NET 4.5 Expert Development Cookbook" is a book that guides you through steps to ensure you enrich the best experience with the latest technology in the best amount of time possible. The book focusses to give you under the hood expertise in .NET technologies it tends to cover and adapts you the best to face common problems of these technologies. The book is divided in forms of recipes. Each of these recipes gives you clear insight of the problem and step by step process to solve the issue practically. It also addresses the advanced features associated with each of those recipes that gives you additional advantage on getting precise knowledge about the problem and its associated issues.

What you will learn from this book



  • Basic usage of Visual Studio 2012 IDE and its various components and better utilization of the tool while writing code
  • Understand memory management techniques to build better applications
  • Understand the .NET infrastructure with in-depth analysis of its internals
  • Architect solutions that leverage the full power of .NET language gems, understanding when to use what
  • Implement multithreaded / asynchronous applications using recent updates on .NET 4.5 and compare the past approaches
  • Create secure ASP.NET web based applications in .NET 4.5 with use of JQuery and HTML5 for rapid application development
  • Architect advanced .NET client applications using MVVM with WPF 4.5
  • Understand touch sensitive devices and leverage skills to develop multi-touch applications inside Windows 8

Monday, February 27, 2012

Inter-Process Communication using MemoryMappingFile

In an operating system, a Memory Mapping file are virtual storage place which has direct byte to byte correlation between the Virtual Address Space and the corresponding physical storage. So when we access the Virtual Address space via a memory mapping file we are directly communicating with the kernel space where the file is actually loaded. The portion of calculation between the physical storage and logical storage is hence avoided.

Memory Mapping files allows application to access files in the same way as memory. Generally as address between the physical storage and virtual memory address space, we cannot access the physical address directly. But using Memory Mapping Files, the process loads a specific range of address within the process address space with which the storage of memory into the file can be done by just assigning value to a dereferenced pointers. The IO operation on a MemoryMapping file is so fast that from the programmers point of view it seems to be like accessing the memory rather than actual physical storage. To increase performance memory mapping files are not actually stored to the disk file as well, but rather it will be stored automatically in background when FlushViewOfFile is executed or paging file is written. To Read more about memory mapping files, read here.

Memory Mapping file inside .NET Framework

.NET introduces a separate namespace to handle Memory Mapping files. Previously, we needed to do this using unmanaged Api's but with the introduction of managed API into the .NET framework library, it becomes very easy to handle MemoryMapping file directly from .NET library.

As memory mapping files are loaded into memory on a separate range of address space, two process can easily share the same page file instance and thus interprocess communication can be made with fast access to memory. It is recommended to back data with an actual disk file when large data is loaded into memory, so that there is no memory leak on the system when there is large memory pressure.

Saturday, February 4, 2012

Optimizing INPC Objects against memory leaks using WeakEvents

Working with WPF has always been a fun. Dealing with animation and richness in UI to its optimum level often gives you an edge to present something to your client and to ensure that your client shouts with a "WOW!". The Wow factor of applications can give you high rank in the first place, but increases expectation from the software. It is practically very hard to maintain with this expectation as time progresses. The survival of the fittest chooses one which best suits to the problem.

One of the major problems that developers face today is the memory leaks in an applications. Often the software that is built looks great but does not follow basic guidelines to ensure that the application is not memory hungry or even there are no existing memory leaks.

Note : By memory leak we mean, some portion of memory is not reclaimed by the garbage collector even though the object is not in use. 

By this way, the memory usage of the application increases at a certain extent and finally crashes with the OutOfMemoryException. To detect a memory leak there exists a large number of tools of which some are free while others are used as commercial purposes. Most of these problems can be fixed by either using Disposable pattern ( IDisposable interface) or manually de - referencing each and every object that are not in use. Sometimes, this can be also done in destructor / finalizers in .net too (but remember using destructors lose GC cycle).

Monday, September 26, 2011

Internals of .NET Objects and Use of SOS

Well, now getting deeper into the facts, lets talk about how objects are created in .NET and how type system is laid out in memory for this post in my Internals Series.  As this is going to be very deep dive post, I would recommend to read this only if you want to kill your time to know the internal details of .NET runtime and also you have considerable working experience with the CLR types and type system.


Recently I have been talking with somebody regarding the actual difference between the C++ type system and managed C# type system. I fact the CLR Type system is different from the former as any object (not a value type) is in memory contains a baggage of information when laid out in memory. This makes CLR objects considerable different from traditional C++ programs.

Classification of Types

In .NET there are mainly two kind of Types.
  1. Value Types (derived from System.ValueType)
  2. Reference  Type (derived directly from System.Object)
Even though ValueTypes are internally inherited from System.Object in its core, but CLR treats them very differently.  Indeed from your own perception the Value Types are actually allocated in stacks (occationally) while reference types are allocated in Heaps. This is to reduce the additional contension of GC heaps for Heap allocation, GC cycles, occasional call to OS for additional memory needs etc. The object that is allocated in managed Heap is called Managed Object and the pointer that is allocated in stack to refer to the actual object in heap is called Object Reference (which is sometimes called as Managed Pointer). 

Sunday, July 17, 2011

ValueType and ReferenceType : Under the Hood Part 2

Well, if you have read my previous post, you should be already clear how memory of ValueTypes and ReferenceTypes are allocated and De-allocated internally in terms of IL. Here in this post, I am going to cover some more concepts behind ValueTypes and ReferenceTypes and what exactly comprises of them.

In my previous post on the series, I have told you that any type that inherits from System.ValueTypes is stored in Stack while any type that is not inherited from System.ValueType is stored in Heap. Well, the statement is not correct totally.

Saturday, July 16, 2011

ValueTypes and ReferenceTypes : Under the Hood

In .NET, Value Type and Reference Types are forms an element of confusion between both developers and the students. Many of us take this as granted that Value Types are allocated in Thread Stack ( a 1 MB local stack created per Thread) and on each method calls the local value types are allocated in the Stack such that after the call ends, the object is deallocated. On the contrary, the reference types we know are those which are always allocated in heap (which is not always true, I will discuss later) and even though they are used as locals, and will be deallocated only after an interval by a separate Thread that is running with any .NET process (called finalizer thread) which occationally starts finding the memory blocks on Heap storage and compact and store only the reachable objects called Garbage Collector. Well, in this post, I am not going to cover the details of Garbage Collection, but rather I will focus more on Value Types and Reference Types that I know personally to clear any doubt regarding them in terms of IL constructs. So after reading the post, you will know some of the basics of IL too.

Sunday, March 13, 2011

Deal with Performance in WPF applications

Hi friends,

WPF is one of the major changes to the desktop applications in recent times. Most of us is using it in your day to day life programming. Some use for normal desktop or windows based applications while others write programs that run in browsers as Sandboxed application. The major investments of Microsoft on making silverlight to work out of browser enhanced the usage of WPF in a larger extent. But as for any other application, performance is the major issue for your application. Its not how well you structured your application, or how loose couple your UI with other layers, it is often a requirement for any software on how it acts in stressed situations.

One of such performance hits that might appear for your WPF application is over utilization of CPU. In this post, I will cover some of the general performance hiccups with WPF which you might consider unnecessary for your application or may be you want just to identify them for your application. Lets put few of the performance improvement tips for you in this post :


Monday, January 31, 2011

Internals of Exception Handling

Exceptions are runtime bugs that occur due to illegal action taken by the user. The Exception occurs whenever the object state is corrupted and which causes the program to terminate. Based on the severity of the exception we choose either to continue with the program by proper handling the code or rethrow the exception again to the parent block and eventually terminate the whole program.

In this post, I am not going to talk about how to throw/re-throw exceptions or even write the best practices on Exception handling, but I will go on with some of the hidden facts of exception handling which you might want to know and later on will involve IL to check how exceptions are generated.

The Basics

Exception handling is one of the weakest section of CLR. Even though I like most of the things that CLR brings to us, but I definitely disagree if the exception handling is one amongst it. Even the exception handling as been evolved with the system is enhanced very well recently with the introduction of Uncatchable Exceptions, RuntimeWrappedException, code contacts etc. Lets discuss some of the major enhancements to the exception system.

The .NET exception handling is made up of three sections :

  1. try : In this segment you need to write only the portion which can potentially throw errors. 
  2. catch : This section can overload based on the type of Exception and will be used to handle the exception which occurred in the Try block.
  3. finally : This block executes irrespective of try and catch. We write the clean up tasks here as it ensures to run even anything occurs. 

Friday, January 21, 2011

Internals of loops (While, For and ForEach)

Practically speaking, a loop is the primary building block of a program. We use loop to repeat a set of actions for a certain interval. Now if you think of these intervals, it could be a traversal from one number (called as start index) to another number (called as end index). Very often or probably out of 10 such loop eight times you loop a collection such that you start from 0 and loop until you point to the end of the sequence.

In C# (and VB.NET) we use while, do-while, for and foreach loop to loop through a set of instructions. In this post I will try to demonstrate the basic loops for a while and later on take on a bit about foreach loop and its requirement and finally go deep into its internals.

If you want to see all my Internal Series, you are welcome to follow the link :
Internals to .NET

Tuesday, December 7, 2010

Ways of Throwing an Exception in C#

Exception handling is very common for everyone. Exceptions are runtime errors which might be caused by some operation illegal to the application. .NET provides a good Exception Model (even though Microsoft wants to change this model) using try/catch which lets us to deal with runtime exceptions from our code.

It is stated that, you write your code that might generate an exception inside try block, write the logic which handles the exception generated within the catch block ( like logging, notifying etc.), where catch block can overload. Also you should keep in mind, it is recommended to wrap your code in try / catch only if you think you can handle the exception, if you cannot, it is better to leave apart the exception and let the caller to handle this in their own code. Lets take an example :


public void FirstCall()
{
    try
    {

        this.SecondCall();
        Console.WriteLine("After Exception");
    }
    catch (Exception ex)
    {
        this.DumpException(ex);
    }
}

So in the above code the Try/catch block is introduced to implement the code with exception handling.  I am using DumpException which writes the exception to the Console.

Download Sample Code - 30 KB


Saturday, November 6, 2010

Reflection - Slow or Fast? Demonstration with Solutions

Many of you might have heard, calling reflection APIs from your code is always slower than that of calling it directly.  Well, it is right. Some of the major Reflection methods like GetXXX (of MethodInfo, PropertyInfo, FieldInfo etc) are say 100 times slower than that of calling a Method, Property or Fields directly. In this post, I will try to cover some of the major portion of Reflection which is slower like hell than that of normal method call and also try to solve the same.


So what is Reflection for?

As I have already told you about Reflection and Code Emit and also how to build your Lamda Expression Tree, it is good to know where you would like to use Reflection. Yes... Reflection is made truly late bound approach to browse through the object hierarchy or to call methods inside the object. So if you do not know much about your object hierarchy or you have somehow found an assembly external to your application and you need to parse through the object and call its methods say, then Reflection would be the right choice for you.

So basically Reflection allows you to create plugin type of applications where you define an Interface and publish the same for your application and let others create those plugins for you to seamlessly added to your application. Fine. Then what it isn't for?

Yes basically few people try to work everything based on Reflection. Using reflection unnecessarily will let your application very costly. Say for instance,

ConstructorInfo cinfo= typeof(MyType).GetConstructor(new Type[] { typeof(int), typeof(string) });
object createdObject = cinfo.Invoke(new object[] { 10, "Abhishek" });
MyType xyz = createdObject as MyType;

Or say using
MyType typ = Activator.CreateInstance<MyType>();

Silly huh..
I saw few people to do this. They try to use everything using Reflection, may be they love the Reflection too much, or they have already created a Reflection engine right and do not want to mix up unknown types with known ones. May be they would make their code clear by calling the known types to the same module that is built up for dealing with unknown types.

Download Sample - 60 KB

Sunday, August 29, 2010

Implementation of an Observer

Hi Folks,

As few people told me to implement an observer in my last post where I just showed how to use it, here is the post where I am going to clear out confusions for you. If you have read my other post, you might already know what is an Observer and why it is required. Lets recap this a bit more.

An observer is a container which observes each element individually and notifies you when the object state is modified. The observer should contain methods that enables you to subscribe or unsubscribe individually so that when you subscribe for a  notification, it will keep on creating notification until you explicitly unsubscribe the Observer.

In .NET base class library, there are two interfaces introduced viz, IObservable and IObserver. These interfaces gives you a standard to develop Observable pattern and also recommends you to use it rather than doing it of your own. Microsoft also builds forth its Reactive Framework (I will discuss about it later) based on Observer pattern and lets us use it when Observer is required. 

In this post, I will discuss how you could use IObserver and IObservable to implement you own notifiers.


Download Sample - 33KB

Thursday, August 12, 2010

Garbage Collection Notifications in .NET 4.0

Memory management is primary for any application. From the very beginning, we have used destructors,  or deleted the allocated memory whilst using the other programming languages like C or C++.  C# on the other hand being a proprietor of .NET framework provides us a new feature so that the programmer does  not have to bother about the memory deallocation and the framework does it automatically. The basic usage is :

  1. Always leave local variable.
  2. Set class variables, events etc to null. 
This leaves us with lots of queries. When does the garbage collection executes? How does it affect the current application? Can I invoke Garbage collection when my system / application is idle ?

These questions might come to any developer who has just came to .NET environment. As for me too, I was doing the application just blindly taking it account that this might be the basic usage of .NET applications, and there might be a hidden hand for me who works for me in background. Until after few days, I got an alternative to call the Garbage collection using

GC.Collect()

But according to the documentation, GC.Collect() is a request.It is not guaranteed that the Collection process will start after calling the method and the memory is reclaim So, there is still uncertainty whether actually the Garbage Collection will occur or not.

Why GC.Collect is discouraged ? 

GC.Collect actually forces the Garbage collection to invoke its collection process out of its regular cycle. It potentially decreases the performance of the application which calls it. As GC.Collect runs in the thread on which it is called, it starts and quickly finishes the call. In such phase of GC collection, actually the memory is not been reclaimed, rather it just produces a thorough scan on objects that are out of scope. The memory ultimately freed whenever Full Garbage collection takes place.
For reference you can read Scotts blog entry.

Whats new in .NET 4.0 (or .NET 3.5 SP1)
 Well, GC is changed a bit with the introduction of .NET 4.0, so that the programmer have better flexibility on how to use GC. One of such changes is the signature of GC.Collect()

Sunday, August 8, 2010

Garbage Collection Algorithm with the use of WeakReference

We all know .NET objects deallocates memory using Garbage Collection. Garbage collection is a special process that hooks in to the object hierarchy randomly and collects all the objects that are not reachable to the application running. Let us make Garbage collection a bit clear before moving to the alternatives.

Garbage Collection Algorithm

In .NET, every object is allocated using Managed Heap. We call it managed as every object that is allocated within the .NET environment is in explicit observation of GC. When we start an application, it creates its own address space where the memory used by the application would be stored. The runtime maintains a pointer which points to the base object of the heap. Now as the objects are created, the runtime first checks whether the object can be created within the reserved space, if it can it creates the object and returns the pointer to the location, so that the application can maintain a Strong Reference to the object. I have specifically used the term Strong Reference for the object which is reachable from the application. Eventually the pointer shifts to the next base address space.

When GC strikes with the assumption that all objects are garbage, it first finds all the Strong References that are global to the application, known as Application Roots and go on object by object. As it moves from object to object, it creates a Graph of all the objects that it finds from the application Roots, such that every object in the Graph is unique. When this process is finished, the Graph will contain all the objects that are somehow reachable to the application. Now as the GC already identified the objects that are not garbage to the application, it goes on Compaction. It linearly traverses to all the objects and shifts the objects that are reachable to non reachable space which we call as Heap Compaction. As the pointers are moved during the Heap compaction, all the pointers are reevaluated again so that the application roots are pointing to the same reference again.

WeakReference as an Exception

On each GC cycle, a large number of objects are collected to release the memory pressure of the application. As I have already stated, that it finds all the objects that are somehow reachable to the Application Roots. The references that are  not collected during the Garbage Collection are called StrongReference, as by the definition of StrongReference, the objects that are reachable to the GC are called StrongReference objects.

This creates a problem. GC is indeterminate. It randomly starts deallocating memory. So say if one have to work with thousand bytes of data at a time, and after it removes the references of the object it had to rely on the time when GC strikes again and removes the reference. You can use GC.Collect to request the GC to start collecting, but this is also a request.

Now say you have to use the large object once again, and you removed all the references to the object and need to create the object again. Here comes huge memory pressure. So in such situation you have :
  1. Already removed all references of the object.
  2. Garbage collection didnt strike and removed the address allocated.
  3. You need the object again.
In such a case, even though the object still in the application memory area, you still need to create another object.  Here comes the use of WeakReference.

Download Sample Application - 27 KB

Wednesday, May 19, 2010

Design Patterns in C#

As I am doing a lot of architecture stuffs, lets discuss the very basics of designing a good architecture. To begin with this, you must start with Design patterns.

What is Design Patterns ?

Design patterns may be said as a set of probable solutions for a particular problem which is tested to work best in certain situations. In other words, Design patterns, say you have found a problem. Certainly, with the evolution of software industry, most of the others might have faced the same problem once. Design pattern shows you the best possible way to solve the recurring problem.

Uses of Design Patterns

While creating an application, we think a lot on how the software will behave in the long run. It is very hard to predict how the architecture will work for the application when the actual application is built completely. There might issues which you cant predict and may come while implementing the software. Design patterns helps you to find tested proven design paradigm. Following design pattern will prevent major issues to come in future and also helps the other architects to easily understand your code.

History of Design Patterns

When the word design pattern comes into mind, the first thing that one may think is the classical book on Design Pattern "Gangs of Four" which was published by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. In this book, it is first discussed capabilities and pitfalls of Object oriented programming, and later on it discusses about the classic Design Patterns on OOPS.

Types of Design Pattern

Design patterns can be divided into 3 categories.
  1. Creational Patterns : These patterns deals mainly with creation of objects and classes.
  2. Structural Patterns : These patterns deals with Class and Object Composition.
  3. Behavioural Patterns : These mainly deals with Class - Object communication. That means they are concerned with the communication between class and objects.
In this article, I am going to discuss few examples of these patterns.

You can Read the entire article from
http://www.dotnetfunda.com/articles/article889-design-pattern-implementation-using-csharp-.aspx

or

Thursday, October 9, 2008

Memory Management in .NET

In .NET memory is managed through the use of Managed Heaps. Generally in case of other languages, memory is managed through the Operating System directly. The program is allocated with some specific amount of memory for its use from the Raw memory allocated by the Operating system and then used up by the program. In case of .NET environment, the memory is managed through the CLR (Common Language Runtime) directly and hence we call .NET memory management as Managed Memory Management.


Allocation of Memory

Generally .NET is hosted using Host process, during debugging .NET creates a process using VSHost.exe which gives the programmer the basic debugging facilities of the IDE and also direct managed memory management of the CLR. After deploying your application, the CLR creates the process in the name of its executable and allocates memory directly through Managed Heaps.

When CLR is loaded, generally two managed heaps are allocated; one is for small objects and other for Large Objects. We generally call it as SOH (Small Object Heap) and LOH (Large Object Heap). Now when any process requests for memory, it transfers the request to CLR, it then assigns memory from these Managed Heaps based on their size. Generally, SOH is assigned for the memory request when size of the memory is less than 83 KBs( 85,000 bytes). If it is greater than this, it allocates memory from LOH. On more and more requests of memory .NET commits memory in smaller chunks.

Now let’s come to processes. Generally a process can invoke multiple threads, as multi-threading is supported in .NET directly. Now when a process creates a new thread, it creates its own stack, i.e. for the main thread .NET creates a new Stack which keeps track of all informations associated with that particular thread. It keeps informations regarding the current state of the thread, number of nested calls etc. But every thread is using the same Heap for memory. That means, Heaps are shared through all threads.

Upon request of memory from a thread say, .NET allocates its memory from the shared Heap and moves its pointer to the next address location. This is in contrast to all other programming languages like C++ in which memory is allocated in linked lists directly managed by the Operating system, and each time memory requests is made by a process, Operating system searches for the big enough block. Still .NET win32 application has the limitation of maximum 2GB memory allocation for a single process.

32 bit processors have 32 bits of address space for locating a single byte of data. This means each 2^32 unique address locations that each byte of data can locate to, means 4.2 billion unique addresses (4GB). This 4GB memory is evenly distributed into two parts, 2 GB for Kernel and 2 GB for application usage.


De- Allocation of Memory

De - allocation of memory is also different from normal Win32 applications..NET has a sophisticated mechanism to de-allocate memory called Garbage Collector. Garbage Collector creates a thread that runs throughout the runtime environment, which traces through the code running under .NET. .NET keeps track of all the accessible paths to the objects in the code through the Graph of objects it creates. The relationships between the Object and the process associated with that object are maintained through a Graph. When garbage collection is triggered it deems every object in the graph as garbage and traverses recursively to all the associated paths of the graph associated with the object looking for reachable objects. Every time the Garbage collector reaches an object, it marks the object as reachable. Now after finishing this task, garbage collector knows which objects are reachable and which aren’t. The unreachable objects are treated as Garbage to the garbage collector. Next, it releases all the unreachable objects and overwrites the reachable objects with the Unreachable ones during the garbage collection process. All unreachable objects are purged from the graph. Garbage collection is generally invoked when heap is getting exhausted or when application is exited or a process running under managed environment is killed.

Garbage collector generally doesn’t take an object as Garbage if it implements Finalize method. During the process of garbage collection, it first looks for the object finalization from metadata. If the object has implemented Finalize(), garbage collector doesn’t make this object as unreachable, but it is assigned to as Reachable and a reference of it is placed to the Finalization queue. Finalize is also handled by a separate thread called Finalizer thread which traces through the finalizer queue and calls the finalize of each of those objects and then marks for garbage collection. Thus, if an object is holding an expensive resource, the finalize should be used. But there is also a problem with this, if we use finalize method, the object may remain in memory for long even the object is unreachable. Also, Finalize method is called through a separate thread, so there is no way to invoke it manually when the object life cycle ends.

Because of this, .NET provides a more sophisticated implementation of memory management called Dispose, which could be invoked manually during object destruction. The only thing that we need is to write the code to release memory in the Dispose and call it manually and not in finalize as Finalize() delays the garbage collection process.

Cost of Finalize in your Program:

Now let us talk about the cost that you have to bear if you have implemented indeterministic approach of .NET and included Finalize in your class. To make it clear you must know how GC works in CLR:

Generation 0 object means the objects that we have declared after last garbage collection is invoked. 1st Generation objects means which is persisting for last 1 GC cycle. Likewise 2nd Generation objects and so on. Now GC does imposes 10 examinies for 0 to 1 generation objects before doing actual Garbage Collection. For 1 to 2 Generation objects it does 100 examinees before collecting.

Now lets think of Finalize, an object that implemented Finalize will remain 9 cycle more than it would actually collected. If it still not finalized, it would move to Geeration 2 and have to go through 100 examinees to be collected. Thus use of Finalize is generally very expensive in your program.

IDisposable implementation:


For Deterministic approach of resource deallocation, microsoft introduced IDisposable interface to clear up all the resources that may be expensive.

Let us take an example :

Protected virtual void Dispose(bool isDisposing)
{
if(IsDisposed) return;
if(isDisposing)
{
// Dispose all Managed Resources
}
IsDisposed = true;
GC.SuppressFinalize(this);
}

Now let us explain,
The first line indicates an if condition statement, Here I have checked if the object is already disposed or not. This is very essential, as in code one can call dispose a multiple times, we need to always check whether the object is already disposed or not. Then we did the disposing, and then made IsDisposed to true.
Now GC.SuppressFinalize will suppress the call to finalize if it is there. This is because, if the user already disposed the object and cleared up all the expensive resources using deterministic approach of deallocation, we dont need the GC to wait to call Indeterministic Finalize method during the Garbage Collection process.

For local objects, we can call dispose directly after using the object. We can also make use of Using block or try/catch block for automatic disposal of objects.

Note: In case of USING, you must remember it works only with the objects that Implements IDisposable. If you use object that dont have implemented IDisposable interface in using block, .NET will through error.

Author's new book

Abhishek authored one of the best selling book of .NET. It covers ASP.NET, WPF, Windows 8, Threading, Memory Management, Internals, Visual Studio, HTML5, JQuery and many more...
Grab it now !!!