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

Question

Loud fan noises. Discovered something called SIMBL Agent was using well over 30 gigabytes of virtual memory. 2nd place was Safari at only 1.5!
So, the question of the day is
What is SIMBL Agent?
What is it doing?
And should I be concerned at 30gb+ of space being consumed?
(OK, so thats 3 questions of the day! )

Answer 1

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.