Re: pre-init / strings ...

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*;