This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: reproducible cygwin memory problems


> Date: Sun, 13 Aug 2006 11:23:16 +0200
> From: Reini Urban <rurban@x-ray.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
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?

If I don't miss anything, it remains to be explained why the OP didn't
see problems with normal buffers.  Could the OP please try visiting
several large text files, then kill their buffers, invoke the
`garbage-collect' function ("M-x garbage-collect RET"), and see if the
memory footprint returns to its original value?

A few more tests come to mind:

  . Put a breakpoint in sbrk and in mmap, and find out which one is
    being called when normal text files and image files (both small
    and large) are visited.

  . Visit many small image files (smaller than 256K) and see whether
    the memory is being returned to the OS.

I'd like to ask the OP to try these and report the results.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]