Pale Moon User Interface Freezes

[athenian200]

I just turned off jemalloc in .mozconfig (ac_add_options --disable-jemalloc). I don't want to use PA Semi's dll.

Well, yeah, you always have to be careful about using strange DLL files. But still, I was actually considering doing that experiment you did with --disable-jemalloc, since I've never tried it before and wanted to see if doing that changed performance at all. Your results seem to confirm a theory I had... that some of our problems in JS may actually come from poor memory stack management, and not actually problems with core functionality of the engine itself. I wasn't expecting just disabling it and using the system allocator to speed anything up, but since it did, it confirms that there may be value in replacing or updating jemalloc with something more reliable after all. There are various weird situations we've had that have made me think whatever was managing our stack was not very smart, though I couldn't put my finger on where the mismanagement was or what was causing it.

It's not a part of the code we like to touch very much, since we aren't experts on memory management, but the fact is it always did kind of worry me that we are building on a foundation of inherited low-level code we don't really know much about and rarely work with, and always wondered how many bizarre or inexplicable issues we deal with are coming from those parts of the code we are a little afraid to touch because they are outside our area of competence and seem to work well enough most of the time. It's the downside to having such a small team and such a huge codebase designed to be worked on by basically an army of coders...

[__Sandra__]

Well, yeah, you always have to be careful about using strange DLL files.

I checked the work PA Semi's dll in a safe environment. The result is similar to turning off jemalloc, only the PM crash was observed with a large memory consumption. He describes his patch as a replacement of calls jemalloc with system ones, so probably the result is similar.

Did you manage to reproduce the loss of windows by my example?

[Moonchild]

We've tested system malloc vs jemalloc before and at the time concluded it was better to use jemalloc (with some minor adjustments like actually using multi-core features to handle arenas). I'm somewhat versed in how it works but it's not something we really touch since it Just Works™.
Of course it's very well possible that the efficiency and stability of system allocators have now surpassed what jemalloc can do (at the time we were also still targeting NT5 which was probably a big part of it) and we should re-evaluate its use.

[__Sandra__]

We've tested system malloc vs jemalloc before and at the time concluded it was better to use jemalloc

And what about the lost (ghost) windows? Is reproduced on another system?

[Moonchild]

The ghost windows are unrelated to which allocator is in use.

[__Sandra__]

The ghost windows are unrelated to which allocator is in use.

Yes, I understand that. Just the topic about the freezes of the interface and my situation with the opening and closing of tabs with that site gives these friezes. If this is reproduced by others, it will be easier to debug.

[Moonchild]

I have an idea to try to deal with ghost windows, but it's rather tricky. We have some debug code that allows us to unlink windows in a not-so-safe way, and we might be able to use that to force the cycle collector to clean it all up. Some research and testing is needed, but I'd be fine with potential undefined behaviour if it cleans up the ghost windows from memory.
This is, however, part of the memory reporter code and I'm not sure if that can be used when jemalloc isn't is use (part of our jemalloc code is explicitly to be able to report memory use to the application). So it's a bit of a rock and a hard place if that's the case.

EDIT: Well whaddayaknow, seems like FranklindDM had the same idea to investigate risky unlinking XD I noticed patches to that effect in his dev branch just now.

[P_A_Semi]

I now published MozMem_18.zip, which corrects the bug I wrote earlier, that some sites were crashing...

(Since jemalloc.c has swapped arguments of aligned_alloc_impl, which I used as a template for my function, which are swapped at end of mozmemory_wrap.c ...)

Now it seems stable...
It is probably the last release, as I see no interest in it, and instead I identified the actual problem elsewhere...

Honestly if this is a better replacement for the system memory allocator handling, then you may actually find it working better (more stable) by disabling jemalloc in mozconfig, and therefore not mixing 2 allocators, making all malloc calls use the system memory allocator. That does require a rebuild, though.

