The clause garbage collector (CGC) scans the environment stacks of all threads for referenced dirty predicates and at which generation this reference accesses the predicate. It then removes the references for clauses that have been retracted before the oldest access generation from the clause list as well as the secondary clauses indexes of the predicate. If the clause list is not being scanned, the clause references and ultimately the clause itself is reclaimed.
The clause garbage collector is called under three conditions, (1) after reloading a source file, (2) if the memory occupied by retracted but not yet reclaimed clauses exceeds 12.5% of the program store, or (3) if skipping dead clauses in the clause lists becomes too costly. The cost of clause garbage collection is proportional with the total size of the local stack of all threads (the scanning phase) and the number of clauses in all‘dirty' predicates (the reclaiming phase).
true. Values for
Status are true, false and stop.
The latter stops the gc thread but allows is to be
recreated lazily. This is use by e.g., fork/1
to avoid forking a multi-threaded application. See also gc_thread.
loop :-
generator,
trim_stacks,
potentially_expensive_operation,
stop_condition, !.
The Prolog top-level loop is written this way, reclaiming memory resources after every user query. See also trim_heap/0 and thread_idle/2.
local, global or trail.
The table below describes the Key(Value) pairs.
Current settings can be retrieved with prolog_stack_property/2.
Related hooks are message_hook/3 (redefining GC messages), prolog_trace_interception/4 and prolog_exception_hook/4.
The total space limit for all stacks is controlled using the prolog flag stack_limit.
SWI-Prolog's memory management is based on the C runtime malloc() function and related functions. The characteristics of the malloc() implementation may affect performance and overall memory usage of the system. For most Prolog programs the performance impact of the allocator is small.161Multi-threaded applications may suffer from allocators that do not effectively avoid false sharing that affect CPU cache behaviour or operate using a single lock to provide thread safety. Such allocators should be rare in modern OSes. The impact on total memory usage can be significant though, in particular for multi-threaded applications. This is due to two aspects of SWI-Prolog memory management:
gc, which means that all deallocation happens in this
thread. Notably the ptmalloc
implementation used by the GNU C library (glibc) seems to handle this
poorly.
Starting with version 8.1.27, SWI-Prolog by default links against
tcmalloc
when available. Note that changing the allocator can only be done by
linking the main executable (swipl) to an alternative library.
When embedded (see section
12.4.23) the main program that embeds libswipl must be
linked with tcmalloc. On ELF based systems (Linux), this effect can also
be achieved using the environment variable LD_PRELOAD:
% LD_PRELOAD=/path/to/libtcmalloc.so swipl ...
SWI-Prolog attempts to detect the currently active allocator and sets the Prolog flag malloc if the detection succeeds. regardless of the malloc implementation, trim_heap/0 is provided.
If SWI-Prolog core detects that tcmalloc is the current allocator and provides the following additional predicates.
gperftools/malloc_extension.h:162Documentation
copied from the header.
tcmalloc.max_total_thread_cache_bytes. Setting an unknown
property raises a domain_error and setting a read-only
property raises a permission_error exception.