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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
