On Fri, Nov 29, 2013 at 08:37:28PM -0800, Tim Kientzle wrote:
> On Nov 29, 2013, at 3:44 PM, jb <jb.1234a...@gmail.com> wrote:
> > 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:
> Don?t forget:
>  * Request a block of ?at least N bytes? and have the
> allocator tell you what it *really* allocated.
> This allows applications to use memory more efficiently
> by taking advantage of over-allocation when it happens.

Taking random message in the thread.

IMO, more important point of this API is not to allow the code to
micro-optimize. By the nature of malloc-like API, consumer code usually
pass only the allocated pointed around, without attached notion of the
size.  Just note the signature of free(9) or free(3).

As consequence, any interceptor-like functionality, e.g. performing
accounting, leak detection, consistency analysis or anything else
somebody could imagine, has to either track correspondence between
allocation address and size on its own, or dive deep into the allocator
implementation to obtain the size from address.

When I am working with user-space and doing any trick with malloc,
this functionality is in fact absolutely required.

Attachment: pgpDj7Oy2TAjR.pgp
Description: PGP signature

Reply via email to