Shared system routines

Hal Perkins hal at cornell.UUCP
Sun Jul 31 10:23:35 AEST 1983


Someone made a remark about the Univac 1100 EXEC 8 "common banks".
This was something of a kludge, but it did allow shared libraries
WITHOUT having to make changes to the existing compilers or loaders,
and old programs could take advantage of the shared library by just
relinking them.

It worked something like this.  The shared routines were kept in a
common area of virtual memory (that's the basic idea--the details
are much more grungy and you probably don't want to know them).
[On a VAX, this could be done by placing the shared routines in the
system 1/4th of the virtual memory and using common page tables
for all users.]  The shared routines were preceded by an address
vector, and all calls to shared routines went through this vector.
Thus, shared routines could be modified and moved around in memory
as long as the pointer was updated.  This avoided wiring absolute
entry point addresses into user programs, and meant that programs
always used the currently installed version of the routines.

The interesting thing is how this was made to work with old user
programs.  In the system libraries, the existing routines were
replaced by little stubs that had exactly the same calling
sequence as the old (non-shared) library routines.  These stubs
jumped to the appropriate shared routine to do the work.  The
stubs were linked with compiler object files to produce absolute
files just as before.

But once this change was made, the size of absolute files
shrunk by almost the entire size of the library routines, and
this was achieved without modifying any of the compilers or
loaders.  Eventually, some of the compilers were modified to
call the shared library directly (I believe), which eliminated
the small overhead of calling the shared library through the
stub routines.

I can't see why it wouldn't be possible to implement a similar
setup in Unix, at least on systems with large virtual memories.
The savings in disk space for linked files and the reduction in
individual program working sets might well be worth the small
cost in extra CPU time needed to call shared routines indirectly.

Any volunteers?  I am not a qualified wizard and don't have
any spare time to attempt something like this even if I knew
enough about the system to do it.


Hal Perkins                         UUCP:  {decvax|vax135|...}!cornell!hal
Cornell Computer Science            ARPA:  hal at cornell  BITNET: hal at crnlcs



More information about the Comp.unix.wizards mailing list