ECL relies on the Boehm-Weiser garbage collector for handling memory, creating and destroying objects, and handling finalization of objects that are no longer reachable. The use of a garbage collector, and in particular the use of a portable one, imposes certain restrictions that may appear odd for C/C++ programmers.
In this section we will discuss garbage collection, how ECL configures and uses the memory management library, what users may expect, how to handle the memory and how to control the process by which objects are deleted.
First of all, the garbage collector must be able to determine which objects are alive and which are not. In other words, the collector must able to find all references to an object. One possibility would be to know where all variables of a program reside, and where is the stack of the program and its size, and parse all data there, discriminating references to lisp objects. To do this precisely one would need a very precise control of the data and stack segments, as well as how objects are laid out by the C compiler. This is beyond ECL’s scope and wishes and it can make coexistence with other libraries (C++, Fortran, etc) difficult.
The Boehm-Weiser garbage collector, on the other hand, is a conservative garbage collector. When scanning memory looking for references to live data, it guesses, conservatively, whether a word is a pointer or not. In case of doubt it will consider it to be a pointer and add it to the list of live objects. This may cause certain objects to be retained longer than what an user might expect but, in our experience, this is the best of both worlds and ECL uses certain strategies to minimize the amount of misinterpreted data.
More precisely, ECL uses the garbage collector with the following settings:
Except for finalization, which is a questionable feature, the previous settings are not very relevant for Common Lisp programmers, but are crucial for people interested in embedding in or cooperating with other C, C++ or Fortran libraries. Care should be taken when manipulating directly the GC library to avoid interfering with ECL’s expectations.
Beginning with version 9.2.1, ECL operates a tighter control of the resources it uses. In particular, it features explicit limits in the four stacks and in the amount of live data. These limits are optional, can be changed at run time, but they allow users to better control the evolution of a program, handling memory and stack overflow gracefully via the Common Lisp condition system.
The customizable limits are listed in Table 3.1, but they need a careful description.
ext:heap-size limits the total amount of memory which is available for lisp objects. This is the memory used when you create conses, arrays, structures, etc.
ext:c-stack controls the size of the stack for compiled code, including ECL’s library itself. This limit is less stringent than the others. For instance, when code is compiled with low safety settings, checks for this stack limit are usually omitted, for performance reasons.
ext:binding-stack controls the number of nested bindings for special variables. The current value is usually safe enough, unless you have deep recursive functions that bind special variables, which is not really a good idea.
ext:frame-stack controls the number of nested blocks, tagbodys and other control structures. It affects both interpreted and compiled code, but quite often compiled code optimizes away these stack frames, saving memory and not being affected by this limit.
ext:lisp-stack controls the size of the interpreter stack. It only affects interpreted code.
If you look at Table 3.1, some of these limits may seem very stringent, but they exist to allow detecting and correcting both stack and memory overflow conditions. Larger values can be set systematically either in the ~/.eclrc initialization file, or using the command line options from the table.
When ECL surpasses or approaches the memory limits it will signal a Common Lisp condition. There are two types of conditions, ext:stack-overflow and ext:storage-exhausted, for stack and heap overflows, respectively. Both errors are correctable, as the following session shows:
> (defun foo (x) (foo x)) FOO > (foo 1) C-STACK overflow at size 1654784. Stack can probably be resized. Broken at SI:BYTECODES.Available restarts: 1. (CONTINUE) Extend stack size Broken at FOO. >> :r1 C-STACK overflow at size 2514944. Stack can probably be resized. Broken at SI:BYTECODES.Available restarts: 1. (CONTINUE) Extend stack size Broken at FOO. >> :q Top level.
As we all know, Common-Lisp relies on garbage collection for deleting unreachable objects. However, it makes no provision for the equivalent of a C++ Destructor function that should be called when the object is eliminated by the garbage collector. The equivalent of such methods in a garbage collected environment is normally called a finalizer.
ECL includes a simple implementation of finalizers which makes the following promises.
The implementation is based on two functions, ext:set-finalizer and ext:get-finalizer, which allow setting and querying the finalizer functions for certain objects.
Stack overflow condition
Class Precedence List
ext:stack-overflow, storage-condition, serious-condition, condition, t
Methods
A non-negative integer.
A symbol from Table 3.1, except ext:heap-size.
Description
This condition is signaled when one of the stack limits in Table 3.1 are violated or dangerously approached. It can be handled by resetting the limits and continuing, or jumping to an outer control point.
Memory overflow condition
Class Precedence List
ext:storage-exhausted, storage-condition, serious-condition, condition, t
Description
This condition is signaled when ECL exhausts the ext:heap-size limit from Table 3.1. In handling this condition ECL follows this logic:
(ext:set-limit 'ext:heap-size 0) to remove the heap limit and avoid further messages, or use the (continue) restart to let ECL enlarge the heap by some amount.
Any lisp object.
Description
This function returns the finalizer associated to an object, or nil.
A symbol.
Description
Queries the different memory and stack limits that condition ECL’s behavior. The value to be queried is denoted by the symbol concept, which should be one from the list: Table 3.1
Associate a finalizer to an object.
Any lisp object.
A function or closure that takes one argument or nil.
Description
If function is nil, no finalizer is associated to the object. Otherwise function must be a function or a closure of one argument, which will be invoked before the object is destroyed.
Example
Close a file associated to an object.
(defclass my-class () ((file :initarg :file :initform nil))) (defun finalize-my-class (x) (let ((s (slot-value x 'file))) (when s (format t "~%;;; Closing" s) (close s)))) (defmethod initialize-instance :around ((my-instance my-class) &rest args) (ext:set-finalizer my-instance #'finalize-my-class) (call-next-method)) (progn (make-instance 'my-class :file (open "~/.ecl.old" :direction :input)) nil) (si::gc t) (si::gc t) ;; Closing
Set a memory or stack limit.
A symbol.
A positive integer.
Changes the different memory and stack limits that condition ECL’s behavior. The value to be changed is denoted by the symbol concept, while the value is the new maximum size. The valid symbols and units are listed in Table 3.1.
Note that the limit has to be positive, but it may be smaller than the previous value of the limit. However, if the supplied value is smaller than what ECL is using at the moment, the new value will be silently ignored.
| Concept | Units | Default | Command line |
|---|---|---|---|
| ext:frame-stack | Nested frames | 2048 | --frame-stack |
| ext:binding-stack | Bindings | 8192 | |
| ext:c-stack | Bytes | 128 kilobytes | --c-stack |
| ext:heap-size | Bytes | 256 megabytes | --heap-size |
| ext:lisp-stack | Bytes | 32 kilobyes | --lisp-stack |
Table 3.1: Customizable memory limits