[-allSplitLibs] pid

DESCRIPTION

     vmmap displays the virtual memory regions allocated in a specified
     process, helping a programmer understand how memory is being used, and
     what the purposes of memory at a given address may be.

OPTIONS

     -d seconds     Take two snapshots of the vm regions of the process, sepa-
                    rated by the specified time, and print the delta between
                    those snapshots.

     -w, -wide      Print wide output.

     -resident      Show both the virtual and resident sizes for each region,
                    in the form [ virtual/resident].

     -pages         Print region sizes in page counts rather than kilobytes.

     -interleaved   Print all regions in ascending order of starting address,
                    rather than printing all non-writable regions followed by
                    all writable regions.

     -submap        Print information about VM submaps.

     -allSplitLibs  Print information about all shared system split libraries,
                    even those not loaded by this process.

EXPLANATION OF OUTPUT

     For each region, vmmap describes the starting address, ending address,
     size of the region (in kilobytes or pages), read/write permissions for
     the page, sharing mode for the page, and the purpose of the pages.

     The size of the virtual memory region represents the virtual memory pages
     reserved, but not necessarily allocated.  For example, using the vm_allo-
     cate Mach system call reserves the pages, but physical memory won't be
     allocated for the page until the memory is actually touched.  A memory-
     mapped file may have a virtual memory page reserved, but the pages are
     not instantiated until a read or write happens.  Thus, this size may not
     correctly describe the application's true memory usage.

     If the -resident flag is given, then both the virtual and physical size
     of each region is shown, in the form [virtual/resident].  By default, the
     sizes are shown in kilobytes.  If the -pages flag is given, then the
     sizes are in number of 4KB pages.

     The protection mode describes if the memory is readable, writable, or
     executable.  Each virtual memory region has a current permission, and a
     maximum permission.  In the line for a virtual memory region, the current
     permission is displayed first, the maximum permission second.  For exam-
     ple, the first page of an application (starting at address 0x00000000)
     permits neither reads, writes, or execution ("---"), ensuring that any
     vate copy of the page.  Empty (NUL) sharing implies that the page does
     not really exist in physical memory.  Aliased (ALI) and shared (SHM) mem-
     ory is shared between processes.

     The share mode typically describes the general mode controlling the
     region.  For example, as copy-on-write pages are modified, they become
     private to the application.  Even with the private pages, the region is
     still COW until all pages become private.  Once all pages are private,
     then the share mode would change to private.

     The far left column names the purpose of the memory: malloc, stack, text
     or data segment (for Mach-O binaries), PEF binary, etc.  For regions
     loaded from binaries, the far right shows the library loaded into the
     memory.

     If the -submap flag is given, then vmmap's output includes descriptions
     of submaps.  A submap is a shared set of virtual memory page descriptions
     that the operating system can reuse between multiple processes.  Submaps
     minimize the operating system's memory usage by representing the virtual
     memory regions only once.  Submaps can either be shared by all processes
     (machine-wide) or local to the process (process-only).  (Understanding
     where submaps are located is irrelevant for most developers, but may be
     interesting for anyone working with low levels of the virtual memory sys-
     tem.)

     For example, the memory between 0x90000000 and 0x9fffffff is a submap
     containing the read-only portions of the most common dynamic libraries.
     These libraries are needed by most programs on the system, and because
     they are read-only, they will never be changed.  As a result, the operat-
     ing system shares these pages between all the processes, and only needs
     to create a single data structure to describe how this memory is laid out
     in every process.

     That section of memory is referred to as the "split library region", and
     it is shared system-wide.  So, technically, all of the dynamic libraries
     that have been loaded into that region are in the VM map of every
     process, even though some processes may not be using some of those
     libraries.  By default, vmmap shows only those shared system split
     libraries that have been loaded into the specified target process.  If
     the -allSplitLibs flags is given, information about all shared system
     split libraries will be printed, regardless of whether they've been
     loaded into the specified target process or not.

     If the contents of a machine-wide submap are changed -- for example, the
     debugger makes a section of memory for a dylib writable so it can insert
     debugging traps -- then the submap becomes local, and the kernel will
     allocate memory to store the extra copy.

SEE ALSO

     heap(1), leaks(1), malloc_history(1,) lsof(1)

     The heap, leaks, and malloc_history commands can be used to look at vari-