Lieven Marchand <mal@bewoner.dma.be> writes:
> Date: 04 Jul 1999 14:46:17 +0200
>
[AS]
> > I have heard that in some lisp systems neither compiled functions nor
> > arrays are garbage collected because the garbage collector works only on
> > lists (or lists and records?). But I don't know whether that is or ever
> > was true.
>
> Could very well be true once. Lisp is 40 years old and has known a
> large number of variants and implementations. It isn't with modern
> implementations though.
>
> In for example Allegro Common Lisp you have:
> USER(2): (room t)
> area address(bytes) cons symbols other bytes
> 8 bytes each 24 bytes each
That's interesting. Assuming a 32 bit machine, this implies a
"caged" heap, i.e. the address space is divided into different areas
or cages containing different types of entities.
You explain this later:
> Some CL implementations use the sparse virtual address space technique to
> do type checking (or rather avoid it). A page can only hold objects of one
> type and they are mapped into the 64 bit (or 32 bit) virtual address space
> in such a way that checking a type becomes checking the first bits of the
> address.
This sort of caged heap was once used in a version of pop2 (known as
"wpop" = "Wonderpop" implemented mainly by Robert Rae in Edinburgh
in the mid 70s.
We seriously considered this for Poplog, and then rejected the idea,
partly because of our experience of Wpop.
Advantages of caging:
Because different types of entities are in different parts of the
address space, each entity does not need to have extra information
saying what type of thing it is, which in the case of lists would
require 50% more space. (In Poplog, which does not use caging,
each list link has head, tail and pointer to pair-key, instead
of just head and tail as in Allecro CL).
Also type checking can be faster in a caged system because it is
done on the address of the entity, without needing to look at the
contents.
Since all list cells are in a particular area, the garbage collector
can simply use a free list and never bother with compaction (unless
fragmentation leads to too much paging).
Likewise for other fixed-size records.
Disadvantages of caging:
Different applications need the address space to be partitioned
differently, and it may be hard to re-allocate cages.
In the WPOP system you had to guess the maximum amount of space
needed for various cages (lists, references, other kinds of
records, vectors, etc.) before starting up. If you guessed wrong and
one of the cages ran out of space, you had to abort and start again,
which could be very irritating. I don't know whether Allegro allows
dynamic reallocation of parts of the address space to different
types.
The bit manipulations required are architecture specific and may
have to be changed as a new address space becomes available. (E.g. I
seem to recall that some lisp implementations which used
caging+tagged addresses on the early motorola-based machines with
only about 1 Mbyte of address space (e.g. early suns), required a
lot of messy work to upgrade them when larger memories become
addressable in the early 80s).
Managing caged addresses is more complicated than managing a single
heap which can contain any type of data. I suspect that that is why
many people found the poplog garbage collector so fast, compared
with GC in various lisp systems which had to do more complex
things. (E.g. I even heard stories of people transferring from
dedicated Lisp machines to Poplog running on a general purpose
Unix workstation because although normal lisp code ran much faster
on the lisp machine, garbage collections took much much longer
than in Poplog.
The fact that lists in Poplog used 50% more space was often
compensated for by the fact that Poplog itself was much smaller than
most common lisp systems at that time. I don't know why they were so
big. (E.g. Lucid common lisp). At the time we decided against caging
we were a bit worried about the extra space required, but we assumed
memory would get much cheaper (though we never guessed how much
cheaper).
Of course, the slowness of GCs using caged heaps might simply have
been poor design rather than an inherent feature of caging.
Actually poplog uses 2 bit "tags": Single-word integers and decimals
are distinguished from pointers using these bits. Only every 4th bit
pattern can be a pointer, but that loses nothing on a byte-addressed
machine if you need all pointers to be word-aligned anyway.
There's a slight speed cost since machine arithmetic operations have
to be modified so that the two bit tags are preserved.
It does mean that only 30 bits are available for small integers and
small decimals, though you can have 32 bit signed integers in
vectors, as described in REF INTVEC, and also double-decimals and
bigintegers.
> Thanks for a great job. I've read Popplestone's book and another about
> AI programming in Pop-11 about 10 years ago but I've never had a
> pop-11 system to play with. I even started designing one myself but I
> didn't get very far ;-)
Well, real soon now, .... I hope.
Aaron
====
--
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK
EMAIL A.Sloman AT cs.bham.ac.uk (NB: Anti Spam address)
PAPERS: ftp://ftp.cs.bham.ac.uk/pub/groups/cog_affect/0-INDEX.html
|