http://www.usenix.org/events/bsdcon02/full_papers/gerbarg/gerbarg_html/index.html

See section 6.

Large VM mappings are not free, they take up page table space. Probably not enough to worry about, but it depends on the OS.

/be

Yikes, I can’t believe I overlooked the “-resident” flag for vmmap! Very useful. It does seem to confirm my suspicion that most of the biggest VM regions are not being used. Basically what one would expect, but now with numbers to prove it.

I deliberately avoided getting unto examining malloc usage; that’s a topic for some other blog post! Rather, the interesting data point here is how much *isn’t* being used. I’ve been planning to poke around with libumem on Solaris, and it would be interesting to compare its capabilities with libMallocDebug and leaks(1)… in a different blog post. :-)

Håkan:

Yeah, IOKit is what originally motived me to post this, as it looked like an interesting example of how “cost” can mean different things in different contexts. It felt unlikely to be a serious problem (I think we would have noticed if OS X was thrashing around an extra 256MB, compared to Linux/Windows), not to mention the “vmmap -resident” data. But still, it does have some sort of cost, as measured by the impression users get if they look at the VM size and think Firefox is using gobs of memory.

Eliminating or pruning IOKit would reduce that “cost”… But it’s sort of bullshit performance tuning (because the only effect is in someone’s head, and I think we’re far more interested in real gains). Then again, a big reduction in a fairly visible and confusing number like VSIZE might we worth taking if it was easy. I’d first want to understand it better.

Finally (phew!), yes, most of the framework and system stuff should be shared data, and so the real cost of having it in physical memory is spread across all the processes sharing it. Yet another reason why a single number like VSIZE doesn’t tell the whole story!

Shouldn’t most of these frameworks (which by and large are just collections of shared libraries) be in shared memory anyway? Or is this the allocation of private memory every user of these shared libraries need to put up with?

/H

1. For malloc memory:
On Mac OS X, you can use MallocDebug:
/Developer/Applications/Performance\ Tools/MallocDebug.app

You have to preload libMallocDebug when you are running your application:
export DYLD_INSERT_LIBRARIES=/usr/lib/libMallocDebug.A.dylib

MallocDebug can show where the malloc allocation were initiated. So that you can know where most of malloc memory is going.

2. For other memory:

$ vmmap -resident
REGION TYPE [ VIRTUAL/RESIDENT]
=========== [ =======/========]
ATS (font support) [ 33856K/ 1076K]
Carbon [ 1144K/ 1144K]
CoreGraphics [ 5016K/ 3232K]
IOKit [ 262144K/ 0K]
MALLOC [ 33884K/ 21944K]
STACK GUARD [ 48K/ 0K]
Stack [ 14336K/ 152K]
VM_ALLOCATE ? [ 2028K/ 608K]
__DATA [ 5300K/ 3244K]
__IMAGE [ 1088K/ 480K]
__IMPORT [ 500K/ 500K]
__LINKEDIT [ 18328K/ 18028K]
__OBJC [ 864K/ 848K]
__PAGEZERO [ 4K/ 0K]
__TEXT [ 83044K/ 47560K]
mapped file [ 13476K/ 7700K]
shared memory [ 16376K/ 128K]

in short, that shows that IOKit allocation is only address space allocation and it seems that it is never mapped into real memory. So that we can ignore IOKit allocation.

It looks like your output has much mapped file address space:
You can know which files are mapped using the following:

$ vmmap -w -resident | grep mapped
mapped file 00fcd000-00fe1000 [ 80K/ 76K] r–/rwx SM=COW /System/Library/CoreServices/CharacterSets/CFUnicodeData-L.mapping
mapped file 0185d000-018b4000 [ 348K/ 348K] r–/rwx SM=COW /System/Library/CoreServices/CharacterSets/CFCharacterSetBitmaps.bitmap
mapped file 12808000-1280d000 [ 20K/ 8K] r–/rwx SM=COW /System
…

[fixed, thanks :-) --dolske]