operator new no longer routes through rtl_AllocMemory in libsalcpprt under gbuild link rules

[Michael Stahl]

On 18/05/12 15:38, Arnaud Versini wrote:
> Hi,
> 
> I checked on Linux and Windows, the memory after a massive allocation
> and a massive deallocation is really freed, so currently la raison
> d'être of our internal allocator is gone (need to be checked on Mac Os
> X). About performance I don't know.

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

in the case where a single object is backed by its own mmap it is
trivial for the allocator to unmap the memory on free, and i would
expect every system allocator to do that (even 10 years ago); the far
more interesting case is what happens when a large number of small
objects of different sizes get allocated: is the allocator smart enough
to release the memory when all, or a substantial number of them, are
freed again?

> Currently there is a mix of system allocator (or jemalloc) and our
> internal allocator. I don't think it is optimal.
> 
> I propose to delete all our allocation code and use small stubs for ABI
> compatibility until LibreOffice 4.0, and we can use the system allocator
> or jemalloc if there is performance issues, perhaps on Windows.
> 
> I ask you if I could see if it is a good idea to go on this way or not,
> and how (branch or trunk).

i don't think there is any pressing need to do this right now, but of
course you can experiment a bit, i'm also not happy that we maintain our
own allocator, but i'd like to wait for LO4 with actually doing a change.