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

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.

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).

Thanks in advance


2012/3/27 Stephan Bergmann <sbergman@redhat.com>

> As discussed offline, and for the record:  The original raison d'être for
> our home-grown memory allocation machinery, IIRC, was loading certain Calc
> documents, which temporarily required large amounts of heap memory that
> could be released again later on (either after loading was complete or when
> closing the specific document; I do not remember).  As traditional malloc
> implementations only ever grow a process's heap and never shrink it again,
> this meant that an soffice process's memory requirements as seen by the OS
> could be excessively large, needlessly degrading overall system behaviour.
>
> At least to me, it always felt kind of wrong to include memory management
> facilities in our code base. -- It increases maintenance cost and cuts us
> off advancements in the OSs' stock memory management facilities.
>
> I have no idea if there are still any scenarios where our home-grown
> memory management is beneficial, let alone if such scenarios would depend
> on our global new/delete handlers (i.e., if such scenarios obtain the
> relevant memory via stock C++ new, instead of directly via
> rtl_allocateMemory or explicitly defined operator new instances that in
> turn call rtl_allocateMemory).




-- 
Arnaud Versini