Sender:	vheyndri AT rug DOT ac DOT be
Message-Id:	<34699F39.2F40@rug.ac.be>
Date:	Wed, 12 Nov 1997 13:21:13 +0100
From:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version:	1.0
To:	Demmer AT lstm DOT ruhr-uni-bochum DOT de
Cc:	djgpp-workers AT delorie DOT com
Subject:	Re: malloc()
References:	<8BD792772F6 AT brain1 DOT lstm DOT ruhr-uni-bochum DOT de>

Tom Demmer wrote:

> [...]
> > - 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 intention is of course to have structures that belong together on
the same or adjacent pages, because, normally, those structures are also
used together. This way the number ofpage swaps can be decreased. So, I
mean linear a.p. When it concerns physical addresses, I think that we
should solely rely on the processor (except for alignment).

> > - 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? 

For instance in segmented memory environments, no. When all pages in a
segment are freed the entire segment can be freed. In order to have the
same results *all* memory blocks should be in front of the memory heap.
I think you can easily assume this is never true.

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

Like I just said, Murphy says there's always a block at the end of the
heap.
 
> 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.

The reason that I'm not speaking in terms of DL's code is that I haven't
had a thorough look at it yet, but from what I have read about till now,
yes, I'm in favour of DL's. At least what I can say is that I have
strong objections against the current.

Ciao,

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/

- Raw text -