Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


On 05/18/2012 04:23 PM, Michael Stahl wrote:
checking "a massive allocation" doesn't really tell us all that much,
because allocators typically operate in 2 modes:
- for large objects, directly request zero-backed memory via mmap
- for small objects, maintain elaborate data structures to allocate
these from arenas or whatever

I had hoped to address this in the test code in my other post with 100,000 times allocating 10,000 bytes each. However, further inspection reveals that allocation is apparently brk-based there, so that it can only ever shrink memory back to the highest allocation that has not yet been freed. (That is, changing the second, deleting, loop in my test code to run short one item prevents any shrinkage.) Contrast that with the always-mmap approach of rtl/alloc.h, which allows for different shrinkage patterns. (Whether or not that is relevant in practice.)

Stephan

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.