There are GC chunks, jemalloc heap, then some dlls are using api-*crt-heap*.dll forwarding to ucrtbase.dll heap (which I intercept also), then there are dlls, including system ones, that use msvcrt.dll with another heap (that I started to intercept and unify into my single heap also since v16), and then there are about 20 different heaps acquired by HeapCreate() or GetProcessHeap(), which I do not plan to intercept and unify into the common heap...

Then I made a graphic representation of memory usage, see attachment...

Pmx_PM_Mem_240309a2.png

On the attachment, there is 2Gb address space, every pixel is 4kb page, 1Mb row width, 2048 px height... There are four examples...
The colors are: red executable code (dlls), gray reserved blocks, brown is unidentified, green is heap, either jemalloc or MmHeap (slightly different color), purple are system HeapAlloc, and blue are GC chunks... In those, light blue are pages completely zero...

Of the four columns: first is Palemoon soon after restart, the one in which I write this... The second column is using jemalloc... Third is using MmHeap... Notice a lot of light-blue (zero-filled) GC chunks with just first 16 pages (arenas) non-zero... Fourth is Palemoon with that problem fixed, now it endured 4x more browsing before thus completely filling space...

Using that I identified there are a lot of GC chunks, which have only cca 50kb of data, all else 00 null bytes, completely empty, with RelocationOverlay 0xbad0bad1 cells pointing "nowhere" (in released memory, in heap blocks in middle of strings, etc...), with JSRuntime at the end pointing to deallocated memory or released memory... I call them "abandoned" GC chunks, they are really signicifant leaks, and it's safe to release them...

Originally it seemed jemalloc is causing the "swelling", but instead it was releasing earlier pages, which were occupied by abandoned GC chunks, and the jemalloc was "swelling" on newer and newer addresses because of that...

----------------------------------------------------------------------

In MozMem_18.zip there is now MozGcGc.dll - "garbage collector of garbage collector", that if it is loaded into Palemoon, it periodically releases the leaked (abandoned) GC chunks...
I checked it also with Palemoon 33 now on download and there is still this same problem, and it works also there...

MozGcGc.dll can be used independently of my MozMem allocator, it also works with original jemalloc heap, it is only 32-bit... It cycles, waits in 15 second sleep(), then sifts address space using VirtualQuery, identifies "abandoned" GC chunks, which are completely deallocated, their JSRuntime does not point to a valid JSRuntime (it was already deallocated). If it finds some, it marks it, waits another 15 seconds, and if it is still there and still empty, it is released...

Example empty abandoned chunk trailer, with the freé mark by MozGcGc.dll in place of padding... (If you use my TaskView to view process memory, if it is black&white, press Ctrl+H or use Options/Highlight to switch on coloring, it looks much better...)

Clpx267902_crop.png

On the following example, there is end of one "abandoned" Chunk, its JSRuntime points to all zero bytes, and there is visible start of another abandoned (relocated and leaked) Chunk:

Clpx267474_crop.png

The MozGcgc.dll checks all bytes from 0xfffa0 thus, beside the free-mark, and the JSRuntime is checked that it has pointer to itself at offset +0x10... If it doesn't identify any valid JSRuntime, then the detection is incompatible and it doesn't release anything... Only if it identifies some valid, then the invalid ones with completely deallocated bitmap are thus released...
That Palemoon is stable afterwards is a proof they were abandoned leaks and program makes no reference to them ever...
(When I catch it with DumpBlocks.script, such Chunk is on a place where was not a Chunk 10 minutes earlier, and also its JSRuntime is already released, it has to be something temporary used during webpage load, on which relocateArenas runs and soon the JSRuntime is destroyed...)

Over last 24 hours, it released 187 Mb memory, and it consumed 4 and half minutes CPU time total, making it second most "expensive" background thread... (4 minutes per day is not a problem...)
On another host I tested it, there were over 360 Mb of abandoned GC chunks...
(It depends, how much web-pages you open, each leaks this 1 Mb GC chunk, beside some minor leaks...)

