home *** CD-ROM | disk | FTP | other *** search
/ RISC DISC 1 / RISC_DISC_1.iso / pd_share / code / desklib / Docs / ModuleNote / Mem < prev    next >
Encoding:
Text File  |  1993-05-13  |  5.9 KB  |  120 lines
  1. About the Mem sublibrary
  2. ========================
  3.  
  4. "Flex" is the RISC OS Lib 'flexible' malloc for desktop tasks
  5. "Mem" is DeskLib's equivalent thereof, and uses an interface that is
  6. very similar to that of flex.
  7.  
  8. Mem memory chunks are held in a 'heap' of memory above the area grabbed
  9. by the SharedCLibrary for mallocs and stackspace, extending up to the
  10. end of the WimpSlot, which is adjusted up & down as necessary.
  11.  
  12. The major feature that externally distinguishes Mem from flex() is that
  13. the heap is NOT compacted automatically (flex keeps the entire heap
  14. compacted at all times). This has several advantages:
  15.   - You can rely on pointers remaining constant at all times between
  16.     calls to Mem_Compact() (and other Mem_ calls if you allow it)
  17.   - everything is a lot faster if you are allocating and/or
  18.     deallocating many chunks in one go.
  19.  
  20. The idea behind this is that you simply call Mem_Compact before
  21. calling Wimp_Poll - this returns free memory to the Wimp as effectively
  22. as the flex system did, but saves us from having to waste time on
  23. multiple compactions between Wimp_Polls.
  24.  
  25. Automatic compaction (a la flex) can be turned on (or off) at any time
  26. so the Mem system can be made to emulate flex_ if you really want it.
  27.  
  28.  
  29. Important Notes
  30. ===============
  31.  
  32. * The Mem sublibrary has not been thoroughly tested yet, so don't be too
  33.   surprised if it suddenly dies on you... However, it seems to work OK for
  34.   the tests I have had time to perform on it.
  35.  
  36. * For reasons utterly unknown to me, Mem_MidExtend (and possibly others, like
  37.   Mem_Compact, for example) will fail if your initial WimpSlot is a bit tight.
  38.  
  39.   (If you allocate a large enough WimpSlot, malloc and stack extension will
  40.   fail with a 'not enough memory' error when they run out. However, with a very
  41.   tight WimpSlot, I got all kinds of neat errors which appeared to be because
  42.   of a corrupt stack, which usually killed things on exit from MidExtend!
  43.  
  44.   The problem went away when I made the main program slightly smaller, so
  45.   it might only occur in very special circumstances. However, if your program
  46.   dies with calls to non code and other such stuff, try increasing the WimpSlot
  47.   in your !Run file...
  48.   
  49.   If anyone can tell me WHY this was happening, I'd love to know!
  50.  
  51.  
  52. Possible mem improvements in the future
  53. =======================================
  54.  
  55. No guarantees, but here's my list of ideas which somebody (you perhaps?)
  56. may be interested in implementing for future releases of DeskLib.
  57.  
  58. * Add the missing code from mem_MidExtend which will improve the chances
  59.   of extending large blocks in low memory situations.
  60.  
  61.   This may be done by adding another mem extend call (mem_ForceExtend)
  62.   which will compact the heap and then force extension of the block by
  63.   moving everything after the chunk up to make space (if possible). This will
  64.   allow you to extend chunks whenever possible, but still elect to link in
  65.   the extra code for these situations if you really need it.
  66.  
  67. * Add the ability to lock mem chunks (preferably after being moved to the
  68.   'safest' address possible, to minimise memory trapping) to stop them ever
  69.   moving. Ability to unlock (and move) these chunks when you feel like it.
  70.  
  71. * Add function to emulate flex_budge, which will allow malloc and
  72.   stack extension attempts to shift the mem heap up if needed. (Not
  73.   recommended, as this means you must be VERY careful with anchors)
  74.   Note that although this code exists (in the form of ShiftHeap), it
  75.   must be repeated within the budge function, as you are in the process of
  76.   finding more memory for the stack, so can't call other functions ;-(
  77.  
  78. * Possibly a flex_budge style function which will allocate a new chunk
  79.   and LOCK it, and give this memory to the SharedCLibrary, so that malloc
  80.   and stack extension will "never" fail.
  81.  
  82. * Additional code for mem_Alloc to provide different allocation strategies.
  83.   Currently, a 'best fit' is found, but it is faster to find the 'first fit',
  84.   especially if you are working with a lot of small, similar-sized chunks.
  85.  
  86.   Another allocation strategy which might even be better than either of these
  87.   is 'grab' - always allocate the chunk at the end of the heap, and rely on
  88.   the user calling Compact enough to keep the free space at the end of the heap
  89.   (where the Wimp Pool is thought of as 'memory at the end of the heap')
  90.   This is the fastest strategy, and also needs the minimum of code.
  91.   (If you wish to try this out, just delete the first half of the code in
  92.   mem_Alloc, and use 'bestfit' == lastchunk!)
  93.  
  94. * Addition of a flagword to each mem chunk. Uses I can see for this are:
  95.   - Chunks which have their own 'mem_autocompact' style values (i.e. some
  96.     chunks are allowed to move, others should move only if necessary, and
  97.     others are not allowed to move ever).
  98.  
  99.   - Chunks which never release memory when you MidExtend them (i.e. they will
  100.     grow, but will never shrink. This is a very good idea if you have a data
  101.     structure which gets bigger and smaller all the time, but never goes above
  102.     a (reasonable) maximum - instead of it causing endless heap relocations,
  103.     mem can just keep the memory around on the assumption that the data in
  104.     the chunk will expand again in the near future.
  105.  
  106.   - Data pertaining to the use of mem anchors from within a mem chunk. As
  107.     mem minimises the amount of shifting of chunks, it is more possible to
  108.     resolve chunk-to-chunk references as chunks are shifted. This would be
  109.     slower (especially if used a lot), but would be extremely convenient, as
  110.     it would allow things like trees and linked lists to be constructed
  111.     easily across a set of mem chunks...
  112.     Or perhaps just a way of indirecting dereferences through mem, which can
  113.     look up the current address of the chunk for you -slow to search through
  114.     such structures, but a useful ability.
  115.  
  116.   - Addition of a 'moved' flag. This can be set whenever mem moves a chunk,
  117.     and the user can check this flag at important points to see if they need
  118.     to bother updating pointers into the chunk - after such adjustment, the
  119.     flag is cleared again.
  120.