Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Nov 2013 23:44:18 +0000 (UTC)
From:      jb <jb.1234abcd@gmail.com>
To:        freebsd-current@freebsd.org
Subject:   Re: [RFC] how to get the size of a malloc(9) block ?
Message-ID:  <loom.20131130T002152-608@post.gmane.org>
References:  <CA%2BhQ2%2BgK1pc_aS1LEKp29Bi=MHFtJCkw2uOrib_9wQ-7AziH=w@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo <rizzo <at> iet.unipi.it> writes:

> ... 
> There is a difference between applications peeking into
> implementation details that should be hidden, and providing
> instead limited and specific information through a well defined API.
> ...

Right.

If you want to improve memory management, that is, have the system (kernel
or user space) handle memory reallocation intelligently and transparently
to the user, then aim at a well defined API:
- reallocate "with no copy", which means new space appended (taking into
  account *usable size*, a hidden-to-user implementation detail), if
  possible
- otherwise fail, and let the user decide about reallocation "with copy"
  or allocation of a new space

The malloc_usable_size() is a hack.
The extra space allocated or not due to fragmentation, alignment, etc, is
an internal by-product, irrelevant to original memory alloc request, and it
should not be leaked, also because its details may change in future API
implementations.
So, these memory allocation functions leaking implementation details, and
the two derived functions, ksize() and malloc_usable_size() (and other
derivatives like malloc_size() in Mac OS X), are a violations of a clean,
safe, and maintainable API.

Note that malloc_usable_size() is a GNU C Library extension, not part of
Single UNIX Specification.

jb
 





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?loom.20131130T002152-608>