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" 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: <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 Precedence: bulk > Date: Thu, 16 May 2002 07:33:32 -0400 > From: CBFalconer > > > > 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).