Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!ncar!gatech!bloom-beacon!eru!hagbard!sunic!news.funet.fi!funic!santra!hila.hut.fi!jmunkki
From: jmunkki@hila.hut.fi (Juri Munkki)
Newsgroups: comp.sys.mac.programmer
Subject: Re: malloc() in Think C programming on the Mac
Message-ID: <1991Jan26.190058.3270@santra.uucp>
Date: 26 Jan 91 19:00:58 GMT
References: <1991Jan24.060336.12684@nlm.nih.gov> <4978@awdprime.UUCP>
Sender: news@santra.uucp (Cnews - USENET news system)
Reply-To: jmunkki@hila.hut.fi (Juri Munkki)
Distribution: comp
Organization: Helsinki University of Technology, FINLAND
Lines: 49

In article <4978@awdprime.UUCP> eswu@ub.cc.umich.edu writes:
>I've been using NewPtr() and NewHandle() instead of malloc().
>Does any ``real'' Mac programmer know what we are really
>suppose to use, especially for programs that really beat on
>garbage collectors? 

I think we are supposed to avoid allocating a lot of handles
and pointers with the memory manager. If a program I'm writing
requires more than a few allocated blocks, I always write my
own memory management routines. Usually I allocate one or two
handles and resize them in chunks.

For example, Dizzy, a digital circuit simulator, uses a single
NewHandle and then uses ResizeHandle to allocate memory in
blocks of 32KB. I have my own garbage collection routines
and a routine that allocates memory from this "heap".

I try to avoid locking. Most of the time the handles I allocate
just float there. All references to these structures are defined
as offsets from the beginning of the block or handle-like with
my own (unlocked) "master pointer block" (allocated as a handle).

I have never noticed any delays caused by memory allocation in
this way. The only way to make Dizzy slow is to make the chunk
size really small (using 64 bytes usually does the trick). The
chunk size I use is never hard-coded, so I can modify it to be
really small, if I want to track down memory allocation bugs.

The terminal program I'm using right now has a buffer for lines
that scroll offscreen. That buffer is now set to 2500 lines and
the allocation block size is 8192 bytes. The program does garbage
collection on this structure, if more than 16384 bytes are wasted.
So far, I've never noticed any pauses because of memory management.

I never use malloc on a native Macintosh program and I use NewPtr
only to reserve memory for the whole lifetime of the program.
(You could probably find a few NewPtrs that allocate temporary
memory inside a subroutine, but using a NewHandle and a HLock
would actually be faster, since the memory is not allocated
from the bottom of the heap.)

Luckily for programmers, desk accessories no longer wreck havoc on our
memory management schemes, if the program is running under multifinder.
FKEYs and trap patches can still manage to foil even the best efforts.

   ____________________________________________________________________________
  / Juri Munkki	    /  Helsinki University of Technology   /  Wind  / Project /
 / jmunkki@hut.fi  /  Computing Center Macintosh Support  /  Surf  /  STORM  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~