On Jan 15, 2009, at 8:55 AM, Michael Ash wrote:
On Thu, Jan 15, 2009 at 1:59 AM, Bill Bumgarner <b...@mac.com> wrote:
For example, an application's VSIZE might be growing over time
because it is
mmap()'ing a bunch of files (or a few small files). If the app
fails to
unmap, the VSIZE will grow and the app may likely exhaust its
address space
without any paging activity.
Example: for applications that are processing large files -- ID3
tag editors
come to mind -- watching the VSIZE can be a useful way of
determining if
your code is properly managing the mapping of said files.
All good points. However what I meant by "system resources" was that
VSIZE, while it may indicate misbehavior in your process, never
indicates misbehavior that could affect the system as a whole. An app
with a runaway RSIZE can quickly run you into swap hell. An app with
runaway CPU usage can make everything else slow. But VSIZE is at most
an internal problem. That's all I meant to indicate.
The kernel still needs to keep track of those VSIZE allocations.
Perhaps in 64-bit if you mmap() a small file a few billion times then
the kernel will exhaust some resource or clobber some algorithm's
performance. (Also I bet `top` will be really slow.)
But yes, in general VSIZE either is not a problem or is only a local
problem.
--
Greg Parker gpar...@apple.com Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
