Jason Evans <[email protected]> wrote: > On Nov 17, 2013, at 2:47 PM, Eric Wong <[email protected]> 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]. > > > > 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. Thanks for the response. Is having mallopt() be a no-op acceptable to you? That would be acceptable to me. > 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. I'm trying to conditionalize the build already, but the problem is that mallopt detection succeeds with glibc even if I use LIBS=-ljemalloc (or any alternative allocator). So I'm wondering if there's a way to stop mallopt detection if jemalloc is used on a GNU system. I suppose I could use dlsym to find mallctl and use that as an indicator jemalloc is linked into the process at runtime. But maybe there's a better way... _______________________________________________ jemalloc-discuss mailing list [email protected] http://www.canonware.com/mailman/listinfo/jemalloc-discuss
