delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2002/05/16/11:23:52

X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Date: Thu, 16 May 2002 18:22:00 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp-workers AT delorie DOT com
Message-Id: <1225-Thu16May2002182200+0300-eliz@is.elta.co.il>
X-Mailer: emacs 21.2.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <3CE3990C.308C92EC@yahoo.com> (message from CBFalconer on Thu, 16
May 2002 07:33:32 -0400)
Subject: Re: emacs under w2k
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1020516075834 DOT 13145D-100000 AT is> <3CE3990C DOT 308C92EC AT yahoo 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

> Date: Thu, 16 May 2002 07:33:32 -0400
> From: CBFalconer <cbfalconer AT yahoo DOT com>
> > 
> > Actually, the main problem is to be able to join many small free'd chunks
> > into larger chunks.  If you fail to do that, you'll hit the problem of
> > being unable to allocate memory for reading a file because the free pool
> > is fragmented.  Then you'll need to sbrk more from the OS.
> 
> nmalloc handles this.

Without any limitations?  How do you overcome the problem of joining
non-contiguous chunks?  (Sorry, I don't have time to read the code and
figure that out myself.)

> This nmalloc does not handle.  However the effect can occur with
> any malloc, by simply keeping a copy of a pointer and then
> reallocing that pointer.  nmalloc goes to some lengths to avoid
> changing the pointer under realloc, but it obviously must be
> allowed to occur.
> 
>       p = malloc(SIZE);
>       p1 = p;
>       if ((t = realloc(p, NEWSIZE))) p = t;
>       else reallocfailure();
>       /* p1 is not necessarily valid anymore */

Sure; but that's not what I meant.  What the Emacs allocator does is
something much more crazy: it relocates buffers that were not involved
in the call to malloc/realloc.  In the example above, imagine that
after the call to realloc, some other pointer, q, say, no longer
points to the same data it pointed before; that data was moved to
another address, and q now points to garbage, perhaps even garbage
that is on the free list.

No general-purpose malloc can do that without breaking lots of
programs.

> If you restrict the usage of pointers, as you can with a LISP,
> then such operations become quite reasonable.  You effectively
> insert an indirection level, via handles.

That's not what Emacs does.  A Lisp object in Emacs is just a C
pointer with some of its bits (which are unused by the underlying OS)
used as tag bits, to tell Emacs what kind of object is pointed to by
the pointer.  To access the object, you reset the tag bits, then cast
the rest to a pointer to the appropriate data type, and dereference.

> But that should not require replacing the system malloc, which would
> open the gates for misusage by calling almost any standard library
> function that uses malloc.

It sounds insane (I couldn't believe it myself when I read that code
the first time), but the fact is it works quite well, at least for a
program such as Emacs.  It does require some vigilance, though,
especially when porting Emacs to unusual systems (I once debugged an
obscure bug for a week, which happened in the DDJGPP port because our
`write' called malloc back then).

- Raw text -


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