Bob,
>I still have a feeling that you won't actually be able to move that
much
>out of the dynamic heap. Before you spend a lot more time on this, you
>should probably do some analysis first.
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. If a lock fails, it will most likely occur
because the dynamic heap is filled and there is not enough RAM to
allocate to hold the contents in storage RAM. So the client tries again
later.
As far as additional analysis goes, please advise. I hope that the
breadth of discussion that we have had over the last few days
illustrates that I did give this problem some considerable thought.
>Without an MMU, the pointers or locked chunks have to be located where
the
>address says they are, and you can't go moving them around. That means
the
>only candidates for VM-ing are unlocked handles. Right? Well, in
general
>there just aren't that many of them.
You are absolutely correct in that I can't go moving locked memory
around. Like the Palm OS, I don't do that. As far as there not being
many unlocked handles, that is indicative of some potentially unfriendly
Palm code. The reason is that as long as that chunk is locked, the Palm
memory manager can't move it. This affects the compaction process quite
a bit as you're aware.
>Which means that what you're really trying to do boils down to
combining a
>copy to a new dynamic chunk with a call to MemHandleLock when accessing
>storage chunks. Then you can freely read/write these things, and when
you
>unlock them they get copied back to the storage heap in one DmWrite.
You are absolutely correct. What I'm doing here isn't revolutionary at
all, nor is it intended to be. But, this will work with all Palm
hardware and is not OS bound.
>...but that's not really all that difficult to do with current APIs.
In
>fact, you could probably even do it with a couple of #defines.
Well, yes and no.
It _is_ sort of difficult to do with the current APIs because storage
RAM is hardware protected. You can't just assign a value to some
dereferenced storage RAM pointer. That point alone is what spawned
VMM (check back about 2 weeks ago to a posting by Jason Dawes which got
me started on VMM).
But, the VMM itself _wasn't_ difficult to construct. It is all fairly
straightforward when you look at it. I wrote most of it in the period
of about 40 hours including research. But if I save someone else from
writing those 2000 or so lines of source which comprise VMM, why
wouldn't you want it? It's not like I'm trying to make any money off
this--I plan to release this all as freeware.
In my header file, I do provide #defines for the MemX APIs so you could
have potentially little code to edit.
>Or am I missing something? (It's possible that I am -- from mid-Friday
>last week until Tuesday morning I was accidently unsubscribed from this
>list, so I missed the middle of this discussion.)
Nope. You interpreted everything exactly as it is.
Thanks Bob for the goods,
Mike
