operator new no longer routes through rtl_AllocMemory in libsalcpprt under gbuild link rules
sbergman at redhat.com
Tue Mar 27 05:40:11 PDT 2012
On 03/27/2012 12:58 PM, Caolán McNamara wrote:
> On Thu, 2012-03-22 at 14:24 +0100, Stephan Bergmann wrote:
>> I unfortunately lost track long ago which platforms we use our own
>> memory allocator on, which platforms we additionally use libsalcpprt on,
>> and what the rationale was for the exceptions.
> I'm now inclined to leave things as they are. Given that MacOSX and
> Windows didn't route operator new through the rtl_Alloc family it
> doesn't seem to make a massive pile of sense to me to have the Linux one
> do so on its own without an evidence-based reason to do so again.
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).
More information about the LibreOffice