Closed
Bug 800063
Opened 12 years ago
Closed 12 years ago
Make GC_ALLOCATION_THRESHOLD dynamic
Categories
(Firefox OS Graveyard :: General, defect)
Tracking
(blocking-basecamp:+, firefox18 fixed, firefox19 fixed)
RESOLVED
FIXED
blocking-basecamp | + |
People
(Reporter: gwagner, Assigned: gwagner)
References
Details
Attachments
(1 file)
9.82 KB,
patch
|
billm
:
review+
|
Details | Diff | Splinter Review |
In the desktop browser we only start GCing after the GC heap reached 30MB. We should make this dynamic and reduce it for mobile devices.
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → anygregor
blocking-basecamp: --- → ?
Assignee | ||
Comment 1•12 years ago
|
||
(In reply to Gregor Wagner [:gwagner] from comment #0) > In the desktop browser we only start GCing after the GC heap reached 30MB. > We should make this dynamic and reduce it for mobile devices. This is the allocation based trigger. We sure can trigger GCs for other events. But in the parent we have less (to none?) window-event based triggers.
Comment 2•12 years ago
|
||
> But in the parent we have less (to none?) window-event based triggers.
We can definitely add them, though. It would be a matter of bubbling the event up from BrowserElementChild to BrowserElementParent and then firing an observer.
Comment 3•12 years ago
|
||
I could even imagine doing a selective compartment GC that just works on the compartments in the parent that are associated with the child somehow. (Not knowing precisely how that all works...)
Assignee | ||
Comment 4•12 years ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #3) > I could even imagine doing a selective compartment GC that just works on the > compartments in the parent that are associated with the child somehow. (Not > knowing precisely how that all works...) I guess that's what we are currently doing. In the parent I mostly see malloc and alloc based triggers for one compartment. Hm a huge win could be a global GC that is connected to the idle API.
Comment 5•12 years ago
|
||
> Hm a huge win could be a global GC that is connected to the idle API. Along the same lines, I just filed bug 800166.
Comment 6•12 years ago
|
||
Marking blocking as it seems to be a big enough win to justify.
blocking-basecamp: ? → +
Assignee | ||
Comment 7•12 years ago
|
||
Assignee | ||
Updated•12 years ago
|
Attachment #675712 -
Flags: review?(wmccloskey)
Comment on attachment 675712 [details] [diff] [review] patch Review of attachment 675712 [details] [diff] [review]: ----------------------------------------------------------------- One problem I see here is that incremental GC isn't used for the allocation-based triggers. But it seems like you guys are mostly worried about memory usage, so maybe it's better to do it this way.
Attachment #675712 -
Flags: review?(wmccloskey) → review+
Assignee | ||
Comment 9•12 years ago
|
||
You are right, the current focus is memory usage. We can still tweak it if it causes too many GCs. https://hg.mozilla.org/integration/mozilla-inbound/rev/a32865b52f01
Assignee | ||
Comment 10•12 years ago
|
||
Followup: https://hg.mozilla.org/integration/mozilla-inbound/rev/647d6f4cd15d
Comment 11•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/a32865b52f01 https://hg.mozilla.org/mozilla-central/rev/647d6f4cd15d
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Comment 12•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/c25644a55f65 https://hg.mozilla.org/releases/mozilla-aurora/rev/7af481b6c252
status-firefox18:
--- → fixed
status-firefox19:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•