Date: Wed, 10 May 2000 08:17:12 -0400 (EDT)
Message-Id: <200005101217.IAA11786@indy.delorie.com>
From: Eli Zaretskii <eliz AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
In-reply-to: <200005091956.PAA28210@envy.delorie.com> (message from DJ Delorie
	on Tue, 9 May 2000 15:56:59 -0400)
Subject: Re: Perfomance of gc-simple
References: <200005091512 DOT LAA22852 AT qnx DOT com> <200005091906 DOT PAA10862 AT indy DOT delorie DOT com> <200005091956 DOT PAA28210 AT envy DOT delorie DOT com>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Tue, 9 May 2000 15:56:59 -0400
> From: DJ Delorie <dj AT delorie DOT com>
> 
> > Yes, but why use mmap for that?  Why not use sbrk?
> 
> When you're done with the mmap'd memory, you can unmap it and release
> it to the system.  With sbrk you can only return it to your local
> heap

Doesn't sbrk return memory to the system when called with a negative
argument, at least on some systems?  (Ours doesn't, but this is
obviously not a problem for DJGPP anyway.)

> Plus, individual mmap'd regions can be grown as needed.

How would this be implemented, typically?  Growing a memory region
should need to relocate it, at least sometimes, no?  It sounds a lot
like realloc, unless I'm missing something.