If you want to just see the blocks, there is also Tools\DropAbandon.script (for Eval.exe), that is only for Palemoon 32, 32-bit, not compatible with Palemoon 33, that can list the blocks, or also drop them...

(Or with the released MozGcGc.dll, if you edit bytes at file offset 0x645 reading 89 F8 E8 7D 01, and replace the first one 89 with C3, then it will only mark the blocks with "freé" and list them in its data segment, without actually releasing them, so that they can be inspected using some memory editor... (In MozGcGc.dll in runtime memory at offset 0x8080 is list of the released chunks...))

It can be "installed" by copying it to Bin\Palemoon folder and listing MozGcGc.dll in dependentlibs.list before the last line... Last line must stay xul.dll

Or you can test it without installing: Have Palemoon running, and where you unpacked MozMem_18.zip in folder MozGcGc, there is rldmod.exe tool, which can be used thus from command line:
rldmod.exe Palemoon.exe C:\Path\To\MozGcGc\MozGcGc.dll
(if you open cmd.exe command line, write: rldmod.exe Pallemoon.exe , and after space drag-drop the dll onto command-line, so that it is filled with full path...)
My rldmod.exe tool can load DLL into another running process. The process is found by name, the DLL must be "visible" from the process (in its folder), or it can be specified with full path...
(If you have multiple Palemoon processes running, instead of Palemoon.exe specify integer PID (process id) to load only into some instance... It allocates memory using VirtualAllocEx, writes there DLL name, and uses CreateRemoteThread on LoadLibraryA function to load it, waits for thread finished, and frees the memory for dll name by VirtualFreeEx...)

It could write a log-file of released pages, but then I couldn't claim it is pristine clear not writing to any files... So it instead logs the released pages in cyclic memory buffer...
(Again it is published with source and with byte listing, so it can be "verified" it does not contain any other "harmful" code... It is just 3 KiB file, of which 1 KiB is dll header, 2 KiB code...)

In case it encounters Exception (there is a try-catch), it sleeps a while and restarts the thread... It can be manually stopped and unloaded by placing byte 1 at offset 0x800C from where it is loaded in memory... If it is loaded on startup, the stop-flag is on 0EFE800C and statistics on 0EFE8010, but if loaded later in running Palemoon, it will be on different address... (it takes 15 or 30 seconds before that stop-flag byte is noticed, and not if it restarts due to Exception... Normal user does not need this, it is for debugging and playing with it without restarting Palemoon...)

To get statistic, what it does

, using my Eval.exe language, from command line:
eval.exe -dll EvalTaskUtil "var P:=OpenProcess('Palemoon.exe'),M:=P.Memory,B;P.Modules.ForEach(#f(Mo){if(WildMatch(Mo.Module,'MozGcGc*.dll'))B:=('0x'+Mo.Base)*1});if(!B)#r 'Not found';L('Runs: '+M.ReadUint(B+0x8010));L('Drops: '+M.ReadUint(B+0x8014));"

May output something like this:

Runs: 88
Drops: 16

Or it may output:

Not found

Again - it is just an Emergency Solution before you correct the Leak, for users not patient to wait for corrected Palemoon 34...

--------------
Then on my Windows 7, there is another significant leak, that system dlls

of "Save as" file-dialog sometimes forget to release mapped imageres.dll having 20Mb, often it is there twice... I tried to search, if it is pointer to it anywhere - didn't find any, and I unmaped it manually using TaskView and it did not cause any problem - it was really just forgotten...
(Probably the call to UnmapViewOfFile() sometimes fails and the system dlls do not retry it later... I do not plan making any automated solution to this problem, it is hard to recognize it would not cause a problem and it may differ between various Windows versions...)

