Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.lang.eiffel
Subject: Re: Garbage Collection
Message-ID: <1169@tetrauk.UUCP>
Date: 30 May 91 08:03:20 GMT
References: <1991May28.202104.27332@eng.cam.ac.uk>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 34

In article <1991May28.202104.27332@eng.cam.ac.uk> nhr@eng.cam.ac.uk (Neil Russell) writes:
>I'm currently experiencing problems with garbage collection -- it doesn't
>appear to work.  I have a program which has an image size of about
>1.5 Mb after it has built the main data structures during the initialisation
>phase and then shouldn't consume much memory for permanent structures
>subsequently.  However its image grows at about 30kb every 10 seconds
>or so until the point is reached where it has consumed all the available
>memory on the machine! (many Mb).  I'm pretty sure I've got GC switched on.

I haven't encountered a situation of unlimited growth, but I have found that
auto-collection doesn't keep the image as clean as using full_collect.  I have
experimented with different collection modes in my programs, in particular
those which run as servers and so have a distinct message loop.  By turning
collection off and running full_collect every cycle of the loop, the amount of
memory used is considerably lower - I don't have the figures to hand.  This is
to be expected, since full_collect always collects all dead objects, not just a
limited number.  I haven't done any timings, but there is no noticeable
performance difference, and my guess is that full_collect could even be more
efficient.

I've added a routine which inspects an environment variable at startup to
decide which collection mode to use - that way it's easy to try different
modes.  You  might find this worth trying.

Having looked at some of the garbage collector code, I am dubious as to whether
the amount of time it spends collecting (in auto mode) increases with the rate
of object creation, which of course it should do.  If it doesn't, this could
explain you problem.  Perhaps the ISE technical team might like to comment?

-- 
Rick Jones, Tetra Ltd.  Maidenhead, Berks, UK
rick@tetrauk.uucp

Any fool can provide a solution - the problem is to understand the problem