Mail Archives: cygwin/2011/08/10/11:28:37
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.[*]
Ken
[*] 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: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -