Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

322
Visualizações
malloc and heap: extra memory for storing the size and linked list information?

I have a simple question about the heap and malloc:

When we allocate some memory space using malloc as following:

int *p;
p = (int*) malloc (10*sizeof(int));

It actually allocates 10 words in the heap. However, my question is:

The actual memory space used is really 10 words?

Or there are other extra space needed for storing the value of memory size?

Or, even, because the heap is structured as Linked list, is there other memory space being used for storing the address which points to the next node of the list in the heap?

over 4 years ago · Santiago Trujillo
3 Respostas
Responde à pergunta

0

It is completely implementation dependent.

a) It could have a few bytes before each allocated node which contains the size of the node, pointer to the next node, and maybe a previous node pointer and the type of node.

b) The returned item may have nothing else around it except other allocations. A structure elsewhere keeps track of what is allocated and what is free, perhaps by a bitmap or a miniature parallel list.

c) Another variation provides several arrays of fixed sized chunks. One array may provide 32-byte blocks; another 128-byte blocks, etc. A bitmap for each array manages allocations.

d) The most minimal implementation I have seen ignores free() completely (that is, free() is a no op) and allocates the next piece of the pool at each malloc().


By far, the most commonly used modern technique is a. Variant b is used in many filesystems like NTFS and FAT. Option c was/is favored in many DEC operating systems, especially for kernel use. Option d is used by a few minimalist embedded environments with a suitable caveat.

In most implementations, the requested allocation is rounded up to some natural multiple (usually of 2, 8, 16, etc.) convenient for the algorithm. So a series of allocations of 5, 3, 8, 7, 4, 1, and 15 might each be regarded as a 16 byte request.

over 4 years ago · Santiago Trujillo Relatório

0

Memory allocation is dependent on the compiler libraries and the operating system.

Both languages don't state a maximum amount of memory that can be allocated. All you are guaranteed is the requested size.

So if there is any additional memory allocated, it would be platform dependent.

Also, there may be less overhead when allocating larger spaces.

Try writing your own memory allocator and see what is needed, especially when desposing the memory.

over 4 years ago · Santiago Trujillo Relatório

0

Yes, it is possible for an implementation of malloc to actually allocate a little more memory than what you requested, store the size of the allocated memory at the start of the allocated memory, then give you a pointer to the immediate next memory address. When you call free on that pointer, the allocator will go back a little, read the size of the buffer, and figure out how much it needs to actually release.

But of course, another possible implementation could keep a list, or a dictionary, or do something entirely different under the hood, as long as it gives you the same specified behavior.

over 4 years ago · Santiago Trujillo Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda