X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_NEUTRAL X-Spam-Check-By: sourceware.org Message-ID: <4E42A381.3080806@cornell.edu> Date: Wed, 10 Aug 2011 11:28:01 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: emacs and large-address awareness under recent snapshots References: <4E404424 DOT 9000600 AT cornell DOT edu> <4E40526C DOT 9080605 AT cornell DOT edu> <4E406C21 DOT 7010007 AT cs DOT umass DOT edu> <20110809082652 DOT GA9492 AT calimero DOT vinschen DOT de> <4E4117AF DOT 3030305 AT cornell DOT edu> <4E414054 DOT 6040206 AT cornell DOT edu> <4E4142F7 DOT 8020708 AT cornell DOT edu> <20110809152155 DOT GB17030 AT calimero DOT vinschen DOT de> <4E417AB6 DOT 5070306 AT cornell DOT edu> <4E41EDE9 DOT 4040004 AT cornell DOT edu> <20110810114716 DOT GA23977 AT calimero DOT vinschen DOT de> In-Reply-To: <20110810114716.GA23977@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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