Handle vs. Pointer

What's a handle, what's a pointer, and what's the difference?

There are two strategies for managing memory in computers: direct physical memory access and "virtual memory". All modern PC OSes use virtual memory. This requires a special circuit called a Memory Management Unit (MMU). The key thing an MMU does is decouples the memory addresses a program sees from the physical memory addresses. For example, the MMU might be set up so that physical address 0x12345678 is accessed via virtual address 0xF7D3798E. This lets the OS move data around in physical memory to suit its needs, swap it out to disk if physical memory is needed for other tasks, or consolidate several pieces of disparate physical memory into one contiguous virtual memory block.

The Motorola Dragonball processor that current Palm and compatible units use does not have an MMU. Without an MMU or something similar, memory gets fragmented just like a hard disk: you end up with lots of memory technically free, but most of it's in blocks too small to be individually useful. Either of the first or the third operations above will eliminate this problem, but without an MMU, the Palm has to choose a different strategy for avoiding fragmentation.

The Palm OS creators fixed this dilemma with the "handle" mechanism. A handle is like a virtual address in a virtual memory system: it doesn't refer to a physical location directly, but instead is mapped through a table to find the actual physical memory location. When a program is ready to access a piece of memory through a handle, it "locks" it. This asks the OS to look up the physical memory location and return it; in some computer languages, this physical address value is called a "pointer". As long as a handle is locked, the OS won't move the data it refers to, since now the program "knows" the physical location of the data. When a program is finished accessing that memory, it should unlock the pointer. This tells the OS that it is free to move that block of memory if it needs to.

A typical use of handles is in accessing Palm databases. The database access functions usually return a handle to the resource. To use the data, you lock the handle to get a pointer. Then when you're done accessing the data, you unlock the handle so the OS's memory manager can defragment that bit of memory if need be.

The Palm OS defragments memory when it can't find free memory and when you do a soft reset. You can also call a function to make it defragment memory immediately. Normally you don't have to ask it to defragment memory, which is good because it takes a long time. This is the main reason your Palm takes a minute or so to come up when you reset it: it's defragmenting memory.

You should always unlock a handle as soon as you can. Also, never use a pointer value after you've unlocked the corresponding handle. The OS can move the memory that the pointer refers to, but if the OS has moved different data into that physical memory location, your program will become confused and perhaps corrupt some unrelated piece of data. This is another consequence of not having an MMU: the Palm has no memory protection. If your program goes randomly writing through memory, you won't get a blue screen or a GPF or a core dump. You will just write over precious data and the OS can't stop you. (This is not strictly true, but only because the Dragonball processor has limits on the allowable alignment of memory accesses. Truly random reads and writes tend to violate these rules, so you get a "bus error".)

You can find out all about the memory manager in the Reference book of the PalmOSSDKDocumentation? set.

Today: Sep 10, 2010