Closed Bug 965916 Opened 8 years ago Closed 8 years ago

On memory pressure, trigger a second GC if it would probably be productive


(Core :: XPCOM, defect)

Not set





(Reporter: mccr8, Assigned: mccr8)


(Blocks 1 open bug)


(Whiteboard: [MemShrink])


(1 file)

When we finish a CC, we poke the GC if sCCollectedWaitingForGC exceeds some threshold.  But if we're doing a GC->CC combo due to getting a memory pressure event, in nsJSEnvironmentObserver::Observe, we probably want to do that second GC immediately.
(Luke pointed out that we probably want that second GC on memory pressure.)
This really just makes the memory pressure more useful, we could add it either way.
Blocks: 865959
No longer blocks: 936236
And that second GC will then trigger second (async) CC too.
(In reply to Olli Pettay [:smaug] from comment #3)
> And that second GC will then trigger second (async) CC too.

Sure.  Hopefully it won't do much.  The hope of the second GC is that it will free a bunch of stuff the CC made into garbage.

try run:
Attachment #8368656 - Flags: review?(bugs) → review+
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
"Minimize memory usage" triggers 3 memory pressure events, precisely so that this GC/CC/GC dance gets done sufficiently. Could the number be reduced to 2 or 1 now?
Reducing it to 2 should be okay.  In theory, 2 would have been okay before (in theory, 1 is okay now).  Trading a little jankiness for less weirdness in case of bugginess is probably the way to go, or we'll just have to tell people to hit the button multiple times, which defeats the point.
I was thinking that MMU happened when apps went into the background, but that's just vanilla memory-pressure. Yeah, jank after hitting the MMU button doesn't matter.
You need to log in before you can comment on or make changes to this bug.