[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SUN vs Lisp machine hardware differences?
Date: Fri, 07 Aug 87 11:43:25 PDT
From: larus%paris.Berkeley.EDU@berkeley.edu (James Larus)
I should also take an opportunity to clarify my remark above in
light of Weinreb's reply to it that accused me of confusing virtual
and physical address space. The two concepts are different, but not
separate. I see two advantages of the process model in this respect:
1. When a process terminates, the OS can reclaim both address spaces.
In a single address space, the best you can hope to do is to page out
the task's pages.
OK, it can reclaim an address space. How does that help you? The
important resource is not the total number of address spaces times the
size of one address space, but rather the total size of a single address
space. Having "more address space" where the additional space is a
differenent address space doesn't solve the problem.
However, these pages are likely to contain other
tasks' code and data (internal fragmentation) that reduce the
effectiveness of paging.
First, this is alleviated by garbage collection. Second, keep in mind
that this works both ways: when you have many address spaces, the same
code generally appears many times, once in each address space, and
therefore occupies more virtual memory, which means more disk space.
Also, the many processes page against each other: one process's copy of
routine X needs to be paged out to make room for another process's copy
of routine X. (This isn't a problem in a Multics-like structure, but
it is definitely a problem in a Unix-like structure.)
This means that statements like "you will never run a real Lisp on a
Sun because you don't have 2^X byte address spaces" are meaningless.
You don't need 2^(X-1) bytes of address spaces for the system code.
You don't need that much for system code on any system. The system code
occupies a tiny fraction of a 36xx address space. It doesn't make any
difference.
2. Each process is a separate address space can be managed with
different policies as to their working set and paging algorithms. I
can't see how to do this directly in a single address space except to
put the burden on the program (you know the arguments against that
one).
Easy. The 3600 divides up virtual address space into areas, and each
area can have its own policies. We've been doing this for a long time.
There's no particular reason it has to be tied into the notion of
"process". No burden is placed on the program.