From: utzoo!decvax!harpo!floyd!cmcl2!philabs!sdcsvax!sdchema!jmcg
Newsgroups: net.unix-wizards
Title: Shared libraries
Article-I.D.: sdchema.483
Posted: Thu Apr  7 23:28:25 1983
Received: Fri Apr  8 06:11:02 1983
References: ariel.276 unc.4910

Printf should not be a system call.  System calls should be reserved
for functions requiring access to something not available to the
process by normal means.

Shared libraries would provide all the advantages claimed.  Only one
copy of the library needs to be kept in memory.  Only one copy of the
library's routines needs to be kept on disk.  Linking and loading would
be faster.

The main reason that shared libraries are not a part of UNIX is because
they were not reasonable on PDP11s, where dedicating a chunk of address
space to the library would have decreased the amount of space available
to programs (few programs load the ENTIRE library, after all).

Besides having to consume enough address space to hold the entire
library, there are other implementation decisions that have to be made
for shared libraries.  A scheme for dynamic linkage is needed, to allow
for loading the library initially and to allow for updating it without
rebooting the system or having to recompile everything.  For instance,
VMS uses a transfer vector at the front of the library so that a
particular routine does not get a new address when the library is
updated.  On large Burroughs systems, the operating system would trap
on the first call to a library routine, load it if necessary, and then
patch in the address so later calls would take place without overhead.

The code in a shared library generally must be position-independent and
access to static data must use indirection, since its location is not
known at the time the library is linked.  These restrictions can be
avoided by reserving fixed locations in address space for library text
and data, but this approach has several drawbacks making it difficult
to use several shared libraries, and, on the VAX, wastes page table
space; plus, you have to find a place that will satisfy everyone.

Shared libraries offer significant performance advantages, so they will
eventually occur despite their requiring an extension to the UNIX
process architecture.  We should see them implemented at the same rate as
we see the PCC replaced (or supplemented) with C compilers that do a
much better job of generating code on their particular machine: i.e. it
is a machine-dependent improvement that is only likely to occur as
manufacturers start supporting UNIX.

In their talk at Winter UNICOM in San Diego, Glenn Skinner and Bill
Jolitz talked about their plans for shared libraries for UNIX on the
16032.  Neither SUN nor Berkeley has mentioned similar plans for
4.2BSD, but some of the new virtual memory capabilities planned would
make it easier to do.
							Jim McGinness
		sdcsvax!jmcg	(619)452-4016		UC San Diego, Chemistry
	   or	decvax!jmcg