Managing Available Memory

From TreoCentral

Jump to: navigation, search

Contents

[edit]

Memory management on PalmOS Treos

The introduction of the NVFS (Non-Volatile File System) on the Treo 650 has had many benefits but also caused a few issues unique to this device. This article was written primarily to address memory management on the Treo 650. While the expanded memory of the Treo 700p and Treo 680 have resolved this issue for most people, the concepts described here still apply.

[edit]

What is the problem?

If you often get a "There is not enough memory available..." message (typically when you start Blazer) despite having a couple of megabytes of free memory, you are likely running into the hidden, secondary memory limit of PalmOS Treos since the Treo 650 - the NVFS dbCache memory limit. Not everyone will run into this problem – it really depends on which apps you run and how much total memory they use. Note that this is similar to, but not the same as the Blazer internal web page cache.

[edit]

Early versions of the firmware

This article was written primarily for the following Treo 650 ROM updates (referred to as "early versions of the firmware" below). If you are using any of these firmware versions and have the Blazer "There is not enough memory available..." problem, you should upgrade to a newer version as Palm has made a number of improvements.

Sprint 1.12 and 1.12a
Unlocked GSM 1.13
Cingular 1.15
Rogers ATT 1.13
Verizon 1.03
[edit]

Later versions of the firmware

If you are using any of the following PalmOS updates, the good news is that Palm has made significant improvements to the dbCache manager which has reduced the likelihood of the issues described below (referred to as "later versions of the firmware" below). The rest of this article is still useful information to help your understanding of what is going on inside.

Sprint 1.13
Unlocked GSM 1.20
Cingular 1.17
Verizon 1.04
Alltel, Cellular South, Telus Mobility and other CDMA 1.04
[edit]

What is NVFS?

There are two types of memory in Treos after the Treo 650:

  1. Fast volatile dynamic RAM (DRAM) which is used for running applications and PalmOS
  2. Slower non-volatile flash RAM which is used for persistent storage of PalmOS and your data and applications.

The Treo 650 was one of the first Palm devices to use an NVFS memory system (also used on the LifeDrive and Tungsten E2 and T5). The good thing is that it prevents data loss when you run out of battery power. However, there are some new things to deal with in the current implementation in PalmOS 5.4 (Garnet).

For a good overview of the NVFS implementation, read this article first. From the Resco Backup page, this is how NVFS is used on the Treo 650:

Non-Volatile File Storage, i.e. a permanent storage that will survive even the battery removal.

Unlike older Palm handhelds, databases are located in the NVFS storage and cannot be accessed directly. Instead, they are accessed through a reserved RAM area called dbCache.

It is a kind of window into NVFS: Prior to use the DB must be copied to the dbCache and after the use the changes are copied back to NVFS and the DB may be removed from the dbCache to provide the space for other databases. For efficiency reasons the last step is delayed until the dbCache is full.

dbCache is around 10 MB (on the Treo 650) and you can have installed a lot more data in the RAM. You can even have a single database that is larger than the whole dbCache. This implies a fundamental consequence for the Palm programming: The position of the database or their records is no longer constant.

As shown in this diagram of the Treo 650 memory allocation from the PalmOne site,


Tech_NVFS_Map.jpg

The "User Data" memory block is where data and programs are stored when they are not in use. Because this block is NVFS/flash memory, all the information in this memory block is retained even if the battery runs empty or is removed.

The dbCache block is where running programs and data being accessed is stored. The dbCache memory can be thought of as a "staging" area between fast dynamic RAM and slower NVFS/flash memory. Since this block is dynamic RAM, nothing written here is permanent until the cache manager writes it out to the "User Data" block which is in NVFS/flash memory.

The "Dynamic Heap + Misc" block is where apps and PalmOS store data temporarily while running. Because it is in dynamic RAM, it is lost after a soft reset or if the battery empties or is removed.

One final reference regarding the PalmOS NVFS memory management system presents more detail on the different memory blocks and how they are used during the initial boot-up sequence. You can find the article written by TreoCentral user mmastrac here. It provides a very good insight into how this works and how you can increase the dbCache size by making a custom ROM. The actual process of making a custom ROM is covered by this article.

The PalmOS cache manager is supposed to manage the dbCache memory block so that updated data gets written back to flash while yet allowing new data to come in (when a new app is launched or database is opened) without the cache getting full again. In addition, free memory can get fragmented as apps start, stop, or use memory. This fragmentation can limit the size of the largest contiguous chunk of free memory that an app can request.

