Closed
Bug 606637
Opened 14 years ago
Closed 13 years ago
TM: tune GC parameter to get better benchmark performance in the browser
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: gwagner, Assigned: gwagner)
References
Details
Attachments
(1 file)
|
(deleted),
text/plain
|
Details |
No description provided.
|
Assignee | |
Updated•14 years ago
|
Assignee: general → anygregor
|
|
Assignee | |
Updated•14 years ago
|
Summary: TM: tune GC parameter to avoid GC runs in the browser for benchmarks → TM: tune GC parameter to get better benchmark performance in the browser
|
|
Assignee | |
Comment 1•14 years ago
|
||
Lots of text and numbers in the attachment.
|
|
Assignee | |
Comment 2•14 years ago
|
||
Running SS in the browser triggers an onTooMuchMalloc GC which we should try to avoid. I am not sure yet if we just have to increase the malloc bytes or if there is a bug somewhere.
Looking at the gcMallocBytes code I see that we update the counter twice in PropertyTable::change. First in the calloc call (cx calloc calls rt calloc and we update the counter there) and line 416 with cx->runtime->updateMallocCounter(nbytes);
Brendan, Igor, is this wanted or a bug?
|
||
Comment 3•14 years ago
|
||
Argh, that PropertyTable::change code should be calling js_calloc. OOM reporting is up to the caller and not always done if the failure can be tolerated. There's a bug in the one caller that tests change's return value for null (which should mean unreported OOM): JSObject::addPropertyInternal.
I filed bug 606880 on this.
/be
Depends on: 606880
|
||
Comment 4•13 years ago
|
||
Lots of GC tuning has been done in other bugs in the last year. Please open if there's more to do in this bug.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•