From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri, 30 May 1997 09:37:55 +1000
From: David Hogan dhog@lore.plan9.cs.su.oz.au
Subject: Plan 9 loader memory consumption
Topicbox-Message-UUID: 5b3ed394-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19970529233755.Q0eZW9Phz-mUJrtzqYR6JjAySUr-fWyqH3vEdHfz0ws@z>

I have been trying to compile the X server and ghostscript 4.03
at home.  Unfortunately I "only" bought 32M of RAM, and 8l
tends to use around 29M compiling one of these monsters.
After deducting 3-4M for kernel and ~3M for kfs, I don't have
enough RAM to keep 8l in core.  This means it takes about an hour
to link the X server, and a similarly long time for gs.

As I recall, 8l doesn't use malloc and free; it just allocates
space on the heap and never frees it.  It tends to walk some
fairly large lists multiple times, which adds to the thrashing
behaviour when there isn't enough RAM.  I remember being told
that the justification for this was efficiency; when you have
the RAM, it is a lot faster to avoid the extra overheads of
using a real allocator, or so the argument goes.

I'm starting to wonder if it mightn't be a bad idea to try and
change the way 8l does its allocation, to make compiling
these programs possible on machines which don't have huge
amounts of RAM.  Has anyone else looked at the linker internals
and have an opinion on this?  It's been a while since I looked
in there myself, so I don't have a really good feel for how
much memory is being wasted, or how much locality of reference
there is, or indeed how easy it would be to figure out
what needs to be freed...