[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MCL2.0.1 + PPC
- To: Douglas Shiller <email@example.com>
- Subject: Re: MCL2.0.1 + PPC
- From: Gary Byers <gb@digitool>
- Date: Mon, 2 Jan 1995 01:50:40 -0500 (EST)
- Cc: firstname.lastname@example.org
- In-reply-to: <email@example.com>
- Sender: firstname.lastname@example.org
On 28 Dec 1994, Douglas Shiller wrote:
> I just loaded MCL 2.0.1 onto my PowerMac 6100/60/Sys 7.5. I am aware
> that it is supposed to be incompatible with virtual memory (for which
> there is a hack) and the Modern Memory Manager (which should be turned
> off). But here's the thing... MCL seems to work just fine on my machine
> with the Memory Manager LEFT ON (I have not installed the VM hack because
> I'm using RamDoubler). Is there a more subtle problem with the Memory
> Manager that I should be aware of? Is it possible that the Memory Manager
> is just not working properly (ie. NEVER on, even when selected in the
> memory control panel), and if so is there a way I could check to see if it
> is working properly? I would appreciate any information anyone might have.
> Thank you.
> D. Shiller
> McGill University
The only outright incompatibility between MCL 2.0.1 and the Modern Memory
Manager that I'm aware of has to do with MCL's "growzone" function. That
function - which is called by the Memory Manager when it can't otherwise
satisfy an allocation request - mucks around in various internal data
structures and stands a pretty good chance of causing heap corruption
under the Modern Memory Manager.
It's relatively straightforward to disable MCL's growzone function when
running under the MMM; it's significantly harder to patch the MCL kernel
so that its growzone function works correctly under the Modern MM. If
MCL's growzone function is disabled, attempts to create Mac data structures
that are larger than the amount of free heap space will fail; this -might-
be better than having them think that they succeeded when they've actually
fouled things up.
There are a couple of other pieces of MCL code that know more than they
should about Memory Manager data structures. As far as I can tell, they
seem to get away with it without serious consequences:
1) The lisp functions CCL:ZONE-POINTERP and CCL:HANDLEP use various
heuristics which involve examining Memory Manager Zone headers and
block headers. As far as I can tell, they aren't sensitive to
differences between the Modern Memory Manager and previous versions.
2) The kernel code which allocates the "Lisp Heap" - that portion of
the application heap reserved for the alloction of Lisp data
structures - does all kinds of Unspeakable Things to get that
block of memory allocated where it wants it to be. It's not
successful - the Lisp Heap winds up at the wrong end of the
application heap as far as "growzone" is concerned - but it
seems to (again) get away with doing Unspeakable Things. Must be
karma ... or Good Clean Livin' ... or blind luck.
I haven't seen most of the last couple of years of bug-mcl mail, so
it's possible that people have found and reported other serious
Modern Memory Manager-related incompatibilities. It's also possible
that things that seem to me to either work or to fail in a more-or-less
harmless way would fail in harmful ways in other environments. (Someone
recently replied to an info-mcl question about MCL's compatibility with
System 7.5 by saying that they had "lots of problems" until they disabled
the Modern Memory Manager in the Memory Control Panel. If they sent a
bug report to email@example.com, it's not (yet) archived where I can
get at it.)
0) All of this should be taken with a grain of salt; if people have
found and reported other MMM-related problems, I haven't (yet) seen
1) MCL's growzone function isn't compatible with the Modern Memory
Manager. If your application allocates lots of handles and pointers
in the Mac Heap and you want to try running on a PowerMac with the
MMM enabled, you're probably best off changing the default apportionment
of Mac/Lisp Heap space; see the SAVE-APPLICATION section of the MCL 2.0
Disabling the growzone function is fairly straightforward, but doesn't
necesarily make the environment more usable. Patching the growzone
function to make it MMM-friendly requires further investigation.
2) Somewhat surprisingly, other parts of the MCL runtime system that
know more than they should about Memory Manager internals seem to either
work correctly or to fail in benign ways.
3) See 0.
If anyone knows of other incompatibilities between MCL and the PowerMacs'
Modern Memory Manager, please let us (firstname.lastname@example.org) know.