none
allocating memory in .net RRS feed

  • Question

  • Every array is a reference type in .NET (System.Array type) so it would be allocated on heap as all other reference types.

    from http://blog.vuscode.com/malovicn/archive/2008/01/13/net-foundations-memory-model-part-2.aspx

    Heap is been created by GC (garbage collector) using the VirtualAlloc() WinApi function as large, contiguous memory block where all the NET managed memory allocations are placed in the heap one after another.

    from http://blog.vuscode.com/malovicn/archive/2007/12/30/net-foundations-stack-and-heap.aspx

    VirtualAlloc Function
    Reserves or commits a region of pages in the virtual address space of the calling process.
    from
    http://msdn2.microsoft.com/en-us/library/aa366887.aspx

    so every reference object is allocated in virtual memory? and it goes to physical memory at first use?
    Tuesday, April 29, 2008 5:00 PM

Answers

  • Every object you allocate in your process is allocated in virtual memory.  There is no way to allocate physical memory and access it directly from user mode processes, without going through a virtual memory address (AWE included).  This includes the heap, the stack, or any other piece of memory - these are all abstractions around portions of virtual memory.

    Normally it is indeed possible for a virtual memory page to be committed to physical memory only when you need to use it.  However, memory that is handed to you by the .NET allocator is always committed.  The .NET allocator allocates virtual memory in segments (the segment size is 16MB on workstation GC and 64MB on server GC, 32-bit), and commits these segments immediately.  The operating system doesn't have to map these pages to physical memory right away, but there is nothing you need to do in order to use them.
    Tuesday, April 29, 2008 6:36 PM
  • I'm sorry, I can't reproduce your measurements.  How did you determine the amount of virtual and physical memory used before and after?  If you use the Process\Private Bytes and Process\Working Set performance counters, they are both increasing.

    Thursday, May 1, 2008 8:30 PM

All replies

  • Every object you allocate in your process is allocated in virtual memory.  There is no way to allocate physical memory and access it directly from user mode processes, without going through a virtual memory address (AWE included).  This includes the heap, the stack, or any other piece of memory - these are all abstractions around portions of virtual memory.

    Normally it is indeed possible for a virtual memory page to be committed to physical memory only when you need to use it.  However, memory that is handed to you by the .NET allocator is always committed.  The .NET allocator allocates virtual memory in segments (the segment size is 16MB on workstation GC and 64MB on server GC, 32-bit), and commits these segments immediately.  The operating system doesn't have to map these pages to physical memory right away, but there is nothing you need to do in order to use them.
    Tuesday, April 29, 2008 6:36 PM
  • thank you for your answer. i have another question: how is that possible that the same line, for example:  byte[] data = new byte[100000]; in .net under Windows Vista causes that pages containing table aren't mapped to physical memory, but in java under the same system they are?
    Thursday, May 1, 2008 3:03 PM
  • I'm sorry, I'm not sure I understand the question.  What do you mean by "pages containing table"?  What is the basis for comparison between .NET and Java?
    Thursday, May 1, 2008 7:29 PM
  • i have noticed that when i run this line: byte[] data = new byte[100000]; in java, it increases used physical memory by 100KB, when i run it in .net it increases used virtual memory by 100KB, but it doesn't increase physical memory use.
    pages containing table - so when we run it in java, pages from virtual memory
    wich contains this table goes to physical memory, but when we run this line in .net they doesn't.
    i wonder what is the cause of this difference?
    Thursday, May 1, 2008 8:18 PM
  • I'm sorry, I can't reproduce your measurements.  How did you determine the amount of virtual and physical memory used before and after?  If you use the Process\Private Bytes and Process\Working Set performance counters, they are both increasing.

    Thursday, May 1, 2008 8:30 PM
  • here i am doing it for 100MB
    i observe how physical memory and page file is used in Windows Task Manager in Performance tab.
    after i run program below in .net, the size of page file increase by 100MB,
    nothing happens after first enter, and we see increasing of used physical memory after second enter.

    Code Snippet

    using System;
    using System.Collections.Generic;
    using System.Text;
    using System.IO;

    namespace AlokacjaPamieci
    {
        class Program
        {
            static void Main(string[] args)
            {
                long rozmiar = 100000000;
                byte[] data = new byte[rozmiar];
                Console.WriteLine("allocated");
                Console.ReadLine();
                data[rozmiar - 1] = 1;
                Console.WriteLine("last element initialized");
                Console.ReadLine();
                for (int i = 0; i < rozmiar; i++)
                    data[i] = 1;
                Console.WriteLine("all elements initialized");
                Console.ReadLine();
            }
        }
    }

    Thursday, May 1, 2008 8:57 PM
  • That makes sense, the data is paged into RAM as you access it.

     

    Thursday, May 1, 2008 9:04 PM
  • but for java, it goes into RAM before first enter, after that line: byte[] data = new byte[rozmiar];
    i wonder how is that possible that in .net it first go to virtual memory, and in physical in java?
    is some kind of optimization in windows for .net?
    Thursday, May 1, 2008 9:31 PM
  • It's not a Windows optimization for .NET.  I don't know what Java does to force the data in RAM, but Windows is not dependent or optimized for .NET.

    Friday, May 2, 2008 4:43 AM
  • ok, thank you for your answers.
    Friday, May 2, 2008 9:25 AM