Idea: static builds

[Peter Jeremy]

On 2007-Oct-06 21:20:24 +0300, Diomidis Spinellis <dds at aueb.gr> wrote:
>I can give you quantitative data on the benefits of shared objects.  On a 
>web server running FreeBSD 6.2 I found 98 shared objects sharing 16,790,901 
>bytes of memory through 1,002 mappings.
>Without shared libraries the corresponding binaries would require 
>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 
  (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 
>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.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20071007/a6ecad01/attachment.pgp