From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 01:21:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EAF7467 for ; Sat, 30 Nov 2013 01:21:35 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 776F41BCB for ; Sat, 30 Nov 2013 01:21:34 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id er20so7110938lab.36 for ; Fri, 29 Nov 2013 17:21:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BufjPVSFRVHv8S1mZe5eJruyvsgsUb0YyRWt7UWAOuU=; b=zl67t0dnivxzeeoTFhR9hih7NBRl+kSUI9ox5FRMguUgO9G/slvbfLQhK8oYyoWF2V zQgaX0lohchG2A90Kpa47cdZxTskakjqoeyMk5g+YWXqzKzqo07yS/8fKmzZTua9d+Mv aTvH8zdJ4cajtxiFinusZZYuG99zcpzaASm252nbSzyNVGlAdUBuCPGbQldUXmQKDVAv dFReKnwKj0paFcq7BWiFX1WU4mS8P8aY+uH4iCbx1tQA3LhfX8bzrWTcdL7Pzrdi89v+ +GU9rW+IwHAGospDsgcZpnBFqq/RDGvrAxL80rzgSzbMA7NzjqZIQCysgsum1eMxEIKA WLMQ== MIME-Version: 1.0 X-Received: by 10.152.140.193 with SMTP id ri1mr37841646lab.18.1385774492449; Fri, 29 Nov 2013 17:21:32 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.175.180 with HTTP; Fri, 29 Nov 2013 17:21:32 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Nov 2013 17:21:32 -0800 X-Google-Sender-Auth: uHrxfkgvCLwMj6jBW2zV1WSu7Iw Message-ID: Subject: Re: [RFC] how to get the size of a malloc(9) block ? From: Luigi Rizzo To: jb Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 01:21:35 -0000 On Fri, Nov 29, 2013 at 5:02 PM, jb wrote: > Luigi Rizzo 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) -----------------------------------------+-------------------------------