[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MCL and virtual memory.
- To: ST7990@SIUCVMB.SIU.EDU
- Subject: Re: MCL and virtual memory.
- From: firstname.lastname@example.org (Bill St. Clair)
- Date: Thu, 2 Jul 1992 17:34:30 -0500
- Cc: email@example.com
>I need to know how MCL makes use of System 7's virtual memory facility. Does
>it actually use paging for its Lisp heap and control stack? Also I belive it is
> necessary to predefine application size; in which case is this size limited
>to primary RAM size or is virtual memory applicable.
Gary knows more about this than I and I may have some of it wrong,
but here goes.
MCL 2.0b1 will work with MacVM enabled. Application size is limited to
room left in the virtual memory. Garbage collection when MCL's partition
is a lot larger than physical memory takes a long time (hours). MCL 2.0
final's ephemeral garbage collector will mitigate this problem somewhat
by delaying the need to do full garbage collection. Also, MCL 2.0 final
has a copying garbage collector option, which has better paging behavior
than the mark/sweep/compact algorithm. I have not heard about any
experiments with the copying GC under VM, though I expect that it will
be about 2 to 3 times as fast.
I spent a few years programming Symbolics machines. I typically had
1 or 2 megawords of physical memory swapping to 30 megawords of virtual.
All was fine as long as the EGC was doing most of the work. As soon
as real garbage collection started, I usually booted the machine;
it was impossible to get any work done. Running MCL in an environment
with a lot more virtual than physical memory will be similarly unpleasant
once a full GC is necessary.
Conclusion: you can run MCL in virtual memory, but unless you like
taking the afternoon off when a full GC happens, you should make sure
that MCL's partition size is not much larger than your machine's
physical memory. If you need to do some batch processing on huge
data, you may find it useful to run MCL in a partition that is
larger than physical memory.
Another problem with MCL 2.0b1 in virtual memory is that the hash
table implementation has very bad locality (it hashes to alists).
MCL 2.0 final puts all of the keys and values in a single vector,
hence it will behave much better under VM.