what's making executables so large?
- From: Winston <wbe@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 14 Jun 2012 21:44:43 -0400
[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
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,
- Prev by Date: Re: Largest Filesystem on FBSD 8?
- Next by Date: sendmail with auth
- Previous by thread: Re: Fed up with DE's
- Next by thread: Re: what's making executables so large?