Sign in to follow this  
EngineProgrammer

Allocation of memory

Recommended Posts

Hi everyone!

I'm digging into open source engines to understand their memory management but the more I look in it, the more confused I get.

For example Unigine ( it's a nice engine ) uses different headers for all kind of allocations.
[CODE]
struct FixedChunk;
struct FixedAllocator;
struct HeapChunk;
struct HeapPool;
struct HeapAllocator;
struct SystemAllocator;
struct Allocator;
struct Memory;
[/CODE]

Why are they using so many structs(all in different headers)?
An allocator is an allocator so why don't they just write 1 struct: Allocator. and use it for everything.
I don't get it why they uses so many structs. So if someone could explain this for me, thank you!


~EngineProgrammer

Share this post


Link to post
Share on other sites
swiftcoder    18426
[quote name='EngineProgrammer' timestamp='1349707579' post='4988005']
An allocator is an allocator so why don't they just write 1 struct: Allocator. and use it for everything.[/quote]
An allocator is not [b]just[/b] an allocator. There are many, many different types of allocator, each with different behaviours and performance characteristics. Edited by swiftcoder

Share this post


Link to post
Share on other sites
Radikalizm    4807
I can't comment on any design decisions made in unigine, having never used or studied it, but different allocation mechanisms can be desired for different systems. Some contributing factors could be memory layout, consistent contiguous allocations, allocation speed, object lifetimes, etc.

You should be careful with digging through existing code when it comes to allocation schemes, because these systems are most likely not general purpose allocators as you have pointed out yourself, but allocators designed specifically for use in that specific engine with specific memory requirements.

If you are designing an engine (and judging by your name, I assume you are) you'll probably want to look over your own memory requirements when approaching custom allocators, if you even need a custom allocator at all.

Share this post


Link to post
Share on other sites
freakchild    572
[quote name='EngineProgrammer' timestamp='1349707579' post='4988005']
An allocator is an allocator so why don't they just write 1 struct: Allocator. and use it for everything.
I don't get it why they uses so many structs. So if someone could explain this for me, thank you!
[/quote]

Each allocator likely has a mix of common and unique/specific needs based on a unique purpose or scenario. This probably means the structs have slightly differing members based around that need, which likely means the structs have varying sizes. If you packed all structs into one you'd be stuck with the same size struct all the time and the size would always be equivalent to the largest of them all, also always the worst case scenario.

Structs in memory management are often used as headers for blocks of allocations (or sometimes with each allocation) so this would mean that every time you deploy the header it will use the same memory as this worst case scenario, regardless of the other memory you're looking to allocate. If you are using one of the smaller structs that uses only a subset of the members, needing only to occupy just a few bytes then you are wasting memory.

While there are other ways to boil this egg, using different structs allows you to more easily access only the members you need and only use only the memory those members require. Edited by freakchild

Share this post


Link to post
Share on other sites
nife87    520
Two blogs that describe some of the available allocation strategies very well:
http://molecularmusings.wordpress.com/
http://jfdube.wordpress.com/

You might want to take a look at [url="http://www.hoard.org/"]Hoard[/url] (formerly known as HeapLayers), an open-source C++ allocator (collection/library), which enables you to use both general-purpose allocators as well as special-purpose ones. Hoard's real strength is that most of its allocation layers can be composed and extended in nearly countless ways via C++ mix-ins (brilliant idea, IMHO) and that its general-purpose allocator is very efficient for multithreaded applications.
One of the authors, Emery Berger, have also published several, in-depth articles online (most available from his site) about allocation strategies and implementation.

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