| Message ID | xnvapjngr0.fsf@greed.delorie.com |
|---|---|
| State | New |
| Headers | show |
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. >
Siddhesh Poyarekar <siddhesh@gotplt.org> writes: >> Patch ok? (it's basically just s/reallocated/grown/) > > Yes. Thanks, pushed.
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.