Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!elroy.jpl.nasa.gov!sdd.hp.com!hplabs!hpfcso!mjs
From: mjs@hpfcso.FC.HP.COM (Marc Sabatella)
Newsgroups: comp.sys.hp
Subject: Re: Demand-loaded vs. Shared binaries
Message-ID: <7370420@hpfcso.FC.HP.COM>
Date: 25 Jun 91 16:47:23 GMT
References: <4670@bnr-rsc.UUCP>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 44

>A program linked only as "shared-library", would have all necessary shared-
>library segments linked in at run-time.  Thus, program startup is affected,
>and all the linking goes on.  Also, run-time memory usage is affected, since
>the program gets on the library code, even if some of it is NEVER used (e.g.
>a program that uses printf() only when there's an error message to print).
>
>A program designated as "demand-loaded" will NOT get all required library
>routines (or whole libraries, I'm still unclear on exactly what gets linked)
>linked at run-time.  Instead, some things will not get linked until it is
>actually needed.  This is supposed to reduce program startup time, since
>there is less initial linking.

These are two entirely different concepts.

Shared executable versus demand magic executables work as I described
previously.  Entirely orthogonal to this is whether you link with shared or
archive libraries - ie, you can link with a shared library and still specify
either shared or demand load for the executable.  The default is to link
against shared libraries, and the default for SHARE_MAGIC / DEMAND_MAGIC is
not specified.  On the 300/400, SHARE_MAGIC is chosen if the executable is
"small enough", where small enough changes from release to release depending on
the characteristics of the VM system.  Demand loaded files contain an average
of 6K of extra padding which can be significant in a file of around 10K or so.
And with shared libraries, most simple programs will be smaller than that.

With shared libraries, the code and data from the library is not copied into
your executable file, so the a.out is much smaller.  The libraries are attached
to your process at run time.  Shared libraries are demand loaded in that the
attach operation merely sets up some pointers and reserves swap space for the
data; no actual code or data is read into memory.  Symbolic linkages into
shared libraries are also resolved at run time, but procedure references are
only bound when the function is actually called.  The actual code and data are
loaded into memory page by page on demand.  The code is shared between
programs that use the library, and the data is copy on write.

Thus there is some startup cost associated with shared libraries (measured in
the tens of milliseconds); but you won't be using more memory except in the
most degenerate of cases.

--------------
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