Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!hc!beta!cmcl2!rutgers!bellcore!faline!hammond
From: hammond@faline.bellcore.com (Rich A. Hammond)
Newsgroups: comp.arch,comp.os.misc
Subject: Re: Shared libraries (Was: Re: Big Programs Hurt Performance)
Message-ID: <1441@faline.bellcore.com>
Date: Tue, 29-Sep-87 07:30:28 EDT
Article-I.D.: faline.1441
Posted: Tue Sep 29 07:30:28 1987
Date-Received: Thu, 1-Oct-87 02:39:29 EDT
References: <6886@eddie.MIT.EDU) <2501@xanth.UUCP> <2067@sfsup.UUCP> <443@devvax.JPL.NASA.GOV>
Reply-To: hammond@faline.bellcore.com (Rich A. Hammond)
Organization: Bellcore MRE
Lines: 39
Xref: mnetor comp.arch:2418 comp.os.misc:252

In article <> shap@sfsup.UUCP (J.S.Shapiro) writes:
 [much discussion of shared libraries being dynamically modified] ...
>
>There is a technique which can be used to avoid all this which is to have
>an indirection table and a directory in each library, or a
>well-known-globals list, as someone suggested, but this implies a
>remarkable performance hit.

I assume by this he means avoiding modifying the shared library or the
binary image of the process.

>In short, it ain't all as easy as it sounds, which is why most compilation
>systems still don't support it at all.
>
>And that is why you want non-shared libraries.

I don't know how you come to the conclusion that it is a "a remarkable
performance hit" to support statically linked shared libraries.  On the VAX,
M680x0 and National 320X0 families each subroutine call requires an extra
jump instruction from the indirection table to the actual code.  You can
link things so that the globals are all adressed exactly as they would be
in a normal (non-shared) library executable, so the only "hit" is the cost
of the extra jump.  From my memory of when I worked on this, the most
frequently called items in the shared library are the assembly language
glue to system calls and printf/sprintf/...  All of these take enough
time that the overhead of a single extra jump is not going to be a big loss.

Compare this to the savings from sharing the library, i.e. less space used
in memory, less I/O (PAGE FAULTS?) to handle as the process runs, ...

As the people from SUN might point out, the really big wins for shared
libraries are when you have large libraries, such as the window system,
or when your I/O is painfully slow relative to the CPU speed, i.e. a
25 MHz 68020 using a disk across the ethernet.  How many jumps can a
68020 do while waiting for just 1 block to come across the ethernet?

And that is why you want shared libraries.

Rich Hammond	Bell Communications Research	hammond@bellcore.com