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

G2 Memory Regions

To understand G2 memory management, you need a general understanding of how G2 uses the memory that it receives from the operating system.

When you invoke G2, the operating system provides the memory necessary for the G2 process to run. This memory comes in two blocks: one for code, and one for data.

Code memory holds G2's executable code, a table of constants, and a stack. You do not need to understand code memory internal organization, and you cannot control code memory allocation: G2 and the operating system automatically handle everything relating to code memory.

Data memory holds everything relating to the particular KB that G2 is executing. G2 memory management consists almost entirely of managing data memory. When this chapter refers to memory without qualification, the reference is to data memory only.

G2 subdivides its data memory into two regions, named Region 1 and Region 2. Each of these regions holds a particular kind of data:

When you start G2, you can accept default sizes for these regions, or you can preallocate memory to either or both of them as needed by your KB. G2 cannot swap memory between these regions, so exhausting the memory available to one region will cause G2 to request more memory even if there is unused memory in the other.

The background image cache that exists in Region 1 acts like a separate region in many ways. When it must be referred to separately, it is called Region 3. Since Region 3 is a subset of Region 1, you cannot explicitly preallocate Region 3 memory: the Region 1 preallocation supplies Region 3 also. However, you can specify a maximum size for Region 3 when you start G2. This maximum limits the size of the background image cache.

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

Copyright © 1997 Gensym Corporation, Inc.