Hi Baden,
On 07/02/20 11:27 AM,
baden.kudrenecky@gmail.com wrote:
Hi Dave:
Thanks so much for your detailed response.
As you probably know a lot about large application (Mozilla) compilation, I have a few more questions, that were probably never covered in a Red Book:
1) IIRC, the shared memory pool is 384 MB, and this has always been an OS constraint. With 'Mozilla', how much of that shared memory is used? I still have occasional problems, where I need to close programs.
Actually with Warp server and Warp 4.5+, there is also the high shared
memory arena, which varies on how VIRTUALADDRESSLIMIT is set. Currently, testing some new builds and having forgot to set the DLLs to load in
high memory, I currently have this,
H:\tmp>mem /v
Total physical memory: 12,169 MB
Accessible to system: 3,241 MB
Additional (PAE) memory: 8,928 MB
Resident memory: 166 MB
Available virtual memory: 3,111 MB
Available process memory:
Private low memory: 140 MB
Private high memory: 1,792 MB
Shared low memory: 39 MB
Shared high memory: 1,303 MB
This is going to soon crash due to running out of low shared memory :)
2) While I often see 500 MB memory allocated (200 to start) while using Mozilla, occasionally it uses 1.5 GB or more. However, Mozilla seems unstable and often abends when addressing too much memory. Is that expected as an application or OS issue, or
might it be unique.
There's a few things happening. The Mozilla apps by default will try to allocate memory in the high arena first, which is why it can allocate
1.5 GBs. There is also where the actual DLLs are loaded. By default in
low shared memory, a precious resource. They can be marked to load into
high memory, both code and data, best to only load the code high, eg
"highmem -c xul.dll" which helps a lot. Then we run into a kernel bug
where the memory is not released when unloading the DLL. Easy to see
with Theseus. Workaround is to use one of the mozturbo programs to keep
the DLLs loaded. This has made my system stable enough to have weeks of
uptime while repeatably loading, unloading and reloading all 3 Mozilla
apps. Once again it is important to have VIRTUALADDRESSLIMIT set to a
high value, at least 2560, if not 3072. Some hardware doesn't like 3072,
things like video cards using a lot of memory. AOS has way too low of a
default causing lots of crashes in the Mozilla apps.
Then there is the crappy coding that Mozilla has, things like using
objects before creating them. On all platforms OOM (out of memory
crashes) are the most common crash on 32 bit systems.
I've been experimenting with the new GCC 9.2.0. It shows a lot of
programming errors on Mozilla's part as it is not as forgiving and took
quite a bit if work to make it stable.
3) Maybe related to (2), I am wondering how thread management performs on the gcc ports. Should it be similar to native applications? The reason I am asking, is that often I have to use Ctrl-Esc/Watchcat to kill SeaMonkey if a tab hangs. Is the
threading written into the application source code?
The threading is the same as native apps. Mostly written into the native
app, though Bitwise often used pthreads, which is mapped to native
threads. Your hangs are likely memory related, though Mozilla doesn't
use threading that much.
thanks for your help!
Baden
In summary, have a high VIRTUALADDRESSLIMIT, mark the DLLs to load code
high, use the mozturbo programs to keep the DLLs loaded in high memory
and the Mozilla apps are quite stable. There's still JavaScript
problems/bugs, I run NoScript. uBlock Origin to block ads and a hosts
file to route ads into NUL: Ads are a resource hog and a security risk.
Dave
ps I'm using
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts ,
recommended, route those ads to 0.0.0.0 before they make it to the browser.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)