Re: Memory Management

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

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'


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.

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.

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).

-- Niki

"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@xxxxxxxxxxxxxxx>
wrote in message news:OpqdA61kGHA.4200@xxxxxxxxxxxxxxxxxxxxxxx
Klaus Hartmann wrote:
Hi everyone,

I have implemented a memory manager for some SDK I'm working on (a
game engine). The primary goal of this memory manager is to reduce
fragmentation, to perform fast allocation of small blocks of memory,
and to give more detailed information about memory leaks. This
manager works fine, and without problems.

Now, as you might have guessed already, my problems are the operators
new and delete. I wish to overload them in a *safe* way, such that
the memory manager is automatically used. I do not want to use
class-based new/delete operators. It also has to work properly with
other libraries, including the STL. I did overwrite the global
operators, and that woks, but it just doesn't feel safe.

I realize that there's a good chance, that you'll tell me, that
there's just no good and safe way to do what I want. But maybe I'm
wrong, and someone here's got this great idea :-) There's just got to
be some way to write a cusom memory manager.

IF you're using VC++ (which presumably you are, since you're posting
here), and IF your program is monolithic (not a collection of DLLs), then
you can simply provide your own definition of the malloc family of fine
functions and all C and C++ memory allocations will go through your code,
including new, new[], std::allocator, etc.

If you're building a program out of a bunch of DLLs, then it's a bit
harder, but there's still a reasonably clean solution: put your rmemory
manager in a DLL of it's own, supplying malloc (free, etc) and global
operator new/new[]/delete/delete[] as exports from your DLL. Link the
import library for your memory manager with the main executable and all
the other DLLs, making sure that the linker sees your import library
before the C/C++ runtime libraries.

-cd





.

Relevant Pages

  • Re: Symbol table
    ... First, for RosAsm, i was in need of a good Memory Manager, ... KJH -- this is the guy who has refused to fix a symbol table allocation ... or multiples of 64K) and then parcel out the memory chunks using ...
    (alt.lang.asm)
  • Re: Delphi memory manager.
    ... Delphi comes in with it's memory manager, using virtual memory allocation ... Allocation is even more embarrassing since in order to use virtual allocate ... These functions internally do everything Borland's Memory Manager does... ...
    (comp.lang.pascal.delphi.misc)
  • Re: Preventing memory fragmentation
    ... The c-runtime dynamic memory manager (and most other commercial memory ... Where can I find information on implementing and using buffer pools? ... > Is it this memory pool class you wrote that does your allocation? ...
    (comp.lang.cpp)
  • Re: Memory Manager
    ... > practically a thing of the past with a good memory manager. ... NexusMM3, to be released shortly after NexusDB2 (in which it will be ... allocation to a new memory location and without wasting address space by ...
    (borland.public.delphi.non-technical)
  • Re: Dlls,memory allocation
    ... quite a few dlls and execute. ... be no dynamic memory in the libraries.. ... In that case, the allocation /freeing will ...
    (comp.lang.c)