gecko-dev/startupcache/StartupCacheParent.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

31 строка
827 B
C
Исходник Обычный вид История

Bug 1627075 - OMT and OMP StartupCache access r=froydnj The overall goal of this patch is to make the StartupCache accessible anywhere. There's two main pieces to that equation: 1. Allowing it to be accessed off main thread, which means modifying the mutex usage to ensure that all data accessed from non-main threads is protected. 2. Allowing it to be accessed out of the chrome process, which means passing a handle to a shared cache buffer down to child processes. Number 1 is somewhat fiddly, but it's all generally straightforward work. I'll hope that the comments and the code are sufficient to explain what's going on there. Number 2 has some decisions to be made: - The first decision was to pass a handle to a frozen chunk of memory down to all child processes, rather than passing a handle to an actual file. There's two reasons for this: 1) since we want to compress the underlying file on disk, giving that file to child processes would mean they have to decompress it themselves, eating CPU time. 2) since they would have to decompress it themselves, they would have to allocate the memory for the decompressed buffers, meaning they cannot all simply share one big decompressed buffer. - The drawback of this decision is that we have to load and decompress the buffer up front, before we spawn any child processes. We attempt to mitigate this by keeping track of all the entries that child processes access, and only including those in the frozen decompressed shared buffer. - We base our implementation of this approach off of the shared preferences implementation. Hopefully I got all of the pieces to fit together correctly. They seem to work in local testing and on try, but I think they require a set of experienced eyes looking carefully at them. - Another decision was whether to send the handles to the buffers over IPC or via command line. We went with the command line approach, because the startup cache would need to be accessed very early on in order to ensure we do not read from any omnijars, and we could not make that work via IPC. - Unfortunately this means adding another hard-coded FD, similar to kPrefMapFileDescriptor. It seems like at the very least we need to rope all of these together into one place, but I think that should be filed as a follow-up? Lastly, because this patch is a bit of a monster to review - first, thank you for looking at it, and second, the reason we're invested in this is because we saw a >10% improvement in cold startup times on reference hardware, with a p value less than 0.01. It's still not abundantly clear how reference hardware numbers translate to numbers on release, and they certainly don't translate well to Nightly numbers, but it's enough to convince me that it's worth some effort. Depends on D78584 Differential Revision: https://phabricator.services.mozilla.com/D77635
2020-07-08 05:46:11 +03:00
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 2; -*- */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#ifndef StartupCacheParent_h
#define StartupCacheParent_h
#include "mozilla/scache/StartupCache.h"
#include "mozilla/scache/PStartupCacheParent.h"
namespace mozilla {
namespace scache {
using mozilla::ipc::IPCResult;
class StartupCacheParent final : public PStartupCacheParent {
friend class PStartupCacheParent;
protected:
IPCResult Recv__delete__(nsTArray<EntryData>&& entries);
virtual void ActorDestroy(ActorDestroyReason aWhy) override;
};
} // namespace scache
} // namespace mozilla
#endif // StartupCacheParent_h