Mail Archives: djgpp-workers/1999/03/12/03:25:07
On Tue, 9 Mar 1999, Nate Eldredge wrote:
> ??? 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.
Nevertheless, that's exactly what happens in Emacs. The application code
is supposed to protect itself against the relocation, either by verifying
that no pointers in danger of being relocated are being passed to
functions, or by explicitly blocking the relocation while some code runs,
and then unblocking it again.
The problem, of course, is that Emacs code has been adapted during the
years to the several flavors of Unix libraries, and it avoids calling
dangerous (in the above sense) functions at strategic places. But
DJGPP v2 library is an entirely different beast, and that was why the
first version of v2-compiled Emacs took such a long time to become
stable. (The dumping process was the other major piece of the puzzle.)
I think you can also have control on what is the minimum size of a block
that can be relocated (it only happens for large blocks), as well as turn
it off altogether.
The rationale behind this relocation is that a program such as Emacs which
allocates and frees memory all the time, both for small Lisp objects like
strings and arrays, and for large objects like buffers, must have a
relocatable allocator or else it will run into memory fragmentation
which promptly leads to wild paging. Remember that in windowed
environments Emacs gets started once and left running for days or weeks
on end.
> I know GNU has a relocating allocator scheme, but it uses indirect
> pointers-- you pass a `char **' and it updates the pointer as needed.
Relocating indirect pointers is also a trouble, because an application
might use them to change a simple pointer.
- Raw text -