Re: [PATCH][RFC] Allow explicit shrinking of arena heaps using anenvironment variable

[Carlos O'Donell <carlos_odonell at mentor dot com>]

On 7/20/2012 6:55 AM, Siddhesh Poyarekar wrote:
> Hi,
> 
> The current arena-per-thread implementation maps a 64M map (on x86_64)
> and makes most of it PROT_NONE initially. When malloc requests need to
> be serviced from this map, contiguous portions are given read+write
> permissions. When memory at the end of the map is freed, madvise() is
> called on the consolidated region to notify the kernel that we don't
> want to use that part. For setuid programs, we go a step further and
> ensure that the consolidated region to be freed has no permissions, by
> calling mmap() on it with MAP_FIXED and PROT_NONE.

Why do we do this for setuid programs? It isn't immediately obvious
to me why it should matter.

> This patch extends this functionality for setuid programs to all
> programs through the use of an environment variable
> MALLOC_ARENA_SHRINK. There are two motivations for this:
> 
> 1. Make sure that the consolidated sections are unusable and hence
>    simulate the process heap much more closely, regardless of whether
>    the program is setuid or not.
> 2. One may want to look at memory maps in /proc/PID/maps and get an
>    estimate of how much of it is in use, similar to the main process
>    heap. The main process heap *actually* shrinks and hence it is easy
>    to see how much of it is in use, but for the arenas, there is
>    currently no way to guess this. Until now. The way to identify the
>    vmas that are acting as arenas is to collate /proc/PID/maps data with
>    the strace of the program.

It is my opinion that if we want to know about arenas then we should
write an API to expose their state to an in-process agent. Groking the
maps is bad design for exposing such information.

> The default behaviour remains as before -- this new behaviour is only
> seen when MALLOC_ARENA_SHRINK is exported and set to a positive value.

Why don't we enable this unconditionally?

What would be the problem in doing that?
 
Cheers,
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026