home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / amiga / programm / 18325 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  3.6 KB
  1. Path: sparky!uunet!usc!hacgate!SDFSERV!johnl
  2. From: johnl@SDFSERV.hac.com (John Lee)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Flushing Devices; C= doco (mutter!)
  5. Message-ID: <24657@hacgate.SCG.HAC.COM>
  6. Date: 8 Jan 93 02:46:33 GMT
  7. References: <1993Jan7.092127.13752@philips.oz.au> <1993Jan7.104601.19603@trl.oz.au> <crystal.726440462@glia>
  8. Sender: news@hacgate.SCG.HAC.COM
  9. Organization: Hughes Aircraft Company, El Segundo, CA
  10. Lines: 71
  11.  
  12. In article <crystal.726440462@glia> crystal@glia.biostr.washington.edu (Crystal) writes:
  13. [...]
  14. >Memory is not all THAT cheap...and with only 2Meg of Fast ram...*I*'ve
  15. >panicked!  This is a VERY important consideration - flushing memory and
  16. >getting things back to an unfragmented state so PageStream doesn't crash.
  17. >*grumble*
  18. >
  19. >A POX on programmers who can't clean up after themselves...(or their programs!)
  20.  
  21. First off:  yes, a pox on the developers of PageStream who didn't
  22. handle memory allocation errors correctly.
  23.  
  24. True, the cost of adding more memory is non-trivial for many of us, but
  25. it's not like unflushed libraries and devices greedily hoard memory
  26. from the poor PageStreams that need it.  As said before, the flushing
  27. of those libraries and devices are simple delayed until it's really
  28. needed, when a memory request cannot be fulfilled.  Think of it as a
  29. cheap and simple caching mechanism (which it is.)
  30.  
  31. As for unfragmenting memory, I don't think flushing to half-dozen or so
  32. unused libraries and devices will do much.  It's really not that big a
  33. deal, but forgive a little discourse as to why this is so.
  34.  
  35. Keeping memory unfragmented is one of those great complex Black Magic
  36. chores.  It's a tremendously tricky problem when you can't move things
  37. around to compact memory.  For instance, the unflushed libraries and
  38. devices may hold onto large contiguous blocks.  This forces smaller
  39. memory requests to be satisfied with smaller and better fitting blocks
  40. of memory instead of breaking up larger blocks.  Notice that is
  41. can actually _help_ to reduce fragmentation.
  42.  
  43. "But wait!" you cry.  "What if the memory allocator already implements
  44. a Best-Fit algorithm?"  Always flushing unused libraries and devices
  45. can _still_ increase fragmentation.  A short example will clarify this.
  46.  
  47. Assume we have one 24 byte free memory block, and 20 byte and 64 byte
  48. blocks tied up in an unflushed library.  None of the blocks are adjacent
  49. and so cannot be coalesced.  We'll allocate memory using the Best-Fit
  50. algorithm.
  51.  
  52. If flushes are delayed:
  53.     Action                Free Memory,(Unflushed Memory)
  54.     ------                ------------------------------
  55.     Initial Condition     24,(20,64)
  56.     1.  malloc(16)         8,(20,64)
  57.     2.  malloc(8)            (20,64)
  58.     3.  malloc(20)        (flush occurs) 64
  59.  
  60. we're left with one contiguous 64 byte block.
  61.  
  62. If flushes are immediate:
  63.     Action                Free Memory
  64.     ------                -----------
  65.     Initial Condition     20,24,64
  66.     1.  malloc(16)         4,24,64
  67.     2.  malloc(8)          4,16,64
  68.     3.  malloc(20)         4,16,44
  69.  
  70. and we're left with three fragmented blocks.
  71.  
  72. Of course this is a contrived example, but the point is that keeping
  73. memory unfragmented is a very tough problem.  Since flushing immediately
  74. won't help memory allocation, why not delay it to cache things and
  75. perhaps save a little disk access?
  76.  
  77. -------------------------------------------------------------------------------
  78. The crew faces deadly GURUs!  Next time on AmigaDOS: The Next Generation.
  79.     +--------+            John Lee
  80.     | HUGHES |
  81.     +--------+            Internet: jhlee@hac2arpa.hac.com    
  82. The above opinions are those of the user and not of those of this machine.
  83.