[RFC] New mallinfo64 as alternative for 32bit mallinfo

[Holger Hopp <holger dot hopp at sap dot com>]

Hi,

The mallinfo() interface only supports 32bit data and no 64bit
data. Supporting 64bit in this case is getting more and more
important: machines are getting bigger and it is more likely than
processes can allocate more than 4GB heap memory.
This is already known since years, but there is still no suitable
interface available now:

- mallinfo cuts off data to 32bit values. The interface should
  or could not be changed due to compatibility reasons.

- malloc_info (returning a XML string) is a slow and extensive
  interface for the simple task of reporting some data for monitoring
  and it does not even report the mmap memory. --> useless

- calculating sbrk values is simpler than malloc_info for getting the
  sbrk'ed memory, but also does not report the mmap memory.
  --> also useless

- malloc_stats reports the sum of sbrk'ed and mmap memory, but stderr
  is a very bad method for transfering some data to a caller. stderr is
  usually used for stuff like error reporting. Additionally, several
  threads could write to stderr. So stderr could be only useful for
  debugging purposes, but not e.g. for monitoring purposes. --> bad

- malloc_get_state only returns void*. It is possible to get
  all information using glibc internal code, but this interface could
  change in future glibc versions. Additionally there are legal
  issues (glibc GPL, publicheaders+libs LGPL). This is bad. But a
  solution could be making this interface public (e.g. via returning a 
    struct malloc_save_state {
      long          magic;
      long          version;
      union { 
        struct impl_1 {...}; 
        struct impl_2 {...};
        struct impl_3 {...}; 
        ... 
      }
    } *
  instead of returning a void*).
  This interface is open for future extensions or completely
  different internal implementations. The implementation returned
  can be identified by the magic and version fields. It is callers
  job to decide how many versions need to be considered on caller side.
  I think this type of interface is acceptable as long as the
  numbers of implementations is small. Currently, changes seem to be
  rare (at least for glibc-2.11 to glibc-2.20 there were no changes).


Solution:

We propose a new function mallinfo64 (or: mallinfo_long, or whatever)
that does the same as mallinfo, but with 64bit data. This mallinfo64
is easily to implement by using the existing mallinfo code with 64bit
values. The old 32bit mallinfo (for compatibility reasons) could call
mallinfo64.

An alternative solution could be a public malloc_get_state interface.


Additional info:

- Previous old Threads:
  https://www.sourceware.org/ml/libc-alpha/2004-08/msg00007.html
  https://www.sourceware.org/ml/libc-alpha/2004-08/msg00053.html

- On other UNIX operating systems (AIX, Solaris) mallinfo already
  returns 64bit values.

Thanks,
Holger