Firefox poor memory management in live editions

[Bill777]

This has been affecting my systems for some long time now, but it is not immediately clear who should own the problem, between linux itself, the distro, the Live concept, the filesystem used by Live editions, or firefox (as amended).
It is further complicated by the misbehaviour of Flash within its plugin-container, which is not simply memory leakage but seems to get into lock contention sometimes at quite low memory use.

I am of the view it's primarily a Firefox problem, because it is Firefox that is allocating memory to itself, and it could be obviated by altering the Firefox memory-grab allocation procedures - but there is a relatively complex interaction.

Specifically, it has continued through to FF 16 in my certain experience, but started ages ago.
The symptoms are similar to early & not well-formed bug/3677.
At one point I thought it was due to the aufs filesystem, but it continues unabated.

It may exend to the installed system too, but I haven't actually installed for some time.

Symptoms.
#######
I'm using a fairly capable recent laptop with over 3Gb enough of RAM.
There is an ample (and fast) HDD swap file.
Setting swappiness low does not seem to alter much.
Moving FF cache to disc does not make discernable difference.
The problem has affected other distros, but could well be solved here.
It occurs with a raw Firefox, no addons. In fact, it is worse without extensions such as adblockplus & flashblock, which reduce consumed memory.

Using a live DVD edition for an extended time, after building up a number of tabs with plenty of content, first Firefox, & then the whole system becomes sluggish.
It goes on to have petit-mal seizures, ignoring all attempts of the actual attendant computer-owner to intervene.
No reaction to mouse or keyboard. Very frustrating & time-wasting, inefficient.
Sometime for many minutes, one cannot even get ctrl+alt+f1 to work, or to get >top or >vmstat, or >free to display.
Occasionally, a hard "off" & start again, is the only solution.

This hïatus is accompanied by a great deal of clattering from the live DVD, which seems to be going round in circles (the illogical process, as well as the DVD). Such thrashing would be less apparent with a silent system, installed HDD or flash drive, but I surmise that the same inefficiency would be going on unheard, just that it would be hidden, only manifesting as sluggishness.

Just to discount one set of objections:
Some might say that live editions are not for extended use. This is very true with an improperly conditioned cows filesystem, since it fills up & locks solid, with no way out. However, I see no reason why a live edition should not be fully usable, if slightly slower. If anyone has a good non-bs argument to the contrary, I have yet to hear it.

In some cases
>vmstat, when it can be invoked, shows a fair amount of out-swapping, indicating some resource distress.
This is a clue.

In many cases, if there is an instance of plugin-container, to pkill it will release resources & free up operations.
That's a slightly separate issue, but I do note that it is not simply a case of memory leak un-freed allocation, since even at low plugin- memory levels, the killing of plugin-container still causes release. In fact, it helps to kill plugin-containe even if it is not visible at the head of >top.
Without much hard evidence, I suspect an interlock condition or resource contention.
But this is a subset of the main problem.

What also seems to go on is that as time & usage goes on, Firefox tires & gets more sluggish, almost as if it was written by Windows programmers. That could be the effect of buggy websites, but FF should be resilient to that.
A restart seems to clear the decks. Use of about:memory to CC or GC has little effect, indeed I've known CG to crash the instance of FF after a fair locked-up wait. (More resource contention, and possibly a problem with FF/kernel interfacing.)
A restart should not ideally be necessary.

What also seems to happen, is that unused web-page memory is not swapped out as it might be, but seems to be locked in core. I'm not sure this is absolute.
This may have been done for security/privacy reasons, but it would be a great help if such unused, un-focused memory were not taking up useful RAM.
SUGGESTION--> One might address the privacy/security problem, where swap is allocated, by encrypting the swap.

Conjecture
+++++++++
We know that FF in its memory-hog incarnation grabs all the memory it can.
We hear this is "efficient use of resources", and not theft at all.

SUGGESTION(gripe)--> If it were polite, it would at least ~ask~ at some stage; it might present the beleaguered actual owner of the RAM with an option to limit its memory-grabbing ambitions, to allow the user to decide how much resource to concede.

After all, we the user might wish to have some free memory spare to load some other programmmes alongside, occasionally. Bleachbit, for example. Or top. Or vmstat. Anything.

What I think is happening in the Live case is that FF is not computing the correct measure of available RAM memory.
It is probably detecting that it is over-using RAM, so it packages up some memory to put out of current RAM in to what it believes to be out-swap disc. The problem then with a live edition, the out-swap "disc" is still in another part of RAM, in a virtual filesystem.
Contention.

In addition, some parts of code may be being swapped out, but then required, so the system goes inefficiently hunting on the DVD for the live replacement. It would be interesting to put a monitor on the seek.

If FF had its algorithms right I imagine it could get around this.
But there also need to be resource parameters set to allow relatively unused parts of that pseudo out-swapped virtual filesystem to be properly swapped out to the HDD swapfile.
It's a bit beyond my current expertise (years ago I could have managed it:).

I do hope someone here can look into this seriously, even if you consider it to be an up-stream matter; otherwise I see the buck being passed around for years to come (whilst Chromium takes over the field).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.