gecko-dev/startupcache/test
Doug Thayer fcbcc674d2 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 02:46:11 +00:00
..
browser Bug 1636244 - Relax the StartupCache telemetry test r=froydnj 2020-06-16 21:34:28 +00:00
TestStartupCache.cpp Bug 1627075 - OMT and OMP StartupCache access r=froydnj 2020-07-08 02:46:11 +00:00
moz.build