From: "Tom Demmer" <DEMMER AT brain1 DOT lstm DOT ruhr-uni-bochum DOT de>
Organization:  Lehrstuhl Stroemungsmechanik, RUB
To: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>, djgpp-workers AT delorie DOT com
Date:          Wed, 12 Nov 1997 12:59:33 GMT-1
MIME-Version:  1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject:       Re: malloc()
Reply-to: Demmer AT lstm DOT ruhr-uni-bochum DOT de
Message-ID: <8BD792772F6@brain1.lstm.ruhr-uni-bochum.de>
Precedence: bulk

[...]
> 
> Criteria for a good allocator are, IMHO, AFAIK, IIRC:
> - It shouldn't waste memory (or rely on the DPMI host that it catches
> this)
> This includes the use of an excessive amount of adminstrative data for
> allocated blocks.
> - Memory fragmentation should be avoided (this is especially important
> for programs that run for a longer time like many interactive programs
> (and OSes), but I think also about 'make'). A general malloc
> implementation should meet these programs.
> - Blocks allocated at the same time, should be allocated 'close'
> together, although that rule is mutually exclusive with the previous on
> many occasions.

In DJGPP, what exactly does `close' mean? In terms of linear address 
space, or in terms of physical address?

> - The ability to return freed memory to the system (in case of djgpp I
> think this is next to impossible because of the linearity of the memory
> and the possibility by other functions than malloc to call brk/sbrk)

Doesn't that hold also for other OSes? IIRC, the DL version takes some 
precautions in case it is compiled for a Linux kernel. Anyway, I didn't 
notice any change when calling sbrk() with a negative argument, but maybe I'm 
not searching enough.


> - Exploiting platform specific benefits, like allocating on 32 byte
> addresses for PII machines or allocating on 16 byte addresses for
> Pentiums. The current implementation allocates on 4K page boundaries,
> and that's fine as long as it doesn't waste memory.
> 
> Non-criteria are:
> - The speed (except exponential increase)
> - The ability to fastly realloc memory (but it may be an advantage
> though)
> 

According to your criteria it would be a good idea to switch to Doug Lea 
version of malloc(), at least from what I found out so far.

For a way of evaluating the locality of allocations, any ideas are welcome.

Ciao
Tom

  ******************************************************************
  *  Thomas Demmer                     * Phone : +49 234 700 6434  *
  *  Universitaetsstr. 150             * Fax   : +49 234 709 4162  *
  *  Lehrstuhl fuer Stroemungsmechanik *                           *
  *  D-44780 Bochum                    *                           *
  ******************************************************************
  *  Email: demmer AT LStM DOT Ruhr-Uni-Bochum DOT De                         *
  *  WWW:   http://www.lstm.ruhr-uni-bochum.de/~demmer             *
  ******************************************************************

    The problem with computers is that they only do what we
    tell them to, but not what we want them to do.