| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (13 out of 14)

Causes of Unbounded Memory Requirements

No preallocation of memory for a KB can suffice unless the KB's need for memory is bounded. If a KB's memory requirement grows without limit during execution, the increase will exhaust any preallocation, then consume additional memory until no more is available, forcing G2 to shut down.

Two types of problems can cause unbounded increases in a KB's memory requirement:

Unnecessary Retention of Storage

Any system can exhaust memory by creating ever more things and retaining them indefinitely, or by initiating ever more actions and failing to complete them. G2 does not differ from other systems in this regard.

Failure to Delete Transient Items

To understand why failure to delete transient items is a problem, you must understand how G2 manages the memory that such items occupy.

Some programming environments allow you to obtain storage as needed and abandon it when you are done with it. Such an environment includes a capability that periodically identifies all abandoned storage and reclaims it for reuse. Such reclamation is often called garbage collection.

Garbage collection entails moving data as needed to consolidate free memory into a single block. Such consolidation must be done carefully, or concurrent changes to memory will result in data loss. Some garbage collection algorithms suspend all other processing while they consolidate memory. Other algorithms are incremental, but this just distributes their overhead more finely.

G2 does not perform garbage collection, because pausing or slowing to do so would impair real-time performance. After G2 uses a block of memory, it does not return the memory to a generic pool, but retains it intact for future reuse when G2 again needs a block of that size. This technique manages memory with minimal impact on performance, which helps G2 provide real-time response.

When G2 allocates memory, as for a procedure call, it knows how much it has allocated, so it can reclaim and reuse the memory after the procedure returns. However, G2 does not attempt to manage memory that it allocates when a procedure creates transient items, because such management would slow performance.

When a procedure or method creates transient items (create action) but does not delete them (delete action) before returning to its caller, the item continues to exist after the procedure returns. Unless something else deletes the item, the memory that it occupies remains unavailable until you reset G2. Chronic failure to delete transient items causes an insidious loss of memory as G2 executes. Such a problem is called a memory leak.

G2 also creates transient items when you pass objects between different G2's, using the G2-to-G2 interface, or between G2 and a G2 Gateway bridge. To prevent memory leakage, you must explicitly delete all such items when you are done with them.

| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (13 out of 14)

Copyright © 1997 Gensym Corporation, Inc.