Sign in to follow this  
Alex B.

Some things about memory management

Recommended Posts

Hi guys,

 

I'm working currently on a memory management system for a game engine.

I've read a lot of articles and books about it and think I understood the main part, still there are some questions:

 

 

If I understoo it right you have to take the memory youwant to use over the game ap as a static field.

 

fr example i got an linear allocator:

I would do something like this

 

char* subsystemMemory[2048];

linearAllocator.start = subsystemMemory;

 

char* renderSystem = linearAllocator.Allocate(sizeof(renderSystem), 4);

 

So to say I could do a file, where i declare all of the memory as static and use it over the game?

 

Next would be the alignment: Do I have to align my memory always in the type of the system im working? example: 32bit 4 byte align and so on?

 

Last I know about linear, stack, double-ended stack and pool allocators. Are there more that I should learn about?

 

 

Thank you for your time and merry christmas!

Alex

Share this post


Link to post
Share on other sites


If I understoo it right you have to take the memory youwant to use over the game ap as a static field.



fr example i got an linear allocator:

I would do something like this



char* subsystemMemory[2048];

linearAllocator.start = subsystemMemory;



char* renderSystem = linearAllocator.Allocate(sizeof(renderSystem), 4);



So to say I could do a file, where i declare all of the memory as static and use it over the game?

 

I think this is a perfectly valid way to do it, but I don't think you "have" to do it that way. I've always acquired the memory for my memory allocators by calling the system's memory allocation function (e.g. malloc).

 

In fact, in some cases your approach won't work. e.g. Some consoles have multiple memory 'arenas', and any static allocations will always come only from the default arena. so if you want to make an allocator for MEM2 on Wii for instance, you would need to use a different approach.

 

Regarding alignment, it's not unusual for the caller to have some alignment requirement so any general purpose allocator should have that functionality built in. It's also pretty reasonable to set the minimum alignment to 4 bytes for a 32-bit platform, 8 bytes for a 64-bit platform, or just round up to 16 byte alignment to make life easier for SIMD

Share this post


Link to post
Share on other sites

So you just take a huge block of memory allocated by malloc and use this block then for your own allocators?

 

But for Pc only it should work i hope :)

 

If I always round up to 16 bytes wouldnt that be a huge waste of memory?

Share this post


Link to post
Share on other sites

So you just take a huge block of memory allocated by malloc and use this block then for your own allocators?
 
But for Pc only it should work i hope

 

In principal this should work fine on other platforms as well. You might not call malloc to get the memory originally, but the idea is the same.

 

 

 


If I always round up to 16 bytes wouldnt that be a huge waste of memory?

 

Probably not, unless you're doing tons of allocations. 

 

As C0lumbo said, there are often alignment requirements for different uses of memory. Not as much on the PC, but on consoles it's pretty standard for, for example, texture data to require 256 byte alignment (or more!) or sound data to be 32 byte aligned, or whatever. Rounding everything up to 256 bytes probably WOULD be a huge waste of memory, so in practice your allocator should have an AllocateAligned() function that takes a size and an alignment. Then the regular Allocate function will just call AllocateAligned with whatever default alignment you deem necessary. When you need memory that's explicitly aligned, you call AllocateAligned with your required alignment instead of calling Allocate and relying on the default alignment.

Edited by Samith

Share this post


Link to post
Share on other sites


If I always round up to 16 bytes wouldnt that be a huge waste of memory?

 

I believe that the heap allocator in visual studio always rounds to at least 16 bytes. It'd only be wasteful if you do a lot of, say, 4 byte sized allocations, but if you have a system that is doing that, then maybe it should use your pool allocator instead of your general purpose allocator. (I only suggest that a minimum 16 byte alignment for the general purpose heap allocator, I think it'd be a bad idea for mempools, as you usually use them when a system wants large numbers of small allocations)

Share this post


Link to post
Share on other sites

thanks for th replies guys :).. I think I understood what u mean. so for different stuff I have to use different alignments. I thought I have to align the whole data of the game to on boundary..

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this