By default, atoms created during the execution of a program remain permanently in the system until Prolog exits. For the majority of applications this behavior is not a problem and can be ignored. However, for two classes of application this can present problems. Firstly the internal architecture of SICStus Prolog limits the number of atoms that be can created to 1,048,575 on 32-bit machines, and this can be a problem for database applications that read large numbers of atoms from a database. Secondly, the space occupied by atoms can become significant and dominate memory usage, which can be a problem for processes designed to run perpetually.
These problems can be overcome by using atom garbage collection to reclaim atoms that are no longer accessible to the executing program.
Atoms can be created in many ways: when an appropriate
token is read with read_term/3, when source or PO files are loaded, when
atom_codes/2 is called with a character list, or
when SP_atom_from_string() is called in C code.
In any of these contexts an atom is only
created if it does not already exist;
all atoms for a given string are given the same identification
number, which is different from the atom of any other string. Thus,
atom recognition and comparison can be done quickly, without having to
look at strings. An occurrence of an atom is
always of a fixed, small size, so where a given atom is likely to be used
in several places simultaneously the use of atoms can also be more
compact than the use of strings.
A Prolog functor is implemented like an atom, but also has an associated arity. For the purposes of atom garbage collection, a functor is considered to be an occurrence of the atom of that same name.
Atom garbage collection is similar to heap garbage collection, invoked
automatically as well as through a call to the built-in predicate
garbage_collect_atoms/0. The atom garbage collector scans
Prolog's data areas looking for atoms that are currently in use and
then throws away all unused atoms, reclaiming their space.
Atom garbage collection can turn an application that continually grows and eventually either runs into the atom number limit or runs out of space into one that can run perpetually. It can also make feasible applications that load and manipulate huge quantities of atom-rich data that would otherwise become full of useless atoms.