CODEWITHSUNDEEP
c++malloc
Revital Eres
Revital Eres

Reputation: 263

Replacing malloc implementation

I have a c++ program which is called via JNI from a java program and I want to replace the memory allocator in the c++ program with the Doug Lea's dlmalloc implementation (IIUC this is doable because new operator calls malloc underneath). I also use std:list and std:map in my c++ program and would like that these library function will also use the dlmalloc upon a call to "new" operator. I've tried to use LD_PRELOAD but it seems to cause that dmalloc will be called also from the JAVA program and I do not want it. Does linking the c++ program against libdlmalloc.so while compiling it is enough to guarantee that all of the c++ library functions will use dlmalloc? If so can one provide an example of how to link against dlmalloc? Thanks

Upvotes: 2

Views: 1691

Answers (2)

Omnifarious
Omnifarious

Reputation: 56048

I don't necessarily think playing games with the linker is bad, but I have an alternative...

If dlmalloc has a library with symbols that are not 'malloc' you can override the global C++ operator new, operator new[], operator delete, and operator delete[] with your own versions that call the dlmalloc versions of malloc and free.

This will cause all C++ allocation to go through your overloads, including library functions. This behavior is guaranteed by the standard. Though, if you have two different versions of these overloads it's unspecified which is called. But it's clear that if the standard library itself has a version, your version is supposed to take precedence.

This will not cover any C standard library functions that you might call. They will still use the malloc symbol regardless, and there isn't much you can do about that without playing games with the linker. Luckily, in most C++ programs, there will not be many ways in which the standard C library will be invoke in a way that does allocation.

Recompiling your program will not be sufficient. In fact, it will largely not accomplish anything as the standard C++ implementations of the new and delete operators do not appear in the standard library headers and so the preprocessor will have no way to replace malloc with whatever function the dlmalloc library provides.

Upvotes: 0

Florian Weimer
Florian Weimer

Reputation: 33719

If you program does not call any libc functions which allocate memory which you need to free (such as realpath), you can link statically against dlmalloc and carefully manage the set of exported symbols. If you only export those functions which are actually called by the JNI interface (and not malloc, free, etc.), this should work.

The JNI API has callback functions which will call malloc/free, and those will remain the ones from the original process, but things will remain consistent because the malloc/free implementations will match.

However, you should make sure that your dlmalloc variant does not use brk/sbrk, only mmap, for allocation from the operating system because the older form of allocation could interfere with the system malloc.

For symbol management in an ELF environment, Section 2.2 (Export Control) of Ulrich Drepper's How To Write Shared Libraries is a good reference.

Upvotes: 1

Related Questions