[patch/21411] tweak realloc/MREMAP comment

[patch/21411] tweak realloc/MREMAP comment

[DJ Delorie]

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

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.

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

[Siddhesh Poyarekar]

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

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

[DJ Delorie]

Siddhesh Poyarekar <siddhesh@gotplt.org> writes:
>> Patch ok?  (it's basically just s/reallocated/grown/)
>
> Yes.

Thanks, pushed.