Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Explanation' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Explanation
Authored by: Anonymous on Nov 08, '02 05:33:23PM
The Finder isn't actually allocating the memory, it is mapping it. There is a difference, but the end result is the same (and a bug).

When you browse a set of images, the Finder-- likely QuickTime or something related to the imaging infrastructure-- is asking the Mach memory manager to map the image data into memory. There is a difference between mapping a file into memory and allocating a hunk of memory and reading the file into that memory. Namely, when the system needs to page out a hunk of mapped memory (the image is no longer being previewed in the finder), it can simply dump the data in memory as the file already exists on disk-- there is no need to write the data out to the swapfile.

Because the current generation of machines are 32 bits, a process cannot simply map every file on disk into memory. As each file is mapped, it is assigned a virtual address within the process. If the process [Finder] tries to map in more than 4GB (likely less because of a series of reserved addresses) into memory, it will exceed the 32bit address space and crash (unless it does some fairly esoteric mach level memory interrupt handling).

Obviously, Finder shouldn't crash in this case. The problem is that the Finder is not releasing the mapped memory.

Keep in mind that simply because a file is mapped into memory, it may not actually be occupying a physical hunk of memory. By mapping a file, the mach memory manager simply reserves a set of addresses to correspond to the contents of that file. The contents of the file are not physically read into RAM until the program tries to actually read the data.

All of this (except the Finder crashing part) is the reason why you'll often see applications claiming that they are using tons of RAM listed in the VSIZE column. Just because it is listed does not mean the app has actually used that much physical memory + swap space.

The mach memory manager can also preallocate memory. For example, PhotoShop could choose to "allocate" 2GB of RAM from the mach memory manager. This only means that PhotoShop has indicated to mach that it wants a 2GB address space, not 2GB of memory. As PhotoShop writes data into that 2GB of memory, the mach memory manager will take care of ensuring that the memory is backed by physical RAM and, as needed, swaps the oldest accessed pages out to disk.


[ Reply to This | # ]
Explanation
Authored by: pmccann on Nov 08, '02 07:34:59PM

Thanks for the clear explanation, Bill. Now if we can just corral the henny-penny's of the Mac OS X world and force them to read what you've written then the number of posts claiming that the sky is falling should diminish dramatically.

One fairly convincing way to underline the disparity between "give me abstract addresses for this much space" versus "give me this much space" is to crank up classic, and then compare the VSIZE given by "top" with the number of VM pages that have actually been made on the system. This demo usually has a calming effect on those distressed by the large VSIZE's that are visible in OS X's "top".

Cheers,
Paul



[ Reply to This | # ]