Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!nrl-cmf!ukma!rutgers!att!alberta!ubc-cs!fornax!mcdonald
From: mcdonald@fornax.UUCP (Ken Mcdonald)
Newsgroups: comp.sys.mac.programmer
Subject: Memory manager query
Keywords: Practical limits
Message-ID: <868@fornax.UUCP>
Date: 6 Feb 89 08:27:15 GMT
Distribution: na
Organization: School of Computing Science, SFU, Burnaby, B.C. Canada
Lines: 32

Does anyone out there know the practical limits of the memory manager?
As in:

I want to write an application that will make heavy use of relocateable
blocks--as in, HEAVY.  In degenerate cases, I could be running about
10,000 relocateable blocks/250k of heap space.  (The limit, of course,
is about 20,000/250k, at which point the entire heap is taken up with
memory manager info, leaving no room for your own data!)  Question: when
will the memory manager start to complain.  Complaining consists of slowness,
crashes, or other undesireable behaviour.

Some notes to aid you in your advice...I will be arranging things so that
all nonrelocateable blocks are at the bottom of the heap, and all
relocateable blocks are unlocked when a request for more memory is
issued.  This means that the memory manager can get every last by out
of the heap.  I will be doing lots of things like increasing or decreasing
the sizes of blocks, and, in general, proby working the memory manager's
little fingers to the bone.

So, comments?

Finally, is there Pascal source available (preferably free) to set up a
pseudo-heap (by grabbing a big array, for instance), and then doing
transparent dynamic allocation in the pseudo-heap?  By transparent, I
mean that it keeps track of what is valid and what's not, and throws
something away when it should be thrown away--like LISP garbage collection,
except I want variable-size elements in the pseudo-heap.  The memory
manager isn't really suitable for something like this.

Thanks for all the help,
Ken McDonald
{...!ubc-cs!mcdonald@fornax.uucp}