|Did you know ...
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
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 table below describes the Key(Value) pairs.
Current settings can be retrieved with prolog_stack_property/2.
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.166Multi-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
Starting with version 8.1.27, SWI-Prolog by default links against
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.25) 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=/path/to/libtcmalloc.so swipl ...
If SWI-Prolog core detects that tcmalloc is the current allocator and provides the following additional predicates.
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