compatibility with apps using mallopt?

[Jason Evans]

On Nov 17, 2013, at 2:47 PM, Eric Wong <normalperson at yhbt.net> wrote:
> Hi, I'd like to continue providing the option of using jemalloc (and
> other alternative malloc implementations) to glibc/Linux users of
> cmogstored[1].
> 
> I have a pending change[2] in cmogstored.git which adds mallopt(3)
> support.  This needed for good out-of-the-box VM usage on modern glibc
> and many disk-bound threads.  cmogstored is not at all dependent on
> malloc performance/scalability, so glibc malloc defaults clash greatly
> with the design of cmogstored.
> 
> When I ./configure with LIBS=-ljemalloc, things go bad because the
> mallopt call is still detected and going to glibc even though the glibc
> malloc implementation is not used/linked.
> 
> So my question is: what's the best way to avoid mallopt() when using
> glibc if cmogstored is linked to jemalloc (or any non-glibc malloc)?
> 
> Or should jemalloc provide a mallopt() function which may
> wrap mallctl() in some cases and/or just do nothing at all?

mallopt() is a non-standard function, as is jemalloc’s mallctl().  I contemplated what to do about mallopt(), mallinfo(), mallinfo_heap(), etc. while implementing mallctl(), and decided that trying to emulate them would be an exercise in futility.  As for replacing them, I would be uncomfortable having replacements do anything besides call abort(3).  I’ve never followed through with that though, because I’m afraid the cure might be worse than the disease.

In the case of cmogstored, I suggest you conditionalize the mallopt() calls such that they’re only used when using glibc’s allocator.  Since you’re making an explicit effort to support multiple alternative memory allocators, you may end up adding other allocator-specific tuning in #if..#elif..#else..#endif blocks anyway.

Jason