Closed Bug 800063 Opened 7 years ago Closed 7 years ago

Make GC_ALLOCATION_THRESHOLD dynamic

Categories

(Firefox OS Graveyard :: General, defect)

x86
macOS
defect
Not set

Tracking

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed)

RESOLVED FIXED
blocking-basecamp +
Tracking Status
firefox18 --- fixed
firefox19 --- fixed

People

(Reporter: gwagner, Assigned: gwagner)

References

Details

Attachments

(1 file)

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: nobody → anygregor
blocking-basecamp: --- → ?
(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.
> 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.
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...)
(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.
> 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.
Marking blocking as it seems to be a big enough win to justify.
blocking-basecamp: ? → +
Attached patch patchSplinter Review
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+
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
https://hg.mozilla.org/mozilla-central/rev/a32865b52f01
https://hg.mozilla.org/mozilla-central/rev/647d6f4cd15d
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.