From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 14:06:56 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 1372F470 for ; Sat, 30 Nov 2013 14:06:56 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A95251659 for ; Sat, 30 Nov 2013 14:06:55 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAUE6oRR028076 for ; Sat, 30 Nov 2013 16:06:50 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAUE6oRR028076 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAUE6oKE028075 for freebsd-current@freebsd.org; Sat, 30 Nov 2013 16:06:50 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 30 Nov 2013 16:06:50 +0200 From: Konstantin Belousov To: FreeBSD current Subject: Re: [RFC] how to get the size of a malloc(9) block ? Message-ID: <20131130140650.GB59496@kib.kiev.ua> References: <8BCD215D-55D8-452F-AAFC-8BC07AEDB76C@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R6wYhkMFzQRgf+Dz" Content-Disposition: inline In-Reply-To: <8BCD215D-55D8-452F-AAFC-8BC07AEDB76C@freebsd.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home 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 14:06:56 -0000 --R6wYhkMFzQRgf+Dz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 29, 2013 at 08:37:28PM -0800, Tim Kientzle wrote: >=20 > On Nov 29, 2013, at 3:44 PM, jb wrote: >=20 > > Luigi Rizzo iet.unipi.it> writes: > >=20 > >> ...=20 > >> 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. > >> ... > >=20 > > Right. > >=20 > > If you want to improve memory management, that is, have the system (ker= nel > > or user space) handle memory reallocation intelligently and transparent= ly > > to the user, then aim at a well defined API: >=20 > Don?t forget: >=20 > * Request a block of ?at least N bytes? and have the > allocator tell you what it *really* allocated. >=20 > 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. --R6wYhkMFzQRgf+Dz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSmfD6AAoJEJDCuSvBvK1BVkcP/3zJ/FwrHUUV0Ij2N0AJA0o4 fuD459lwGxB2E1x5NDk/ERV3ZhACAmTs6ED7pfk3oXZk6yWClU08XWjBbQyzP5B8 QtUQaZ5gAUQWH4itsEu4oAWUfZw6SumNx/kJcDb1es1tzVdnBqZd6OKDyFn4BTB7 etBCgiC/7FKD2BQ3rFpKQvf5DgP/2hwXbFavftf05hAWktEUi3ALYZ3uWgXNF6qb RORBWSz6rwGl+OkncpZ+Haiof5I9FY+W0monAeaD5ewY+ROMV1Iy6GnMFH5iXCKb 1hVIWNCHeaMMiYCAVjkQqs8S62MhDUn+ISwbjq4f0iN1NYgfncOOHc2IkqC9Yndd hvs8enROH8z3ZvSVfAKhSPWIQ8qiDyzCJfiN/Oxl/BKN6XOjFbx8iAeg4Vk/T2Zf KcwTHMvAZP7SIc33FuI56N8CwcUsMgDs3otljiKBUAxAj7NXqKZO4+gViXoZmIIm zuDzILEwxkfGFYAnnEwAQ1aNZ26sjWuRxCFNpBN4AZW7g0kXEMVVyctmDioBA9GT ocsPnTxJyFNgkr51TRMIUUxaIDeHvOQhc85d/WRXEtI0Eb3IkT8CoyczPu/nNztG USVf7LP4pkwsu+FxYHO7LkmOQN6B2GHiaMGfqmYj19NCDASW0NUkfdPDR1MPLkTT JPuLeRMZ9q45ax0q28Dd =tycF -----END PGP SIGNATURE----- --R6wYhkMFzQRgf+Dz--