Re: Locating managed objects within ObjectAlloc (was Re: Garbage collection, core data, and tight loops)

FROM : Chris Hanson
DATE : Mon Nov 05 04:28:22 2007

On Nov 4, 2007, at 7:01 PM, Aaron Burghardt wrote:

> Yup, even 10 KB mallocs were small enough.  For anyone that may be 
> following this thread, the following test looks different in 
> Activity Monitor (and and presumably ObjectAlloc).  Once the VSIZE 
> and RSIZE go up, they stay at that level until the test quits:


And do not represent "the memory used by the test," but rather "the 
address space used by the test."  These are very different things. 
Address space can be in use with no physical memory backing it, and as 
Ben said, can represent a high-water mark.

In top(1) terms, the best measure of actual memory use for a process 
is RPRVT, not RSIZE.  As seen on the top(1) man page:

  RPRVT  -  Resident private memory size.
  RSIZE  -  Total resident memory size, including shared pages.
  VSIZE  -  Total address space allocated, including shared pages.

"Shared" pages are memory pages that are mapped into multiple address 
spaces, typically read-only.  These include the system frameworks and 
window back-buffers handed out by the window server.

If I look at, say, a fresh launch of TextEdit on my system right now, 
it has the following:

    PID    COMMAND    RPRVT    RSIZE    VSIZE
  6596    TextEdit  1680K    6324K    358M

Thus even though it has 358M of its address space assigned, and an 
RSIZE of 6324K, only 1680K of that is really "unique" to TextEdit. 
And doing a "heap TextEdit" corroborates this; the number of bytes 
allocated is very close to the RPRVT value.  (I think the RPRVT value 
is calculated in terms of allocated pages, rather than allocated 
bytes, whereas I think heap looks at the malloc statistics which are 
in terms of bytes.)

  -- Chris