Bob,

I think that the random software currently running on your Palm *should*
produce the numbers that you gave.  The presumable reason is that the
developers of that software worked under the constraints presented to
them (i.e., more limited dynamic RAM area).  If they had the
availability of more virtual RAM, they _could_ have implemented the
software in a different manner.  In fact, they may have rolled their own
VM strategy in their current software products for all we know.

>However, it's not that hard to do the same sort of thing yourself.

Nobody is saying that there is brain surgery behind this--this is just
the application of some APIs to handle a given problem in a fairly
transparent way.  But, I didn't see any other postings concerning
techniques to give the appearance of more "dynamic" RAM to this list nor
did I see anything searching the archives at e-groups.  So I decided to
make a run for it.

>VMMNewHandle  is just DmNewHandle
>VMMLockHandle is MemHandleLock(storage), MemPtrNew(dynamic),
>MemCopy(storage->dynamic)
>VMMUnlockHandle is DmWrite(dynamic->storage), MemPtrFree(dynamic),
>MemHandleUnlock(storage)

This is basically how it was implemented.  Although I was using records
as opposed to just handles from DmNewHandle which has a little more
overhead because I was unaware of the applicability of DmNewHandle in
situation (which you addressed in your previous post).

>Anyway, this seems too simple given the discussion of the last couple
of
>days, so I wonder what I'm missing?

The bottom line is that what is described here in this email is the
design and implementation that I would up using after considering all
points mentioned in previous emails (page sizes, preallocation, etc.).
The reasoning behind this simple solution was that it was the most
efficient IMHO to get the job done because the majority of work is
handled by the OS, as opposed to me rolling my own stuff.

Mike


Reply via email to