NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/sys/hp/9670

Internet Message Format | 1992-08-25 | 6.3 KB

Path: sparky!uunet!dtix!darwin.sura.net!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!usc!sdd.hp.com!hp-cv!hp-pcd!hpfcso!mjs
From: [e-mail] (Marc Sabatella)
Newsgroups: comp.sys.hp
Subject: Re: Shared libraries have me very confused!
Message-ID: <[e-mail]>
Date: 25 Aug 92 19:29:20 GMT
References: <[e-mail]>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 110

In comp.sys.hp, [e-mail] (Doug Siebert) writes:

> I've got an application running on an HP 9000/710 with 48M of RAM under HP-UX
> 8.07 that is run by up to 80 users at a time (and adding more would always be
> an advantage) each running a separate copy of the application.

When you say "running a separate copy", do you literally mean a separate copy
of the executable file?  If so, step one is to make sure everyone runs the same
copy of the application, so you can shared text.

> I recompiled
> again, this time with the option "-Wl,-a,archive" to the linker, which should
> use the archive libraries instead of the shared libraries.  I figured I would
> be using up more real memory by not using the shared libraries, but am in fact
> using less!  How can this be?!

How did you measure real memory usage?  I don't think any of the available
tools like "ps", "monitor", "glance", or anything using "pstat" are
particularly smart about shared libraries.  I can easily imagine that they
would think each instantiation of the program was using its own copy of the
library.

If you are counting swap space, then you should *not* expect to see usage go
down with shared libraries.  Swap is never used for text segments (it is paged
in directly from the filesystem), so only data is an issue.  With archive
libraries, a program will have swap reserved/allocated for all the data in the
program, plus all the data copied out of archives libraries.  A typical Motif
program accesses only 60% (or some other relatviely small amount) of the data
in the libraries it is linked with, so only that amount of data is copied into
the program.  With shared libraries, however, you are allocated swap for all
the data in all the libraries you are linked with.  Plus, you are allocated
swap for the data structures used by the dynamic loader.  Thus, a program
typically needs more swap space when linked with shared libraries than archive
libraries.  This does not mean it needs more real memory, however - most of
the swap is allocated "just in case", but still only those pages that are used
are allocated in memory, so a given process would use almost exactly the same
amount of memory with shared as archive libraries.  Possibly a little more due
to fragmentation of the data it is using (the 60% of the data it uses from a
library may be scattered over 80% of the library's pages).

> 1)  How come NOT using shared libraries allowed my application to use up less
> real memory per process?  If this is so, what is the point of shared libraries?

Possibility number one is that the program really isn't using less real memory
with archive libraries - the tools that report memory usage may be flawed, or
you may have been measuring the wrong thing (swap space).  As I observed above,
any given process will appear to need slightly more (due to fragmentation, and
dynamic loader overhead) real memory with shared libraries than with archive
libraries.  The savings comes as soon as there is sharing - memory pages used
for library text can be shared processes.  But note that program text is shared
anyhow.  If your program is linked against libfoobar, and it is the only
program linked against libfoobar, then its text pages will be shared among all
users regardless of whether it is a shared library or not.  The shared library
is only a win if some other program is also linked against libfoobar - then
the pages will be shared among all users of both programs, rather than having
one set of pages for users of one program and another set for users of the
other.

To recap, you should expect any individual process to need significantly more
swap when using shared libraries, and slightly more memory.  If you have
several invocations of the same program at once (as you do), this only
magnifies those differences.  The savings come when you also have *other*
programs that use the same libraries.

Do we expect these savings to be realized in the average case?  I don't know.
I know for a fact that in my environment, where the only programs I ever have
running at once are several shells and several "hpterm"'s, there is no memory
savings - the shells were built with archives libraries, and the hpterm's
all share the Motif & X11 library code among themselves either way.  Now that
I've started using VUE, maybe there is a savings; I don't know.

The real reason we implemented shared libraries is to save disk space for the
delivered HP-UX - by not linking libc into every command, and libX11 into every
tool, we cut the size of HP-UX itself down tremendously.

> 2)  How can I compile my application so as to make it share memory better among
> the 80 copies of it that may be simultaneously running?  Is there something
> big I'm missing?  Or would I have to tear it apart and put most of its
> functions in a library of my own creation?  (And would I then want to make that
> shareable or not?)

Assuming the application really is shared - all 80 users are running from the
same i-node, I think you've done all you can.  If you're wondering just how
much difference the libraries are making, try the following experiment:

1. link your application normally, with something that presumably looks like:

    cc -o program.shared $(OBJS) $(LIBS)

2. link it with archive libraries:

    cc -o program.archive $(OBJS) -Wl,-a,archive $(LIBS)

3. link it with no libraries (result will not be executable):

    cc -o program.none $(OBJS)

Now run "size" on each of the resultant executables, and compare.  #2 and #3
should be similar - #2 should be slightly larger due to shared library
overhead.  #1 should be larger.  If it is "a lot" larger, it means you are
using a lot of library code, and any tuning should indeed be in your use of
libraries.  If is "only a little" larger, then most of the memory you are using
is in your application code, and the libraries don't really make much
difference.

--------------
Marc Sabatella ([e-mail])
Disclaimers:
    2 + 2 = 3, for suitably small values of 2
    Bill (H.) and Dave (P.) may not always agree with me