What is the limit for memory a .NET process or AppDomain can use?

[Max2006]

Hi,

What is the limit for memory that a .NET process or AppDomain can use?

Thank you,
Max

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Max2006 wrote:

What is the limit for memory that a .NET process or AppDomain can use?

For 32 bit Windows ther eis a limit of 2 (or 3 if so configured) GB
of virtual memory (which is what .NET sees).

For 64 bit Windows the limit may not be the sky, but it is high - higher
than what you can use.

Arne

[Max2006]

Thank you Arne for help..

Could you refer me to msdn or online resource that explain this?

Thanks again,
Max
"Arne Vajhøj" <ar**@vajhoej.d kwrote in message
news:48******** *************** @news.sunsite.d k...

Max2006 wrote:

>What is the limit for memory that a .NET process or AppDomain can use?

For 32 bit Windows ther eis a limit of 2 (or 3 if so configured) GB
of virtual memory (which is what .NET sees).

For 64 bit Windows the limit may not be the sky, but it is high - higher
than what you can use.

Arne

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Max2006 wrote:

Could you refer me to msdn or online resource that explain this?

Google finds links like:

http://blogs.msdn.com/tom/archive/20...processes.aspx
http://forums.techarena.in/showthread.php?t=933856

Arne

[Jeffrey Tan[MSFT]]

Hi Max,

.Net AppDomain or Process does not have hard-coded memory limit in
principle. So the memory limit normally lies with the underlying OS memory
manager limitation. As Arne pointed out, the modern OS uses the virtual
memory management, so all the memory usage comes from the virtual memory
space instead of physical memory. For 32bit OS, 2^32 bytes(4GB) are
available to a process. However, since the OS kernel normally uses 2GB
virtual space. There are only 2GB left for the process user-mode code. So
we may believe that the memory limit for a .Net process/AppDomain is 2GB.

Can you tell me why you want to know of the memory limitation for .Net
process/AppDomain? In .Net world, the memory is abstracted as managed
objects. The .Net developers seldom touch or deal with memory directly
unless you are using unsafe code or p/invoke COM interop. Also, in the CLR,
the .Net GC is responsible for us to free the managed objects memory and
return to managed heap.

Do you allocate memory directly for native code? If we can understand your
purpose and problem context better, we may have a better solution. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsof t.com.
=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.

[=?Utf-8?B?TXVkYXNzYXIgSGFzc2Fu?=]

I agree with TAN, that there is no hardcoded memory limit, it depends on the
RAM size and the paging memory size.

--
Regards,
Mudassar Hassan
Software Engineer
http://mudassarhassan.spaces.live.com/
""Jeffrey Tan[MSFT]"" wrote:

Hi Max,

.Net AppDomain or Process does not have hard-coded memory limit in
principle. So the memory limit normally lies with the underlying OS memory
manager limitation. As Arne pointed out, the modern OS uses the virtual
memory management, so all the memory usage comes from the virtual memory
space instead of physical memory. For 32bit OS, 2^32 bytes(4GB) are
available to a process. However, since the OS kernel normally uses 2GB
virtual space. There are only 2GB left for the process user-mode code. So
we may believe that the memory limit for a .Net process/AppDomain is 2GB.

Can you tell me why you want to know of the memory limitation for .Net
process/AppDomain? In .Net world, the memory is abstracted as managed
objects. The .Net developers seldom touch or deal with memory directly
unless you are using unsafe code or p/invoke COM interop. Also, in the CLR,
the .Net GC is responsible for us to free the managed objects memory and
return to managed heap.

Do you allocate memory directly for native code? If we can understand your
purpose and problem context better, we may have a better solution. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsof t.com.
=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.