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

[Daniel]

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

[Doug Semler]

"Daniel" <so************ *******@yahoo.c omwrote in message
news:%2******** ********@TK2MSF TNGP02.phx.gbl. ..

is there some per-process-limit on memory in .net processes? is there any
way to increase it? i keep getting System.OutOfMem oryException 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]]

"Doug Semler" <do********@gma il.comwrote in message
news:eF******** *****@TK2MSFTNG P05.phx.gbl...

"Daniel" <so************ *******@yahoo.c omwrote in message
news:%2******** ********@TK2MSF TNGP02.phx.gbl. ..

>is there some per-process-limit on memory in .net processes? is there any
way to increase it? i keep getting System.OutOfMem oryException 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'.

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 LARGEADDRESSAWA RE bit in the X86 PE header file. For C# and
VB.NET this means compiling with /platform:x86 and run editbin
/LARGEADDRESSAWA RE on the executable file
For C++ and C++/CLI you'll have to specify the /MACHINE:X86 and
/LARGEADDRESSAWA RE 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]

"Willy Denoyette [MVP]" <wi************ *@telenet.bewro te in message
news:%2******** ********@TK2MSF TNGP03.phx.gbl. ..

"Doug Semler" <do********@gma il.comwrote in message
news:eF******** *****@TK2MSFTNG P05.phx.gbl...

>"Daniel" <so************ *******@yahoo.c omwrote in message
news:%2******* *********@TK2MS FTNGP02.phx.gbl ...

>>is there some per-process-limit on memory in .net processes? is there
any way to increase it? i keep getting System.OutOfMem oryException 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 must learn to proofread. <gI *meant* to say 32 bit processes still
suffer a similar limitation on x64. (but it's 4 gb not 2)

>
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 LARGEADDRESSAWA RE bit in the X86 PE header file.
For C# and VB.NET this means compiling with /platform:x86 and run editbin
/LARGEADDRESSAWA RE 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 LARGEADDRESSAWA RE 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.LongLengt h 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]]

"Doug Semler" <do********@gma il.comwrote in message
news:%2******** ********@TK2MSF TNGP02.phx.gbl. ..

"Willy Denoyette [MVP]" <wi************ *@telenet.bewro te in message
news:%2******** ********@TK2MSF TNGP03.phx.gbl. ..

>"Doug Semler" <do********@gma il.comwrote in message
news:eF******* ******@TK2MSFTN GP05.phx.gbl...

>>"Daniel" <so************ *******@yahoo.c omwrote in message
news:%2****** **********@TK2M SFTNGP02.phx.gb l...
is there some per-process-limit on memory in .net processes? is there
any way to increase it? i keep getting System.OutOfMem oryException 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 must learn to proofread. <gI *meant* to say 32 bit processes still
suffer a similar limitation on x64. (but it's 4 gb not 2)

>>
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 LARGEADDRESSAWA RE bit in the X86 PE header file.
For C# and VB.NET this means compiling with /platform:x86 and run editbin
/LARGEADDRESSAWA RE 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 LARGEADDRESSAWA RE 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.LongLengt h 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.