Closed Bug 481977 Opened 15 years ago Closed 15 years ago

TM: ARM: memory usage spike on browser sunspider on crypto-aes

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
ARM
Windows CE
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 481922

People

(Reporter: vlad, Unassigned)

References

Details

When I run sunspider in the browser, when it transitions to crypto-aes after controlflow-recursive, I see memory usage spike by 70MB (total device in-use memory was 70MB before, quickly grows 90->120->140 when controlflow-rec ends, after printing a dump() to say it's starting crypto-aes); and my device kills firefox with out of memory.

This may or may not be related to the problem in bug 481922.
I bisected this down to the patch that went in for bug 473256 (commit d6927736).  However, that doesn't look very likely; indeed if I back that out locally the problem doesn't go away.
changeset 3ea85396 is good, so it must've been something that came in during the merge that immediately follows.
Then you can

hg bisect --reset
hg update 737ca70d654f
<<test this revision>>
hg bisect --good  # probably
hg update 4f383f83df5a
<<test this revision>>
hg bisect --bad  # probably

and work from there.

Re comment 1, note that d6927736 actually *did* get backed out.  hg bisect is very sensitive, you can imagine--if you tell it anything wrong at any point, it'll let you plow ahead for umpteen more iterations and then cheerfully produce a completely bogus answer.
Yeah, working on it -- mainly commented because I was about to leave for dinner and wasn't sure if I'd have time to work on this afterwards :)
Ok, looks like the patch in bug 479487 is causing this.  Confirmed by backing out locally.
Blocks: 479487
The patch in bug 481922 fixes this.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.