home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ARM Club 3
/
TheARMClub_PDCD3.iso
/
hensa
/
memmanagement
/
slflex_1
/
ReadMe
Wrap
Text File
|
1995-03-25
|
4KB
|
89 lines
Straylight shifting heap manager
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Some important notes:
1. This is supplied `as is'. There's no warranty or anything like that.
It seems to work for me, though.
2. Nothing stated anywhere should be taken to mean that there will be another
release of this software, because there probably won't. This version of
flex is a part of an obsolete library, and we have better things to be
getting on with.
3. Source code to this software won't be given out, no matter how nicely you
ask.
On with the story:
The flex shifting heap manager was one of the more useful parts of
RISC_OSLib, since it allows large blocks of memory to be manipulated without
causing fragmentation. Now that RISC_OSLib has been replaced by the
Toolbox, Acorn are advocating the use of malloc instead. Unfortunately,
malloc has some problems which flex solves quite nicely.
The RISC_OSLib version of flex unfortunately has a load of dependencies on
other parts of RISC_OSLib, which means that it can't be used on its own
without a load of hacking (and the source code).
This is a rewritten version of flex, with some big bonuses (and a slight
disadvantage -- I'll come on to that later).
The pluses:
1. It's written entirely in assembler. The only routines it calls are also
written in assembler. It's fast. Faster than the Acorn one, anyway.
It's also quite a bit smaller.
2. It doesn't have any dependencies on anything outside the standard C
library kernel. In fact, the only symbols it needs are:
x$stack_overflow (for stack limit checking)
_kernel_register_slotextend (to stop malloc heap from growing)
memmove (for fast memory movement)
I don't know whether this set is small enough to allow flex to be used
under Unixlib. It's certainly small enough for use with the
SharedCLibrary.
3. It compacts in the background. The Acorn version worked by moving all the
memory blocks each time you did a flex operation, so that there was no
free space in the heap. This version will quite happily leave holes in
the heap, and will fill them in `later'. Quite what `later' means is
something I'll deal with below. What all this means is that the time
taken to compact the heap is spread over a long period, so you don't
notice it.
The minus:
There's only one of these. This version of flex does *not* allow the malloc
heap to grow, whereas the Acorn one did. If you need this feature, don't use
this memory manager.
What's different?
All the functions offered by Acorn's flex are implemented in this version.
With the exception of flex_budge, all of these work in a compatible way.
It's basically just a drop-in replacement. Almost.
This flex version `compacts' the heap in the background. It needs to be told
when to do this compaction. Two extra routines are needed to manage this:
flex_reduce does a `small amount' of compaction. Lots of calls to
flex_reduce will result in a compacted heap.
flex_compact will completely compact the heap.
Memory will only be given back to the operating system during compaction. If
there isn't enough memory to do something, flex will compact the heap
completely and try again, so you don't have anything to worry about there;
it's just that your application takes up too much memory is the heap isn't
compacted.
My recommendation is that you call flex_reduce every null event; this results
in fairly rapid compaction, but it still happens more-or-less `in the
background' and no-one notices the performance drop while this is happening.
I also recommend that you compact the heap completely after doing something
which has left a lot of holes in it, such as freeing lots of blocks.