Re: mallinfo not 64-bit clean

[steve_dum at mentorg dot com]

I know some of you don't like top quoting, but there is no reason to
continue this asinine tearing apart other peoples messages line by line
-- so I didn't include quotes from the thread.  I thought the goal was
to discuss statistics reporting in malloc and try to find a replacement
for mallinfo that is both useful and has a chance of surviving multiple
implementations of malloc without change.

The other objective, which I think is the underlying source of the animosity
on this thread is consideration of what kind of information needs to be
provided.
A.  My impression is that Drepper wants to present detailed internal
    characteristics of what malloc is doing.  This is clearly very
    release specific and due to it's rapidly changing nature xml, while
    not the only way to present the data, I'll concede (xml) is a way
    to meet all the 'portability' requirements.

B.  On the Other hand, as an application developer, who needs basic
    information out of malloc, on general system performance that level
    of detail is useless.  I believe that James Antill, in his post of
    24 Aug 04 summarized this side best.  The basic information believe
    malloc should provide is
    1) Amount of active space allocations - sum of all sizes of objects 
       currently allocated by malloc(), calloc(), or realloc().
       (this value decreases when blocks are freed)
    2) Count of active allocations - number of currently allocated objects.
    3) Total memory obtained from kernel 
    4) malloc overhead - space used by malloc for internal bookkeeping

    Possibly include the following, which will exceed size_t, and thus 
    if provided should be a struct of 2 size_t's (long long is still not
    completely supported).  They still might overflow, but the value of
    these two fields are less useful to an application anyway.

    5) Total Amount space allocated -- sum of all sizes of objects ever
       requested by malloc(), calloc() or realloc().
       (this value doesn't decrease on free()'s)
    6) Total count of allocation requests - total number of allocation requests
       made by program (even if subsequently returned to system).
       
I believe that presentation of data described under A is really an
internal affair for people wanting to tune successive versions of malloc
and needs to be version dependent.  But for generic information described
in B it is easy to have a simple interface that returns a simple
struct and still have a highly portable interface that spans versions
of malloc with different implementation details.  This simple generic
interface is all that most application developers should be using.
Generally, this would be summary information for the process, but in
some cases, being able to get it for each thread is also useful, but
clearly some implementations may not even be able to break out per thread
info.


steve
--------------
Stephen Dum            steve_dum at mentorg dot com    (503)-685-7743
Mentor Graphics Corp.  8005 S.W. Boeckman Rd.   Wilsonville, Or 97070-7777