Closed Bug 392073 Opened 17 years ago Closed 11 years ago

Firefox limited to 1 CPU on multi-cpu machine; multi-threading appears broken

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 516752

People

(Reporter: mozilla, Unassigned)

References

Details

Attachments

(2 files)

source of 'webpage' that will hang all ff windows/tabs by 1 pages/javacript
(deleted), text/plain
Details
file that will cause hang immediately upon opening w/ff(not commented, will run, so save as text!)
(deleted), text/plain
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

This isn't a new problem, but has come to stand out as a fairly major "booboo" as Firefox has more windows open and has become slower and less responsive.
But firefox seems to be limited to 1 Core on a multi-way machine.  I have a 2Px2Core setup (4 cores).  Firefox's threading is broken in that it is constrained to 1 Core.
Given that cores are increasing in number but CPU GHz is not, this is a "major bug".  While it should be a goal, overall to decrease all resource usages, when it becomes necessary to use more resources, FF should be able to take advantage of *parallel* processing (running on more than one processor at a time).



Reproducible: Always

Steps to Reproduce:
1. ...happens spuriously & often; ... *any* CPU-bound operation
2. 
3.
Actual Results:  
Firefox performance is very bad (lockups 10-20 seconds at a time or more), but FF limited to "exactly" **25%** of my machine's CPU. 
I have a 2Processor x 2 Core machine (4 cores total).
Even though firefox appears to be multithreaded, it doesn't use more than 1 Core at a time.

Expected Results:  
I would expect a program that has multiple "independent" windows open at the same time (independent, meaning unrelated websites, for example).  Firefox should not be limited to 1 CPU.  I have both types of "multi-cpu" available: 2 physical processors in a dual-socket machine, and each socket containing a Core 2 Duo.