--------------------------
Please instead of whining you dislike my DLLs, can you do something to fix that bug, that every web-page load forgets to release and abandons 1 or more GC chunks, 1 Mb memory lost on each page load...?! (not sure but possibly each iframe looses it's own GC chunk? I'm not sure...)
They are full of RelocationOverlay, and their JSRuntime was already destroyed and freed... So they passed through jsgc.cpp GCRuntime::relocateArenas, but were not released later... There are some #ifdef differing between DEBUG and normal version... I suspected js\src\vm\HelperThreads.cpp struct parseTask, but when reading the source, it seems it releases its explicit context properly... May it be, that the chunks are queued to release in some bg thread, while their JSRuntime is released sooner??? Not sure...

-------------------------------------------------------------------------------------------------------------------

Off-topic:

he distributes Russian propaganda and fakes about the Russian war in Ukraine

Maybe you were instead fed with Western Propaganda full of Lies and Hypocrisy, that you do not recognize the Truth any more ?
I really do not want to discuss politics here, and I am professional enough to distinguish between my personal preferences, journalism, and my professional IT work...

--------------------------
Nb - while reading this forum from my last post and previewing (now 7x) this post edits and saving each in mht, the MozGcGc.dll already released cca 80Mb of abandoned GC chunks... Before finishing it (with 16 previews and saved mhts), it released 130 Mb of abandoned GC chunks and there appeared one stray mapped imageres.dll from save-as file-dialog, on the following map it is the brown-field on 240E0000, and unmapping it manually I see no problems with SaveAs file dialog... (this map is progress from the first column in the 4-column collage above, during writing this text in forum, with MmHeap, and MozGcGc.dll doing periodic cleanup...)

Mem_I_240309_1914.png

πα½

[P_A_Semi]

Short summary of my post above:

There is leak of GC Chunks after relocateArenas, when the JSRuntime is destroyed. It is something temporary during webpage loading, probably one for main page and one for each iframe...??
That releasing them does not cause any harm is a proof they were forgotten and program makes no further reference to them ever...

Please test it with released version of Palemoon 32 or 33, because there are some #ifdef DEBUG in jsgc.cpp in the functions related to releasing these relocated chunks...
(I provided some proof-of-concept test tool to release them periodically, but you could also deal with them otherwise...)

It causes hundreds of MB of leaks per day of web browsing...

πα½

[athenian200]

There is leak of GC Chunks after relocateArenas, when the JSRuntime is destroyed. It is something temporary during webpage loading, probably one for main page and one for each iframe...??
That releasing them does not cause any harm is a proof they were forgotten and program makes no further reference to them ever...

Please test it with released version of Palemoon 32 or 33, because there are some #ifdef DEBUG in jsgc.cpp in the functions related to releasing these relocated chunks...
(I provided some proof-of-concept test tool to release them periodically, but you could also deal with them otherwise...)

I think this is potentially useful information, and I thank you for it, and the DLLs... the reason we're not recommending them is strictly security because of the fact that we can't audit ASM code, it's nothing personal. What I've been wondering is which part of the code we need to look at, so that people can get better memory management out of the box...

And it seems like you are saying it is actually the garbage collector that's leaking after all? I mean, if you're suggesting that we need a garbage collector for our garbage collector, it sounds like the right fix would be to fix the garbage collector itself...

Anyway, I just want to point you to something that could help you find where in the code the stuff you're observing in the DLLs is happening...

https://xref.palemoon.org/goanna-central/

If you look through this, you can cross-reference line numbers and variable names, etc. So if you can point to a specific line of code where you think something is off, I can test out changing that code up and seeing what happens. It's kind of an odd workflow, with you trying to guess at what's wrong and where it's going wrong, and me trying to modify the code and compile, but I'm willing to give it a shot.

[P_A_Semi]

... the topic about the freezes of the interface ...

Repeating, that javascript.options.gc_on_memory_pressure in about:config should be set to false, because in case of pressure (JS::gcreason::MEM_PRESSURE) the GC runs ever and ever again...

There should be some timeout barier, that prevents running GC with this reason sooner than 1s or 5s from last such run regardless how often it is posted from upper UI levels...
(that is what causes GUI "freezing" (very slow responses) in case of memory pressure that the GC cannot solve but it comes ever and ever again, disabling this option seems to aleviate the "freezing", but not solving the leaks which are causing such "pressure"...)

