This compartment flag was only ever needed in order to track system-privileged
add-on code running under the compartment-per-addon system. That system, and
the legacy add-ons it supported, are gone.
WebExtension compartments have their add-on ID stored on their principal, and
are tracked in less obtrusive ways, so this code is no longer useful.
MozReview-Commit-ID: NVEd3Oawak
--HG--
extra : rebase_source : 31908a4daa5e7897ce165a5383110fb722391662
Time Precision Reduction in the JS Engine was handled by a small bit of
duplicated logic. With Time Jittering, and general improvements to the
logic due to float fuzziness, we want to unify the logic for the JS Engine
and the browser into one location. This patch does that.
Note that this will leave the JS Shell without a time jittering implementation.
It currently has a time clamping implementation - but I'm not actually sure if
the shell is doing anything with it, because it's probably not calling
SetTimeResolutionUsec to set it up. In Bug 1440539 we will add a jitter
implementation for the shell. (And probably turn time rounding and jittering on
for it too.)
MozReview-Commit-ID: 2BTIMzE8MjW
--HG--
extra : rebase_source : db5cd6a219e1b89988f142fc22994bf816507889
Fuzzytime deterministically generates a random midpoint between two clamped values,
and if the unreduced timestamp is above the midpoint, the time is rounded upwards.
This allows safe time jittering to occur, as time will never go backwards on a given
timeline.
It _is_ possible for time to go backwards when comparing different (but related)
timelines, such as a relative timeline in one page (with its own
performance.timeOrigin) and a relative timeline in an iframe or Worker (which
also has its own performance.timeOrigin). This is the same behavior as the 2ms timer
reduction we previously landed; jitter doesn't make this any better or worse.
MozReview-Commit-ID: IdRLxcWDQBZ
--HG--
extra : rebase_source : 40b29d34e5cc99f9b8e6d5e711a03b9fe9bfa595
Time Precision Reduction in the JS Engine was handled by a small bit of
duplicated logic. With Time Jittering, and general improvements to the
logic due to float fuzziness, we want to unify the logic for the JS Engine
and the browser into one location. This patch does that.
Note that this will leave the JS Shell without a time jittering implementation.
It currently has a time clamping implementation - but I'm not actually sure if
the shell is doing anything with it, because it's probably not calling
SetTimeResolutionUsec to set it up. In Bug 1440539 we will add a jitter
implementation for the shell. (And probably turn time rounding and jittering on
for it too.)
MozReview-Commit-ID: 2BTIMzE8MjW
--HG--
extra : rebase_source : 035f84a88413e2ea34b239ae0228e9c1ec9a39d7
Fuzzytime deterministically generates a random midpoint between two clamped values,
and if the unreduced timestamp is above the midpoint, the time is rounded upwards.
This allows safe time jittering to occur, as time will never go backwards on a given
timeline.
It _is_ possible for time to go backwards when comparing different (but related)
timelines, such as a relative timeline in one page (with its own
performance.timeOrigin) and a relative timeline in an iframe or Worker (which
also has its own performance.timeOrigin). This is the same behavior as the 2ms timer
reduction we previously landed; jitter doesn't make this any better or worse.
MozReview-Commit-ID: IdRLxcWDQBZ
--HG--
extra : rebase_source : e455f934e6e6d65d54c122a6cec9f6cabbd5ac78
"Include what you use."
--HG--
extra : rebase_source : 2239a380029e0efbc9dd3042459222a67c38d70f
extra : amend_source : 4453c32cc469caa592049167205666997f1a1e7b
extra : histedit_source : a533edd4a4d3d0642b08989e93674661d27baa6a%2C37d27eeef9580381ccc0de8507f60166dabf1730
This also renames ForEachProfiledFrameOp::FrameHandle to ProfiledFrameHandle.
MozReview-Commit-ID: 7Jh1x2QWjXe
--HG--
extra : rebase_source : 8bb0fa15fa20215f03148cfd30ae0e41f82330fd
This requires moving some things around. RootingContext is an existing
superclass of JSContext whose members are exposed in a header file, so we can
use it to expose the location of the geckoProfiler_ member to non-JS code.
MozReview-Commit-ID: 3oClAEVMsDr
--HG--
extra : rebase_source : f5943a710cddaa65cfdcb13370f95387caaf6892
extra : source : 2f5b804cef7b0888ac6121f5645bbb910750ed72
Before this patch, the writes to stackPointer were done using sequentially-
consistent stores. On x86 these compile to 'xchg' instructions, which showed up
as the most expensive part of the PseudoStack overhead.
MozReview-Commit-ID: IP9w9ievEXZ
--HG--
extra : rebase_source : 6b08b1ce98b59812e9da6da055a9a8daa18a1200
Only one thread ever modifies a PseudoStack, so we don't need to enforce
synchronization of writes from different threads. We can just read the old
value, add one to it, and then do an atomic store with the new value, because
we know that the current value of stackPointer can't have changed in the
meantime.
On its own, this patch actually seems to make things slower. But combined with
the next patch (which changes the memory ordering to ReleaseAcquire) it doesn't.
(I haven't checked whether the next patch on its own would give just as much
improvements with and without this patch.)
MozReview-Commit-ID: 3WIdyJC9kcj
--HG--
extra : rebase_source : c4e88746a0239cab3d0f9cf6f7b7fb10732a62ab
Jan de Mooij
Boris Zbarsky
Ryan VanderMeulen
André Bargull
Kris Maglione
Andreea Pavel
Andi-Bogdan Postelnicu
Luke Wagner
Brindusan Cristian
Kannan Vijayan
Tom Ritter
Dorel Luca
Jeff Walden
Jon Coppeard
Sebastian Hengst
Markus Stange
Jason Orendorff
Steve Fink
Cosmin Sabou
Chris Peterson
Andrew McCreight
Nicolas B. Pierron