tags:

views:

273

answers:

6

I am working with a memory manager that, on occasion, wants to defragment memory. Basically, I will go through a list of objects allocated by the memory manager and relocate them:

class A {
  SomeClass* data; // This member is allocated by the special manager
};

for(... each instance of A ...) 
    a.data = memory_manager.relocate(a.data);

memory_manager.relocate() will memcpy() the contents of data to a new location, and return the pointer.

Although it's generally not idiomatic to memcpy() C++ classes, it seems to be a useful solution in this case, considering that I control the implementation of the (few) classes that will be used with the memory manager.

The problem is that one of those classes uses std::map, which is an opaque class as far as I am concerned. I certainly don't imagine I can memcpy() it. I may not be able to use std::map in any case. For all I know it could allocate several pieces of memory.

The best workaround I can think of is simple enough. Due to the fact that the fragmented memory manager will put new allocations at more beneficial locations, all I need to do is allocate it anew and then delete the old:

for(... each instance of A ...) {
    stl::map<something>* tmp = a.the_map;
    a.the_map = new stl::map<something>(tmp);
    delete tmp;
}



In any case, this lead me to wonder:

Does C++ have semantics or idioms to move/copy an object into a specific memory location?

Is it possible to move the contents of an stl container to a specific memory location?


Edit: Although I didn't point it out, I would obviously pass an allocator parameter to std::map. Based on the informative answers I got, I realize the workaround I posted in my initial question would probably be the only way to reduce fragmentation. By using the map's copy constructor (and the allocator template parameter), all memory used by the map would be properly re-allocated.

As a comment pointed out, this is mostly a theoretical problem. Memory fragmentation is rarely something to worry about.

A: 

You did not mention which platform you are coding for or if that is allowed to matter. But in Linux and the GCC, the C++ default allocator is implemented with malloc.

malloc can be overridden and replaced with your own internal allocator.

I would implement this malloc as follows:

in the general case, just defer to original malloc. Whenever you want to, you can change the behavior of the malloc function to return pointers to this special memory area you have prepared.

So, before creating this particular std::map you would give your malloc a hint. (Through a global variable or some other means of communication.)

Update: alemjerus suggested implementing std::map::allocator which is a much cleaner way on the same theme, also platform agnostic.

Amigable Clark Kant
+1  A: 

No, C++ manages memory solely by itself, but you can help stl to do it by implementing std::map::allocator, which will do it all your way so you won't need memcpy it.

alemjerus
+2  A: 

The contents of a C++ object will be scattered around the heap. A STL object for example a container or string etc might store its meta-data on your stack (if you don't put it in dynamic memory) ... however the contents are scattered arround the heap.

It will be a hard task to keep track of all the elements of an object, and all the references to these elements. The language has to provide some form of "hooks" or events to enable tracking the relationships between chunks of memories.

So no, you can't just memcpy a arbitrary STL object.

Afaik overriding new is not a panacea, it is a "process global" concept so trying to localize the news to a thread-object-allocation pair is not possible. And this localization would enable you to group the memory together.

You could write your own containers that used a custom memory allocator explicitly (explicit because your provide the necessary object identity information), and there are some custom allocators out there.

Hassan Syed
+2  A: 

You could use placement new?

void* adress = new void[size_of(*old_map_ptr)]; // or wherever you want it in your memory
map<type> new_map* = new (adress) map<type>(*old_map_ptr);
delete old_map_ptr;
Viktor Sehr
Make sure you match the `delete/delete[]` with the original allocator - in the code Viktor provides a `new[]` is matched to a `delete` which is wrong. `new[]` should be matched with a `delete[]`.
Douglas Leeder
Also the majority of the space 'used' by the `std::map` will be in heap allocated memory allocated by std::map, that you can't control in this way.
Douglas Leeder
Yupp, actually, using placment new for containers, or any class containing pointers, are most often quite unnessesary.
Viktor Sehr
Ah, placement new. Now there's some syntax that escaped me until now. I'm glad to have learned about it.
A: 

You can use placement new to define where the base std::map object lives. But the majority of the space will be allocated on the heap, by std::map.

Douglas Leeder
+3  A: 

Everytime you insert a new key,value pair the map will allocate a node to store it. The details of how this allocation takes place are determined by the allocator that the map uses.

By default when you create a map as in std::map<K,V> the default allocator is used, which creates nodes on the heap (i.e., with new/delete).

You don't want that, so you'll have to create a custom allocator class that creates nodes as dictated by your memory manager.

Creating an allocator class is not trivial. This code shows how it can be done, you'll have to adapt it to your own needs.

Once you have your allocator class (let's say you call it MemManagerAllocator) you'll have to define your map as std::map<K, V, MemManagerAllocator> and then use it like you would use a regular map.

Personally, I would need to have a really bad problem of memory fragmentation to go into all that trouble.

Manuel
My initial question already assumed the use of an Allocator parameter. (Otherwise, as several people pointed out, most of the map would live on the heap, and the workaround would do nothing of interest). But I absolutely should have pointed that out.
The task is much more complex, besides moving the memory you would need to update implementation defined private members in the map internals so that the `left`, `right` and `parent` pointers in the nodes refer to the new locations. Any existing iterator into the map will be invalidated by the operation, so either you go hunting for them (possibly up in the stack) and update their internals (implementation defined, private) or else you will be breaking the invariants that the standard guarantees...
David Rodríguez - dribeas
@David - Isn't it enough to create a new map with the copy constructor? Of course the problem of invalid iterators would still remain but I don't think that's too important
Manuel
@Manuel: you are right, recreation of the map will solve the problem of the 'tree' structure, and if the copy constructors in the used types within the map manage the internal object's pointer updates that would reduce the problem quite a bit. There would still be issues with already existing iterators, and pointers/references into the elements stored in the container that can be outside of the map.
David Rodríguez - dribeas