... So if you can point to a specific line of code where you think something is off ...

I downloaded Palemoon 29.4.6 source earlier from the archive, that helped me analyzing it... (And then I checked in git jsgc.cpp if it is similar in relocateArena and related functions...)

But I didn't find, what is actually wrong...

It would help to place a logging function at chunk allocation (js\src\gc\Allocator.cpp Chunk::allocate, add some global variable remarking what is being allocated, and write it to some log file including Chunk address...), at chunk releasing (GCRuntime::recycleChunk, js\src\jsgc.cpp GCRuntime::finish, static FreeChunkPool , logging released Chunk address), and compare it with the log of "abandoned" chunks from my MozGcGc.dll... Or just compare them to see, which ones were not released...

Or you can use js\src\gc\Heap.h struct ChunkInfo in Chunk.info.padding char padding[24] to write there some remark whose Chunk it is, like type of JSRuntime owning it etc... or give those GCRuntime some "name" in some variable to know what it is... but please don't leave that in released version... Or make some #ifdef GcDebug to be removed when you later solve it...
(to this I'll add, that if there would be anything in the padding field other than my "freé" mark, my MozGcGc.dll would not touch such chunk... if you release such Palemoon version, I'll have to rewrite MozGcGc.asm to adapt to such change, if there still would be such leaks...)

(This type of changes, if I cannot recompile Palemoon, are out of my possibilities... I repeat that I do not have disk space here to install MSVC, and also the sources are on slow external usb disk, and I have Windows 7 32-bit, and where I have Windows 10 64-bit, there is only small (256Gb) ssd disk with few Gb free space...)

πα½

[Moonchild]

Thanks for the detailed analysis; definitely interesting.

There is, however, one thing that you may not be aware of and that is that vacating but not releasing the memory has been created by Mozilla on purpose for recycling already-allocated chunks of memory which (presumably) improves performance.
It does make me wonder though whether we may have 2 similar technologies trying to work in tandem that interfere, as jemalloc also recycles arenas, so the Moz GC really shouldn't have to do that as well. I'm wondering now if we stop doing that in GC, leaving any recycling to the memory allocator itself (which would make a lot more sense TBH) if that would solve at least part of this issue.

[P_A_Semi]

... So if you can point to a specific line of code where you think something is off, ...

I found it, by placing halt-point in JSRuntime::destroyRuntime, and waiting what catches in... Also disabled clearing free memory in my heap and outright refraining to free JSContext-sized blocks (0x6AD8 bytes in PM 32) and instead just placing there string 'FREE' at beginning, to see how it ends up when it is passed to free() ... And I disabled memset, that fills that memory before releasing (in js::DestroyContext, there is js_delete_poison(), using disassembler, it is on offset +2C57F3 in mozjs.dll in Palemoon 32.2.1, bytes E8 82 7D 1D 00 are rewritten to all 90 90 90 90 90, using TaskView I patch it in runtime memory without modifying the dll file)...

• There is background thread from xul.dll, that has on stack resource://modules/osfile/osfile_async_worker.js , that has its own JSRuntime, thus destroyed...
• At the moment when destroyRuntime is called, there is a NurseryChunk, which when it finishes, ends up in GCRuntime::emptyChunks Pool after that pool has been already cleared, and is never released...
• js::Nursery::disable() calls updateNumChunks(0), in js::Nursery::updateNumChunksLocked() it calls runtime()->gc.recycleChunk() . But by that time, emptyChunks pool was already cleared, because JSRuntime::destroyRuntime() first calls gc.finish(), and then later it calls gc.nursery.disable(); few lines below...

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...

https://xref.palemoon.org/goanna-central/

If you look through this, you can cross-reference line numbers and variable names, etc.

Yes, thank you, that is pretty much faster workflow than searching the sources in my file-manager on slow external usb disk...

