Practical use of RAM beyond 512MB

Posted By: Sue Loh

I actually got a fourth question from Gursharan, but it is a separate topic so I’m breaking it out into a different post.  This is in reference to one of my previous blog posts.

Q4. So winCE cannot address RAM larger than 512 MB. But we can make our application use that space by using VirtualAlloc to allocate the pages. So if I P/Invoke from some managed application to use VirtualAlloc to allocte memory for my app, would Garbage collector in the .NET CF work for that “extended” memory too. I feel that the .NET CF acts dumb in this case because it only asks the base native APIs to look for locations where it can get garbage and hence would not go to that location( if it contained some garbage to be collected). So one option could be to use GC.Collect explicitly everytime. IF this whole point seems wrong, whats the actual thing then?

Using VirtualAlloc to access the RAM beyond 512MB does not really turn it over to the system in a way that it would be used for things like running managed code.  It really only gives it directly to you, and you’d have to manage it yourself.  Say, for example, you had 1024MB of RAM.  The first 512MB could be used by the system, as you know.  If you used VirtualAlloc to access the other 512MB, it would only be useful to the extent as if you had just allocated 512MB of heap using “LocalAlloc” or “malloc”.  You can use it, but you can’t easily layer anything else on top of it.  If you wrote your own heap management code, then you could allocate objects out of that memory by using your own allocate and free routines.  By overloading “operator new” in C++, and making that operator call your own alloc function, you could get C++ objects to be allocated out of that memory.  I don’t know if the .NET framework has a similar way to write your own allocator, or not.  I somewhat doubt it.  But anyway you basically end up managing that memory all yourself instead of being able to give it to the system.

Comments (6)

  1. Travis Owens says:

    While not everyone shares my view but….

    As far as I’m concerned, any Win9x based kernel is dead to me as a developer.

    The sooner people start use only NT5.x (or higher) the better. There’s just too many massive improvements to even entertain an arguement.

  2. ce_base says:

    Hi Travis — but Windows CE is not Win9x based. It is a completely separate kernel. As far as I know, the kernel doesn’t share a shred of code with Win9x or NT.


  3. Michal Wünsch says:

    Hello Sue, now I am a bit confused. For now, my concern is not how to allocate RAM beyond 512MB, but actually how to allocate RAM beyond 32MB slot. Yes, I know that it can be done via "VirtualAlloc", but how can be 512MB allocated via "malloc" or "LocalAlloc", as you wrote? As far as I understand, "malloc" as well as "LocalAlloc" utilizes process’s local heap, which should be limited to 32MB per process. Am I wrong?


  4. ce_base says:

    Hi Michal, I don’t think you can use malloc/LocalAlloc/HeapAlloc to allocate memory outside your process slot. Yes, as you suspect, those functions use the process local heap which cannot exceed the 32MB process slot. To get that much RAM you’ll have to use VirtualAlloc or CreateFileMapping.

    My post wasn’t really about heap allocations, but about how to make your device use greater than 512MB of physical memory. I hope it didn’t cause confusion. I was trying to say, you could possibly use the additional memory as a heap if you implement the heap yourself. You couldn’t use the Win32 heap functions to access it.


  5. Michal Wünsch says:

    Hi Sue, thanks for reply. That’s exactly the answer I hoped for. Actually, I had recently to modify our memory-hungry application (originally malloc-based) to move some large allocations outside the process slot (via VirtualAlloc), and now I was terrified a bit, that the work (not quite easy) was unnecessary. Sorry for misunderstanding and thank you.


  6. Gursharan says:

    Michal, I would like to add to Sue’s answer to your question. Sue is very right in saying that you can’t use win32 functions to manage that "extended" heap. So to visualize writing your own heapAlloc- ,malloc/free you can take some offset from the base RAM that the OS addresses. So, in your MyMalloc(int size) function, you instead of taking the CRT support allocate memory by your own by defining some "offset" with MyMalloc function. This offset takes your malloc function to a chunk that is in a way untouched by the system and you are its owner i nevery way. But, it requires really careful programming to clean up any garbage you produce for your system to run fine. To write your own heap management functions would not be an easy job. Because lot of issues will pop up if you want to give full functionlaity to it. Per se if 2 threads call MyMalloc(n) simultaneously, you yourself has to resolve it and Multi threaded CRT would not come to your rescue. Am I right?