On Fri, Nov 29, 2013 at 08:37:28PM -0800, Tim Kientzle wrote: > > On Nov 29, 2013, at 3:44 PM, jb <jb.1234abcd_at_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.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC