Genera

[P. T. Withington]

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 
>implemented.)

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 
been copied.

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 
invisible.

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.)