X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.7 required=5.0	tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_NEUTRAL
X-Spam-Check-By: sourceware.org
Message-ID: <4E41EDE9.4040004@cornell.edu>
Date: Tue, 09 Aug 2011 22:33:13 -0400
From: Ken Brown <kbrown AT cornell DOT edu>
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: <4E40093D DOT 10107 AT cornell DOT edu> <20110808162556 DOT GM11601 AT calimero DOT vinschen DOT de> <87sjpbhij7 DOT fsf AT Rainer DOT invalid> <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>
In-Reply-To: <4E417AB6.5070306@cornell.edu>
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: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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/9/2011 2:21 PM, Ken Brown wrote:
> On 8/9/2011 11:21 AM, Corinna Vinschen wrote:
>> However, whatever you do, it will not really work.  Keep in mind that
>> the large address awareness only makes sense (and has any effect!) on
>> systems which provide a large address area.
>>
>> To me the bottom line here is, that emacs is doing the wrong thing.
>> There are a couple of assumptions how a system maintains memory, which
>> are just not valid on all systems.  The malloc initialization and the
>> assignment of the heapbase (the first call to sbrk(0)) should happen
>> in emacs every time it starts.
>
> That makes sense to me.  I thought that was what I was accomplishing
> (for Cygwin) by setting __malloc_initialized to 0 before dumping.  I'm
> not sure why it didn't work.  In any case, the fix shouldn't be Cygwin
> specific.  It's probably time to report this as an emacs bug.

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?

Ken

--
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