Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!haven!aplcen!uunet!mcsun!ukc!strath-cs!cs.glasgow.ac.uk!jack
From: jack@cs.glasgow.ac.uk (Jack Campin)
Newsgroups: comp.object
Subject: Re: Garbage collection -- difficulty, cost, generality
Message-ID: <4862@vanuata.cs.glasgow.ac.uk>
Date: 16 Mar 90 18:59:50 GMT
References: <1990Mar13.011146.6019@Neon.Stanford.EDU> <2356@syma.sussex.ac.uk> <4836@vanuata.cs.glasgow.ac.uk> <1990Mar15.232035.147@Neon.Stanford.EDU>
Reply-To: jack@cs.glasgow.ac.uk (Jack Campin)
Organization: COMANDOS Project, Glesga Yoonie, Unthank
Lines: 53
Summary:
Expires:
Sender:
Followup-To:
Keywords:


wilson@carcoar.Stanford.EDU (Paul Wilson) wrote:
> jack@cs.glasgow.ac.uk (Jack Campin) writes:
>> aarons@syma.sussex.ac.uk (Aaron Sloman) wrote:
>>> wilson@carcoar.Stanford.EDU (Paul Wilson) writes:
>>>> Don't expect a fast language on stock hardware to have gc speed costs of
>>>> less than about 10% on average.
>>> [Poplog] varied between 1.5% and 3.2%.
>> PS-algol uses about 2.9% according to some measurements done a couple of
>> years ago.

> Questions:

>   1) how fast is PS-Algol, flat out?  Less-than-great code quality can
>      flatter gc performance. 

Very fast for an interpreted language.  Much better than any Smalltalk I've
seen (Smalltalk is probably the closest familiar programming environment).
There is a much faster native-code-generated version used by ICL on their
mainframes; I don't have any performance figures on this (that I can give
out, anyway).  Maybe comparable to a good interpreted Lisp, but that's
guesswork.  I wasn't surprised that Poplog led to similar figures on
something; anyone got a nice closure-bashing benchmark that we could try
in Smalltalk, Scheme, Poplog and PS-algol to firm this up a bit?


>   2) what kind of gc was used? 

Sliding compaction; Deutsch-Schorr-Waite or Morris, I forget which.  Later
versions add a feature that makes a big difference: sometimes treating
read-only persistent objects as garbage (you can always get them back from
disk later if this is wrong).  This can reduce heap size drastically.


>   3) what kind of programs were used for testing?

Recompiling the compiler.


>   4) did this involve persistent objects?

Yes, but that doesn't make much difference to in-core gc, except for the
point mentioned in 2).  The garbage collector only needs to test bit 31 of
a 4-byte address to tell persistent and virtual-memory pointers apart.
Persistent storage garbage collection is a different kettle of ballgames.
Time for a lunchbreak with our persistent store (~100 MB of data, gc
running on fast Suns).  Only done every few weeks.

-- 
--  Jack Campin   Computing Science Department, Glasgow University, 17 Lilybank
Gardens, Glasgow G12 8QQ, Scotland   041 339 8855 x6044 work  041 556 1878 home
JANET: jack@cs.glasgow.ac.uk    BANG!net: via mcvax and ukc   FAX: 041 330 4913
INTERNET: via nsfnet-relay.ac.uk   BITNET: via UKACRL   UUCP: jack@glasgow.uucp