Friday, March 31, 2006 2:28 PM
MikeCal
Paging Dr. RAM
I get such ... colorful ... comments whenever I do a RAM entry. How could I resist doing another? I've been asked whether there's some way to use spare storage space as a way to extend the RAM on Windows Mobile devices. We'll talk about that in this entry. If the difference between "RAM" and "ROM" isn't inherently obvious to you, please read this first.
Storage isn't RAM, but...
What people would really like to do is use their storage as RAM. "I may only have 32M of RAM, but I've got a 1 Gig SD card that's mostly empty. It would be cool if I could use that SD card to run more programs." At first blush, this can't work at all. The SD card is made of NAND flash and flash is just too slow to be used as RAM.
But hard drives are also too slow to be used as RAM. Yet, the desktop system manages to extend its RAM with clever use of the hard drive. Why can't Windows Mobile do the same thing with the SD card?
Pagefiles amongst us
Here's what the desktop is doing. First, it divvies up the RAM into small chunks called "pages." (Typically a page is 4K in size.) Then, when it runs out of RAM, it finds some pages that haven't been used recently and saves them onto the hard drive. That frees up some space in RAM, which allows more programs to run. If someone needs the information that was stored on the hard drive, the system saves some other page to disk and then loads the previous one back into RAM. This is called "paging" and the place on the disk where the pages are stored is called the "pagefile."
RAM can hold code, and RAM can hold data. "Code" is the program itself and "Data" is stuff that the program generates or loads while running. For instance, your web browser gets information from the internet (Data) and stores that information in RAM. The instructions it uses to turn that web page into something a human can read (Code) are also stored in RAM.
By and large, code never changes, but data does. Code is already stored somewhere on your device. Since it doesn't change, the system can throw away pages whenever it wants to. If it needs those pages back, it can reload the originals. Data, though, is always changing. If you need to get rid of a page of data, you need to find someplace to put it. Desktop pagefiles put the data on the hard drive.
In Windows CE, we have a limited version of the desktop pagefile that we call the "PagePool." The PagePool works with Code, but not Data. But there's typically a lot more Data in RAM than Code.
Do what the desktop does!
Here's the problem. You can't put the pagefile on removable media. Apps don't expect their data to just disappear. The magic of the pagefile is that pages get archived away, but can come back at a moment's notice. If you put the pagefile on an SD card and then ejected the SD card, the pages would be gone. Apps wouldn't be able to deal with that.
The desktop puts its pagefile on the same hard drive that its code is on (c:). It knows that hard drive won't be removed. But the desktop is in a situation that's totally different than the one we're in. They've got hundreds of times more storage than RAM. So, it makes sense to use up some of that storage to extend the RAM.
The situation in Windows Mobile is different. The typical WM5 device has the same amount of internal storage space as RAM space. Previous Smartphones had more RAM than storage. And previous PocketPCs didn't even have separate storage. They used RAM instead. Pagefiles don't make any sense in those situations.
Well, if you had any foresight...
Like most development institutions, there's more stuff we'd like to do than we have time for. Any feature we didn't implement enabled us to implement a different one. Or, to look at it another way, enabling pagefiles for WM5 would have required that we cut some other feature that we did do. When you couple that with the facts that pagefiles can't go on removable media and that they don't make sense until there's a lot more storage than RAM, it's pretty clear that we shouldn't implement them yet.
But the days of enormous amounts of storage are clearly coming. Hopefully, when we get there, we'll implement a pagefile. Not that I'm promising we will, but we certainly understand the benefits.
Mike Calligaro