🚀 go-pugleaf

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