Re: Memory size and allocation

[Steve Baker <sjbaker1@airmail.net>]

Francesco Orsenigo wrote:
> 
> I've got two questions:
> 
> 1) Is there a portable way to know the size of a malloc()ed memory block,
> knowing just its address?

Well, I don't think there is a *portable* way - I've seen a call on some
UNIX'en (IRIX for example) called 'mallocsize' or something like that - but
it's not portable.

It seems nonsensical that the malloc system wouldn't be able to tell you - 
you'd think that it would have to know in order to maintain it's internal
stats.  However, that's not the case.  Some memory allocators do things
like maintaining large arrays of fixed sized blocks in order to avoid memory
fragmentation.  If you ask for a chunk of ram less than that size then the
allocator will give you one of those fixed size chunks.  Hence, it MAY not
know the exact size you asked for (although it may know how much it gave
you).  The C standard doesn't rule on what mechanism is used by the underlying
allocator (that's "A Good Thing") - so it doesn't make sense to offer to
tell you the size - which would have the effect of imposing extra workload
on the vast majority of programs that either don't care what sizes things
are - or can keep track themselves.

You could write:

  void *mymalloc ( size_t x )
  {
    void *res = malloc ( x + sizeof(size_t) ) ;
    *((size_t *)res) = x ;
    return res + sizeof(size_t) ;
  }

  void myfree ( void *p )
  {
    free ( p - sizeof ( size_t ) ) ;
  }

  size_t mymalloc_size ( void *p )
  {
    return ((size_t *)res)[-1] ;
  }

(that code isn't tested!!)

The idea is to allocate a block that's bigger than you asked for and to
store the size into the start of the block and return the address somewhere
into the block)...I'll leave it to you to write mycalloc, myrealloc, etc.

> 2) When malloc() fails, my program frees memory up to the required size, in
> the hope that the freed blocks were contiguos.

You can hope - but there is no guarantee that'll work.

> The eldest memory blocks (in order of usage) are freed first.
> Is this a good way to handle data dynamically?

That's impossible to know because it depends so much on the underlying
mechanism - which is not part of the C specification.

You could imagine that your malloc implementation was using the 'fixed size
block' trick for allocations less than 256 bytes - in those cases, you could
free up any number of 100 byte blocks - and never free up enough RAM to allow
you to allocate a 1000 byte chunk.

> How can I improve it?

I think that if you truly expect your program to *NEED* to do this (very few
do), then you should write your own memory allocator.

Have it call 'malloc' to grab (say) a megabyte of RAM at a time - then do your
own allocation within that chunk.  Then you have full control of the system
and you can *KNOW* how it'll behave.

Alternatively, you could grab the source code for the GLIBC 'malloc' implementation
and hack that to do what you want (Remembering the licensing rules of course!)

----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net>   WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net