hmc@uk.ac.nerc-pml.unixb (Helen McCall - PML Mast2) writes:
> My experience is that the performance penalty is not all one
> suffers with automatic garbage collection in POPLOG.
>
> POPLOG may well collect up garbage and free the memory for it's
> own use,
No: for *your* use, or the use of your programs, or in some cases
use by other people's programs. What would Poplog want to use
memory for????
> but it does not appear to be very altruistic with respect to other
> processes running on the machine. When making a garbage collection,
> POPLOG actually INCREASES the total amount of memory it is using, so
> forcing other processes running on the machine into an "out of swap
> space" situation and crashing them.
I guess you have not discovered that this is easily turned off: i.e.
false -> pop_gc_copy;
There are two garbage collectors in Poplog, one which does as you
say, by temporarily allocating extra space, then copying the non
garbage into it, then copying back. This has the beauty that the
time taken to do a garbage collection depends only on the amount of
NONgarbage in the head, as the garbage is never even looked at, thus
your program can produce very large amounts of garbage and spend
very little time on garbage collection.
If you make pop_gc_copy false, then the other garbage collector is
invoked: it works within the currently allocated, compating data
structures in the heap after doing the sweep to find where garbage
is. It was designed specifically to address the problem you mention.
In my experience it is only slightly slower than the copying garbage
collector, and can be much faster in cases where the copying one
would cause paging on a machine short of memory.
> Further to this; I have found that POPLOG's own behaviour becomes
> somewhat unpredictable and irrational when swap space runs low,
> with a distinct tendency for conditional branches to default to
> the else path regardless of the evaluation performed, and without
> signalling any error.
It sounds to me as if you have a hardware fault, or a bug in your
memory management software. I've used systems where such bugs have
the effect that pages in use can get corrupted, and of course if
this includes code, then you will get bizarre behaviour. If your
memory management system is bug-free then the performance of a piece
of code should be independent of whether there's paging or not,
except for time.
You can also have problems if you clobber your own program and
misuse poplog's non-checking "fast_" procedures. These can indeed
give different behaviour as pages get relocated and previously
adjacent pages are no longer adjacent in main memory.
If you use the fast_ procedures and are getting such problems you
should replace all the calls of fast_procedures and see if the
fault goes away.
> > Allowing the programmer to manage the utilisation of resources
> herself, can save an awful lot of heartache!
In Poplog there's nothing to stop you building and mainintaing one
or more "free lists" for re-usable portions of memory, if you want
to minimise or eliminate garbage collections. There could be an
efficiency overhead that's worse than using the built in GC.
--
Aaron Sloman,
School of Computer Science, The University of Birmingham, B15 2TT, England
EMAIL A.Sloman@cs.bham.ac.uk OR A.Sloman@bham.ac.uk
Phone: +44-(0)21-414-3711 Fax: +44-(0)21-414-4281
|