View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# Allocation of memory

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

4 replies to this topic

### #1EngineProgrammer  Members

Posted 08 October 2012 - 08:46 AM

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.
struct FixedChunk;
struct FixedAllocator;
struct HeapChunk;
struct HeapPool;
struct HeapAllocator;
struct SystemAllocator;
struct Allocator;
struct Memory;


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

### #2swiftcoder  Senior Moderators

Posted 08 October 2012 - 08:59 AM

An allocator is an allocator so why don't they just write 1 struct: Allocator. and use it for everything.

An allocator is not just an allocator. There are many, many different types of allocator, each with different behaviours and performance characteristics.

Edited by swiftcoder, 08 October 2012 - 09:00 AM.

Tristam MacDonald - Software Engineer @ Amazon - [swiftcoding] [GitHub]

Posted 08 October 2012 - 09:04 AM

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.

I gets all your texture budgets!

### #4freakchild  Members

Posted 08 October 2012 - 12:21 PM

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!

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, 08 October 2012 - 12:33 PM.

### #5nife87  Members

Posted 08 October 2012 - 12:55 PM

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 Hoard (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.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.