Re: Build with jemalloc

Thanks for you reply.

On Sat, 31 Aug 2013 12:20:04 +0200
Michael Stahl <mstahl@redhat.com> wrote:

> although as far as i vaguely remember the really "bad" system memory
> allocators are in Windows XP and earlier; the Vista and newer allocators
> are said to be much better.

It is a interesting things. I tried to watch memory usage on XP and 7,
And the output is a little different.

> and i would suspect if LibreOffice requires more memory than MS Office
> it is most likely not because of the memory allocator but because of
> sub-optimal data structures in the application cores (plus some constant
> overhead because LibreOffice is portable and thus needs more platform
> abstraction layers).

From my inspection, VCL calls quite many malloc/free pair (in the face,
new() call of some objects). UI compornent on LibreOffice supported
many platform, so it woud be unavoidable.

> i don't know why this does not work for the specific case of
> soffice.bin, because i don't know what symbols are in the extra
> libraries you link.  perhaps there are different calling conventions in
> the jemalloc library and the soffice.bin objects or something like that,
> so it still picks up the allocator symbols from msvcrt.lib.

Thank you your comment. I tested building avery small program with jemalloc,
and it seems fine. So I check build related things again.

> this does not work on Windows because DLLs do not have a global symbol
> namespace, their namespace is local to each DLL.  and every DLL knows
> not only the name of an imported symbol, but also which other DLL it is
> imported from.  so i think what you would need to do to replace the
> memory allocator on Windows is to link _every_ DLL and executable
> against your custom allocator.

Actually, I also tried to modify another link commands, almost passed
the build but cli_maker was not.

> oh, and for quite a lot of classes in the code base a custom memory
> allocator is used anyway due to overloading operator new for the
> particular class, see include/tools/mempool.hxx and the underlying
> rtl_cache API in include/rtl/alloc.h.  this implements a SLAB like
> allocator which is used for the most-used classes and should be quite
> efficient and reduce the fragmentation considerably.

Sounds good. 

So I understand that LibreOffice supports jemalloc in many Unix-like
systems but Windows is not. And many classes are used internal memory
allocator on Unicos and Windows.
Is this right?