Page 2 of 2
Re: PM never releases memory?
Posted: 2019-07-21, 10:44
by PalleP
adesh wrote: ↑2019-07-21, 09:34
What are the browser settings you have tweaked? It'd be good if you publish your "troubleshooting info" here so somebody can point out the faulty configuration. See the stickies for that.
I have provided tons of info several times, see these two treads:
viewtopic.php?f=3&t=20573&hilit=freeze
viewtopic.php?t=20882
Re: PM never releases memory?
Posted: 2019-07-21, 14:21
by Moonchild
PalleP wrote: ↑2019-07-21, 10:44
I have provided tons of info several times, see these two treads:
I understand that you feel it superfluous, but:
- You can't really expect people to go and dig through your previous posts in case you already posted the relevant information before
- The information provided in other threads may be outdated
Re: PM never releases memory?
Posted: 2019-07-21, 19:47
by PalleP
Ok, I have now made a new tread in general instead of here under Linux, and hope it will not be flooded by users telling that they can open 200 tabs.
viewtopic.php?f=3&t=22613
Re: PM never releases memory?
Posted: 2019-08-25, 12:53
by mabloom
PM does , I think, need to have it's memory usage examined closely by an engineer who is not absolutely certain that it has no issues in that area.
I've been using an old 1,2Ghz Pentium M machine with 512Mb Ram as an emergency measure following the death of my regular computer(due to its power supply getting shorted out due to absentminded insertion of the wrong kind of connector (one of those wide and flat, hard-metal-shielded, skinny connectors provided for new external USB-3 drives) into a regular USB receptacle into it (It was an ASUS Gaming laptop, for those who might want to be wary, prior to purchase, of hardware that fails to protect it's power supplies from such accidental circumstances).
With a 32 bit version of Pale Moon, this machine very quickly demonstrates the problem being discussed in this thread without very many tabs in use.
This old Pentium M machine turns out to be a very useful testbed for demonstrating the issue because on the same system, I have also been using a 32 bit version of the "Flashpeak Slimjet" browser (not at the same time, of course). Although Slimjet does slow down as tabs are accumulated, unlike the Pale Moon browser, it speeds up again as I close some of them. "apples vs oranges" concerns should only be minimal as I am using the same mix of web pages in Pale Moon as in Slimjet. "Minimal" rather than zero simply because the 32 bit version of slimjet has some bugs which cause failures in the rendering of some media types. For the purpose of maintaining the integrity of these comparisons, however, I'm making a conscious effort to avoid pages using those types.
Re: PM never releases memory?
Posted: 2019-08-25, 13:25
by Moonchild
Minimum system requirements for Pale Moon include 1GB of RAM (with most of that free for use, I should clarify). Its settings and (internal) configuration aim for that as a minimum. If you are constantly creating memory pressure by running it on a machine with half the expected minimum amount of RAM, with a good chunk of that taken up by the OS and other software, then you can expect the browser to not perform well.
Re: PM never releases memory?
Posted: 2019-08-25, 18:46
by mabloom
As I'd hoped my post would have made clear, my immediate situation is a very temporary one. One that you could have treated as a stroke of luck, for it caricatures the very real situation that others are seeing, but because the amount of memory on their systems is in excess of the amount you have specified as a minimum, they have have had more difficulty than I've had with the main task that is an end-user's responsibility in such a situation: that of delivering to maintainers a means for reproducing the problem that they are seeing.
In the relevant (to this discussion) portions of the 40+ years I have spent in the field of computer science, I have diagnosed and resolved countless difficult bugs and escalations at both user-level and deep within the guts of the UNIX kernel. In doing so, I have experienced many times just how difficult it can sometimes be to obtain data that is of sufficient quality and/or quantity to help reproduce a reported problem.
To be handed an a new insight into an existing problem that has been reported by others is a
gift.
To turn that gift on its head, and suggest that the person giving you that gift was wrong to do so is a kind of hubris that is ultimately going to do harm to your product.
If I were one of the earlier individuals who had described having this issue (
on systems that exceed the memory requirements stated in your reply to me) I would be outraged at such dismissal of additional data that a third party had taken the time and trouble to provide you with to help in the investigation of the problem I'd previously reported.
When I first read about Pale Moon, not very long ago, I had high hopes for it.
I'm researching the purchase of a new computer, "as we speak".
I'm also learning about Pale Moon's support, both from posts on other sites and in these forums. And I've discovered that your response to the assistance I tried to provide is not unusual. It conforms to a trend in how "uncomfortable issues" appear to be dealt with here. (In fact, after reading about the trumpish manner in which NoScript had been labeled
malware, I half-seriously
actually had expected the information I was providing to be treated with dismissal.)
Some of the following, which range from probable to quite certain, may be under your control, and some may not be:
- I'm going to replace my damaged and hopelessly inoperative computer soon, after which
- this low-memory computer shall go back to the closet, and
- you may continue to dismiss a very real macro-level memory leakage issue, and
- if there are further posts about it, you may find ways to dismiss those too.
- Since Pale Moon is too good to have real problems, there will be other issues reported that are also dismissed
- The number of un-problems may continue to accumulate, and maintainer frustration with end-users may mount.
- The number of un-problems has the potential to become so great that most copies of Pale Moon could end up being "relegated to the closet".
Re: PM never releases memory?
Posted: 2019-08-25, 19:10
by Moonchild
Excuse me, but reporting issues in a non-supported environment that may or may not be caused by the same is not a "gift", it's complicating matters and opening the door to a lot of wasted time and effort if it is not caused by the same. If you are so experienced in your troubleshooting as you say you are, then you should already know this.
Accepting such an environment as valid will not help anyone except your temporary use case, so please don't try to make it into something it's not. Being all high and mighty and by-the-by insulting the people providing this browser is not scoring any points either. If you want to set yourself up for being dismissed and ignored, then that is exactly the way to do it, and that will be all on you, not Pale Moon, not the community, not the "trumpish" devs, no, just you.
You should not attach anything to our refusal to cooperate in troubleshooting a system that is way below spec except this: Minimum system requirements are minimum system requirements. Not "kinda" minimum, not "acceptable", but "totally unsupported".
You can pat yourself on the back all you want and you can try to lay blame where none is due all you want, but that doesn't change the fact that these minimum requirements are stated for a reason.
Re: PM never releases memory?
Posted: 2019-08-25, 22:19
by wicknix
It's not the browsers fault. I run PM28 and Iceweasel-UXP without issue on an ancient 32-bit 1.5ghz powerpc mac mini g4 w/1gb ram. With 5 tabs open and 3 other apps running my system stays well below 500mb ram used.
Cheers
Re: PM never releases memory?
Posted: 2019-08-26, 17:38
by mabloom
The first step in solving a problem is recognizing that it exists.
A specific set of symptoms have been reported occurring in fully-spec'd systems, ones not subject to the limitations of minimal memory.
If a problem is reported in a system that meets stated specifications, it should be investigated.
A report has been received describing the same set of symptoms occurring at an exaggerated rate under circumstances where specific resources are limited.
It can be worth investigating whether the reason for a set of symptoms being encountered more quickly is that an edge condition has been encountered more quickly. (and in this case, the obvious candidate for the nature of the edge condition is pretty obvious)
Anything that helps one spend less time reproducing a problem would be welcomed. (except by those who would point out that the least time of all is spent by never trying to reproduce the problem
)
Introducing edge conditions into a controlled testbed is a time honoured and well-respected investigative methodology.
Can you honestly refute any of the above statements, either standing on their own or in series?
How about the following:
- It might be worth while to obtain the browsing history and browsing timeline from a fully spec'd system on which the problem has been reported.
- It might be worth while to use those for attempting reproduction of the problem.
- Once reproduced, it might be worth while to attempt to locate it's proximate cause with an eye toward resolving the problem.
- It is possible, after reproducing the problem, to overshoot it's cause during a session in your debugger, possibly making it necessary to begin all over again to reproduce the problem.
- It is possible for that to occur repeatedly.
- Reducing the percentage of time spent in repetitive reproduction of a problem is a way to allow a greater percentage of time to be spent in analysis following it's reproduction.
- If one could reproduce the problem more quickly, one might be able to locate it's proximate cause more quickly.
- If one knows that the problem occurs more quickly in systems with less RAM than the amount currently being used, It might be worth proving whether (or not!) the problem will reproduce more quickly after rebooting with progressively larger blocks of RAM disabled (easy to do on Linux; I'm not sure about Windows) at a time.
- Am I missing something?
How do you think an assertion that "
a problem occurring in fully spec'd systems does not deserve attention because it is has been seen in a below-spec system" sounds to observers? It sounds to me like
conflation.
I would like to refer you to the following presentation:
http://mathscinotes.com/wp-content/uploads/2016/03/Kepner-Tregoe_Methodology_version_2_20130307.pdf
( Especially starting with slide number 19.
)
Although the presentation is not specifically targeted toward engineers, the methodology it describes is one taught in workshops given on-site at NASA and at Fortune 500 companies, including two of my former employers.
Here's a teaser: It begins "Apollo 13: Houston, Houston, do you read me ? We have a big problem…."
Re: PM never releases memory?
Posted: 2019-08-26, 18:48
by New Tobin Paradigm
tl;dr check again to be sure? You could have just said that. You don't get points for being ridiculously verbose while saying MAYBE two things.
Re: PM never releases memory?
Posted: 2019-08-27, 00:52
by moonbat
mabloom wrote: ↑2019-08-26, 17:38
The first step in solving a problem is recognizing that it exists.
A specific set of symptoms have been reported occurring in fully-spec'd systems, ones not subject to the limitations of minimal memory.
Maybe wait till you can reproduce it on a fully spec'd system and share relevant logs/troubleshooting info/screenshots from there instead of bloviating here. People here aren't telepathic to be able to figure out what's wrong without providing complete and
relevant info.
Re: PM never releases memory?
Posted: 2019-08-27, 07:14
by Moonchild
Off-topic:moonbat wrote: ↑2019-08-27, 00:52
instead of bloviating here
looks up "bloviate" -- hah that term describes it exactly! Thanks for adding that one to my vocabulary.
Re: PM never releases memory?
Posted: 2019-08-27, 08:02
by moonbat
Speaking of which, I've faced the same problem on Linux(Mint 19.2 Xfce and x64 PM), with a 4 GB RAM i5 HP laptop (Doesn't have an SSD, if that's relevant). I've seen Gmail still retaining memory (around 50-60 MB according to about:memory) after being closed, and overall PM memory usage stays at 1-1.2 GB even after closing Gmail. I don't usually run too many other applications concurrently given my hardware constraints. I always close tabs when I'm done reading a page, and only keep Gmail and Whatsapp web open always. Usually I try to keep less than a dozen tabs open concurrently. Anything I should look at? I know I have a few legacy FF extensions but
about:addons-memory doesn't show anything out of the ordinary.
Troubleshooting info below-
Moonchild wrote: ↑2019-08-27, 07:14
Off-topic:
[
looks up "bloviate" -- hah that term describes it exactly! Thanks for adding that one to my vocabulary.
Re: PM never releases memory?
Posted: 2019-08-27, 10:05
by Moonchild
GMail is a known issue -- it does some nasty scripting that will cause the tab to become a ghost window by not releasing properly. Unfortunately finding out exactly what causes it is going to be difficult because we are peerless in that respect -- Firefox and Chrome don't care because they have opted for multiple processes; those will always dump everything when closed, including allocated memory that might otherwise be "sticky". I've been thinking about how to work around this but it'll take time to research.
As for memory not being immediately freed otherwise, that is very much by design. A lot of the browser and platform uses buffering and caching memory pools for performance reasons. For example, there's a surface cache that will hold up to 1 GB of decoded and rendered image data so they won't have to be redrawn -- that will not be immediately released when closing a tab. There are similar mechanisms for page content as a whole and composited data. All of that is on purpose, and depends on whether there is memory pressure or not when and how it's released. In addition, application memory is not as straightforward when looking at numbers, so you have to keep in mind that a "working set" or "committed" memory number is not necessarily actually allocated or exclusive to the application.
Re: PM never releases memory?
Posted: 2019-08-27, 12:56
by moonbat
Moonchild wrote: ↑2019-08-27, 10:05
As for memory not being immediately freed otherwise, that is very much by design. A lot of the browser and platform uses buffering and caching memory pools for performance reasons. For example, there's a surface cache that will hold up to 1 GB of decoded and rendered image data so they won't have to be redrawn -- that will not be immediately released when closing a tab. There are similar mechanisms for page content as a whole and composited data. All of that is on purpose, and depends on whether there is memory pressure or not when and how it's released. In addition, application memory is not as straightforward when looking at numbers, so you have to keep in mind that a "working set" or "committed" memory number is not necessarily actually allocated or exclusive to the application.
Thanks for the detailed explanation. Is it possible to separate out memory usage or leaks from misbehaving extensions? As I understand, XUL extensions are sort of 'in process' (for want of a better word) with the browser's own core, and were blamed for Mozilla deciding to dump XUL altogether because they couldn't be bothered with having to troubleshoot multiple combinations of extensions with users complaining about high memory usage/low responsiveness.
Can one reliably troubleshoot extensions as a developer, other than disabling them one by one?
Re: PM never releases memory?
Posted: 2019-08-27, 13:25
by New Tobin Paradigm
moonbat wrote: ↑2019-08-27, 12:56
As I understand, XUL extensions are sort of 'in process' (for want of a better word) with the browser's own core, and were blamed for Mozilla deciding to dump XUL altogether because they couldn't be bothered with having to troubleshoot multiple combinations of extensions with users complaining about high memory usage/low responsiveness.
Some extensions misbehave sometimes like any javascript that is executed. Only as good as the code is. But Mozilla is fake news and obviously we have a generally performant XUL based platform with full extensability using the power of XUL. So while that could be a contributing factor.. It wasn't for them. They have shown us that a rich extension system using the technology the applications them selves use is completely antithetical to being able to redefine the browser every 30 seconds so it won't be racist or something.
You can't change the everything all the time AND maintain compatibility with code up to 15 years old. Mozilla also proved you can't even do it with abstraction which among other things was the whole point of the Add-on SDK with Jetpack Extensions. Also, FUEL before it.
Re: PM never releases memory?
Posted: 2019-08-28, 04:47
by mabloom
@adesh "think the issue is with private browsing mode." Other concerns notwithstanding, It is easy to see why one could perceive the problem to be a consequence of the use of private browsing mode. While the use of private browsing mode could easily be exacerbating the problem in your case, I don't think I'd look there for the underlying cause. If heap object segregation is being used as part of the enforcement of private browsing mode, it could certainly be contributing, by affecting how quickly one could run out of configured virtual memory.
Come to think of it, the effective deadlocks people have described experiencing could be a consequence of the program running out of allocatable virtual memory, not physical memory (that I didn't make this distinction earlier tells me that I've been retired for waay too long). If you'd like to try it, a possibly useful experiment might be to increase the amount of virtual memory you have configured, to see if you might merely run more slowly rather than blocking. For this experiment, you might try setting it to four times the amount of RAM in your system (unless you already have at least that, in which case, there's no experiment)
An experiment like this is best tried on a system from the current decade. Something much older (NatSemi 32016, anyone? - just kidding) may already be slow enough to make the incremental slow down be so severe that without aid, it might be hard to distinguish from effective deadlock, making the experiment worthless)
@New Tobin Paradigm: Re: "check again to be sure? " ... "You don't get points for being ridiculously verbose"
Verbosity... You have put your finger squarely on what at one time had been called one of my biggest communicative faults (you should have seen a specification I had once written for a means of fully encoding GNU debugging "stabs" within unmodified standard AT&T COFF symbol table entries via a method that would allow them to be successfully and correctly handled in a backward compatible manner by an unchanged native System V linker binary - it
was very wordy, with many definitions being minimally altered edits of neighboring definitions.)
Thanks for the reminder. I shall try to be more concise in the future.
But "check again..."? I'd been concerned over an appearance of no examination having taken place in the first place. Had I misinterpreted the situation?