Unfortunately, the PalmOS cache manager in the early versions of the firmware wasn't effective enough managing the dbCache block which resulted in these "There is not enough memory available..." messages. Typically, that simply means "there is not enough contiguous free dbCache memory available to run this app." The good news is the the cache manager in later versions of the firmware has resolved most of the issues. In addition, the increased amount of memory (and specifically dbCache) in the Treo 700p and Treo 680 have been an even bigger help in preventing these issues.

[edit]

What can I do about the problem?

There are six main options to workaround this problem.

  1. Make sure you are running the latest revision of the firmware (see the table at the beginning of this article). PalmOne has made some efficiency improvements in how it allocates memory which results in more free memory (biggest benefit is for PIM data). Equally valuable, Palm also made significant improvements in the cache manager which resolves most of the issues. PalmOS updates may be found here.
  2. Ensure you are running the latest released version of apps that were specifically designed to run on NVFS systems such as the Treo 650, Treo 680, or Treo 700p. Given that databases may be moved around when PalmOS is managing the dbCache area, some apps needed to be updated to be compatible. While this may not help your “out of memory” problems, it will definitely help prevent other crashes.
  3. Move applications to an SD card and launch them from there. This will free up memory since the application files will be on the SD card instead. See the How do I run applications from the SD card? FAQ for specifics on how to do this.
  4. If you can go most or all of the day before getting an “out of memory” message, you have two choices:
    1. Perform a backup using Resco Backup. There are other backup programs which perform well on the Treo, Resco Backup is unique because it offers an option to flush the dbCache area after the backup and another option help prevent dbCache memory fragmentation.
    2. Another choice is to perform a nightly soft reset. Because the backup program running on the Treo necessarily needs to open every file, the dbCache area can quickly fill and lead to an unexpected soft reset. The advantage of a scheduled soft reset before backups is that it will automatically clear the db cache and allow you to start fresh where the db cache amount is very close to the amount of total free memory available. You can use apps like ProfileCare, mReset + LookAtMe, and others to schedule a nightly soft reset.
  5. Use the Preference Doctor and Resco Locker apps. Another useful utility is MemoryInfo which has some of the same capabilities as Preference Doctor. In particular, both of them can clear the dbCache area usually eliminating the need for a soft reset.
  6. Create a custom ROM since reducing the size of the ROM will increase the size of your dbCache area. For an explanation of why, see this article written by TreoCentral user mmastrac. The actual process of making a custom ROM is covered by this article.
[edit]

What is the MemoryInfo tool?

MemoryInfo is an application released by Palm as part of the SDK utilities package to members of the Developer's Plugged-In Program and compiled and posted by TreoCentral user oscarc. It displays details of your current memory usage and also has some of the "cache clearing" functions of PrefDoctor. The app and forum thread on MemoryInfo is here. It's primarily useful to see exactly how your memory is being used and how much is available.


MemoryInfo1.JPG

Similar to PrefDoctor and dbCacheTool, it also has options to clear the cache. The "Flush dbCache (MemFill)" option seems to consistently free more dbCache than the "Flush dbCache (Hotsync)" option.


MemoryInfo2.JPG

The difference between MemoryInfo and PrefDoctor is that MemoryInfo shows more memory statistics but doesn't have automatic cache clearing when needed. Like dbCacheTool, it is free but not supported or enhanced. PrefDoctor is low-cost shareware, supports automatic cache clearing, is actively being supported and enhanced, and has many more features for helping prevent unexpected soft resets.

[edit]

What is PrefDoctor and how do I use it?

PrefDoctor is a comprehensive effort to prevent unexpected resets where you've lost all your preferences. It has also been enhanced to perform automatic dbCache clearing (aka flushing) which has made it even more useful.

The PrefDoctor app contains three reset prevention features:

  1. The first automatically fixes rogue Exchange Manager entries. In fact, it's the same code as in Butler noted above and also a technique recommended by PalmSource in this PalmSource article on the Exchange Manager and the Saved Preferences.db database.
  2. The second forces preferences to be saved every time an application runs. PrefDoctor then restores the saved preferences database if it should get corrupted during a soft reset.
  3. The third allows you to lock the preferences database.

PrefDoctor has been extremely effective at preventing unexpected resets. To see other's experiences or add your own, please visit this thread.

