Re: mallinfo not 64-bit clean [PATCH]

[James Antill <nevyn-glibc-alpha at and dot org>]

Ulrich Drepper <drepper@redhat.com> writes:

> Wolfram Gloger wrote:
>
>> Ok, here is what I have coded up today for the mallinfo problem.  A
>> new test is also included.  I don't intend to change the
>> malloc_{arena,global}_info structs any time soon, but they shouldn't
>> be considered 'fixed' either.  I added the three new functions with
>> GLIBC_PRIVATE for now, but maybe GLIBC_2.3.x is justfied.  Your call.
>
> The problem I see is that this interface makes implementation details
> visible.  If the implementation changes at some point we will be in the
> same situation again.

 True.

> The advantage is that the libc interface is stable and programs will
> notice if they don't understand the output format and will be able to
> recover.

 Ok, so you've moved from the change in interface being noticed at
compile time to the change in interface (maybe) being noticed at
runtime ... and this is a good thing?

 I've seen OLS papers that disagree...

http://www.ozlabs.com/~rusty/ols-2003-keynote/ols-keynote-2003.html

 You are still changing the interface, and programs written for the
old interface stop working.

 If you had something like...

 void *malloc_get_stats(void);
 int malloc_get_stat_total(void *);
 int malloc_get_stat_arena(void *, unsinged int);

...and version the functions, if malloc_get_stats() returns NULL the
implementation has changed and you can't use anything else. Then you
can have (or not) compile failure on interface changes ... and you
still have binary compat. for old programs (but they don't suddenly
start getting data they have no idea what to do with).

> I haven't thought about the details much yet, but I imagine an interface
> like this:
>
>   int malloc_get_stats(char *buffer, size_t);
>
> and an XML format like
>
> <mallocstat>
>   <total>123231</total>
>   <arena idx="0">
>     <free>2342</free>
>     <allocated>34534</allocated>
>   </arena>

 So are you going to recommend libxml to decode?
 More likely everyone will assume this "XML" is not really XML and
they'll write their own "parse the triangle brackets" parser assuming
what the constraints are.

 Also as someone who is interested in getting stats out of malloc(), I
wouldn't really care about all the above info. my main points of
interest would be...

 Amount allocated (sum of values passed to malloc(), calloc() or
realloc()).

 Number of active allocations.

 Total number of allocations.

 Amount of overhead (Ie. Total memory from kernel - Amount allocated).

...for any interface involving arenas etc. I'd just write functions to
combine them into the above.

-- 
# James Antill -- james@and.org
:0:
* ^From: .*james@and\.org
/dev/null