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

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

Stephan