Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!kth!draken!tut!tucos!ra!moj
From: rcbc@honir.cs.cornell.edu (Robert Cooper)
Newsgroups: comp.lang.clu
Subject: Re: Garbage Collection in CLU-question
Message-ID: <26807@cornell.UUCP>
Date: 10 Apr 89 14:28:20 GMT
References: <677@tuvie>
Sender: moj@ra.abo.fi
Distribution: inet
Organization: Cornell Univ. CS Dept. Ithaca NY
Lines: 32
Approved: moj@cs.utu.fi
In-reply-to: brock%tuvie.UUCP@mcvax's message of 8 Apr 89 15:55:21 GMT
X-Posting-Number: 42

In article <677@tuvie> brock%tuvie.UUCP@mcvax (Inst.f.Prakt.Info 1802) 
Ulrich Neumerkel asks:

>   1. Does anybody know some reports about its realisation?

There is an internal MIT report:
   Sharon E. Perl
   "VAX CLU Implementation Notes"
   MIT Laboratory for Computer Science, DSG Note 124, 29 November 1984.
This describes many aspects of the VAX CLU implementation including the
mark-sweep garbage collector. You could obtain this from Barbara Liskov's
group at MIT.

>   2. Immutable objects seem to be an ideal area to implement much more
>   sophisticated storage allocation mechanisms than simple GC-algs: Consider
>   two independently created sequences, structures or oneofs which are
>   occasionally identical. The GC could remove one of them as one can be
>   replaced with no effect by the others. ... has anybody considered this
>   problem? 

I have not seen this suggested for CLU, but it has been proposed for 
functional languages. In particular see:
    William Stoye
    "The Implementation of Functional Languages Using Custom Hardware"
    University of Cambridge Computer Laboratory
    Technical Report 81, (Thesis), December 1985, p 4.7.
A different approach is the hashing cons provided in some functional language
systems.

>   Ulrich Neumerkel (ulrich@vip.UUCP  UUCP: ...!mcvax!tuvie!vip!ulrich)

Robert Cooper (rcbc@cs.cornell.edu)