Hi,
simple answer - very hard, almost impossible, specific to each OS
version and device.
on OS5 there are following solutions
1st solution - UDMH hack - i.e. hooking into heap allocation functions +
plaing dirty tricks with memory protection. Hack needs to be enabled all
the time. Aplications get pointers directly to storage memory and the
memory protection is turned off. If it is turned off only for the part
that simulates heap this can be more safe but some applications may not
like that the pointers do not point to memory belonging to heap.
2nd solution - ROM change + reflash
ROM change means changing low level code which has MMU mappings
hardcoded (very nasty) + changing more high level code in memory and
database manager that has virtual adresses and size hardcoded too.
3rd solution - changing MMU mapping when device is running + extending
already existing heap. After that no hack is needed, original OS is
running with extended (but a bit fragmented) heap.
I don't like solution 1 since it is dangerous and I am paranoid.
Solution 2 means flashing and possibility of having nice paperweight.
Solution 3 seem to be doable but hard and specific to each device.
I'm trying to do solution 3 on my Tungsten 2.
Unfortunately the hardcoded virtual memory mapping on T2 is so bad that
heap can be easily extended from ~800Kb only to ~1.8MB because storage
addresses starts on 2MB boundary. This is still good for something.
I succeded with changing of virtual mapping - i.e. from m68k application
I can access (read/write) memory directly below heap beginning and
above original heap end. New virtual memory is mapped to same physical
memory as is allocated in storage via FtrPtrNew. There is playing with
storage memory mapping and protection so it should be safe (if the MMU
mapping are correct).
Next thing is resizing the heap (i.e let the OS know it is bigger) which
is hard. Currently I am investigating this. Any information on low
level heap structures is appreciated. I know something about chunks and
how they are linked together. I don't know where memory manager stores
information about where the heap begins.
I know there is some chunk table on heap beginning. I suppose I can
recreate simlar table on new heap beginning and link it to the existing
heap and then somehow tell the memory manager where the new heap begins.
After that I'm done.
I'm not sure whether it is possible to extend the heap after its end.
If yes then I know such heap will be fragmented because the nonmovable
allocations are on the end of old heap. Unfortunately on T2 one 4kb page
after heap end seems to be used for something (SD/MMC drive buffer? arm
stack?) Also I'm not sure what is on the beginning. There are few (4)
pages mapped to memory starting at virtual address 0. What is this?
If anyone cares about this and has plenty of free time let me know :)
Frantisek
On 26.5.2005 7:56, Luc Le Blanc wrote:
Some of my data sets require large arrays for computation and display.
Despite my best efforts to design tight structures, I eventually run out
of heap space, depending on device model. Is there a way (orthodox or
not, hack or otherwise) to dynamically raise the amount of heap space
about the OS or maker-defined value when the device still has available
RAM not used for DB storage? Before someone suggests it: changing device
is not always possible or convenient. But seeing an application choke
while there is plenty of unused RAM on the device is indeed frustrating.
--
Luc Le Blanc
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
