As 64-bit machines become more common, the problems we need to solve also evolve. In this post I\u2019d like to talk about what it means for the GC and the applications\u2019 memory usage when we move from 32-bit to 64-bit.<\/FONT><\/P>\n <\/FONT><\/P>\n One big limitation of 32-bit is the virtual memory address space – as a user mode process you get 2GB, and if you use large address aware you get 3GB. A few years these seemed like giant numbers but I’ve seen as more and more people start using .NET framework, the sizes of the managed heap go up at a quite high rate. I remember when I first started working on GC (which was late 2004 I think) we were talking about hundreds of MBs of heaps – 300MB seemed like a lot. Today I am seeing managed heaps easily of GBs in size – and yes, some of them (and more and more of them) are on 64-bit – 2 or 3GB is just not enough anymore. <\/FONT><\/P>\n <\/FONT><\/P>\n And along with this, we are shifting to solving a different set of problems. In CLR 2.0 we concentrated heavily on using the VM space efficiently. We tried very hard to reduce the fragmentation on the managed heap so when you get a hold of a chunk of virtual memory you can make very efficient use of it. So people don’t see problems like they have N managed heap segments, are running out of VM, yet many of these segments are quite empty (meaning having a lot of free space on them). <\/FONT><\/P>\n <\/FONT><\/P>\n Then you switch to 64-bit. Now suddenly you don’t need to worry about VM anymore – you get plenty there. Practically unlimited for many applications (of course it\u2019s still limited \u2013 for example if you are running out physical memory to even allocate the datastructures for virtual pages then you still can\u2019t reserve those pages). What kind of differences will you see in your managed memory usage?<\/FONT><\/P>\n <\/FONT><\/P>\n First of all, your process consumes more memory – I am sure all of you are already aware of this – the pointer size is bigger – it’s doubled on 64-bit so if you don’t change anything at all, now your managed heap (which undoubtly contains references) is bigger. Of course being able to manipulate memory in QWORDs instead of DWORDs can also be beneficial \u2013our measurements show that the raw allocation speed is slightly higher on 64-bit than on 32-bit that can be attributed to this.<\/FONT><\/P>\n <\/FONT><\/P>\n There are other factors that could make your process consume more memory – for example the module size is bigger (mscorwks.dll is about 5MB on x86, 10MB on x64 and 20MB on ia64), instructions are bigger on 64-bit and what have you. <\/FONT><\/P>\n <\/FONT><\/P>\n Another thing you may notice – if you have looked at the performance counters under .NET CLR Memory – is that you are now doing a lot fewer GCs on 64-bit than what you used to see on 32-bit. <\/FONT><\/P>\n