Mail Archives: cygwin/2006/08/18/07:41:20
> 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/
- Raw text -