jemalloc linking

[Mayank Kumar (mayankum)]

Thanks Konstantin. I wanted to call some of the stats api to periodically get usage information in different arenas and how it grows.
 I will patch the header file after its generated by configure to fix this.

Is there a way to get stats periodically much like the profile dumps using the /etc/malloc.conf interface ?

-----Original Message-----
From: Konstantin Tokarev [mailto:annulen at yandex.ru] 
Sent: Wednesday, May 20, 2015 4:46 AM
To: Mayank Kumar (mayankum); jemalloc-discuss at canonware.com
Subject: Re: jemalloc linking



19.05.2015, 22:59, "Mayank Kumar (mayankum)" <mayankum at cisco.com>:
> Thanks  Konstantin. I think putting jemalloc early enough worked.
>
> But I am getting the following errors and it seems others have seen this error before . I am compiling with windriver toolchain. I ran the configure script, so I am wondering the configure script should have done the right thing and determined that all these definitions are already present and hence when generating the header file , should have skipped these definitions so that this is not an issue.
>
> Do I need to pass specific options to configure or what is the right way to fix this issue ?
>
> declaration of 'void* malloc(size_t) throw ()' throws different exceptions
> jemalloc-3.6.0/include/jemalloc/jemalloc.h:137: error: from previous declaration 'void* malloc(size_t)'
> usr/include/stdlib.h:474: error: declaration of 'void* calloc(size_t, size_t) throw ()' throws different exceptions
> jemalloc-3.6.0/include/jemalloc/jemalloc.h:139: error: from previous declaration 'void* calloc(size_t, size_t)'
> usr/include/stdlib.h:486: error: declaration of 'void* realloc(void*, size_t) throw ()' throws different exceptions
> jemalloc-3.6.0/include/jemalloc/jemalloc.h:144: error: from previous declaration 'void* realloc(void*, size_t)'
> usr/include/stdlib.h:488: error: declaration of 'void free(void*) throw ()' throws different exceptions
> /include/jemalloc/jemalloc.h:145: error: from previous declaration 'void free(void*)'
> lib/gcc/i586-wrs-linux-gnu/4.3.2/../../../../i586-wrs-linux-gnu/include/c++/4.3.2/cstdlib:73,


Do you really need to include jemalloc.h?

There are related Mozilla issues [1,2]. They ended up by removing prototypes of these functions from jemalloc.h on Linux [3]. Otherwise, you can patch your jemalloc.h to add throw() wherever needed.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=422960
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=526389
[3] http://hg.mozilla.org/mozilla-central/rev/7a2802932585


>
> -----Original Message-----
> From: Konstantin Tokarev [mailto:annulen at yandex.ru]
> Sent: Monday, May 18, 2015 12:20 PM
> To: Mayank Kumar (mayankum); jemalloc-discuss at canonware.com
> Subject: Re: jemalloc linking
>
> 18.05.2015, 19:30, "Mayank Kumar (mayankum)" <mayankum at cisco.com>:
>>  Hi All
>>
>>  My application worked perfectly with LD_PRELOAD and the virtual memory growth was contained. As soon as I linked it dynamically with jemalloc, this wasn’t the case. So virtual memory kept growing. So  I am guessing that my application is still not using jemalloc but libc’s default malloc when linking dynamically. My application is a binary which links to many dynamically loadable libraries some of which are internally built and some are open source versions which we don’t always build. My questions are:-
>>
>>  1.       When linking dynamically with jemalloc, is it a requirement to have –ljemalloc as early as possible or possibly the first library being linked to, to override the default malloc ?
>
> Yes - this is how dynamic linking works on ELF platforms. When linker sees undefined symbol "malloc" it will take it from first ELF object (in order of specified ld arguments) which has defined "malloc" symbol.
>>  2.       What method does jemalloc uses while linking to override malloc, does it use the malloc_hooks to override or just the normal linking, so that whatever the linker gets first, it will link to .
>
> LD_PRELOAD deals only with ELF linking, injecting your library(ies) in the beginning of *.so list used by runtime linked (e.g., ld-linux.so)
>>  3.       Would linking statically  solve this issue, although my preference would be to link dynamically since I have at least 10 processes which needs jemalloc, and at least they would share the code in memory.
>>
>>  4.       When linking with external open source libraries, do I need to re-compile those with jemalloc as well to make sure any mallocs in those libraries also go through jemalloc or that is not required. I am guessing it should not be required as long as my process links to the right malloc library, their dependencies should be correctly resolved.
>
> --
> Regards,
> Konstantin

-- 
Regards,
Konstantin