Profiling scalable_malloc virtual memory overhead

[Daniel_S_]

Hopefully this is a fairly simple question.  Are there any tools available that will let me get an overview of the virtual memory overhead from using scalable_malloc?  

For context, I'm trying to debug a plethora of out of memory crashes in a 32bit application and I'm trying to ascertain what our actual footprint is, as well as how much of our virtual space is being used by tbb internally.  

I wasn't able to find much information on this topic in the docs so I was hoping someone else may have some insight?

[jimdempseyatthecove]

On tight memory situations consider not overloading new/delete and malloc/free. Instead explicitly call the scalable allocation routine on a case by case basis (or overload new only for) types that have high degree of allocation/free. You can use "placement new" to execute your ctor.

Jim Dempsey

[Daniel_S_]

Sadly, that's not really an option in our current configuration.  We have our own in house allocator that currently sits on top of scalable_malloc / scalable_free, and all systems use this allocator.  However, we do have the ability to switch out the allocator for a variant at run time, but it's still somewhat of an all or nothing approach (right now, anyway).

If push comes to shove and we see that the overhead is just too high, we'd probably have to break the problem apart a bit, however we need to get those numbers before we throw the baby out with the bathwater,