is there some per-process-limit on memory in .net processes? is there any way to increase it? i keep

[Daniel]

is there some per-process-limit on memory in .net processes? is there any
way to increase it? i keep getting System.OutOfMemoryException when my box
has 8 gigs of unused memory.

 

[Doug Semler]

is there some per-process-limit on memory in .net processes? is there any
way to increase it? i keep getting System.OutOfMemoryException when my box
has 8 gigs of unused memory.

A 32 bit process can only address 2 GB. Doesn't matter how much memory you
have on your system, the limit is the process. . That being said, you
probably will only see a max 1.6 GB max allocation (32 bit) due to other
factors... and due to memory fragmentation you'll probably not be able to
allocate a block larger than what, 1GB or so?

If you want to be able to get over that limitation, you'll need to run it on
a 64 bit processor in a 64 bit process. 32 bit processes even on a 64 bit
machine still suffer the ame limitation since the process still sees
everyting '32 bits'.

--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

 

[Willy Denoyette [MVP]]

A 32 bit process can only address 2 GB. Doesn't matter how much memory
you have on your system, the limit is the process. . That being said, you
probably will only see a max 1.6 GB max allocation (32 bit) due to other
factors... and due to memory fragmentation you'll probably not be able to
allocate a block larger than what, 1GB or so?

If you want to be able to get over that limitation, you'll need to run it
on a 64 bit processor in a 64 bit process. 32 bit processes even on a 64
bit machine still suffer the ame limitation since the process still sees
everyting '32 bits'.

Not really, on 64 bit Windows the "system portion" is no longer mapped into
the process virtual address space, that means that a 32 bit process enjoys a
full 2^32 (4GB) users address space. To take advantage of this you'll have
to set the LARGEADDRESSAWARE bit in the X86 PE header file. For C# and
VB.NET this means compiling with /platform:x86 and run editbin
/LARGEADDRESSAWARE on the executable file
For C++ and C++/CLI you'll have to specify the /MACHINE:X86 and
/LARGEADDRESSAWARE linker options.
X64 and MSIL code runs in a 64 bit process so these application have access
to ~8TB of VM.
Note that, despite the larger users address space available to 32 bit
processes on 64 bit Windows, that the largest CLR object is still limited to
~2GB, allocating larger objects will throw OOM's even when running MSIL or
X64 code on 64bit Windows. Also, be aware that even with 4GB available for
32 bit code, you'll still can get OOM exceptions thrown on you, long before
you even reach this limit, this as a result of process heap fragmentation.

Willy.

 

[Doug Semler]

Not really, on 64 bit Windows the "system portion" is no longer mapped
into the process virtual address space, that means that a 32 bit process
enjoys a full 2^32 (4GB) users address space. To take advantage of this
you'll have to set the LARGEADDRESSAWARE bit in the X86 PE header file.
For C# and VB.NET this means compiling with /platform:x86 and run editbin
/LARGEADDRESSAWARE on the executable file

Sure. And on some versions of the 32 bit windows, you can also give 3GB
virtual address space if you boot with /3GB when the LARGEADDRESSAWARE bit
is set in the executable. But to me that can be just a "trick" and
depending on the application may or may not be the appropriate thing to do.
For a high transaction volume server apps (exchange, msmq, sql, etc), sure,
being able to address that extra gig or 2 increases app performance. But if
the problem is because you're trying to read an mpeg file thats 5 GB long
into memory all at once, well, that's a different story and should be
addressed at the design level...

Note that, despite the larger users address space available to 32 bit
processes on 64 bit Windows, that the largest CLR object is still limited
to ~2GB, allocating larger objects will throw OOM's even when running MSIL
or X64 code on 64bit Windows.

However I've always wondered the purpose of the Array.LongLength property
with respect to that limitation <g>

--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

 

[Willy Denoyette [MVP]]

Sure. And on some versions of the 32 bit windows, you can also give 3GB
virtual address space if you boot with /3GB when the LARGEADDRESSAWARE bit
is set in the executable. But to me that can be just a "trick" and
depending on the application may or may not be the appropriate thing to
do. For a high transaction volume server apps (exchange, msmq, sql, etc),
sure, being able to address that extra gig or 2 increases app performance.
But if the problem is because you're trying to read an mpeg file thats 5
GB long into memory all at once, well, that's a different story and should
be addressed at the design level...


However I've always wondered the purpose of the Array.LongLength property
with respect to that limitation <g>

In the current implementation, this property is nothing else than a type
cast of an int (Array.Length) to a long. Maybe we will ever see an
implementation that returns what it should, that is - the *sum* of the
Length of all elements
Note that the 2GB restriction is imposed by the CLR on all objects allocated
on the GC heap, not only on Array types.
The Array's Length property (an Int32) denotes the number of elements in the
array, without the CLR restriction, an Array could theoretically hold 16GB
if the element was a long.

Willy.