Pages
Calender
<<  July 2010  >>
MoTuWeThFrSaSu
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678
Blogroll
    Ajander Singh , Created On 27. May 2008, 16:57

    C# supports the ability to handle events “inline” by assigning a block of code statements directly to an event, rather than building a stand-alone method to be called by the underlying delegate.


    ArgumentsToProcess => StatementsToProcessThem

    static void LambdaExpressionSyntax()
    {
    // Make a list of integers.
    List<int> list = new List<int>();
    list.AddRange(new int[] { 20, 1, 4, 8, 9, 44 });
    // Now, use a C# 2008 lambda expression.
    List<int> evenNumbers = list.FindAll(i => (i % 2) == 0);
    Console.WriteLine("Here are your even numbers:");
    foreach (int evenNumber in evenNumbers)
    {
    Console.Write("{0}\t", evenNumber);
    }
    Console.WriteLine();
    }


    Processing Arguments Within Multiple Statements

    // Now process each argument within a group of
    // code statements.
    List<int> evenNumbers = list.FindAll((i) =>
    {
    Console.WriteLine("value of i is currently: {0}", i);
    bool isEven = ((i % 2) == 0);
    return isEven;
    });




    Garbage Collection

        The .NET Framework's garbage collector manages the allocation and release of memory for your application. Each time you use the new operator to create an object, the runtime allocates memory for the object from the managed heap. As long as address space is available in the managed heap, the runtime continues to allocate space for new objects. However, memory is not infinite. Eventually the garbage collector must perform a collection in order to free some memory. The garbage collector's optimizing engine determines the best time to perform a collection, based upon the allocations being made. When the garbage collector performs a collection, it checks for objects in the managed heap that are no longer being used by the application and performs the necessary operations to reclaim their memory.

    Note

        In the .NET Framework version 1.0, the common language runtime (CLR) has a separate memory manager for the large object heap. Under some circumstances this memory manager does not return unused memory to the operating system, and in a few cases it does not make the memory available for garbage collection. This results in failure to allocate memory due to virtual address space fragmentation. In the .NET Framework versions 1.1 and 2.0, the large object heap is composed of contiguous areas of memory called heap segments, properly aligned to minimize virtual memory fragmentation. During garbage collection, the space reclaimed from large objects is consolidated and placed in a free list. Heap segments containing only free list items are freed and the memory is returned to the operating system. These changes to the large object heap have effectively eliminated memory allocation failures due to virtual address space fragmentation.


    Important
        On servers with more than 2GB of memory, it may be necessary to specify the /3GB switch in the boot.ini file to avoid apparent out-of-memory issues while memory is still available to the system.

    Automatic Memory Management
       
     Automatic memory management is one of the servicesthat the common language runtime provides during Managed Execution. The common languageruntime's garbage collector manages the allocation and release of memory for anapplication. For developers, this means that you do not have to write code to performmemory management tasks when you develop managed applications. Automatic memorymanagement can eliminate common problems, such as forgetting to free an object andcausing a memory leak, or attempting to access memory for an object that has alreadybeen freed. This section describes how the garbage collector allocates and releasesmemory. 

     

    • Allocating Memory:-
            When you initialize a new process, the runtime reserves a contiguous region of address space for the process. This reserved address space is called the managed heap. The managed heap maintains a pointer to the address where the next object in the heap will be allocated. Initially, this pointer is set to the managed heap's base address. All reference types are allocated on the managed heap. When an application creates the first reference type, memory is allocated for the type at the base address of the managed heap. When the application creates the next object, the garbage collector allocates memory for it in the address space immediately following the first object. As long as address space is available, the garbage collector continues to allocate space for new objects in this manner. Allocating memory from the managed heap is faster than unmanaged memory allocation. Because the runtime allocates memory for an object by adding a value to a pointer, it is almost as fast as allocating memory from the stack. In addition, because new objects that are allocated consecutively are stored contiguously in the managed heap, an application can access the objects very quickly.

    • Releasing Memory:-
            The garbage collector's optimizing engine determines the best time to perform a collection based on the allocations being made. When the garbage collector performs a collection, it releases the memory for objects that are no longer being used by the application. It determines which objects are no longer being used by examining the application's roots. Every application has a set of roots. Each root either refers to an object on the managed heap or is set to null. An application's roots include global and static object pointers, local variables and reference object parameters on a thread's stack, and CPU registers. The garbage collector has access to the list of active roots that the just-in-time (JIT) compiler and the runtime maintain. Using this list, it examines an application's roots, and in the process creates a graph that contains all the objects that are reachable from the roots. 
              Objects that are not in the graph are unreachable from the application's roots. The garbage collector considers unreachable objects garbage and will release the memory allocated for them. During a collection, the garbage collector examines the managed heap, looking for the blocks of address space occupied by unreachable objects. As it discovers each unreachable object, it uses a memory-copying function to compact the reachable objects in memory, freeing up the blocks of address spaces allocated to unreachable objects. Once the memory for the reachable objects has been compacted, the garbage collector makes the necessary pointer corrections so that the application's roots point to the objects in their new locations. It also positions the managed heap's pointer after the last reachable object. Note that memory is compacted only if a collection discovers a significant number of unreachable objects. If all the objects in the managed heap survive a collection, then there is no need for memory compaction. To improve performance, the runtime allocates memory for large objects in a separate heap. The garbage collector automatically releases the memory for large objects. However, to avoid moving large objects in memory, this memory is not compacted.

     



    Ajander Singh , Created On 2. May 2008, 12:06


    Download Visual Studio 2008 Professional Edition, Visual Studio Team System 2008 Team Suite and Visual Studio Team System 2008 Team Foundation Server from MSDN Evaluation Center.

    Download Visual Studio 2008