SIMBL Agent--what is it and why is its virtual memory footprint 30gb+?

See this information. The amount of +virtual memory+ is a function of the program but does not actually involve any memory (hence the word, virtual.) If you use Activity Monitor what you should look at is Real, not Virtual memory. The latter is irrelevant except to the developer.

Since SIMBL is a third-party add-on you had to install it or other software that installed it. Although you can remove SIMBL, if you do then whatever you use that requires SIMBL will stop working.

Thanks for the reply! My understanding is that virtual memory uses hard drive space... so 30 GB+ is excessive, right? Or, has "virtual memory" taken on a new meaning in Leopard, or OS X.

Virtual Memory information is mostly meaningless, except to software developers and very few of them.

Virtual Memory is often times filled with holes of unused address space. The application code is mapped into this space, and the disk used for this is the actual executable code.

All the shared libraries and application frameworks that the application uses are mapped into the virtual address space, often times with empty gaps in the address space. Again the disk used are the shared library and framework files.

If the application has loadable modules, such as browser or photoshop add-ons, then these get mapped into virtual address space. And the disk for this comes from the add-on files. Also these add-ons are most likely mapped into the virtual address space with gaps between them and other code.

Then comes the data used by the application. This comes in different flavors. Some might be memory mapped files, where an explicit file accessed as if it is part of memory (vs doing read/write operations). If the file is huge, then the virtual address space needed to map it will be large as well. Or an application can memory map a bunch of smaller files, but if you have enough of them then that adds up to a lot of virtual address space.

NOTE: when memory mapping a file, the application has the opiton of specifying where in the virtual address space it would like the file to be mapped. So it is very possible for an application to specify they would like to map a file at the 29GB address offset, and everything from the lower address up to the now memory mapped file at 29GB is empty address space. No RAM and no disk associated with this gap.

So far everything I've mentioned does not need swapfile space, as real files are used for all of the above.

The application stack is mapped into the virtual address space. Since the stack grows as the application calls subroutines, it is necessary to leave lots of unmapped addresses for the stack to grow into. Since most stacks to not grow that big, a lot of that virtual address space is never mapped to RAM nor disk.

And there is the actual data being worked on by the application. This could be local variables used as part of the program flow control, or it could be buffers used to hold data the program is working on. This data would get allocated potential space in swapfiles (/var/vm/swapfile*), however, if the operating system does not run out of RAM, then it will not need to actually create any additional space in the swapfiles.

Now I have no idea what your 30GB application is doing with all of its virtual address space. And it is possible that it is using all of it, and forcing RAM to /var/vm/swapfile* files. If you really want to know, you can always use the vmmap command from a terminal (man vmmap).

However, in my experience, no one really cares. All they really want to know is whether their Mac is spending a lot of time paging. And for that I like to use Applications -> Utilities -> Terminal

sar -g 50 100

The command will display pageout information once a minute for 100 minutes (adjust values to suite your tastes).

Now you do your normal work. When you come back an look at the sar output, if it is mostly zero or some small values, or a momentary burst, then you really do not need to worry. If you have sustained high values, or if you notice a the Mac is slow at the same time you getting high pageout numbers, then you could benefit from more memory, or running fewer apps at the same time.

The virtual memory info in Activity Monitor has nothing to do with disk based VM used by the OS. It also has nothing to do with page swapping. As I said and as Bob said it is meaningless except to the developer.

Not really a different term but used in an unusual way. In Activity Monitor the VM figure relates to the maximum amount of VM the application is able to access but is not a measure of VM in use. The indirect measure of VM in use is provided in Activity Monitor by the PageIn and PageOuts figures. The direct measure can be obtained in the Terminal using vm_stat or looking at the Swap Used figure in Activity Monitor in the System Memory tab.

If you select All Processes from the Processes menu then double-click on the CPU heading to display in descending order any process using a large amount of CPU time will be displayed at the top of the list. It would be that process most likely causing the computer to heat up and the fans to ramp up.

Have you tried resetting the PMU?

It shouldn't affect SIMBL, but one never knows.

No need to do it unless you have problems that resetting it might help.