what's making executables so large?

[amd64, FREEBSD 9.0-RELEASE, though the release probably doesn't matter]

I just had a 3MB-size program (xv) dump core and was amazed the core
dump file was ~172MB(!) (No, I wasn't looking at a gigantic image).
That caused me to look at two other programs.

# size /bin/ps /usr/local/bin/emacs
text data bss dec hex filename
31457 10404 4512 46373 b525 /bin/ps
2022646 11001832 0 13024478 c6bcde /usr/local/bin/emacs

That's ~46 KiB (0.046MiB) for ps and ~13 MiB for Emacs. About what
I'd expect.

# ps

USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
wbe 54781 0.0 0.0 14328 1200 1 R+ 8:33PM 0:00.00 ps ut1
wbe 54810 2.9 0.3 174720 29108 1 S 8:45PM 0:00.77 emacs

(That's a just-started Emacs.)

Their virtual sizes are 14,328 KB and 171MB! Ouch!

I believe those VSZ numbers, too. When I get core dumps, the ls -s size
is comparable to their VSZ (not surprising), so it doesn't look like
these large numbers are the result of big gaps in memory space.

So, I checked the dynamically linked libraries in /lib. "du /lib" says
"9104". Even if ps linked with every library in /lib (and I doubt it
does), the total size wouldn't reach 14MB.

That leads me to two questions:

1) Are shared libraries in fact shared during execution (only 1 instance
in RAM/swap space even if referenced by >1 process)? (E.g., compiled
for position-independent code?)

2) What's making the virtual sizes so large? Is it caused by having
each shared library mapped to a separate memory page and memory page
size being "too large" (thus mostly empty) or some such?

Thanks in advance,
-WBE
.

Relevant Pages

  • Re: Dying processes (inetd, cron, syslogd, sshd)
    ... to fit by limiting the amount of memory seen by the kernel. ... bit less than actual size of your dump area in place of "100m"). ... such a process usually writes a core dump. ... nearly as large as your combined RAM + swap. ...
    (comp.unix.sco.misc)
  • Re: Dying processes (inetd, cron, syslogd, sshd)
    ... > to fit by limiting the amount of memory seen by the kernel. ... such a process usually writes a core dump. ... > tries to allocate more memory while the system is strapped. ...
    (comp.unix.sco.misc)
  • Solaris fork() to generate core file
    ... calls abortto dump core file then exit. ... If the parent modifies very little of its memory while the core is ...
    (comp.unix.programmer)
  • Daily Report #4852
    ... Verify Guide Star Acquisition with Continuing FGSs ... Load and Dump Onboard Memory ... At the beginning of each test, the attitude control law ...
    (sci.astro.hubble)
  • Re: Chucks plan
    ... Still, the external memory bus on the Intellasys I am interested what in particularly stopped it from having an automated memory bus, rather than the software driven bus? ... I asked the above separately, because potentially being on one core, it is not such a bottle next to every other core, and can drag in data faster, however, I am interested in how this played into the design? ... I would have expected that a word could have been dumped to the serial bus (link wakes up other core with first bit, core software reads port to tos, other bits automatically follow/streamed across and dumped into tos) and it streamed across to the receiving core at 700mhz*18, well within the boundaries of present intra chip busses. ...
    (comp.lang.forth)