This is the mail archive of the
mailing list for the Cygwin project.
Re: emacs and large-address awareness under recent snapshots
On 8/9/2011 10:39 PM, Ryan Johnson wrote:
On 09/08/2011 10:33 PM, Ken Brown wrote:
I submitted a bug report and may or may not get a useful response.
While waiting, I'd like to keep trying to figure out what the right
fix is. Unless the dumping mechanism (unexec) is completely revamped,
we can't just ignore the static heap. Some of it has already been
allocated by temacs and has to be taken into account by the memory
management scheme. So when emacs starts up (as of 2011-07-21), the
heap is going to come in two pieces: the static heap in low memory and
the Cygwin-provided heap starting at 0x20000000 or 0x80000000. I
can't think of any easy way of dealing with this, short of drastically
rewriting malloc. Do you have any suggestions?
BTW, I don't necessarily have to use the malloc that comes with emacs.
I just verified that I can build emacs so that it uses Cygwin's
malloc. I haven't done any testing yet to make sure there are no
glitches, but I think it will be OK. Assuming this is the case, does
that simplify dealing with a heap that has two non-contiguous pieces?
Given that the static heap is only 12MB, with most of that arguably
occupied by stuff that isn't going away, what if we did "just ignore the
static heap" (mostly)? Anything freed from that regionjust gets dropped
on the floor and all new requests are served from the cygwin heap? I
assume temacs stays away from the dynamic heap, since otherwise the dump
would be corrupted.
I tried forcing malloc to reinitialize itself in emacs.c, and emacs
crashed almost immediately. A gdb backtrace showed that the memory got
corrupted as soon as realloc got called on objects that were originally
stored in the static heap. After reinitialization, malloc had no
knowledge of memory allocation in the static heap.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple