Date: Fri, 29 Nov 2013 16:03:48 -0800 From: Luigi Rizzo <rizzo@iet.unipi.it> To: jb <jb.1234abcd@gmail.com> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: [RFC] how to get the size of a malloc(9) block ? Message-ID: <CA%2BhQ2%2Bj0cYW0dfhEtMGRXWhXhS=VF_N_ZB=JmcqRUofFKWXFiQ@mail.gmail.com> In-Reply-To: <loom.20131130T002152-608@post.gmane.org> References: <CA%2BhQ2%2BgK1pc_aS1LEKp29Bi=MHFtJCkw2uOrib_9wQ-7AziH=w@mail.gmail.com> <loom.20131130T002152-608@post.gmane.org>
index | next in thread | previous in thread | raw e-mail
On Fri, Nov 29, 2013 at 3:44 PM, jb <jb.1234abcd@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: > - 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 > i respectfully disagree :) but am not pushing to add ksize. Just note that both mine and your "well defined API" leak details: yours is (A) "I may be overallocating but won't tell you how much"; mine is (B) "I may be overallocating and here is exactly how much". Now if I may make a comparison with going shopping, I'd rather hear the final price from the seller (case B), than having to guess by repeated trial and error, which is what case A leads to if i really want to figure out. > 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. > Honestly i did not even know they existed until a few days ago; but the fact that many different systems have come out with similar extensions at least make me wonder whether the SUS missed it. cheers luigihome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BhQ2%2Bj0cYW0dfhEtMGRXWhXhS=VF_N_ZB=JmcqRUofFKWXFiQ>