mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: confusion about brk and mmap in expand_heap in malloc implementation
Date: Thu, 10 Sep 2015 16:58:17 -0400	[thread overview]
Message-ID: <20150910205817.GQ17773@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAAKbDrfwRxP_yQLapYdhQR1ubDhnZBo0ebCQk7e02L8A0HHDHw@mail.gmail.com>

On Thu, Sep 10, 2015 at 02:58:33PM -0400, Yuxin Ren wrote:
> Hi,
> 
> I found in the __expand_heap function used by malloc, if brk fails, it will
> use mmap to get a memory area.
> I think in this case, this area should be returned back to system via
> munmap.
> But in my test, when I free such area, I found it is still passed to
> madvise, not munmap.
> 
> How do we track if an area is expanded by brk or mmap?
> And when we free an area, how do we decide to use munmap or madvise?

I think you're starting from some mistaken assumptions. The managed
heap for small allocations (under a few hundred kb) is permanent for
the lifetime of the process once it's allocated, whether it comes from
brk or mmap. The only difference between the two approaches of
obtaining memory is that brk is faster and makes it possible to obtain
a contiguous range gradually rather than having to request large
amounts at a time to ensure contiguity.

Either way, what madvise does is free up the _physical_ memory backing
large contiguous free areas on the heap. No attempt is made to free
virtual address space (this would be a very bad idea; it could lead to
heavy fragmentation) or commit charge. I have some ideas for freeing
commit charge in the future, which may be desirable.

Rich


      reply	other threads:[~2015-09-10 20:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-10 18:58 Yuxin Ren
2015-09-10 20:58 ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150910205817.GQ17773@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).