Devices with embedded processors typically did not include processing and memory resources matching those of general purpose computers. The embedded processors implement some or all of the device's functionality by executing a limited set of programs stored on the device. Examples of such embedded devices include mobile cellular telephones, personal digital assistants, and set top boxes. Such devices often have just enough working memory to handle their limited functions, include only limited local storage resources, such as non-volatile RAM or ROM, and rarely possess hard disk drives. They have, as compared to general-purpose computers of similar age, components or systems with fewer capabilities.
Services provided by or through the embedded device can be augmented and extended through additional programs. As an example only, a cable television set top box can be programmed to provide additional, interactive services, such as not only an interactive program guide, but also news tickers, RSS feeds, games, email and other such services. Software for these services may not be resident in working memory. When a viewer requests the service, the software is dynamically loaded from a local storage device, such as a hard drive, or more typically from a server on a network to which the embedded service is connected, or from a network file system, such as a broadcast file system (BFS) data carousel.
When a new service is loaded, a decision must be made whether to terminate the other services and whether software for the other services will remain resident in processor working memory. In a typical general-purpose computer, virtual memory can be used for swapping programs and data resident in memory to local storage, such as a hard drive or non-volatile memory, thus effectively increasing the size of working memory. However, even if it had local storage devices such a hard disks, a typical embedded device would not have virtual memory or similar capabilities. Furthermore, the embedded device will also typically have a comparatively simpler operating system than a general purpose or personal computer, and it will not, in most cases, give the user explicit control over applications. Thus, the user cannot decide when applications are loaded or when applications quit.
Without the advantage of virtual memory or a storage device such as a hard drive, dealing with memory allocation problems therefore presents a challenge for embedded devices. Handling memory allocation failure is complex for an applications developer or a system operator responsible for deploying software for implementing services on the device. However, rather than meet the challenge, an approach often used is to terminate programs for other services and reallocate memory to the new program.