This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug malloc/16939] New: revert malloc hook deprecation or provide an alternative


https://sourceware.org/bugzilla/show_bug.cgi?id=16939

            Bug ID: 16939
           Summary: revert malloc hook deprecation or provide an
                    alternative
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: malloc
          Assignee: unassigned at sourceware dot org
          Reporter: danielmicay at gmail dot com

This feature was deprecated because these hooks aren't usable as a thread-safe
wrapper around the glibc allocator, but they are certainly usable in a thread
safe manner with another allocator where you don't need to save and restore the
hooks before calling the allocator.

The weak symbols aren't a robust way of doing this because they don't work with
static linking, where it will simply cause symbol conflicts. If the deprecation
isn't going to be undone, an alternative should be provided for this use case.

It's important to provide a way of reliably replacing the glibc allocator with
jemalloc, tcmalloc, Hoard or another general purpose allocator. The glibc
allocator may eventually be improved to the point where it's competitive with
jemalloc/tcmalloc for general purpose single/multi-threaded workloads, but
there will still be a use case for allocators targeted at different niches.

We're using jemalloc in Rust by statically linking it into the standard library
and explicitly calling it via the non-standard API, but replacing the glibc
allocator is desirable due to eliminate the external fragmentation caused by
using 2 memory allocators in one process.

Statically linking against the standard C library is questionable, but it's not
really a programming language's place to tell you not to do it, so we need to
use the hooks rather than the weak symbols.

Here's an old post about this by the author of Hoard:

https://sourceware.org/ml/libc-alpha/2011-07/msg00136.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]