No subject
utzoo!decvax!ucbvax!unix-wizards
utzoo!decvax!ucbvax!unix-wizards
Wed Oct 28 20:48:09 AEST 1981
>From decvax!duke!somewhere!duke!bcw at Berkeley Wed Oct 28 19:56:49 1981
(Bruce C. Wright at Duke University)
Subject: Memory management
The DEC operating systems do indeed do things differently
than Unix in the memory management area. Whether they are
worse as Greg Ordy implied is a matter of opinion; their
capabilities are structured differently in a way which
makes exact comparison difficult.
The DEC operating systems (PDP-11 only now -- the others
don't have to worry about i/d space and so forth) will be
taken as including RT-11, RSX-11 (in it multitudinous forms),
IAS, RSTS, and DOS. All of the others (such as TSX, COS, and
so forth) are basically derivitives of one of these systems.
None of them support i/d space reasonably (the latest version
of RSX-11M/PLUS supports i/d space in the kernel and allows
a user to create i space regions -- which must be done with
an explicit syscall, it isn't transparant like it is in Unix).
RSX-11M/PLUS also supports the use of supervisor mode libraries
which allow some appropriately-written language runtimes to be
moved into supervisor mode on machines which have it. This
can obviously greatly reduce the demand for space in user mode
and in some cases make the i/d space issue moot.
But the support of i/d space is not the only feature which
might be interesting. The multi-user systems (RSX-11, IAS,
and to a certain extent RSTS) allow the sharing of segments
of text and data which are common to multiple programs, rather
than the more restrictive version on Unix which allows the
sharing of text and data across multiple copies of a single
program. This allows things like language runtimes to have
only one copy in memory which can significantly reduce memory
contention.
The DEC systems also support overlays, which although as usual
a hassle goes a long way to making up for the lack of i/d
space separation. It is also possible in some of the systems
to declare "memory-resident" overlays, which look logically
like normal overlays but which put all of the segments in
memory rather than on disk; overlay segments are selected by
manipulating the PDP-11 mapping registers with system calls.
This is implemented on top of a more general feature which
allows the manipulation of arbitrary-sized memory regions,
using a mapping register as a window pointer into the larger
region.
The use of forks to simulate overlays can be inefficient, not
to mention inconvenient for the programmer, when there is a
lot of data which has to be moved between the segments.
The overall effect of all this on the useability of the memory
management system is unclear, and probably is highly dependent
on the specific problems being addressed and the performance
constraints placed on the solution. Certainly there does not
seem to me to be a clear-cut superiority for either the DEC
memory management systems or for the Unix system.
Bruce Wright @ Duke University
More information about the Comp.unix.wizards
mailing list