Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!sri-spam!mordor!lll-tis!ames!elroy!devvax!jplpro!des
From: des@jplpro.JPL.NASA.GOV (David Smyth)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Shared libraries (Was: Re: Big Programs Hurt Performance)
Message-ID: <443@devvax.JPL.NASA.GOV>
Date: Thu, 24-Sep-87 12:29:35 EDT
Article-I.D.: devvax.443
Posted: Thu Sep 24 12:29:35 1987
Date-Received: Sat, 26-Sep-87 17:05:23 EDT
References: <6886@eddie.MIT.EDU) <2501@xanth.UUCP> <2067@sfsup.UUCP> <3009@ulysses.homer.nj.att.com> <28957@sun.uucp>
Sender: news@devvax.JPL.NASA.GOV
Reply-To: des@jplpro.JPL.NASA.GOV (David Smyth)
Organization: Jet Propulsion Laboratory, Pasadena CA.
Lines: 34
Xref: mnetor comp.arch:2328 comp.unix.wizards:4452 comp.os.misc:228

In article <28957@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes:
>> >It's not too uncommon that a new version of a program comes along, but some
>> >people still want to use the old version, for whatever reason.  
>> 
>> You have to relink with the unshared version of the old library.
>
>You do in some, but not all, implementations.  An earlier article indicated
>See "Shared Libraries in SunOS" from the last USENIX proceedings for another
>Of course, this requires you to keep old versions of the library around, but
>you can't have everything; if this causes a disk-space problem, you might have
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>to link with an unshared version of the library.
>	Guy Harris

How is COPYING the old shared libraries into executables which need 
them ANY savings in disk usage?  It seems it will be a DEAD LOSS:
core (bigger executable images); virtual memory (it gets used up even
if paged out);  AND disk space (the executable file gets bigger for EVERY
program which needs the unshared library).

Why EVER have unsharable libraries???  

Why EVER have libraries specifically linked to an executable???
	a) If it is an application which makes repeated calls
	   to a library, the FIRST invocation may be slower, but
	   all following invocations can be VERY CLOSE to the same
	   speed [Message/Object Programming, Brad J. Cox, see 
	   table 1].
	b) Speed Critical Applications probably want to be vectorized,
	   and I would think reducing the competition for core via
	   shared libraries would be a BIG win if swapping is reduced
	   even a little bit (I don't know much about vectorized
	   algorithms, I only work on these archaic Suns, Vaxen, and
	   such Von Nueman rubbish :^) ).