What is up with .NET memory usage?

[Frank Rizzo]

It is common knowledge that 32-bit processes can use up to 2GB of RAM.
This has been my experience with native (vb6, c++) apps. However, .NET
apps tend to crash with Out of Memory errors whenever they approach 1.6
to 1.7 GB of RAM. Is the rest of the memory space between 1.7 GB and 2
GB is taken up by the runtime? 300mb? That cannot be since I've seen
winform apps run (not fast, but still) on systems with 128mb.

And if you set your app to be large address aware (e.g. to see up to
3gb) , it will crash at about 2.4gb to 2.6gb.

Is there a good explanation for this?

 

[Duggi]

I think memory occupied by OS and other applications should also be
considered.

The amount of memory space available depends on the above factors also.

Thanks
-Cnu.

 

[Michael Nemtsev]

Hello Frank,

there are 2 reasons
1) The memory (.net heap) is reserved by segmemts wich size is 32/64 mb
2) memory can be fragmented, so even you have 1gb of free memory you may
have no free block with the size of 32mb - only number of block less then
32, so u got this exception

---
WBR,
Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo


FR> It is common knowledge that 32-bit processes can use up to 2GB of
FR> RAM. This has been my experience with native (vb6, c++) apps.
FR> However, .NET apps tend to crash with Out of Memory errors whenever
FR> they approach 1.6 to 1.7 GB of RAM. Is the rest of the memory space
FR> between 1.7 GB and 2 GB is taken up by the runtime? 300mb? That
FR> cannot be since I've seen winform apps run (not fast, but still) on
FR> systems with 128mb.
FR>
FR> And if you set your app to be large address aware (e.g. to see up to
FR> 3gb) , it will crash at about 2.4gb to 2.6gb.
FR>
FR> Is there a good explanation for this?
FR>

 

[Willy Denoyette [MVP]]

It is common knowledge that 32-bit processes can use up to 2GB of RAM. This has been my
experience with native (vb6, c++) apps. However, .NET apps tend to crash with Out of
Memory errors whenever they approach 1.6 to 1.7 GB of RAM. Is the rest of the memory
space between 1.7 GB and 2 GB is taken up by the runtime? 300mb? That cannot be since
I've seen winform apps run (not fast, but still) on systems with 128mb.

And if you set your app to be large address aware (e.g. to see up to 3gb) , it will crash
at about 2.4gb to 2.6gb.

Is there a good explanation for this?

This has been discussed a billion times before, a regular process has 2GB of memory space
available, but this memory is/can get fragmented. That means that the largest chunk of
memory your application can allocate equals the largest block of free memory.
Now if you take a look at the Virtual Address Space at the *start* of a .NET program (but
exactly the same applies to any Win32 process) it should look something like this:

0x00000000 - 0x01xxxxxxx Reserved for your application image(s) CLR workspaces and stack
space (1MB per thread)
0x01xxxxxxx - 0x02xxxxxxx Initial GC heap (generational and LOH)
0x02xxxxxxx - 0x5xxxxxxxx Free memory (the GC heap expands into this area)
0x5xxxxxxxx - 0x6yyyyyyyy Space (fragmented) taken by a number of DLL's (like gdiplus.dll
used by Windows Forms)
0x6yyyyyyyy - 0x7xxxxxxxx Free memory (the GC heap expands into this area)
0x7xxxxxxxx - 0x7FFFFFFF Space (fragmented) taken by runtimes (CRT, CLR and system
DLL's)
----- Next is for /4GT tuned systems
0x80000000 - 0x80010000 64 KB barrier - cannot be used.
0x80010000 - 0xBFFFFFFF Free memory

So, a 2GB VAS starts with a free space of ~1.2GB + ~500MB, depending on the number of DLL's
loaded and their base load addresses.
For a 3GB "Large Address Aware" process, you have ~1.2GB + ~500MB plus an extra ~1GB free
area, but still the largest area is ~1.2GB, that means that the largest CLR object (an
array) is limited to ~1.2GB.
But there is more, each memory segment (used to load a DLL or an heap segment) must start at
a 64KB boundary. that means that the space at top of VAS (> 0x7xxxxxx) where all DLL's are
mapped is largely fragmented, the free space between the mapped dll's is in general too
small to be allocated as process heap space and will never be used as GC heap space anyway.
The same is true for the space between 0x5xxxxxxxx - 0x6yyyyyyyy, the size of this area,
highly depends on the the number of mapped DLL's their base locations, which on their turn
depend on the type of application the version of the OS it's language version and the
language version of the application.

Willy.