On 12/07/2017 10:53 PM, Michael Meeks wrote:
The basic problem is this - LOOL pre-initializes LibreOffice before
forking to ensure that lots of the memory is shared copy-on-write between it
and the child processes. That works reasonably well, but unfortunately - when
we re-use strings from that corpus - we tend to touch the ref-counts, which
causes lots of page dirtying.
If the issue is mostly with rtl_uString that originated from
(implicitly) converting a string literal in the source code into an
rtl::OUString instance (rather than rtl::OUString instances that have
actually been computed from other values during the pre-initialization
phase, and survive past that phase):
I think that with
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0424r2.pdf>
"String literals as non-type template parameters" potentially making it
into C++20 (and potentially being available in Clang or GCC even before;
it already is, in a form almost usable for our needs), we will be able
to create such rtl_uString from string literals in the source code
during compilation, placing them into read-only data segments.
So, it would be interesting to know whether the issue indeed is mostly
with such rtl_uString instances, so that the mechanism I outlined above
would be going to sufficiently solve your issue.
[...]
diff --git a/sal/util/sal.map b/sal/util/sal.map
index 579119065121..1dffaf8bc787 100644
--- a/sal/util/sal.map
+++ b/sal/util/sal.map
@@ -740,6 +740,11 @@ PRIVATE_1.4 { # LibreOffice 6.0
_ZN3sal19backtrace_to_stringEPNS_14BacktraceStateE;
} PRIVATE_1.3;
+PRIVATE_1.3 { # LibreOffice 6.1
this would need to be PRIVATE_1.5 (we're already at PRIVATE_1.4 for
LibreOffice 6.0)
+ global:
+ rtl_alloc_preInit;
+} PRIVATE_1.2;
+
PRIVATE_textenc.1 { # LibreOffice 3.6
global:
_ZN3sal6detail7textenc20convertCharToUnicode*;
_______________________________________________
LibreOffice mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
