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