Re: Build with jemalloc
Thanks for you reply. On Sat, 31 Aug 2013 12:20:04 +0200 Michael Stahl 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? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Build with jemalloc
Does anyone tried to build LibreOffice with jemallc?
I tried to use LibreOffice on Windows environment, and it required too much
memory rather than Microsoft Office.
So I tryied to inspect memory usage with Microsoft Performance Analyzer.
http://msdn.microsoft.com/en-us/library/windows/desktop/hh448170.aspx
I can find many malloc/free and new/delete pair, so I suspect possibility of
heap memory fragmantation.
Then I tried to build with jemalloc, a famous memory allocator.
I modified desktop/Executable_soffice_bin.mk like the following:
$(eval $(call gb_Executable_add_ldflags,soffice_bin,\
/STACK:1000 \
/NODEFAULTLIB:msvcrt /NODEFAULTLIB:libcmt \
'c:\cygwin\libo\jemalloc\jemalloc_s.lib' \
'c:\cygwin\libo\jemalloc\libgcc.a' \
'C:\Program Files\Microsoft Visual Studio 11.0\VC\lib\msvcrt.lib' \
'C:\Program Files\Microsoft Visual Studio 11.0\VC\lib\libcmt.lib' \
))
(it’s a dirty hack)
So gbuild invoked the following command (a little bit long):
S=C:/cygwin/libo && O=C:/cygwin/opt/lo/build2/solver/wntmsci14.pro &&
W=C:/cygwin/opt/lo/build2/workdir/wntmsci14.pro &&
mkdir -p $W/LinkTarget/Executable/ &&
rm -f $W/LinkTarget/Executable/soffice_bin.exe &&
RESPONSEFILE=C:/cygwin/tmp/gbuild.ThJJlZ &&
unset INCLUDE &&
link -release -opt:noref -incremental:no -debug -nxcompat -dynamicbase
-manifest -SUBSYSTEM:WINDOWS,5.01-LIBPATH:$O/lib
-LIBPATH:C:/PROGRA~1/Java/JDK17~1.0_2/lib
-LIBPATH:C:/PROGRA~1/MICROS~1.0/VC/lib -LIBPATH:C:/PROGRA~1/WI3CF2~1/8.0/lib
-LIBPATH:C:/PROGRA~1/WI3CF2~1/8.0/lib/win8/um/x86
-LIBPATH:C:/PROGRA~1/MICROS~1.NET/SDK/v2.0//lib
-LIBPATH:C:/PROGRA~1/MI5E29~1/lib/x86/STACK:1000
/NODEFAULTLIB:msvcrt
/NODEFAULTLIB:libcmt
'c:\cygwin\libo\jemalloc\jemalloc_s.lib' 'c:\cygwin\libo\jemalloc\libgcc.a'
'C:\Program Files\Microsoft Visual Studio 11.0\VC\lib\msvcrt.lib'
'C:\Program Files\Microsoft Visual Studio 11.0\VC\lib\libcmt.lib'
@${RESPONSEFILE} isal.lib isofficeapp.lib iuwinapi.lib ooopathutils.lib
winextendloaderenv.lib advapi32.lib user32.lib
-out:$W/LinkTarget/Executable/soffice_bin.exe; RC=$?; rm ${RESPONSEFILE} &&
if [ -f $W/LinkTarget/Executable/soffice_bin.exe.manifest ]; then mt.exe
-nologo -manifest $W/LinkTarget/Executable/soffice_bin.exe.manifest
outputresource:$W/LinkTarget/Executable/soffice_bin.exe\;1 &&
touch -r $W/LinkTarget/Executable/soffice_bin.exe
W/LinkTarget/Executable/soffice_bin.exe.manifest; fi &&
if [ -f $S/solenv/inc/DeclareDPIAware.manifest ]; then
mt.exe -nologo -manifest $S/solenv/inc/DeclareDPIAware.manifest
-updateresource:$W/LinkTarget/Executable/soffice_bin.exe\;1 ;
fi ; exit $RC
I thknk it seems fine, but the output binary hadn’t have static jemalloc code.
Does anyone tried same thing?
Or how can I build LibreOffice with jemalloc static library?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
