1751543 - Parent process appears to be momentarily waiting for chance to do major GC

Status: RESOLVED FIXED

(Core :: JavaScript: GC, defect, P3)

Description

[Steve Fink [:sfink] [:s:]]

I'm not sure of what's going on here exactly, but I think the parent process is doing the same Promise dance before starting a major GC. According to the comment:

* When mGCRunner fires
 * --------------------
 *
 * When mGCRunner fires it calls GCRunnerFired.  This starts in the
 * WaitToMajorGC state:
 *
 *  * If this is a parent process it jumps to the next state
 *  * If this is a content process it will ask the parent if now is a good
 *      time to do a GC.  (MayGCNow)
 *  * kill the mGCRunner
 *  * Exit

except that the parent process does not seem to jump to the next state. It seems to do the same as a content process would: kill the GC runner, create a MozPromise for MayGCNow, etc. It looks like the request is immediately granted, but it still goes through all the promise machinery and stuff?

I'm inferring this because I implemented interruptible GCs for when the parent process sends an IPC message to a content process saying there's been a keypress or whatever. But the parent is getting interrupted, and the marker table looks like:

Runnable - DummyEvent (lots of these)
Runnable - CCGCScheduler::EnsureGCRunner (19.887µs)
Runnable - CCGCScheduler::EnsureGCRunner (27.612µs)
GC Interrupt
Runnable - MozPromise::ThenValueBase::ResolveOrRejectRunnable
Runnable - DummyEvent (lots of these)

What that means is that we saw an EnsureGCRunner runnable, then another one that starts doing a GC but is immediately interrupted by the promise resolution. I believe that promise is most likely the MayGCNow promise. I also don't see code to skip over the WaitToMajorGC state in the parent.

Comment 1

[Steve Fink [:sfink] [:s:]]

Looking into this further, it seems the default behavior of MozPromise is to queue up a Runnable to resolve the promise. So although the code in the parent process does immediately identify that the GC can be allowed to continue, the promise resolution process delays the GCRunner processing until a later pass through the queue. It looks like promises can be resolved synchronously, which would fix this, but in this case it would be better to not create a promise in the first place.

Comment 2

[Steve Fink [:sfink] [:s:]]

Attachment: Bug 1751543 - Skip the "can I GC yet?" check entirely in the parent process

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dc74a9409316
Skip the "can I GC yet?" check entirely in the parent process r=smaug

Comment 4

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/dc74a9409316