Introduction
G2 memory management differs from that of most programs. Because G2 performs real-time process control, it must avoid pausing for memory management to the greatest possible extent. This requirement affects every aspect of G2's use of memory.
G2 uses memory of various kinds in various contexts:
This chapter describes all of these uses of memory, and shows you how to achieve optimal performance with each of them.
Managing KB Data Memory
Most G2 memory management decisions relate to memory that holds the data associated with a KB. The essential principles for managing such memory are:
- Allocating and deallocating memory causes unpredictably long synchronous waits for the operating system to process the request. Such waits are incompatible with real-time performance. The goal of G2 memory management is to eliminate them.
- When G2 starts, it receives an initial memory allocation, which is specified on the command line or with environment variables. G2 never asks for more memory unless an executing KB has exhausted this initial allocation. A correctly configured KB never exhausts its initial allocation.
- G2 never returns memory to the operating system under any circumstances. It retains all allocated memory in an internal pool. Creating an item withdraws memory from the pool; deleting it returns memory to the pool. The memory is then available for reuse by G2.
- A correctly configured KB does not require ever-increasing amounts of memory. The usual cause of unbounded memory requirement is code that creates transient items and does not explicitly delete them, causing them to accumulate as the KB executes. Other possible causes also exist.
After describing other types of memory, this chapter expands the four principles listed into a complete description of KB data memory management, the problems that can arise with it, and ways in which such problems can be solved.
Copyright © 1997 Gensym Corporation, Inc.