Re: Maximum size of an NSMutableData object?
Re: Maximum size of an NSMutableData object?
- Subject: Re: Maximum size of an NSMutableData object?
- From: Bill Bumgarner <email@hidden>
- Date: Wed, 4 Dec 2002 11:14:39 -0500
On Tuesday, December 3, 2002, at 11:46 PM, Phill Kelley wrote:
At 23:25 -0500 03/12/2002, Bill Bumgarner wrote:
[snip]
In short: it's an NSData problem that I can work around if need be,
and the
apparent 2x correlation between my physical RAM size and NSData's
observed
limit was merely a coincidence.
Yup.
As always, your reply was both extremely informative and a joy to read!
Happy to help.
In reading the various random Mac Community message boards [macintouch,
macfixit, macnn, spymac, macosxhints, etc..], it is clear that the
virtual memory behavior of OS X has been a very large source of
confusion. For anyone coming from the OS9 world and prior, the
assumption is often made that OS X's virtual memory system has
something in common with OS9 -- it doesn't, not at all.
It is also common to assume that the VSIZE of an application--
rightmost column in 'top -u'-- represents the amount of virtual memory
an application is actually using. The actual behavior is a bit more
complex and gets back to the whole address space vs. memory used
dichotomy.
[may be fixed by 10.2.2 -- I haven't looked] On a side note -- a vm
related bug appears to be present in the Finder. If you go to a
folder filled with images-- say your iPhoto library -- and scan through
a bunch folders, the Finder will eventually exhaust its address space
and crash.
However, the system doesn't go into "swap death" prior to this
happening-- the behavior one might expect if the Finder was actually
using all of the memory that the VSIZE column indicates. In this
case, the Finder is very likely mapping each image file into its
address space, then using that data to calculate the images to be
displayed within the Finder window. Unfortunately, the Finder doesn't
"unmap" the images.
As each image is mapped and used, its data will be read in and occupy
physical pages of memory. As the finder maps more files in and
eventually exhausts physical ram, the VM subsystem will start paging
out unused pages. The pages occupied by the previously mapped images
are an ideal candidate -- they aren't in use and there is no need to
actually page them to disk as the data is already on the disk in the
original file [the VM subsystem implements a notion of 'copy on
write'-- if you were to write to one of the pages that had been mapped,
then that page WILL be paged to the swapfile]. So, the VM subsystem
simply tosses the data on the physical page and remaps that page of
memory to a new address within the Finder's VM address space [likely
for use by another image file].
After enough files are mapped, the finder will run out of address
space. But the system won't experience swap death because there was
never a need to write the formerly displayed image data to the
swapfile. System performance remains relatively snappy even though
the Finder is technically using multiple GBs of RAM.
b.bum
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.