Thread: Call destructor from memory manager

Hi

I'm writing a memory manager and I wonder if it possible to call the destructor of an object (assuming I know it has one) from the memory manager?
The memory manager allocates a big chunk of memory and then divide it into smaller pieces as it recieves requests for allocations. Each piece of allocated memory is preceeded by a header which containes some data.

Would appreciate some help here

Regards
Daniel

All objects have destructors. You should probably only be calling the destructor if you are using placement new, which you might be doing if you have a memory manager. See this FAQ (and the others on that page) for more information:

http://www.parashift.com/c++-faq-lit...html#faq-11.10

That was good reading but I'm afraid I didn't find what I was looking for (maybe I haven't been looking hard enough), and after reading my first post again I realized it was a bit... fuzzy. Here's is a better description of my problem.

I'm using a mark-sweep memory manager which, in the beginning of the program, allocates a big chunk of memory. I have then overloaded the new operator so that I can simply call the memory managers allocate method by writing:

Code:

Foo* foo = new Foo;

//I haven't got the code right here, but it looks something like:
void * operator new(size_t nBytes)
{
    return g_pMemMgr->alloc(nBytes);
}

The memory manager then finds a suitable block, splits it if necessary, and returns the memory address. When I no longer need to use this foo variable I just leave it right where it is. The memory manager then looks through the whole memory after pointers to the blocks of memory it has. If it doesn't find a pointer to a certain block it flags it as free. At that place I want the memory manager itself to call the proper destructor of a void* type memory piece. I have read this is possible but the author of the article didn't really say how, and my attempts at using google has failed utterly.

Thanks for your response though, it was very interesting reading!
After reading it I begin to wonder if even the contructors of my objects are called, got to check that.

The general description of your design is suggestive of a garbage collector, but it is widely recognized that such constructions are in opposition to some of the basic principles of C++ objects (the tightly coupled constructor/destructor cycle of objects).

What would happen, for example, if a destructor were called because the object so allocated were explicitly deleted?

Let me ask, then, what is the overall goal of implementing the custom allocator?

Is it speed?

Custom allocators are a well known practice in C++. Stroustrup indicated that performance gains can be an order of magnitude (there are times when performance gains of 10x are realized). The STL has provisions for supplying a custom allocator for certain container types (strings, for example).

Another purpose of custom allocation is to reduce fragmentation of the heap. By taking control of allocation (away from the general CRT allocator upon which new is based), one can organize allocations in a way that avoid some of the fragmentation issues that occasionally affect runtime limits. This particular problem is more noticeable in smaller systems (either older desktop/laptop machines or embedded systems). Typical modern desktop computers have enough RAM that usually the problems associated with fragmentation of the heap simply don't occur. Certainly there are exceptions.

I've written custom allocation engines myself, primarily to help with these two issues (performance more than fragmentation), but all of those solutions did not venture to violate the destructor cycle common to C++ practices.

So what is your purpose in delayed destruction? Why is your design goal motivated in this direction?

BTW, a destructor must be performed on a known type if the destructor function is to be called. Calling a destructor on a void type could never 'find' the correct destructor to call, so it's a dead end (if I understood that part of your inquiry).

I think 11.14 in that FAQ looks like an example of exactly what you're trying to do. Creating a pool allocation manager and overloading operator new and operator delete to use the pool of memory rather than the default memory management.

Whether its necessary or appropriate for your situation is another question, but that should be a good run-through of the major issues.

The purpose of this manager is to keep it automated, and avoid memory leaks. I have tried to write a "fast" manager before, but it ended up being 2x slower than new/delete. So this one isn't targeted at performance, and I don't really care about fragmentation.

The author of the article I mentioned explained it this way:

Originally Posted by Bill Blunden

To institute this type of functionality with my mark-sweep collector,
you might want to consider adding another field to the memory
block header.

This new field, which we’ll call TYPE, indicates if the memory block
is an object, and if it is, then it indexes an element in an array of
function pointers. These function pointers store the addresses of
destructor functions. This setup is displayed in Figure 5.12.

When a memory block is about to be reclaimed, the garbage collector
will check to see if the memory block represents an object. If
the memory block is an object, the collector will invoke the object’s
destructor before it reclaims the memory block’s storage.
Naturally, there are many more details to consider than I’ve mentioned,
such as setting up the table of function pointers and handling
nested objects that call different destructors. You will have to experiment
with a number of different approaches. Nevertheless, I hope
to have guided you in the right direction.

From this I found out that I might want to access the virtual function table, got to find out on how to do that.

Thanks for your replies, I'll try writing something up tomorrow and return with hopefully good news. After I've got that working I just need to rewrite this manager a few times

Regards
Daniel

Have you considered smart pointers instead?

Reference counted smart pointers provide the two primary goals you've indicated, with very little hassle - and the concept supports threaded work.