Re: Memory Management
Klaus Hartmann wrote:
Thanks for the reply Carl.
The program is a bunch of DLLs. Some are loaded at run-time, like
plug-in DLLs and 'driver' DLLs (e.g., to encapsulate DirectX), and
some are linked to at compile time.
I have tried to export the operators from a DLL, but I cannot get it
compiled without error C2375:
d:\Develop\Gryphon\Include\GryphonBase\GryphonBase_Memory.h(40): error
C2375: 'operator delete' : redefinition; different linkage
predefined C++ types (compiler internal)(21) : see declaration
of 'operator delete'
This is probably due to some header file that's already been seen by the
compiler that declares new/delete without the decoration. That may be hard
to get around other than by leaving the functions undecorated and using a
DEF file to get them exported from the DLL.
In the header file I do:
GRBASE_API void * operator new(size_t bufferSize);
GRBASE_API void operator delete(void * pBuffer);
In the cpp file I do:
GRBASE_API void * operator new(size_t bufferSize)
{
return IMemoryManager::Instance()->AlloacteMemory(bufferSize);
}
GRBASE_API void operator delete(void * pBuffer)
{
IMemoryManager::Instance()->FreeMemory(pBuffer);
}
the macro GRBASE_API is either __declspec(dllexport) or
__declspec(dllimport), depending on wheter I build the DLL or the
application. Also, I didn't care about the new[] and delete[], yet.
I have also tried a module definition file with some nice
name-mangling in the EXPORTS section. That compiled without problems,
but the application would call the operators from the CRT. I'm not
sure if I did this right, though.
That _should_ work, but you may have to fiddle with linker settings to make
sure that your version is preferred over the CRT version. You can use the
/verbose flag on the linker to see what it's doing. Generally, the linker
prefers whatever it finds first, so if you ensure that it finds your import
library before it finds the CRT, then it should choose your version of
new/delete.
Also, I'm getting the feeling that your explanation wants to tell me
something that I just don't see at the moment. Don't ask me what it
is, but there's something about the way you wrote that. So maybe I'm
on the wrong track here. Let me give you some more info, in case you
need it for further discussion.
Well, there are subtleties when you have a program broken into multiple
DLLs. Having your allocator in a DLL that all of the other DLLs link
against is about the only way to globally replace new/delete in such a
program.
I'm still using the CRT's malloc and free to allocate memory. What the
memory manager does is, that it allocates a dynamic amount of pages of
fixed-sized memory blocks. The pages themselves are allocated with
malloc, and the number of memory blocks in a page is currently
hard-coded to 16. There are multiple of those "fixed-sized memory
pools" for various "fixed sizes". If the application makes a memory
allocation request, then it first tests, if one of the "pools" can be
used, otherwise the manager falls back to normal malloc/free.
In addition to those fixed-sized pools (which make small memory
allocations roughly 18 times faster, and reduce fragmentation), the
manager also keeps debugging information (source file name, line
number, and size of the memory block).
OK, that's a conventional small-block allocator plus allocation tracking.
Make sure that you're using appropriate synchronization primitives to make
allocation/deallocation thread-safe. Some high performance heaps maintain
per-thread small block heaps to reduce the amount of synchronization code
that's required (which complicates de-allocation, since it's generally not
required that you free memory in the same thread that allocated it).
If you can't get your wrappers to work, you might look into "SmartHeap", a
commercial heap replacement that does just what you describe (and lots more)
and is already set up to just drop into VC++.
http://www.microquill.com/smartheap/index.html
-cd