Date: Fri, 10 Nov 2000 18:57:45 -0800 (PST) From: John Polstra <jdp@polstra.com> To: arch@freebsd.org Cc: dillon@earth.backplane.com Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <200011110257.eAB2vj034258@vashon.polstra.com> In-Reply-To: <200011100326.eAA3Q6015450@earth.backplane.com> References: <200011091223.eA9CNQW26294@mobile.wemm.org> <200011091944.eA9JiSN30771@vashon.polstra.com> <20001109115022.Y5112@fw.wintelcom.net> <200011100326.eAA3Q6015450@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <200011100326.eAA3Q6015450@earth.backplane.com>,
Matt Dillon <dillon@earth.backplane.com> wrote:
>
> Linking with a shared library eats memory at run time. It's that simple.
> Shared libraries make life easier but they do *NOT* generally reduce
> the run time in-core memory footprint of a machine. Dynamic executables
> actually increase the number of dirty pages the system has to cope with,
> at least for discretely-run programs, and they tend to force the entire
> shared library into core.
As I'll explain below, I don't share your opinion about this.
> Don't forget that even static images can be demand-paged, and for a
> static image paging equates to simply throwing the page away since it
> is always clean.
That is true for the text segment, which is pure, but of course not
for the data and bss segments. (I know you understand this, but
perhaps not everybody does.)
> Demand-paging a dynamic binary requires writing some of those
> pages to swap due to the dynamic relocation and each instance of
> the binary (when exec'd independantly) have their own private
> set of dirty pages to page out.
In a shared library, just as in an executable, the text segment is
pure. It contains no relocations, and its pages are never dirtied.
All of the relocations in a shared library are confined to the data
segment. The whole point of the compiler's "-fpic" option is to
generate that kind of code, so that the text segment can be pure and
100% shareable.
For example, looking at /usr/lib/libc.so from a fairly recent
-stable system, we see:
austin$ size /usr/lib/libc.so
text data bss dec hex filename
508413 15084 78200 601697 92e61 /usr/lib/libc.so
The text segment, about 500 KB in size, will be shared among all
dynamically linked processes. Only the data and bss segments, about
92 KB, will be unshared. This 92 KB includes all of the run-time
relocation. (The main region modified by run-time relocation is the
global offset table, and it is compact. In the case of this libc.so,
it's a contigous region less than 4 KB in size.)
Since most programs only use a small part of libc, they will tend
not to touch most pages of that 92 KB. The untouched pages will be
shared, since they are mapped copy-on-write. Thus the 92 KB figure
exaggerates the amount of unshared memory needed by each instance of
libc.so.
Whether shared libraries are a win on a given system depends on the
job mix. If you are on a system running 30 instances of one program
and not much of anything else, shared libraries won't save you any
memory. But on a system with a richer job mix, they can save quite a
bit.
But to keep things in perspective, saving RAM isn't really the main
advantage of shared libraries. Their value lies in other areas. They
save a lot of disk space; they allow bugs to be fixed in many programs
at once via the installation of a single repaired library; and they
provide the flexibility of run-time modules ("plug-ins"), which are
used by more and more software packages these days.
John
--
John Polstra jdp@polstra.com
John D. Polstra & Co., Inc. Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011110257.eAB2vj034258>