Re: [RFC] how to get the size of a malloc(9) block ?

On Fri, Nov 29, 2013 at 5:02 PM, jb <jb.1234abcd_at_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_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>



-- 
-----------------------------------------+-------------------------------
 Prof. Luigi RIZZO, rizzo_at_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)
-----------------------------------------+-------------------------------