Closed Bug 590533 Opened 14 years ago Closed 14 years ago

GC blocks and never completes while workers are running

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla2.0b8
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: mmichal_90, Assigned: igor)

References

()

Details

(Keywords: hang, testcase, Whiteboard: fixed-in-tracemonkey)

Attachments

(4 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b4) Gecko/20100817 SUSE/4.0b-16.1 Firefox/4.0b4
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b4) Gecko/20100817 SUSE/4.0b-16.1 Firefox/4.0b4

when i go to this site (http://29a.ch/sandbox/2010/cornellbox/)
Firefox take all free RAM and some swap and not responding. When i wait some time it responding for few sec and again  not responding. So i can't  use FF ;/. I run that site in chrome 7.0 and it take 8% of my ram and it was 40x faster.
in description of script i read it made for 4-core processors (chrome use it) but Mozilla use 300 % CPU (3 -cores) but later use 100% CPU (only one core).

Reproducible: Always

Steps to Reproduce:
1.go to http://29a.ch/sandbox/2010/cornellbox/
2.wait
3.you don't have free ram :P
Actual Results:  
http://29a.ch/2010/5/17/path-tracing-a-cornell-box-in-javascript

top | grep firefox:



Expected Results:  
FF should respond all time and don't use too much RAM and swap

http://29a.ch/2010/5/17/path-tracing-a-cornell-box-in-javascript

top | grep firefox:
//go to site
14254 michal    20   0  922m 157m  22m R   18  2.6  28:55.30 firefox
14254 michal    20   0 1311m 580m  22m S  159  9.7  29:00.08 firefox
14254 michal    20   0 2039m 1.3g  22m S  254 21.9  29:07.75 firefox
14254 michal    20   0 2763m 2.0g  22m S  255 33.9  29:15.41 firefox
14254 michal    20   0 3465m 2.7g  22m S  252 45.7  29:22.99 firefox
14254 michal    20   0 4169m 3.3g  22m S  252 57.4  29:30.56 firefox
14254 michal    20   0 4866m 4.0g  22m S  250 69.0  29:38.09 firefox
14254 michal    20   0 5523m 4.7g  15m S  240 79.9  29:45.31 firefox
14254 michal    20   0 5715m 4.8g  11m S   84 83.0  29:47.83 firefox
14254 michal    20   0 5898m 5.0g 5776 S   82 85.7  29:50.35 firefox
14254 michal    20   0 6006m 5.1g 3660 S   50 87.0  29:51.88 firefox
14254 michal    20   0 6085m 5.1g 3420 S   34 87.8  29:52.92 firefox
14254 michal    20   0 6177m 5.1g 3420 S   41 87.9  29:54.15 firefox
14254 michal    20   0 6222m 5.1g 3412 S   20 87.9  29:54.79 firefox
14254 michal    20   0 6326m 5.1g 3412 S   44 87.3  29:56.13 firefox
14254 michal    20   0 6414m 5.1g 3364 S   37 87.6  29:57.25 firefox
14254 michal    20   0 6414m 5.1g 3396 D    0 87.4  29:57.26 firefox
14254 michal    20   0 6414m 5.1g 3412 D    1 87.8  29:57.29 firefox
14254 michal    20   0 6414m 5.1g 3428 D    1 87.9  29:57.33 firefox
14254 michal    20   0 6414m 5.1g 3400 D    0 87.8  29:57.34 firefox
14254 michal    20   0 6414m 5.1g 3352 D    1 87.5  29:57.38 firefox
14254 michal    20   0 6414m 5.1g 3528 D    1 87.6  29:57.41 firefox
14254 michal    20   0 6414m 5.1g 3532 D    2 87.7  29:57.46 firefox
14254 michal    20   0 6414m 5.1g 3436 D    2 87.6  29:57.52 firefox
14254 michal    20   0 6414m 5.1g 3480 R   87 87.6  30:00.15 firefox
14254 michal    20   0 6414m 5.1g 3464 R   87 87.5  30:02.78 firefox
14254 michal    20   0 6414m 5.1g 3456 R   97 87.5  30:05.70 firefox
14254 michal    20   0 6414m 5.1g 3456 R   99 87.4  30:08.68 firefox
14254 michal    20   0 6414m 5.1g 3444 R  100 87.4  30:11.68 firefox
14254 michal    20   0 6414m 5.1g 3444 R   89 87.4  30:14.36 firefox
14254 michal    20   0 6414m 5.1g 3444 D   53 87.4  30:15.94 firefox
14254 michal    20   0 6414m 5.1g 3360 R   34 87.3  30:16.96 firefox
14254 michal    20   0 6414m 5.1g 3232 D   24 87.4  30:17.69 firefox
14254 michal    20   0 6414m 5.1g 3144 D    7 87.5  30:17.90 firefox
14254 michal    20   0 6414m 5.1g 3076 D   14 87.7  30:18.33 firefox
14254 michal    20   0 6414m 5.1g 3208 D   12 88.0  30:18.70 firefox
14254 michal    20   0 6414m 5.1g 3208 D   12 88.0  30:19.06 firefox
14254 michal    20   0 6414m 5.1g 3204 D    6 88.0  30:19.23 firefox
14254 michal    20   0 6414m 5.1g 3108 D    7 88.1  30:19.45 firefox
14254 michal    20   0 6414m 5.1g 3108 D   13 88.0  30:19.84 firefox
14254 michal    20   0 6414m 5.1g 3100 D    7 87.8  30:20.06 firefox
14254 michal    20   0 6414m 5.1g 3096 R   55 87.8  30:21.71 firefox
14254 michal    20   0 6414m 5.1g 3096 R   98 87.8  30:24.66 firefox
14254 michal    20   0 6414m 5.1g 3096 R   96 87.7  30:27.54 firefox
14254 michal    20   0 6414m 5.1g 3096 D   23 87.6  30:28.24 firefox
14254 michal    20   0 6414m 5.1g 3096 D   11 87.7  30:28.57 firefox
14254 michal    20   0 6414m 5.1g 3096 D    6 87.7  30:28.74 firefox
14254 michal    20   0 6414m 5.1g 3096 D    7 87.7  30:28.96 firefox
14254 michal    20   0 6414m 5.1g 3096 D    8 87.8  30:29.19 firefox
14254 michal    20   0 6414m 5.1g 3096 D    5 87.6  30:29.34 firefox
14254 michal    20   0 6414m 5.1g 3140 D   11 87.1  30:29.67 firefox
14254 michal    20   0 6414m 5.1g 3140 D   15 87.8  30:30.11 firefox
14254 michal    20   0 6414m 5.1g 3140 D   12 87.8  30:30.47 firefox
14254 michal    20   0 6414m 5.1g 3076 D    6 87.9  30:30.65 firefox
14254 michal    20   0 6414m 5.1g 2696 D    9 87.2  30:30.93 firefox
14254 michal    20   0 6414m 5.1g 2696 D   11 87.8  30:31.25 firefox
14254 michal    20   0 6414m 5.1g 2696 R   10 88.0  30:31.55 firefox
14254 michal    20   0 6414m 5.1g 2696 D   14 88.0  30:31.96 firefox
14254 michal    20   0 6414m 5.1g 3200 D   13 87.8  30:32.36 firefox
14254 michal    20   0 6137m 4.8g 5660 R   19 83.1  30:32.94 firefox
14254 michal    20   0 5755m 4.4g 9020 D   29 76.4  30:33.80 firefox
14254 michal    20   0 5331m 4.0g 9260 S   28 69.4  30:34.64 firefox
14254 michal    20   0 5302m 4.0g 9444 D   10 69.2  30:34.93 firefox
14254 michal    20   0 5277m 4.0g 9480 S   11 69.1  30:35.26 firefox
14254 michal    20   0 5251m 4.0g 9672 S   10 68.9  30:35.56 firefox
14254 michal    20   0 5215m 4.0g  10m S    9 68.7  30:35.82 firefox
14254 michal    20   0 5169m 4.0g  10m S   13 68.3  30:36.20 firefox
14254 michal    20   0 5154m 4.0g  10m S    6 68.2  30:36.39 firefox
14254 michal    20   0 5130m 4.0g  10m S    7 68.0  30:36.61 firefox
14254 michal    20   0 5100m 3.9g  10m S   10 67.7  30:36.91 firefox
14254 michal    20   0 5073m 3.9g  10m S    9 67.4  30:37.18 firefox
14254 michal    20   0 5053m 3.9g  12m D   10 67.2  30:37.48 firefox
14254 michal    20   0 5029m 3.9g  12m S   10 66.9  30:37.77 firefox
14254 michal    20   0 4997m 3.9g  12m D   12 66.6  30:38.14 firefox
//close tab with site
14254 michal    20   0 1929m 935m  12m S   56 15.7  30:39.83 firefox
14254 michal    20   0 1166m 139m  12m S   24  2.3  30:40.56 firefox
14254 michal    20   0 1166m 140m  12m S    4  2.4  30:40.68 firefox
14254 michal    20   0 1166m 140m  12m S    1  2.4  30:40.71 firefox
14254 michal    20   0 1166m 140m  12m S    1  2.4  30:40.74 firefox
14254 michal    20   0 1166m 140m  12m S    3  2.4  30:40.82 firefox
sorry i forgot about my hardware:
VPCF11S1E
at a glance:
i7 and 6GB RAM
michal, have you tested with anything newer?

hangs for a few minutes for me with 20100828 4.0b5pre on a fast win7 box, low cpu (13%) - gobbled 1+GB but then freed up, and nothing displayed for the page. testcase coming up.
Severity: normal → critical
Keywords: hang, testcase
OS: Linux → All
Summary: firefox take all free RAM and some swap → severe performance problem - firefox take all free RAM/memory and some swap
Version: unspecified → Trunk
Minefield freezes immediately for me after loading the test page. The memory gets filled-up immediately. Tested with a recent Minefield build on OS X.
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Hardware: x86_64 → All
The testcase is about web workers. Moving into the correct component.

Possible dupe of bug 537527?
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
I wasn't able to reproduce with this html source using today's nightly. 

but I was able to reproduce using the URL - sucked up almost 4GB of memory
Attached file testcase
Full testcase as tgz file.
Ben, can you check what worker related objects might be hanging around too long and causing this?
Assignee: nobody → bent.mozilla
blocking2.0: ? → betaN+
This is a JS engine bug. The main thread is blocked waiting on the worker threads to yield their requests, but the worker threads are chewing and don't ever do so.
Assignee: bent.mozilla → general
Component: DOM → JavaScript Engine
QA Contact: general → general
The worker's GC callback says "don't GC on this thread", but we never yield in this case. We should add a JS_Yield in the engine right after the callback comes back with "NO".
Summary: severe performance problem - firefox take all free RAM/memory and some swap → GC blocks and never completes while workers are running
(In reply to comment #9)
> The worker's GC callback

Well, we don't have a worker GC callback, it's just the same one that DOM uses.
Attached file Sample of two threads
This shows the two threads. Main is blocked 100% of the time.
Yeah, and there we should yield if the callback refused to GC on the thread.
Assignee: general → igor
Attached patch wip (obsolete) — Splinter Review
The patch is work-in-progress that adds the JS API test case to demonstrate the problem. It hangs with the same stack traces as the other test cases here.
Attached patch v1Splinter Review
The new version fixes the bug via calling the yield unconditionally in the operation callback and increases test coverage in the test.
Attachment #495002 - Attachment is obsolete: true
Attachment #495230 - Flags: review?(gal)
Comment on attachment 495230 [details] [diff] [review]
v1

We yield a lot less than we used to because we removed title sharing, so this is definitely the right thing to do. Thanks.
Attachment #495230 - Flags: review?(gal) → review+
We should take this for b8.
http://hg.mozilla.org/tracemonkey/rev/0b53fd11e374
Whiteboard: fixed-in-tracemonkey
could this also be related to bug 609543 and the stack from comment 176?
(In reply to comment #18)
> could this also be related to bug 609543 and the stack from comment 176?

No. This bug require the main thread to wait on the GC lock under js_GC while some other thread busy running the JS. The waiting lock in the bug 609543 comment 176 is nsCycleCollectorRunner::mLock.
http://hg.mozilla.org/mozilla-central/rev/0b53fd11e374
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
This is not fixed in Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101207 Firefox/4.0b8pre

The memory gets filled-up with a cpu load of about 150% on my dual-core MBP. Closing the page the acquired memory from the testcase gets never released (probably another bug).

If I'm wrong, please tell me what's the expected result of the fix is, and if remaining issues should be filed as new bugs. Thanks.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blocks: 617569
(In reply to comment #21)
> This is not fixed in Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre)
> Gecko/20101207 Firefox/4.0b8pre

I filed the bug 617569 to keep this one about the GC stuck waiting for a worker. This is covered by the API test in the landed patch.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Thanks Igor! Marking as verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101212 Firefox/4.0b8pre
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla2.0b8
No longer blocks: 617569
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: