Re: Delphi memory manager.

nobody_at_noplace.not
Date: 07/20/04


Date: Tue, 20 Jul 2004 09:09:01 -0400

On Mon, 19 Jul 2004 23:25:05 GMT, "Martin Harvey (Demon Account)"
<martin@_nospam_pergolesi.demon.co.uk> wrote:

>I reckon I can guess what it is. I bet the Delphi memory manager
>synchronises via something that internally is represented as a
>dispatcher object, whereas the other memory managers probably use
>interlocked operations, or a spinlock.

>From the header of Delphi's default memory manager (getmem.inc)...

>{ *********************************************************************** }
>{ }
>{ Delphi Runtime Library }
>{ }
>{ Copyright (c) 1996,2001 Borland Software Corporation }
>{ }
>{ *********************************************************************** }
>
>// Three layers:
>// - Address space administration
>// - Committed space administration
>// - Suballocator
>//
>// Helper module: administrating block descriptors
>//

It's just soaking up a whole lot of time doing stuff that windows heap
manager already does anyway.

Consider the case of deallocating a whole series of pointers...

Delphi comes in with it's memory manager, using virtual memory allocation
routines, frees the memory, launches into a cleanup operation, destroys is't
allocated blocks, updates the allocations database then notifies the
suballocator and helper module the memory is freed. Right behind this
windows does exactly the same thing in response to VirtualFree and
GlobalFree making everything happen at least twice.

Allocation is even more embarrassing since in order to use virtual allocate
you must first call global allocate to reserve space. Delphi adds a big
chunk of overhead into this by building virtual memory allocations within
the globally reserved chunk, then performing memory blocking to track the
sub-allocation... in essence duplicating window's heapalloc and heapfree
calls... then windows has to do it all over again when virtual and global
allocation calls are made.

In essence Borland is trying to second guess Windows native memory
management and it's not working out so well. It ends up being bloated and
slow, just like their SEH functions are (same programmer?).

Memory management at the language level can generally be reduced to a small
handful of calls:

        HeapCreate -- get a memory handle for your application
        HeapAlloc -- create variable space within your heap chunk
        HeapFree -- release memory back to the windows heap
        HeapReAlloc -- increase or decrease memory allocated to a variable
        HeapCompact -- housecleaning routine to consolidate gaps in memory
        HeapDestroy -- destroy memory handle and surrender memory to windows

These functions internally do everything Borland's Memory Manager does...
and leaves the overhead of blocking and deblocking etc. to windows. Nicely
enough, the Heap* calls will generate exceptions if problems occur.
If you call HeapCompact after each HeapFree call you end up with a fully
self maintaining memory system. ... and the memory management routines only
get called once.

-----
Laura



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: 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: Memory Management
    ... The program is a bunch of DLLs. ... I'm still using the CRT's malloc and free to allocate memory. ... If the application makes a memory allocation request, ... I have implemented a memory manager for some SDK I'm working on (a ...
    (microsoft.public.vc.language)
  • Re: Memory fragmentation
    ... - On single CPU machine the standard memory manager is absolutely adeguate ... compared to single CPU machine. ... b - If you have a single very CPU and memory bound process a third party ...
    (borland.public.delphi.non-technical)
  • Re: A Layered Kernel: Proposal
    ... > requests is rather trivial for a memory manager. ... >>there is one in the kernel, ...
    (Linux-Kernel)