Sender:	nate AT cartsys DOT com
Message-ID:	<36E581E0.972D4E5C@cartsys.com>
Date:	Tue, 09 Mar 1999 12:17:36 -0800
From:	Nate Eldredge <nate AT cartsys DOT com>
X-Mailer:	Mozilla 4.08 [en] (X11; I; Linux 2.2.1 i586)
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: Bash 2.03 updated
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 990309120039 DOT 7248I-100000 AT is>
Reply-To:	djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> 
> On Mon, 8 Mar 1999, Mark E. wrote:
> 
> > 1) Use of GNU malloc provided by Bash.
> 
> That figures.  It's not that gmalloc is slower (I don't know if it is,
> but I doubt it's significantly slower).  The problem probably is just
> what it looked to me: gmalloc is a relocating allocator, meaning that
> it sometimes decides to relocate large buffers behind the scenes, if
> it is going to run out of memory.  In other words, before it calls
> sbrk, it tries very hard to reuse memory it already owns.  And this
> relocation takes time, since it's a kind of garbage collection.

??? How can that ever work?  Once `malloc' returns a pointer, it can't
change it-- you're expected to be able to alias the pointer all over the
place, and malloc can never find and fix them all.

I know GNU has a relocating allocator scheme, but it uses indirect
pointers-- you pass a `char **' and it updates the pointer as needed. 
It's different and incompatible.
-- 

Nate Eldredge
nate AT cartsys DOT com

- Raw text -