Mail Archives: cygwin/2006/08/14/03:42:18
[Sorry, I forgot all the CCs]
On Aug 13 22:11, Eli Zaretskii wrote:
> > Date: Sun, 13 Aug 2006 11:23:16 +0200
> > From: Reini Urban <rurban AT x-ray DOT at>
> >
> > Corinna Vinschen schrieb:
> > ...
> > > Ok, back to mmap/munmap. Private anonymous mappings are implemented in
> > > Cygwin by calling VirtualAlloc/VirtualFree. However, due to
> > > restrictions in the Win32 API, VirtualFree is only called by munmap, as
> > > soon as *all* pages within a single mmap'ed area are free'ed by this or
> > > preceding calls to munmap.
> > >
> > > In other words, the mmap'ed memory will not be returned to the OS, if
> > > not the complete mmap'ed area is munmap'ed. Therefore I assume that the
> > > implementation in Lisp keeps bits of memory around which are not
> > > munmap'ed for some internal reason.
>
> 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.
> this portion of Corinna's message:
>
> > 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.
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.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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/
--
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 -