Christophe Rhodes wrote:
> I think that there's a problem in EMIT-FETCH-WRAPPER and
> EMIT-READER/WRITER, caused by the use of STD-INSTANCE-SLOTS (or
> perhaps caused by the fact that STD-INSTANCE-P returns true for
> ordinary instances).
> The essential problem is that (std-instance-slots instance) calls
> (%instance-ref instance 1), which as the comment in EMIT-FETCH-WRAPPER
> says, usually causes no problems and is ignored if we don't actually
> have a PCL instance, because we only perform this operation in
> accessor methods, which are never applicable to ordinary structures,
> so we're about to take a cache miss.
> However, there are cases when even just referencing the first slot of
> a structure is unsafe, irrespective of whether the reference is used;
> they are when the structure has no slots at all, and when it has only
> raw slots. In the no-slots case, the reference is one beyond the end
> of the object, which might usually be OK, being a descriptor -- though
> I wouldn't bet on it. The raw-slots-only case is far worse, in that
> raw slots are now stored directly after all the ordinary slots, so
> that operation will retrieve an arbitrary word and interpret it as a
> descriptor, leading to disaster. If a GC happens while the
> register/stack location is live on a non-conservative platform,
> hilarity will ensue.
This is fixed in 18.104.22.168, by adding a FOR-STD-CLASS-P slot to layouts,
which allows a fast test for structureness/wrapperness.