Pale Moon User Interface Freezes

[back2themoon]

Don't know if and how relevant this is, but I'm fairly confident that performing Process Lasso's SmartTrim function (with its non-default "Trim Working Sets" setting enabled) on Pale Moon, does shave off a lot of what RAM usage (it will go up soon again, of course) is being reported by the Task Manager and more importantly: it does seem to improve Pale Moon performance and responsiveness. This, on a very old 8-core machine (non-AVX) with 12GB of RAM (Windows 10).

SmartTrim is an intelligent memory management algorithm that can trim working sets on a per-process basis when thresholds are reached, and can also clear the system standby list (cache).

[jobbautista9]

Since disabling jemalloc in the build is discussed here, I have tested it too myself, and it does seem a bit more responsive. Not 100% sure if it's placebo though.

But it's certainly not as stable as having jemalloc on, as for some reason I can consistently cause my jemalloc-free build of Pale Moon to crash when I try to Inspect Element the "Next Post" link at the bottom of this article: https://www.infoterkiniviral.com/2024/0 ... state.html

VS2022 in a mach run --debug tells me that an exception is thrown at line 41 of xpcom/glue/nsISupportsUtils.h from platform code.

Code: Select all

Exception thrown: read access violation.
aObject->**** was 0xFFFFFFFFFFFFFFF7.

Relevant code snippet:

Code: Select all

// Making this a |inline| |template| allows |aExpr| to be evaluated only once,
// yet still denies you the ability to |AddRef()| an |nsCOMPtr|.
template<class T>
inline void
ns_if_addref(T aExpr)
{
  if (aExpr) {
    aExpr->AddRef(); // line 41
  }
}

Call stack:

Code: Select all

[Inline Frame] xul.dll!ns_if_addref(nsISupports *) Line 41
	at c:\palemoon\obj-x86_64-pc-mingw32\dist\include\nsISupportsUtils.h(41)
xul.dll!nsCOMArray_base::InsertObjectAt(nsISupports * aObject, int aIndex) Line 138
	at c:\palemoon\platform\xpcom\glue\nsCOMArray.cpp(138)
[Inline Frame] xul.dll!nsCOMArray_base::AppendObject(nsISupports *) Line 78
	at c:\palemoon\obj-x86_64-pc-mingw32\dist\include\nsCOMArray.h(78)
xul.dll!nsArrayBase::AppendElement(nsISupports * aElement, bool aWeak) Line 129
	at c:\palemoon\platform\xpcom\ds\nsArray.cpp(129)
xul.dll!inDOMUtils::GetCSSStyleRules(nsIDOMElement * aElement, const nsAString_internal & aPseudo, nsIArrayExtensions * * _retval) Line 256
	at c:\palemoon\platform\layout\inspector\inDOMUtils.cpp(256)
xul.dll!XPTC__InvokebyIndex() Line 99
	at c:\palemoon\platform\xpcom\reflect\xptcall\md\win32\xptcinvoke_asm_x86_64.asm(99)
[Inline Frame] xul.dll!CallMethodHelper::Invoke() Line 2060
	at c:\palemoon\platform\js\xpconnect\src\XPCWrappedNative.cpp(2060)
[Inline Frame] xul.dll!CallMethodHelper::Call() Line 1376
	at c:\palemoon\platform\js\xpconnect\src\XPCWrappedNative.cpp(1376)
xul.dll!XPCWrappedNative::CallMethod(XPCCallContext & ccx, XPCWrappedNative::CallMode mode) Line 1343
	at c:\palemoon\platform\js\xpconnect\src\XPCWrappedNative.cpp(1343)
xul.dll!XPC_WN_CallMethod(JSContext * cx, unsigned int argc, JS::Value * vp) Line 998
	at c:\palemoon\platform\js\xpconnect\src\XPCWrappedNativeJSOps.cpp(998)
[External Code]

about:buildconfig:

Build platform

Code: Select all

target
x86_64-pc-mingw32

Build tools

Code: Select all

Compiler 	Version 	Compiler flags
C:/MSVC2022/VC/Tools/MSVC/14.39.33519/bin/HostX64/x64/cl.EXE 	19.39.33523 	-TC -nologo -wd4752 -wd4091 -D_HAS_EXCEPTIONS=0 -W3 -Gy -Zc:inline -utf-8 -FS -Gw -wd4244 -wd4267 -we4553
C:/MSVC2022/VC/Tools/MSVC/14.39.33519/bin/HostX64/x64/cl.EXE -std:c++17 	19.39.33523 	-TP -nologo -wd5026 -wd5027 -Zc:sizedDealloc- -wd4752 -wd4091 -wd4577 -D_HAS_EXCEPTIONS=0 -W3 -Gy -Zc:inline -utf-8 -FS -Gw -wd4251 -wd4244 -wd4267 -wd4345 -wd4351 -wd4800 -wd4595 -we4553 -GR- -Zi -O2b1 -GTs -GS- -Qspectre -utf-8 -arch:AVX -favor:AMD64 -Oy

Configure options
'MOZILLABUILD=C:\mozilla-build3.4\' --host=x86_64-pc-mingw32 --target=x86_64-pc-mingw32 --enable-application=palemoon --with-external-source-dir=c:/palemoon --enable-update-channel=release MAKE=c:/mozilla-build3.4/bin/mozmake.EXE --disable-accessibility --enable-appcompat-guid --enable-av1 --enable-jxl --disable-gamepad --enable-official-branding '--enable-optimize=-O2b1 -GTs -GS- -Qspectre -utf-8 -arch:AVX -favor:AMD64' --disable-parental-controls --disable-precompiled-startupcache --enable-strip --disable-updater --disable-webrtc

I wonder if this disabling of jemalloc can help us find hidden memory read access violations like this.

[Enobarbous]

Solution: what about making gc.postFinish(), GCRuntime::postFinish() , that will once again check to empty its chunk pools ?!
Or call gc.nursery.disable() before calling gc.finish() ...
Or in GCRuntime::recycleChunk() in Allocator.cpp, when the GC was already "finished", then do not push such Chunk to emptyChunks pool but outright call UnmapPages on it...

I think the simplest solutions would be 2 or 3, or perhaps do both...

Since UXP#2251 now has some solution (speaking of which, I think it would be nice to release a beta version for wider testing), perhaps it's worth taking another look at the P_A_Semi research/proposal?

Upd. this was a stupid question