Firefox seems unable to take advantage of modern multi-core CPU's.  This is "terrible", since the trend in the recent past (and likely future), has been to drop clock speeds and double, quadruple or octuple CPU's.
While I might have had option to find a 4GHz single CPU (P4), the current mode of expansion is to drop the clock (sometimes by 50%), and add more cores.  Firefox is not taking advantage of multiple cores even though it *appears* to have multiple
threads.
According to ProcessExplorer, my FF process has *27* threads.  Yet all of them seem to be constrained to running on 1 Core.  I currently have Firefox's CPU affinity set to "CPU 0 + CPU 1" (I have cpu's 2 & 3 dedicated to an application which sit's idle when it doesn't have focus).  But affin'ed to 2 or all 4 cores, FF still only uses 1 core (25% of CPU).  This is just "broken".  
I expect FF to use more resources as I open more windows (in separate windows or, even, multiple tabs in each window). 
FF is using a substantial amount of resources (which I'm NOT complaining about in this report), but *refuses* to use more CPU than 25% (1 out 4 Cores).
Other resource usage stats:
memory: Working: 712MB(/721MB peak), Virtual:927MB, Private:734MB(741MB Peak);
Handles: Sys:1104, GDI:1687, USER:1098

---------
There's some discussion about it in bug 40848 and bug 384115. The problem is that most of the GUI runs in a single thread, and is therefor not really scalable. It would be *very* hard to change that. And then I'm not even talking about extensions and plugins.
Thanks for the pointers -- both bugs appear mostly inactive for a few months.
It's amazing the lack of understanding around allowing multiple threads of execution.  But more pertinent.  I don't *think* the GUI would have to become multi-threaded to solve the problem.  

Where I *noticed* the problem the most was after Firefox had been *up* for a few days.  

I usually go to a news site like news.google, news.bbc.co.uk, or reuters.com.  On the main page, I usually look over interesting articles and press "middle mouse (launch URL in background).  I verified it just now -- there is an increasing slowness that parallels time that Firefox remains 'up'.  With a fresh start, I can click several URL's within a few seconds and have them all start coming up in background.  No prob.  But after FF had been up (~a week?) (yeah, this is on XP2), the new-URL launch froze the UI for up to ~7-15 seconds per URL.  Needless to say -- it really slows down launching articles of interest.

So, really, that's one "aspect" that may be completely separate from any multi-threading.  Don't know if it was due to a memory leak or what, but I know it wasn't paging (was only using ~900M out of 3G and wasn't close to limits.

The second aspect, *I believe*, is that the GUI is processing "events" that are tasking "too much time" in processing certain GUI events that *should* be handed off to one or more execution (worker) threads.  It's not like the GUI is displaying anything on the screen.  It should gen tasks and hand them off to a queue.  Events in the Queue could be, *optionally* marked as "execution barriers", meaning no other ops could be running while they are running, but the default should be allowing parallel event execution.  That way, as many as possible parallel events could get the benefit of the new architecture, but those events that "don't play nice" in parallel with other threads could be marked as such.  
    Even more advanced, threads might include "pre-events" that need to be processed before executing a given event and future events could be forced to wait for one or more dependencies.

It floors me that FF can use 26 threads (obviously parts of FF are designed to operate in multiple threads), the *none* of the threads will execute on a separate core.  Very strange...

Over to General for triage and adding dupeme
Component: Shell Integration → General
QA Contact: shell.integration → general
Whiteboard: [DUPEME]
L.A.Walsh, Can you dupe this to bug 277547 or bug 384115?
This bug was reported on Firefox 2.x or older, which is no longer supported and will not be receiving any more updates. I strongly suggest that you update to Firefox 3.6.3 or later, update your plugins (flash, adobe, etc.), and retest in a new profile. If you still see the issue with the updated Firefox, please post here. Otherwise, please close as RESOLVED > WORKSFORME
http://www.mozilla.com
http://support.mozilla.com/kb/Managing+profiles
http://support.mozilla.com/kb/Safe+mode
Whiteboard: [DUPEME] → [closeme 2010-05-25] [DUPEME]
Version: unspecified → 2.0 Branch
No reply, INCOMPLETE. Please retest with Firefox 3.6.x or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
Is this bug still active under another bug number? I've seen this bug using versions 3.6.3, 4.0, etc. I haven't yet fully tested with 5.0, but I should know by the end of the day...
This is still a bug under firefox 3.6.18
Status: RESOLVED → UNCONFIRMED
OS: Windows XP → Windows 7
Hardware: x86 → x86_64
Resolution: INCOMPLETE → ---
Whiteboard: [closeme 2010-05-25] [DUPEME]
Version: 2.0 Branch → 3.6 Branch
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago → 13 years ago
Resolution: --- → DUPLICATE
This is not a duplicate of a meta-bug about future architecture.

If there's a bad use of OS threading system calls, identify and fix. Cc'ing Rob Arnold in case he can comment.

/be
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
brandan...so I see....

I was responding/acting in response to:
--
Comment 4 Wayne Mery (:wsmwk) 2009-03-17 03:22:40 PDT

L.A.Walsh, Can you dupe this to bug 277547 or bug 384115?

---
bug 277547 didn't apply, and 384115 looked closer, so I chose it.

Sorry, I shouldn't have blindly followed instructions.
Guess I opened 1 too many windows -- anyway FF hung, non-responsive for over 15 minutes -- enough time to copy down the stack traces of all the busy modules
and their usage percent:

module/prog         (cpu usage)
firefox.exe+0x1840  (99.76) 
ntoskrnl.exe!memset+0x64a
ntoskrnl.exe!KeWaitForMultipleObjects+0xd52
ntoskrnl.exe!KeWaitForSingleObject+0x19f
ntoskrnl.exe!__misaligned_access+0xba4
ntoskrnl.exe!__misaligned_access+0x1821
ntoskrnl.exe!KiCheckForKernelApcDelivery+0x25
ntoskrnl.exe!MmGetSystemRoutineAddress+0x2be78
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
ntdll.dll!NtAllocateVirtualMemory+0xa
wow64.dll!Wow64EmulateAtlThunk+0x2a45
wow64.dll!Wow64SystemServiceEx+0xd7
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!LdrpInitializeProcess+0x17e4
ntdll.dll!??_C@_0BN@KLOBBEB@Enabling?5heap?5debug?5options?6?$AA@FNODOBFM@+0x29220
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtAllocateVirtualMemory+0x12
KERNELBASE.dll!VirtualAlloc+0x18
MOZCRT19.dll!@_realloc_crt@8+0xcf4
MOZCRT19.dll!_expand+0xfd9
MOZCRT19.dll!_expand+0x158f
MOZCRT19.dll!malloc+0x53
xul.dll!?ForEachFontInternal@gfxFontGroup@@IAEHABVnsAString_internal@@ABVnsACString_internal@@HHP6AH01PAX@Z2@Z+0x537b
xul.dll!?ForEachFontInternal@gfxFontGroup@@IAEHABVnsAString_internal@@ABVnsACString_internal@@HHP6AH01PAX@Z2@Z+0x5ca2
xul.dll!?InitTextRunUniscribe@gfxWindowsFontGroup@@IAEXPAVgfxContext@@PAVgfxTextRun@@PBGI@Z+0xd56
MOZCRT19.dll!_initptd+0x1b3
MOZCRT19.dll!_errno+0x5
-----
Other busy threads:

sapi.dll!UnregisterServer+0x8c79f (m=million) 
	(3total using  1%, .12%, and 1 <.06%: or (183m, 25m, .125m) Δcycles, 
ntoskrnl.exe!memset+0x64a
ntoskrnl.exe!KeWaitForMultipleObjects+0xd52
ntoskrnl.exe!KeWaitForSingleObject+0x19f
ntoskrnl.exe!__misaligned_access+0xba4
ntoskrnl.exe!__misaligned_access+0x1821
ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d
ntoskrnl.exe!KeWaitForMultipleObjects+0x26a
ntoskrnl.exe!NtWaitForSingleObject+0x40f
ntoskrnl.exe!IoReportTargetDeviceChange+0xe61
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0xf5
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!??_C@_0BN@KLOBBEB@Enabling?5heap?5debug?5options?6?$AA@FNODOBFM@+0x29364
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForMultipleObjects+0x15
kernel32.dll!WaitForMultipleObjectsEx+0x8e
sapi.dll!DllUnregisterServer+0x1545c
sapi.dll!DllUnregisterServer+0x65134
sapi.dll!DllUnregisterServer+0x8c774
sapi.dll!DllUnregisterServer+0x8c815
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36
-----------------  another busy one...

MOZCRT19.dll!_endthreadex+0xa0
ntoskrnl.exe!memset+0x64a
ntoskrnl.exe!KeWaitForMultipleObjects+0xd52
ntoskrnl.exe!KeWaitForSingleObject+0x19f
ntoskrnl.exe!__misaligned_access+0xba4
ntoskrnl.exe!__misaligned_access+0x1821
ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d
ntoskrnl.exe!KeWaitForSingleObject+0x19f
ntoskrnl.exe!NtWaitForSingleObject+0xde
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!??_C@_0BN@KLOBBEB@Enabling?5heap?5debug?5options?6?$AA@FNODOBFM@+0x29364firefox.exe+0x1840  (99.76)
ntoskrnl.exe!memset+0x64a
ntoskrnl.exe!KeWaitForMultipleObjects+0xd52
ntoskrnl.exe!KeWaitForSingleObject+0x19f
ntoskrnl.exe!__misaligned_access+0xba4
ntoskrnl.exe!__misaligned_access+0x1821
ntoskrnl.exe!KiCheckForKernelApcDelivery+0x25
ntoskrnl.exe!MmGetSystemRoutineAddress+0x2be78
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
ntdll.dll!NtAllocateVirtualMemory+0xa
wow64.dll!Wow64EmulateAtlThunk+0x2a45
wow64.dll!Wow64SystemServiceEx+0xd7
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!LdrpInitializeProcess+0x17e4
ntdll.dll!??_C@_0BN@KLOBBEB@Enabling?5heap?5debug?5options?6?$AA@FNODOBFM@+0x29220
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtAllocateVirtualMemory+0x12
KERNELBASE.dll!VirtualAlloc+0x18
MOZCRT19.dll!@_realloc_crt@8+0xcf4
MOZCRT19.dll!_expand+0xfd9
MOZCRT19.dll!_expand+0x158f
MOZCRT19.dll!malloc+0x53
xul.dll!?ForEachFontInternal@gfxFontGroup@@IAEHABVnsAString_internal@@ABVnsACString_internal@@HHP6AH01PAX@Z2@Z+0x537b
xul.dll!?ForEachFontInternal@gfxFontGroup@@IAEHABVnsAString_internal@@ABVnsACString_internal@@HHP6AH01PAX@Z2@Z+0x5ca2
xul.dll!?InitTextRunUniscribe@gfxWindowsFontGroup@@IAEXPAVgfxContext@@PAVgfxTextRun@@PBGI@Z+0xd56
MOZCRT19.dll!_initptd+0x1b3
MOZCRT19.dll!_errno+0x5
-----
sapi.dll!UnregisterServer+0x8c79f (m=million) 
	(3total using  1%, .12%, and 1 <.06%: or (183m, 25m, .125m) Δcycles, 
ntoskrnl.exe!memset+0x64a
ntoskrnl.exe!KeWaitForMultipleObjects+0xd52
ntoskrnl.exe!KeWaitForSingleObject+0x19f
ntoskrnl.exe!__misaligned_access+0xba4
ntoskrnl.exe!__misaligned_access+0x1821
ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d
ntoskrnl.exe!KeWaitForMultipleObjects+0x26a
ntoskrnl.exe!NtWaitForSingleObject+0x40f
ntoskrnl.exe!IoReportTargetDeviceChange+0xe61
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0xf5
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!??_C@_0BN@KLOBBEB@Enabling?5heap?5debug?5options?6?$AA@FNODOBFM@+0x29364
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForMultipleObjects+0x15
kernel32.dll!WaitForMultipleObjectsEx+0x8e
sapi.dll!DllUnregisterServer+0x1545c
sapi.dll!DllUnregisterServer+0x65134
sapi.dll!DllUnregisterServer+0x8c774
sapi.dll!DllUnregisterServer+0x8c815
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36
-----------------


MOZCRT19.dll!_endthreadex+0xa0
ntoskrnl.exe!memset+0x64a
ntoskrnl.exe!KeWaitForMultipleObjects+0xd52
ntoskrnl.exe!KeWaitForSingleObject+0x19f
ntoskrnl.exe!__misaligned_access+0xba4
ntoskrnl.exe!__misaligned_access+0x1821
ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d
ntoskrnl.exe!KeWaitForSingleObject+0x19f
ntoskrnl.exe!NtWaitForSingleObject+0xde
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!??_C@_0BN@KLOBBEB@Enabling?5heap?5debug?5options?6?$AA@FNODOBFM@+0x29364
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
kernel32.dll!WaitForSingleObjectEx+0x43
kernel32.dll!WaitForSingleObject+0x12
xul.dll!?GetTextUnicode@gfxTextRun@@QBEPBGXZ+0x1bac
xul.dll!NS_Realloc_P+0xfe8
xul.dll!?ShrinkToLigatureBoundaries@gfxTextRun@@AAEXPAI0@Z+0x1838
xul.dll!XRE_main+0xda2f
MOZCRT19.dll!_endthreadex+0x78
MOZCRT19.dll!_endthreadex+0x106
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36
----
+ 2 more running sapi threads @ same addr (but not displayed)
Forgot to mention -- in above hang case, no windows were responsive.

Had to kill process.
The stack trace from comment 12 looks like (if I had to take a wild stab), the kernel running some APC (deferred function call) related to the Firefox process. Second guess is a corrupted stack (hint is the misaligned_access with largish offsets and the stack starting at _errno+0x5) but it doesn't seem likely. EIther way, not clear how it's related to the original report so please file a new bug on that if you can reproduce it again.

Now back to the original issue. A few things:
1) In 3.6.4+, plugins now run in their own process which gives some scaling to multi cores so you should see some of that (look for CPU usage in plugin-container.exe)
2) There's been a lot of work in Firefox 4+ to make use of more cores. Does this problem still occur if you upgrade?
3) There appear to be no calls to set the process or thread affinity in the Firefox source according to mxr so if that is the problem (can be verified with Process Explorer or the task manager I believe) either you've inherited this from the environment in which you launch Firefox or some 3rd party addon (extension, plugin, external program, etc...) is setting it.
Short version
1) stack trace is showing stack trace of FF suffering from an extreme example of the base problem  -- by I was refreshing a complex webpage, with about 30-40 other tabs open in multiple windows.

