Date: Wed, 10 May 2000 09:11:36 -0400
Message-Id: <200005101311.JAA30165@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
In-reply-to: <200005101217.IAA11786@indy.delorie.com> (message from Eli
	Zaretskii on Wed, 10 May 2000 08:17:12 -0400 (EDT))
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> <200005101217 DOT IAA11786 AT indy 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


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

The problem is that the memory you want to free is intermixed with
memory you don't want to free.  If you use a mmap'd region elsewhere,
you can release the whole region at once without messing up your usual
heap.

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

mmap'd regions are placed far away from each other, say one every
256MB, with big unmapped gaps between them.  That leaves plenty of
room for growth, by simply mapping more pages adjacent to them.