NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/sys/mac/system/11801

Internet Message Format | 1992-09-11 | 3.7 KB

Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!data.nas.nasa.gov!taligent!apple!mumbo.apple.com!gallant.apple.com!kip2-27.apple.com!user
From: [e-mail] (Scott Boyd)
Newsgroups: comp.sys.mac.system
Subject: Re: 7.x.x Finder Heap Allocation ?
Message-ID: <[e-mail]>
Date: 11 Sep 92 08:26:21 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Followup-To: comp.sys.mac.system
Organization: Apple Computer Inc.
Lines: 72

In article <[e-mail]>,
[e-mail] (Sven Grenander) wrote:
>
> In article <[e-mail]>, [e-mail] (Scott Boyd) writes:
> >
> > In article <[e-mail]>,
> > gpb@gpb-mac. (greg berryman ) wrote, suggesting that you alter the Finder
> > to give it a larger heap.
> >
> > Don't do this.  It won't get you what you want.  Finder has two sub-heaps,
> > and their sizes are fixed.  You won't be altering their sizes when you
> > adjust
> > the Finder's heap size.
> >
> > It is far more likely that you are running out of Finder heap because some
> > poorly-written software is allocating memory in other people's heaps,
> > including Finder's.  You might try looking through your extensions to
> > see if you can spot the offender.
> >
> > scott
> > [e-mail]
> >
> >
> Scott,
>
> Given your address I would assume that you know what you are talking about,
> but empirical evidence overwhelmingly shows that increasing the Finder
> heap size reduces the problems that I (and at least a few others) have had.
> If you are correct, then the empirical evidence seems to imply that the
> increased Finder heap allocation cures the symptom (OOM warnings and random
> crashes) but not the underlying problem (misbehaving extensions was your
> suggestion).

Increasing the heap size masks the problem, but does not FIX the problem.


> Do you have any suggestions for how one would go about tracking down these
> underlying problems ? Is there for example any system 7 MemWatcher utility
> which could help trap offending apps or extensions ?

The simplest technique is to remove all of your extensions, and add them
back, one at a time, and try to reproduce the problem.  This can be
tedious,
but can also be fairly reliable.

More advanced techniques are available to those with the skills.  While it
might be fun (for some people) to learn those skills, I'm not up to trying
to teach these things via e-mail.

> A review of IM VI is no doubt in order if one is to understand the two sub-
> heaps that you mention, is there some other information source that you can
> recomend, such as a TN or something similar which addresses this specific
> issue ? In particular, is there any reference which describes how a fixed heap
> can satisfy the requirements from the lowest Mac to one at the high end with
> dozens of simultaneously running apps, tens of disk partitions, zillions of
> open windows over half a dozen monitors, gobs of open files and
> who-knows-how-many extensions ?

How can you write an app so its heap is small, yet still satisfactory for
a wide range of memory-consuming activities?

The technique is one anyone can use, and involves using temporary memory.
Inside Macintosh Volume 6 details the use of Process Manager temporary
memory.  The concept is simple Q put only what you have to in your own
heap, and do everything else with temporary memory.  Not all applications
are really suited for this approach, but many are.

Scott Knaster's books also are rich with tips and techniques for wise
use of limited memory resources.

scott
[e-mail]