[Libreoffice] --with-alloc setting

[Michael Meeks]

On Fri, 2011-10-07 at 09:10 +0200, Stephan Bergmann wrote:
> The main reason, IIRC, for inventing the internal malloc replacement was 
> that it sometimes happens that OOo needs large amounts of heap for a 
> rather short time (while loading calc documents, I think)

	:-)

>  and traditional malloc implementations never give pages that have
> become free again back to the OS.  No idea whether that is still
> a realistic issue today, though.

	When mhu was talking it through, back in the day, it seemed the major
thrust of his custom allocator re-write was to fix the horrendous
scalability problems of the previous custom allocator ;-)

	At that time, it seemed the system allocator performed better from
every given direction. Having said that - using a slab allocator is
clearly a good idea that should actually improve space efficiency, and
perhaps allow page release too - though whether our current slab
allocator uses best practise: thread-local storage, per-thread
magazines, etc. I havn't looked at recently.

	Instrumenting the only relevant munmap I can see in sal/ thus:

--- a/sal/rtl/source/alloc_arena.c
+++ b/sal/rtl/source/alloc_arena.c
@@ -1233,6 +1233,7 @@ SAL_CALL rtl_machdep_free (
     pArena->m_stats.m_mem_total -= nSize;
     pArena->m_stats.m_mem_alloc -= nSize;
 
+    fprintf( stderr, "actually freed a block !\n" );
 #if defined(SAL_UNX)
     (void) munmap(pAddr, nSize);
 #elif defined(SAL_W32)

	And loading, and even closing a few documents with G_SLICE unset - I
see not a single instance of this message; but perhaps I screwed up the
quick measurement ;-)

	My suspicion is, that the generic custom allocator ie. not the slab
stuff (backing rtl_allocateMemory) is worthless or a performance hit,
particularly on Linux. It'd be great to validate that of course :-)

	HTH,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot