There are a lot of good reasons to implement your own memory manager in lieu of the OS's. For one thing, the OS's allocator has to be a general allocator that works well in -all- applications, sometimes at the cost of peformance in specific cases. Your own memory manager can be tailored to your specific needs. Secondly, everytime you do a malloc(), you're making a system call and a full context-switch is required, with associated performance overhead. Lastly, many of the general memory managers can have fragmentation issues, minimum page sizes and all that which can add overhead and cause a program to use more memory than it actually needs to.

Google actually has its own memory manager, tmalloc or some such, which apparently runs well in multi-thread applications; I wonder why we don't see more of that being used, especially in the case of browsers where there tend to run a lot of threads doing a lot of caching...

Secondly, everytime you do a malloc(), you're making a system call and a full context-switch is required, with associated performance overhead.

Uhh, no it doesn't. malloc() isn't a system call, it's part of the C library. It only makes system calls if it needs to increase the size of the heap (or do an mmap() for large blocks of memory). Otherwise, it simple mucks around with some pointers in userspace and returns a chunk of memory, which may be quite fast.