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.