Cool VL Viewer forum

Henri, you see to be under the impression that your application does not run as a native Mac application, which indeed it does. It is subject to the same memory management policies that any application that launch from an application bundle on the desktop and use the Window manager to manage its window(s).

So trying to use a different memory manager would be highly counterproductive as it both would make your application non-runnable across versions of OS X. but could also destabilize the entire system (When I say non-runnable I mean not allowed to run on OS X 10.8 or higher. Such a service would need a code signing certificate and I don't think Apple would issue one for an alternative memory manager.)

I don't even see why this is an issue as the system will provide the memory needed for the application within the per-application 32-bit address space your application is compiled for (which is actually the full 32-bit address space and not limited to 2 or 3 Gb as on Windows.)

If your application was running purely as terminal application or if OS X was started with a completely different Window manager on the desktop (which is possible by changing /etc/ttys) what you want to do might have something for it.

I'm sorry, but you are obviously completely clueless about operating systems and memory management levels. I'd were you, I'd stop arguing: you are making a fool of yourself...

Thanks to Catten who built jemalloc for MacOS-X, the Mac builds now have the memory safety checks implemented and the RenderTextureMemoryMultiple setting has now been raised to its maximum (1.0) for Mac builds.