Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!hpfcso!mjs
From: mjs@hpfcso.FC.HP.COM (Marc Sabatella)
Newsgroups: comp.unix.internals
Subject: Re: shared libraries can be done right
Message-ID: <18370002@hpfcso.FC.HP.COM>
Date: 30 May 91 17:54:13 GMT
References: <20May91.042630.9136@franklin.com>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 64

>There's something to be said for either end of the spectrum. With
>a small granularity, you don't have to load in the entire
>executable (or the pages with shared references, anyway); you can
>just load what gets used

This happens trivially anyhow with demand loading.  Using the scheme we
developed for HP-UX, you can get at least object module granularity on your
relocations, so "demand" is only for a module at a time.

| Suppose you have two shared libraries that define the same
| symbols; perhaps they are different versions of the shared
| library. Some program comes along and runs the first and then runs
| again using the second. The second invocation of the program has
| to consider itself to be not shared with the first invocation; its
| shared text isn't, in this case, shared. Actually, you could
| share those pages of the text which don't make reference to the
| differing shared libraries. Life gets complicated if you do that,
| I think. Still, it might be worthwhile if it can be done
| efficiently, because it would mean that some of the more common
| situations don't cause problems with wasted memory.

This is why we normally use jump table.  They really aren't that big a deal.
Share the whole text, no fixup necessary except to a table in the data segment.

| This situation, one would hope, doesn't occur often.

No, but an analagous one does: some systems provide two versions of malloc()
located in different libraries.  Almost every library in the world calls
malloc() at some point, so there is the potential for a reference not being
shareable.  Again, indirect calls and data references (as opposed to merely
"PC-relative code") solve these problems with not a lot of overhead.
Particularly if you only use the indirection on references you "expect" to be
intercepted.

: In
: the shared case, swap is reserved for the whole library's data segment, but in
: the archive case, only those few modules needed by the program are copied into
: the a.out, so the data space for the rest of the library needs no swap at run
: time.  We measured up to 100K of "wasted" swap per process for Motif
: applications.

>The trade-off, then, is between the allocated space in swap for
>each running process, vs. the disk space saved for the
>executables? Is there any other way to avoid the swap deadlock I
>assume is the reason for allocating for the worst case?

Sure - arbitrarily kill off a process.  But it is so much less painful to not
let a process start up than to kill it once has started.  Do you really want to
see your X server die because some trivial "ls" is using all the swap at the
moment?

>Another solution to this problem is to use smaller shared
>libraries, instead of a monolithic library. At least in my scheme,
>this doesn't involve much additional overhead, so it would be the
>easy solution.

I agree with this, but note there is more VM overhead associated with having
lots of small libraries than their is with a few monolithic ones.

--------------
Marc Sabatella (marc@hpmonk.fc.hp.com)
Disclaimers:
	2 + 2 = 3, for suitably small values of 2
	Bill and Dave may not always agree with me