Re: Locating managed objects within ObjectAlloc (was Re: Garbage collection, core data, and tight loops)
Re: Locating managed objects within ObjectAlloc (was Re: Garbage collection, core data, and tight loops)
- Subject: Re: Locating managed objects within ObjectAlloc (was Re: Garbage collection, core data, and tight loops)
- From: Chris Hanson <email@hidden>
- Date: Sun, 4 Nov 2007 19:28:22 -0800
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
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden