TM: [Pentium 3] 100 % CPU utilization, rare run-away memory consumption [http://www.fancast.com/static-25168/js/bottom_combined.js]

RESOLVED FIXED

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
9 years ago
4 years ago

People

(Reporter: IU, Unassigned)

Tracking

({perf, regression})

Trunk
x86
Windows XP
perf, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: SEE COMMENT #4 and #5, URL)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091112 Minefield/3.7a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091112 Minefield/3.7a1pre ID:20091112045818

At the linked URL, Minefield experiences 100 % CPU utilization with JIT content, due to the script: http://www.fancast.com/static-25168/js/bottom_combined.js

Disabling JIT content allows the page to load without issue.

Reproducible: Always

Steps to Reproduce:
1. Make sure JIT content is default
2. Load the linked URL
3. Notice the 100 % CPU utilization.
(Reporter)

Comment 1

9 years ago
Created attachment 412048 [details]
test case: web page archive.

Loading this will also cause 100% CPU in the contained bottom_combined.js script.
(Reporter)

Comment 2

9 years ago
The memory consumption aspect of this bug is difficult to reproduce.
Summary: TM: 100 % CPU utilization, occasional run-away memory consumption [http://www.fancast.com/static-25168/js/bottom_combined.js] → TM: 100 % CPU utilization, rare run-away memory consumption [http://www.fancast.com/static-25168/js/bottom_combined.js]
(Reporter)

Comment 3

9 years ago
Regression Range:

TraceMonkey:
1257362374-20091104111934-7d834c0884b7-firefox-3.7a1pre 04-Nov-2009 12:35   
1257335057-20091104034417-24b4d2efe0b4-firefox-3.7a1pre 04-Nov-2009 05:16 

Minefield Nightly:
1257403024-20091104223704-c9fe484ebc81-firefox-3.7a1pre 05-Nov-2009 00:20   
1257392568-20091104194248-eb2a556deb11-firefox-3.7a1pre 04-Nov-2009 21:20
Keywords: regression
Version: unspecified → Trunk
(Reporter)

Comment 4

9 years ago
In my STR, when I wrote, "Load the linked URL," the URL I was referring to is http://www.fancast.com/ NOT the script URL.
Whiteboard: SEE COMMENT #4
(Reporter)

Updated

9 years ago
Keywords: perf
(Reporter)

Comment 5

9 years ago
This bug needs attention.  It's affecting a lot of sites.  I have been noticing the many sites with JavaScript are generally slower.

You can also see the effects on abcnews.com video player: http://www.abcnews.go.com/Video/playerIndex?id=9077753

On abcnews.go.com, when you navigate the left-hand side video list, in the player, there is very significant slow-down between builds eb2a556deb11 and c9fe484ebc81.  Sometimes I get momentary hangs.

I'm increasing priority and also requesting blocking on branch.
Severity: major → critical
Flags: blocking1.9.2?
(Reporter)

Updated

9 years ago
Whiteboard: SEE COMMENT #4 → SEE COMMENT #4 and #5
(Reporter)

Comment 6

9 years ago
Note: I'm on an Intel P3, so I wonder if there's an architecture-specific bug?
(In reply to comment #6)
> Note: I'm on an Intel P3, so I wonder if there's an architecture-specific bug?

I tried fancast.com with m-c nightlies of 11/1, 11/4, 11/5, and 11/12. On all of them, my average CPU usage was 13%. Most of the time it was 6%, but spiked to 50%+ every 4 seconds or so. This is on a 2.2GHz Core 2 of 2007 vintage. It is plausible to me that a P3 would have 100% CPU usage on the same load.

For me, turning content JIT to false on this page had no effect on CPU usage.

It may be architecture-specific; there were a few changes to the JIT backend on Nov 4. bug 516348 and bug 517405 look like the most likely to have had an effect.
(Reporter)

Comment 8

9 years ago
Thanks David, I'm going to add blocking on those till somebody can take a look at this.  The regression is pretty bad for my CPU.
Blocks: 516348, 517405
(Reporter)

Updated

9 years ago
Keywords: qawanted
(Reporter)

Updated

9 years ago
Summary: TM: 100 % CPU utilization, rare run-away memory consumption [http://www.fancast.com/static-25168/js/bottom_combined.js] → TM: [Pentium 3] 100 % CPU utilization, rare run-away memory consumption [http://www.fancast.com/static-25168/js/bottom_combined.js]
Bug 516348 and bug 517405 seem unlikely to have caused this problem, IMO.  You've narrowed the regression range down to six revisions, can you narrow it down to one?
(Reporter)

Comment 10

9 years ago
(In reply to comment #9)
> Bug 516348 and bug 517405 seem unlikely to have caused this problem, IMO. 
> You've narrowed the regression range down to six revisions, can you narrow it
> down to one?

How?  I don't see any more frequent hourlies in the archive.  Is there another hourly archive somewhere?
(Reporter)

Comment 11

9 years ago
@Nicholas:

By the way, if you look at the following TraceMonkey changelog for the regression interval: http://hg.mozilla.org/tracemonkey/log/f3e9ac90c086

you will notice that the only check-ins within the regression window are bug 516348 and bug 517405.  It is impossible that any other check-ins are the issue.

So unless I'm not understanding you, one of those check-ins caused the regression.
I don't know how the hourly archives work.  According to 'hg log', in the tracemonkey repo we had the following commits between 7d834c0884b7 and 24b4d2efe0b4:

changeset:   34381:7d834c0884b7
user:        Graydon Hoare <graydon@mozilla.com>
date:        Wed Nov 04 10:28:43 2009 -0800
summary:     Update nanojit-import-rev stamp.

changeset:   34380:f0d5ea88d07f
user:        Graydon Hoare <graydon@mozilla.com>
date:        Wed Nov 04 10:15:41 2009 -0800
summary:     Bug 526011 - Backed out changeset ccae3c736aed, premature landing.

changeset:   34379:04014b568209
user:        Nicholas Nethercote <nnethercote@mozilla.com>
date:        Wed Nov 04 16:44:13 2009 +1100
summary:     Bug 517405 - nanojit: don't compute x86 FP conditions twice(!).  r=
rreitmai.

changeset:   34378:6b96e43a6dd3
user:        Nicholas Nethercote <nnethercote@mozilla.com>
date:        Wed Nov 04 14:45:29 2009 +1100
summary:     Bug 516348 - nanojit: add findSpecificRegForUnallocated().  r=edwsm
ith.

changeset:   34377:34f7de7463c0
user:        Graydon Hoare <graydon@mozilla.com>
date:        Tue Nov 03 11:49:31 2009 -0800
summary:     Bug 525392 - Fix ARM branch-patching logic, r=vlad.

changeset:   34376:280561a45b76
user:        Graydon Hoare <graydon@mozilla.com>
date:        Mon Nov 02 17:10:27 2009 -0800
summary:     Bug 526070 - lirasm call argument ordering bug, r=dvander.

changeset:   34375:b64f119567bf
user:        David Anderson <danderson@mozilla.com>
date:        Tue Nov 03 10:16:17 2009 -0800
summary:     Removed Fragment::vmprivate and Fragment::root (bug 526011, r=grayd
on).

changeset:   34374:24b4d2efe0b4
user:        Luke Wagner <lw@mozilla.com>
date:        Tue Nov 03 15:22:48 2009 -0800
summary:     Bug 526356 - invalid debug memset of global native frame in Executr
eTree (r=dvander)


How did you determine the regression range?
(Reporter)

Comment 13

9 years ago
(In reply to comment #12)
> How did you determine the regression range?

All I did was determine which hourly builds first included the regression, using the hourly archives here:
http://hourly-archive.localgho.st/hourly-archive2/tracemonkey-win32/
http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-win32/

As for your list:

1. 34381:7d834c0884b7
- This doesn't look like it is likely to have caused the regression, but I'm guessing.

2. 34380:f0d5ea88d07f
- Doesn't seem likely.  Builds following this supposed backout still exhibited the regression.  However, I have been unable to determine where this relanded.  

3. 34379:04014b568209
- Suspected

4. 34378:6b96e43a6dd3
- Suspected

5. 34377:34f7de7463c0
- Obviously, this should not affect x86

6. 34376:280561a45b76
- I guesss this is a possibility.

7. 34375:b64f119567bf
- Same as #2.


@Graydon: Is there anything in your changes that had the potential of causing this?
(Reporter)

Comment 14

9 years ago
The regression-causing changes have not yet made their way into Namoroka, so I've removed the blocking request for now.
Blocks: 526070
Flags: blocking1.9.2?
Patch #4 had a follow-up (34692:515d7e584de6) that fixed a problem with it.  If you're using a non-debug build that might explain it.  (If you're using a debug build the problem should have caused assertion failures.)  Can you try an hourly build from after that follow-up and see if the problem is still present?
(Reporter)

Comment 16

9 years ago
(In reply to comment #15)
> Patch #4 had a follow-up (34692:515d7e584de6) that fixed a problem with it...  > ...Can you try an hourly build from after that follow-up and see if the problem
> is still present?

That was it.  So Bug 516348 was the cause.  The following hourly TraceMonkey build contains the fix: 1258333637-20091115170717-30f8f6dcf808-firefox-3.7a1pre	15-Nov-2009 19:00

Now just gotta wait for it to land on mozilla-central before I can mark it fixed.

Thanks
No longer blocks: 517405, 526070
Depends on: 527874
Excellent!  The best kind of bugs are the ones I've already fixed :)  Thanks for trying new version.  Interesting that it caused 100% CPU utilisation, I wouldn't have expected that.
(Reporter)

Comment 18

9 years ago
YEAH! Fixed by check-in for bug 527874

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091119 Minefield/3.7a1pre ID:20091119050202
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Great, thanks for the feedback.
Issue is resolved - clearing old keywords - qa-wanted clean-up
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.