Date: Sat, 30 Nov 2013 16:06:50 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: FreeBSD current <freebsd-current@freebsd.org> Subject: Re: [RFC] how to get the size of a malloc(9) block ? Message-ID: <20131130140650.GB59496@kib.kiev.ua> In-Reply-To: <8BCD215D-55D8-452F-AAFC-8BC07AEDB76C@freebsd.org> References: <CA%2BhQ2%2BgK1pc_aS1LEKp29Bi=MHFtJCkw2uOrib_9wQ-7AziH=w@mail.gmail.com> <loom.20131130T002152-608@post.gmane.org> <8BCD215D-55D8-452F-AAFC-8BC07AEDB76C@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <jb.1234abcd@gmail.com> wrote: >=20 > > Luigi Rizzo <rizzo <at> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131130140650.GB59496>