3.8 Memory Management

All execution stacks are automatically expanded in Version 3.0, including the local stack/heap region, the trail/choice point region, and the completion stack region. For the main thread, each of these regions begin with an initial value set by the user at the command-line or with a default value - see Section 3.7). Execution stacks increase their size until it is not possible to do so with available system memory. At that point XSB tries to find the maximal amount of space that will still fit in system memory. When a thread is created within an XSB process, the size of the thread's execution stacks may be set by thread_create/3, otherwise the default values indicated in Section 3.7 are used. Once XSB is running, these default values may be modified using the appropriate XSB flags (see Section 6.11). In addition, whenever a thread exits, memory specific to that thread is reclaimed.

Heap garbage collection is automatically included in XSB [10,23]. (To change the algorithm used for heap garbage collection or to turn it off altogether, see the predicate garbage_collection/1 or Section 3.7 for command-line options). In Version 3.0 the default behavior is indirect garbage collection. Starting with Version 3.0, heap garbage collection may automatically invokes garbage collection of XSB's atom table, which stores Prolog's atomic constants. Expansion and garbage collection of execution stacks can occur when multiple threads are active; however atom garbage collection will not be invoked if there is more than one active XSB thread.

The program area (the area into which XSB byte-code is loaded) is also dynamically expanded as needed. For dynamic code (created using assert/1, or the standard predicates load_dyn/1 and load_dync/1) index size is also automatically reconfigured. Space reclaimed for dynamic code depends on several factors. If there is only one active thread, space is reclaimed for retracted clauses and abolished predicates as long as (1) there are no choice points that may backtrack into the retracted or abolished code, and (2) if the dynamic predicate is tabled, all of its tables are completed. Otherwise, the code is marked for later garbage collection. If more than one thread is active, private predicates behave as just described, however space reclamation for shared predicates will be delayed until there is a single active thread. See Section 6.13 for details.

Space for tables is dynamically allocated as needed and reclaimed through use of the predicates abolish_all_tables/0, abolish_table_pred/1, abolish_table_call/1 and other predicates. As with dynamic code, space for tables may be reclaimed immediately or marked for later garbage collection depending on whether choice points may backtrack into the abolished tables, on the number of active threads, etc. See Section 6.14.3 for details.