X-Spam-Check-By: sourceware.org
Date: Fri, 18 Aug 2006 14:40:59 +0300
Message-Id: <uy7tmi850.fsf@gnu.org>
From: Eli Zaretskii <eliz AT gnu DOT org>
To: cygwin AT cygwin DOT com
In-reply-to: <20060814065812.GA29807@calimero.vinschen.de> (message from 	Corinna Vinschen on Mon, 14 Aug 2006 08:58:12 +0200)
Subject: Re: reproducible cygwin memory problems
Reply-to: Eli Zaretskii <eliz AT gnu DOT org>
References: <BAY107-F22549D794C527187392FB2F8480 AT phx DOT gbl> <uoduqc8g9 DOT fsf AT gnu DOT org> <20060812165300 DOT GB19272 AT calimero DOT vinschen DOT de> <44DEEF84 DOT 803 AT x-ray DOT at> <ubqqofo1y DOT fsf AT gnu DOT org> <20060814065812 DOT GA29807 AT calimero DOT vinschen DOT de>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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
Note-from-DJ: This may be spam

> Date: Mon, 14 Aug 2006 08:58:12 +0200
> From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
> 
> > As far as I could tell from the OP's report about Emacs configuration
> > results, available here:
> > 
> >     http://www.deas.harvard.edu/climate/eli/emacs-debug/
> > 
> > Emacs he built does not use mmap.  Here's the relevant excerpt:
> > 
> >     Should Emacs use the GNU version of malloc?             yes
> >     Should Emacs use a relocating allocator for buffers?    yes
> >     Should Emacs use mmap(2) for buffer allocation?         no
> > 
> > So it looks like the above hypothesis about mmap is not relevant, and
> 
> You missed what I told about Doug Lea's malloc implementation.  It uses
> mmap for mappings > 256K.  It does not matter whether emacs is
> configured for using mmap or not.

Right.  Sorry.

> > > Cygwin uses the Doug Lea version of malloc/free.  The latest Cygwin
> > > versions uses the DEFAULT_MMAP_THRESHOLD of 256K, so mmap/munmap are
> > > used for mappings > 256K.  I assume that's the case here, since we're
> > > talking about images.  Otherwise, for mallocs < 256K, Cygwin is using
> > > sbrk and sbrk'ed memory is never returned to the OS.
> > 
> > seems to say that the fact that memory is not returned to the OS is a
> > known issue with Cygwin's malloc when sbrk is used.  Am I missing
> > something?
> 
> There is no known issue.  The heap is an area of reserved memory, which
> is on demand commited when sbrk is called.  If the heap is too small to
> fit the new allocation, more memory is reserved/commited.  When sbrk is
> called with negative value, memory is decommited, but it's not released.
> Maybe that's why the OP doesn't see a decrease in the memory footprint.
> However, this works as designed.

AFAIK, decommitting memory does decrease its memory footprint as shown
by the task manager.  The emulation of sbrk used by the native Windows
port of Emacs does the same as what you described: it calls
VirtualFree with MEM_DECOMMIT flag (see w32heap.c:sbrk), and I do see
decrease in memory footprint when a large buffer is killed.  So, at
least in theory, the Cygwin build of Emacs should exhibit the same
behavior.

> Sbrk resp. munmap are fairly basic operations.  I explained how they
> work or are supposed to work.  If they don't work for emacs/lisp, they
> don't work for hundreds of applications and it should be quite easy to
> come up with a simple testcase in C.  So far I didn't see one, and my
> local tests work as expected.

FWIW, I looked into the Emacs image-support code, and I don't see any
memory allocation when it loads and displays an image, except the
allocation that happens inside the external image libraries used for
image support (libtiff.dll, jpeg62.dll, etc.).  So what's been said
earlier in this thread -- that Emacs allocates memory for images, but
doesn't release all of it -- sounds less and less likely, especially
since Cygwin uses the same C code as any other Posix platform,
including GNU/Linux.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/