Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ucla-cs!zen!ucbvax!decvax!ima!think!barmar
From: barmar@think.UUCP
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: pointer alignment when int != char *
Message-ID: <8024@think.UUCP>
Date: Tue, 1-Sep-87 18:33:43 EDT
Article-I.D.: think.8024
Posted: Tue Sep  1 18:33:43 1987
Date-Received: Thu, 3-Sep-87 02:04:03 EDT
References: <493@its63b.ed.ac.uk> <6061@brl-smoke.ARPA> <3812@spool.WISC.EDU> <7939@think.UUCP> <588@murphy.UUCP>
Sender: news@think.UUCP
Reply-To: barmar@godot.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 38
Xref: utgpu comp.lang.c:3921 comp.unix.wizards:3729

In article <588@murphy.UUCP> dave@murphy.UUCP (Dave Cornutt) writes:
>> In fact, I know of an architecture where it may return different
>> results for pointers to the same two objects at different times: the
>> Symbolics Lisp Machine.  It has a garbage collector that moves objects
>> around in memory, so the addresses may change, and therefore the
>> difference may change.
>
>I must be missing something here.  Admittedly, I don't know anything about
>this machine, but it looks like this garbage collection would make pointers
>useless, since there is no guarantee that, when you dereference a pointer,
>the object that you're referring to will be in the same place that it was
>when you obtained the address.  I can see how it could be done using some
>sort of highly segmented memory, but it seems like the overhead would be
>enormous (i.e., the iAPX 432).  How does this work?

Whenever the garbage collector moves something, it effectively updates
all pointers to the object.  Most Lisp garbage collectors are of this
relocating variety these days, as it also tends to shrink the working
set and increase locality.  A particular pointer variable will always
point to the same object (until it is reassigned, of course), although
its internal numerical value may change.

I'm not sure how they deal with the fact that a pointer cast into an
integer and back into a pointer (or is it vice versa?) must maintain
its value.  My guess is that they maintain a hash table of pointers
that have been converted into integers.

As for the overhead, it's just part of the garbage collection that
Lisp programmers have been living with for decades.  It's worth it not
to have to keep track of when memory needs to be deallocated.  And
Lisp Machines have special hardware that optimizes GC.

---
Barry Margolin
Thinking Machines Corp.

barmar@think.com
seismo!think!barmar