7.2 Compiler Transformations

The compiler can assist in optimizing calls to slot-value: in
particular, and despite the highly-dynamic nature of CLOS, compile-time
knowledge of the name of the slot being accessed permits precomputation
of much of the access (along with a branch to the slow path in case the
parameters of the access change between compile-time and run-time).

7.2.1 Within Methods

If the object being accessed is a required parameter to the method,
where the parameter variable is unmodified in the method body, and the
slot name is a compile-time constant, then fast slot access can be
supported through permutation vectors.

(FIXME: what about the metaclasses of the object? Does it have to be
standard-class, or can it be funcallable-standard-class? Surely
structure-class objects could be completely optimized if the class
definition and slot name are both known at compile-time.)

Permutation vectors are built up and maintained to associate a
compile-time index associated with a slot name with an index into the
slot vector for a class of objects. The permutation vector applicable
to a given method call (FIXME: or effective method? set of classes?
something else?) is passed to the method body, and slots are accessed by
looking up the index to the slot vector in the permutation vector, then
looking up the value from the slot vector. (FIXME: a diagram would
help, if I understood this bit well enough to draw a diagram).

Subsequent redefinitions of classes or of methods on
slot-value-using-class cause an invalid index to be written into
the permutation vector, and the call falls back to a full call to
slot-value.

If the conditions for (structure or) permutation vector slot access
optimization are not met, optimization of slot-value within
methods falls back to the same as for calls to slot-value outside
of methods, below.

7.2.2 Outside of Methods

A call to slot-value with a compile-time constant slot
name argument is compiled into a call to a generic function
named (sb-pcl::slot-accessor :global name sb-pcl::reader),
together with code providing load-time assurance (via
load-time-value) that the generic function is bound and has a
suitable accessor method. This generic function then benefits from the
same optimizations as ordinary accessors, described in
Accessor Discriminating Functions.

(FIXME: how does this get invalidated if we later add methods on
slot-value-using-class? Hm, maybe it isn't. I think this is
probably a bug, and that adding methods to slot-value-using-class
needs to invalidate accessor caches. Bah, humbug. Test code in
ex:buggycache, and note that I think that the analogous case
involving adding or removing methods from
compute-applicable-methods is handled correctly by
update-all-c-a-m-gf-info.)