|Did you know ...||Search Documentation:|
|Heap memory (malloc)|
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.155Multi-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
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=/path/to/libtcmalloc.so swipl ...
If SWI-Prolog core detects that tcmalloc is the current allocator and provides the following additional predicates.
gperftools/malloc_extension.h:156Documentation copied from the header.
tcmalloc.max_total_thread_cache_bytes. Setting an unknown property raises a
domain_errorand setting a read-only property raises a