Re: Memory Management
- From: "Klaus Hartmann" <niki_hartmann@t-online_add_dot_de>
- Date: Mon, 19 Jun 2006 20:52:16 +0200
I managed to export the operators from a DLL using a .DEF file, but that
only works for debug builds. As soon as I'm making a release build, the
linker starts yelling about multiple definitions. It's not even warnings,
it's errors.
There's probably a way to trick the linker into actually compiling this, but
that feels very unsafe. This SDK will be used to make multiple products, so
I cannot really take that risk.
I've had a look at SmartHeap's technical specification. Wtihout perusing its
header files, they appear to be doing what has worked for me before, i.e.,
include the memory manager after any files that declare malloc etc. I'm not
sure I like that. For example, is it safe to assume, that any STL files
included prior to the memory manager will use my global operator
replacements? Ok, the STL provides allocators, so this is a bad example, but
there are other useful template libraries, and they tend to allocate and
free small blocks of memory like crazy. For me this is one of the top ten
reasons to use my own memory manager.
If you now say, that the include-last-approach is not safe either, then I
will ditch the entire idea.
Thank you very much for the time you've spent on this. I appreciate it a
lot.
-- Niki
"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@xxxxxxxxxxxxxxx>
wrote in message news:u7UngX7kGHA.4444@xxxxxxxxxxxxxxxxxxxxxxx
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
.
- References:
- Memory Management
- From: Klaus Hartmann
- Re: Memory Management
- From: Carl Daniel [VC++ MVP]
- Re: Memory Management
- From: Klaus Hartmann
- Re: Memory Management
- From: Carl Daniel [VC++ MVP]
- Memory Management
- Prev by Date: Re: 13 bit bitfield
- Next by Date: Re: Monitor a directory using WaitForMultipleObjects
- Previous by thread: Re: Memory Management
- Next by thread: Need mod operator as VB
- Index(es):
Relevant Pages
|
