Re: [patch/21411] tweak realloc/MREMAP comment

[Siddhesh Poyarekar <siddhesh at gotplt dot org>]

On Wednesday 03 May 2017 02:00 AM, DJ Delorie wrote:
> I think this subtle change makes the comment match the existing source
> better.  However, we never actually munmap pages when shrinking mmap'd
> chunks...  in theory, we could just use munmap() even if mremap is
> unavailable, yes?  (and even if we make that change, we would then add
> a *new* comment documenting that behavior, the old comment still
> wouldn't be corect).
> 
> IIRC, we don't try to map-copy-unmap such shrinking chunks because
> they tend to be very large, and would incur a large cost penalty for a
> rare case, where the kernel could just swap out the unneeded pages.
> 
> Patch ok?  (it's basically just s/reallocated/grown/)

Yes.

Siddhesh

> 
> diff --git a/malloc/malloc.c b/malloc/malloc.c
> index 068ffc1..aa45626 100644
> --- a/malloc/malloc.c
> +++ b/malloc/malloc.c
> @@ -514,9 +514,9 @@ void*  __libc_calloc(size_t, size_t);
>    REALLOC_ZERO_BYTES_FREES is set, realloc with a size argument of
>    zero (re)allocates a minimum-sized chunk.
>  
> -  Large chunks that were internally obtained via mmap will always
> -  be reallocated using malloc-copy-free sequences unless
> -  the system supports MREMAP (currently only linux).
> +  Large chunks that were internally obtained via mmap will always be
> +  grown using malloc-copy-free sequences unless the system supports
> +  MREMAP (currently only linux).
>  
>    The old unix realloc convention of allowing the last-free'd chunk
>    to be used as an argument to realloc is not supported.
>