Bug 1607505 - Move StartupCache destructor later in shutdown r=froydnj a=reland CLOSED TREE

Since we've decoupled the writing of the StartupCache from the freeing
of the StartupCache's tables (which takes nontrivial time), this patch
moves the StartupCache's destructor later in shutdown so it will be
skipped in the early _exit(0) efforts. There is a remaining
WaitOnWriteThread in the StartupCache's destructor, but this is a
minor sanity check to avoid use-after-frees in the write thread during
shutdown. In general it won't matter as we already wait for the write
thread in the xpcom-shutdown observer, and if we shut down during write,
the system is set up to be okay with that (because it already happens).

Differential Revision: https://phabricator.services.mozilla.com/D62295

--HG--
extra : source : d79f1d283acde1a971fe0e5e6f1a8db075f8589a
extra : histedit_source : 32a2b4fec1fcf35960155b0f4280a38bcb54ec19

xpcom/build/XPCOMInit.cpp

@@ -634,7 +634,6 @@ nsresult ShutdownXPCOM(nsIServiceManager* aServMgr) {
     gfxPlatform::ShutdownLayersIPC();
     mozilla::RemoteDecoderManagerChild::Shutdown();
 
-    mozilla::scache::StartupCache::DeleteSingleton();
     if (observerService) {
       mozilla::KillClearOnShutdown(ShutdownPhase::ShutdownThreads);
       observerService->NotifyObservers(
@@ -717,6 +716,8 @@ nsresult ShutdownXPCOM(nsIServiceManager* aServMgr) {
   mozilla::AppShutdown::MaybeFastShutdown(
       mozilla::ShutdownPhase::ShutdownPostLastCycleCollection);
 
+  mozilla::scache::StartupCache::DeleteSingleton();
+
   PROFILER_ADD_MARKER("Shutdown xpcom", OTHER);
 
   // Shutdown xpcom. This will release all loaders and cause others holding