delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/03/11/19:20:20

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019