There are several layers to this patch:
1. GeckoChildProcessHost now exposes a promise that's resolved when
the process handle is available (or rejected if launch failed), as a
nonblocking alternative to LaunchAndWaitForProcessHandle.
2. ContentParent builds on this with the private method
LaunchSubprocessAsync and the public method PreallocateProcessAsync;
synchronous launch continues to exist for the regular on-demand launch
path, for the time being.
3. PreallocatedProcessManager now uses async launch, and handles the new
"launch in progress" state appropriately.
Depends on D8942
Differential Revision: https://phabricator.services.mozilla.com/D8943
--HG--
extra : moz-landing-system : lando
This fixes/adjusts two things about how content process preallocation is blocked:
1. Processes aren't registered as blockers until after they launch
successfully. The main goal is to not leak a blocker if launch fails,
but we don't need to block *while* launching synchronously, because this
all happens on the main thread.
2. Preallocated processes themselves aren't blockers. The main goal
here is so that async preallocation doesn't need extra complexity to
avoid being blocked by itself when launch completes. This mostly
doesn't affect actual behavior, because we currently support at most
one preallocated process. The difference is the window from when the
process is sent its first PBrowserConstructor until when it's next idle,
where there is now no longer a blocker, but this seems to be relatively
short (~100ms) and we don't even try to launch a new process until at
least 1s + an idle runnable.
This patch does not explicitly RemoveBlocker in ActorDestroy like the
first attempt did, because it's unnecessary: this is handled in the
ipc:content-shutdown observer.
Differential Revision: https://phabricator.services.mozilla.com/D8939
--HG--
extra : moz-landing-system : lando
There are several layers to this patch:
1. GeckoChildProcessHost now exposes a promise that's resolved when
the process handle is available (or rejected if launch failed), as a
nonblocking alternative to LaunchAndWaitForProcessHandle.
2. ContentParent builds on this with the private method
LaunchSubprocessAsync and the public method PreallocateProcessAsync;
synchronous launch continues to exist for the regular on-demand launch
path, for the time being.
3. PreallocatedProcessManager now uses async launch, and handles the new
"launch in progress" state appropriately.
Depends on D8942
Differential Revision: https://phabricator.services.mozilla.com/D8943
--HG--
extra : moz-landing-system : lando
This fixes/adjusts two things about how content process preallocation is blocked:
1. Processes aren't registered as blockers until after they launch
successfully. The main goal is to not leak a blocker if launch fails,
but we don't need to block *while* launching synchronously, because this
all happens on the main thread.
2. Preallocated processes themselves aren't blockers. The main goal
here is so that async preallocation doesn't need extra complexity to
avoid being blocked by itself when launch completes. This mostly
doesn't affect actual behavior, because we currently support at most
one preallocated process. The difference is the window from when the
process is sent its first PBrowserConstructor until when it's next idle,
where there is now no longer a blocker, but this seems to be relatively
short (~100ms) and we don't even try to launch a new process until at
least 1s + an idle runnable.
This patch does not explicitly RemoveBlocker in ActorDestroy like the
first attempt did, because it's unnecessary: this is handled in the
ipc:content-shutdown observer.
Differential Revision: https://phabricator.services.mozilla.com/D8939
--HG--
extra : moz-landing-system : lando
This makes sure to release blockers (so that content process
preallocation can resume) in error cases, and stops making preallocated
processes themselves blockers, because it's unnecessary (we don't
currently support multiple preallocated processes) and not doing it
means not having to handle those error cases as well.
(Also, in the future we might want to allow the possibility of multiple
concurrent launches if the hardware can support it with acceptable
performance.)
Differential Revision: https://phabricator.services.mozilla.com/D5725
--HG--
extra : moz-landing-system : lando
This is currently a no-op, but the idea here is to make sure to set the
process to "active" when we're about to use it for something.
MozReview-Commit-ID: 2QUlALhfD4k
--HG--
extra : rebase_source : 13a67e9353bb47593b1394ce7ae7a7b6eef6e381
We should not let the ppm to do work before the first paint in a new cp. This patch
makes sure that we only let the ppm spawn a new process after the last process reached
an idle state AND the main process becomes idle too.
To prevent addons or other code to rapidly create and destroy content processes
under various conditions, we let the preallocated process manager to reuse short
lived content processes.
To mitigate the delay that a new content process startup might cause, when the
browser reaches a non-busy state we attempt to prelaunch an empty content process
in the background that can be grabbed and used the next time we need one. This patch
enables the preallocated process manager by default and attempts to fix all the
issues that prevented us doing this sooner.
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
This allows us to send a sync fork request to the Nuwa process when we need one but there is no
spare process available. After an app is launched, the request to fork a spare process is still
handled asynchronously.
--HG--
extra : rebase_source : 9b692a647f4fc861285d95f0372d6a9913eadf64
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
Sylvestre Ledru
Jed Davis
Andreea Pavel
Blake Kaplan
Ryan VanderMeulen
Jim Mathies
Gabor Krizsanits
Bill McCloskey
Carsten "Tomcat" Book
Ehsan Akhgari
Kan-Ru Chen
Alexandre Lissy
Kyle Huey
Thomas Zimmermann
Birunthan Mohanathas
Phil Ringnalda
Nathan Froyd
Cervantes Yu
Ting-Yu Chou
Andrew McCreight