... that vacating but not releasing the memory has been created by Mozilla on purpose ...

No, that must not be "by purpose" to leak 1Mb memory on every webpage load...!
(Or yes, I understand that "design" now better than before... But while the memory may be left around for a while unused, but it must not accumulate over time, it should be released, possibly with some delay...)

... whether we may have 2 similar technologies trying to work in tandem that interfere, as jemalloc also recycles arenas ...

I apologize for formerly accusing jemalloc of being "ineffective"...
The chief problem is in that lost NurseryChunk on every webpage load, that accumulates to hundreds of MB of memory during a day of modest web-browsing...

And yes, in assembler the heap may be faster (and there are literally milions of heap allocations so the speed matters), but effectiveness (less memory footprint for same amount of allocations) is probably comparable...? (Not sure... But that seems to me now, when I compared the colored graphics and found that the heap memory usage does not differ that much as I thought...?)

There is also problem with the system Heap (HeapCreate,HeapAlloc), used by ucrtbase.dll and msvcrt.dll (each has its own), that end up having a lot of "reserved" blocks, obstructing address space... (So now I'm not sure, that when I first complained about 500Mb of "reserved" and not properly reused address-space, whether that was jemalloc or HeapAlloc()...? When jemalloc was pushed from low addresses by those hundreds of lost NurseryChunks and ended up at top-most addresses of the growth, but the "reserve" wasting was probably done by HeapAlloc...? I'm not sure now...)

That colored map of address space I posted yesterday is produced

in MozMem_18.zip, Tools\DumpBlocks.script
eval -f DumpBlocks.script -v Level=2 -v Img=1 -v View=1 -v Out=Mem_A_%D.txt
The colors depend on memory block classification... There constants 0x118 and 0x400 (for GC Chunk detection) are specific to Palemoon 32, in Palemoon 33 it would be 0x128 and 0x470 respectively...

πα½

[P_A_Semi]

Then another type of minor "leaks"...

I have always Browser Console (Ctrl+Shift+J) opened, and I periodically hit Clear button (Alt+R) to clear it...
But there are many strings held by the browser console "forever" until the browser console window is closed...
Example:

Clpx269184_crop.png

This string is allocated on Heap (jemalloc in your case, MozMem in my case) a day or more after I visited that page and closed the browser tab... (this one is Response headers from some request)
It holds whole surrounding 4kb memory page, where space around is "free" but not reused soon and the page (arena) may not be released until there sits this stray string...

When I close the Browser Console window, during the following few tens of seconds it "works" on background and releases some cca 30 MB of memory according to TaskManager memory usage...
(I think these or similar strings are even listed in "detailed" about:memory report, long after the related web-pages have been closed...)

I'm not sure who holds the string after I "clear" the Browser Console window...? But it would be nice if it would really release the memory for request headers at that moment and not waiting for closing the Browser Console window... (There could be some background task spawned upon user clearing the Browser Console window, that would walk the former entries and explicitly release the strings allocated from heap... There is some list of them somewhere, because the Browser Console releases them when its window is closed...)

When you will search for them in code, start with the "response headers" in Browser Console, where they are stored, and when they are actually released... As a user, I would expect them to be released when I hit "clear" button in the Browser Console, or soon afterwards...

πα½

[Moonchild]

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...

[P_A_Semi]

I have published another version MozMem_21 - now more optimized middle blocks free-list, there is now special pool for 8Kb blocks, used very often by PL_Arena, and there is also special pool for 8-byte blocks or smaller...

About "auditing" claims - software is usually rather being Tested, since auditing often overlooks problems not visible at first sight, as I've proven on the leaked GC chunk case... Did you "audit" AES encryption using assembler, video-codecs, and Wasm which compiles internet-supplied Javascript or Regexp into assembler ?

-------

I've spent some time getting Brotli decompress to extract and patch Palemoon.res files (there are two), and analyzing the Browser Console leaks... Again I'm offering it with bug-fixes and optimizations I already tested...

