At 4:30 PM -0800 3/3/99, Mike Pellegrino wrote:
>Only locked handles are in the dynamic heap. Unlocked handles are
>always in storage RAM with the current incarnation of the VMM. Given
>the current Palm programming guidelines of "only lock handles for brief
>periods of time", I think that the expectation of the VMM is consistent
>with that philosophy.
Well -- yes, the expectation is consistent. But in actual reality, the
number of unlocked handles in the dynamic heap tends to be small. In
general, they dynamic heap is only used for values that are actually in
use. e.g. most apps copy records to the dynamic heap, modify them there,
then copy them back to the storage heap.
The guideline to only lock handles for brief periods really turns out to
apply more to the storage heap.
Anyway, it's easy to check this. Just grab a random device, hook it up to
the PalmDebugger (or PilotDebugger) console, and do a "hd 0" or "ht 0"
On my device, running a random 3rd party app, I get this from "ht":
Displaying Heap ID: 0000, mapped to 00001480
----------------------------------------------------------------------
Heap Summary:
flags: 8000
size: 016B80
numHandles: #40
Free Chunks: #11 (01091E bytes)
Movable Chunks: #8 (000768 bytes)
Non-Movable Chunks: #47 (005A4A bytes)
Owner 0: 015B7A bytes
Owner 2: 000E80 bytes
Owner 15: 0000D6 bytes
So on this heap there are only 768 bytes available to be paged out. (And
quite a lot of free heap.)
Running another app (a fairly intensive game) produces this:
Heap Summary:
flags: 8000
size: 016B80
numHandles: #40
Free Chunks: #12 (00D14E bytes)
Movable Chunks: #10 (000962 bytes)
Non-Movable Chunks: #48 (009020 bytes)
Owner 0: 01312A bytes
Owner 2: 0038D0 bytes
Owner 15: 0000D6 bytes
...a little less free space, a few more movable chunks.
So in either case, the VMM thing actually won't help that much.
For people writing apps from scratch, it may be handy to be able to
allocate relatively large chunks of VMM memory for use as scratch space,
and that might make it easier for the programmer to conceptualize the
design.
However, it's not that hard to do the same sort of thing yourself.
VMMNewHandle is just DmNewHandle
VMMLockHandle is MemHandleLock(storage), MemPtrNew(dynamic),
MemCopy(storage->dynamic)
VMMUnlockHandle is DmWrite(dynamic->storage), MemPtrFree(dynamic),
MemHandleUnlock(storage)
...I'll leave stuff like VMMHandleResize, VMMHandleFree, etc as an
exercise, but as you can see it's fairly straightforward.
Anyway, this seems too simple given the discussion of the last couple of
days, so I wonder what I'm missing?
--Bob
