Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uwm.edu!linac!midway!quads.uchicago.edu!jcav
From: jcav@quads.uchicago.edu (john  cavallino)
Newsgroups: comp.sys.mac.hardware
Subject: Re: Mac IIfx running VERY slow - solution
Message-ID: <1991Mar26.163513.14403@midway.uchicago.edu>
Date: 26 Mar 91 16:35:13 GMT
References: <40366@cup.portal.com> <1991Mar26.134620.27192@bmers95.bnr.ca>
Sender: jcav@midway.uchicago.edu (john  cavallino)
Organization: University of Chicago
Lines: 26

In article <1991Mar26.134620.27192@bmers95.bnr.ca> slang@bmerh563.bnr.ca (Steven Langlois) writes:
>In article <40366@cup.portal.com> ekalenda@cup.portal.com (Edward John Kalenda) writes:
>
>	>I got an answer: The memory manager code in MacOs seems to have a
>	>problem on the IIfx. Apple has an INIT called MMInit which takes
>	>care of the problem. Presumably anybody can get a copy of this from
>	>Apple or a distributor for free.
>
>Could someone post MMInit to comp.sys.mac.binaries.

There was an article recently from the guy at Apple who wrote MMInit.  His
basic point is that MMInit is a hack, and is only needed for the users of
one or two applications that are bitten by the Memory Manager bug, which
ONLY hits those apps that allocate large numbers of non-relocatable
blocks.  He says that MMInit is known to cause an increase in the frequency
of system crashes, and that if you're not running those particular apps
(sorry, can't remember their names) it would be better to wait for System
7, which fixes this and other bugs.  BTW, the bug exists on all machines
with the 32-bit-clean Memory Manager (IIci, IIsi, IIfx, also LC I think).


-- 
John Cavallino                      |     EMail: jcav@midway.uchicago.edu
University of Chicago Hospitals     |    USMail: 5841 S. Maryland Ave, Box 145
Office of Facilities Management     |            Chicago, IL  60637
"Opinions, my boy. Just opinions"   | Telephone: 312-702-6900