Shared libraries

[Anton Rang]

In article <1991May3.134905.42465 at eagle.wesleyan.edu> amolitor at eagle.wesleyan.edu writes:
>	I've not noticed anyone mention the VMS implementation. It's my
>impression that the VMS shared library system is Done Right.

  I'd agree, though it's not *quite* as good as you make it out to be.
(Oh no, I'm finding myself on the other side!  Yay!  :-)

>I believe that VMS a) uses the copy-on-write abilities of it's memory
>system to deal with static data areas gracefully

  Close; actually, though, it uses copy-on-reference, which isn't as
good as copy-on-write would be.  (At least, VMS 4.x does--I don't have
current documentation on VMS 5.x.)  When a (writable) data page is
faulted in from the shared library, a private copy is made for the
process, whether the access was a read or a write.

>and b) has proper load-time linking to libraries -- i.e.  calls to
>library routines are exactly the same as any other call. There is,
>therefore, no performance hit besides the startup (both in linkage,
>and in copying on write of data areas).

  Nope.  It's a little questionable what the "correct" way to link to
a shareable library is, actually.  If you go through the original
image and fix up all of the calls, you may fault in the entire image
in the process, and you also violate the read-only condition (so that
it can no longer be paged from the image on disk, but must be in the
swap area or page file).

  VMS normally takes the approach of making function calls to shared
images go through one level of indirection.  At link time, a table of
functions from shared images which are referenced by the main image is
built; calls to functions are replaced by indirect calls through a
cell in this table.  At load time, this table is filled with the
correct addresses.  A call within the main image is absolute; a call
in the shared library is absolute-indirect.

  If enough registers are available, a good compiler could get rid of
most of this overhead (in loops, at least) by loading the address of
the function being called into a register and taking it out of the
loop.  This would be especially easy on RISC systems.

  (It is also possible to ask VMS to have every reference, or some,
fixed at load time, avoiding the indirection at the cost of increased
fixup time.  This must be done when static data is referenced from a
library.  As before, this temporarily violates the read-only
constraint on code, so that space in the swap file must be allocated,
and the code cannot be shared between processes.  Of course, VMS
doesn't normally share code of programs among processes only--a BAD
design decision, IMHO--so it's not as much of an impact as it would be
on UNIX.)

>This is typically more than made up for by the performance GAIN
>achieved by not loading 100K of library routines when you execute the
>image.

  True, at least under VMS....

  A few other things about VMS's shared libraries:

    * They have version numbers done in a relatively reasonable way.
      There is a major version number, and a minor version number.
      This is checked against the version of the library which was
      used when linking a program; it is possible to specify several
      constraints on the use of the image (e.g. require an exact
      match, or require that the major version be exact and the minor
      version no less).

    * Each image (the main image, and shareable images) can have an
      initialization routine.  These are automatically called in an
      appropriate order (topological sort).  This lets run-time
      initialization be done pretty easily (useful for some languages
      though not really in C).

    * There is a user-callable function which will search for a given
      function and map the shareable image containing it into address
      space (if it isn't already).  This dynamic loading is done
      essentially using the existing shareable library loading code.

	Anton
   
+---------------------------+------------------+-------------+----------------+
| Anton Rang (grad student) | rang at cs.wisc.edu | UW--Madison | "VMS Forever!" |
+---------------------------+------------------+-------------+----------------+