Hi,
I was profiling the memory usage of libgtk when discovered something
very strange.
As you may know, shared memory are usually mapped in 2 different memory
segments.
The first segment containing constant data & code and is shared by all
applications using the library.
The second segment contains non-constant data and each application gets
its own copy.
What I discovered is that in the official Debian package for libgtk, a
large part of the constant data is moved from the shared segment to the
non-shared one.
That is easy to see in the section table dumped with 'objdump' where
the section .rodata is shared while the section .data is not.
$ objdump -h -w libgtk-x11-2.0.so
The section size is in the 3rd column
DEBIAN PACKAGE FROM REPOSITORY:
11 .rodata 000840cb 000000000021a180 000000000021a180 ...
21 .data 000233c0 00000000003f1d60 00000000003f1d60 ...
MY OWN RECOMPILED DEBIAN PACKAGE:
11 .rodata 000a43ad 00000000001f3180 00000000001f3180 ...
21 .data 00000748 00000000003f3460 00000000003f3460 ...
That's 0x0233c0-0x748 = 140KB moved from shared to non-shared
140KB of non shared memory per GTK application is HUGE!!!
The problem does not seem to be limited to libgtk.
I picked a library randomly: libasound
Here are the results:
DEBIAN PACKAGE FROM REPOSITORY:
12 .rodata 00008a78 000000000009f240 000000000009f240 ...
14 .data 00010e20 00000000001ad000 00000000001ad000 ...
MY OWN RECOMPILED DEBIAN PACKAGE:
12 .rodata 000140f8 000000000009eda0 000000000009eda0 ...
21 .data 00005740 00000000001cbd20 00000000001cbd20 ...
For libasound 'only' 0x10e20-0x5740 = 47KB are not shared.
My first though was that the official debian package was probably
compiled with a different version of gcc.
However, I could not reproduce the official package size with gcc-3.3,
gcc-3.4 and gcc-4.0 so the problem
is probably elsewhere: libtool? binutils ?
The problem is also not specified to AMD64. The x86 version of libgtk
also has more non-shared data than it should.
I would like to file a bug I do not in which package.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