The current webpage froze, nothing else was runnable though 5 cores were free.

FF is not limited to 1 core, it has 6 cores to exec on.

The mis-aligned access is "normal behavior" for 32bit FF running on Win7-64 (normal doesn't imply "desired").



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

Longer version:


The traces show the stacks of the active threads in FF where 1 window's javascript or rendering is blocking all other windows/threads;  It is also the case, that all of the busy threads are only running on 1 CPU/CORE.

The stack trace is an instance where a hang or javascript loop in 1 window will freeze all the windows.

If the javascript in each window was in it's own separately scheduled thread, and the GUI was in it's own thread, it then javascript running amok wouldn't stop the GUI.

As far as the thread / process affinity  --

when I inspect FF, it has available to it, all 6 Cores.
(I regularly use process explorer to manage core usage duing AV playback but FF always has 6 cores available to it -- it just never uses more than 16.66% of the system's CPU resource (i.e. 100% of 1 CORE).  It was the same when I first filed this bug and had a 2-cpu SMP, (pre-core era), FF was limited to '50%' of the cpu resources at the time.

So if a javascript object, like the one used on this page runs,

     http://www.bucksch.org/1/misc/freeze-me.html  (going to add source to 
an attachment to this bug, as I don't know if that website will stick around forever...); its shorter than this comment (I know, it's pathetic, sorry!)

in 1 tab, then all tabs in all windows lock up, because that 1 javascript object
is 'hogging the cpu', and FF isn't scheduling other tasks (like rendering/doing javascript in other tabs/windows, or responding to the UI) to run on alternate CPUs/Cores...  

It isn't (and, for me, has never been, the plugins that have caused problems, as I don't generally use active plugin's in multiple windows or tabs -- i.e. maybe main window, playing a video, but I'm not going to intentionally play a video or music or do anything else likely to require a plugin in other than the active window.  Putting them in in their own process only decreased stability.

Upgrading isn't an option at this point.  I've tried, it was bad.  I tried to upgrade to FF5 (4 doesn't seem to be around anymore, (was only available for a few months, no?)  and couldn't type anything into the address bar. Nada-zilch...  I could click on things, and open menus, but the address bar, while visible, would accept no input from the keyboard -- I could select text with the mouse, but that was about it.

Anyway, it was really only a test to see if it would work 'better' than my 3.6.x, as it didn't, given the cost in lost extensions (I had about 130 at one point maybe a year ago, when everything played nice together, but am now down to under 100, that still work, if I jumped to 4 or 5, that would halve, I'm sure.  Many people are put-off by all the version bumping and trying to keep extensions up-to-date.  Many extensions are being updated, but the lesser 'corner case ones'...sometimes the devel isn't even around anymore.

I originally reported this bug originally against 2.x.  
Almost 3 years after I reported it, I was told: (2010-05-05)
   "This bug was reported on Firefox 2.x or older, which is no 
    longer supported and will not be receiving any more updates. 
    I strongly suggest that you update to Firefox 3.6.3 or later...."

of course, I wasn't looking for replies to this bug 3 years later, 
which ended up in a bug-archive folder, so 12 days later, it was closed as incomplete.

I did see the email from BIGDOG on 2011-07-27 and that prompted me to reply
to the bug that it was still a problem in the current 3.6 release (that I'd 
been asked to test earlier)... so, I updated this bug to be relevant to the current version -- which is where the stack trace came from.  I.e. stack trace was given during a FF hang on 1 webpage rendering, and appeared to be an example of the the originally reported bug.


As for the 'mis-asligned_access' -- that's what you get when you run a 32 bit
version on a 64-bit machine!  Those mis-aligned messages are on ALL FF procs.

I do have current Win7-SP1 symbols loaded that are used to parse those addrs.
FYI, here's a stack trace from 64-bit FF on windows:

No misaligned accesses -- there's a reason why 32-bit windows is 15% slower than 64-bit on 64-bit machines...since you'd never seen the misaligned
accesses before, perhaps you've been running either 64bit on 64 or 32 on 32-bit?

To run 64-bit I have to go back to FF 3.6.3 -- the last version in the 3.6 series made available -- got taken to the welcome page on mozilla.org for
fresh installs, where it promptly said I could 'upgrade' [sic], to a 32-bit 5.x version.

Um, offering a 32-bit version as an upgrade to a 64-bit version is probably not a great idea... 

Stack:

ntoskrnl.exe!memset+0x64a
ntoskrnl.exe!KeWaitForMultipleObjects+0xd52
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!_misaligned_access+0xba4
ntoskrnl.exe!_misaligned_access+0x1821
ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d
ntoskrnl.exe!KeWaitForMutexObject+0x19f
win32k.sys!memset+0x7ac7
win32k.sys!memset+0x7b69
win32k.sys!W32pArgumentTable+0xa68a
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
USER32.dll!ZwUserWaitMessage+0xa
xul.dll!gfxPDFSurface::operator=+0x27a23
xul.dll!gfxPDFSurface::operator=+0x273e1
xul.dll!gfxPDFSurface::operator=+0x276f8
xul.dll!NS_ShutdownXPCOM_P+0x2473
xul.dll!NS_DebugBreak_P+0x2794
xul.dll!gfxPDFSurface::operator=+0x27426
xul.dll!gfxPlatform::UpdateFontList+0x24217
xul.dll!XRE_main+0x13a3
firefox.exe+0x1404
firefox.exe+0x1590
firefox.exe+0x1790
kernel32.dll!BaseThreadInitThunk+0xd
ntdll.dll!RtlUserThreadStart+0x1d

Also, BTW, I just tried opening several windows simultaneously -- FF-64bit never went over 4-5% cpu usage. (24-30% of 1 core).   Now if only 3.6.24 was in 64-bit...
lol welcome to my world...

Mozilla really stuck their thumbs up their butts w/FF5.x and their new website design...
Big dog, please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html.

Walsh, just so you know, Firefox x64 never got officially released. there are nightly versions of it, never any official x64 release
I apologize, Ty...I just didn't realize before I submitted my help request that nobody at Mozilla Support responds to Anything....EVER...but I know that's not your guys' responsibility, and I shouldn't discuss it here. :-)
Tyleer -- was unfortunately aware of the 64-bit support being for all platforms except windows...why is that?  It's been available on linux for years, and is available on the Mac, but not windows.  I don't need plugins as much as extension compatibility with 3.6.x -- everything you guys have done in the GUI in 4.0, 5.0 and are planning in future versions -- I already *can* have (and sometimes do, on a whim!), due to the extensions in 3.6.x

I wish you guys hadn't been 'followers' and followed the google market in bumping up versions faster than makes any logical sense, but this is a market driven world, and if those in charge perceived value...well, so it was.

Stable extension API's an large numbers of extensions are my primary reason for using FF -- take those away, might as well use Chrome.

I really whish you'd put the 4.x and 5.x improvements in a 3.7 and/or 3.8...that could have remained (possibly) with more compat for existing extensions.

I'd even, if I was a designer, choose 'namespaces' like the DTD defs at the top of HTML docs, to describe the feature set I want to use.  Then the same binary
could support extensions from multiple versions.

Make each thunking layer a .so/.dll, that an be loaded as needed at runtime.

Then you get best of all worlds.


Anyway, I installed the x64 to demonstrate what a proper stack looks like on a 64-bit machine -- but the "corrupt" looking stack (as it was described by someone else), is the normal way FF-32 bit looks.
Walsh, you do realize that if an extension is not labeled compatible for anything over 3.6 is will break even if the next version is 3.8? you can always disable compatibility checking, or encourage your addon developers to update their extensions. Now AMO is working automatically updating extensions to make them marked compatible with future releases, but that is beyond what this bug is even about, as is the 64 bit issue. please, keep this bug on focus.
True, I I just installed the x64 version to see what the stack looked like.

It is installed using the same profile as the x86 version, so has the same extensions.

A fresh instance of firefox:

Only 2 misaligns (been three on every other check...)...it's a 'feature' of
win32-ff - that was my point -- not that it's a sign of a some other problem.


ntoskrnl.exe!memset+0x64a
ntoskrnl.exe!KeWaitForMultipleObjects+0xd52
ntoskrnl.exe!KeWaitForSingleObject+0x19f
ntoskrnl.exe!__misaligned_access+0xba4
ntoskrnl.exe!__misaligned_access+0x1821
ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d
ntoskrnl.exe!KeWaitForSingleObject+0x19f
win32k.sys!memset+0x7ac7
win32k.sys!memset+0x7b69
win32k.sys!W32pArgumentTable+0xa68a
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x676
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!LdrpInitializeProcess+0x17e4
ntdll.dll!??_C@_0BN@KLOBBEB@Enabling?5heap?5debug?5options?6?$AA@FNODOBFM@+0x29220
ntdll.dll!LdrInitializeThunk+0xe
USER32.dll!WaitMessage+0x15
xul.dll!?GetUnderlineOffset@gfxWindowsFontGroup@@UAENXZ+0x97a0
USER32.dll!UnhookWinEvent+0x1b4
I cannot tell if you are trying to report what the title of the bug says or that Firefox hangs. If the later, then this bug should be closed and you should file a new issue. Looking at the stacks, it's not clear what's going on. If you can't reproduce it on 5.0, I honestly wouldn't expect it to be fixed.

I'll address a few things but most of the discussion seems to have been off-topic (like the version numbering change and extension compatibility challenges).

You won't see each window's JS running in its own thread until well into the electrolysis project. It's an inherently huge design flaw in the browser that has been taken years to come up with a viable solution for. Extensions are actually part of the problem. Firefox 4+ splits some tasks (like HTML parsing) out into their own thread. You still haven't checked for me if the process or set of threads is being limited to a single core by some 3rd party. Besides using the task manager's process view (confusingly enough, right click on a process and select "set affinity"), another way to check is to go to the performance tab and see if only one core is being hit. Windows' scheduler likes to use all cores roughly evenly so if there's an artificial affinity being set, then it should be clear from these graphs. A third but unlikely possibility is that someone is setting an affinity on each thread that's created. I don't know of a good way to detect this.

The reason 64 bit Windows builds aren't built/distributed (yet - it is coming) is primarily due to the lack of plugin support. 32 bit plugins don't work with 64 bit Firefox and 64 bit plugins aren't made because no one on Windows uses a 64 bit browser (even IE defaults to 32 bits). This is important for a number of users, but seemingly not you. The speedup you see is likely due to the architecture differences between x86 and x86-64.
I was reporting that FF seems to be limited to 1 cpu so if it becomes blocked due to a run-away process, other windows /tabs will be unresponsive.

It is when the 1 CPU the FF users is under load that the problem is most noticeable.  

Design flaw was noted in 2007.   It wasn't responded to for almost 2 years.

As for the processes being limited -- I said FF has all 6 cores available -- it isn't being limited to any subset.  In ProcExp, I am only able to view or set cpu priorities attached to the process.  I don't know if this a because there is no 'per-thread' mask, or just a feature-deficit in ProcExp.

No 3rd party app is limiting the process to a subset.  As for individual threads -- I am unable to view separate settings for each thread, but I'd guess whether or not an APP is multi-core enabled, has to do with some flag set in the binary (just like a flag was needed for 'large address aware' (bugurl:  https://bugzilla.mozilla.org/show_bug.cgi?id=556382 ).  Without explicitly enabling 'full resource usage', MS defaulted to 'safe mode', with the onus being on app-devs to know how to hack win-binaries (often undocumented!).

The only graphs available are the multi-cpu graphs for all process -- and they are all used.  But having them all used doesn't mean a program is scheduled for use on any single processor at the same time as another (i.e. parallel execution).  There's nothing preventing the task scheduler from running all FF's threads on each CPU, in turn.  But switching CPU's doesn't imply using more than 1 cpu  at a time.   I do see FF bounding from core to core -- like most processes.   But I never see it using more than 100% of 1 cpu at any point in time.   That indicates that as a process, it is not constrained, but at the thread level, the threads are constrained to run on 1 cpu at a time.

The real test for 5.0 -- can you enable javascript, and go to  http://www.bucksch.org/1/misc/freeze-me.html  , and run the tests and switch to other tabs and open webpages 'normally?   If not, then there's your test case.

(source is in an attachment of this bug in case the website goes away).  The autor shows 2 ways to to cause the problem where a javascript on 1 page, hangs the entire browser.

As for the 64-bit/x86, My IE brings up the 64 bit by default (I configured it that way).  I don't use it for media playback, so never had an issue with compat.  I have both 64 and 32 bit IE -- and if I need compat, I can run the 32 bit version.  The same could be done w/FF.
There is no multi-core flag for binaries as far as I'm aware. Note that not using more than 100% of a CPU's worth of CPU usage does not mean that Firefox isn't multithreaded. Firefox often uses threads to do long operations (usually IO) to avoid blocking the main thread. These threads typically block for a long time, wake up for a bit to post a message to another thread, and then go back to sleep. They do not show up very much on CPU profiles.

It sounds like what you really want is the electrolysis project to happen so that one page cannot kill the responsiveness of the browser. I'm going to dupe this bug against that.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → DUPLICATE
You're welcome L A. ;-) Always happy to keep testers busy. ^_^

So I'm not quite caught up on all the stack tracing tools and such for providing useful bug-finding data for windows, but...it may not matter. I noticed in my [brief] time using 5.0.1 that it actually did climb above 25% usage, for the first time ever.
That I've seen.
I'm attempting to tax my 5.0 FF on my work machine to see if it does the same, but so far I haven't seen it above 25%. I'm not touching 5.0.1 with a 39-and-a-half foot pole...perhaps I'll wait til FF6 is released, which is supposedly not as far off as I previously thought...
This is a variant of the previous freezme test that runs automatically w/out
user interaction.

To demonstrate FF inability to multitask, save it to a file, then close all your work in 'firefox', heck, close ff, 

Now click on the file you saved to open in ff, -- open it rapidly in succession
at least 2-4 times -- the idea being to get 2 or more copies running in separate tabs.


I've no idea the efficiency of those loops, but I did put an upper bound of 1mill on the loops, but you'll likely have to kill your browser to stop it.

BUT -- note -- while there are 'N' tabs or windows (if you don't have redirect new window to tab selected, you'll get separate wins), and they are all executing javascript programs in their own separate spaces,

only 1 CPU gets used.

This isn't related to the UI interaction that this bug had been dupped off to, though it also causes that.
Not a duplicate of electrolysis, since the whole problem was people wanted proof that multiply competing tabs didn't run on more than one core.

I attached a new attachment that I used to duplicate the problem.

You open multiple tabs each with an instance of the 'bad program', -- 

They are all demanding 100% cpu, but ff as a whole only uses 16% (1/6 cores) cpu.

It DOESN'T use multiple processors or cores -- which was the point of the original bug filed over 4 years ago..

It's not like I have been 'impatient' but this bug has been buried for years, and now people are trying to dup it off to something other than what it is.

Yes, it may required restructuring FF and fixing things that never should have
been designed that way in the first place, but back during initial creation, muliple cpu machines weren't plentiful.


It may be that it would be hard.  'I agree!  But if it work had started 4 years ago, and done a bit at a time, I bet you it'd be done or close to it by now.  I.e. saying it is hard as a reason to do nothing about it solves nothing.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
OS: Windows 7 → All
Hardware: x86_64 → All
LAWalsh, do not reopen this bug. Engineers have already said that the only way to fix this (and many other similar problems) is with content processes, which is what this bug was dupped to. Your continued harassment in the bug will not make anything better.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → DUPLICATE
I just tested this with 4.0 on linux -- same problem

Multiple tabs -- all competing for 100% cpu --

yet ff only using 1 out of 8 cpus.

Changing version to 'trunk', and affected cpu's/archs to all/all.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Version: 3.6 Branch → Trunk
Sorry, I missed your comment....from the description,
electrolysis project is about improving UI responsiveness when progs are
causing a slowdown.


That could be solved many different ways than by utilizing multiple cores.

I.e. That's not about multi-core/multi-cpu usage. -- IT MIGHT be addressed that
way, but from the project description, it's not _necessarily_ about that.

If my understanding is wrong, then fine, I'll redup it.   But the project description of that bug should be made more clear that it's about utilizing multi-cores -- which as a side effect, could improve UI responsiveness.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → DUPLICATE
(In reply to comment #30)
> LAWalsh, do not reopen this bug. Engineers have already said that the only
> way to fix this (and many other similar problems) is with content processes,
> which is what this bug was dupped to. Your continued harassment in the bug
> will not make anything better.
----
My 'continued' harassment?!   

This bug was filed 4 years ago, I responded witha  thank you to a pointer 4 years ago... then I "harassed them to death for the next 3yrs 11 months, by not following up on the bug, and by not asking for status -- but letting it be.   Then I was asked to dup it to a bug that wasn't the place to dup it to.

Now it's been duped to the descendant of the bug that I was told this WASN'T a duplicate of, and that it was wrong to dup it to.

If it wasn't the same bug as the bug I first (following instructions), duped it to, then why is it the same bug as the successor to the successor of that bug -- which was created 2 years after this bug, and has had no activity on it for 2 years.

I'm defending the fact that the bug isn't fix.  That's all, but 'harrassment'?!
Oh poor 'whoever', that I should assert that a bug that existed and was reported 4 years ago still exists and ISn't just about US responsiveness.

That I should claim that FF doesn't run javascripts in separate windows, in separately scheduled threads, then be disputed and told that FF indeed runs multiple threads on separate CPU's, and then I display a test case, that shows it doesn't on Windows OR on linux (when I was told that linux didn't have this 1-cpu usage problem)...


That's harassment?   After 4 years, of patiently waiting for any response?

Sorry, but it is you who are harassing me to close out this bug for some reason -- even though it is valid.   Now it's been parked on a 2-yr/o metabug that has has no activity.

I resent your invalid and provably false accusations.   I've been very patient -- I had bugs closed out recently 'en masse', going back to 2002, because I didn't check what was an inactive bug-folder every week or month (when it hadn't seen activity for years on most of the bugs)....  

You really need to think about how it sucks to report bugs that are ignored for years, then duped to inactive 'parking places' [meta bugs that people are told not to comment in] in order, it seems to simply close as many bugs as possible without actually fixing anything.

By duping this bug into that bug, you are inviting comment on this problem into that bug.

The slightest insensitive remark in another bug had them complain that the entire bug was ruined and close it out as invalid -- also after 4 years -- like someone was looking for any reason to close out that bug too.

Besides, calling something a metabug as a way to have it take precedence over a
a 2 year older, and more severe real bug, is, IMO, shady, at best.

Have it your way, I'll add comments to that bug, *if necessary*, to clarify that that bug is about executing different window's/tabs's  javascript tasks on different cpu's (this bug was filed before multi-core, which is why it says 'CPU')...

This bug isn't a duplicate of  electrolysis... it might be addressed by some later stage of electrolysis, but that doesn't mean the bug is a duplicate

This bug should remain open and have a dependency on electrolysis -- if that is the fix.  But given that the stage that will fix THIS bug is last on the schedule and the schedule appears to be delayed by over a year, It seems unethical to simply close out this bug as a dup of a project that may eventually solve it -- but is no where near close to doing so.
Depends on: electrolysis
The same problem with FF 11, Win 7 x64.
FF uses only 25% of CPU.
Oh that's just wonderful... I'm pretty sure this doesn't happen on linux.

Maybe it's an artifact of the windows scheduler and using threads?  

Maybe it's another example of windows being fundamentally flawed?... 

Other progs with thread run on multi-cpu/cores, why not ff?
How can this be considered resolved!?  I'd just like to say that if it was not for this "Bug" I would still be using Firefox.  In fact I still test it from time to time during a new version roll-out to see if you guys got with the program!  I switched to Chrome 2+ years ago for the simple fact that I am a power user and need a multi-threaded browser.  If I open 10 tabs in firefox, and several of them are cpu intensive, the whole browser can hang, and may need to be killed if any one of those tabs locks up.  I could have something important in tab A, and when tab B locks up, oh well, it's lost.  It's unacceptable at this stage.  In Chrome, under the same situation the guilty tab becomes unresponsive and can be closed with the 'X' leaving the other tabs (processes) unaffected.  This separation of processing is becoming more and more critical as websites become more complex, competing for resources, with the potential of a bug or error.  

May I propose a solution, run each tab in it's own process, let the OS handle the rest... 

BTW This has nothing to do with the OS, it's a fundamental flaw of the application.  This should be escalated from bug to fundamental software design flaw.
I have to agree with the last comment.  

Still with nothing done on this bug... I guess I'll have to increase my
"harassment[sic]" .. and re-open this bug -- over a year after my last comment.

It MAY be true that electrolysis (the bug this one was "dup'ed" to) might solve this issue, but it's so vaguely defined, that any progress made on that "bug" is invisible.

That presents its own problem in that if someone was to work on a bug that renders work on itself as invisible, then the person working on that would be seen as wasting their time and not doing anything productive.  

This is a bug.  electrolysis is a vague project effort (it claimed), that seems to have no traction to get anything done, but is still being used as a park space for real bugs.

I don't see that keeping this bug as a duplicate of a project that has no indication of any progress since this bug was dup'ed to it,  as a wise nor ethical to support.

Of most importance in examining whether or not this is a "duplicate" of another bug -- is to look at the bug numbers, as they sequentially rise over time.  So if a bug has a lower bugid than another, the one with the lower bug id cannot be a duplicate of the latter as 2nd bug didn't exist when this one was filed.  In deed -- this one was filed 5 years ago in 2007.  The other "bug" didn't even exist until 2 years later.

It's also the case that the "bug" this one was closed as a dup of, isn't really a bug,
but describes itself as a "metabug" or placeholder for information about a some theoretical project that was thought of to solve this problem -- but one that seems
to have stalled.  Regardless, as it's about a project, and not about this problem.

To perhaps make things more clear -- the focus of this bug should not be whether or not FF has processes running on more than one core -- but on the fact that there seems to only be 1 dispatch point for all windows and tabs that can be blocked by any tab that "misbehaves". 

In a way, this is like like Windows 3 (pre-win95) technology, where you could multi-task if the various tasks all cooperated and call yield frequently and no process or task ever holds on to the cpu.   That model didn't work very well.  

On linux, you can build for servers, where it's ok to have poor response time, if it benefits overall throughput -- and if a job that needs to be done "hogs" resources (like the cpu), its ok, as the server is a unified "whole" -- this might work for a server that is dedicated to only a few tasks (like a database server).  

A second option is to build for "cooperative", unified content (like official programs in an office suite for a desktop package, where all are known to work well in yielding resource control). the equivalent in a web-client would be a client that is optimized to work with 1 company's internal websites that all follow an internal standard (and are known to behave well).

A third option is to build for interactive usage -- where it's not ok for the kernel to stop paying attention to various tasks because one task is poorly written or wants to hog all of the resources.   That's the fully preemptible kernel that's needed for real-life -- where you aren't just using the kernel for development, but also are using it to play music or video's serve webpages, email, etc -- and you don't want any misbehaving program to bring everything else to a halt.

That's how the browser needs to be built -- it can't allow the javascript or flash on one site to hot resources to the point that the browser stops listening to the user (browser is not responding messages) -- popups from the OS telling you that the program is not being responsive to ANYTHING and asking you if you want to terminate it.

Unfortunately, FF isn't designed that way -- and forced the activity -- javascript execution or rendering (or both), all through 1 "resource" -- and whichever window (running in the background or foreground), grabs that resource can and does block every other window -- the fact that they are done sequentially guarantees that none of the work can be done in parallel using multiple cores.

This has been a design flaw for over 5 years now -- and instead of fixing it, or spending time on it -- work to pump-up Version ID's and greater ease to synchronize multiple devices with FF settings has been given priority.   I'm sure those features had proponents and benefits, but this bug really should have been addressed first -- as if it had been done, the coordinating multiple copies of FF coming from different devices would have been been solved as part of solving this.  

I.e. having the browser be object oriented and multi-threaded would make adding different -clients accessing a common-ff-dataset, that much easier.

Anyway, I think this bug should remain open and separate -- as fixing this bug would
have solved or laid framework for easy solutions for not only the electrolysis project but other projects as well.

Please don't close this out or mark it as a duplicate until the problem describe by this bug is addressed.  

Note, the other bug is listed as 'blocking' this bug, so they are still tied in that
sense.   But it's a project, not a bug -- and its completion may "unblock" and fix not just this bug but others as well (that were not listed as being blocked by the work that project was supposed to solve.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I just experienced this:
Tab 1: 
https://www.youtube.com/watch?v=eYJhFvoNdJI
Tab 2: 
http://underthepianostool.blogspot.com.es/2010/12/arthur-rubinstein-master-class-chopin.html
On tab 2, Av Pag (scroll down).
Before tab 2 scrolled, the audio of the tab 1 was interrupted.

Mozilla please.

My 4 cores for what? 3 are ROFLing while the other one dies.

Full specs: Intel Core i5-480M, 4 GB RAM, Linux 3.2.0-27-generic-pae, Lubuntu 12.04 fully updated, Firefox 17.0 (Beta). Even I have AdBlock Plus. Without it could have been even worse.

Making a conservative prediction, in 2 years from now, mainstream will be: phones with 4 cores, laptops with 8 cores, desktops with 16 cores, users spending 80% of their time on the web.

Without multicore support, what will Firefox be in that scenario? A friendly browser for low-end phones, at most. Then Firefox and by extension Mozilla will become irrelevant for the web.

Please Mozilla and Firefox team: Set up a realistic plan to fix this bug before 2015.
spec: win xp 32-bit, intel i5

Can't believe this problem still exists in 2012.
Please fix it before the world ends! :)
Dear developing team. This issue prevents me to use Firefox even I would really like to continue to use it. I was using Firefox for years when I had single-core PC or notebooks. Since I got 4 core PC I had to switch to google chrome, just because of speed (and responsibility - it uses all my 4 cores) even it lack functionality that i was using in FF (tree style tab) and uses much more memory.

For me this issue is most important and until it will be fixed the chrome will be better choice for me even with missing functionality and other drawbacks. I thing it is the same for many other power users - the ones that influence the others. Please fix this issue before all the users switch to google chrome.
All add my discontent to this as well.

All 3 of my PC's from dual to quad core, as well as any PC repair I have done.
I don't see the exact same thing.  Instead of 1 core at 100%, I get 3 cores at 50%.

Linux version 3.2.0-34-generic (Kubuntu)
Firefox for Ubuntu 17.0.1
AMD FX-6100 Six-Core Processor (3.3GHz)

I created a gratuitously festive holiday-themed Easter Egg for my website (falling snow animations, flying reindeer, flashing lights, etc), which makes heavy use of CSS & JavaScript animations.

When I load it on my 6-core machine, *3* of the CPUs jump up to 30-50% usage, and the animations all run smoothly.

But the odd thing is, if I load a couple more instances of the same page in other Firefox windows, the same 3 CPU cores still run at %40-%50, but the animation starts to get a little choppy. If I load a YouTube video on top of that, the CPU usage doesn't change (no core ever goes above 50%), and everything runs slower still, and the YouTube video runs at less than 1 fps. 

So it does appear to multi-thread a little, but not enough.

For comparison, Chrome limits each *tab* to one CPU (so each instance of my animation page will consume 100% of one of the cores). But 100% isn't enough, and the animation runs a little choppy, even with only 1 instance running (where Firefox runs perfectly with one instance, since it is partially using 3 cores)

But Chrome is apparently already working on this... there is an experimental feature called "Threaded compositing" under "chrome://flags". With this option enabled my instances eat up as much CPU time as they can get a hold of (3 instances cause all 6 cores to do some work, each at 30-100%). FireFox needs something similar.
(In reply to cschuler from comment #43)
> When I load it on my 6-core machine, *3* of the CPUs jump up to 30-50%
> usage, and the animations all run smoothly.

Firefox actually runs in a lot of threads, which is why it all balances across the cores, but there seems to be some global locking which prevents those independent thread from running concurrently.
Actually, I haven't read all of the commentary, but.. seems to me that the most common time this happens, for me, is if I go to a site, or have others loading in the background, and one, or more of them, run into a case of trying to load animated gifs. It might be the case with other large files, like flash, but I can't be sure. But, the GUI doesn't have anything to do with the problem, for me, its a case of, "Oops, I have a lot of animations to load, lets lock up entirely, until I get a "large" percentage of them loaded." This might "look" prettier, or something, since the page in question won't display, until all the elements are there, to be seen, but.. I would almost prefer the old days, or having "missing picture" markers where they hadn't loaded yet, rather than have some background tab lock up everything, for a long time, in the middle of trying to do somethings else. And.. It only gets worse, if I am, for example, looking through some place like, say, Renderosity.com, or the like, where I am also popping open background windows, for pictures I want a better look at later. Then, combine all that background loading, or large files, with a sudden page of animated gifs... and of boy does things go wrong...
Agreed with previous posters, this is larger than a bug, it's a long-standing fundamental software design flaw that has become corrosive to all other Firefox capabilities.

15 years ago NCSA Mosaic under SunOS was solid, snappy, and responsive to user input regardless if individual windows got bogged down.  By contrast Firefox's current CPU and memory handling architecture behave in bottlenecked fashion reminiscent of Microsoft Windows 3.x multitasking and memory management.

Even under a capable OS like Windows 7 64-bit, with enough tabs open Firefox will gasp and struggle along starved for CPU and memory despite system utilization of both at only around 15%.

Developer energies spent on bells and whistles like skins and toolbar layouts seem to me like fussing over stateroom window trimmings as the ocean liner's lower engine room decks progressively fill with seawater.

I'm sticking with Firefox now only because I have more confidence in Mozilla's privacy intentions than Google's.  But that may change as month by month Firefox continues to be less practically usable as a browser due to regular browser-wide slowdowns, lockups, and crashes from single-tab implosions.
Patrick -- it's not gifs or even flash -- flash was moved to a separate process, and you can set your gif animations to 'once' (not that they are used that much anymore).

It's the sites using complex javascript (jquery  && google -- look at their javascripts sometime -- they are HUGE pieces of spaghetti)...and the fact
that *javascript* execution, AFAICT, is single threaded -- there's a fear that multi-threaded -- or multiple javascript engines will walk on each other's states as they access global variables.  There is no synchronization support for any of the global variable access (and I don't *know* how much there needs to be! -- and likely that's a huge part of the equation with the engineers working on FF now).  

It's my impression that the current code _is seen_ as needing too much work to be made safely parallel.  As long as it is 'seen' or perceived as being too big to fix with current resources, no one will even try as it would be seen as wasted effort -- but that's my completely 'out-of-touch' view as an an outsider who asked for parallel support from Mozilla when they were Netscape back in the late 90's early 2000's, as companies regularly used SMP machines (sgi). 

Parallel code can be a pain -- especially if multiple tabs have to coordinate -- which I think is the rub -- how many sites use google and update info using their code?   I'm NOT sure, how important losing some state in a ***browser***, is (between windows/tabs)...but if FF could just allow opening more than once "instance" of the browser -- and use a backend "in-memory" contention and merge agent to coordinate access to one disk session maybe that would be the easiest immediate route (certainly not ideal in terms of performance, BUT, .. #cpu /chip is increasing each generation...

Intel already is shipping 100-core machines @ 1GHz, -- with clockrates that slow, using multiple cores/threads becomes a necessity...
How difficult would it be to write instrumenting code (time +waiters) around any and all locks to find the bottle necks?
Five and a half years and this bug is still here. Oh my goodness...

Steps to reproduce problem:
Load a handful (10+) of any NYTimes news reports, FF will lag significantly, with continuous full load on only one thread (my CPU is 4 core 8 thread).

FF 19.0.2 (and many versions before that)
CPU E3-1245 V2
RAM 16GB
OS Win7Pro 64-bit
@M_Compute Good news on this front appeared this week:
https://blog.mozilla.org/blog/2013/04/03/mozilla-and-samsung-collaborate-on-next-generation-web-browser-engine/

From the reading, I figure that an stable, secure, multi-threaded Firefox could be released before 2016.
I agree with H.F in comment 46.  But I do not think I can wait as long as it seems it will be for RUST and SERVO.  I use Waterfox, a 64-bit build of FF, occasionally.  It does seem to work faster, and it is more reliable, but as stated above, not all add-ons work with it(due to its' 64-bit nature), so I cannot fully switch to it.  I have also used Ice Dragon, by Comodo, a build of 32-bit FF that is focused on security.  It has better add-on support, but lacks the performance of a 64-bit build.

After more than 5 years here, I do not expect this bug to be fixed.  When my browser crashes one too many times, I will reluctantly switch to Chrome.  Pick your battles, nothing's perfect.  I did not pay for FF, so I don't expect the developers to care about my opinion anyway.
I was thinking about this problem and how I might go about dealing with it given the very inter-woven nature of the code.

I'd work BACK from the data I want to protect the most, and then least... meaning,

I'd go with the fact that ultimately, you only want 1 writer writing to the session database (that will be stored on disk) at 1 time.  That's the "HAVE TO" as far as I can tell.  So I'd start with putting locks around all accesses -- which won't have
any contention, 'now', as it's all 1-active process (i.e. it's a change that can
be folded into the current code with little or no impact (other than code growth) --
it shouldn't break anything during this phase.

Now it may be naive (I really don't know alot about the internals of FF), but once 
those are in place, What would prevent you spawning/forking a new browser instance on every 'tab'  that is opened (or if that is too many, then maybe with every 'new' site that is opened, or if they open a new & separate window -- whatever makes the most sense)?

The fork would use copy-on-write so since each copy that's spun off would be fully initialized -- at least internally, the only thing that would need tidying would be duplicating some set of the resource forks on windows, cuz it doesn't have a native fork.

Now hopefully, you could start having multiple windows open that should be relatively independent of each other -- I would say in the first incarnation, there might be
some limitations on communication between separate instances -- but if they were based on a windowing environment, I wouldn't think there'd be too much inter-process contention FF would have to solve (in the short term) as far as the windowing environment.  

It seems the biggie is to focus on protecting the session space/dir so multiple readers can be using it and hopefully writers won't need to write to it that often,
as that will be a contention point -- a bit like the "big kernel lock" that used
to exist in early SMP versions of linux.  

Once you've gotten that basic framework -- which should be achievable in parallel with other ongoing development efforts (as in the single, active-cpu case, it's not really doing much), then you can move forward with splitting the big lock into smaller
chunks.  For things like the local disk cache (which I don't even use in my setup cuz I have a local squid proxy cache running on a machine with larger disk space -- and everything goes through that) .. which led me to thinking -- why not do the same for FF.  I.e. have a 'baby squid' - a proxy process that talks to the cache, and the
separate 'computer' or 'worker' instances would do all their disk caching through
through that proxy -- that would solve the problem of multiple reader/writers wanting 
access to the disk cache at the same time.

From there, could start coordinating a memory proxy that keeps a larger cache of
memory and the worker instance threads would do their caching through that --
not ideally efficient, but another notch up the performance scale.  From a memory
caching proxy, it could move toward sharing memory to allow for higher performance
transfers, it the cache manager would move toward being a process that maintains
the integrity of the the cache, but for I/O, it could point at a specific file 
for a client to retrieve directly, or a specific memory range, it would, at first,
copy, but later, might be able to use directly...

It seems like the main problem right now is "where to start"... Even though it wouldn't
be the most efficient coordination at first, -- ANY speedup would be welcomed by users.  Over time, it seems that with increasing coordination and finer granularity
on work performed, there'd be tons of improvement work that could be done in parallel with other tasks.   But this way, I don't know if my proposal makes any sense, but it it does, it seems like it would allow ongoing and new development, while at the same time, allowing the codebase to move toward increasing parallelization.  

It has the benefit of not needing a major interruption of all devel work to go off on something that wouldn't appear to provide new functionality (just reduce lags and such -- stuff that users often don't appreciate as much -- but really get bugged if it doesn't happen in tangent with newer, ongoing work)...

??? Sorry if this is all way to primitive or basic to be of any use, but I wasn't sure where you were in the devel process and didn't know if this type of feedback would even be of any use?... but I thought about what would be needed to make this transition "doable" (not take too many resources, and not block ongoing future projects)...  feel free to email if you have any questions you wanna toss around... I can't guarantee anything, but given the problem maybe any possibilities that might happen in the 'sooner' category might make it worth the bother...?

Just throwing this out...hope it's of some use (hell of a way to do project design though... ;-))...
I remember having read some paper from a Firefox dev that said that Firefox didn't need multi-threading (or multi-processing) because it was already well-optimized and multi-threading won't save a lot.
At that time, I blindly believed what this guy was saying, and I thought Firefox was slower on Linux at home than on Windows at work for some other mystic reasons.

But today I tried Chromium. To see with my own eyes that there were no improvement, and oh boy I was so wrong... Chromium is like 4 times faster that Firefox (on my 4-core CPU)! I'm really really sad about that discovery for Firefox is truly my favorite browser.

Please Firefox devs, do consider doing some multi-threading and/or multi-processing. In the meantime, I'll have to stick with Chromium and I don't like that, but I got no other choice, I can't afford a quad core at 4GHz each.
(In reply to romain.failliot from comment #53)
> I remember having read some paper from a Firefox dev that said that Firefox
> didn't need multi-threading (or multi-processing) because it was already
> well-optimized and multi-threading won't save a lot.
> At that time, I blindly believed what this guy was saying, and I thought
> Firefox was slower on Linux at home than on Windows at work for some other
> mystic reasons.

Firefox uses threads en masse (that can spread across multiple CPUs), so your info is false (or at least outdated). Also, plugins run in their own process, and currently there is ongoing work to separate the UI and content into its own process (project electrolysis, short: e10s). Please note that this bug dates back to 2007, that was 6 years ago!

If you have issues with Firefox, you can try safe-mode or resetting Firefox to rule out some bad influences (your profile might be broken, or you have badly behaving addons installed): https://support.mozilla.org/en-US/kb/reset-firefox-easily-fix-most-problems
Make sure that all your software is up to date, this includes Firefox itself, any addons and plugins, as well as your operating system, graphics and other hardware drivers (yeah, they can affect Firefox performance, too). 

If you still have speed issues, and they are not hardware related (e.g. slow harddrive), file a new bug (with specific descriptions of what is slow, maybe comparing it to other browsers, too) – it's definitely not related to CPU usage, but most likely unresponsiveness of certain parts of the browser (because it has to do disk I/O on the main thread, but this is also in the process of being refined, so please try a Aurora or Nightly release first and see if it fixes your problem).
(In reply to Florian Bender from comment #54)
> Firefox uses threads en masse (that can spread across multiple CPUs), so
> your info is false (or at least outdated). Also, plugins run in their own
> process, and currently there is ongoing work to separate the UI and content
> into its own process (project electrolysis, short: e10s).

That's good to know, thanks.

> If you have issues with Firefox, you can try safe-mode or resetting Firefox
> to rule out some bad influences (your profile might be broken, or you have
> badly behaving addons installed):
> https://support.mozilla.org/en-US/kb/reset-firefox-easily-fix-most-problems
> Make sure that all your software is up to date, this includes Firefox
> itself, any addons and plugins, as well as your operating system, graphics
> and other hardware drivers (yeah, they can affect Firefox performance, too).

I'm using ArchLinux, meaning I've got kinda the latest software possible on Linux (I'm using the radeon open source drivers which have pretty decent performances on video games so I don't think it could be the reason).
I've got 4 or 5 plugins, including adblock plus (well known), Ctrl+Tab and New tab homepage (very tiny plugins). I've reset my profile two months ago, and I did it already 6 months before it. It's a bit better, but it's really not perfect and, moreover, I don't want to delete my profile every 6 months!

> If you still have speed issues, and they are not hardware related (e.g. slow
> harddrive), file a new bug (with specific descriptions of what is slow,
> maybe comparing it to other browsers, too) – it's definitely not related to
> CPU usage, but most likely unresponsiveness of certain parts of the browser
> (because it has to do disk I/O on the main thread, but this is also in the
> process of being refined, so please try a Aurora or Nightly release first
> and see if it fixes your problem).

And here is the problem... There is no real steps to reproduce, no site to go to and "see for yourself"... As the time goes, Firefox just goes... slow. And the more you use it, the more it's slow (and plugins aren't the problem). And it is no only since few months, it's slow for the past 5 years! Of course, when you just open one page from time to time, there is no problem, but that's not my case: I have between 10 to 30 tabs opened, and I save my session.

Because I don't want just to complain in this message, here is a suggestion: why not integrate a profile system directly in Firefox, so that we could really see what's going on?
This is not the right forum to discuss this. Please don't answer my comment, instead direct them to the mailing lists (e.g. firefox-dev [https://mail.mozilla.org/listinfo/firefox-dev] or mozilla.dev.platform). 

(In reply to romain.failliot from comment #55)
> I'm using ArchLinux, meaning I've got kinda the latest software possible on
> Linux (I'm using the radeon open source drivers which have pretty decent
> performances on video games so I don't think it could be the reason).
Theoretically, they may be blacklisted in Firefox due to security issues, check out about:support to see if you run hardware acceleration. 

> I've got 4 or 5 plugins, including adblock plus (well known), Ctrl+Tab and
> New tab homepage (very tiny plugins). I've reset my profile two months ago,
> and I did it already 6 months before it. It's a bit better, but it's really
> not perfect and, moreover, I don't want to delete my profile every 6 months!
Newer versions of Firefox restore most profile data (except addons and preferences). 
Either way, your profile does not seem to be the culprit here. A wild guess could be Bug 934934.

> And here is the problem... There is no real steps to reproduce, no site to
> go to and "see for yourself"... As the time goes, Firefox just goes... slow.
Assuming it's not one of your addons, again, it sounds like Bug 934934 (so your sessionrestore file gets rather big which slows down Fx).

> Because I don't want just to complain in this message, here is a suggestion:
> why not integrate a profile system directly in Firefox, so that we could
> really see what's going on?
There is a profiler available which you can use: https://developer.mozilla.org/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler


Either way, it's definitely not this bug, so please open a new bug (you can start with "gets slower over a long time period" and add your usage pattern, and later refine the bug with newer findings).
http://www.shadertoy.com

This page. Just this one bloody page, is a direct indictment of the failure to include multithreading. It literally ***will not load*** at anything like a sane time span, if at all, with Firefox. With something like Chrome, it loads quickly, and simply, without the slightest hint of slowing down. If there is anyone, for one moment, than things this isn't something that needs to be fixed... they just need to try to visit the above page with Firefox.
Or, since someone above claims it can thread, and across multiple CPUs, then... something else is horribly wrong. Because... the issue is symptomatic, I think, of why any number of pages may be slower than they should, and some things just go really seriously wrong (with another one being handling of things like "progressive display" of pages, like on Tumblr, and others).
(In reply to Florian Bender from comment #56)
> This is not the right forum to discuss this. Please don't answer my comment,
> instead direct them to the mailing lists (e.g. firefox-dev
> [https://mail.mozilla.org/listinfo/firefox-dev] or mozilla.dev.platform). 
Applies here as well. Don't comment on bugs unless you provide any additional information to that particular bug. 

(In reply to Patrick Elliott from comment #57)
> http://www.shadertoy.com
Loads wonderfully fast on my Mac (MBA '12, takes about 2-3s, Chrome isn't any faster). Please file a new bug for this site with a description of your system & setup. 

> This page. Just this one bloody page, is a direct indictment of the failure
> to include multithreading. It literally ***will not load*** at anything like
> a sane time span, if at all, with Firefox. With something like Chrome, it
> loads quickly, and simply, without the slightest hint of slowing down. If
> there is anyone, for one moment, than things this isn't something that needs
> to be fixed... they just need to try to visit the above page with Firefox.
This is not due to multiple processes or something but due to other factors. Again, works good on my machine. 


If you have problems with specific sites, please file bugs. Worst case is that it gets duplicated to another bug, and that's ok!
There seems to be a confusion between multi-threading and multi-process architecture. Multi-threading allows a process to have multiple parallel threads of execution, however, they may or may not be parallel in real-time. e.g. most OS will only do time-slicing for threads of the same process. Multi-processing involves more than one independent processes (that may communicate with IPC or filesystem) and may have multiple threads within each process. Chrome uses multi-processing architecture whereas, to my understanding, Firefox doesn't. In multi-threading the memory is shared so no need for IPC, which makes programming much simpler than multi-processing. However, multi-processing is the right way to utilize all cores of a multi-core processor or multi-processor computer, considering the design or most common OS'es.
FYI, for those who want to follow along, there's a new blog post up explaining the ongoing effort: http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/

Please test & file bugs, and don't add your findings to this bug.
Per comment #14, comment #22, comment #24, comment #26, comment #29 (and probably a few others), I dupe this bug to the e10s project. The core of e10s is separating chrome and content into multiple processes which will solve what the original bug report was about (IIUC). Bugs similar to the testcases attached (`while(true)`) were also duped to e10s. Additionally, the initial bug report tried to cover several issues at once which lead to some confusion during investigation. Thus, I propose the following (to keep things nice and clean):

If multi-threading does not work on your system (read: there is proof), and you have steps-to-reproduce (STR), please file new bug with a description of your system & setup and STR. Please make sure that you have installed the latest (supported) versions of Firefox (that is, 24ESR and 25, though 26 gets released next week – please also try with pre-release versions like Aurora and Nightly if your problem exists there), any addons and plugins, and your operating system and hardware drivers (especially graphics). Also, please test in safe mode and with a new (clean) profile (or reset it) to see if there is some addon breaking Firefox BEFORE filing a new bug. Keep in mind that some operating systems may restrict resource usage by processes from time to time, so it's vital that you provide clear STRs. 

If you experience issues with out-of-process plugins, please file a new, separate bug.

Whenever you file a bug, please include detailed descriptions of what you did to investigate this bug, so others can follow and understand your steps. This will drastically improve investigation & fixing time. Thanks!


(In reply to Florian Bender from comment #61)
> FYI, for those who want to follow along, there's a new blog post up
> explaining the ongoing effort:
> http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/
> 
> Please test & file bugs, and don't add your findings to this bug.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 11 years ago
Resolution: --- → DUPLICATE
I totally agree with you Florian. I'll do my best to give feedbacks on this.
(BTW i tried http://www.shadertoy.com and it crashed my entire system... I suppose this is more Linux's fault though)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: