Closed Bug 958882 Opened 6 years ago Closed 6 years ago

Firefox and computer freeze with high CPU use when opening http://pythonfiddle.com/

Categories

(Core :: JavaScript Engine: JIT, defect)

26 Branch
x86_64
Windows 7
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla29
Tracking Status
firefox26 --- wontfix
firefox27 + verified
firefox28 + verified
firefox29 + verified
b2g-v1.2 --- fixed
b2g-v1.3 --- fixed

People

(Reporter: epinal99-bugzilla2, Assigned: jandem)

References

Details

(Keywords: memory-footprint, power, regression, Whiteboard: [MemShrink])

Attachments

(1 file)

STR:
Open http://pythonfiddle.com/ and start to type something in the code textarea (or just wait for 10/15 sec).

Result: Both browser and computer freeze, high CPU use.

Regression range:
good=2013-09-03
bad=2013-09-04
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d54e0cce6c17&tochange=e3785e299ab6
I think this is peek memory usage problem.

Regression range
Good Peek memory usage 400MB :
http://hg.mozilla.org/integration/mozilla-inbound/rev/f66ac3e480ca
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130902085957
Bad Peek memory usage 2400MB:
http://hg.mozilla.org/integration/mozilla-inbound/rev/abb25a18b5a5
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130902100557
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f66ac3e480ca&tochange=abb25a18b5a5

Regressed by:
abb25a18b5a5	Brian Hackett — Bug 906788 - Construct TypeObject newScript information using MIR, r=jandem.
Blocks: 906788
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Component: JavaScript Engine → JavaScript Engine: JIT
Er
s/Peek/Peak/g
Reproduce with Firefox Nightly 29.0a1 (2014-01-11) on Ubuntu 12.04 (3.8.0-35-generic x86_64)

In terminal, i could see ###!!! [Child][MessageChannel] Error: Channel error: cannot send/recv
Whiteboard: [MemShrink]
Given :bhackett is on vacation, NI on :jandem to see if he can help here.
Flags: needinfo?(jdemooij)
tracking as this is a recent release regression.
Attached patch PatchSplinter Review
We're running the TI new-script analysis on a huge script (bytecode length 548304 bytes)

This patch limits it to scripts <= 2000 bytes. I think the analysis is unlikely to be useful or worth it for scripts that are (much) larger than that, and because we run this analysis immediately (usecount == 0) compile time matters.
Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
Attachment #8359397 - Flags: review?(kvijayan)
Flags: needinfo?(jdemooij)
Comment on attachment 8359397 [details] [diff] [review]
Patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 906788.
User impact if declined: Memory peaks, OOM crashes.
Testing completed (on m-c, etc.): -
Risk to taking this patch (and alternatives if risky): Very low, it just adds a size limit.
String or IDL/UUID changes made by this patch: None.
Attachment #8359397 - Flags: approval-mozilla-beta?
Attachment #8359397 - Flags: approval-mozilla-aurora?
Comment on attachment 8359397 [details] [diff] [review]
Patch

This could avoid b2g memory usage problems as well.
Attachment #8359397 - Flags: approval-mozilla-b2g26?
Comment on attachment 8359397 [details] [diff] [review]
Patch

Review of attachment 8359397 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/jit/IonAnalysis.cpp
@@ +2149,5 @@
>  
>      if (!script->compileAndGo() || !script->canBaselineCompile())
>          return true;
>  
> +    if (script->length() > 2000)

Consider making this a proper named constant (#define), or an ion option.  We should be careful about littering tuning constants around the code.
Attachment #8359397 - Flags: review?(kvijayan) → review+
Waiting for inbound/central landing before approving on branches.
https://hg.mozilla.org/integration/mozilla-inbound/rev/689e99a56512

(In reply to Kannan Vijayan [:djvj] from comment #9)
> Consider making this a proper named constant (#define), or an ion option. 

I added a "static const uint32_t MAX_SCRIPT_SIZE".
https://hg.mozilla.org/mozilla-central/rev/689e99a56512
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Attachment #8359397 - Flags: approval-mozilla-beta?
Attachment #8359397 - Flags: approval-mozilla-beta+
Attachment #8359397 - Flags: approval-mozilla-b2g26?
Attachment #8359397 - Flags: approval-mozilla-b2g26+
Attachment #8359397 - Flags: approval-mozilla-aurora?
Attachment #8359397 - Flags: approval-mozilla-aurora+
(In reply to Loic from comment #0)
> STR:
> Open http://pythonfiddle.com/ and start to type something in the code
> textarea (or just wait for 10/15 sec).
> 
> Result: Both browser and computer freeze, high CPU use.
> 
> Regression range:
> good=2013-09-03
> bad=2013-09-04
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=d54e0cce6c17&tochange=e3785e299ab6

Loic, can you please help verify this is fixed for you now ?
I tested with the latest Nightly (Built from http://hg.mozilla.org/mozilla-central/rev/81bced59e8b3), no more freeze when loading and typing, but the CPU use stays high even the page is idle (maybe should I file a new report?) and it's not the case with an old version like FF17.
Loic, please verify this is fixed in the latest Nightly, Aurora, and Beta builds.
Flags: needinfo?(epinal99-bugzilla)
Yes, it's fixed for me in FF27+.

But the high CPU use is still present in these 3 builds.
Flags: needinfo?(epinal99-bugzilla)
(In reply to Loic from comment #17)
> Yes, it's fixed for me in FF27+.
> 
> But the high CPU use is still present in these 3 builds.

Can you do a comparison of CPU usage between Firefox 25, 27, 28, 29, latest Chrome, and latest IE?
Flags: needinfo?(epinal99-bugzilla)
The regression range about the CPU use:
good=2014-01-14
bad=2014-01-15
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=34dddf6f7ec1&tochange=81bced59e8b3

One of my 4 cores is completely used by Nightly when this website is loaded.
The patch is probably not optimal.
Flags: needinfo?(epinal99-bugzilla)
(In reply to Loic from comment #19)
> The patch is probably not optimal.

The patch here was only intended to address your system becoming locked up completely. If that's no longer happening then this is resolved. That said, you should report a new bug report, referencing this bug report, to improve the CPU usage in Firefox. Particularly if it is significantly worse than the competition. I will leave that up to you.
Blocks: 961124
You need to log in before you can comment on or make changes to this bug.