Hi,<br><br>I checked on Linux and Windows, the memory after a massive allocation and a massive deallocation is really freed, so currently la raison d&#39;être of our internal allocator is gone (need to be checked on Mac Os X). About performance I don&#39;t know.<br>

<br>Currently there is a mix of system allocator (or jemalloc) and our internal allocator. I don&#39;t think it is optimal.<br><br>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.<br>

<br>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).<br><br>Thanks in advance<br><br><br><div class="gmail_quote">2012/3/27 Stephan Bergmann <span dir="ltr">&lt;<a href="mailto:sbergman@redhat.com" target="_blank">sbergman@redhat.com</a>&gt;</span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br></div>
As discussed offline, and for the record:  The original raison d&#39;ê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 <span class="il">not</span> remember).  As traditional malloc implementations only ever grow a process&#39;s heap and never shrink it again, this meant that an soffice process&#39;s memory requirements as seen by the OS could be excessively large, needlessly degrading overall system behaviour.<br>


<br>
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&#39; stock memory management facilities.<br>


<br>
I have <span class="il">no</span> 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 <span class="il">operator</span> new instances that in turn call rtl_allocateMemory).</blockquote>

</div><br><br clear="all"><br>-- <br>Arnaud Versini<br>