2

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.

porgarmingduod
  • 7,668
  • 10
  • 50
  • 83
  • 2
    Why do you want to compact memory? Have you done profiling to confirm it is necessary? – ebo Feb 11 '10 at 11:25
  • 1
    A much simpler and more efficient solution is to ditch that memory manager, and simply write the necessary allocators to ensure memory doesn't get too fragmented in the first place. About `memcpy`, the problem isn't that it's not idiomatic, but that it **doesn't work** for many types. – jalf Feb 11 '10 at 11:30
  • The task you have decided to go for is very very complex. Moving one object from one location to another in memory will require that any and all pointers and references to the moved object get updated to the new location, and that would have to be made in a thread safe way if you have more than one thread, which would imply freezing time for all threads while you relocate everything... and updating the pointers and references that are held in the stack (or stacks if multithreaded) You are talking about implementing almost a a complete moving garbage collector!! – David Rodríguez - dribeas Feb 11 '10 at 12:15
  • This is true. And it's absolutely worth pointing out these complexities. Luckily for me, all the objects I need to defragment lives in a very protected area of code, and they are all of the same class, allowing for a very intrusive approach. But yeah... obligatory warning: Don't write your own memory allocators or anything similar. – porgarmingduod Feb 11 '10 at 12:25
  • If you still want to go for it, note that reimplemeting STL container (at least the ones you use) to provide support for your move operations will help (at least you control the internals of your containers, know what attributes are present, what operations can be performed, can keep track of changes in iterators...). That will ease the implementation of the move for containers, but you will still be left with the problem of updating pointers/references everywhere. The cost of all these operations (in runtime) will be quite important. – David Rodríguez - dribeas Feb 11 '10 at 12:30

6 Answers6

4

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
  • 12,749
  • 1
  • 27
  • 35
  • 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. – porgarmingduod Feb 11 '10 at 12:05
  • 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 Feb 11 '10 at 12:21
  • @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 Feb 11 '10 at 12:37
  • 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 Feb 11 '10 at 12:58
2

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
  • 20,075
  • 11
  • 87
  • 171
2

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
  • 12,825
  • 5
  • 58
  • 90
  • 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 Feb 11 '10 at 11:35
  • 2
    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 Feb 11 '10 at 11:36
  • Yupp, actually, using placment new for containers, or any class containing pointers, are most often quite unnessesary. – Viktor Sehr Feb 11 '10 at 12:05
1

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
  • 8,023
  • 3
  • 32
  • 40
0

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.

Prof. Falken
  • 24,226
  • 19
  • 100
  • 173
0

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
  • 52,368
  • 9
  • 94
  • 137