]> git.ipfire.org Git - thirdparty/man-pages.git/commit
mallopt.3: Document M_ARENA_TEST and M_ARENA_MAX
authorCarlos O'Donell <carlos@redhat.com>
Mon, 24 Aug 2015 16:05:02 +0000 (12:05 -0400)
committerMichael Kerrisk <mtk.manpages@gmail.com>
Sun, 30 Aug 2015 10:09:38 +0000 (03:09 -0700)
commit9d116bd272ae32c3c1046cebacf52067b815f84a
tree777f08da8865db67756c329c524c4439d3c5a1e3
parent3f81631283db870e5e28f61f3852a5b41d474c80
mallopt.3: Document M_ARENA_TEST and M_ARENA_MAX

In 2013 I brought up the discussion if M_ARENA_MAX and M_ARENA_TEST
were public parameters:
https://sourceware.org/ml/libc-alpha/2013-03/msg00376.html
Consensus among Siddhesh and myself was that they should be
public, and in fact they were already in the public header.
Therefore there may already be applications uses these constants
and expecting them to work. At best we could limit mallopt()'s
acceptance of the options, but that seems like a bad solution
that could lead to unexpected behavior for user applications.
A quick google search shows that there are packages relying on
these constants to tune the glibc malloc implementation.

Since glibc 2.10 the M_ARENA_TEST and M_ARENA_MAX features
have been part of the public interface with
--enable-experimental-malloc.

Since glibc 2.15 the experimental allocator has been on by default
and M_ARENA_TEST and M_ARENA_MAX have been more broadly used.

There are environment variables, without trailing underscore, that
can also be used to adjust these values at runtime i.e.
MALLOC_ARENA_MAX, and MALLOC_ARENA_TEST.

This change describes these two options in the mallopt(3) man page
along with their environment variables.

Tested with glibc master on x86_64 to verify it works as expected.

Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
man3/mallopt.3