For automatic dbCache handling, PrefDoctor also has cache management functions similar to MemoryInfo and dbCacheTool. You can manually clear the cache using the Clear cache now option or set the Clear cache if less than value (in megabytes) to serve as a trigger for automatic cache clearing. You will need to experiment with this setting to find the optimal value based on the apps you have loaded. As a starting point, you should set it to roughly half the amount of total free dbCache memory you have after a soft reset. Note that too high a value might cause PrefDoctor to run after just about every app (making you wait for it to finish) and setting it too low would result in “out of memory” messages. You’ll just need to experiment to see which settings work best for you.

[edit]

What is Resco Locker and why might I need it?

Resco Locker is a free utility which locks apps into dbCache so they can’t be moved by a cache clearing. From the Resco Locker page

Resco Locker is a utility that keeps applications locked in memory on NVFS systems. While Resco Locker can be formally used on non-NVFS systems, it cannot do anything useful here.

Why to use Resco Locker?

Main reason is the safety. NVFS brought changes to the Palm OS programming and not all applications reflected them. (Those that were last time updated prior to NVFS release, could not.) One of the most frequent problems is that the Palm databases are no longer fixed (in RAM). That's exactly the problem that is targeted by Resco Locker. For more detailed explanation of the NVFS specifics see please the discussion on the Resco Backup product page.

As a side effect, applications locked in memory need less time to load, which in turn may increase the performance of your handheld.
[edit]

How do I use Resco Locker?

In general, you should lock any apps that are constantly running in the background (e.g. TreoGuard, Fonts4OS5, KeyCaps, ringtone/call managers, etc) if they don’t automatically lock themselves into cache (Butler, Causerie (r3.2.3) and Good Mobile Messaging are examples which lock themselves). Background apps are those which automatically respond to some type of event like the time of day, a hotsync operation, or a particular button or key press. Foreground apps are those you specifically need to launch yourself.

Here are some pointers from the Resco Locker built-in help file and Resaco Locker discussion forum:

Apps locked in memory can load faster A good selection of locked apps may lead to increased device performance. A bad selection has adverse effect as it decreases cache space for the remaining apps. An app can work on background if it registers to receive selected OS notifications (e.g. open tap). On NVFS systems background app must be:
  • Locked
  • Protected
RLock looks for the most important notifications when looking for risky apps.

In the Attributes column of the Resco Locker file list window, the following attributes may appear:

  •  ! means the app receives notifications and hence is a candidate for background processing. Such apps might need to be locked - if they are not NVFS-aware. Unfortunately, RLock is not able to detect all notifications.
  • L = Locked app
  • P = protected app (this is a technical concept; basically such apps receive notification if somebody tries to delete their databases)
Apps marked with !LP are probably OK. They receive notifications (risky factor), but are protected and locked (so they seem to take the correct measures). A good tool to assess the notifications is Palm Internals as it shows the notification details.

Another way to determine which apps runs in the background is to use the free PalmInternals utility to check the list of apps which register for hede, hpps and hvch notifications via the PalmInternal "Notif" button. Finally, you may need to search the forums or contact the developer if you are not sure if an app should be locked or not. For example, VolumeCare and ProfileCare are two apps that run in the background but due to the way they are written, do not need to be locked.

[edit]

Is it possible to lock too much with Resco Locker?

Apparently yes. Lock too much cache memory and it won’t be available for anything else so you might not be able to run some of your large apps. The more memory that's locked, the more often other apps are going to get swapped out of the cache. So I'd recommend only locking those apps that really need to stay in the background all the time and then only the ones where using Resco Locker seems to help. Resco Locker has a 4 MB app lock limit on the Treo 650.

[edit]

Summary

This is a complicated issue, but hopefully this article will help share what information the Treo Community has figured out. We can only hope that PalmOne will continue enhancing PalmOS and improve the stability and usefulness of our favorite device – the do-everything, know-everything Treo.

Indications from Treo 650 Cingular 1.17 ROM, Unlocked GSM 1.20 and Sprint 1.13 users was that they noticed much more effective automatic cache management in PalmOS without any of the apps noted above. It's safe to assume that these improvements will be included in future firmware updates for remaining carriers. To add your comments, please visit this thread.

Many thanks to the forum members and the developers noted above for their individual contributions that helped form this article.

[edit]

References

Retrieved from "http://wiki.treocentral.com/index.php/Managing_Available_Memory"
Personal tools