Mail Archives: djgpp-workers/2002/05/16/11:23:52
> 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 -