Public Group

# Custom Allocator

This topic is 1255 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi guys! First post, most of the time only read. I'm taken a look at this article about custom allocators and trying to implement one. There a couple of things on the FreeListAllocator that i don't understand.

1) Knowing that total_size variable already takes into the consideration the header, I don't see sens of this, if fact never can be less than the size of header, same or bigger and only gets inside when is the same size. If it gets inside and the prev block is no null, the prev block now points to the next block of the actual block, leaving this block without any way to get to it.

if(free_block->size - total_size <= sizeof(AllocationHeader))
{
//Increase allocation size instead of creating a new FreeBlock
total_size = free_block->size;

if(prev_free_block != nullptr)
prev_free_block->next = free_block->next;
else
_free_blocks = free_block->next;
}


2) OK! We have a free block, now we create a new block that contains the remaining free memory, but next_block->next = free_block->next it will always point to null, there is no link is generated between them, in fact no list is generated, next_block should points to free_block.

else
{
//Else create a new FreeBlock containing remaining memory
FreeBlock* next_block = (FreeBlock*)( pointer_math::add(free_block, total_size) );
next_block->size = free_block->size - total_size;
next_block->next = free_block->next;

if(prev_free_block != nullptr)
prev_free_block->next = next_block;
else
_free_blocks = next_block;
}


3) At this point we have our aligned address, but the alignment offset only takes into consideration the allocation header. So depending on the offset size the header could override the block memory info (FreeBlock). An other problem that I'm seeing is that in any moment is marking this free block as occupied.

uptr aligned_address = (uptr)free_block + adjustment;



PS: Sorry for my poor english

##### Share on other sites

1) Knowing that total_size variable already takes into the consideration the header, I don't see sens of this, if fact never can be less than the size of header, same or bigger and only gets inside when is the same size. If it gets inside and the prev block is no null, the prev block now points to the next block of the actual block, leaving this block without any way to get to it.

I don't see anything wrong here. The code checks if there's enough room to split up the current FreeBlock into two separate FreeBlocks by checking if there's enough room for an extra AllocationHeader once the requested memory size has been accounted for.

OK! We have a free block, now we create a new block that contains the remaining free memory, but next_block->next = free_block->next it will always point to null, there is no link is generated between them, in fact no list is generated, next_block should points to free_block.

Why do you think that free_block->next is always NULL? If the code is correct then it should point to the next available FreeBlock (which could potentially be a NULL pointer).

At this point we have our aligned address, but the alignment offset only takes into consideration the allocation header. So depending on the offset size the header could override the block memory info (FreeBlock). An other problem that I'm seeing is that in any moment is marking this free block as occupied.

The FreeBlock header is replaced by an AllocationHeader for memory blocks that have been allocated. You don't need both of them at the same time.

##### Share on other sites

I don't see anything wrong here. The code checks if there's enough room to split up the current FreeBlock into two separate FreeBlocks by checking if there's enough room for an extra AllocationHeader once the requested memory size has been accounted for.

So, if the block size is enough big hi splits it into two pieces, if not all the block size is assigned to current allocation, am I wrong?.

Why do you think that free_block->next is always NULL? If the code is correct then it should point to the next available FreeBlock (which could potentially be a NULL pointer).

Because first time free_block->next points to null, but looking closely the list is generated when memory is deallocated. Basically until no deallocation is made the list is always of one node, the remaining available space.

##### Share on other sites

So, if the block size is enough big hi splits it into two pieces, if not all the block size is assigned to current allocation, am I wrong?.

Yes. Advanced allocators are able to join smaller memory chunks together when possible but that obviously slows down allocations and deallocations.

Basically until no deallocation is made the list is always of one node, the remaining available space.

Yes, that's how it's supposed to be. What's the problem with that?

##### Share on other sites

Yes, that's how it's supposed to be. What's the problem with that?

No, no problem, I've made me a mess xD. Thanks for the help.

1. 1
2. 2
3. 3
4. 4
Rutin
12
5. 5

• 12
• 18
• 10
• 14
• 10
• ### Forum Statistics

• Total Topics
632662
• Total Posts
3007702
• ### Who's Online (See full list)

There are no registered users currently online

×