Path: utzoo!attcan!uunet!mcsun!ukc!icdoc!syma!aarons
From: aarons@syma.sussex.ac.uk (Aaron Sloman)
Newsgroups: comp.object
Subject: Re: Garbage collection -- difficulty, cost, generality
Keywords: garbage collection times
Message-ID: <2356@syma.sussex.ac.uk>
Date: 15 Mar 90 00:31:28 GMT
References: <1990Mar13.011146.6019@Neon.Stanford.EDU>
Organization: School of Cognitive & Computing Sciences, Sussex Univ. UK
Lines: 67

wilson@carcoar.Stanford.EDU (Paul Wilson) writes:

> Date: 13 Mar 90 01:11:46 GMT
> Reply-To: wilson@carcoar.Stanford.EDU (Paul Wilson)
>
> As somebody who's written a state-of-the-art gc (in some respects, at
> least), ......

> ...................Don't expect a fast language on stock
> hardware to have gc speed costs of less than about 10% on average.
> I think in the 8-15 percent range myself.
    ..........

> Paul R. Wilson
> Software Systems Laboratory               lab ph.: (312) 996-9216
> U. of Illin. at C. EECS Dept. (M/C 154)   wilson@bert.eecs.uic.edu
> Box 4348   Chicago,IL 60680

I thought 8-15 percept was rather high, so I thought I would do some
experiments in Pop-11 (a lisp like language with a Pascal-like
syntax) in the Poplog system on a Sun4/260 (stock hardware I think).

I ran Poplog with heap limit set to vary between 800,000 bytes and
2,000,000 bytes, and then did a range of things, including running
the integrated editor on some fairly large files, using the
incremental compiler to re-compile a little 1700 line expert system
shell several times, running a small planning program that uses the
shell several times, computing factorial(1000) several times (in
order to generate lots of "big" integers to force garbage
collections), doing some double precision decimal arithmetic (which
causes garbage collections) and some single precision (which
doesn't), and at various times recorded the ratio of GC time to
total CPU time.

It varied between 1.5% and 3.2%.

Typical times for individual garbage collections were about 0.15
seconds - obviously it would have been more for a larger process, or
less if I had "locked" the part of the heap containing non-garbage.

Also, by allocating more heap-space I could reduce the frequency
of garbage collections and so bring the percentage of GC time down.

These times were obtained using the default Poplog garbage collector
which uses the "stop-and-copy" method. Forcing it to use the
non-copying ("compacting") garbage collector, which is invoked when
there is not enough memory or swap space for the copying mechanism)
then it would have been a bit slower (e.g. 0.22 seconds per GC).

It would also have slowed down had there been more data-structures.
e.g a program with about 2 Mbytes in the heap might spend a couple
of seconds on a garbage collection. The actual time would depend
on whether there's enough physical memory to make paging
unnecessary.

The above times compare quite well with stories about having to
stop for coffee whenever a lisp machine has a garbage collection,
and of course as "stock" hardware gets faster, the GC times will
reduce, though not necessarily the percentage.

Aaron Sloman,
School of Cognitive and Computing Sciences,
Univ of Sussex, Brighton, BN1 9QH, England
    EMAIL   aarons@cogs.sussex.ac.uk
or:
            aarons%uk.ac.sussex.cogs@nsfnet-relay.ac.uk
            aarons%uk.ac.sussex.cogs%nsfnet-relay.ac.uk@relay.cs.net