Feature Memory

[zhamilton1]

I have done alot of testing on the Feature memory and for anyone who is having problems with dynamic memory space read on...

Feature memory is a feature that was added in OS 3.1
It allowed to allocate storage space and put the pointer in a specified feature slot. Each feature slot is identified by a feature ID which is 16bit (65,535 slots).

In PalmOS 3.5 you can allocate above 64KB. This is useful for allocating large amounts of data like off-screen windows on the new OS5 devices where the display is 320x320. This requires over 100KB which cannot be allocated on dynamic memory.

Reading speed is as fast as dynamic memory since it uses a direct pointer to the storage space. However you need to use DmWrite to write information to the space. This means that write speed is just as slow as writing to a record. However if the contents do not change much this is not a problem.

Feature memory lasts untill the device is reset. This means that if you need to store information that needs to be accessed quickly but in short bursts for example a launcher, then feature memory is the way to go since it does not take up dynamic memory and therefore you can use as much of the space that you want without interfering with other applications.

Each feature ID is asigned to a CreatorID. The CreatorID is a four letter char that describes the application such as 'tEXT'.

All this information is documented in the PalmOS Docs however I have discovered a way to allocate/destroy memory using pointers without having to store feature IDs.

Choose one feature ID that will be used for memory allocations. I generally use Feature ID 0. Then when you want to allocate new memory call FtrMemNew with the feature ID 0. Take the pointer and put it somewhere. Then call FtrUnregister and not FtrMemFree. Why? Because then it does not destroy the memory but frees the ID 0. That way next time you allocate just do the same thing and it will give you some more memory space.

To free a pointer call FtrSet and set the value of ID 0 to the pointer and then call FtrPtrFree. This will free the memory and unregister the ID 0 for a next allocation/destroy of data.

The only problem is that you must not loose a pointer or you will have memory being used for nothing.

If anyone you have any problems send me an email to zhamilton1@yahoo.co.uk or post here where I'll check up here and then.

I hope this has been useful info to you... (:

[ayasin]

Originally posted by zhamilton1
The only problem is that you must not loose a pointer or you will have memory being used for nothing.


That is actually quite bad (more so than an ordinary mem leak) because you are leaking on the storage heap and that memory will not be reclaimed until a soft reset or your app is uninstalled.

[Alistar]

I think I had that happen then. My NX said it had approx 4 megs of free memory left. I installed a skin and soft reset it so that it would install and that number jumped to approx 5 megs.

[iebnn]

Features are really easy to do.... but FtrPtrNew is confusing me :(

[ayasin]

What about it confuses you?

[iebnn]

Well, I've got an app that can't use global variables.. I've been having trouble putting a struct into feature memory with FtrPtrNew in one function then being able to get the values from that pointer in another function..

[ayasin]

First of all zhamilton1 this us not a flame of your technique. I personally would not generally endorse using Feature Memory in the manner described in this section for the reason I stated earlier as well as the fact that DmWrite does some important things for you (one of the key things being bounds checking which is esp important on the storage heap). Additionally a pointer to feature memory is locked (preventing the palm from efficently compressing the storage heap) until you unallocate it so use it with care. I am, however, curious to see the code that you are having a problem with if you want to distill out the relavent portions into an example.

[zhamilton1]

Yes that is the main problem. However it does not destroy any of the storage data and since you normally only allocate small areas it does get to a point where you have defragmented data. However you gain the speed and low usage of dynamic data. It should not be used by applications which are rarely opened and closed quickly (like a word-proccessor). But for a launcher, it is great since you enter/exit a launcher like all the time, therefore speed is crucial. For debugging make it add an entry to some file (which will slow it down but give you debug data) and then provide a function which tries to unregister all feature data. If an entry still exists you know you have a memory leek. In the release version just dont include that part of the code. Then you wont have that problem. Note: With MemPtr you still have the same problem since if you forget the pointer the memory is unused in dynamic memory which much more smaller which can cause worse memory leaks than feature memory.

[ayasin]

Originally posted by zhamilton1
Yes that is the main problem. However it does not destroy any of the storage data and since you normally only allocate small areas it does get to a point where you have defragmented data.


You _could_ destroy data if say you are storing a string there, and you pass the string to a StrPrintF call that writes too much back. Also fragmentation is very bad on the storage heap because now you are affecting all other apps on the device negatively.


Note: With MemPtr you still have the same problem since if you forget the pointer the memory is unused in dynamic memory which much more smaller which can cause worse memory leaks than feature memory.
That's not entirely true. While you will cause a mem leak, it will be cleaned up as soon as your application exits (because it's on your dynamic heap). This is not the case for lost feature memory; it requires a soft reset to reclaim this memory.

You may be correct that if you use this technique for a launcher you see some major benefit, but I think the risk associated with it should make most developers in most situations think twice.