Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!munnari.oz.au!diemen!ecc.tased.oz.au!ecc_jim
From: ecc_jim@ecc.tased.oz.au
Newsgroups: comp.sys.acorn
Subject: Memory handling
Message-ID: <1991Mar20.143227.247@ecc.tased.oz.au>
Date: 20 Mar 91 04:32:27 GMT
Article-I.D.: ecc.1991Mar20.143227.247
Lines: 59

I posted this way back when comp.sys.acorn started up and didn't get a
reply. In case it was our news program, here it is again:

We are developing a package using C 1.3B that makes extensive use of tree
structures for handling indexes into data files.

These structures are loaded into memory when needed (using malloc) and
discarded when finished with (using free). If the current wimpslot is too
small to handle the data, it is automatically extended to accomodate it
(this is handled by RISC_OSLIB).

Unfortunately, when the associated memory has been "free'd" it is not handed
back to the operating system for general usage. The memory gets re-used
within the program so when another "malloc" is done the memory is not
wasted.

This has the unfortunate side effect of building the wimpslot up to a
certain maximum level (depending on the size of the indexes). This level is
approaching the limit for 1 megabyte machines - hence the problem.

The practical upshot of this is that the package starts out using around
400K and then builds (after use) up to around 600K. So when the package is
"idle" there is 200K of free memory inside the wimpslot that cannot be
passed back to the operating system.

ANSI C release 3 has an additional memory management tool called a flex
pool. This is a method of claiming free operating system memory and then
passing it back when finished with (Edit does this for the files it loads).
There is, however, a restriction on a flex memory allocation (from page 225
of the ANSI C release 3 guide):

   "...you cannot have flex pointers within blocks of memory allocated by
flex."

This means that you cannot have linked lists or binary trees - the main
reason that memory is being used by our application.

That is the problem, does anyone have a solution?

_______________________________________________________________________________

          Jim Palfreyman                  Elizabeth Computer Centre 
          jim@r140.tased.oz.au            Link Road
          phone: +61 02 496999            Claremont
            fax: +61 02 496969            TAS 7011  Australia

_______________________________________________________________________________

           Imagine that Cray decides to make a personal computer.

 It has a 150 MIPS processor, 200 Mb of RAM, 1500 Mb of disc storage, a screen
    resolution of 4096 x 4096 pixels with 16777216 colours, relies entirely
    on voice recognition for input, fits in your shirt pocket and costs $300.

          What's the first question the computer community asks?

                           "Is it PC compatible?"

_______________________________________________________________________________