3

When we use malloc() we provide a size in byte. When we use free() we provide nothing. This is because the OS of course knows about it already, it must have stored the information somewhere.

By the way, also our software must remember how many memory blocks it has requested, so that we can (for instance) safely iterates starting from the pointer and going ahead.

So, my question is: isn't this redundant? Can't we simply ask the OS the size of the memory pointed by a given pointer since it knows it? And if not, why not?

Magnus Hoff
  • 21,529
  • 9
  • 63
  • 82
nyarlathotep108
  • 5,275
  • 2
  • 26
  • 64
  • 7
    The block allocated could be *larger* than what we requested. – Magnus Hoff Sep 17 '14 at 13:00
  • 1
    asking the os everytime you access the data pointed by that pointer? seems like too many request will go to the os. compared to the small space that it will take if we store that value somewhere in the program. – Haris Sep 17 '14 at 13:01
  • 2
    Some background details are given in http://stackoverflow.com/questions/1518711/how-does-free-know-how-much-to-free – Lanting Sep 17 '14 at 13:04
  • I like this answer: http://stackoverflow.com/a/3083006/2971 It sketches out some alternative allocation strategies which illustrate how a good allocator can work without keeping track of how much the user asked to allocate. Voting to close this question as a duplicate. – Magnus Hoff Sep 17 '14 at 13:40
  • The OS generally doesn't know, the CRT is built on top of OS memory management primitives. Not being able to query the size of a heap block was quite intentionally omitted. If you need to know then you're doing it wrong. – Hans Passant Sep 17 '14 at 13:43

3 Answers3

2

When we use malloc() we provide a size in byte. When we use free() we provide nothing. This is because the OS of course knows about it already, it must have stored the information somewhere.

Even though it gives you memory and it keeps track of what memory range belongs to your process, the OS doesn't concern itself with the internal details of your memory. malloc stores the size of the allocated chunk in its own place, also reserved inside your process (usually, it's a few bytes before the logical address returned by malloc). free simply reads that reserved information and deallocates automatically.

By the way, also our software must remember how many memory blocks it has requested, so that we can (for instance) safely iterates starting from the pointer and going ahead.

So, my question is: isn't this redundant? Can't we simply ask the OS the size of the memory pointed by a given pointer since it knows it? And if not, why not?

Given the above, it is redundant to store that information, yes. But you pretty much have to store it, because the way malloc does its book-keeping is an implementation detail.

If you know how your particular implementation works and you want to take that risk for your software, you are free (no pun intended) to do it. If you don't want to base your logic on an implementation detail (and you'd be right not to want to), you'll have to do this redundant book-keeping side-by-side with malloc's own book-keeping.

Theodoros Chatzigiannakis
  • 28,773
  • 8
  • 68
  • 104
  • As a previous commenter noted the runtime might reserve more memory, and thus have noted a bigger allocation down. Still, the address of the allocation may well map to its size, or `free` might be a no-op and nobody keeps track of it. – Deduplicator Sep 17 '14 at 13:17
  • This answer seems to boil down to "it is necessary to have this redundancy because there is no available interface to ask the memory allocator about this". I think a more insightful answer would address the reasons why no such interface exists: The redundancy is rarely perfect, ie. the memory allocator rarely remembers exactly how big the allocation was supposed to be. – Magnus Hoff Sep 17 '14 at 13:20
1

No, it's not redundant. malloc() manages, in cooperation with free() and a few other functions, a zillion tiny, individually addressed blocks within relatively large blocks which are generally obtained with sbrk(). The OS only knows about the large range(s), and has no clue which tiny block within it are in use or not. To add to the differences, sbrk() only lets you move the end of your data segment, not split it into parts to free independently. Though one could allocated memory using sbrk exclusively, you would be unable to free arbitrary chunks for reuse, or coalesce smaller chunks into larger ones, or split chunks without writing a bunch of bookkeeping code for this purpose - which ends up essentially being the same as writing malloc. Additionally, using malloc/free/... allows you to call sbrk only rarely, which is a performance bonus since sbrk is a system call with special overhead.

Alex North-Keys
  • 4,200
  • 1
  • 20
  • 22
0

When we use free() we provide nothing.

Not quite true; we provide the pointer that was returned by malloc.

Can't we simply ask the OS the size of the memory pointed by a given pointer since it knows it?

Nope. Pointers are simply addresses; apart from their type, they carry no information about the size of the object they point to. How malloc/calloc/realloc and free keep track of object sizes and allocated vs. free blocks is up to the individual implementation; they may reserve some space immediately before the allocated memory to store the size, they may build an internal map of addresses and sizes, or they may do something else completely.

It would be nice if you could query a pointer for the size of the object it points to; unfortunately, that's simply not a feature of the language.

John Bode
  • 119,563
  • 19
  • 122
  • 198
  • It's not a feature of malloc(). There's no reason a function which was aware of how malloc() is implemented couldn't return housekeeping information. However, since there is no guarantee that malloc() will be implemented in any specific fashion, there's also no guarantee that such a function could be implemented in a portable manner. And yes, I'd =love= to be able to ask how large my allocated space happened to be. – Julie in Austin Jan 27 '15 at 15:51