P. T. Withington
Fri, 3 Apr 1998 16:58:28 -0500
On 4/3/98 14:47, Luca Pisati wrote:
>P. T. Withington wrote:
>> The hardware support for GC on the LispM consists of word-granularity
>> read barriers, page-granularity remembered sets, and invisible forwarding
>> pointers. The collector itself is all software.
>forwarding-pointers ... not that invisible :-)
>They gave me a few headaches ...
>I remember cases (inside of the S-Products) where EQ would fail because of
>forwarding pointers (I think it was associated to how CHANGE-CLASS was
That's a slightly different use of forwarding pointers than what the GC
uses. The GC-FORWARD pointer is only ever visible to the GC and is only
used to "snap-out" additional references to an object that has already
There are other classes of forwarding pointer, such as STRUCTURE-FORWARD,
which is used on structures such as arrays or classes if they change in
size to transparently update all old references. Nearly all instructions
use memory cycles that will chase the forwarding pointer, so they are
EQ, however, only compares addresses, so if you were to compare an old
and new version of the "same" object, they would not compare. You
wouldn't want EQ to check for forwarding every time would you? Instead,
you must take care when working with objects that might grow. (I don't
recall if EQL did the right thing. I do remember stubling across a
function SYS:EQ-INCLUDING-FORWARDS in some old code...
Other uses for forwarding pointers:
When you RPLACD into a cdr-coded list, there is no CDR cell, so you have
to invisibly forward the CAR to a new CONS.
Dynamic closures used invisible forwarding to dynamically bind the global
symbol-value to the captured value.
The hardware deep binding cache used forwarding pointers to trigger a
deep-binding lookup and to hold the global value. (The Ivory chip could
operate in either shallow or deep binding mode, the latter intended for
real-time and multi-processor systems.)