2

I allocate a big memory pool from RTOS (I already know my application memory requirement, it will not grow beyond a certain size). And then my application allocation requests are fulfilled from that pool.

Recently I started facing a problem; allocation request were not being fulfilled even though memory was there (got integrated memory bench marking framework, which showed this), investigation reveals we are suffering from memory fragmentation.

My application is heavily dependent on STL (also receive data from network, XML parsing, image manipulation, saving it as PNG etc), and as heap memory allocation behind memory fragmentation (are there any other reasons?), What are best ways to avoid it?

jreem
  • 7
  • 5
Saqlain
  • 17,490
  • 4
  • 27
  • 33
  • There are many ways to skin that cat. But, is your pool allocator really better than the default `new/delete`? – jxh Apr 06 '13 at 08:19
  • 1
    Programmers that implement their own sub-allocator often end up making that Uppsala pilgrimage. Rounding up allocation sizes might be a Q&D fix. – Hans Passant Apr 06 '13 at 12:22

3 Answers3

4

The typical cause for memory fragmentation is that large memory blocks gets split into smaller and smaller chunks as the pool ages. The simple way to avoid this is to have fixed sizes.

This clearly doesn't solve the problem that use 18MB of storage for XML where each XML node is stored as a small string, and then trying to load a 4096 x 4096 x 8bit PNG (16MB), if your pool is 24MB, because the XML will split your memory into tiny bits, and then you need 16MB of contiguous memory. But the "fixed sizes" will avoid an XML string of <aaa>b</aaa> taking up 4 bytes and 2 bytes of memory, thus making the memory completely useless for anything else ever being stored there, since no other object is 4 or 2 bytes long.

This method will require that your memory allocator as such is being written to take "fixed sizes" into account.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
2

The first step would be to see if the RTOS provides any mechanism for low-fragmentation heaps.

If not, see if someone else already implemented a low-fragmentation allocator. A related question (from the right side bar) suggests an example.

Third, if no other existing solution works, a solution would be to use multiple memory pools for allocations.

Service short lived allocations of size 1 to X bytes from one pool and long lived allocations of size 1 to X bytes from another.

Similar for allocations of size X + 1 to 2X, 2X +1 to 4X, 4X + 1 to 8X and so on. (You may experiment with other bucket sizes...)

To determine the best size for X you will need to profile your app and see the frequency of each allocation size.

Make sure each bucket has enough space to fulfill the allocations :)

Community
  • 1
  • 1
Andrei
  • 4,880
  • 23
  • 30
0

Hypothetically: Switch to garbage collection. You need a compacting garbage collector, one that is able to physically move around allocated data, else it won't help with fragmentation.

  • Garbage collection is not necessarily incompatible with real-time requirements. Real-time means "your system has to guarantee reaction within a certain deadline". If the garbage collector works incrementally and can guarantee a sufficiently short "hold-the-world"-phase, you're fine.
  • Performance of modern garbage collectors is not all bad. People always tend to forget that free and delete are pretty expensive operations also.
  • There are trade-offs with garbage collection: The most efficient ones have long hold-the-world-phases. The ones with short hold-the-world-phases have lower overall efficiency.

Unfortunately all this is hypothetical, as I currently don't know of any compacting, incremental garbage collector for C++. Except maybe C++/CLI.

edgar.holleis
  • 4,803
  • 2
  • 23
  • 27