This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: mallinfo not 64-bit clean
- From: Wolfram Gloger <wmglo at dent dot med dot uni-muenchen dot de>
- To: steve_dum at mentorg dot com
- Cc: libc-alpha at sources dot redhat dot com, drepper at redhat dot com, nevyn-glibc-alpha at and dot org
- Date: 7 Sep 2004 15:33:55 -0000
- Subject: Re: mallinfo not 64-bit clean
- References: <200409032204.i83M4EId018279@drdoom.wv.mentorg.com>
Hello,
Sorry for the delay, but I have thought about this some more.
> How about the following alternative! Check out ioctl(2). Here is an
> interface that is extensible, time proven, etc.
> int get_malloc_statistics(int request, ...)
>
> You can setup some defines for the request,
> #define MALLOC_ALL_ARENAS 000000 /* get summary data for all arena's
> */
> #define MALLOC_CURR_ARENA 000001 /* get data for current arena */
> #define MALLOC_SELECT_ARENA 000002 /* specify arena of interest */
This would be ok too, I only note a few aspects:
- not really very efficient in the common case if you want to get
_complete_ stats (unless we pass back a big struct -- then we are
back with my proposed patch), but that would be fine with me -- I
really cannot believe malloc stats are performance-critical
- MALLOC_SELECT_ARENA would be thread-unsafe, it would be _much_
better to always specify the arena number or a magic value for
"current arena" (of the calling thread) in the "..." parameters
- not typesafe...
> This interface is time tested, efficient, extensible, etc. Not only
> does this allow
> moving malloc_stats out of malloc, so stdio isn't there, it also avoids
> adding
> in a bunch of data formatting commands into malloc.
Yes. I think a good solution is either
(A) such a get_malloc_statistics() call: this function would need to
be within libc, but I think it could well become
get_libc_statistics() for a more general interface, there are
surely more interesting variables in the C library than just
malloc stats
or:
(B) export "struct opaque * _int_get_arena(int n)" from libc like in
my proposed patch, and do all the messy versioned processing in a
separate library _outside_ libc. Note that global (non
arena-related) info can be obtained from the already exported
malloc_get_state().
Either way it would be just _one_ new exported function in libc, and
no foreseeable incompatibilities/restrictions. Uli, what would you
prefer?
Regards,
Wolfram.