Date: Sun, 7 Oct 2007 20:21:49 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Diomidis Spinellis <dds@aueb.gr> Cc: freebsd-ports@freebsd.org Subject: Re: Idea: static builds Message-ID: <20071007102149.GI67571@turion.vk2pj.dyndns.org> In-Reply-To: <4707D1E8.5000103@aueb.gr> References: <20071004190304.GA9491@hades.panopticon> <20071006150207.GA19775@amilo.cenkes.org> <4707D1E8.5000103@aueb.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
--82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Oct-06 21:20:24 +0300, Diomidis Spinellis <dds@aueb.gr> wrote: >I can give you quantitative data on the benefits of shared objects. On a= =20 >web server running FreeBSD 6.2 I found 98 shared objects sharing 16,790,90= 1=20 >bytes of memory through 1,002 mappings. >Without shared libraries the corresponding binaries would require=20 >198,815,270 bytes - an order of magnitude more. Unfortunately, your perl script is overly simplistic and you have vastly over-estimateed the unshared size. The major inaccuracies are: - Text segments are shared so multiple instances of the same executable=20 (eg shells) all share the one copy of memory. - All of a .so is mapped into every process that references it whereas a statically linked executable will only link in the required bits of the corresponding .a. It's extremely unlikely that any executable uses every function in a library so a static executable will normally be much smaller than the size of the dynamic executable plus all the .so's it maps. - rw mappings are not normally shared The size differences between static and dynamic linking are not clearcut and will depend on the process mix. For a server running multiple copies of a small number of distinct executables, static linking is likely to use less memory (because the unused parts of the libraries are not mapped). For a desktop running a single copy of a variety of different executables - which themselves share large .so's (eg X applications) then shared libraries are a win. >These are not just memory savings, but, more importantly on a modern=20 >system, they contribute to improved locality in the code cache. It's not clear that a random collection of executables that all load a common .so will actually have any code locality benefits. Code locality is a very large can of worms... Since most of this thread has stressed the advantages of dynamic loading, it might be worthwhile pointing out some of the benefits of static linking: - Static executables start faster because there's no RTLD step - On some architectures (eg i386) static executables run faster because PIC code needed in the .so's is less efficient. - It can be easier to secure the fewer inodes associated with a static executable than a dynamic one. To expand on this last point, loading a static /bin/sh accesses 3 inodes. A dynamic /bin/sh on FreeBSD accesses 7 inodes (plus any dynamically loaded .so's). On Solaris, /bin/sh accesses something like 20 inodes. --=20 Peter Jeremy --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHCLM9/opHv/APuIcRAvYyAJ9SeJZ1k7EHPfrwURQY0jJ1TJTgUgCgqT4G KeuJluwSqLZp/gfHjxnjMas= =D0QP -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071007102149.GI67571>