[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Strange situation
- From: firstname.lastname@example.org (Mark Preece)
- Date: Fri, 25 Jun 1993 17:04:31 -0500
> There is a way to allocate more memory to the Mac heap before
>Go into ResEdit and open up MCL.
>Double click on LSIZ.
[and so on...]
>NOTE/WARNING: The above is a true hack. I have read no documentation and have
>no real knowlege in this are. It does however seem to work.
We built a (slightly) more elegant interface to setting the Mac heap size
into MCL 2.0. It was too late to make it into the Reference Manual, but
it's in the MCL 2.0 Release Notes. Here's the story:
SAVE-APPLICATION takes a new keyword argument :MEMORY-OPTIONS. This
argument gives you some control over how the saved application apportions
and uses the memory available to it. The value of the :MEMORY-OPTIONS
keyword argument is itself a list of keyword/value pairs, which are
interpreted as follows:
Keyword Default value
Given an application partition size of n bytes, the MCL kernel reserves roughly
(min mac-heap-maximum (* n (/ mac-heap-percentage 100)))))
bytes for the "mac heap", and roughly
(min stack-heap-maximum (* n (/ stack-heap-percentage 100)))))
bytes for MCL's control and value stacks. (Each stack uses roughly half of
The MCL kernel signals an "OUT-OF-MEMORY" condition when, after GC, free
space in the lisp heap is less than the value of the :LOW-MEMORY-THRESHOLD
If free space in the lisp heap exceeds the value of the
:COPYING-GC-THRESHOLD option when the application starts up, the MCL kernel
arranges that a two-space copying GC algorithm is used for (non-ephemeral)
garbage collection. This algorithm may improve GC performance in some large
VM environments, at the cost of roughly halving the amount of memory
available for the allocation of lisp objects.