The Browser Console does not release its NetworkEventActor objects when user presses Clear button... In my case, on the web-page I read most and where I occasionally use wp-admin, there is Cookie string, which converted to 2-byte unicode has over 1300 bytes... I'm not sure why are there 8 cookies... But that may happen to many other users... A typical WordPress has between 70 and 110 requests for reading an article... The cookie string is in memory in 2 different flavors, one is prefixed with ref-count and length, the other is not, and when I read an article, tomorrow I come and inspect, and GC is still scattering the cookie strings here and there... Closing browser console, which was already "cleared", releases between 20 and 50 Mb of memory, after a while when it settles...

I propose a solution:
In file chrome/devtools/modules/devtools/server/actors/webconsole.js , in function onClearMessagesCache there should be added:

if (this._actorPool && this.networkMonitor) {
let A = [], actor, acts = this._actorPool._actors, aid, n;
let voidActor={actorID:0,release:function(){},stub:true};
for(n in acts)if(n.indexOf('netEvent')>=0)A.push(acts[n]);
for(actor of A)if(actor){
aid = actor.actorID;
if(actor.release)actor.release();
// sometimes the actors are not removed, possibly because of scratchpad inspector visited them ???
// or because there are thousands of them and "delete" operator has some bug in such case ?
// in such case, plain delete does not work, not sure why...
if(aid && acts[aid]){
acts[aid]=voidActor;
delete acts[aid];
}
}
if(this.networkMonitor.onConsoleClear) this.networkMonitor.onConsoleClear();
}


(not sure why is there "pre" in the bb-forum, if it removes spaces at start of lines?)

Then, when enabling devtools.chrome.enabled to run Scratchpad in Environment/Browser context, there is bug that logs long error message in Browser Console, which is simple to fix:

get globalDebugObject() {
//S:x240323: return this.parentActor.threadActor.globalDebugObject;
//S:New240323 - avoid problems if scratchpad executes in Browser Context:
let pa=this.parentActor, ta=pa?pa.threadActor:null;
return ta?ta.globalDebugObject:null;
//
},

See my version of actors/webconsole.js, the places I patched are marked by //S:New... tag ...

Then, there are http headers (in request.headers and response.headers), which repeat very often same ones... I propose a patch to cache them and use same object {name,value} in each request... There are callstack frames which repeat often and again they can be reused...

As PaleMoon boasts of being very "Configurable", which is perfect, then I propose adding another configuration option devtools.browserconsole.filter.httpheaders , that defaults to true, no change from existing behavior, but can be switched off, so that NetworkMonitor discards all request and response headers and cookies... Unless it is used from Network tab in Devtools, where the headers are retained... As a Web developper, I use Browser Console often, and occasionally also Network recording, and I am also sometimes interested in http headers also in Browser Console, but during most of my work, I do not need them and they just occupy memory, and not just little... There could be a switch for that in Browser Console below button Net... Also, in the Browser Console, the rawheaders are never displayed, so they are discarded regardless of the option, while in Network tab in Devtools they are retained, depending on this.saveRequestAndResponseBodies ...

Which then looks thus, if these "headers" tabs are opened in Browser console:

Clpx274373_crop.png

(the lists may not be just empty, since there are some "ifs" that check the headers already arrived...)

My proposed and tested solution is in network-monitor.js , again all modified places marked by //S: tags, related changes have usually same date in that tag...
(From PaleMoon 32.2.1, but as I compared PaleMoon 33.0.1, these two files were identical there, so the patch is valid for newer version also...)
(The about:config option devtools.browserconsole.filter.httpheaders appears only when Browser Console is first opened with that network-monitor.js patch...)

