This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: emacs and large-address awareness under recent snapshots

On 8/10/2011 7:47 AM, Corinna Vinschen wrote:
On Aug 9 22:33, Ken Brown wrote:
On 8/9/2011 2:21 PM, Ken Brown wrote:
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?

I guess so. Cygwin's malloc obviously uses Cygwin's heap or mmap to get memory. If it works, I don't see a reason to stick to emacs' own malloc implementation. Is emacs always using it's own malloc by default, or is it using it's own malloc only on certain platforms?

It uses its own malloc only on certain platforms. This is determined during configuration, and it's easy enough to tell it to use Cygwin's malloc.

Of course, Cygwin's malloc won't use bss_sbrk, so nothing that temacs loads into memory (which would be in the Cygwin heap) will get dumped. I wonder if there's a better way to do the dumping to get around this. Here's what happens currently:

temacs starts up and then loads a bunch of lisp files. Memory for this is allocated in the static heap by emacs's malloc, which uses bss_sbrk at this stage. Note that the static heap also contains the table that malloc uses to keep track of the memory it has allocated. temacs then writes a file emacs.exe, which starts out as a copy of temacs.exe but with the bss and data sections replaced by those of the running temacs. The bss section contains the static heap. Finally, temacs converts this new bss section in emacs.exe to an initialized data section. The bulk of the work for this is done by the function fixup_executable in unexcw.c.

Would it be possible to accomplish the same goal without using bss_sbrk and the static heap? In other words, can one save the information on the Cygwin heap as part of emacs.exe, so that when emacs is run the heap gets restored? I know virtually nothing about the structure of .exe files and how the loader works, so I have no idea whether that's feasible.

That might be a much better solution. We'd still have the issue of the heap sometimes starting at 0x20000000 and sometimes at 0x80000000, but that seems less important. At worst, we would just have to give up the possibility of using large address awareness for emacs. But I'm afraid that emacs will have memory problems in Cygwin 1.7.10 if we just leave things the way they are.[*]


[*] I've actually been running emacs with the 2011-08-03 snapshot (patched by your fix at the very beginning of this thread), and I haven't noticed any memory problems. But I feel like that's just luck, because I don't see how the code in gmalloc.c could possibly be doing the right thing when Cygwin's heap starts at 0x20000000. Maybe I'm missing something.

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]