an alternative view of memory management

[Richard Kwan]

In <6234 at utzoo.UUCP>, Henry Spencer wrote:
>...  For lack of
>anything better, net.unix or net.micro would be the obvious places for
>this one. ...
>...Over and over again, groups have
>been created as the result of popular enthusiasm, only to fizzle and
>die because nobody ever submitted anything to them after the first week.

This article really belongs in net.os/mod.os.  At the risk of being
flamed out of existence for impatience, I thought I would show a little
interest in the proposed group.  (...Halon system enabled... :-} )

-----
I assume that a large number of the UNIX utilities use a lot of common
code, e.g., strcmp(), strcpy(), bcopy(), etc., etc.  ...that is, many
of the things that can be found in 'libc.a'.  Certainly, my own code
is riddled with such things.  This means that as executable files are
created, they include a considerable amount of code which has been
duplicated elsewhere, i.e., in other executable files.  This is
certainly the case for PDP-11 UNIX systems, probably VAX systems, many
68000 systems, etc.

It means that disk space has to be sufficiently large to hold all
the duplicated as well as unique code.  This is probably a stumbling
block in getting a well-endowed UNIX system onto a PC, whether IBM PC
or anything else.  (The people at Interactive Systems in Santa Monica,
CA, probably have a better insight into this.)

My Smalltalk friends have got me thinking...

Suppose (1) executable files are unlinked executables and the ".o"
files that they refer to, instead of fully linked executables, and
that (2) upon a trap to an unknown routine(), the system resolves
the address or loads in the appropriate ".o" and then resolves.
The following positive results should occur:

    1.  Less disk space should be required for executables.
    2.  Many of the ".o" files needed for address resolution should
        already be in main memory.
    3.  The amount of paging and swapping for a given work load should
        go down or disappear.
    4.  Option-driven code (e.g., code selected by various "-" options
        in UNIX commands) which is rarely invoked will rarely take
        up space in main memory.
    5.  The amount of main memory required to support a given mix of
        application code should go down.  (But see item 2 below.)

The following negative results should also occur:

    1.  Additional memory accesses would be needed to reference
        routinetinaddresses from a table rather than the immediate
        instruction stream.
    2.  Kernal code and data space would be required to support
        resolution.

(There are probably hardware solutions to item 1, but I haven't heard
of any being implemented.)

As for getting it implemented, memory management of position independent
code which is shared by different process address spaces would be a
major kernal rewrite, akin to adding demand paging to UNIX/32V.
Furthermore, a new "C" compiler and linker would be required.

People and articles seem to indicate that the following systems are
implemented this way:  Multics, AT&T 7300, National's GENIX, Apollo
DOMAIN.  (Any of this list incorrect?  Smalltalk is similar, but only
uses a single address space.)

Slowly, I am beginning to favor this approach for the following reasons:
    1.  CPU speeds are increasing; disk seeks do not seem to have
        kept pace.
    2.  As applications get more sophisticated, they seem to require
        more and more common code.
    3.  Paging is now a common feature of small systems (well, super-
        micros, anyway).  Thus, there is a mechanism for caching small
        routines.  (I don't think you could do this on a PDP-11.)

Alas, this is not a standard feature of UNIX; nor would I expect it to
become one (...not as long as people keep their sights on IBM PCs).
Nor do I know how well the above named systems implement this type of
strategy.

You operating system architects and aficionados out there, your comments
are appreciated.  (And when net.os or mod.os gets started, please
direct your responses there.)

        Rick Kwan
        JPL
-----
(I am keeping the asbestos suit handy :-} )