Shared runtime libraries - SV shared memory?

[Dave Brower]

  In a random discussion with a co-worker the other day, I recalled a
scheme for reducing the size text segments of programs used in an
otherwise excreble and unnamed operating system:  Shared runtime
libraries.  Though I have no current application, it seemed like an
interesting topic to bounce around.

  It works like this:  You link the pure code of common routines
(libc for example) into a module, keeping the symbol table around.  This
module is loaded into a publicly accessible part of memory either at
boot time (like a daemon) or on demand by client programs.

  When the client program is linked, it is resolved to the symbol table
of the previously linked shared library.  When it fires up, somehow it
attaches to the runtime library and goes along its merry way, sharing
the code with all other active client programs.  None of the clients has
the common code in its text segment.  Note that this is NOT the much
discussed dynamic linking-- the symbols are completely resolved when the
client program is created by the loader.

There are some interesting benefits on systems with marginal resources,
e.g., workstations with < 300 mB disk and < 4mB memory:

  (1)  The size of all the clients AS STORED ON DISK would be reduced by
the amount of common library code used.

  (2) The amount of physical AND virtual memory used for each process
could be reduced by the amount of common code used.

Some obvious difficultites are:

  (1)  Ensuring that the executables are resolved to the currently
loaded version of the library.  This can probably be solved with version
and/or time stamps.

  (2)  OS and/or Hardware support.

  On operating systems that support numerous segments, it is simple
enough to stash the library in some reserved and public segment.  Things
are less clear on UNIX.  My current sketchy thinking involves the use of
System V shared memory and runs along the following lines.  It  assumes
that a shared memory segment can be made both executable and read-only.

  (1) A client program forks and execs a common library process, which
sets up a shared memory segment for the client to use.  This involves
many library processes, but all presumably have the same text segment
and a set sticky bit so that it is not too expensive in terms of real
memory or execution time.  The major cost is having a separate shared
memory segment for each client process, of which there are probably only
a small number available because of hardware limitations.

  (2) A library daemon sets up a well-known shared memory segment that
can be used by multiple client programs.  There is likely some limit on
the number of processes that may attach to a shared memory segment.

The major trick is in figuring out how to link the client programs.
Where would one locate the library code?  It would need to be at the
same fixed location for all client programs.  On an intellegent virtual
system, you could just stuff it a bunch of meg past the end of the space
you're really going to use.  You're in trouble if the system creates
disk pages for the holes between your real data and the library.  On
dumber systems, like System V's that swap, you'd probably want to start
at some low address, like 0.  But you'd lose most of the size advantage
if the load image had to have a big physical hole where the library
segment was to be mapped.  And you'd like to be able to have the client
be  able to attach to multiple libraries.  Then there's the nettlesome
problem of doing something smart with the impure data used by the
library.  Well, I didn't say it would be simple!!!

Questions about the sanity of the idea belong in net.arch; ideas about
how to do this for real belong in net.unix-wizards(?).  Please send
truly inspired flames by mail-- I'll summarize the best to the net :-)

WARNING: Don't try to reply via the .ARPA in the send path.  It won't work.
-- 
{amdahl|dual|sun|zehntel}\			| Overheard in Berkeley:
{ucbvax|decvax}!mtxinu    >!rtech!daveb 	| "Have you got an Apple?"
ihnp4!phoenix ___________/			| "Oh, yeah, of course."