35.3. Object Pointer Representations
Prev | Chapter 35. Overview of CLISP's Garbage Collection | Next

## 35.3. Object Pointer Representations

CLISP implements two ways of representing object pointers. (An object pointer, C type object, contains a pointer to the memory location of the object, or - for immediate object - all bits of the object itself.) Both of them have some things in common:

- There is a distinction between immediate objects (`CHARACTER`s, `FIXNUM`s, `SHORT-FLOAT`s, etc) and heap allocated objects.
- All object pointers are typed, i.e. contain a few bits of information about the type of the pointed-to object. At a minimum, these bits must allow to distinguish immediate and heap-allocated objects.
- Not all of the type information is contained in the object pointer. For example, CLOS objects can change their type when `CHANGE-CLASS` is called. To avoid scanning all the heap for references when this happens, the class information is stored in the heap allocated object, not in the object pointer.

The `HEAPCODES` object representation has a minimum of type bits in the object pointer, namely, 2 bits. They allow to distinguish immediate objects (which have some more type bits), `CONS`es (which have no type bits in the heap, since they occupy just two words in the heap, with no header), other heap objects (many, from `SIMPLE-VECTOR`s to `FFI:FOREIGN-POINTER`s), and Subrs. Most object types are distinguished by looking a the `rectype` field in the header of the heap object.

The `TYPECODES` object representation has about two dozen of types encoded in 6 or 7 bits in the object pointer. Typically these are the upper 8 bits of a word (on a 32-bit machine) or the upper 16 bits or 32 bits of a word (on a 64-bit machine). The particular values of the typecodes allow many common operations to be performed with a single bit test (e.g. `CONSP` and `MINUSP` for a `REAL` are bit tests) or range check. However, the `rectype` field still exists for many types, because there are many built-in types which do not need a particularly fast type test.

Which object representation is chosen is decided at build time depending on the available preprocessor definitions. You can define `TYPECODES` or `HEAPCODES` to force one or the other.

One might expect that `TYPECODES` is faster than `HEAPCODES` because it does not need to make as many memory accesses. This effect is, however, hardly measurable in practice (certainly not more than 5% faster). Apparently because, first, the situations where the type of an object is requested but then the object is not looked into are rare. It is much more common to look into an object, regardless of its type. Second, due to the existence of data caches in the CPU, accessing a heap location twice, once for the type test and then immediately afterwards for the data, is not significantly slower than just accessing the data.

`TYPECODES` is problematic on 32-bit machines, when you want to use more than 16 MB of memory, because the type bits (at bit 31..24) interfere with the bits of a heap address. For this reason, `HEAPCODES` is the default on 32-bit platforms.

`HEAPCODES` is problematic on platforms whose object alignment is less than 4. This affects only the mc680x0 CPU; however, here the alignment can usually be guaranteed through some gcc options.

| These notes document CLISP version 2.45 | Last modified: 2008-05-14

Enter your search termsSubmit search form
Webclisp.cons.orgclisp.podval.orgwww.lisp.org

Prev | Up | Next
35.2. Lisp objects in CLISP | Home | 35.4. Memory Models