[ACCEPTED]-Maximum Memory a .NET process can allocate-memory-management

Windows can be configured to allocate more 36 page file space on demand, or on request.
Job objects can prevent 35 the consumption of more than a certain amount 34 of memory.
Fragmentation of the heap and 33 the generational nature of it (plus the 32 need to put large stuff in the Large Object 31 Heap)

All these mean that the hard limit 30 is not much use in reality and means answering 29 the question "how much memory could 28 I theoretically allocate" is rather 27 more complex than you think.

Since it is 26 complex anyone asking that question is probably 25 trying to do something wrong and should redirect 24 their question to something more useful.

What 23 are you trying to do that would appear to 22 necessitate such a question?

"I just 21 want to know when the current memory load 20 of the process could get problematic so 19 I can take actions like freeing some items 18 of a custom cache."

Right. this is much 17 more tractable a question.

Two solutions 16 in order of complexity:

1. Make your caches use WeakReferences
   • This means that things will be freed by the system almost magically for you but you will have little control over things like the replacement policy
   • this relies on the cached data being much bigger than the key and the overhead of a weak reference
2. Register for notification of Garbage Collections
   • This lets you take control of freeing things up.
   • you rely on the system having the appropriate maximum size for the GC generations which may take a while to get to a steady state.

Points to note. Is 15 it really less expensive to maintain this massive 14 cache (going to disk by the sounds of it) than 13 to recalculate/re-request the data.
If your 12 cache exhibits poor locality between commonly/consecutively 11 requested items then much effort will be 10 spent paging data in and out. A smaller 9 cache with an effective tuned relpacement 8 policy stands a good chance of performing 7 considerably better (and with much less 6 impact on other running programs)

As an aside: In 5 .Net, no variable sized object (strings, arrays) can 4 be more than 2GB in size due to limitations 3 of the core CLR structures for memory management. (and 2 either solution above will benefit from 1 this)

Doesn't it depend on how much RAM you have?

In 29 theory, a x64 process can allocate EB's 28 (etabytes?) of RAM, I think - ie, a LOT. But 27 if you do, your machine should start paging 26 like crazy and generally die.

It was different 25 in 32 bit mode, as you couldn't allocate 24 more than 1GB of RAM in ANY process in windows 23 (yes, there are ways around it, but it's 22 not pretty). In practice, this ment about 21 7-800meg per .NET process, as .NET reserved 20 some space.

Either way, in 32 bit, the most 19 you can use is 3GB - the OS reserves 1GB 18 of virtual space for itself.

In 64 bit, it 17 should be 2^64, which is a big number, but 16 http://en.wikipedia.org/wiki/X86-64 says it's 256TB of virtual space, and 1TB 15 of REAL RAM. Either way, it's a lot more 14 than you are likely to have in your machine, so 13 it's going to hit the page file.

With a 64-bit 12 OS and a 64-bit runtime, .NET 2.0-based 11 applications can now utilize 500 times 10 more memory for data such as server-based 9 caches.

This has some good info, too http://www.theserverside.net/tt/articles/showarticle.tss?id=NET2BMNov64Bit

BTW, if 8 you are on a x64 machine (ie, x64 machine 7 + x64 OS), compiling for AnyCPU and x64 6 does the same thing - it runs in x64 mode. The 5 only difference is if you use AnyCPU vrs 4 x86:

• x64 OS/.NET, AnyCpu: x64 app
• x64 OS/.NET, x64: x64 app

• x64 OS/.NET, x32: x32 app (x64 .NET 3 framework as BOTH x32 and x64 versions of 2 the Fx installed)

• x32 OS/NET, AnyCPU: x32 1 app

• x32 OS/.NET, x64: CRASH AND BURN BABY! (actually, it just dies gracefully)
• x32 OS/.NET, x32: x32 app.