As a proof-of-concept, I made PM_Browser_altUtil.js script, also compatible with my old Firefox 45, that is used in Scratchpad with devtools.chrome.enabled, switch Environment/Browser, and run... Or open Shift+F4 Scratchpad from about:config page, which then also executes in Chrome context, just "this" is there something else...
It installs this.altUtil object with various useful functions, among them this.altUtil.exportNetActors() asks to export json-like file with Network activity from Browser Console, even if it was cleared - unless my patch above that really clears them, and this.altUtil.clearNetActors() to clear them (regardless of the actors/webconsole.js patch above)... These can be executed from Browser Console jsterm at bottom of that window, which is there with devtools.chrome.enabled , or in that Scratchpad in PM_Browser_altUtil.js below each function is a comment, that can be selected and Ctrl+L evaluated, or Ctrl+I inspected ...
A toy and example for web developers, not for normal users... (and as it is plain open-source Javascript, you can "audit" it that it is not a malware... for use only by someone who understands what is it useful for...)

Regardless of aforementioned clearing of NetworkEventActors or outright discarding http headers, one of two versions of that long cookie string (that not prefixed with ref-count and length) are still in memory (repeating multiple times) and being scattered here and there by GC... I'm not sure where they are in javascript and for what purpose...? (when inspecting my Heap, I see them slowly eating all larger free spaces from middle-sized blocks and fragmenting them into parts the size of that cookie string, until they are all occasionally released, and then soon repeating again...)

(about GCRuntime...)
I think the simplest solutions would be 2 or 3, or perhaps do both...

I hope you would manage your team to apply those fixes to GC...
As I am only providing the analysis, suggesting solutions, but I will not apply them... As I am a newbie here and an externist, you'd better check my proposed changes instead of allowing me to apply them at my discretion...

I also suppose that if you accept (some of) my fixes above, you (someone of your Team) would reformat them and remove the //S: tags ... Generally said, I personally do not need it at this moment, because I already patched it on my computers, but other users may find it useful too...

Or is there something like bugzilla, or a web-page where to report bugs and suggest solutions, better than thus in a Forum ?

πα½

[Moonchild]

Or is there something like bugzilla, or a web-page where to report bugs and suggest solutions, better than thus in a Forum ?

https://repo.palemoon.org/MoonchildProductions/UXP

[P_A_Semi]

Or is there something like bugzilla, or a web-page where to report bugs and suggest solutions, better than thus in a Forum ?

https://repo.palemoon.org/MoonchildProductions/UXP

Thank you... I've used https://repo.palemoon.org/MoonchildProd ... oon/issues for this one and two other minor issues...

From yesterday I've also corrected my network-monitor.js , there was problem with httpheaders disabled and the newer header caching... (the attachment in the issue is already the corrected version, there is tag 240326 with the changes...)

After executing PM_Browser_altUtil.js in Scratchpad in Environment/Browser, then selecting in comment this.altUtil.getWCA() and pressing Ctrl+I for inspector, there is WebConsoleActor in inspector, there is networkMonitor, there can be seen new props hdrCache and cookieCache , there "serial" value shows, how much {name,value} objects passed through the cache, in my case it's tens of thousands per day, not sure how many distinct ones, they can be seen in the maps there in inspector...
Also there in _actorPool._actors are objects like server1.conn1.netEvent100 and it can be used to verify whether they are released after clearing the Browser Console...

πα½

[Moonchild]

I pointed you to the UXP repo because the Pale Moon repo only holds the front-end of the browser; the devtools are part of the UXP platform code.

Still, thanks for filing the detailed issues you did. I'll see if I can copy/paste the stuff across to UXP when I get time.

[P_A_Semi]

I pointed you to the UXP repo because the Pale Moon repo only holds the front-end of the browser; the devtools are part of the UXP platform code.

...

I've seen on right side https://repo.palemoon.org/MoonchildProductions there are languages, there was C++ for UXP, so I selected a category where is Javascript...

Yesterday I discovered another significant leak in Browser Console, that it does not release the DOM elements for net requests and the "client" part of NetRequest objects, after the console is cleared... Described in comment of that same issue, again with a code to fix it: https://repo.palemoon.org/MoonchildProd ... ssues/1963

πα½