Make xul.dll work better with high memory

[dryeo]

While the updated os2lib and os2safe.h helped with making Firefox 10.0.12's xul.dll work with high memory, it didn't with 24.8.1. Seems that xpcom/io/nsLocalfileOS2.cpp no longer includes os2safe.h before os2.h. Examining the symbols shows that it is using DosQueryDBCSEnv rather then SafeDosQueryDBCSEnv
Thanks to os4user for finding this problem, I fixed it with this,

diff --git a/xpcom/io/nsLocalFileOS2.h b/xpcom/io/nsLocalFileOS2.h
index 5f02de1..2087077 100644
--- a/xpcom/io/nsLocalFileOS2.h
+++ b/xpcom/io/nsLocalFileOS2.h
@@ -24,6 +24,8 @@
 #include "nsIHashable.h"
 #include "nsIClassInfoImpl.h"

+#include <os2safe.h>
+
 #define INCL_DOS
 #define INCL_DOSERRORS
 #define INCL_WINCOUNTRY

[wztest]

Is this also true for the latest beta3 build of Firefox 24.8.1?

[dryeo]

On 01/05/15 01:50 AM, wztest wrote:

Is this also true for the latest beta3 build of Firefox 24.8.1?

Yes.

[dmik]

Yes, I found exactly the same thing. Unfortunately, it happened some hours after the Beta 3 release so it will be fixed in the next beta (soon).

BTW, this is very inconvenient to care about individual files and function calls here. And since we don't have any way to make gcc automatically include os2safe.h whenever os2.h is included, the best we can do here is to do it ourselves (there are about 118 files in Mozilla using os2.h that need to be changed) and declare a rule that each file including os2.h must also include os2safe.h by default (unless it is absolutely necessary to not include it). I will do such a change and report here.

[ydario]

What about changing os2.h? we don't use the ibm toolkit, so we can modify headers. And such kind of change will be available to all apps built with gcc (in the rpm env).

[dmik]

Well, this is an option too. But the fun thing is that Knut has already fixed this properly by making sure os2safe.h is always included from within os2.h and os2emx.h unless NO_INCL_SAFE_HIMEM_WRAPPERS is defined. See http://trac.netlabs.org/libc/ticket/280, http://trac.netlabs.org/libc/changeset/3834, http://trac.netlabs.org/libc/changeset/3839, http://trac.netlabs.org/libc/changeset/3843. And these fixes are already in http://ftp.netlabs.org/pub/libc/GCC-3.3.5-csd6.zip.

So I will just rebuild Mozilla when libc 0.6.6 RPMs are out and the problem will go away.

[dryeo]

I've had good results running SeaMonkey and Thunderbird with xul.dll marked to load both code and data into high memory since rebuilding with libc066, especially compared to lib065 where SM wouldn't even run when xul.dll was marked with -b.
Do see a lot of shared memory leakage if flash is loaded.

[dmik]

I've rebuilt Firefox with the latest RPMs of gcc 4.9.2 and libc 0.6.6. The size of many DLLs has decreased by some dozen percent. In particular, XUL.DLL is now 47M instead of 55M before (i.e. 8M less which is surely not bad).

I also tried marking all DLLs for high mem (with highmem.exe -b). It starts and seems to work, no crashes. One strange thing I noticed though is that Qt 4 apps (e.g. kdiff3) don't want to run after I start highmem-enabled Firefox (a crash in REGISTRY.DLL 0001:0000dc0c). Also, very often an attempt to start anything else (like sh.exe) after this Firefox gives us the infamous LIBC Error: Couldn't register process in shared memory!. Have no idea what it is, needs some more observation).

Here are some statistics of the firefox.exe launch taken using Theseus4 -> Process -> Memory Utilization (no browsing, just let it fully start, take the metrics and then close, 2 tries each, sizes are in megabytes, roughly rounded):

arena \ ffox	beta 3	beta 4	beta 4 high
private mem	46	47	47
shared mem	73	67	18
total	121	115	66

As we may see, changing the compiler saves us about 5-6 megabytes of shared memory which is not bad I think.

What puzzles me though is why highmem-enabled Firefox uses less shared memory. Perhaps, this Theseus4 function gives you only low memory statistics, that would explain it. I need tot ry a different report.

[dmik]

Here is the memory footprint comparison based on the memory occupied and allocated by private objects and shared objects of the Firefox process (also, in megabytes):

type \ ffox	beta 3	beta 4	beta 4 high
private obj	122	113	112
shared obj	221	214	213

This shows that Beta 4 uses about 10 megabytes less than Beta 3 due to the compile switch. There is (expectedly) no difference between the normal Firefox and the highmem-enabled one.

These metrics don't show how high memory usage changes between Beta 3 and Beta 4 and (which is more important) between the normal Beta 4 version and its highmem-enabled counterpart. I couldn't find a pre-defined report for such purpose in Theseus. There is the Linear Usage by Process report where such kind of information could be perhaps derived from but it contains too much raw data and needs some post-processing in order to extract useful bits. If anybody knows a different way of get this information out of Theseus you are welcome to share it with me.

With this, I'm closing the issue as the main problem is solved now.

[dryeo]

On 02/20/15 11:49 AM, Dmitriy Kuminov wrote:

I also tried marking all DLLs for high mem (with highmem.exe -b). It
starts and seems to work, no crashes. One strange thing I noticed though
is that Qt 4 apps (e.g. kdiff3) don't want to run after I start
highmem-enabled Firefox (a crash in |REGISTRY.DLL 0001:0000dc0c|). Also,
very often an attempt to start anything else (like sh.exe) after this
Firefox gives us the infamous |LIBC Error: Couldn't register process in
shared memory!|. Have no idea what it is, needs some more observation).

I haven't had problems launching sh.exe or kdiff3 or qupzillia while
both SeaMonkey and Thunderbird are loaded high. Currently with both
running I have 282MBs of low shared available.
Flash can really drain shared memory which I guess is expected.
I did get a trap 0 yesterday when launching TB, crashed hard enough to
not finish writing the first line of the trap screen.
Dave

[dmik]

That's strange since I have it 100% reproducible here. Need investigation (when time permits).