Memory Twiddling
Monday, October 12th, 2009Looking at Holger Freyther’s entry on the size of QList::Data object, my first reaction was “no, you can’t make that smaller, not on every architecture.” Holger’s point is that there is a hole of 31 bits in the structure (Thiago points out that that is intentional) where you could re-order elements to remove the hole — the last 24 bits of the hole could be used for something else. Of course, that only works for machine architectures that allow byte-aligned addressing. In any case, this shows that machine-based suggestions on code quality should be taken with a grain of salt.
But Holger’s other comments on memory profiling got me thinking about the tools available on OpenSolaris as well. It comes with something called pmap(1) which spits out a table like this (an edited selection from Firefox):
Address Kbytes RSS Anon Locked Mode Mapped File 07FE4000 400 400 400 - rw--- [ stack ] 08050000 8 8 - - r-x-- firefox-bin 08061000 8 8 - - rwx-- firefox-bin E9600000 4096 4096 - - rw--- [ anon ] E9C00000 3072 3072 - - rw--- [ anon ] EA000000 1024 1024 1024 - rw--- [ anon ] F2673000 560 248 - - r---- DejaVuSans-Bold.ttf F2EA0000 156 36 - - r-x-- libaudiofile.so.0.0.2 F2ED6000 12 12 12 - rwx-- libaudiofile.so.0.0.2 F2EE0000 40 36 - - r-x-- libltdl.so.3.1.4 F2EF9000 4 4 4 - rwx-- libltdl.so.3.1.4 total Kb 249204 155460 54148 -
This seems to be pretty fine-grained, and by totalling the RSS (Lubos help me here) you can find the total real memory usage of the application. Something that might be scripted and collected over time? Heck, there’s probably some DTrace probes to do just that already — it’s just missing a graphing application.
On a vaguely related topic, I should note that KSysGuard on OpenSolaris has received a great deal of attention — not upstreamed yet — both from Belenix and from the KDE4-Solaris project inside Sun, so that it once again produces useful displays on OSOL.