With block size 128, rounding `128` to end of next block gives `256`, which is
not what we want when running MSG iterations. That could mean over-iterating and
buffering unnecessary amounts of silence.
MozReview-Commit-ID: vW14l2ygRy
--HG--
extra : rebase_source : 8aeedc8958e646f9730c9163447e3355a73fd42e
Some included headers for source code in layout directory are left unused. This
patch merely removes these redundant headers. All of these headers are still
found in use for other code, so all of them and their related cpp files are kept
still.
MozReview-Commit-ID: KCleuWyOV8Z
--HG--
extra : rebase_source : 6e892dcd8ad8c1f56069d4d93bc7124641361232
This changeset changes behavior.
If the profile is streamed before any JSContext has gone away, we now iterate
over the entire buffer twice (per thread): First, to collect information about
JIT frames, and then again when we build the JSON for the samples. The first
traversal stores small pieces of JSON for JIT fromes in individual strings, and
the second iteration splices those strings into the thread JSON's frame table.
When the JSContext for a thread goes away, we no longer build JSON for samples,
and we don't reset the profiler buffer. We now only build the JSON for JIT
frames. Once the complete profile is requested and we build samples for it, we
iterate over the entire buffer, and look up the cached JIT frame information for
JitReturnAddr entries from the correct range. Different parts of the buffer may
correspond to the life time of different JSContexts: For each JSContext we will
have one range in the JITFrameInfo, and we can look up the correct range based
on the buffer position of the JitReturnAddr entry that we're processing.
This new way of doing things has multiple advantages:
- We no longer reset the buffer, so we no longer lose information about other
threads.
- All threads from a given process now always have sample data for the same
time range. Before this change, the "partial profile" from a thread that
lost its JSContext could extend further into the past than the other threads'
profiles.
- Requesting profiles multiple times now has more consistent results. Before
this change, the first requested profile would include the partial profile,
but then the partial profile was discarded. And the second requested profile
would not contain any data for the time before the JSContext went away.
- We now do less work when a thread's JSContext goes away. This should
decrease the interruption time.
MozReview-Commit-ID: 3KhnPtBijna
--HG--
extra : rebase_source : 2ef5ac933e4db1c98526a2b36147ff031893de9e
extra : intermediate-source : d63b04327077d1ef55f509b365cd2693905b0733
extra : source : f2d8c993aa2c16bc491c55179d545f5a2c727391
In an upcoming patch we'll want to initialize mUniqueStrings by stealing
another object's UniqueJSONStrings, but UniqueJSONStrings itself is not
move-constructible. But UniquePtr is.
Making UniqueJSONStrings itself move-constructible would be a bit tricky
because it has a SpliceableChunkedJSONWriter which is not move-constructible;
and making SpliceableChunkedJSONWriter move-constructible is hard because
there's no obvious "empty but valid" state that we could leave a moved-out-of
SpliceableChunkedJSONWriter in; for example, it expects to have a non-null
WriteFunc at all times.
MozReview-Commit-ID: Q6o61HFTiD
--HG--
extra : rebase_source : e1073be9892cf7cfd6ca4f2562ce939690b3b4d7
This also renames FlushSamplesAndMarkers to NotifyAboutToLoseJSContext.
MozReview-Commit-ID: FWinMi85yDZ
--HG--
extra : rebase_source : 6d8bfd6937ce757108f80f43e878a2dbead318bd
This makes it clear which combinations of fields are possible.
MozReview-Commit-ID: C3PriO7nWsJ
--HG--
extra : rebase_source : 68df01f11121b09b2f2762581dc28184262abfb8
I think this file was picking up such a declaration from a different file
already, through unified builds.
MozReview-Commit-ID: 9xTB2QA86U0
--HG--
extra : rebase_source : d7b614524ebdf25a185698b6632d6f925ce08da8
nsCString is the idiomatic string class we want to use anyway. There's no need
to think about std::string here.
MozReview-Commit-ID: 1rjZAyqp13d
--HG--
extra : rebase_source : 92c4eb22876c4fc89f00104c56f92a75053284e9
nsGenericHashKey never calls this operator, as far as I can tell.
MozReview-Commit-ID: NDybMI8DOA
--HG--
extra : rebase_source : 933c12e2ef4600ea33b6c7026f539e51447fc454
Combing the two clips as-is should always be correct, and since they're frequently identical, we can usually make IntersectClip a no-op.
MozReview-Commit-ID: EKHdPogzd3t
--HG--
extra : rebase_source : 13dede364b603ff5dd889141430d5d4cd7e51e17
The display items are almost certainly gone from the cache at this point, so dereferencing them can take a while.
This moves the DisplayItemData lookup, and the IsReused/HasMergedFrames checks into the ProcessDisplayItems pass (where we already use the items), and then just uses the AssignedDisplayItem entry for everything.
MozReview-Commit-ID: JrRshEyZncb
--HG--
extra : rebase_source : 280bda37cba3f9dc5a5ba3dadec5e09848b7321c
This picks up an existing fix for variant keys, which we started
using in gecko. The lack of this fix broke l10n-merge, and thus
l10n nightlies.
MozReview-Commit-ID: Gy6U52rc6PH
--HG--
extra : amend_source : 8c5e29e877a24558b96dfa18ec5a0ae05a466b93
Websites which collect passwords but don't use HTTPS start showing scary
warnings from Firefox 51 onwards and mixed context blocking has been
available even longer.
.onion sites without HTTPS support are affected as well, although their
traffic is encrypted and authenticated. This patch addresses this
shortcoming by making sure .onion sites are treated as potentially
trustworthy origins.
The secure context specification
(https://w3c.github.io/webappsec-secure-contexts/) is pretty much focused
on tying security and trustworthiness to the protocol over which domains
are accessed. However, it is not obvious why .onion sites should not be
treated as potentially trustworthy given:
"A potentially trustworthy origin is one which a user agent can
generally trust as delivering data securely.
This algorithms [sic] considers certain hosts, scheme, and origins as
potentially trustworthy, even though they might not be authenticated and
encrypted in the traditional sense."
(https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy)
We use step 8 in the algorithm to establish trustworthiness of .onion
sites by whitelisting them given the encrypted and authenticated nature
of their traffic.
Andreas Pehrson
Ed Lee
Zhang Junzhi
Markus Stange
Marco Bonardo
Dorel Luca
arthur.iakab
Matt Woodrow
Gabriel Luong
ffxbld
Tiberius Oros
ffxbld
Csoregi Natalia
Alex Chronopoulos
Tooru Fujisawa
Johan Lorenzo
Sebastian Hengst
Axel Hecht
Georg Koppen
Jordan Lund