Date: Fri, 29 Nov 2013 17:21:32 -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%2BiCjnxUMP0v6d5ez=n07MBT5hLXzoa%2B1wTff3Wrtm=SHQ@mail.gmail.com> In-Reply-To: <loom.20131130T012034-966@post.gmane.org> References: <CA%2BhQ2%2BgK1pc_aS1LEKp29Bi=MHFtJCkw2uOrib_9wQ-7AziH=w@mail.gmail.com> <loom.20131130T002152-608@post.gmane.org> <CA%2BhQ2%2Bj0cYW0dfhEtMGRXWhXhS=VF_N_ZB=JmcqRUofFKWXFiQ@mail.gmail.com> <loom.20131130T012034-966@post.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 29, 2013 at 5:02 PM, jb <jb.1234abcd@gmail.com> wrote: > Luigi Rizzo <rizzo <at> iet.unipi.it> writes: > > > ... > > > 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. > > ... > > This is not necessarily true - I omitted the details of reallocation > implementation on purpose. > From the caller's point of view, if it requested allocation of memory > size, then that's what it wanted in the first place. If it got it, then > there is no other info needed. > This is not what we are discussing. We are discussing the case where the caller, _before_ requesting extra memory, would like to know how much space is available to make different decisions such as 1. realloc unconditionally 2. give up 3. allocate a separate block and chain to it 4. reduce its requirements and live with what extra space is available (if any). Your suggested flags support #1 and #2 directly, #3 can be simulated with realloc(NO_ALLOC) + malloc(), but prevent #4. cheers luigi Next, if the caller came to the conclusion that more would be needed, then > it should ask for memory reallocation, trusting that the system will do it > in the most efficient way. > If the caller wants to influence that process, then proper option(s) are > needed in reallocation API, e.g.: > - with no copy > - with copy > That means one call with options, with a specific (wanted by user) result. > Of course, thinking thru the options (default, mutual exclusion, etc) is > an important process and subject to RFC. > A user-empowering API. No magic, no hacks. > > So, how about Request-for-Enhancement to GNU C lib, and the ugly hacks > will disappear quickly. > > jb > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+-------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BhQ2%2BiCjnxUMP0v6d5ez=n07MBT5hLXzoa%2B1wTff3Wrtm=SHQ>