Valgrind's 64-bit Darwin support is not very good at the moment.  In particular, both 32-bit and 64-bit Darwin ports rely on mmapping large chunks of the address space to prevent them being used by dyld (I think?)  This works ok on 32-bits, but on 64-bits the mmaps are so large that they take a long time.  Eg. on my MacBook Pro it takes about 4 seconds to do this.

Given how much people complain about Valgrind's slowness in general, it's likely to cause rioting in the streets as people transition to Mac OS 10.6, which uses 64-bit executables by default.  It also makes the regression test suite very painful to run, because it has over 400 short-running tests.

The Linux version of Valgrind doesn't require these start-up mmaps.  Here's Greg Parker's explanation of why the Darwin version has them:

> The memory maps are there to make sure that Valgrind's copies of libc
> and dyld load in a non-default location, so that the inferior's own libc
> and dyld do load in the default locations. (The kernel performs the work
> of loading several things as described by the executable's load
> commands, including the executable itself, dyld, the main thread's
> stack, and the page-zero segment.)  There might be a way to fine-tune it
> so the maps are smaller but still do the job.
>
> The post-launch mmap behavior can be cleaned up - looks like we don't
> unmap as much as we should - which would improve post-launch
> performance.
>
> Hmm, there might be an extra-clever way to give Valgrind a custom
> MH_DYLINKER that performs the "bootloader" work of loading dyld in an
> acceptable place and then unloading itself. Then no mmaps would be
> needed. I'll have to think about that one.