This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
- To: drepper at redhat dot com
- Subject: [PATCH] Correction for new malloc behaviour
- From: wg at malloc dot de
- Date: 21 Jul 2000 17:28:21 -0000
- Cc: wg at malloc dot de
[My usual internet connection is failing today and over the weekend, please forward to libc-hacker if that's OK] Hello, Here is the promised patch for malloc, such that mmap() isn't used excessively when it's not really necessary. With this, it should be possible to run an application with `ulimit -d <small value>' (simulating `running out of addres space'), and not pay the mmap() overhead for small chunks. Please test. Regards, Wolfram. 2000-07-21 Wolfram Gloger <wg@malloc.de> * malloc/malloc.c (chunk_alloc): Try mmap_chunk() for smaller allocations only if a non-main arena cannot be extended. --- malloc.c 2000/07/17 11:33:40 1.1.1.18 +++ malloc.c 2000/07/21 17:10:26 @@ -2938,9 +2938,12 @@ if ((remainder_size = chunksize(top(ar_ptr)) - nb) < (long)MINSIZE) { #if HAVE_MMAP - /* A last attempt: when we are out of address space in the arena, - try mmap anyway, as long as it is allowed at all. */ - if (n_mmaps_max > 0 && (victim = mmap_chunk(nb)) != 0) + /* A last attempt: when we are out of address space in a + non-main arena, try mmap anyway, as long as it is allowed at + all. */ + if (ar_ptr != &main_arena && + n_mmaps_max > 0 && + (victim = mmap_chunk(nb)) != 0) return victim; #endif return 0; /* propagate failure */
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |