Message-ID: <4E41EF48.1030503@cs.utoronto.ca>
Date: Tue, 09 Aug 2011 22:39:04 -0400
From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: emacs and large-address awareness under recent snapshots
References: <4E40093D.10107@cornell.edu> <20110808162556.GM11601@calimero.vinschen.de> <87sjpbhij7.fsf@Rainer.invalid> <4E404424.9000600@cornell.edu> <4E40526C.9080605@cornell.edu> <4E406C21.7010007@cs.umass.edu> <20110809082652.GA9492@calimero.vinschen.de> <4E4117AF.3030305@cornell.edu> <4E414054.6040206@cornell.edu> <4E4142F7.8020708@cornell.edu> <20110809152155.GB17030@calimero.vinschen.de> <4E417AB6.5070306@cornell.edu> <4E41EDE9.4040004@cornell.edu>
In-Reply-To: <4E41EDE9.4040004@cornell.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On 09/08/2011 10:33 PM, Ken Brown wrote:
> 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?
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.

Ryan


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