Mail Archives: cygwin/2006/08/12/12:53:12
On Aug 12 17:52, Eli Zaretskii wrote:
> It's possible that I'm wrong, of course. Let me state the facts and
> observations that led me to my conclusion:
>
> . The OP reported that the problem happens only with image files.
> When he edits text files, the Emacs memory footprint stays at a
> reasonable value.
>
> . After killing the image buffer, the OP invoked the Lisp function
> clear-image-cache, which is supposed to release any memory used by
> Emacs for storing images. There's no other Lisp memory that I can
> see in the sources that is used for images, and that could be left
> unreleased. To be sure, I'd like to ask emacs_user AT hotmail DOT com,
> who is the OP, to invoke "M-x garbage-collect RET" after
> clear-image-cache, and see if that changes anything.
>
> . The OP traced the Emacs code in clear-image-cache, and saw that
> the function in the image libraries that frees the image is indeed
> called.
>
> . Other Emacs builds, including the native Windows build and a
> GNU/Linux build, do not exhibit this behavior.
>
> Given these observations, and the fact that the Cygwin build of Emacs
> runs almost the same C and Lisp code as the GNU/Linux build, what
> other factors can be involved here?
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.
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.
Of course it's also possible that there's a bug in Cygwin related to the
way mmap/munmap is called. But I have so far no evidence for that and
simple mmap/munmap tests show that VirtualFree is called as soon as all
pages in a mmap'ed area have been munmap'ed. If somebody thinks there's
a bug in this implementation, please send a simple, self-contained
testcase in pure C source code, which allows to reproduce the problem.
Of course, patches are welcome, too :)
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/
- Raw text -