home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / next / programm / 5307 < prev    next >
Encoding:
Text File  |  1992-07-28  |  4.2 KB  |  81 lines

  1. Newsgroups: comp.sys.next.programmer
  2. Path: sparky!uunet!caen!hellgate.utah.edu!fcom.cc.utah.edu!swillden
  3. From: swillden@news.ccutah.edu (Shawn Willden)
  4. Subject: NeXTmille and swapping
  5. Message-ID: <1992Jul28.214418.25972@fcom.cc.utah.edu>
  6. Summary: Memory usage increases with time - why?
  7. Keywords: swapfile, mallocdebug, memory usage, newbie
  8. Sender: news@fcom.cc.utah.edu
  9. Organization: University of Utah Computer Center
  10. X-Newsreader: Tin 1.1 PL3
  11. Date: Tue, 28 Jul 92 21:44:18 GMT
  12. Lines: 67
  13.  
  14. Hi all, 
  15.  
  16.     As a newcomer to NeXT programming and a poor student that can't afford
  17. NeXT DevCamp, I decided that a good way to learn about NeXT programming was
  18. to examine/fix some already-written programs.  One of my favorite PD games is 
  19. NeXTmille-2.0 written by Dennis Glatting of Threaded Technologies, but it
  20. has a problem.  If you've ever played it, you know that after a few hands
  21. the game becomes unplayable because of intense swapping.  The swapfile grows
  22. and grows and eventually response time gets so bad that you must give up, 
  23. kill the game and start over.  I undertook to correct this flaw.  If you 
  24. already know what this particular game's problem is, great, if not, either
  25. hit 'n' now or settle back for a discussion of my attempts to discover the
  26. bug, then offer any ideas you may have.
  27.  
  28.     The obvious first guess is that Dennis created objects in the process
  29. of play that he did not later destroy.  Likely candidates were the cards.  My
  30. first guess was that he created a new deck for every hand (though after looking
  31. through his code for a while I decided he wasn't so naive as that).  A little
  32. investigation revealed that the cards were only created once, at the beginning
  33. of the game, and persisted until the game's end (precisely the way I would have
  34. done it, though I probably would have explicitly freed them at the end, just out
  35. of habit).  This fact was also verified by tossing a few printf's into the init
  36. methods of the various card classes and watching the console output of a game.
  37.  
  38.     My next ploy was to find all uses of dynamic memory allocation in the
  39. program through the simple expedient of 
  40.  
  41.     Edit `grep -l alloc *.[chm]`
  42.  
  43. in the source directory and then looking to see that the objects were free'd
  44. somewhere.  Well, Dennis never did bother to free the cards and a couple of
  45. other items but that's okay because they were only created once and of course
  46. die with the termination of the program.  I was able to verify that all other 
  47. instances of explicit dynamic allocation were either correctly free'd or the
  48. memory was allocated with alloca() which should free the memory upon exit
  49. from the current function/method.
  50.  
  51.     After poring over the code for many additional hours, searching for
  52. illumination, I decided to use my weapon of last resort, yes, I decided to 
  53. RTFM.  I read all about memory allocation and zones and such and finally I 
  54. discovered MallocDebug.  "Hah!" I thought, "Here's the answer to all of my 
  55. problems."  Unfortunately, MallocDebug reported few leaks and informed me that 
  56. most of the new memory being allocated by the program was coming from the ObjC 
  57. zone, accessed by objc_malloc().  And worst of all, MallocDebug told me that 
  58. between the time the game had completed startup and the time the game became 
  59. unplayable only ~40K had been allocated.  In fact, the total allocated memory 
  60. was less than 160K!  This did not go far towards explaining the ~10Mb increase 
  61. in the size of my swapfile or the continual swapping.  Even assuming that all 
  62. the data was horribly fragmented across many pages I couldn't see a way to 
  63. justify that much swapping.  After continued hours of reading everything I 
  64. though might be related, I gradually began to admit to myself that there 
  65. remained only three possibilities that made any sense:
  66.  
  67.     1)    MallocDebug was wrong and I was missing something that
  68.         a little more work with the code could uncover.
  69.     2)    Something was wrong with Mach's swapping algorithm.
  70.     3)    I was REALLY missing some vital information and if it
  71.         was in the on-line manuals I couldn't find it.
  72.  
  73.     So, that's that.  I declared myself officially stumped and decided
  74. to abase myself before the Gods of NeXT Programming via the net and beg for 
  75. some scrap of guidance.  Maybe Dennis is here?
  76.  
  77. Any ideas?
  78.  
  79. Shawn Willden
  80. swillden@cc.weber.edu
  81.